The Ghost in the Logs: DFIR Through a Palimpsest Lens

History Is Written Through Palimpsests

I’m back again with another interesting literary and historical concept, that I believe is a great term to understand and make use of, as it directly align with how we as defenders perform our investigations. Say hi to “palimpsest”.

A palimpsest is a manuscript that’s been written over. Beneath the new writing, faint traces of the old remain, waiting to be uncovered. In the same way, in DFIR, attackers try to hide their actions either by deleting logs, files or blinding tools, but the fact that they do that fragments of those actions often linger and generate noise, in different places in the OS.

Before jumping to the DFIR world, let’s explore a real life example of a “palimpsest”. One of the most famous ones, is the Archimedes Palimpsest, a 10th century parchment that originally contained writings by Archimedes himself. Centuries later, the manuscript was scraped and overwritten with a prayer book, because parchment was expensive and reuse was common. For nearly a thousand years, the original work was hidden behind religious text, not visible to the naked eye, but not completely gone.

The Archimedes Palimpsest

After Imaging

Using ultraviolet light, digital imaging, and spectral analysis, researchers uncovered Archimedes’ handwriting beneath the newer ink.

While this story on its own is fascinating, I think it has a lot of similarities on how we approach digital forensics today.

Note: While I will be mentioning a lot of example from the Windows world, the concept can be applied to any other OS and in life, if you really feel like it ;)

The DFIR Palimpsest: Finding What Was Meant to Be Erased

If you ever read about or investigated incidents, you might have encountered commands that looks like the following.

wevtutil cl Security

fsutil usn deletejournal /D C:

Remove-Item -Path $inst -Force

sdelete -z c:

Attackers often try to hide and delete their trace, this could manifests in a couple of ways.

The Vanishing Act — Overwriting and Deletion

Attackers often try to clean up after themselves by overwriting, deleting or clearing logs or files. This might involve:

• Deleting Windows event logs via wevtutil or Clear-EventLog
• Overwriting files with null data
• Self-deleting malware or staged payloads
• Tampering with registry keys, then reverting them

But traces can remain:

• EDRs may still catch the deletion or the tool used to do it (wevtutil.exe running is an artifact itself)
• Windows may emit Event ID 1102 when logs are cleared.
• $MFT records, $I30 attributes, Prefetch, AmCache, and ShimCache.
• Volume Shadow Copies may retain old states even after the current ones are gone

Deletion and clearing in themselves are signals, we can use that to our advantage.

The Blindfold — Disabling or Flooding Tools

Rather than clean up after the fact, attackers may go further and blind the very tools defenders rely on.

Examples include:

• Disabling or tampering with EDR services.
• Disabling logging (ETW, AMSI, etc.)
• Flooding the system with noise.

But here’s the thing:

• Service disruptions might still be visible in system logs (Event IDs for unexpected stop/start behavior)
• Telemetry gaps themselves are anomalies. If logging stops right before suspicious activity, that’s an artifact in itself.

Absence of evidence isn’t absence, in fact, it’s often a signature in itself.

The Path Less Logged — Obscurity or Avoidance

A sophisticated attacker, might have studied the telemetry sources that are collected by the solution and went with an approach of avoiding triggers as much as possible.

For example:

• Security Event ID 4688 is enabled but the Command Line field is missing.
• The monitoring solution might be leveraging partial telemetry from a specific ETW source but not another.
• Process telemetry might be collected but not network telemetry.

While this might seem like a bad situation. The “palimpsestic” mindset teaches us that even though it might looks like nothing is there. Careful investigation will always reveal traces.

In practice it can get even worse for defenders, If you ever did some DFIR work at an SMB level or sometime even at big crop level, you know that more often than not there are no “logs” in the “traditional” sense, AKA, no Sysmon, no Security EID 4688, no EDR, no PowerShell Script block, etc.

Combining the removal of traces with the lack of visibility, creates a difficult situation for every investigator.

This is where a “palimpsestic” mindset is needed and is key.

Even in these “dire” situations, evidence often lingers. Because I'm trying to be fancy, let’s coin the term “Forensic echoes”. These echoes are scattered across the operating system in places attackers cannot clean up completely.

On Windows systems, for example:

• The Registry often holds a gold mine of evidence. Look no further than a tool like RegRipper and it’s amazing capabilities.
• $MFT and $I30 files preserve metadata about files long after deletion.
• Prefetch, AmCache, and ShimCache, can reveal programs that were ran or executed.

And the list goes on.

Conclusion

A palimpsest teaches us that even when something is erased or overwritten, it’s never truly gone (in its entirety). In DFIR, the same holds true, “Forensic echoes” linger for those who are quite enough to listen.