When malware deletes itself, the forensic trace vanishes with it

The attack

Since February 2025, the Russia-aligned Gorbag APT group has targeted Ukrainian courts, law enforcement agencies and city councils with spearphishing emails and self-deleting stealer malware, according to ESET ^[1]. The malware grabs credentials and documents, sends them out, and then wipes itself from the system. By the time the breach is noticed, the malware is gone.

It's a bit like a burglar who not only takes the valuables but also sweeps up their footprints on the way out. You know someone was there, but the evidence of how they got in and what they touched has vanished.

Why self-deletion matters

Most malware leaves traces: files, registry keys, network logs. Forensic investigators rely on those traces to work out what happened, what was taken and how deep the compromise went. Self-deleting malware removes that comfort. The attack happened, data left the network, but the tool that did it is no longer there to examine.

That makes the incident response harder. You can see unusual network traffic in retrospect, or notice that credentials were used from odd locations, but the malware sample itself, which would tell you exactly what it was programmed to steal, is gone. What remains are the logs and records kept by the organisation's own systems, and those records can be questioned.

The evidence question

When malware deletes itself, the question shifts from "what did the malware do" to "what do our own records say it did". If those records can be quietly edited after the fact, by someone with administrator rights or by an attacker who is still inside, they become easier to dispute. An insurer, a supervisor or a court might reasonably ask: how do you know this log hasn't been tidied up since the breach was discovered?

Under the Swedish Cybersecurity Act, which implements NIS2 and applies from 15 January 2026, affected organisations must send an early warning within 24 hours of becoming aware of a significant incident, a full incident report within 72 hours, and a final report within a month ^[2]. The clock starts when you became aware, not when it suits you. If the only record of when you first knew is a log you control, and the malware that would corroborate it has deleted itself, that record needs to be solid.

Similar rules apply across the EU under NIS2 itself. The question is the same: can you show that the timeline in your incident report matches what was actually recorded at the time, and that nobody has rewritten it since?

Logs that hold up

Access controls and monitoring are the foundation, but they don't answer the question of whether a log has been changed by someone who had the right access in the first place. That is where an independent record helps.

A digital witness seals log segments as they are written, taking a fingerprint of each segment every few minutes. The content stays on your systems. The fingerprint goes onto a chain where any later change would show, even one made by someone with full administrator rights, and even one made by us. When an incident is questioned, anyone you share the log with can recalculate the fingerprint and check that it matches the sealed one. If it does, the log is exactly what was written at that time. If it doesn't, something has changed.

It doesn't replace access control, monitoring or backups, and it doesn't show that the log is complete. What it does is let you show that what you have hasn't been altered since it was sealed, which is a shorter conversation than asking people to trust the organisation that kept the log.

You integrate it through the REST API, the SDK or the MCP server. The first 2,000 witnesses a month are free. Documentation is at WitniumChain.

How it would work

1. Log segments are sealed every few minutes as they close, with a fingerprint sent to WitniumChain.
2. When an incident is reported, the sealed fingerprints show which log entries existed at what time.
3. An auditor, insurer or supervisor can check that the logs match the sealed fingerprints, proving nothing has been quietly edited.

What this means for you

If you run systems that have to report incidents under NIS2, the Cybersecurity Act or sector rules, ask yourself: if the malware sample is gone and the only record of what happened is in logs you control, could you show that those logs haven't been edited since the day of the breach? It is worth deciding that before the next incident, not during it.

Self-deleting malware is not new, but it is a reminder that forensic evidence can disappear, and that what is left behind needs to be trustworthy. The question is not whether your team would change a log, but whether you can prove to someone else that they didn't.

What to watch

The Swedish Cybersecurity Act applies from 15 January 2026 to essential and important entities in 18 sectors ^[2]. NIS2 itself sets similar deadlines across the EU. If your organisation falls under either, check now whether your incident logging and reporting process can produce records that hold up under scrutiny, especially when the malware itself has vanished.