Honeypot Tales: The Case of the Missing Triage Collection

Welcome to “Honeypot Tales” an ongoing series of posts by our Director of Incident Response, Tyler Hudak, sharing stories from the front lines of cybersecurity. 

Here at Inversion6, we often setup “honeypots” to attract malicious actors and conduct research into attacker behavior. During one of our most recent exercises, I received a harsh reminder on the importance of system isolation during an active incident. 

The story is worth sharing, whether you’re a beginner or a seasoned cybersecurity professional. 

The Setup 

We began this exercise by setting up a very attractive honeypot with weak credentials and remote desktop protocol (RDP) exposed to the internet. As expected, within a few hours multiple attackers had gained access to this system. The plan was simple; let the attackers operate for a while, observe what they did and then collect triage data for analysis. 

When the time came to collect the forensic triage files (memory captures, registry hives. file system artifacts etc.), we moved everything to a temporary mounted drive (F:) for extraction. The collection process was completed successfully, and I swear I saw the .zip file containing all the triage data sitting right there on my screen. 

Before I finished up, I decided to spend some time testing other collection tools, which meant the drive containing the .zip file stayed mounted to the honeypot for several more hours.  

You can probably see where this is going. Once I finished up, downloaded the drive and checked the local copy, my triage .zip file was nowhere to be found. 

The Search 

As I went through the triage collection process again, I began to question myself: Did I miss something? Should I have copied instead of moving the file? Could the drive have been corrupted?  

The other option was more troubling. What if one of the attackers was still active on the system while I was collecting evidence? What if they found and deleted my triage file before I unmounted the drive? 

Either way, we decided to turn this setback into another learning opportunity. A deep forensic analysis of the honeypot system was begun - the same as we’d do for any IR investigation. 

First, we needed to confirm I wasn’t crazy and the triage .zip file had in fact been created and saved on the mounted drive. Fortunately, it had. 

Next, we needed to figure out who else besides me may have accessed this drive.It didn’t take long to find the attacker’s actions under the username “System32” (note how this name cleverly mimics the Windows system directory).  

We were able to confirm this access via four pieces of evidence: 

1. Windows “Quick Access” jump lists for user  “System32” clearly showed access to the triage file, as seen below. 

 

2. The RecentDocs registry key, which stores recent files opened by a user through Windows Explorer, showed the triage file as being accessed by a user named “System32”. 

 

3. Windows browser history in WebCacheV01.dat, which occasionally records file interactions, showed the .zip file being accessed. 

 

4. Shellbags, another registry artifact that records file system interactions through Explorer, also confirmed that System32 had browsed to the F: drive and accessed the zip file. 

 

 

Notably, standard NTFS artifacts on F:, like $LogFile, did not reflect the file or its deletion. The USN Journal (UsnJrnl:$J) was also missing. I don’t have an explanation for this. Let’s face it, it was probably something I did. 

Bottom line: the System32 account wasn’t mine, and it accessed the file in question. This pointed to one conclusion: the attacker found the triage collection, accessed the file and likely deleted it before we could isolate the system. 

 

The Lessons 

I’ll never be able to say for certain that this attacker deleted the file. There was no evidence specifically showing a "delete" command or log entry. However, the timeline and user-specific activity strongly points to attacker interference. 

Overall, this story reinforces a few critical incident response truths we’d all do well to remember. 

1. Containment is Critical 

When an attacker is active on a system, it’s always best to isolate it before starting forensic collection. As we saw here, attackers can and will actively interfere with evidence gathering. 

 

2. Document Your Containment Plan 
   Remember, a plan that works for 2 systems may not work for 200. You should also have a backup plan. Most incident response teams rely on EDR for containment, but it pays to be ready with an alternate method in case attackers disable it.  

 

3. Never Shut Down Unless Necessary 

When gathering volatile evidence, system isolation is always preferable to shutting down. With this in mind, avoid powering off your compromised system for as long as you can while critical info is being collected.  

 

4. Think Strategically and Proactively 

If an attacker gains access to multiple systems, a single containment action may do more harm than good by tipping them off. It’s far more effective to coordinate and contain all affected systems simultaneously, but this requires planning and practice BEFORE an incident occurs, not after. 

 

Final Thoughts 

In this case, we lost a .zip file, but we gained valuable insight into how agile and reactive attackers can be.  

If you're running live collections on a compromised system, never assume you’re alone. An attacker may still be active, and I can tell you from firsthand experience they are likely watching every move you make. 

Stay sharp out there; and remember, our incident response team is always here to help. 

Learn more about our services