Defensive architecture is overwhelmingly organised around detection. Sensors, rules, models, scoring, triage: the machinery assumes the hard part is noticing.
Some adversaries have concluded that the more profitable target is the phase that comes after noticing. Not the alarm. The record the responder reaches for once the alarm has already gone off.
Part one: what the advisory says
This section reports the contents of a joint government advisory. Sources are listed at the foot of the post. Our own reading begins in part two.
On 10 August 2026, the FBI and CISA published joint advisory AA26-222A on Gunra ransomware, together with the Department of Defense Cyber Crime Center, the National Security Agency, the United States Secret Service and the Korean National Police Agency.
The advisory describes a double-extortion family that emerged in April 2025, derived from the leaked Conti ransomware source code and also operating under the name Golden Community, with ransomware-as-a-service operations formalised by January 2026. Targeting spans healthcare, financial services, critical manufacturing, transportation, government, utilities, academia, media, retail and nonprofit organisations, across the Americas, Europe, the Middle East, Africa and Asia-Pacific.
Initial access is unremarkable and effective. The advisory points primarily at internet-facing
appliances, naming FortiOS and FortiProxy authentication-bypass flaws CVE-2024-55591 and
CVE-2025-24472, alongside SSH access-control weaknesses in VPN gateways. Post-access movement uses
Impacket tooling, with the advisory naming psexec.py, smbclient.py and secretsdump.py,
alongside SMB abuse and RDP session hijacking using stolen credentials.
The multi-factor bypass is described precisely, and the precision is worth quoting. The actors "modified authentication processing files on the corporate VDI authentication portal server to allow successful authentication when a specific, Gunra-designated one time password (OTP) value was entered."
Then the part that gives this post its title. The advisory documents deliberate interference with
the evidence base: deletion of logs, clearing of command history, deletion of volume shadow copies
via WMI, and debugger evasion using the IsDebuggerPresent API. It further records that malicious
activity was conducted "during late-night and early-morning hours (10:00 p.m. - 06:00 a.m.)."
One defensive note appears in the advisory that is unusual for the genre. Researchers identified that
Linux ELF variants seed a weak pseudorandom number generator with the predictable
srand(time(NULL)), which the advisory says can permit mathematical key reconstruction using file
timestamps, allowing decryption without payment. That is a specific finding about specific variants
and should be treated as one. It is not a general recovery route, and confirming whether it applies
in any given case is work for a responder with the samples in hand.
Part two: our reading
What follows is DNA Cybertech Solutions' interpretation, not the position of any authoring agency.
Notice how little of the tradecraft above is novel. Known appliance vulnerabilities. Public post-exploitation tooling. Credential theft and reuse. A responder who has worked ransomware has seen all of it, and a detection engineer could write rules for most of it before lunch.
The anti-forensic behaviors are a different category, because they do not attack the sensor. They attack the thing you consult after the sensor has done its job.
Here is the failure mode we think matters. In most security data models, a log that was deleted and a period in which nothing happened arrive in the same shape: an absence. There is no field for this source was truncated. There is no field for command history on this host was cleared at 02:14, and everything we believe about what ran here between 22:00 and 02:14 now rests on other sources. So the absence gets filled by assumption, and the assumption is almost always the comfortable one, because a quiet interval reads as a quiet interval.
An investigation built on that inherits a conclusion nobody ever stated: nothing happened here.
The correction is not more collection. Collection is not the constraint when an adversary is removing records after they were collected. The correction is a representation able to hold three states rather than two: this was observed, this was inferred from something else, and this we could not see, for a reason we can name. When the reason is the record was destroyed, that is a materially different position from the sensor covered this window and reported nothing. An account that renders both as blank space misleads its reader in a specific and predictable direction.
The second half of the argument inverts the first, and we find it the more interesting half.
Log deletion is not only a hole in the evidence. It is an action, performed by something, at a time, with effects that persist. So is clearing command history. So is deleting shadow copies. Treated as missing data, these are a subtraction from what an investigation can conclude. Treated as behavior, with an actor, an action, an immediate effect and a lasting one, they are additions. An account stating that at 02:14 a process running under a named account cleared shell history for these users, and that the clearing is still in effect, is a stronger position than an account with a gap in it. It converts an unknown into a known event with a known author.
The VDI authentication detail is the cleanest illustration in the advisory. A modified authentication processing file is not an event that happened and ended. It is a change that remained: a property of the live system, sitting quietly in the authentication path, valid until someone finds and reverts it. Password resets do not touch it. Session terminations do not touch it. Remediating the original appliance flaw does not touch it. The question what remained? is the one that decides whether an incident is actually over, and it is a different question from what happened?, which is why we treat it as its own dimension rather than as a detail buried in a timeline.
None of this is a claim about outcomes. Recording provenance and persistence as first-class facts is
an architectural choice, and it is the choice we made. Whether it produces measurably better
conclusions under anti-forensic conditions is something we intend to test rather than assert.
[metric - to be added when benchmarked]
On the 22:00 to 06:00 timing, one short observation and no pitch. Concentrating activity in the hours when most security teams are thinnest is a staffing argument before it is a technology argument, and no representation fixes an empty chair. That is the honest case for continuously operated capability, and it deserves to be made on its own rather than smuggled into a post about evidence.
What we are not claiming
- That our platform detects Gunra, or would have. The advisory describes real intrusions in real organisations. We have no visibility into any of them and no basis for a counterfactual.
- That deleted logs can be recovered. They cannot. The argument is about representing the loss accurately, not about undoing it.
- That other platforms cannot represent uncertainty. Many handle parts of this well. Our distinction is architectural: whether observed, inferred and unobservable are modelled states in a stored behavioral structure, or notes an analyst carries in their head.
- Any measured improvement in investigation quality under anti-forensic conditions. That is design intent and an open measurement question.
- That a government advisory endorses anything. Advisories describe adversary activity. Citing one is not a claim of validation, and we would say the same if it happened to flatter us.
- That the Linux key-reconstruction finding is a dependable recovery path. The advisory describes a weakness in specific variants. Treat it as a lead for a responder, not as a plan.
- Completeness. A platform reasons over the telemetry it receives, and an adversary who deletes records reduces that telemetry. Evidence awareness is a way of being honest about that limit rather than a way of escaping it.
Understand the behavior behind the threat.
Sources
- CISA and FBI, "#StopRansomware: Gunra Ransomware", advisory AA26-222A, 10 August 2026 — https://www.cisa.gov/news-events/cybersecurity-advisories/aa26-222a
- Joint advisory PDF, Department of Defense mirror — https://media.defense.gov/2026/Aug/10/2003976697/-1/-1/0/CSA_STOPRANSOMWARE_GUNRA_RANSOMWARE.PDF
- Joint advisory PDF, IC3 mirror — https://www.ic3.gov/CSA/2026/260810.pdf
Quoted passages are taken from the advisory text as published in the government-hosted PDF mirrors listed above. Verify against the current version at cisa.gov before relying on any operational detail; the advisory may have been revised since 10 August 2026.