Pirates of The Internetz - The Curse of The Waterhole

Pirates of the Internetz: The curse of the waterhol...
Bromium Labs
http://labs.bromium.com/2014/09/16/pirates-of-th...
September 16, 2014 / Vadim Kotov
Pirates of the Internetz: The curse of the waterhole
Last week the Bromium Labs team was contacted by a Fortune 1000 customer that detected an
interesting attack via one of their installed LAVA sensors. We get such events frequently from our
customers; however this attack was a bit different. The attack was a classic waterhole attack targeting
potential viewers of a technology startup in the Oil and Gas sector. Interestingly, this attack occurred
days after the company announced a sizable funding grant. Its likely that the attackers were expecting
more traffic to the website and hoped to increase their chances of a successful infection. The names of the
companies involved are redacted and they have confirmed that the infection has been remediated and
both have confirmed that no sensitive information was leaked.
Attacks on the ONG sector (http://www.darkreading.com/attacks-breaches/destructive-attacks-on-oiland-gas-industry-a-wake-up-call/d/d-id/1140525?) are not new and attacks targeting companies in this
sector might be premeditated. Bromium Labs is working with the target and well update the blog if
theres any significant development.
The event we received was dated 09/04/2014. The alert produced the following malware graph which
confirms the infection, at a glance (click to enlarge):
1 of 17
17-09-2014 11:33
After analyzing the captured forensic evidence, we found some interesting traits.
Anatomy of the Attack

The malware was leveraging the CVE-2013-7331 (http://web.nvd.nist.gov/view/vuln
/detail?vulnId=CVE-2013-7331), which was unpatched at that time. There have been several reports of
malware exploiting this vulnerability in the wild. If the low (https://technet.microsoft.com/library
/security/ms14-052) severity from Microsoft is not motivating to patch, then hopefully some of these
details are useful to jump over that hoop. Its obvious that various exploit kits are using this vulnerability
actively in the wild.
In this case, the script on the compromised web server looked for the presence of Kaspersky and Trend
Micro drivers on the victim machine by leveraging the XMLDOM vulnerability. It would appear that
they tested their malware with these two popular engines and found they were able to detect the
malware used.
2 of 17
17-09-2014 11:33
Lets look at the sequence of redirects. One of the .JS files on the server was modified with the following
cookie based code:
This led to another redirect (this time just plain iframe) and then to yet another one. The latter hijacks
onmouseover and onhover events of the page DOM:
Then an iframe is created pointing first at google.com but later its SRC property is overwritten with the
3 of
17
17-09-2014
malicious
URL. The popup_open function checks if the page referrer is in the blacklist. In our
case the 11:33
blacklist was empty. After that setTimeout is called. The handler of this timeout is the function overriding
the src property of the iframe.
This finally leads a victim to the drive-by-download page (which actually is a version of the Sweet
Orange exploit pack). The attacking code is fairly small just 17 KB. It doesnt use PluginDetect library,
which became a de facto standard for exploit kits. Instead it goes with isVersionSupported and trial and
error via trycatch.
Heres the list of exploit CVEs that weve confirmed from the forensics capture:
Flash CVE-2014-0497
Java CVE-2012-1723
IE CVE-2013-2551
The exploits code seems to be taken from Metasploit Framework which is also quite typical.
4 of 17
17-09-2014 11:33
Dropper and Obfuscation

The dropped Trojan (MD5 = a4f10d4ed6253bad9fff4687ed6b8c94) disguises itself as the Windows folder,
which can evade most people at first glance:
Its dropper is written in VB5 and uses a common obfuscation technique. It creates the instance of itself
and modifies the code section. The payload is self-contained and does not rely on any import functions.
Instead it resolves process names on the fly using the hash technique. First it gets the base address of
NTDLL.DLL in PEB->LoaderData->InLoadOrder, then it looks up the address of an undocumented
function LdrGetDllHandler. Using this function it gets the base address of KERNEL32.DLL.
Heres the hash function implemented in python:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
def get_hash(funcname):
if not funcname:
return 0
hashval = 0
for c in funcname:
hashval ^= (ord(c)|0x21)
hashval = rol(hashval,0x0B, 32)
hashval &= 0xFFFFFFFF
return hashval
def rol(a,b, bits=8):
return ((a<<b)|(a>>(bits-b)))&(2**bits-1)
The second stage payload is de-obfuscated into memory. Its not a PE file, but a binary blob, which has
the following structure.
1. Table of API calls containing addresses of the functions
2. Strings used in the program
5 of3.17
Executable code
17-09-2014 11:33
The executable code is also self-contained and resolves the necessary functions on the fly.
The second stage is responsible for code injection:
1. Check if it is a 32 or a 64 bit system

2. In the former case choose system32\wuauctl.exe as injection target, in the latter syswow64\svchost.exe
3. Set environment variable src = <injection target>
4. Launch the injection target and replace its image with the copy of itself
5. Modify the entry point of the target process so that it follows another routine
The injected code then de-obfuscates yet another chunk of code using the same de-obfuscation function
resulting in the same structure. You can find the list of the imported functions and strings in the end of
the article.
Anti-Analysis Tricks
The Trojan looks for several processes in the system (using CreateToolhelp32Snapshot) and wont run if
any of them is found. It doesnt contain the names of this processes, only hash values that are:
1. 0x4CE5FD07
2. 0x8181326C
3. 0x31E233AF
4. 0x91D47DF6
5. 0x0E8CDDC54
6. 0x8C6D6C
7. 0xA8D0BA0E
8. 0x0A4EF3C0E
9. 0x5CD7BA5E
We tried to figure out the names using the dictionary of malware analysis related tools and antiviruses
but were able to resolve only two of them: Wireshark and Process Monitor.
The malware tries to fingerprint if the victim is running inside Sandboxie by calling
GetModuleHandleA(sbiedll.dll).
Finally, it queries the values stored in HKLM\SYSTEM\CurrentControlSet and looks for the
virtualization software artifacts:
vmwa
vbox
qemu
These methods are not the smartest ones, but they do great job evading automated analysis tools such as
Cuckoo Sandbox (which usually runs on Virtual Box or VMWare). It also wont show malicious activity
in presence of some monitoring tools. So dynamic analysis alone is not very useful in this case.
6 of 17
17-09-2014 11:33
Final Payload
The resulting payload can be described as malware installation tool. Its a type of Trojan that persists on
the infected system and install another malware send from the command and control server. Its
workflow goes like this:
1. Get system and volume information
2. Relocate itself to %allusersprofile%\Local Settings\Temp\<random name>
3. Start the thread that runs malicious code stored in the HKLM\Software\Microsoft registry (if any
hence on the first run it wont do anything, since all the malcode is fetched from the Web)
4. Start the thread that malicious DLLs stored in the registry (if any)
5. Send system information to the C&C
6. Extract command code from the response and perform one of the following functions:
1. Write on disk and execute the received PE file
2. Execute the received PE in memory and write its encrypted contents to \Software\Microsoft
\<%08X>%checksum as REG_BINARY value
3. Load the received DLL and run the entry point; then save its name in the registry
4. Delete previously loaded files
5. Delete previously set registry values
6. Replace itself with newer version, set up autorun and execute
7. Delete all binary values in HKLM\Software\Microsoft and execute whatever is inside the Load
subkey in the same key
What interesting about this Trojan is that it stores the malicious executable code in HKLM\Software
\Microsoft registry key. This is not the first time we have heard about this trick though. The user named
EP_X0FF first reported (http://www.kernelmode.info/forum/viewtopic.php?f=16&t=3377) similar
specimen on kernelmode.info forum in the Malware section.
There are two types of data it stores in the registry:
REG_BINARY
In this case the data has the following structure:
Signature 04034B50 (thats how it knows its actually executable code)
Size of unpacked data
Size of packed data
Checksum of the unpacked data
Data
These values are only executed in memory and are not written on disk. The encryption used is a
Vigenere cipher mod 256 with the hardcoded key. Before encryption some simple compression
algorithm was used.
So17
in order to execute this kind of payload the Trojan checks the signature, decrypts and unpacks
the 11:33
7 of
17-09-2014
data and verifies the checksum. The checksum algorithm is very simple and similar to the hash function
mentioned above.
Next addresses of all the imported functions are resolved and the program calls the entry point (looked
up in the PE header).
REG_SZ
In this case the name of the value is the name of the DLL previously saved at %allusersprofile%\Local
Settings\Temp and the data is one of the exported functions. So to execute this payload the program
calls LoadLibrary, GetProcAddress and calls the exported function.
Malware installation tools like this are widely used to install bank Trojans and more recently cryptoransomware. This explains the peculiar choice of where to store the executable code. Perhaps according
to their tests most AVs do not scan the registry thoroughly enough. Clearly it is an attempt to improve
user level persistence and overall stealthiness. Its difficult to say how effective this method is, but surely
it makes a good marketing point for advertising this malware on underground message boards.
Conclusion
Water hole attacks have been around for some time and attackers are continuing to use this tried and
true attack vector while staying ahead of the defenders detection techniques. This attack is yet another
example of the ongoing game between the defenders efforts to detect attacks and the attackers efforts to
evade detection and collect the buried treasure. The authors of this attack paid a lot of attention to
stealthiness, starting from the cookie-based redirect and driver fingerprinting to monitoring tools
detection. This might narrow down the target audience of the attackers but improve the success rate.
Which makes perfect sense there are plenty of vulnerable machines out there why bother infecting
protected ones?
Appendix A. List of Imported Functions

RegCloseKey
CheckTokenMembership
RegQueryValueExW
8 ofRegOpenKeyExA
17
17-09-2014 11:33
RegEnumValueW
RegSetValueExA
RegSetValueExW
RegSetKeySecurity
RegDeleteValueW
ConvertStringSidToSidA
RegCreateKeyExA
ConvertStringSecurityDescriptorToSecurityDescriptorA
DnsRecordListFree
DnsWriteQuestionToBuffer_W
DnsQuery_A
DnsExtractRecordsFromMessage_W
GetEnvironmentVariableW
RtlGetLastWin32Error
GetProcA
9 ofGetProcessHeap
17
17-09-2014 11:33
GetShortPathNameW
GetSystemDirectoryW
GetVersionExA
GetVolumeInformationA
RtlAllocateHeap
RtlFreeHeap
RtlReAllocateHeap
RtlSizeHeap
LoadLibraryW
SetCurrentDirectoryW
SetEnvironmentVariableW
SetErrorMode
ExpandEnvironmentStringsW
VirtualAlloc
VirtualFree
WaitForSingleObject
10 of
17
17-09-2014 11:33
lstrcatA
lstrcpyA
lstrlenA
MultiByteToWideChar
CreateDirectoryW
CreateFileW
GetFileTime
GetTickCount
LocalFree
ReadFile
SetFileTime
WriteFile
lstrcatW
lstrcmpiW
lstrcpyW
lstrlenW
11 of
17
17-09-2014 11:33
LoadLibraryA
CreateProcessW
FreeLibrary
GetModuleFileNameW
GetModuleHandleW
ResumeThread
ExitThread
ExitProcess
DeleteFileW
CreateThread
CreateMutexA
CloseHandle
SetFileAttributesW
ZwDelayExecution
RtlRandom
ZwQueryInformationProcess
12 of
17
17-09-2014 11:33
wsprintfA
wsprintfW
_connect
_gethostbyname
_getsockname
_WSACreateEvent
_socket
_shutdown
_sendto
_WSAEventSelect
_closesocket
_send
_recvfrom
_recv
13 of 17
17-09-2014 11:33
_WSAStartup
_inet_a
Appendix B. List of Strings

id:%lu|bid:%lu|bv:%lu|sv:%lu|pa:%lu|la:%lu|ar:%lu,0
unicode 0,<%allusersprofile%>,0
unicode 0,<src>,0
unicode 0,<src>,0
unicode 0,<%userprofile%>,0
software\microsoft\windowsnt\currentversion\windows',0
unicode 0,<Load>,0
software\microsoft\windows\currentversion\Policies\Explorer\Run',0
unicode 0,<%lu>,0
unicode 0,<exe>,0
14 of 17
17-09-2014 11:33
unicode 0,<com>,0
unicode 0,<scr>,0
unicode 0,<pif>,0
unicode 0,<cmd>,0
unicode 0,<bat>,0
unicode 0,<com>,0
unicode 0,<exe>,0
unicode 0,<\LocalSettings>,0
unicode 0,<\Temp>,0
unicode 0,<%s\ms%s.%s>,0
unicode 0,<%08X>,0
unicode 0,<ms%08X.dat>,0
unicode 0,<%allusersprofile%\>,0
unicode 0,<%lu>,0
unicode
0,<%tmp%\>,0
15 of
17
17-09-2014 11:33
unicode 0,<%08x.exe>,0
unicode 0,<%tmp%\>,0
unicode 0,<%08x.exe>,0
id:%lu|tid:%lu|result:%lu,0
http://secondgate.pw/skyload/skygate.php,0
/%s HTTP/1.1,0Dh,0Ah ; DATA XREF: sub_3D14B5+12Eo
Host: %s,0Dh,0Ah
User-Agent: Mozilla/4.0,0Dh,0Ah
Content-Type: application/x-www-form-urlencoded,0Dh,0Ah
Content-Length: %d,0Dh,0Ah
Connection: close,0Dh,0Ah
0Dh,0Ah,0
GET /%s HTTP/1.0,0Dh,0Ah ; DATA XREF: sub_3D14B5+146o
Host: %s,0Dh,0Ah
16 of 17
17-09-2014 11:33
User-Agent: Mozilla/4.0,0Dh,0Ah
Connection: close,0Dh,0Ah
0Dh,0Ah,0
Filed under Uncategorized
Blog at WordPress.com. The Paperpunch Theme.
Follow
Follow Bromium Labs

Powered by WordPress.com
17 of 17
17-09-2014 11:33

Pirates of The Internetz - The Curse of The Waterhole

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pirates of The Internetz - The Curse of The Waterhole

Uploaded by

Copyright:

Available Formats

Pirates of the Internetz: The curse of the waterhol...

September 16, 2014 / Vadim Kotov