Anatomy of a ransomware breach: from one exposed RDP port to domain-wide encryption in 72 hours

Most ransomware post-mortems read like weather reports — a storm came, it did damage, here is the cleanup bill. That framing is comforting and wrong. Ransomware is not weather. It is the last ten minutes of an intrusion that had been quietly underway for days, executed by a human operator who logged in, looked around, stole credentials, switched off the defences, and only then pressed the button.

What follows is a sanitized, hour-by-hour reconstruction of one such intrusion, drawn from a digital forensics and incident response (DFIR) engagement our team ran against the encrypted estate of a large Indian manufacturer. The environment was hosted inside a data centre operated by a third-party managed connectivity provider (MSP) — a detail that matters, because the root cause sat on the seam between the two organisations.

A quick note on confidentiality: every client identifier has been removed. Hostnames, account names, the organisation, the MSP, and the absolute dates have all been changed or abstracted. The forensic mechanics — the techniques, the order of operations, the artefacts that survived, and the ones that did not — are faithful to the engagement, because that is the part worth learning from. Where we cite file hashes and network indicators, those are public threat-intelligence artefacts of the malware family, not anything that attributes the case to a specific victim.

How we were engaged

This was a reactive engagement. By the time we arrived, the ransom note was already on the screens and production had stopped. The client and the MSP had done the single most important thing right: they pulled the affected systems offline and preserved them rather than rebuilding in place.

Four virtual machines were imaged for analysis:

• DC1-SFTP-01 — an internet-reachable file-transfer (SFTP/RDP) server, the suspected point of entry.
• DC1-AD-01 — the primary domain controller / Active Directory store.
• DC2-REC-01 and DC2-REC-02 — session/recording servers at a secondary site.

We completed full analysis of the SFTP server and the domain controller; the recording servers were partially analysed. Critically — and this becomes a theme — evidence on the recording servers had been tampered with (deleted), so whether data was exfiltrated before encryption remained inconclusive. That is not a comfortable sentence to write in a report, but it is an honest one, and the gaps in a DFIR timeline are as instructive as the certainties.

The precursor: a firewall rule that should never have existed

Before the first malicious packet, there was a change-management failure.

A firewall rule change in the primary data centre allowed inbound internet traffic to reach the network segment where DC1-SFTP-01 lived. That single rule turned an internal file-transfer box into an internet-facing one, with RDP (TCP/3389) answering the open internet. No one set out to expose it; the rule was written, reviewed by nobody who understood the blast radius, and left in place.

This is the unglamorous truth of most ransomware cases we work: the breach begins not with a zero-day but with a configuration that quietly widened the attack surface and was never audited afterward. The seam between the enterprise’s security expectations and the MSP’s change process is exactly where this rule slipped through.

Day 1 — Initial access: RDP, brute-forced

The earliest forensic artefact is a log entry on Day 1, 14:45:00, marking the first use of Advanced Port Scanner on the SFTP host. Everything before that timestamp is gone — which means the true moment of intrusion cannot be stated with confidence. We anchor the timeline to first-observed evidence and say so plainly, rather than inventing a tidier origin.

The mechanism of entry was RDP exposed to the internet, subjected to a brute-force / password-spray against valid usernames. Forensics suggested the initial account used to land was a low-privilege FTP account, but that detail was inconclusive. What is certain: the attacker authenticated over RDP and obtained an interactive session on DC1-SFTP-01.

Once inside, the operator did what operators do — staged tooling. All attacker files were dropped under …\Windows\Temp\, with a nested temp directory created inside it to hold the kit. Hiding malicious tooling inside a legitimate, noisy, frequently-written system path is a deliberate anti-forensic choice: Windows\Temp churns constantly, so a stray archive or executable there draws no attention.

ATT&CK mapping for this phase:

• T1190 — Exploit Public-Facing Application (the exposed segment)
• T1133 — External Remote Services (internet-facing RDP)
• T1110 — Brute Force
• T1078 — Valid Accounts

Day 3 — Discovery: mapping the neighbourhood

With a foothold established, the attacker ran Advanced Port Scanner and related reconnaissance utilities to enumerate everything reachable on the local network. This is the moment an isolated compromise becomes an estate-wide one: the SFTP server could see the domain controller and the recording servers, because the network was flat where it should have been segmented.

ATT&CK for discovery:

• T1046 — Network Service Discovery
• T1018 — Remote System Discovery

