The Day I Accidentally Destroyed My Own Evidence

Most people think cybersecurity is about advanced attacks, sophisticated malware, or complicated tools. Sometimes it comes down to understanding a single character.

Today, I was working through a Windows Alternate Data Stream (ADS) exercise on Immersive Labs. The objective was straightforward: identify a hidden stream attached to a file and recover a bank decryption code stored inside it. I started by enumerating the files and streams with dir /R, which revealed exactly what I was looking for:

file7.txt:hiddensecret.txt:$DATA

file7.txt:hiddensecret.txt:$DATA

So far, so good. The lab instructions suggested using the following command to view the stream contents:

more < file7.txt:hiddensecret.txt:$DATA

more < file7.txt:hiddensecret.txt:$DATA

There was just one problem. Every time I ran it, nothing appeared on screen. The command simply returned back to an empty prompt. At first I assumed I was making a syntax mistake. I tried different variations, switched between Command Prompt and PowerShell, and started digging into the stream itself to figure out what was going on.

That's when I switched to PowerShell to check the stream metadata. The length came back at only two bytes which didn't seem right. I felt like a decryption code should have more data in it than 2 bytes. When I reviewed the raw contents it showed values 13 and 10, which I learned is just a return back to the prompt and a blank line. The stream was basically empty.

At that point the troubleshooting changed direction. The question was no longer "How do I read the stream?" It became "Why is the stream empty?"

After retracing my steps, I found the answer and honestly it was kind of embarrassing.

Earlier in my troubleshooting, I had accidentally reversed the redirection operator. Instead of reading from the stream with more <, I had written to it with more >. Here's where it gets worse. When you run more >, it doesn't immediately overwrite the file. It opens and waits for input. So I sat there, not realizing what I had done, and typed ii into the prompt before hitting Ctrl+C to escape. That ii became the new contents of the hidden stream. Instead of a decryption code, the stream now held two random characters I had typed without even realizing it. I had unknowingly destroyed the forensic artifact. One small symbol, one wrong direction, two accidental keystrokes and all my evidence was gone.

more > file7.txt:hiddensecret.txt:$DATA
ii
C^C
more < file7.txt:hiddensecret.txt:$DATA
ii

more > file7.txt:hiddensecret.txt:$DATA
ii
C^C
more < file7.txt:hiddensecret.txt:$DATA
ii

After restarting the lab and repeating the process correctly, the decryption code appeared as designed. The experience reminded me that when something doesn't make sense, don't immediately assume the tool is broken. Examine the evidence and review your assumptions. A good defender always follow the facts. I mean the clue was there the entire time. A stream containing ii was telling me a story but I just wasn't listening to it.

There is a lot of focus in cybersecurity on advanced skills, complex exploits, and cutting-edge tools. Those things matter but a lot of investigations get solved by understanding the fundamentals and paying attention to the details sitting right in front of you. In this case, the root cause wasn't Windows, it wasn't PowerShell, and it wasn't the lab environment. It was a single character typed by the operator who was actually me. Lesson learned!!

Still Learning. Still Training. Still Defending.

Patrick Nolen is a CTE Cybersecurity teacher documenting his journey of ethical hacking from the ground up. Follow along on Medium. LinkedIn: linkedin.com/in/teachnolen | Instagram: @teachnolen