- Jul 27, 2015
- 5,459
Quote : " By Andrew Brandt Mark Loman
It’s a lot easier to change a ransomware’s appearance (or obfuscate its code) than to change its underlying goals or behavior. After all, ransomware must necessarily reveal its intent when it strikes. But there are behavioral traits that ransomware routinely exhibits that security software can use to decide whether the program is malicious. Some traits – such as the successive encryption of documents – are hard for attackers to change.
The author of the WastedLocker ransomware cleverly constructed a sequence of maneuvers meant to confuse and evade behavior based anti-ransomware solutions. We’ll discuss some of those tricks below, but it’s also worth mentioning that a code analysis we’ve performed on WastedLocker shows something else we didn’t expect: some of the specific techniques WastedLocker ransomware employs to obfuscate its code and perform certain tasks mirror the subroutines we’ve seen previously used by another ransomware, Bitpaymer, and in the Dridex trojan – too closely to have been a coincidence, in our opinion.
Evasion takes center stage
Ransomware creators are acutely aware that network or endpoint security controls pose a fatal threat to any operation, so they’ve developed a fixation on building complex logic for detecting and subverting those controls. Modern ransomware spends an inordinate amount of time attempting to thwart security controls. Most of the advancements we observe in ransomware development can be categorized as survival skills, so the malware remains undetected just long enough to encrypt the target’s files. Survival demands that static and dynamic endpoint protection struggle to make a determination about a file based on the appearance of its code, and that behavioral detection tools are thwarted in their efforts to determine the root cause of the malicious behavior.
Many malware families employ code obfuscation techniques, like runtime packers, as a way to thwart analysis, but a few have taken this a step further. Bitpaymer, for example, uses a unique method that calls Windows API functions using a hash of the function call, rather than the call itself. WastedLocker appears to have adopted this technique and that adds an additional layer of obfuscation by doing the entire thing in memory, where it’s harder for a behavioral detection to catch it. Over the years, ransomware file system behaviors have, largely, remained consistent. (This year’s Ryuk and REvil attacks exhibit the same file system behaviors as CryptoLocker from 2013, for example.) Ransomware defenses based on behavior monitoring are typically tailored to detect this universal telltale activity. Now that things have changed a bit, the tactics we use to detect this behavior will have to change as well.
Before diving into the tricks, you need to know that ransomware defenses based on behavior monitoring typically implement a minifilter driver. Minifilter drivers are kernel drivers that attach to the file system stack. Minifilters filter I/O operations in order to keep an eye on everything that happens to files. For example, the well-known Process Monitor utility from Sysinternals uses a minifilter driver to create a real-time log of file system activity. Most anti-ransomware solutions use a similar approach to keep an eye on what happens to files.
WastedLocker uses a trick to make it harder for behavior based anti-ransomware solutions to keep track of what is going on: using memory-mapped I/O to encrypt a file. Although it is unnecessary for ransomware to access documents as a memory-mapped file (MMF), the method is more common nowadays, as Maze and Clop also employ the same tactic. This technique allows the ransomware to transparently encrypt cached documents in memory, without causing additional disk I/O. For behavior monitoring, this may be a problem. Tools used to monitor disk writes may not notice that ransomware is accessing a cached document, because the data is served from memory instead of from disk. But the kicker here is that WastedLocker is closing the file once it has mapped a file in memory. You’d think this would result in an error, but the trick actually works because the Windows Cache Manager also opens a handle to the file once a file is mapped into memory.
Cache Manager’s lazy writer
The Cache Manager is a kernel component that sits between the file system and the Memory Manager. If a process accesses the mapped memory, the memory manager will issue a page fault and the Cache Manager will read the necessary data from disk into memory. The more memory is accessed, the more pages will be read from the disk into memory via so-called paging I/O.
The Memory Manager also keeps any eye on memory that has been modified, so-called dirty pages. If a process encrypts the mapped memory, the memory manager knows which pages need to be written back to disk. This writing is done by the Cache Manager’s Lazy Writer. The Cache Manager implements a write-back cache with lazy write. This means that dirty pages are allowed to accumulate for a short time and are then flushed to disk all at once, reducing the overall number of disk I/O operations. This also means that the writing is not done in the context of the process but in the context of the system (PID 4). It’s this aspect that can be troublesome for anti-ransomware solutions, as it becomes harder for an anti-ransomware tool to determine which process wrote to the file. "
Full source :
news.sophos.com
It’s a lot easier to change a ransomware’s appearance (or obfuscate its code) than to change its underlying goals or behavior. After all, ransomware must necessarily reveal its intent when it strikes. But there are behavioral traits that ransomware routinely exhibits that security software can use to decide whether the program is malicious. Some traits – such as the successive encryption of documents – are hard for attackers to change.
The author of the WastedLocker ransomware cleverly constructed a sequence of maneuvers meant to confuse and evade behavior based anti-ransomware solutions. We’ll discuss some of those tricks below, but it’s also worth mentioning that a code analysis we’ve performed on WastedLocker shows something else we didn’t expect: some of the specific techniques WastedLocker ransomware employs to obfuscate its code and perform certain tasks mirror the subroutines we’ve seen previously used by another ransomware, Bitpaymer, and in the Dridex trojan – too closely to have been a coincidence, in our opinion.
Evasion takes center stage
Ransomware creators are acutely aware that network or endpoint security controls pose a fatal threat to any operation, so they’ve developed a fixation on building complex logic for detecting and subverting those controls. Modern ransomware spends an inordinate amount of time attempting to thwart security controls. Most of the advancements we observe in ransomware development can be categorized as survival skills, so the malware remains undetected just long enough to encrypt the target’s files. Survival demands that static and dynamic endpoint protection struggle to make a determination about a file based on the appearance of its code, and that behavioral detection tools are thwarted in their efforts to determine the root cause of the malicious behavior.
Many malware families employ code obfuscation techniques, like runtime packers, as a way to thwart analysis, but a few have taken this a step further. Bitpaymer, for example, uses a unique method that calls Windows API functions using a hash of the function call, rather than the call itself. WastedLocker appears to have adopted this technique and that adds an additional layer of obfuscation by doing the entire thing in memory, where it’s harder for a behavioral detection to catch it. Over the years, ransomware file system behaviors have, largely, remained consistent. (This year’s Ryuk and REvil attacks exhibit the same file system behaviors as CryptoLocker from 2013, for example.) Ransomware defenses based on behavior monitoring are typically tailored to detect this universal telltale activity. Now that things have changed a bit, the tactics we use to detect this behavior will have to change as well.
Before diving into the tricks, you need to know that ransomware defenses based on behavior monitoring typically implement a minifilter driver. Minifilter drivers are kernel drivers that attach to the file system stack. Minifilters filter I/O operations in order to keep an eye on everything that happens to files. For example, the well-known Process Monitor utility from Sysinternals uses a minifilter driver to create a real-time log of file system activity. Most anti-ransomware solutions use a similar approach to keep an eye on what happens to files.
WastedLocker uses a trick to make it harder for behavior based anti-ransomware solutions to keep track of what is going on: using memory-mapped I/O to encrypt a file. Although it is unnecessary for ransomware to access documents as a memory-mapped file (MMF), the method is more common nowadays, as Maze and Clop also employ the same tactic. This technique allows the ransomware to transparently encrypt cached documents in memory, without causing additional disk I/O. For behavior monitoring, this may be a problem. Tools used to monitor disk writes may not notice that ransomware is accessing a cached document, because the data is served from memory instead of from disk. But the kicker here is that WastedLocker is closing the file once it has mapped a file in memory. You’d think this would result in an error, but the trick actually works because the Windows Cache Manager also opens a handle to the file once a file is mapped into memory.
Cache Manager’s lazy writer
The Cache Manager is a kernel component that sits between the file system and the Memory Manager. If a process accesses the mapped memory, the memory manager will issue a page fault and the Cache Manager will read the necessary data from disk into memory. The more memory is accessed, the more pages will be read from the disk into memory via so-called paging I/O.
The Memory Manager also keeps any eye on memory that has been modified, so-called dirty pages. If a process encrypts the mapped memory, the memory manager knows which pages need to be written back to disk. This writing is done by the Cache Manager’s Lazy Writer. The Cache Manager implements a write-back cache with lazy write. This means that dirty pages are allowed to accumulate for a short time and are then flushed to disk all at once, reducing the overall number of disk I/O operations. This also means that the writing is not done in the context of the process but in the context of the system (PID 4). It’s this aspect that can be troublesome for anti-ransomware solutions, as it becomes harder for an anti-ransomware tool to determine which process wrote to the file. "
Full source :
WastedLocker’s techniques point to a familiar heritage
WastedLocker’s evades detection by performing most operations in memory, and shares several characteristics with a more well known ransomware family
news.sophos.com
