Mitigating Wow64 Exploit Attacks

November 10, 2015


Every once in a while, security researchers try to bypass security solutions for kicks, fame, marketing and to raise awareness for a new vulnerability that totally foils protection. Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) has seen its share of bypasses and when it is bypassed, the underlying approach grabs our attention. Somewhat like EMET’s philosophy, the technologies in our HitmanPro.Alert solution are also completely signatures-less, i.e. the behaviour-based anti-exploit technologies in both EMET and HitmanPro.Alert focus on the attack techniques and stop attacks without requiring threat information or signatures based on prior knowledge of attacks.

For people who are unfamiliar with this terrain, some background explanation is in order; why is there a need for software like EMET or HitmanPro.Alert.

To deliver malware to as many victims as possible, attackers turn to web-borne exploits that abuse vulnerable software (like Flash and Java) running on computers that visit trusted websites that contain malicious ads (malvertising) or hidden iframes that load an attack site.

But did you know that there are only a two dozen techniques to abuse any vulnerability, known and unknown? And often it takes more than a year before researchers or attackers come up with a new attack technique!

Did you also know that, depending on the vulnerability, always two or more techniques (like Heap Spray, Stack Pivot and Return-Oriented Programming (ROP)) must be used in sequence in order to be successful and deliver malware on victim’ machines? Software that aims to detect and block exploit techniques are e.g. Microsoft EMET and HitmanPro.Alert. Blocking exploit techniques stops exploit attacks on existing and future vulnerabilities and prevents malware from being delivered, no matter how obfuscated, new or sophisticated this malware is. So true anti-exploit solutions that revolve around stopping the attack techniques are kind of’ the holy grail against exploit attacks and their malware. For attackers they are a formidable barrier to conquer in order to successfully compromise a pc.

Wow64 Bypass

Last week a new technique was disclosed by Duo Security to bypass EMET’s ROP mitigations. The technique focusses on bypassing EMET’s security hooks abusing Wow64 compatibility layer.

The Wow64 compatibility layer provides a 32-bit execution environment on 64-bit Windows systems. This environment allows legacy 32-bit software to run on 64-bit computers.

Current exploit mitigation solutions protect the 32-bit environment. The bypass technique disclosed by Duo Security demonstrates that an attacker may also use the 64-bit environment when a 32-bit application is executed under Wow64. This effectively bypasses all security measures placed in the 32-bit environment.

To read more about the bypass, see the blog of Duo Security.


To get around DEP, an attacker needs to make a piece of memory on the heap executable. This piece of memory usually contains the malicious shellcode. Windows API provides functions to facilitate the modification of the protection of memory regions. For this article we focus on the NtProtectVirtualMemory function, located in ntdll.dll.

HitmanPro.Alert 3.1 provides three mitigations that relate to syscall bypasses. The following figure illustrates these three attacks using syscalls.

Wow64 Attack

Attack #1 uses a legit syscall stub (partial) with an attacker-supplied syscall index parameter. This bypasses security hooks on the NtProtectVirtualMemory stub in 32-bit ntdll.dll. This is illustrated in the following figure.

Attack #1

As you can see above, both syscall stubs (functions) look very similar. The only difference is the syscall index which is placed in register eax. A security solution will place a hook at the green line, the start of NtProtectVirtualMemory. If an attacker is able to resolve the address of a different syscall stub, for example NtQuerySection, it only needs to make sure eax contains the syscall index of NtProtectVirtualMemory. On this system it is 4Dh. Then by calling the address indicated by the red arrow, an attacker can mimic a call to NtProtectVirtualMemory.

Attack #2 bypasses the 32-bit ntdll.dll entirely by directly calling the Wow64 marshalling layer performing the NtProtectVirtualMemory in 64-bit ntdll.dll. This attack is similar to the above, but now the attacker needs to resolve a function in Wow64, specifically wow64cpu!X86SwitchTo64BitMode. A pointer to this function is normally stored in fs:[0xc0]. More details on this attack can be read on this post at pastebin, referenced by @r41p41.

Attack #3 is the bypass as disclosed by Duo Security. The attacker uses ROP gadgets to transition from 32-bit mode directly into 64-bit NtProtectVirtualMemory. See this paper on how this is done.

The first 2 attacks are mitigated by HitmanPro.Alert 3.1 build 310 (or newer). Attack #3 is mitigated by HitmanPro.Alert 3.1 build 332 (or newer).

To illustrate the responsiveness of our development team, the time between disclosure by Duo Security and the release of build 332 is less than a week.

Wow64 bypass alert


Network based exploit protections are reactive based and rely heavily on signatures. Endpoint exploit mitigation solutions are behaviour-based and are not dependent on signatures. That’s why in our opinion, behaviour-based exploit technique prevention is the preferred choice. It is possible to bypass a layered behaviour-based solution, but only if an attack is entirely based on a sequence of completely new exploit techniques. However, as is shown with the new Wow64 bypass technique, the mitigation of these new techniques could quickly be incorporated into our behaviour-based solution. Which is as of then capable of mitigating all attacks (whether compressed, encrypted or otherwise obfuscated) that are based on the newly discovered exploit technique.


