Ransomware attacks have become increasingly sophisticated, and the “Impact” phase represents the final, most destructive part of the attack campaign. During this phase, after threat actors have achieved their initial objectives, including data exfiltration, they may deploy a ransomware cryptor to encrypt your data. To maximize their leverage, these actors often tamper with your backup and recovery mechanisms, aiming to make recovery difficult and squeeze you into paying the ransom.
Securing Your Backup Systems
Your backups are one of the most critical assets to secure in your organization. Threat actors often target backup servers to disable or delete backups before deploying ransomware. Here are some essential steps to secure your backups:
Monitor All Logins to Backup Servers: Ensure that every login attempt to your backup servers is monitored and logged. This includes successful logins as well as failed attempts.
Implement the Principle of Least Privilege: Only designated accounts should have the necessary permissions to access and perform administrative actions on backup servers. Restrict access as much as possible to minimize the attack surface.
Scanning for Backup Services: Ransomware affiliates frequently scan for backup services by checking for open ports on well-known systems. To prevent this:
Review Documentation: Refer to your backup system’s documentation to understand which ports are used for various services.
Set Up Alerts: Monitor these ports and set up alerts for any suspicious activity.
Volume Shadow Copy Service (VSS)
Many organizations rely on Microsoft’s Volume Shadow Copy Service (VSS) for backups. While VSS can be a convenient way to back up critical files, it can also pose a security risk. VSS keeps copies of essential system files, such as registry hives, in an unlocked state, making them vulnerable to threat actors.
Commands Used to Delete Shadow Copies: Ransomware operators may use the following commands to delete VSS shadow copies, thereby eliminating one of your recovery options:
vssadmin.exe delete Shadows /all /quiet wmic shadowcopy delete /nointeractive Get-WmiObject Win32_ShadowCopy | % { $_.Delete() }Get-WmiObject Win32_ShadowCopy | Remove-WmiObject Get-WmiObject Win32_ShadowCopy | ForEach-Object { $_Delete(); } Get-CimInstance Win32_ShadowCopy | Remove-CimInstanceBy deleting these shadow copies, the attackers remove a significant recovery option, making it crucial to protect and monitor VSS on your systems.
Tampering with Recovery Mechanisms
Threat actors often disable built-in recovery components using native tools, making it difficult for organizations to recover from an attack. They may use tools like bcdedit, which manipulates Boot Configuration Data (BCD) settings, or wbadmin, which configures settings for Windows Backup.
Commands Used to Disable Recovery Mechanisms:
bcdedit /set {default} recoveryenabled no bcdedit /set {default} bootstatuspolicy ignoreallfailures wbadmin delete catalog –quiet wbadmin delete systemstatebackup -keepversions:0Preventing IT Response
In addition to tampering with backup and recovery mechanisms, threat actors may also prevent IT teams from responding to the attack by weaponizing security mechanisms. They may disable Remote Desktop Protocol (RDP) or block inbound connectivity via Windows Firewall.
Common Commands Used:
Set-NetFirewallProfile -Profile Domain, Public, Private -Enabled True New-NetFirewallRule -DisplayName "Block PORTS1" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Block New-NetFirewallRule -DisplayName "Block PORTS2" -Direction Inbound -LocalPort 443 -Protocol TCP -Action Block netsh advfirewall set currentprofile state on netsh advfirewall set allprofiles state on netsh advfirewall firewall add rule name="Block PORTS6" protocol=TCP dir=in localport=80 action=block netsh advfirewall firewall add rule name="Block PORTS7" protocol=TCP dir=in localport=443 action=blockThese measures make it extremely difficult for IT teams to access affected hosts and respond to the threat, emphasizing the need for robust monitoring and proactive defense mechanisms.
Clearing Windows Event Logs
Threat actors often clear Windows Event Logs to cover their tracks. Unfortunately, this is a simple task in Windows, especially if logs are not being forwarded to a SIEM, log aggregator, or syslog server. The command Clear-EventLog is commonly used for this purpose.
Commands to Clear Event Logs:
Get-EventLog -LogName Security | Clear-EventLog Clear-EventLog -LogName Application, Security, SystemClearing event logs can make post-incident analysis extremely difficult, highlighting the importance of having log forwarding in place.
Payload Deployment Methods
Ransomware payloads are often deployed via Group Policy Objects (GPOs). Unfortunately, many organizations do not audit GPO deployment, and admin accounts are often overprivileged. This lack of oversight can allow threat actors to create and deploy GPOs without constraint, leading to widespread ransomware deployment across a domain or forest.
Threat actors may also use existing deployment methods such as SCCM, PDQ, or SolarWinds to deliver ransomware payloads. In addition, they commonly use native Windows tools like PSExec, WMIC, and BITS to execute processes remotely.
Background Intelligent Transfer Service (BITS): BITS is a Windows service that transfers data in the background, often used by Microsoft to download updates. It’s an intelligent service that minimizes impact on user experience by managing bandwidth effectively. However, threat actors can exploit BITS to transfer malicious payloads.
Detection Methods:
EDR, Event IDs 4688/4689 | Sysmon IDs 1/5: Monitor for bitsadmin.exe and review PowerShell logs for related cmdlets.
Event ID 7036: Monitor for service state changes in the System log.
Event ID 60: BITS has stopped transferring a file. Look for temporary files named BITFxxxx.tmp created in the target transfer directory.
Example Using Sysmon Event ID 11: Monitor file creation events for BITS temporary files.
file_path.keyword:/.*\\BITF[0-9]+\.tmp/Encryption Key Usage in Ransomware
Modern ransomware typically uses asymmetric key encryption, also known as public key cryptography. The public key, embedded within the ransomware payload, encrypts the victim's data. The private key, which is necessary for decryption, remains with the attacker, and victims must pay the ransom to obtain it.
File Write Methods: Overwrite vs. Copy/Delete
Ransomware payloads use two general file write methods:
Overwrite/Rename: Opens the original file, replaces its contents with encrypted data, and renames the file.
Copy/Delete: Creates a new file with encrypted data, then deletes the original file.
From a forensic perspective, the Overwrite/Rename method might leave evidence in the $UsnJrnl or $LogFile, while the Copy/Delete method might allow recovery of "deleted" files from unallocated disk space using tools like Bulk Extractor and PhotoRec.
I already have a blog recoverying evidence using Photorec do check it out:
Detecting Encryption and Ransom Notes
Monitoring for file creation events using Sysmon/EDR can help detect ransomware activity. Sysmon Event ID 2, for instance, logs file creation time changes, which can be indicative of ransomware encryption.
To understand how a specific ransomware payload encrypts files, reverse engineers and malware analysts often disassemble or decompile the ransomware's code using tools like IDA Pro and Ghidra. Detailed write-ups on ransomware samples are valuable resources for incident response.
The VX-Underground team maintains extensive collections of malware samples, including ransomware families, which can be instrumental for analysis.
The team also maintains an archive with various builders, including ransomware builders!
Importance of Backing Up Encrypted Files
Backing up encrypted files is crucial because:
Partially Encrypted Files: May still contain recoverable data.
Future Decryption Possibilities: Decryption keys or tools may become available in the future.
If using a decryptor, exercise caution. Some decryptors may be flawed, ineffective, or even malicious. Always perform malware analysis on any decryptor before use. Free decryptors for some ransomware variants are available at No More Ransom’s site, which also offers the “Crypto Sheriff” tool for identifying ransomware strains and checking for available decryption resources.
Efficiency Issues with Decryptors
Decryptors, even those provided by attackers after paying the ransom, are not always efficient. They may be slow, non-multithreaded, or otherwise poorly designed. For example, the decryptor provided by DarkSide ransomware during the Colonial Pipeline attack was notoriously slow, leading responders to develop a custom tool using the provided decryption key.
Remember: Always back up encrypted data before attempting decryption to avoid potential data loss.
Conclusion
By understanding the methodologies and tactics employed during the "Impact" phase of a ransomware attack, organizations can better prepare their defenses, respond more effectively, and mitigate the risks associated with these increasingly sophisticated threats.
Akash Patel
コメント