Reconstructing an Akira Ransomware Kill Chain from Perimeter and Endpoint Logs, (Wed, May 27th)

Most Akira write-ups focus on the ransom note or the encryption routine. By the time those show up the interesting forensic work is over. The questions that matter to defenders sit earlier. How did they get in. When did they get domain admin. What did they touch before the binary fired. Those answers live in the days before impact. They sit in two log sources that almost never get joined. The perimeter firewall and the Windows event channel. This diary walks through a recent Akira-attributed intrusion at a mid-sized organization. The reconstruction used only SSLVPN syslog and Windows EVTX exports. No EDR. No memory captures. Every identifier in the post has been anonymized. The event types and sequencing are preserved exactly as observed. The setup The environment was a single-site Active Directory forest behind a perimeter NGFW. SSLVPN gave remote access to a small workforce. We started the engagement with the following sources available: Firewall syslog covering roughly seven days before the encryption event. Authentication, IPS and traffic categories were retained. EVTX exports from both domain controllers and three member servers. Channels covered were Security, System and Microsoft-Windows-PowerShell/Operational. The ransom note text file and a sample of encrypted files. Used only to confirm attribution. No EDR. No PCAP. No proxy logs. This is a representative starting point for many small and mid-sized organizations. It is also why the joinable signal between the firewall and the Windows event channels matters so much. Stage 1: Initial access The first useful signal came from the firewall authentication log. We filtered SSLVPN events for the 72 hours before the encryption event. An unambiguous brute-force pattern jumped out. It targeted a single local SSLVPN account. The customer confirmed later that the account had been disabled in Active Directory. It remained provisioned as a local firewall user. Two details from Figure 1 deserve a closer look. The brute force was not distributed. Every failure came from a single source IP in a hosting-provider range. One IPS rule or a geo-block would have stopped it. The successful authentication landed inside the ramp. There was no pause to test the credential. The attacker walked straight in once one matched. That is the behavioral fingerprint of credential stuffing against a known target. Mapping this to the firewall vendor known SSLVPN credential exposure issue is plausible. It is not strictly provable from the logs we had. What is provable is this. The local account had no MFA. It had been deprovisioned in AD but not in the firewall. Its password survived a six-hour online attack. Stages 2 and 3: Discovery and credential access Once on the VPN the attacker had a layer-3 path into the user VLAN. The pivot point to internal evidence was the firewall NAT log. It gave us the post-VPN source IP and the relevant time window. We joined that window against the Windows Security channel. The first internal e