Together with the release of HitmanPro.Alert 3.1 build 332 we also updated our Exploit Test Tool application. This application allows to safely trigger an exploit technique, including the new Wow64 bypass technique.


HitmanPro.Alert 3.1 build 332

Exploit Test Tool


How the Wolf attacked and outsmarted defenses with CVE-2015-3113

July 2, 2015

Malware-authors create millions of new unique malware samples every year to bypass web filters and antivirus software. But did you know that every exploit attack (to deliver malware) must use the exact same techniques to exploit software vulnerabilities? And that there are only a dozen offensive techniques to make this happen? Also, did you know that depending on the vulnerability, attackers are bound to chain 2 to 5 of these techniques to even get to the stage to deliver the malware?

As many of you know, our recently released HitmanPro.Alert 3 is purpose built to disrupt attackers during every stage of their attack – from exploitation to exfiltration. Instead of depending on prior knowledge of attacks (aka signatures), HitmanPro.Alert concentrates on the techniques required to exploit and compromise a computer from remote. If you are able to block attacks at the exploit stage, malware doesn’t even reach the machine in the first place.

Cyber Kill Chain
Figure: HitmanPro.Alert disrupts individual chains of the Cyber Kill Chain with multiple signature-less technologies

Exploit Techniques
Some of the offensive techniques that help and make exploitation possible are called Heap Spray, Stack Pivot, Return-Oriented Programming (ROP) and Vtable Hijacking. Many of these techniques are necessary and chained to evade defensive technologies like DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) that protect modern operating systems. The ability to detect and block the offensive exploit techniques in real-time puts HitmanPro.Alert in an excellent position against zero-day attacks from both nation-state attackers as well as skilled cybercriminals.

But like with malware and depending on resources like skill, time and money, there are attackers that take the easy road and there are those that want or need to go the extra mile. The recent exploit attacks on CVE-2015-3113, a previously unknown vulnerability in Adobe Flash Player, is an excellent example.

Operation Clandestine Wolf
Discovered by FireEye and coined Operation Clandestine Wolf, this attack was crafted by a nation-state attacker they call APT3, apparently a China-based threat group. And with most discovered zero-day attacks, it didn’t take long before cybercriminals heard of it and included an attack for this vulnerability in their exploit kits, to increase the success rates of their attacks (it took them only four days as revealed by security researcher Kafeine from Malware Don’t Need Coffee).

Significant differences
But there are significant differences between the APT3 exploit attack and the code in exploit kits that abuse CVE-2015-3113. APT3’s code is not only meticulously crafted to bypass standard defense techniques, it is also designed to evade Anti-Exploit solutions. So even though Anti-Exploit vendors blogged about the vulnerability and mentioned that their “users were already protected against this threat”, this is in fact not the case for the original APT3 variant! And this is actually true for most exploits. When you have sufficient skills and resources, even old existing exploits can be re-weaponized to evade anti-exploit solutions. This means that even though when it sounds or looks  like other security solutions offer identical mitigations or layers, e.g. our Dynamic Heap Spray and Hardware-assisted Control-Flow Integrity mitigations (as well as our many Risk Reduction features) make a significant difference against well-funded attackers.

But let’s discuss and compare the versions crafted by the APT3 nation-state hackers and the attack inside the Angler exploit kit.

As mentioned by FireEye, the actual exploit was RC4 encrypted inside the hp.swf file, so we had to decrypt it to reveal the perpetrating code. From the decrypted code we can see that it includes a progress indication using GIF files, that help the exploit author debug his attack as it reveals at what stage the attack fails. When the attack succeeds, the exploit retrieves a file named logoshow.gif, using a hardcoded URL in de ActionScript code (an IoC or Indicator of Compromise):

Figure: Hardcoded link in APT3’s ActionScript code

Heap Spray
The APT3 attack employs a heap spray to facilitate arbitrary code execution. Although many Anti-Exploit solutions offer Anti-Heapspraying, few people know how most heapspray mitigations work. They simply pre-allocate memory areas often used by attackers so they cannot use these ranges to setup their heap spray. Naturally, APT3 stayed clear of these memory areas which explains why most Anti-Exploit solutions do not stop the attack with their heap spray mitigation.

Unlike these solutions, the Dynamic Heap Spray feature of HitmanPro.Alert 3 is an active mitigation. It is not so easily bypassed since our technology actually analyzes and compares the contents of the memory blocks allocated and sprayed by the exploit attack. HitmanPro.Alert 3 stops the exploit even before it gains control of code execution:

HitmanPro Alert intercepts HeapSpray  APT3 CVE-2015-3113
Figure: HitmanPro.Alert intercepted APT3’s Heap Spray technique

