First, a quick video of exploitation. If you want a “detection rule” via grep or journalctl feel free to scroll down to the bottom.

In the video, I’m using Putty on Windows to open an SSH session with my tailscale node. I login with the user -i which doesn’t exist. It immediately drops me a the root login and I verify that by running whoami.

The first question I asked myself is if can I see this login attempt in the tailscaled logs? They will not show up in the SSH server (Dropbear in this case) logs as the Tailscale client is handling all of this. I check the syslog file at /var/log/syslog and see the following:

2026-07-15T13:33:34.535160-04:00 DietPiHomeLab tailscaled[592]: magicsock: disco: node [/OSRQ] d:81766ca7a1b911d6 now using 192.168.0.205:41641 mtu=1360 tx=398c82f127ad
2026-07-15T13:33:34.685284-04:00 DietPiHomeLab tailscaled[592]: control: NetInfo: NetInfo{varies=true ipv6=false ipv6os=true udp=true icmpv4=false derp=#1 portmap=active-UMC link="" firewallmode="ipt-default"}
2026-07-15T13:33:34.685378-04:00 DietPiHomeLab tailscaled[592]: magicsock: endpoints changed: [REDACTED_IP]:41647 (portmap), [REDACTED_IP]:1720 (stun), [REDACTED_IP]:41641 (stun4localport), 192.168.0.212:41641 (local)
2026-07-15T13:33:34.733485-04:00 DietPiHomeLab tailscaled[592]: magicsock: disco: node [/OSRQ] d:81766ca7a1b911d6 now using 192.168.0.1:41641 mtu=1360 tx=f2dfd1d933fd
2026-07-15T13:33:35.371241-04:00 DietPiHomeLab tailscaled[592]: ssh-session(sess-20260715T172750-97360649bb): Session complete
2026-07-15T13:33:48.019352-04:00 DietPiHomeLab tailscaled[592]: ssh-conn-20260715T173345-1d65e5d9b8: handling conn: 100.85.179.88:50798->-i@100.105.171.109:22
2026-07-15T13:33:48.029603-04:00 DietPiHomeLab tailscaled[592]: ssh-conn-20260715T173345-1d65e5d9b8: starting session: sess-20260715T173348-860d5964ce
2026-07-15T13:33:48.029694-04:00 DietPiHomeLab tailscaled[592]: ssh-session(sess-20260715T173348-860d5964ce): handling new SSH connection from [REDACTED_USER_EMAIL] (100.85.179.88) to ssh-user "root"
2026-07-15T13:33:48.029784-04:00 DietPiHomeLab tailscaled[592]: ssh-session(sess-20260715T173348-860d5964ce): access granted to [REDACTED_USER_EMAIL] as ssh-user "root"
2026-07-15T13:33:48.029855-04:00 DietPiHomeLab tailscaled[592]: audit: SSH login: user=root uid=0 from=100.85.179.88 ts_user=[REDACTED_USER_EMAIL] node=outsider.[REDACTED_TAILNET].ts.net.
2026-07-15T13:33:48.030395-04:00 DietPiHomeLab tailscaled[592]: ssh-session(sess-20260715T173348-860d5964ce): starting pty command: [/usr/sbin/tailscaled be-child ssh --login-shell=/bin/bash
2026-07-15T13:33:48.030642-04:00 DietPiHomeLab tailscaled[592]: daemon --uid=0 --gid=0 --groups=0 --local-user=root --home-dir=/root --remote-user=[REDACTED_USER_EMAIL] --remote-ip=100.85.179.88 --has-tty=true --tty-name=pts/0 --force-v1-behavior --shell]
2026-07-15T13:33:55.537832-04:00 DietPiHomeLab tailscaled[592]: control: NetInfo: NetInfo{varies=false ipv6=false ipv6os=true udp=true icmpv4=false derp=#1 portmap=active-UMC link="" firewallmode="ipt-default"}

The following syslog entry in particular shows us the passing of the -i as the username called out by the security bulletin:

2026-07-15T13:33:48.019352-04:00 DietPiHomeLab tailscaled[592]: ssh-conn-20260715T173345-1d65e5d9b8: handling conn: 100.85.179.88:50798->-i@100.105.171.109:22

Subsequently, I can see a login from root:

2026-07-15T13:33:48.029694-04:00 DietPiHomeLab tailscaled[592]: ssh-session(sess-20260715T173348-860d5964ce): handling new SSH connection from [REDACTED_USER_EMAIL] (100.85.179.88) to ssh-user "root"

Now that I know what to look for, I can write a simple grep/journalctl command to search for line that match the pattern. This could probably be converted to a Sigma rule or other detection rule; but, I don’t have a testing environment spun up to test and validate them.

grep -E 'tailscaled[[0-9]+]: ssh-conn-[^:]+: handling conn: .*->-i@' /var/log/syslog

journalctl -u tailscaled | grep -E 'ssh-conn-[^:]+: handling conn: .*->-i@'

As a quick sidenote, this will log the user -i as the first user listed in the passwd file. I verified this and was able to log in as a different user if I placed them at the top fo the passwd file.

There appears to be one notable difference in that the profile-data/*/netmap-cache folder has files.

As the folder name suggests, these files do appear to be cached information about the network and the filenames appear to be hex-encoded ASCII. For example:

Not sure why the Windows client doesn’t leverage this or maybe my tests haven’t triggered the caching. I’d have to dig into their source code to see if it provides any hints. In my limited testing/research, the following file types exist:

There is definitely more to dig into here. From quick analysis, you could use this to easily rebuild the network map of the tailnet. This would include:

• Users
• Endpoints
• Which user owns the endpoint
• Routing rules

I am intrigued to see how similar/different the Android client is to the Linux client. This is a really useful digital artifact to have as you would need access to the owner’s Tailscale control panel to typically get all this information. More to come as there is a ton to dig into and test…

Anyways, going back to Tailscale. Back in Part 1, I had asked the question if partial downloads are kept forever or cleaned up periodically. I have an answer that is untested/unverified. It comes by way of looking at the Tailscale repository on GitHub specifically the delete.go file for Taildrop at https://github.com/tailscale/tailscale/blob/d4f2917c1bfd27529ec7997d08a8f1aa9ea903f2/feature/taildrop/delete.go. In the file we see the comment and const variable:

// deleteDelay is the amount of time to wait before we delete a file.
// A shorter value ensures timely deletion of deleted and partial files, while
// a longer value provides more opportunity for partial files to be resumed.
const deleteDelay = time.Hour

So one hour before the partial file gets deleted.

Another interesting callout from reading the code. In the ext.go file for Taildrop at https://github.com/tailscale/tailscale/blob/d4f2917c1bfd27529ec7997d08a8f1aa9ea903f2/feature/taildrop/ext.go there is a comment about how MacOS and some other clients handle the location of in-progress downloads differently.

// directFileRoot, if non-empty, means to write received files
	// directly to this directory, without staging them in an
	// intermediate buffered directory for "pick-up" later. If
	// empty, the files are received in a daemon-owned location
	// and the localapi is used to enumerate, download, and delete
	// them. This is used on macOS where the GUI lifetime is the
	// same as the Network Extension lifetime and we can thus avoid
	// double-copying files by writing them to the right location
	// immediately.
	// It's also used on several NAS platforms (Synology, TrueNAS, etc)
	// but in that case DoFinalRename is also set true, which moves the
	// *.partial file to its final name on completion.
	directFileRoot string

Again, I want to test this when I get the chance.

Going back to Part 1, I looked at logs stored by the Windows client and focused a little on artifacts related to file transfers. MacOS stores them in the System Log and you can retrieve them using the sysdiagnose command. Instructions can also be found on Tailscale’s support page at https://tailscale.com/docs/features/logging?tab=macos.

On the Windows client we saw the following line:

2026-04-21T15:02:44.495-04:00: localapi: [PUT] /localapi/v0/file-put/

On MacOS we see:

default	2026-06-22 21:18:42.990417 -0400	IPNExtension	localapi: [PUT] /localapi/v0/file-put/

Similar lines with some information added to support the System Log format. Namely, the Type and Process. Later in the log, I see the public IP for the computer I am transferring the file to:

default	2026-06-22 21:18:43.204547 -0400	IPNExtension	magicsock: disco: node [qZssQ] d:69d545be08f4adda now using [redacted]:41644 mtu=1360 tx=9f2ea8ed384c

This was a blind spot in my earlier testing since all the tailscale clients were on the same internal network. I’ll need to go back and take a look at this.

• https://cyble.com/blog/new-malware-campaign-abusing-rdpwrapper-and-tailscale-to-target-cryptocurrency-users/
• https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a

The configuration file surfaces information about the Tailscale accounts, connected Tailnets, and unattended mode/account. These could help identify malicious Tailnet connections. Looking at the logs can potentially identify other machines on the Tailnet. There is also the possibility to recover partial file transfers that didn’t complete. I still need to write up the blog post about that.

On Windows, you can solve this by using “Run Unattended” mode. This configures Tailscale to run as the system instead of the currently logged in user. For example, a machine running Windows Server Edition might want to enable this to permit multiple users to connect using RDP at once.

This could be very useful for a threat actor who wanted to maintain persistence or communications with a machine. I was interested how this configuration was stored and if I could I tell which account was set to be unattended. This information is found in the server-state.conf file that we’ve been looking at already.

Running a compare on the server-state.conf before and after setting unattended mode results in highlighting two lines where changes have been made.

The key key here is “server-mode-start-key”. This is NULL if unattended mode is disabled and has the name of the relevant profile if it is turned on. With this information you can trace back to the relevant profile which should have “ForceDaemon” set to true. You can also link this back to the User SID. Below is a screenshot with snipped sections to highlight information related to unattended mode.

I think I’m going to write a simple python script to automatically parse the server-state.conf and decode the Base64. I’ve just been doing it manually for now using Cyberchef.

We can see this SID in the following lines.

• “_current/S-1-5-21-306847822-306330466-671967995-1000”: “profile-617d”,
• “LocalUserID”: “S-1-5-21-306847822-306330466-671967995-1000”,

I created another local user on the computer and signed into Tailscale with another account. This results in more lines being added to the server-state.conf. There are now two “_current/[SID]: “profile-[ID]” lines for each local user. Each record under _profiles references the SID. With this information you can see which local accounts on the computer are using what tailscale accounts.

I had expected to see another avatar file created for the second account I logged into. This was not the case; but isn’t definitive. It is possible that the Microsoft account doesn’t provide an avatar to Tailscale. More testing is required. As a reminder the avatars are stored in %localappdata%\Tailscale\Avatars. You can refer to yesterday’s post for more details - https://ogmini.github.io/2026/04/21/Examining-Tailscale-Artifacts.html.

The server-state.conf file located at %ProgramData%\Tailscale had some obvious changes. You can see a snippet/example below with some information redacted:

{
  "_current/S-1-5-21-306847822-[SNIP]-[SNIP]-1000": "cHJ[SNIP]",
  "_machinekey": "cHJpdm[SNIP]",
  "_profiles": "eyIwNTMz[SNIP]",
  "profile-0533": "ewoJIkNv[SNIP]",
  "profile-617d": "ewoJI[SNIP]",
  "server-mode-start-key": nullbox.c
}

The redacted information is actually Base64 encoded text. Which when decoded results in the following with some information redacted:

{
  "_current/S-1-5-21-306847822-[SNIP]-[SNIP]-1000": "profile-617d",
  "_machinekey": "privkey:[SNIP]",
  "_profiles":
    "{
      "0533": {
          "ID": "0533",
          "Name": "[SNIP]@gmail.com",
          "NetworkProfile": {
              "MagicDNSName": "tail[SNIP].ts.net",
              "DomainName": "[SNIP]@gmail.com",
              "DisplayName": "[SNIP]@gmail.com"
          },
          "Key": "profile-0533",
          "UserProfile": {
              "ID": [SNIP],
              "LoginName": "[SNIP]@gmail.com",
              "DisplayName": "ogmini",
              "ProfilePicURL": "https://lh3.googleusercontent.com/a/[SNIP]"
          },
          "NodeID": "[SNIP]",
          "LocalUserID": "S-1-5-21-306847822-[SNIP]-[SNIP]-1000",
          "ControlURL": "https://controlplane.tailscale.com"
      },
      "617d": {
          "ID": "617d",
          "Name": "[SNIP]@hotmail.com",
          "NetworkProfile": {
              "MagicDNSName": "tail[SNIP].ts.net",
              "DomainName": "[SNIP]@hotmail.com",
              "DisplayName": "[SNIP]@hotmail.com"
          },
          "Key": "profile-617d",
          "UserProfile": {
              "ID": [SNIP],
              "LoginName": "[SNIP]@hotmail.com",
              "DisplayName": "FirstName LastName"
          },
          "NodeID": "[SNIP]",
          "LocalUserID": "S-1-5-21-306847822-[SNIP]-[SNIP]-1000",
          "ControlURL": "https://controlplane.tailscale.com"
      }
    }",
  "profile-0533":
    "{
      "ControlURL": "https://controlplane.tailscale.com",
      "RouteAll": true,
      "ExitNodeID": "",
      "ExitNodeIP": "",
      "InternalExitNodePrior": "",
      "ExitNodeAllowLANAccess": false,
      "CorpDNS": true,
      "RunSSH": false,
      "RunWebClient": false,
      "WantRunning": true,
      "LoggedOut": false,
      "ShieldsUp": false,
      "AdvertiseTags": null,
      "Hostname": "",
      "NotepadURLs": false,
      "AdvertiseRoutes": null,
      "AdvertiseServices": null,
      "Sync": null,
      "NoSNAT": false,
      "NoStatefulFiltering": true,
      "NetfilterMode": 2,
      "AutoUpdate": {
        "Check": true,
        "Apply": true
      },
      "AppConnector": {
        "Advertise": false
      },
      "PostureChecking": false,
      "NetfilterKind": "",
      "DriveShares": null,
      "AllowSingleHosts": true,
      "Config": {
        "PrivateNodeKey": "privkey:[SNIP]",
        "OldPrivateNodeKey": "privkey:0000000000000000000000000000000000000000000000000000000000000000",
        "UserProfile": {
          "ID": [SNIP],
          "LoginName": "[SNIP]@gmail.com",
          "DisplayName": "ogmini",
          "ProfilePicURL": "https://lh3.googleusercontent.com/a/[SNIP]"
        },
        "NetworkLockKey": "nlpriv:[SNIP]",
        "NodeID": "[SNIP]"
      }
    }",
  "profile-617d":
    "{
      "ControlURL": "https://controlplane.tailscale.com",
      "RouteAll": true,
      "ExitNodeID": "",
      "ExitNodeIP": "",
      "InternalExitNodePrior": "",
      "ExitNodeAllowLANAccess": false,
      "CorpDNS": true,
      "RunSSH": false,
      "RunWebClient": false,
      "WantRunning": true,
      "LoggedOut": false,
      "ShieldsUp": false,
      "AdvertiseTags": null,
      "Hostname": "",
      "NotepadURLs": false,
      "AdvertiseRoutes": null,
      "AdvertiseServices": null,
      "Sync": null,
      "NoSNAT": false,
      "NoStatefulFiltering": true,
      "NetfilterMode": 2,
      "AutoUpdate": {
        "Check": true,
        "Apply": true
      },
      "AppConnector": {
        "Advertise": false
      },
      "PostureChecking": false,
      "NetfilterKind": "",
      "DriveShares": null,
      "AllowSingleHosts": true,
      "Config": {
        "PrivateNodeKey": "privkey:[SNIP]",
        "OldPrivateNodeKey": "privkey:0000000000000000000000000000000000000000000000000000000000000000",
        "UserProfile": {
          "ID": [SNIP],
          "LoginName": "[SNIP]@hotmail.com",
          "DisplayName": "FirstName LastName"
        },
        "NetworkLockKey": "nlpriv:[SNIP]",
        "NodeID": "[SNIP]"
      }
    }",
  "server-mode-start-key": null
}

Pretty easy to read and we can see the records for the two accounts that I connected. There is a profile 0533 and 617d which correlate to the two accounts I logged in with. The first line with _profile denotes which account is currently active on the computer.

You’ll also notice that only one account has a ProfilePicURL which sort of lines up with my theory above about there being no avatar for the Microsoft account. This needs to be tested.

Someething to call out for possible investigations is the DisplayName which pulled the Firstname and Lastname that I specified when creating the test accounts on Google and Microsoft. Potentially useful if you have a sloppy suspect.

A lot more to dive into later. I’m particularly interested in the NodeIDs, _machinekey, and LocalUserID. More than likely that LocalUserID is the SID on the computer for the user account Tailscale is being run under. The pattern matches but I didn’t actually verify that yet. This could be useful when someone sets up Tailscale to be run unattended.

Today, I fired up a clean VM running Windows 11 25H2 and installed Tailscale 1.96.3. Authenticated with my account and started to poke around.

Locations of note:

• %localappdata%\Tailscale
  • Avatars folder
• %localappdata%\temp\Tailscale*.log
  • Installation log files
• %ProgramData%\Tailscale
  • Logs folder
  • files folder

The Avatars folder is interesting because it contains files with what appear to be HTTP/2 responses that have the avatar image embedded. I was able to extract them with a hex editor.

Tailscale also has support for secure file transfer between devices on a tailnet. You can read more at https://tailscale.com/docs/features/taildrop. In current versions, files are dropped into %userprofile%\Downloads AFTER they are temporarily stored at %ProgramData%\Tailscale\files[Account-uid-####]\ during transfer. This is to support the ability to resume interrupted tranfers. Possible to find interesting artifacts here… I wonder if they are kept forever or is this folder cleaned out periodically.

Additionally, I was able to find records in the local Tailscale logs about these transfers. Below are some examples:

Tiny transfer

2026-04-21T11:10:26.712-04:00: [v1] Accept: TCP{100.113.x.x:54099 > 100.105.x.x:34718} 41 ok out
2026-04-21T11:10:26.713-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 29500/767972
2026-04-21T11:10:26.713-04:00: [v1] Accept: TCP{100.105.x.x:34718 > 100.113.x.x:54099} 40 tcp non-syn
2026-04-21T11:10:26.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 29580/767972
2026-04-21T11:10:28.000-04:00: [v1] Accept: TCP{100.105.x.x:56010 > 100.113.x.x:36843} 52 tcp ok
2026-04-21T11:10:28.033-04:00: peerapi: got put of <=1MB in 0s from 100.105.x.x/0x7ff60151dc40

Moderate transfer

2026-04-21T11:22:08.273-04:00: [v1] Accept: TCP{100.105.x.x:56042 > 100.113.x.x:36843} 52 tcp ok
2026-04-21T11:22:08.275-04:00: [v1] Accept: TCP{100.105.x.x:56042 > 100.113.x.x:36843} 40 tcp non-syn
2026-04-21T11:22:08.275-04:00: [v1] Accept: TCP{100.105.x.x:56042 > 100.113.x.x:36843} 172 tcp non-syn
2026-04-21T11:22:08.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 36220492/1877892
2026-04-21T11:22:10.480-04:00: peerapi: got put of ~141MB in 2.2s from 100.105.x.x/0x7ff60151dc40

Cancelled transfer

2026-04-21T12:36:44.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 283171412/9316908
2026-04-21T12:36:46.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 434701012/13177516
2026-04-21T12:36:47.346-04:00: netmap: suggested exit node:  ()
2026-04-21T12:36:48.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 563871396/16888732
2026-04-21T12:36:50.347-04:00: netmap: suggested exit node:  ()
2026-04-21T12:36:50.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 704353732/20631252
2026-04-21T12:36:52.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 834675908/24517588
2026-04-21T12:36:53.242-04:00: [v1] Accept: TCP{100.105.x.x:56073 > 100.113.x.x:36843} 1280 tcp non-syn
2026-04-21T12:36:53.347-04:00: netmap: suggested exit node:  ()
2026-04-21T12:36:54.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 985344324/28780612
2026-04-21T12:36:56.347-04:00: netmap: suggested exit node:  ()
2026-04-21T12:36:56.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 1138328004/33788836
2026-04-21T12:36:58.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 1286926196/38278692
2026-04-21T12:36:59.347-04:00: netmap: suggested exit node:  ()
2026-04-21T12:37:00.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 1435116740/42726524
2026-04-21T12:37:02.348-04:00: netmap: suggested exit node:  ()
2026-04-21T12:37:02.735-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 1583067284/46583196
2026-04-21T12:37:03.242-04:00: [v1] Accept: TCP{100.105.x.x:56073 > 100.113.x.x:36843} 1280 tcp non-syn

Sent File

2026-04-21T15:02:42.720-04:00: [v1] Accept: TCP{100.105.x.x:53517 > 100.104.x.x:58294} 41 ok out
2026-04-21T15:02:42.721-04:00: [v1] Accept: TCP{100.104.x.x:58294 > 100.105.x.x:53517} 40 tcp non-syn
2026-04-21T15:02:42.721-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 892/1220
2026-04-21T15:02:44.495-04:00: localapi: [PUT] /localapi/v0/file-put/
2026-04-21T15:02:44.496-04:00: [v1] Accept: TCP{100.105.x.x:53517 > 100.104.x.x:58294} 165 ok out
2026-04-21T15:02:44.503-04:00: netmap: suggested exit node:  ()
2026-04-21T15:02:44.505-04:00: netmap: suggested exit node:  ()
2026-04-21T15:02:45.532-04:00: [v1] v1.96.3-t3ffddb134-g460d8764a peers: 1644/8036

Zeroing in on a few specific lines:

2026-04-21T11:10:28.033-04:00: peerapi: got put of <=1MB in 0s from 100.105.38.14/0x7ff60151dc40

This is logged on the client that recieves a file. We can glean the approximate size of the file, the IP of the Tailscale device that sent the file, and when the file was received.

2026-04-21T15:02:44.495-04:00: localapi: [PUT] /localapi/v0/file-put/

This is logged on the client that sent the file. Previous and subsequent log records possibly point to the IP of the Tailscale device the file was sent to. But this requires far more testing. Those log records could just be showing communication between clients.

Many more things I want to test in future posts.

Learning out Loud

What follows is the “written” version of my talk at BSides South Jersey 2026.

Powerpoint Slides

Zeltser Challenge

I’m going to be lazy here and point you to a previous post where I talked about the challenge. https://ogmini.github.io/2026/02/07/2025-Zeltser-Challenge-Recap.html

Logistics

Pick a platform or platforms of your liking and preference. You could make your posts on LinkedIn, Wordpress, Google Pages, Medium, BlueSky, etc. It is also important to have some fun with this whole process. Think of a fun name and logo/image. This is where you can add some personality and flair to it.

The Plan

Have a plan but be ready to throw it all away. I had a very structured, weekly plan for posts and it helped in the initial start of the challenge as I got my footing. It worked for about a month before I ditched it for something else.

Reality

I realized that this challenge was for me and I could do whatever I wanted. I can go in whatever direction I wanted. My initial plan only last about a month before I decided to just follow where my interests led. It was more important to just post regularly/daily as opposed to keeping to some plan.

Wandering

I ended up wandering in my journey of learning out loud. Onlookers might have thought I was lost; but “Not all those who wander are lost”. I was out there to learn and explore. I wanted to push my boundaries and at the same time experience failure and hit dead ends. These should be expected and are just a part of life. One thing to remember, that this whole challenge is not about the likes and reposts. You are doing this for yourself.

My Journey

Again, I’m going to be lazy and just point you at all my previous posts and the multitude of different topics. Your journey will be unique to you. It may be more focused or even more wide and that is OK.

Short Detours

Sometimes, you’ll take a short detour on a subject and realize that maybe it is a little too complex or not that interesting. That is fine! You learned something and can always revisit it in the future with more knowledge or undertanding. A good example for me was looking at LevelDB. This topic ended up being far more complex and requiring more time than I wanted to devote at the moment.

Day Trips

Take day trips by reading what others post! Add your spin and apply it to something. Don’t just repost about it. Do something with that knowledge. Maybe you learned about a new tool. Go try that tool out and use it for something. Write about your experience good or bad. Maybe while testing it, you’ll discover something new.

Long Journeys

This is the big part of this whole challenge. During your wandering, you may come across a topic that really grabs your interest. The destination may not be known yet. Dig in though. See what you can figure out and learn and just enjoy the experience. For me, this long journey was the research I put into Windows Notepad and the eventual publication on DFIR Review. I do not consider this the end of that journey though. I never thought that researching Windows Notepad would lead to that as it just happened naturally.

Get Lost

Don’t be afraid to get lost with topics that you know nothing about. Push your boundaries and learn new things. Take something you know you might be weak with and jump in.

Regular Pit Stops

You will need to take regular pit stops to keep your momentum going. These types of posts are really useful for when you go on vacation or need some time. They generally don’t require and “work” as you’ve already done it and are just writing about it. Examples would include:

• Recap posts
• Training/Coursework
• CTFs/Challenges

It is a good idea to write regular recap posts. Maybe every month or week. Looking back really helps you see how far you’ve come and what you were able to accomplish. You will be amazed at the progress that occurs.

We’ve all taken classes, courses, training, and studied. Write up your notes about a class or course. Talk about what tools you used or the main take away. Take notes as you study for certification exams. These can serve you well in the future as you try to remember something from the past.

CTF/Challenge writeups are a very popular thing to do. I would challenge you to go beyond the simple posting of the mechanical steps to the solution. Talk about your process of how you went about solving the problem. Don’t be afraid to talk about your FAILS or missteps you took. I really think this is one thing that is missing. No investigator goes in there and just knows where to look. They have a process that they undertake. It is easy enough to teach how to use tools. It is another to teach how and when to apply those tools.

Your Turn

I guess this would be me re-issuing the Zeltser Challenge to anyone reading this. Honestly, I found this to be a very reinvigorating experience that has led to so much learning, research, and talks. If you decide to take on this challenge, let me know. I’d love to follow your journey.

• Make a plan that you don’t have to follow
• Let your curiosity guide you and take detours
• Pick something and take that long journey
• Don’t be afraid to get lost
• Just Post