Hesperbot – Technical Analysis: Part 2/2
Win32/Spy.Hesperbot is a new banking trojan that has been
targeting online banking users in Turkey, the Czech Republic, Portugal
and the United Kingdom. In this 3rd Hesperbot blog post we’ll look at
the most intriguing part of the malware – the way it handles network
traffic interception. The malware spreading campaigns and their victims,
and an technical overview of the malware architecture, its mobile
component and other features are covered in three blog posts: Hesperbot – A New Advanced Banking Trojan in the Wild, Hesperbot Technical Analysis Part 1/2 and Hesperbot Technical Analysis Part 2/2. You can download the comprehensive whitepaper here.
Network Interception and Web-injects
Other well-known banking trojans such as Zeus and SpyEye
are able to intercept and modify HTTP and HTTPS traffic by hooking
WinSock functions (send, WSASend, etc.) and the higher-level WinInet
functions (HttpSendRequest, InternetReadFile, etc.). As the web-injects,
form-grabbing and other shenanigans performed by these banking trojans
take place inside the affected browser, the method has collectively been
labeled as the ‘Man-in-the-Browser’ attack. Win32/Spy.Hesperbot,
however, takes a different approach, which is not very common, but has,
in fact, already been used by the
Gataka banking trojan. A good technical analysis of Win32/Gataka by my colleague Jean-Ian Boutin can be found
here.
The network traffic interception and HTML injection functionality in Win32/Spy.Hesperbot is accomplished by the plug-in modules nethk, httphk and httpi working together.
Figure 1 – Relations between network interception modules
Here’s a brief description of each module’s purpose:
- nethk – used to set up a local proxy, hook socket
functions to drive connections through the proxy and hook browser SSL
certificate verification functions. Also handles decryption and
encryption of HTTPS traffic flowing through the proxy.
- httphk – used for parsing HTTP traffic intercepted by the proxy
- httpi – used for screenshots, video capturing, form-grabbing and web-injects according to the configuration file
Now let’s take a closer look at how the modules work together and
accomplish their tasks. As mentioned above, the modules expose their
functions in a vtable for other modules to use. The program flow in
between the modules as each HTTP request or response is intercepted is
ensured through callback functions.
nethk
Nethk is the first plug-in module to be loaded by the core module.
Win32/Spy.Hesperbot performs a man-in-the-middle attack by creating a
local proxy through which it directs all connections from the browser.
Figure 2 – Local proxy IP address in Hesperbot code
Figure 3 – Internet Explorer connected through Hesperbot proxy
To achieve this, the trojan’s nethk module
creates a proxy on a random port at the address 127.0.1.1 and hooks the
following functions in mswsock.dll, the lower-level Winsock SPI library:
- WSPSocket
- WSPIoctl
- WSPConnect
- WSPCloseSocket
The pointers to these functions are modified in the
WSPPROC_TABLE. To understand how the proxy redirection works, let’s look at the hooked
WSPConnect function.
Figure 4 – Hooked WSPConnect API
The browser socket – when trying to connect to a secured online
banking website, for example – is connected to the proxy created by
Hesperbot instead. In another thread, the legitimate connection to the
website is established.
Figure 5 – Overview of HTTPS traffic interception via Hesperbot’s proxy
An httphk-callback is invoked each time the proxy intercepts a
request from the browser, before passing it on to the real server.
Likewise, an httphk-callback is invoked each time the proxy intercepts a
response from the real server, before passing it on to the browser. The
httphk module then works further with the traffic.
There’s also a difference between the handling of HTTP versus HTTPS
traffic. In the case of HTTP, the request- or response-data is simply
passed to httphk. In the case of HTTPS, nethk first “gets rid of the
encryption”. When an HTTPS request from the browser is intercepted
(encrypted using its own fake SSL certificate – explained below), it is
decrypted, and the decrypted data is passed to httphk through the
callback and then encrypted using the real certificate of the server
(e.g. bank website), and then sent to the real destination.
Reciprocally, when an HTTPS response is received from the server, it’s
decrypted using the real certificate, the decrypted data is again passed
to httphk and then encrypted using Hesperbot’s fake certificate before
being passed to the browser.
In effect, through the man-in-the-middle proxy, Win32/Spy.Hesperbot
can access the victim’s outgoing HTTPS communication before it’s
encrypted and their incoming HTTPS communication after it’s decrypted.
The same effect is essentially accomplished by Zeus’s and SpyEye’s MitB
hooks, but this new approach is slightly stealthier.
Now, of course, this malicious proxy redirection should be given away
by an invalid certificate for an HTTPS website. The Hesperbot authors
thought of this as well. The nethk module carries its own crafted,
self-signed SSL certificates and these are substituted for legitimate
certificates.
Figure 6 – SSL certificates inside nethk binary
Figure
7 – Example of Hesperbot’s fake certificates in use. On a clean system,
Google’s certificate would displayed here, of course.
In order to trick the browser into believing that the certificate is
valid and avoid the display of a warning message, the malicious module
also hooks functions responsible for certificate verification. The
implementation differs depending on the browser. The following table
shows which browsers are supported by Win32/Spy.Hesperbot and which
functions are hooked:
Figure 8 – Certificate verification functions hooked by Hesperbot for various browsers
An interesting feature of the malicious code is that the authors have
used hashes instead of using the browser process names directly, so as
to complicate analysis and, more importantly, to protect the malware
from signature based AV detection.
Figure 9 – Code obfuscation in Win32/Spy.Hesperbot – hashes are used instead of process names
The figure below shows the code of the hooked
CertVerifyCertificateChainPolicy.
Figure 10 – Hooked CertVerifyCertificateChainPolicy API
In the case of an SSL client/server chain policy verification check
(other types are neglected and passed on to the original function) the
hooked function simply returns a result indicating that the policy check
was passed.
httphk
The httphk module is merely responsible for parsing the HTTP protocol
data. When the httphk-callback is invoked, it parses HTTP headers and
data and fills in an internal structure. This structure will
subsequently be accessed by the httpi module.
Again, httphk exposes two callback functions for invoking httpi: httpi_request_callback and httpi_response_callback.
httpi
This is the main module that actually carries out the modification of the HTTP data, according to the configuration file.
When httpi_request_callback is invoked, the following actions are performed:
- Video capture and screenshots – The module reads
the configuration file and checks the request URL. If specified in the
config, video capture and/or creating screenshots is started.
- Form grabbing – The module checks whether it’s a
POST request via the HTTPS scheme and if content-type is either
“application/x-www-form-urlencoded” or “text/plain”. If these conditions
are true, it’s likely that the user has submitted a login form. If the
configuration file specifies that the current URL should be monitored,
the data is written to a log.
When httpi_response_callback is invoked, the following happens:
- HTML injects – First, the trojan checks whether
the HTTP response code is 200. Afterwards, the configuration file is
read and if there are web-inject entries for the responding web-page,
they are inserted into the HTML content.
The figure below shows a decrypted configuration file used in the
Portuguese botnet. You may notice the first group of domains – these are
ignored by httpi – domains which are of little interest to the bot
masters. While stolen Google or Facebook login credentials would be
considered valuable to other spying malware, this shows that the
perpetrators behind Hesperbot are only interested in
online-banking-related data. The targeted bank websites are listed after
those that are ignored. The rest of the configuration file contains the
HTML code that’s supposed to be injected into the online banking
websites.
Figure 11 – Decrypted web-inject configuration file used in the Portuguese botnet
It appears that the people who wrote the web-injection scripts speak
Russian, as evidenced by source-code comments. Note, however, that the
scripts may or may not have been written by the same perpetrators who
created the Win32/Spy.Hesperbot malware and/or operate the botnets.
Web-inject scripts are often shared and reused – this is made possible
when a similar format is being used by different malware families – and
specialization among cybercriminals is commonplace.
Authors:
Anton Cherepanov
Robert Lipovsky
List of MD5s
3d71bc74007a2c63dccd244ed8a16e26
ce7bcbfad4921ecd54de6336d9d5bf12
f8ef34342533da220f8e1791ced75cda
1abae69a166396d1553d312bb72daf65
83b74a6d103b8197efaae5965d099c1e
91c5a64e6b589ffcfe198c9c99c7d1f0
ae40a00aad152f9113bc6d6ff6f1c363
27d8098fe56410f1ac36008dbf4b323e
8a9cb1bb37354dfda3a89263457ece61
ff858b3c0ea14b3a168b4e4d585c4571
1243812d00f00cef8a379cb7bc6d67e7
1e1b70e5c9195b3363d8fb916fc3eb76
4cf7d77295d64488449d61e2e85ddc72
5410864a970403dae037254ea6c57464
64a59d4c821babb6e4c09334f89e7c2d
1f7b87d5a133b320a783b95049d83332
028a70de48cd33897affc8f91accb1cd
4cc533ef8105cbec6654a3a2bc38cb55
59427cfb5aa31b48150937e70403f0db
c8ee74ada32ea9040d826206a482149e
d3c7d6d10cd6f3809c4ca837ba9ae2e8
Article by :Author
Robert Lipovsky, We Live Security