The Real File Lifecycle on Compromised Systems
When someone drops a tool onto a machine and then cleans up after themselves, the artifacts don't just disappear. They leave traces across the CIA triad in ways most guides gloss over. I've spent years staring at memory dumps and disk images from incidents where the operator thought they were clean. They almost never were. Let's break down what actually occurs during a typical install-and-delete cycle and how it touches each pillar of the triad. Commitment (Confidentiality side): When you install a payload, you're creating new data that didn't exist before. This could be a dropped binary, a registry key, a scheduled task, or a hidden directory. The moment of creation is where confidentiality gets compromised. But here's what most people miss: the act of deleting that file doesn't restore confidentiality. The file contents may have been exfiltrated during execution, or at minimum the process address space retained copies. Memory forensics will show you strings, configurations, and occasionally the entire binary still resident hours after the disk deletion.
Integrity: This is where the lifecycle gets messy. Installing a file changes the system state. That change is recorded in the MFT on NTFS, in the inode table, in transaction logs, and potentially in Windows Installer inventory records. Even if you delete the file, the filesystem metadata persists until that cluster is overwritten. On modern systems with USN journals enabled, the deletion itself is logged. I once worked a case where the operator used a secure deletion tool that overwrote the file data seven times, but the USN journal entry showing the original file creation path and timestamp was still intact and readable. The overwrite didn't matter. The journal entry did. Availability: A deleted file shouldn't impact availability, but compromise artifacts often do. Malware that hijacks DNS resolvers, modifies boot configuration data, or replaces system binaries to establish persistence directly undermines availability. Even a simple dropper that drops a file into Program Files can trigger Windows Defender or EDR solutions that quarantine the entire directory, breaking legitimate applications. The availability compromise isn't always the malware itself. It's the response to the malware. I learned this the hard way during an engagement where we were testing defensive visibility. We deployed a benign dropper that wrote a small executable, ran it, and then securely deleted it. The secure delete used sdelete with seven passes. Forensic examiners on the receiving end found the executable in the USN journal, recovered a partial copy from the Master File Table's resident attribute, and identified the process injection in the memory dump. Three separate artifacts from one clean operation. That changed how I approach every engagement after that.
The workaround I adopted was simpler than most people expect. Instead of trying to outsmart the artifact lifecycle, I started focusing on the timing and the environment. On systems without USN journaling enabled or with legacy filesystems, the artifact footprint shrinks dramatically. On fully patched systems with EDR running, the process creation events alone tell the whole story regardless of file deletion. The real insight is that the CIA impact of an install-and-delete cycle is rarely about the file itself. It's about everything the file touches while it exists and everything that records its presence before it's gone. Here's a practical checklist for understanding what survives:
Get the Full Details
- File system metadata: MFT entries, USN journal, prefetch files, ShimCache, AmCache
- Memory artifacts: Process injection points, dumped strings, loaded module lists
- Registry artifacts: Run keys, service entries, firedriver configurations, installer records
- Logical artifacts: Event logs, PowerShell transcripts, Windows Error Reporting files
The counter-intuitive part is that the deletion step often creates more detectable artifacts than the installation. The delete operation itself generates a registry update, a filesystem modification timestamp, and sometimes a new event log entry depending on the tool used. A simple shift-delete through Explorer leaves less trace than using a dedicated deletion utility, which is backwards from what most people assume. For detection purposes, I stop looking at whether the file exists and start mapping when it appeared, what it touched, and what records persist without it. The CIA lifecycle of compromise artifacts isn't a circle. It's a one-way diffusion. Once something enters the system, the traces spread into every subsystem. Deleting the original file is the easiest part. Cleaning up what it touched is the part nobody handles correctly.
