Akira Ransomware Leaves a File-Share Trail After Late EDR Deployment
Huntress reconstructed an Akira attack from Shellbags, ransomware logs and shadow-copy events after its endpoint agent arrived too late to record the launch.
Akira hit an organization’s Windows domain and shared folders before its Huntress endpoint agent was installed. When the agent finally raised an alert on a domain controller, it caught a suspicious svchost.exe running from C:\PerfLogs\Temp under SYSTEM and loading config.dll. The ransomware launch itself had happened outside that agent’s view. For a responder inheriting an incident midstream, the useful record is still on the machines: Huntress’s October 6 investigation tied folder-access traces, Akira logs and PowerShell shadow-copy activity to repeated encryption of shared folders.
This was one September incident investigated by a vendor that sells the EDR involved. Huntress’s analysts, Harlan Carvey and Lindsey O’Donnell-Welch, describe a domain-controller foothold, antivirus services stopping and an attacker’s file-share visits. They write: “even without a recorded ransomware command line, the timeline provides strong evidence of execution.” Preserve those older Windows artifacts and align their timestamps with the agent’s later alert.
RDP access precedes the file activity
Windows event logs placed a Remote Desktop Protocol session on an affected endpoint from a workstation the customer did not own. Soon afterward, the attacker accessed the Bitdefender console; Service Control Manager event 7036 recorded the Bitdefender Endpoint Update, Integration, Protected and Security services stopping. Scope the RDP session and service stops by host and time, then identify other machines reachable with the same accounts.
Huntress also saw procdump.exe run from C:\PerfLogs. The analysts assess that it was likely meant to dump lsass.exe for credentials; treat access to the credential process as an investigation lead, then check the account activity. They found a GOST tunnel executable at C:\PerfLogs\temp\svchost.exe and Rclone launched from C:\PerfLogs. GOST can proxy communications, while Rclone can move files. Huntress describes the tunnel as likely persistence and Rclone as an exfiltration tool; examine proxy and outbound-transfer records to establish what left this environment. The report places the GOST deployment about four hours after encryption began, so an encryption alert would still leave subsequent access to investigate.
Three artifacts locate encryption
Windows Registry Shellbags recorded the attacker browsing subfolders beneath a Shares folder. An Akira log file recorded that the ransomware targeted that share. PowerShell event logs placed shadow-copy removal alongside creation of the Akira log. The shadow-copy command included Get-WmiObject Win32_Shadowcopy and Remove-WmiObject, removing snapshots that could support local recovery. Correlate the three artifact families by host, share and time; a folder visit alone records access, while the Akira log and PowerShell events tie it to encryption.
Less than a minute after the first recorded sequence, Shellbags placed the attacker back in a subfolder through Windows Explorer. Huntress observed the same pattern three more times: ransomware-related log and PowerShell artifacts, followed by a folder check. Those follow-up folder checks identify shares that need an impact review when process history starts too late.
The investigation provides several case-specific hunting values. The unknown workstation name was C1IFRYXI; Huntress lists 64.227.4[.]134 as the GOST tunnel C2 address. It identifies the ransomware executable at C:\storage\win.exe with SHA-256 1f1bb322591b6d27fd2946e373d7d2efc2f4e1e66818846060d391600b600fba, and the GOST executable at C:\PerfLogs\temp\svchost.exe with SHA-256 d00833318a04caa019c6f95dcb3598ad947d405010bfb2f3cbd04530a00bc3a4. Match hashes and path context together: an ordinary svchost.exe under the Windows system directory is a different investigation lead from one under C:\PerfLogs.
Preserve history, then cut access
Preserve the affected controller’s event logs, Registry hives, Akira logs and file metadata before changing the host. Correlate RDP logons with 7036 service stops, folder Shellbags, Akira log creation and PowerShell events across the affected servers. Look for new executables and launches in C:\PerfLogs, then review traffic to the defanged C2 address and outbound transfers associated with the tunnel and Rclone. A match should expand the incident scope to linked accounts and reachable shares; assess the shares against backup copies before restoration.
Keep remote access behind MFA
Restrict exposed remote access and enforce multifactor authentication for the RDP entry points your administrators actually use, as Huntress recommends. Isolate a suspected foothold and restore endpoint protection only after collecting the relevant logs; review credentials touched on the domain controller and disable attacker sessions. Huntress advises monitoring logons from unknown workstations and executable launches under C:\PerfLogs as durable recognition checks.
Verify that each investigated share has an aligned Shellbags, Akira-log and PowerShell timeline or a recorded explanation for whichever artifact has aged out. Then confirm the affected controller’s antivirus services are running, the unknown RDP session is terminated, remote access requires MFA, and the tunnel process is gone. Let older Windows artifacts establish how the attack unfolded; use the agent to watch for renewed access.