Arbitrary Code Execution
But it’s getting interesting when you look at how the nation-state attacker controls code execution without triggering Stack Pivot and typical ROP mitigations. In most recent Flash based exploits, the exploit hijacks the vtable of a built-in object of Adobe Flash Player, e.g. the Sound object, so that a ROP chain can be started for example via an invocation of Sound.toString().

This APT3 exploit uses a different technique to trigger its ROP chain. A custom class is defined in the ActionScript which has a method that takes a large number of parameters.

this.customClassInstance.theMethod(_loc32_, _loc32_, _loc32_, _loc32_,
_loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, 
_loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, 
_loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, 
_loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, 
_loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, 
_loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, 
_loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc24_, _loc33_, 
_loc19_, _loc34_, 65536, 4096, 64, _loc32_, _loc32_, _loc32_, _loc32_, 
_loc32_, _loc32_, _loc32_, _loc32_, _loc32_, _loc19_ + 6,_loc19_ + 6,
_loc30_, _loc19_ + 6, _loc25_, _loc25_);

The method in the custom class enables the attacker to provide ROP gadgets as parameters to the function, which results in the ROP chain ending up on the current stack! This way, there is no need for the attacker to pivot the stack to a heap location that is outside the stack range of the current thread, which would be detected by most Anti-Exploit tooling.

By overwriting the function pointer so that it points to a gadget that moves the stack pointer to the beginning of the ROP chain, located on the stack, the attacker can trigger the start of the ROP chain.

6d4b33dd  83c448   add      esp,48h    ; move stack pointer to start of ROP chain
6d4b33e0  c3       ret

After  the ‘add esp,48h # RET’ gadget is executed, the stack (which is the ROP chain) looks like this:

02fae6ac  6cebb68b 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6cebb68b 6cebb68b
02fae6ec  6cebb68b 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6cebb68b 6cebb68b
02fae72c  6cebb68b 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6cebb68a 1f140100
02fae76c  6d4b6da1 1f140000 00010000 00001000 
          00000040 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6cebb68b 6cebb68b 
          6cebb68b 6cebb68b 6d4b6da7 6d4b6da7
02fae7ac  6cebaff0 6d4b6da7 6cec1b5f 6cec1b5f

There are a lot (46) of ‘dummy’ gadgets (6cebb68b) on the stack which only perform a RETurn.

6cebb68b  c3       ret

This makes sure that stack-analysis will show a call-stack that contains ‘valid’ return addresses up to a very deep call-depth.
The first non-dummy gadget (6cebb68a) pops the address 1f140100 into EAX.

6cebb68a  58       pop      eax
6cebb68b  c3       ret

The following gadget performs a memory allocation, which makes a specific memory range, starting at 1f140000 on the heap executable. This range is under control of the attacker and already contains the shellcode. However, due to DEP, it is not executable (yet).

0:005> !vprot 1f140000
BaseAddress:       1f140000
AllocationBase:    1f030000
AllocationProtect: 00000001  PAGE_NOACCESS
RegionSize:        00150000
State:             00001000  MEM_COMMIT
Protect:           00000004  PAGE_READWRITE
Type:              00020000  MEM_PRIVATE
6d4b6da1           call Kernel32!VirtualAlloc(0x1f140000, 0x10000, 0x1000, 0x40)
6d4b6da7           ret

After the call to VirtualAlloc the memory is executable.

0:005> !vprot 1f140000
BaseAddress:       1f140000
AllocationBase:    1f030000
AllocationProtect: 00000001  PAGE_NOACCESS
RegionSize:        00010000
State:             00001000  MEM_COMMIT
Protect:           00000040  PAGE_EXECUTE_READWRITE
Type:              00020000  MEM_PRIVATE

This gadget, which is legitimate code located in the Flash DLL, performs a seemingly ‘valid’ call to VirtualAlloc in the way as described by Jared DeMott of Bromium, in the technical whitepaper ‘Bypassing EMET 4.1’.  An Anti-Exploit tool based on stack analysis will conclude that the call to VirtualAlloc was legitimate and will not detect a ROP attack in progress at this stage.

When the call to VirtualAlloc returns, the stack looks like this:

02fae780  6cebb68b 6cebb68b 6cebb68b 6cebb68b
          6cebb68b 6cebb68b 6cebb68b 6cebb68b
          6cebb68b 6d4b6da7 6d4b6da7 6cebaff0
          6d4b6da7 6cec1b5f 6cec1b5f 00001000

It contains 9 times the dummy gadget 6cebb68b, which only performs a ‘RET’. After that, it contains 2 times another dummy gadget (6d4b6da7). However, this gadget has the nice property that it is call-preceded.

6d4b6da1           call Kernel32!VirtualAlloc(0x1f140000, 0x10000, 0x1000, 0x40)
6d4b6da7           ret

This feature makes sure that anti-exploit tooling that perform stack-based analysis will see a ‘legitimate’ return address that was seemingly placed onto the stack due to a valid call instruction.

The following gadget (6cebaff0) pops the address of the call-preceded gadget (6d4b6da7) into ECX.