Day 3 — Credential access: Mimikatz, and a domain admin in cleartext

At Day 3, 13:50:26, the attacker launched Mimikatz, the canonical tool for harvesting credentials from Windows memory and the local security authority. The artefacts were unambiguous — the operator left the tool’s own output logs behind under the staging directory (…\mimi\!logs\Passwords.txt, NTLM.txt, SHA.txt, Users.txt), alongside a small library of launcher scripts (!start.cmd, !start-mimi.bat, and friends).

The output contained the prize: the cleartext password P@ssw0rd for an administrative service account we will call svc-recadmin. That account held domain admin privileges. From a single compromised, internet-exposed file server, the attacker now effectively owned the directory.

This is the hinge of the entire incident, and it has two independent failures stacked on top of each other. First, a domain admin account had a trivially weak, dictionary-listed password — the kind that falls to an offline crack or a memory dump in seconds. Second, the host had no protection against credential theft — no LSA Protected Process, no Credential Guard — so the secret was sitting in memory in a recoverable form.

ATT&CK for credential access:

• T1003.001 — OS Credential Dumping: LSASS Memory
• T1552 — Unsecured Credentials (the weak, reused secret)

Day 3 — Defence evasion: switching the lights off

Domain admin in hand, the attacker turned to the defences. Using the elevated account, he was able to stop the endpoint antivirus and other protective services across reachable hosts.

The forensic detail worth dwelling on: the staging directory contained CleanWipe — the antivirus vendor’s own official removal utility (CleanWipe.exe, CleanWipe.db, shipped in CleanWipe.zip). Rather than fighting the AV, the attacker uninstalled it the way the vendor intended, with the vendor’s blessed tool. This is “living off the land” taken to its logical conclusion — the most trusted binary to remove a security product is the one the security vendor signs and ships.

There is an uncomfortable implication here for the client. If the attacker needed domain admin before he could neutralise the AV, then the AV should have stopped Mimikatz from running and dumping credentials in the first place — before he ever got those privileges. The behaviour-based detection engine was either disabled or misconfigured. A security product that only works after the attacker has already won is not a control; it is decoration.

ATT&CK for defence evasion:

• T1562.001 — Impair Defenses: Disable or Modify Tools
• T1070.001 — Indicator Removal: Clear Windows Event Logs (covered below)

Day 4 — Lateral movement: PsExec and xcopy across the estate

With privileges, network visibility, and the defences down, movement was trivial. The attacker used xcopy to push the attack tooling from the SFTP server to the other servers, and PsExec to execute remotely. These are both legitimate Windows administration tools — there is no exploit here, just a domain admin doing domain-admin things on a network that could not tell the difference between an administrator and an adversary wearing his credentials.

ATT&CK for lateral movement:

• T1021.002 — Remote Services: SMB/Windows Admin Shares
• T1570 — Lateral Tool Transfer (the xcopy of tooling)
• T1569.002 — System Services: Service Execution (PsExec)

Day 4 — Impact: the encryption window

Between 07:08 and 07:30 on Day 4, the attacker kicked off the ransomware using PsExec. The payload, masquerading as svhost.exe (a deliberate typo-squat of the legitimate svchost.exe), then ran for three to four hours across multiple machines, continuously encrypting files. The last recorded activity of the ransomware process was 12:59:19.

The masquerade is worth naming explicitly: svhost.exe is one character away from svchost.exe, the legitimate Windows Service Host that runs dozens of copies on any healthy system. To an administrator glancing at a process list under pressure, the malicious process hides in a crowd of legitimate ones.

ATT&CK for impact:

• T1486 — Data Encrypted for Impact
• T1036.005 — Masquerading: Match Legitimate Name or Location

Day 4 — Anti-forensics: clearing the trail on the way out

The attacker did not simply leave. At 07:38:55, he cleared all Windows event logs — which is precisely why so much of the pre-intrusion timeline is unrecoverable, and why we keep saying “first observed” rather than “first occurred.” Then, from the remaining logon/logoff records, we could see the RDP session terminate at 07:59:14, from source IP 185[.]147[.]213[.]127 — geolocating to a commercial VPN exit node in Sweden. That was the last confirmed attacker presence; no further logins followed.

Two forensic notes:

• The egress IP is a commercial VPN endpoint, not the attacker’s true origin. It tells you the operator practised basic operational security; it does not attribute the actor. The same IP carried an abuse history across public reputation feeds.
• Log clearing is itself a high-signal event. A single “audit log cleared” (Windows Event ID 1102) at an odd hour, shipped to an off-box log store, would have been a screaming alarm — if such a store had existed. It did not (see below).

