Case Summary
Marlock Ransomware is defined as a data encrypting malware. It belongs to the MedusaLocker ransomware family that was first detected back in the year 2019. Like MedusaLocker, the Marlock ransomware tries to encrypt as much data on the victim’s network to include automated spreading across remote (mapped) drives. After gaining initial access the Marlock ransomware works by encrypting files, dropping malicious files or executables, lateral movement, establishing persistence, and deleting backups.
The client discovered a ransom note, multiple encrypted host machines, and an encrypted server. The compromised server was determined to be accessible over Remote Desktop Protocol (RDP) port 3389 from the Internet based on port forwarding rules found on their small business router. This finding evidenced the theory that the compromised server was the threat actor’s initial entry point. The earliest definitive sign of intrusion activity was the installation of a uniquely keyed ScreenConnect remote monitoring and management software (RMM) instance on the host server. Three months elapsed between the earliest known intrusion activity and the encryption event, which suggests an initial access broker may have been responsible for the early intrusion activity and later sold the access to the Marlock ransomware-as-a-service gang.
The threat actor began to locally install and execute the ransomware encryptor (m01.exe) on multiple hosts. Upon execution the encryptor both established binary persistence via MedusaLocker’s svhost.exe and deleted local backups. Later, three intrusion tools mimikatz, netpass, and psexec64 were downloaded and executed on the host server effectively ensuring both Windows and browser-based passwords were compromised and remote execution achievable. RDP sessions credentialed with a privileged Windows user account allowed the threat actor to move laterally to additional victim hosts. Several additional binaries (ms01.exe, 64.exe, 32.exe) were executed on multiple hosts, however their purpose was unclear. Persistent network access was achieved using a ScreenConnect instance.
Figure 1: m01.exe (Marlock Data Encrypting Malware) Behavioral Analysis
Figure 2: m01.exe ATT&CK Matrix
Analyst Comments
The threat actor’s ability to remain undetected for approximately three months is a strong example of why an EDR/MDR solution can aid in early detection and mitigation. Had this client had an EDR/MDR solution, they may have been able to quarantine the initial payload sent by the attacker. Moreover, the initial of ScreenConnect could have been identified and mitigated as well. This is also a use case for EDR at the neighborhood business level. Companies of this small size are opportunistic targets for breaches, something that wasn’t seen in the threat landscape 10 years ago.
During the investigation Antigen quickly realized that the client regularly utilized RDP, which made it difficult to determine what was legitimate and wasn’t. Antigen identified the pattern of a specific user utilizing RDP for lateral movement. Based off the timeline of events and specific execution/encryption times, Antigen was able to identify the exact moves the threat actor made before and after the attack.
The client’s server was unfortunately accessible from the internet over RDP, which was likely the threat actor’s initial entry vector. For the threat actor, this was easy picking. If your organization needs the ability to RDP internally, you should focus on safelisting specific IPs that should do so and only allow specific users access. This way only approved IPs and users will be able to RDP internally. Had the client had these types of rules in place, they may not have been the victim of ransomware.
Antigen suspected an initial access broker (IAB) was the reason for the early intrusion activity due to the gap in time before the ransomware was identified in the network. This highlights how prominent IAB’s are in today’s world. Threat actors no longer need to do the dirty work of profiling a company and gaining initial access. They can simply purchase that access from an IAB on the Dark Web. This can make finding the initial access in an investigation difficult. Evidence of initial access might be weeks, months, or even years before a DFIR firm can assist a victim. Depending on how the client logs, you may never be able to identify the initial access. Furthermore, you then will be dealing with two separate issues, one being how the IAB got in and what they may have dropped into your environment, and what the second threat actor has done. Lastly, to reiterate on the importance of EDR/MDR/SEIM, having these offsite cloud aggregation tools would greatly assist in early detection and mitigation.
IOCs
- HOW_TO_RECOVER_DATA.html
- .marlock01
- .marlock7
- .marlock22
- .marlock*
- M01.exe SHA1: d523010e32ea34d5b56809321b84a6c14387c9d2
- Mimispool.dll (mimikatz) SHA1: 9138f91847f3d0fde8853490aa2155edf1567f0b
- Netpass.exe SHA1: 7ab128659ad586761ea68009d59a1ccf1547a039
- ithelp01@decorous[.]cyou
- ithelp01@wholeness[.]business
Figure 3: Ransomware Note Text