6cebaff0 59        pop     ecx
6cebaff1 c3        ret

And finally, the gadget at address 6d4b6da7 jumps to the shellcode with an indirect JMP instruction.

6cec1b5f ff20      jmp     dword ptr [eax]      ; EAX = 1f140000
0:005> dd eax
1f140000  1f140210 00000008 057c3000 057c0140
1f140010  1f13f000 00000000 1f711000 00000000

The shellcode starts at address 1f140210.

1f140210  nop
1f140211  nop
1f140212  nop
1f140213  nop
1f140214  nop
1f140215  nop
1f140216  nop
1f140217  mov     eax,1F140008h
1f14021c  nop
1f14021d  nop
1f14021e  nop
1f14021f  mov     ebx, offset IEShims!xxx_GetProcAddress (70ed9f14)
1f140224  mov     dword ptr [eax],ebx   ; Store address at 1f140008h
1f140226  nop
1f140227  nop
1f140228  push    0
1f14022a  push    74657874h    ;
1f14022f  push    6E6F4364h    ; 'SetThreadContext'
1f140234  push    61657268h    ;
1f140239  push    54746553h    ;
1f14023e  push    esp
1f14023f  push    (KERNEL32+0x0) (75e40000) ; BaseAddress kernel32.dll
1f140244  call    ebx          ; EBX holds address of GetProcAddress

The ActionScript has placed the base address of kernel32.dll and the address of GetProcAddress into the shellcode, so that it can call this function to obtain other system functions of kernel32 without triggering anti-exploit software. One can also see that the shellcode immediately resolves the address of the function ‘SetThreadContext’. This is a very interesting function that can modify the debug register, which can disable functions that depend on them, like Microsoft EMET’s EAF mitigation.

Summarizing the key features of the APT3 version of CVE-2015-3113:

  • The ROP chain never returns directly into a critical function
  • A Stack Pivot is NOT required to start the ROP chain
  • Uses dummy call-preceded RETurn address to trick stack-based heuristics
  • Shellcode uses ‘GetProcAddress’ to resolve system functions

Anti-Exploit solutions that analyze the stack (which is under the control of the attacker) are fooled by the tricks deployed by the APT3 exploit. However the hardware-assisted Control-Flow Integrity feature of HitmanPro.Alert 3 reveals the ROP attack and is immune to the stack manipulations performed by this exploit. The following figure shows how HitmanPro.Alert 3 detects and blocks the ROP attack using Intel® hardware-assistance.

Hardware-assisted Control-Flow Integrity stopping nation-state attack on CVE-2015-3113
Figure: Hardware-assisted Control-Flow Integrity reveals ROP attack on CVE-2015-3113 

Angler Exploit Kit
The version used by the Angler exploit kit is different. Of course it uses the same vulnerability in Adobe Flash Player (CVE-2015-3113) to corrupt a vector on the heap to bypass ASLR, but it uses a different set of exploit techniques compared to the APT3 version.

The exploit deployed by the Angler exploit kit uses so-called Vtable Hijacking to start its ROP chain. A fake object with a crafted vtable is created on the heap:

0857c000  0857c040 6cbf0736 cccccccc cccccccc
0857c010  cccccccc cccccccc cccccccc cccccccc
0857c020  cccccccc cccccccc cccccccc cccccccc
0857c030  cccccccc cccccccc cccccccc cccccccc
0857c040  6ca9f992 cccccccc 6cab4745 6cac4788
0857c050  6cc334a6 6d096dd9 08578000 00008000
0857c060  00001000 00000040 0857c06c 0005e860
0857c070  89610000 90c35dfc fce58955 00e8ec81

This fake object contains a pointer to its vtable at offset 0, so the vtable starts at 0857c040.
And from within the Flash ActionScript a method of this fake object is called. This executes the following code:

6cbf0736  8b01     mov     eax,dword ptr [ecx]
6cbf0738  51       push    ecx
6cbf0739  ff5008   call    dword ptr [eax+8]

At the time of the call, ECX contains the address of the object (0857c000) and EAX contains the start address of the vtable. The call [eax+8] is the actual call of the method in the vtable, which in this case is a call to [0857c040+8] -> 6cab4745

If we take a look at the instructions that are located at this address, we can see that these will perform a stack pivot.

6cab4745  94       xchg    eax,esp
6cab4746  c3       ret

This is detected and blocked by HitmanPro.Alert:

HitmanPro Alert blocks Stack Pivot Angler EK CVE-2015-3113
Figure: HitmanPro.Alert blocking Stack Pivot technique of Angler EK attack on CVE-2015-3113

But after the stack pivot, the actual ROP chain, beginning at location 0857c040, will start. The first gadget, located at 6ca9f992, will advance the stack pointer to the location behind the stack pivot gadget address.

6ca9f992  83c408     add     esp,8
6ca9f995  c3         ret

This adds 8 to skip past the stack pivot gadget which means that the stack pointer now points to 0857c04c, so the next gadget that will be executed is located at 6cac4788.