The timeline, condensed

What the post-incident analysis surfaced

Because the domain controller image was preserved, we extracted and cracked the AD password hashes offline — standard DFIR practice to gauge how exposed the directory was. The picture was bleak.

Weak passwords were endemic. Of 267 user accounts in the directory, a large fraction used dictionary-listable passwords, and — unforgivably — several administrative accounts were among them. The cracked set followed exactly the patterns every credential-stuffing wordlist already contains: P@ssw0rd, P@$$w0rd, Password!, Welcome@1234, Company@123, Summer@2021, Jan@2021, Temp4now. (We have replaced the genuinely client-identifying password strings with equivalent generic patterns; the shape of the problem is faithfully preserved.)

Dormant accounts accumulated. The directory was full of stale and unused accounts — old test accounts, departed staff, vendor logins — that no one had ever reaped. Each one is an unwatched door.

There was no off-box logging. Neither firewall logs nor system logs were being shipped anywhere durable. So when the attacker cleared the event logs, the evidence was simply gone — there was no second copy. This is the single change that would most have improved both detection and the post-incident investigation.

Detection was effectively non-existent. No control fired at access, at the Mimikatz execution, at the AV being torn down, at the PsExec fan-out, or at the log wipe. The first and only signal the organisation received was the ransom note.

Indicators of compromise (IOCs)

These are public threat-intelligence artefacts of the malware and the attacker infrastructure, suitable for retro-hunting across an estate. They do not identify the victim. If you see live connections to the network indicators below, treat the host as potentially still-infected.

Primary payload — svhost.exe

SHA-256  f4f73a451c1ec493eb3b4395d06de73598fcf5b8f7d13e81418238824d90fda3
SHA-1    05cf02f7f79f4dda97ffdc60da9171ec0699bc68
MD5      8a6c49fe4ea20484411093997d7ebf19

Tooling observed on disk (representative sample, MD5):

mimikatz.exe (x64)   a3cb3b02a683275f7e0a0f8a9a5c9e07
mimikatz.exe (Win32) 605d939941c5df2df5dbfb8ad84cfed4
mimidrv.sys          157a22689629ec876337f5f9409918d5
Advanced_Port_Scanner 6a58b52b184715583cda792b56a0a1ed
CleanWipe.exe        855e609c36b137a7f69df67fc668f9aa

Network indicators (representative sample). On execution, the payload attempted outbound connections to a long list of (largely compromised, legitimate) domains and IPs — a callback pattern characteristic of a ransomware-as-a-service family. A few of the observed domains:

bimnapratica[.]com      thee[.]network        roygolden[.]com
ditog[.]fr              krcove-zily[.]eu      vetapharma[.]fr
irinaverwer[.]com       drinkseed[.]com       birnam-wood[.]com

Attacker / abuse infrastructure:

185[.]147[.]213[.]127   RDP egress · commercial VPN exit (Sweden) · abuse history
95[.]178[.]18[.]70      source of ~1080 of ~1184 brute-force hits · poor reputation

The brute-force traffic is its own footnote. Between the log-clearing event and the isolation of the machines, 1,184 failed FTP/RDP login attempts were observed from IPs across many countries — opportunistic noise constantly probing the still-exposed surface. The overwhelming majority (~1,080) came from a single host. Internet-exposed RDP is never probed once.

Lessons learned

Rather than publishing a hyper-specific post-mortem for a single organisation, let’s talk about the bigger picture. In DFIR, we see the exact same story play out across completely different industries. The hostnames change, but the plot remains identical: internet-exposed remote access, a single stolen privileged credential, a flat network, and zero durable logging.

The truth is, none of the fixes below are exotic or cutting-edge. The gap rarely comes from a lack of awareness; it comes from a breakdown in execution and verification. Think of these practices as your absolute security floor, not the ceiling.

1. Shrink your public attack surface

Remote-access protocols like RDP should never, under any circumstances, answer to the open internet. Front them with a VPN paired with Multi-Factor Authentication (MFA), or a brokered, just-in-time access gateway. More importantly, don’t just trust your firewall configuration — actively scan your environment from the outside on a schedule to verify what is actually exposed. Internet-facing RDP remains the single most reliably abused initial-access vector in ransomware cases.

2. Treat firewall changes as “blast-radius” decisions

