TL; DR
With threat actors deploying ransomware in new ways, security awareness training, protecting and testing your backups is more crucial than ever. Blocking the running of scripts on systems and the use of an XDR and/or SIEM should also be considered.
========================
Introduction
First of all, to all of my readers, I hope you are doing well. Sorry for not posting in such a long time. Similar to the past, this was due to other professional commitments. Let’s examine a cyber security topic I have been researching lately.
========================
In recent months, threat actors that use ransomware against their victims have been changing their tactics to increase their chances of being paid.
What is intermittent encryption?
Intermittent encryption is when the victim’s files instead of being encrypted in totality by ransomware are partially encrypted, enough to corrupt them and make them unusable (in short, the same result as ransomware has become known for). This is not only performed to carry out the encryption faster but also in an attempt to evade detection.
Intermittent encryption can damage files faster than fully encrypting them (thus reducing the chances of being detected while the encryption is in progress by reducing the time needed to do so). Evasion from detection is also achieved by being less demanding in terms of I/O (input/output) operations on the systems hard disk(s).
Threat intel sharing firm SentinelOne first encountered this technique in 2021 with the LockFile ransomware using it but other families of ransomware soon adopted it including Black Basta, BlackCat (ALPHV), Agenda, Qyick and PLAY.
Black Basta is the most prevalent family at this time and I have confirmed with anti-ransomware vendors they can detect its use of intermittent encryption but were less certain about the other families listed above.
The table below summarises the techniques used by these ransomware families (many thanks to SentinelOne for providing the original and more detailed version):
| Name | Characteristics | Encryption Methods Available |
| Qyick | Go programming language is used | Exact manner of encryption unknown (samples have yet to be gathered) |
| Agenda | Terminates processes/services of choiceEnables changing of file name extensions | skip-step: Encrypts in blocks in the file while skipping by user chosen intervals Fast: Only encrypts a specific quantity of the file from the beginning Percentage: Encrypts only x% of a file |
| BlackCat (ALPHV) | Written in Rust | Full, Headonly DotPattern SmartPattern, AdvancedSmartPattern Automatic Automatic encryption mode is the fastest and uses AES hardware acceleration (if available) |
| PLAY | First detected in June 2022 | Features intermittent encryption based on file size (divides file into chunks) |
| Black Basta | Written in C++ Supports Linux and Windows | Features intermittent encryption based on file size (skips by intervals based on the file size) |
Use of Windows Shortcut files
Since Microsoft’s decision to block macros within Microsoft Office documents downloaded from the internet since February this year (later finalising the change in July 2022), threat actors have been seeking not only alternatives, but alternatives that can easily scale and not be trivial to detect. The choice of Windows shortcuts fits these criteria.
The shortcut files act as convenient clickable links and icons threat actors can use for their intended victims to click on. These shortcuts can allow threat actors to carry out actions of their choice on your systems by using tools built into Windows for malicious purposes thus reducing the chances of being detected. Examples of such tools/utilities are cmd.exe, powershell.exe, rundll32.exe and wscript.exe These are used to shut down anti-malware software, deny access to folders, carry out further recon, install malware and establish persistence (starting malware after the system reboots to maintain a foothold).
Threat actors continue to develop toolkits that use shortcuts to evade detection from anti-malware software e.g. Windows Defender and bypass permission barriers such as User Account Control (UAC) within Windows with the end goal of using installing ransomware on compromised systems. Some threat actors use these shortcuts to distribute malware such as QBot and Emotet (and others).
The shortcuts usually use random filenames but others are deliberately chosen e.g. setup.exe or windowsupdater.exe. Other shortcuts appear to be point to data files such as Microsoft Word documents (.docx) or video files (.avi) but actually point to executable files (.exe)
Tampering with backups
While tampering with backups or wiping them just before encrypting systems is not new, ransomware threat actors are diversifying to catch organisations off-guard. The aim is to impact organisations who create read only (immutable) backups to prevent tampering or use the technique of air-gapping backups (backups physically separated from the network to prevent corruption/tampering).
With this in mind, threat actors have been observed encrypting systems using ransomware after a backup has been restored. They are also seeking to compromise corporate login credentials in order to obtain privileged access within an IT environment with the intention of deleting backups or adding seemingly harmless files to them. Threat actors may seek to compromise your systems and ultimately your backups by seeking to hide scripts within PDF documents inside encrypted ZIP/archive files to avoid detection by anti-malware, EDR and XDR solutions (EDR vs XDR).
They have also been observed changing the retention period of backups to just 30 minutes and then making their presence on the network known 1 hour later thus making certain no backups are then available for the victims to restore from. These newer techniques are discussed in more detail in this webinar (free to join). However, the appendix (below) includes further detail that I feel should have been present in the webinar. Please don’t misunderstand me, this is a good webinar but I feel it left out some details.
How can I protect my organisation or myself from these ransomware techniques?
- With these newer techniques to deliver and attack using ransomware becoming more common it’s important that your employees/staff know not to open suspicious attachments from unknown or even known senders and not to click links in phishing emails (or suspicious links from other sources). Regularly carried out and updated security awareness training is a key defence against these newer techniques. This advice of being vigilant of phishing attacks and suspicious links and attachments also applies to individuals.
- In an effort to prevent threat actors running scripts and code of their choice on your systems, consider migrating your employees/staff to using standard user accounts on the systems they make use of each day. They should log into a privileged account only, when necessary (preferably using a Privilege Identity Management (PIM), tool). Many scripts won’t execute or have limited effect if the threat actor can’t obtain root or administrator rights on system (they could try to escalate their privileges by exploiting a vulnerability but this is still making it harder than otherwise would be for them). To block scripts on Windows, consider the use of Windows AppLocker or the newer Windows Defender Application Control (WDAC).
- For larger organisations, to detect and block the use of scripts, consider an extended detection and response (XDR) solution. The use of an XDR solution across the organisation in addition to a SIEM while seek to make certain any suspicious or confirmed malicious activity is detected enabling you to respond.
- Make use of cyber threat intelligence to inform you of the types of organisations being targeted and what are the likely methods threat actors will use to breach your network.
- Carry out regular privileged access audits to help reduce your risk by removing old accounts and seeking to detect any suspicious activity (e.g. unknown newly created accounts or accounts with more permissions than expected).
Specifically for Backups
- Backups should be regularly tested to make certain they can be restored from when necessary.
- Become familiar with your recovery time objective (RTO) and work to resolve any issues that slow down recovery in advance of a real incident taking place.
- Carry out pen (penetration) testing and red team exercises to help to highlight potential vulnerabilities your backups may be exposed to and seek to address any issues found.
- Seek to check data to be backed up is malware free before backing it up*. If possible, restore the backups to a test environment to verify they are clean.
- Where possible, only dedicated individuals should have access to backups with strong authentication in place. The systems which create and store backups should have strong controls and be security hardened where possible (consider the use of the CIS benchmarks or NIST 800-123).
========================
*A system that regularly has software updates installed to patch known vulnerabilities, is connected to the internet via an application-level proxy or next generation firewall and has no alerts from an installed XDR solution are contributing factors to a known clean system.
========================
Thank you.
========================
Appendix
The following is an extended analysis of a potential scenario involving ransomware that was discussed at a high level in this webinar. This analysis is my opinion on whether that scenario could occur:
One newer form of ransomware attack is to deliver the ransomware in the manner of a trojan horse attack (related to but not the same as the category of trojan horse malware). If the threat actors can deliver the ransomware code in a form that is not immediately executable (e.g. the file is treated similar to a data file since it’s not executable), by some means e.g. phishing or an email attachment that you may not be able to open (or by another means), then the ransomware can carry out its goal at a later time.
The idea is for this code to be very new and undetectable by an anti-malware product since it has not been seen before by an anti-malware vendor or the wider community e.g., VirusTotal. Since the code is not executable (at this time), there will be no behavioural characteristics to show its malware. The threat actor’s goal is for this file (or files) to be backed up with the rest of your corporate data. Should another incident occur and you need to restore from your backups, the threat actors can now activate that file (or files) and then encrypt your data using a ransomware attack.
This form of attack is described in this webinar, however very little details of it are shared. From my experience, what has been omitted from the description in the webinar is how this file (or files) are suddenly executed. If the file is not executable, it could be an executable file with a deliberately wrong file extension (in a Windows environment) but that is usually detected by anti-malware software since at the binary level, the file will still begin with the format of a portable executable (represented as the letters “MZ” when viewed with a hexadecimal editor).
The webinar doesn’t describe how that change occurs (if it occurs at all). E.g. is the file a Zip (or another archive file) that is decrypted and then executed? But what would trigger that execution? An EDR, XDR solution or anti-malware software might detect that transformation (decryption) or block the script (PowerShell etc.) from executing and prevent that transformation.
A more likely scenario that the webinar doesn’t describe is for the threat actors to already be present in the network and to have established a form of persistence (e.g. fileless malware or start-up entries within the Windows registry e.g. adding a String value to the registry key HKEY_LOCALMACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run or a scheduled task that executes code at a specific time (fitting into the logic bomb scenario described in that webinar). These forms of persistence have equivalents on Unix and Linux based systems.
Using the above forms of persistence, the ransomware could encrypt your data each time you restore from your backup since that persistence will still be present on the restored system(s) and will likely be able to determine the current date is later than a time period of the threat actor’s choice in order to begin its intended purpose.
The scenario of the ransomware becoming active from dormant code upon being restored by the backup application doesn’t seem possible since executable code can’t just execute, it requires an external event e.g. a script, persistence mechanism on a system or user interaction for it to begin executing.
========================
securityinaction 