6cac4788  95         xchg    eax,ebp
6cac4789  c3         ret

EBP now points to a location that is on the current stack and lies before the current position in the ROP chain.
The next gadget in line starts at address 6cc334a6 which swaps the contents of EDI and EAX.

6cc334a6  97         xchg    edi,eax
6cc334a7  c3         ret

Now the following gadget that will execute is the one that will make the contained shellcode executable (DEP bypass). It starts at address 6d096dd9.

6d096dd9  // call Kernel32!VirtualAlloc(0x8578000, 0x8000, 0x1000, 0x40)

This gadget, which is legitimate code located in the Flash DLL, performs a seemingly valid call to VirtualAlloc in the way as described by Jared DeMott of Bromium, in the technical whitepaper Bypassing EMET 4.1. When the allocation returns, it falls directly into the shellcode at address 0857c06c.

0857c06c 60          pushad
0857c06d e805000000  call    0857c077
0857c072 61          popad
0857c073 89fc        mov     esp,edi
0857c075 5d          pop     ebp
0857c076 c3          ret

The shellcode is located on the heap directly after the ROP chain, starting at location 857c06c.

APT3’s attack on CVE-2015-3113 doesn’t perform a stack pivot as the gadgets are placed on the current stack. In addition, it never falls directly onto critical functions or shellcode and uses return addresses that seem legitimate to foil Anti-Exploit heuristics. Compared, the techniques that are used in the Angler exploit kit are rather straightforward and will be detected and blocked by most (commercial) Anti-Exploit tools.

While evaluating both attacks I can’t help but think that APT3’s zero-day attack on CVE-2015-3113 is proofing the same point that we tried to convey and demonstrated with our example attack on an artificial zero-day vulnerability in Firefox 29.0, for MRG Effitas’ Real World Exploit Prevention Test (March 2015). Some people said it was unfair and unrealistic that MRG Effitas included our special crafted version in their test, but it turns out we did not have to wait long before a skilled attacker proofed our point as well: with enough time, effort and money, a knowledgable attacker can bypass Anti-Exploit solutions. But with unique features like our Hardware-assisted Control-Flow Integrity, HitmanPro.Alert raises the bar to new heights by further increasing the attacker’s costs, in effect avoiding future system compromise and reducing business disruption.

Users running HitmanPro.Alert 3 are and were already protected against both the nation-state version as well as the exploit kit version of the attack on CVE-2015-3113.

Protect Yourselves
You can read more about our HitmanPro.Alert software on this page:

Leaflet: HitmanPro-Alert-Brochure-2015.pdf

To increase the security posture of your computers against exploits, digital espionage and crypto-ransomware, download HitmanPro.Alert version 3 from here: (4 MB)

Exploits served via malvertising campaign

June 15, 2015

Two months ago we released HitmanPro.Alert version 3 at the RSA Conference in San Francisco.

This major new version comes with protection against crypto-ransomware and exploits.

In these two months various companies started using HitmanPro.Alert version 3 to protect exploit-susceptible applications and critical documents against malware and zero-day attacks.

Malvertising campaign
Our telemetry shows that a major malvertising campaign became active since Thursday, June 11th. This is in line with the findings of our colleagues at Fox-IT.

We’ve seen exploits being served through advertisements on these sites:

HitmanPro.Alert 3 has been very successful stopping hundreds of attacks from these sites. Blocking the exploit, preventing malware from entering the PC:


Contrary to antivirus technologies, the exploit mitigation technologies in HitmanPro.Alert require no updates, signatures or prior knowledge of exploit attacks or its payload to defend against it. Internet users do not need to seek refuge in ad blockers as HitmanPro.Alert allows safe use of the web without affecting ad revenue of site owners, publishers and journalists, especially when visitor/victim machines need to (or unknowingly) run outdated or vulnerable software.


Below an excerpt of the technical details of the blocked attacks which shows that many of the attacks originate from Adobe Flash Player:

Mitigation   StackPivot

Platform     6.1.7601/x86 06_2a
PID          5272
Application  C:\Program Files\Internet Explorer\iexplore.exe
Description  Internet Explorer 10

Callee Type  AllocateVirtualMemory
             0x2506C000 (32768 bytes)

Stack Trace
#  Address  Module                   Location
-- -------- ------------------------ ----------------------------------------
1  753A7A1B KernelBase.dll           VirtualAllocEx +0x33
2  753A7A47 KernelBase.dll           VirtualAlloc +0x18

3  54DF7C6F Flash32_17_0_0_169.ocx   IAEModule_IAEKernel_UnloadModule
            f7d8                     NEG          EAX
            1bc0                     SBB          EAX, EAX
            f7d8                     NEG          EAX
            c3                       RET         

Process Trace
1  C:\Program Files\Internet Explorer\iexplore.exe [5272]
   "C:\Program Files\Internet Explorer\iexplore.exe" SCODEF:3648 CREDAT:209921 /prefetch:2

