Rebuilding an Akira Ransomware Attack Without EDR: What Huntress Found in the Leftovers

Most of us picture incident response as watching an attack unfold in our tooling. In practice, the tooling often shows up late. Sometimes it arrives as part of the response. Sometimes the rollout just wasn’t finished when the attackers got in.

That’s why I like a recent write-up covered by IT Security Guru. Huntress researcher Harlan Carvey and colleagues had their agent deployed at an organisation that had already been hit by Akira ransomware. No EDR telemetry for initial access, recon, credential theft or persistence. They rebuilt the attack anyway.

The core lesson is one I wish more teams internalised: missing data streams are not the same as missing evidence.

The first signal

According to the report, the first alert came shortly after the agent went live. An EDR signal fired on a domain controller: an executable named svchost.exe running as SYSTEM from C:\PerfLogs\Temp\ and loading a file called config.dll.

It turned out to be a GOST (Go Simple Tunnel) binary. GOST is an open-source proxy and tunnelling tool that has previously been linked to Akira affiliate activity.

That’s a textbook masquerade. svchost.exe is everywhere on Windows, but it has no business living in C:\PerfLogs\Temp\. Path matters more than name, and this is a good reminder why.

Everything before that point had to come from what was left on disk: Windows Event Logs, Registry artefacts and log files the ransomware itself wrote.

The reconstructed kill chain

Here’s the sequence Huntress pieced together, as reported:

• Initial access: Event logs showed the attacker connecting over RDP from a workstation that didn’t belong to the victim, with the hostname C1IFRYXI.
• Defence evasion: Shortly after, the Bitdefender console was accessed and four Bitdefender services were stopped. Service Control Manager event 7036 recorded each one.
• Credential access: An executable was run from C:\PerfLogs, most likely to dump LSASS memory.
• Persistence: The GOST tunnel was deployed, communicating with 64.227.4[.]134.
• Exfiltration: Rclone was launched from the same folder. Huntress says it has repeatedly seen Rclone used to sync stolen data to cloud storage.
• Impact: Akira was run against the organisation’s file shares.

Nothing here is exotic. That’s sort of the point. This is a familiar playbook, and the familiarity is exactly what makes it detectable if you’re looking at the right things.

One detail I’d flag: the attacker didn’t need to bring a fancy AV killer. They accessed the security console and stopped the services. If your security product’s management console is reachable with credentials an attacker can obtain, your EDR or AV is only as strong as that login.

Toolmarks instead of command lines

The part I found most useful is how the team handled the encryption phase. With no process telemetry, there was no recorded command line for the ransomware. So they relied on what they call toolmarks: the side effects a tool leaves just by doing its job.

The correlation went like this:

1. Shellbags showed the attacker browsing subfolders under a Shares directory.
2. At the same moment, the PowerShell event log captured a command deleting volume shadow copies via Get-WmiObject Win32_Shadowcopy, a standard Akira step to block recovery.
3. An Akira log file was created at the same time, confirming the ransomware had targeted that folder.
4. Less than a minute later, Shellbags showed the attacker opening one of the encrypted subfolders in Windows Explorer, apparently to check that encryption had worked.

That launch, shadow copy deletion, log file and visual check sequence repeated three more times. Around four hours after encryption began, the GOST tunnel was set up to keep a way back in.

I think this is a great example of why timeline analysis across multiple artefact types beats staring at any single log. None of these artefacts alone tells the full story. Shellbags tell you a folder was browsed. The PowerShell log tells you shadow copies were deleted. The Akira log tells you which directory was hit. Line them up by timestamp and you get something close to a narrative of hands-on-keyboard activity.

It’s also a quiet argument for making sure PowerShell logging is actually enabled and retained. That log carried a lot of weight here.

My take

A few things stand out to me beyond the specific indicators.

Post-compromise deployment isn’t a dead end. If you’re brought in after the fact, or your EDR rollout is half done, don’t assume you’re blind. Event logs, Registry artefacts like Shellbags, and the attacker’s own tool output can carry you a long way.

The persistence came late. The tunnel was established roughly four hours after encryption started. That suggests the attacker wanted a way back in after the main event. If you’re recovering from ransomware and you only clean up the encryption, you might leave the door open.

C:\PerfLogs keeps showing up. It was the staging area for the credential dumping tool, GOST and Rclone. It’s a directory most people never look at, which is exactly why it’s attractive.

Practical takeaways

Huntress’s own recommendations are deliberately practical, and I agree with all of them:

• Keep an accurate inventory of physical and virtual systems and applications. You can’t spot a rogue workstation if you don’t know what your real ones are called.
• Reduce the attack surface so there’s less to monitor and maintain.
• Enforce MFA on any remote access that has to be exposed. RDP from an unknown host was the way in here.
• Alert on logons from unknown or suspicious workstations. A hostname like C1IFRYXI that isn’t in your inventory should be loud.
• Watch locations like C:\PerfLogs for new executables being created and launched.

A few additions of my own, based on how this attack played out:

• Alert on security service stops. Event 7036 recorded each Bitdefender service going down. Multiple security services stopping in a short window should page someone.
• Lock down your security console. Put MFA on it, restrict who can reach it, and watch its login activity.
• Flag system binary names in odd paths. svchost.exe outside its normal location is a cheap, high-signal detection.
• Make sure PowerShell logging is on and retained long enough to matter after an incident.
• Watch for Rclone and shadow copy deletion. Both are common enough in ransomware cases that they deserve dedicated detections.

The full analysis, including indicators of compromise and file hashes for the Akira payload and the GOST binary, is on the Huntress blog, as noted in the IT Security Guru coverage. If you run detection for a Windows environment, it’s worth pulling those IOCs into your hunting.

Sources

• No EDR, no problem: how Huntress rebuilt an Akira ransomware attack from forensic leftovers — IT Security Guru, 2026-10-08