A single permissive rule is often the root cause of a total compromise. Any change that widens network access deserves a hard question before deployment: “If this goes live, what becomes reachable from the internet?” Follow this up with continuous policy reviews. A single mis-scoped rule should never silently turn an internal host into an internet-facing target.

3. Segment the network — one host shouldn’t equal the whole estate

Ransomware thrives on flat networks. When a single compromised box can freely talk to your domain controllers, file servers, and backup infrastructure, widespread encryption is effortless. Proper network segmentation and host-based firewalling contain the blast radius. The difference between “one server encrypted” and “the entire enterprise encrypted” is purely a matter of network design.

4. Make privileged credentials un-stealable and un-reusable

Adopt a strict tiered-administration model (Microsoft’s Tier 0/1/2 framework is the gold standard) so a domain admin credential is never used on — or recoverable from — an internet-exposed server. Use Group Policy Objects (GPOs) to enable Credential Guard and LSA Protected Process so that an LSASS dump yields absolutely nothing useful to an attacker. Finally, enforce MFA across every single remote and administrative path.

5. Kill weak passwords structurally, not via memo

Stop relying on employee compliance. Implement length-based password policies, utilise banned-password lists that block predictable patterns (like Season@Year or Company@123), and place a hard ban on shared or dictionary passwords for privileged accounts. Additionally, continuously reap dormant and orphaned accounts. Every unused account is an unwatched door, and they accumulate silently over time.

6. Verify endpoint protection fires before privilege escalation

A security product that only catches an attacker after they have already secured domain admin rights is just expensive decoration. Test your Endpoint Detection and Response (EDR) tools to ensure the behavioural and heuristic engines are actively blocking credential-dumping tools at the exact moment of execution. Keep in mind that sophisticated attackers will often look for a security vendor’s own signed removal utility to cleanly uninstall protection.

7. Log off-box, or assume your evidence will be erased

Ship your firewall and system logs immediately to an isolated collector that is completely segmented from production. This single architectural change serves a dual purpose: it preserves the forensic trail when an attacker inevitably attempts to wipe local logs, and it turns that very wiping activity into a massive, high-signal alert.

8. Build detections around the attack chain, then prove they work

Focus your engineering on high-signal, low-noise alerts that catch this specific attack methodology. Look for:

• Windows Event ID 1102 (audit log cleared)
• Antivirus/EDR service-stop events
• Sysmon Event ID 10 (LSASS handle access), filtered to processes that have no legitimate business reading process memory

Once built, validate them. Run a tabletop exercise or a purple-team simulation covering the entire sequence: initial access → credential theft → security tool termination → lateral movement → encryption. If your monitoring tools don’t light up during the test, then the lack of visibility is your immediate finding to fix.

On regulatory posture: the CERT-In clock

For Indian organisations, the forensic timeline collides directly with a legal one. CERT-In’s Direction 70B (April 2022) requires notifiable cyber incidents — ransomware squarely among them — to be reported within six hours of detection, with logs retained for 180 days and clocks synchronised to NPL/NIC. An organisation whose only “detection” event is the ransom note, and whose logs have been wiped with no off-box copy, is in a poor position to meet that obligation. We cover the mechanics of that six-hour window in a separate note on the CERT-In runbook.

What we would write differently next time

Two reflections from the team that ran this engagement.

We arrived after the logs were gone. The most painful gaps in this report — the true moment of intrusion, whether data was exfiltrated before encryption — exist because the only copy of the evidence lived on the same machines the attacker controlled. No amount of forensic skill recovers a log that was never duplicated off-box. The single highest-leverage thing an organisation can do before an incident is ensure that the evidence of the incident lives somewhere the attacker cannot reach.

“Inconclusive” is a finding, not a failure. We could not prove exfiltration, and we said so, rather than inferring it to make a cleaner story. A DFIR report earns its trust by being precise about the boundary between what the evidence shows and what it merely permits. The recording servers were tampered with; we documented the tampering and the limits it imposed, and that honesty is what lets a client make defensible decisions about disclosure.

This debrief is drawn from a real DFIR engagement and sits inside an active client relationship. The narrative is faithful to the forensic mechanics; every identifier that could attribute it to a specific organisation, provider, or individual has been changed or removed. If you are a manufacturer, a managed service provider, or a critical-infrastructure security leader and would like to discuss incident-readiness, off-box logging, or a forensic-readiness assessment of your own estate, the team is reachable through the contact page.