2  C:\Program Files\Internet Explorer\iexplore.exe [3648]
3  C:\Windows\explorer.exe [1032]
4  C:\Windows\System32\userinit.exe [1532]

Mistress Eve
Our telemetry shows that this specific attack took place between 2015-06-11 17:00 (CET) and 2015-06-15 16:30 (CET). Strikingly, the domain seems to play a significant role in this attack.


Zooming in on this domain, we logged the following hostnames, which is an indication that the attackers have direct access to the DNS of this domain to create additional hosts:


The hostname is also mentioned on the Malware Traffic Analysis website, who recorded an attack (.pcap and .zip with malware provided). The attack was carried out by the Angler Exploit Kit (as also confirmed by Fox-IT) and delivered the Bedep trojan through a vulnerability in Adobe Flash Player.

Angler Exploit Kit
The Angler Exploit Kit itself abuses CVE-2013-7331, a vulnerability in Internet Explorer 6 through 11 to determine if the attack takes place inside a research environment, or in the presence of specific security software. If e.g. VMware or VirtualBox is detected, the exploit is not triggered in an attempt to stay under the radar of defenders:


An overview of the domains associated with this particular exploit kit deployment:

Bedep malware
This Bedep trojan horse is delivered in-memory. This means that it infects the computer without writing any files to the disk for most antivirus software to find, scan or block. Researcher Kafeine wrote about the file-less Bedep infection on his website Malware Don’t Need Coffee in August last year.

Also, this trojan typically hoists-in additional malware to perform e.g. click-fraud, hurting advertising businesses. So, advertisers are not only put in a bad light because the ad platform is abused to infect thousands of internet users, they also loose money from the fraudulent ad clicks (the advertisers unknowingly pay the attackers).

But, as pointed out by Kafeine, the Angler Exploit Kit can serve each individual victim different malware.

Protect yourselves
You can read more about our HitmanPro.Alert software on this page:

Leaflet: HitmanPro-Alert-Brochure-2015.pdf

To protect your computers against crypto-ransomware or exploits, download HitmanPro.Alert version 3 from here: (4 MB).

Malware served via Yahoo affected millions

January 5, 2014

We have been pretty busy with a lot of new exciting technology that we are introducing next month, so our blog did not get as much attention as it should. But yesterday, an interesting malvertising campaign on Yahoo drew my attention.

Yahoo is the #4 website in the world and with literally millions of daily visitors and users, Yahoo is a high-profile target for malvertising.

Fox-IT already wrote a great blog entry mainly about the network details of the attack. But since there is also a lot to tell about the malware I decided to spend my Sunday to do some digging in our databases and write some details about it.

Lennart Haagsma (@lennarthaagsma) and Maarten van Dantzig (@MaartenVDantzig) from Fox-IT’s Security Operations Center were the guys that sent out the first tweet about this on January 3rd, 2014: the host, associated with advertisements and tracking, was infecting visitors of Yahoo Mail.


Our own telemetry and research confirmed this and I immediately started to send out additional information on Twitter and share some malware details with the security community.

Below a screenshot of Fiddler showing the recorded drive-by infection, proofing that Yahoo was indeed infecting its visitors through a malicious iframe:


Sharing Information
We also shared some initial information with the Dutch National Cyber Security Center (NCSC) so they could combine it with data from Fox-IT.

The NCSC sent out a warning message to contacts at key infrastructure and important computer networks in The Netherlands, so technicians could add firewall rules to block the attack. This, because the malware used in the attack were slipping passed security defenses, which we can confirm thanks our HitmanPro agents on millions of computers in the world. Our software has detected Yahoo-related malware on computers protected by up-to-date antivirus software.

Note: Microsoft Enhanced Mitigation Experience Toolkit (EMET) offers no protection against these attack as EMET does not protect against Java-based exploit attacks.

If you are unfamiliar with our HitmanPro software: it is a small anti-malware tool that functions as a second-opinion for your antivirus software to reveal undetected threats.

HitmanPro works on-demand and is purpose-built to be compatible with other antivirus programs. Its behavior and forensic analysis are designed to pick up threats without requiring prior knowledge of malware attacks, commonly called virus signatures.

Here an example of how HitmanPro gives you insight on how the attack happened, even days after the incident:


About the Malware
Thanks to the telemetry coming from HitmanPro we are able to compile a list of threats that were used in the attack staged from Yahoo’s own servers.

Our systems detected the first threats associated with this malware campaign on Monday December 30th, 2013 (now 6 days ago). This means that a lot more users are infected than initially thought (4 days x 24 hours x 27,000 infections = 2.5 million infected computers).

The attackers made good use of Yahoo’s reputation and installed many different malware, which leads us to believe there are more interested criminals involved (a so-called Pay-Per-Install operation). An excerpt with some background information:

Click fraud malware
The creator of this file used a neat Star Wars icon:


Once executed by the exploit kit, this malware installs itself in the C:\Windows\Fonts folder. The Fonts folder is a special folder and shows only fonts in Windows Explorer. The malware executable doesn’t come up in the contents list so the user is not able to access it manually. The publisher of the malware executable was also set to Symantec Corporation DB in an attempt to fool users who were somehow able to to access it.
This malware program is causing click fraud and causes high CPU usage. It runs multiple hidden web browser processes to open web pages with ads belonging to the affiliate ID of the criminal. The program is started each hour through the Windows Task Scheduler:


Necurs backdoor
The malware author of this file decided to use an ICQ icon, abused the name of a legitimate registry tool and accidentally gave a clue to where the file could’ve originated from:


The purpose of this malware downloads additional malware and enables backdoor access and control of your computer. It also capable of disabling antivirus software and injects itself in other system processes. It typically installs itself in C:\Windows\Installer\<random GUID>\

Dorkbot backdoor
This malware can steal usernames and passwords, block websites, and launch a denial of service (DoS) attack. The malware is also often used to haul in additional malware.

The most interesting feature of this malware, I think, is that it creates a so-called hollow process to conceal its presence. In this case it spawns and abuses a legitimate Windows Calculator process (calc.exe) and does an in-memory replacement of the original contents with the malicious code. For the operating system and the user it looks like the original calc.exe is running, while in fact the calc.exe process has been transformed into Dorkbot. This Windows Calculator process now has unusual capabilities, like HTTP and DNS interception:


Ramdo malware

This particular malware employs NTFS encryption in an attempt to stay hidden from low level virus scans. A low level scan, like HitmanPro’s Direct Disk Access method, does not use the higher level Windows API’s to scan the disk for malware, because, usually, the higher level Windows API’s are manipulated by malware to evade detection.


For interested security researchers, I’ve compiled an incomplete SHA-256 list of malware associated with the Yahoo malvertising campaign:


Exploiting Java vulnerabilities
Normally, software cannot be installed on a computer without the owner’s consent. If someone would like to silently install software on your computer they would need to find and abuse a vulnerability on your computer – remember Stuxnet, which similarly abused a software vulnerability to hit Iran nuclear plant staff computers.

But practically, every computer has vulnerabilities, even yours. And for online criminals to be effective, they target multiple vulnerabilities to maximize their campaign.

The Magnitude exploit kit makes this possible, which is a favored tool since the arrest of Paunch (the creator the notorious Blackhole exploit kit).

Yahoo’s servers were used as staging area, redirecting visitors to an attack page with the Magnitude exploit kit. The exploit kit was configured to exploit vulnerabilities in Java Runtime to infect Yahoo’s users with malware.

Java is the #1 target since millions of computers still run outdated vulnerable versions of it, caused by the lack of a silent automatic update feature in Java. Also, many people and companies are unable to upgrade to the latest version of Java because they rely on custom software that will no longer work once Java is updated.

So these users rely on antivirus software to keep their computers safe. But since attackers tailor and continuously update their malware they effectively go undetected by many antivirus software.

We’ve seen at least these Java exploits used in the Yahoo malvertising campaign:

We found CVE-2012-0507 to be associated with this campaign on infected computers, confirming the fact that many computers have outdated Java software.

IP registrations
A whois query regarding the IP addresses associated with the attack domains gives us some idea on where the attackers might come from:

inetnum: -
descr: FOP Zemlyaniy Dmitro Leonidovich
country: NL
organisation: ORG-FZDL2-RIPE
org-name: FOP Zemlyaniy Dmitro Leonidovich
org-type: LIR
address: FOP Zemlyaniy Dmitro Leonidovich
address: Zemlyaniy Dmitro
address: Onore de Balzaka str. 86, app.29
address: 02232
address: Kyiv
address: UKRAINE

I saw CNET reporting that users had to click on an malicious ad to get infected, but this is not true. Below, side by side, an uninfected Yahoo advertisement and the infected one. Victims did not click on the ads to get infected and also explains the high infection numbers from the Fox-IT research.


Scan your computer
Not every ad on the Yahoo advertisement network contained the malicious iframe, but if you have an outdated version of Java Runtime (you can check here) and you used Yahoo Mail the last 6 days, your computer is likely infected.

In addition, we also received reports that the malware was spreading through ads in Yahoo Messenger as well. So if you used Yahoo’s services lately, it’s a good idea to scan your computer for malware.

Our HitmanPro software has already helped many Yahoo visitors in these countries: Australia, Germany, Spain, France, Greece, Hungary, Ireland, Israel, Italy, Croatia, The Netherlands, Poland, The United Kingdom and The United States. In most of those scans our HitmanPro anti-malware software also found other malware unrelated to the Yahoo incident, which means it is always a good idea to regularly perform a second opinion scan with a tool from a different security vendor.

You can download HitmanPro here:

HitmanPro Supports 32-bit and 64-bit versions of Windows 8.1, Windows 8, Windows 7, Windows Vista, Windows XP and Windows Server.

LNK Exploit Protection for Windows 2000, XP RTM, SP1 and SP2

August 4, 2010

As expected, Microsoft isn’t offering their MS10-046 patch for the critical Windows Shell shortcut vulnerability to users of Windows 2000, XP RTM, SP1 and SP2.

Yet our Hitman Pro usage statistics show that Windows XP SP2 is still heavily used:

Windows XP SP2 14.45%
Windows XP SP1 0,44%
Windows XP RTM 0,32%
Windows 2000 0,36%

We think that 14,45% is quite a significant number of users that are left out in the cold by the software giant.

Build 109

In Hitman Pro 3.5.6 build 109 we introduced a universal detection method for the shortcut vulnerability. We could not simply rely on checking the version number of shell32.dll as there are simply too many different versions. To complicate things, 64-bit Windows also have WoW64 versions of shell32.dll.

The universal detection method works by trying to trigger the actual exploit. This ensures that the LNK Exploit Protection is not offered to users that either installed MS10-046 or custom patched their shell32.dll. (Note: The custom patch seems to work on some specifc versions of shell32.dll only).

We recommend Windows XP pre-SP3 users to upgrade to SP3 for best protection against the exploit. But if you are stuck with Windows 2000 or you are unable to upgrade to XP SP3 then you can use Hitman Pro LNK Exploit Protection to protect your computer from malware that is currently exploiting the critical shortcut vulnerability.

How LNK Exploit Protection works

July 31, 2010

We have been contacted by a few people that asked how the Hitman Pro LNK Exploit Protection works. Well here it is.


The vulnerability is in the Window Shell component shell32.dll. This library is responsible for parsing shortcuts (.LNK files) and their icons (see IExtractIcon). Certain special shortcuts specify that their icon resides in a separate library file and the shell32.dll uses the LoadLibraryW function in kernel32.dll to load that icon library file.

Now the LoadLibraryW function reads the icon library file with execute rights and it calls the icon library’s DllMain function. Hence, it executes (possibly malicious) code while trying to fetch icon data!

Normally icon libraries do not have a DllMain or even hold code, but malware trying to exploit the vulnerability do.

So in order to provide proper protection for the exploit, we need to prevent the use of LoadLibraryW when shell32.dll is reading an icon from a library file.


The Hitman Pro LNK Exploit Protection Shell Extension intercepts the LoadLibraryW function (using an API hook) when shell32.dll tries to load the icon library file. The intercept replaces the LoadLibraryW call with a function that loads the library as a data file. Reading the library as a data file ensures that the library’s DllMain is not called, meaning no code is executed while reading the icon. This is how shell32.dll SHOULD have read the icon from a library file.

The intercept of the LoadLibraryW function (while reading the icon library file) is a very elegant solution. It works very transparent for the user and it works across the entire system.

PIDL filtering

Other vendors perform PIDL filtering (example code here) in an effort to block malicious shortcuts. While effective, it also blocks non-malicious shortcuts (like VPN shortcuts). The real vulnerability is the use of the wrong function to load the icon’s library file, not in the use of specific PIDLs.


Until Microsoft provides a patch, Hitman Pro offers the user to protect their computer from the exploit. Since we do not know yet how to recognize Microsoft’s patch we will roll-out an update when Microsoft starts pushing its patch for the vulnerability. The Hitman Pro update will then detect the patch and disable the LNK Exploit Protection Shell Extension.

Hitman Pro LNK Exploit Protection released

July 30, 2010

It has been over 2 weeks since Microsoft’s confirmed a serious vulnerability in the handling of Windows shortcuts. At least 5 different pieces of malware have already jumped on the bandwagon and began actively exploiting the vulnerability.

There is still no official patch, presumably since every Windows version (including 64-bit) is affected and it takes time to develop and test a fix for all these versions. Notice that Windows 2000, Windows XP RTM, SP1 and SP2 won’t seem to be getting an update as these products aren’t listed in Microsoft’s advisory. But these older versions are vulnerable too!

The vulnerability is in the handling of reading icons for shortcuts (.lnk files). A special shortcut can specify to load the icon from a separate library file. The Windows Shell (SHELL32.dll) loads that library file with EXECUTE rights, causing (potentially malicious) code in that library file to run. Notice that Windows does this automatically, no user interaction required!

A few AV companies have released standalone tools, but these tools either offer protection of non-local disks only or they also block some legitimate shortcuts. Though these solutions are better than Microsoft’s workaround where all shortcuts lose their icon!

Today we have  released, as part of Hitman Pro, the LNK Exploit Protection Shell Extension. This extension prevents the vulnerability in SHELL32 to load the icon library with execute rights. The result is that the icon is still loaded but no (potentially malicious) code is run. This works on the entire computer (not just on non-local disks) and it does not block the icon of legitimate shortcuts.

More information on the exploit can be read here.

The following video illustrates how to enable and disable the LNK Exploit Protection feature.

Note: The LNK Protection provides protecton of malware exploiting the vulnerability only.