# The “Silent Night” Zloader/Zbot
_by_ _[@hasherezade (Malwarebytes) and @prsecurity_](https://twitter.com/hasherezade)_ _(HYAS)_
_May 2020 - Version 1.1_
-----
## Foreword
ZeuS is probably the most famous banking Trojan ever released. Since its source code
[leaked, various new variants are making the rounds. In the past we wrote about one of its](https://blog.malwarebytes.com/cybercrime/2017/01/zbot-with-legitimate-applications-on-board/)
forks, called Terdot Zbot/Zloader.
Recently, we have been observing another bot, with the design reminding of ZeuS, that
seems to be fairly new (a 1.0 version was compiled at the end of November 2019), and is
actively developed. Since the specific name of this malware was for a long time unknown
among researchers, it happened to be referenced by a generic term Zloader/Zbot (a
common name used to refer to any malware related to the ZeuS family).
Our investigation led us to find that this is a new family built upon the ZeuS heritage, being
sold under the name “Silent Night”. In our report, we will call it “Silent Night” Zbot.
The initial sample is a downloader, fetching the core malicious module and injecting it into
various running processes. We can also see several legitimate components involved, just
like in Terdot’s case.
In this paper, we will take a deep dive into the functionality of this malware and its
Command-and-Control (C2) panel. We are going to provide a way to cluster the samples
based on the values in the bot’s config files. We will also compare it with some other Zbots
that have been popular in recent years, including Terdot.
-----
## Table of content
- Appearance and description
- Distribution
- Elements
- User manual
- Behavioral Analysis
- C2 Communication
- Traffic analysis
- Inside
– Obfuscation
– Used static libraries
– Execution flow
- The loader
- The core bot
– Plain loader vs antiemule loader
– Storage
– Manually loading PEs
– VNC Server
– Commands: implementation
– Hooks
– Man-In-The-Browser local proxy
– Stealer functionality
- Comparison
- Panel
- Builder
- Client clusters and IOCs
-----
## Appearance and description
[The banking Trojan called “Silent Night” (perhaps in reference to the xXx 2002 movie,](https://www.imdb.com/title/tt0295701/)
where Silent Night was the name of Soviet-made binary chemical weapon) was announced
on November 9th 2019 on forum.exploit[.]in, one of the Russian underground forums. The
seller’s username is “Axe”.
The announcement date is very close to the compilation date of version 1.0 that we were
able to capture.
-----
_Compilation timestamp of bot32.exe (743a7228b0519903cf45a1171f051ccfaaa4d12c),_
_version 1.0_
The author described it as a banking Trojan designed with compatibility with ZeuS
webinjects. Yet, he claims that the code is designed all by him, based on his multiple years
of experience - quote: “In general, it took me 5+ years to develop and support the bot, on
average about 15k ~ hours were spent.”.
The price tag is steep, especially for the Russian audience where 500 USD is an average
rent for a small 1 bedroom apartment in the outskirts of Moscow:
- 4,000 USD/month for unique build
- 2,000 USD/month for general build
- 1,000 USD/month extra for HVNC functionality
- 500 USD/14 days to test
In a reflection post by Axe, he talks about his experience developing a banking bot a few
years prior. Rough translation of the text in the image:
_“A few years prior: My previous banking Trojan had a lot of issues and was hard to maintain_
_because of the poor architecture and C-code. The best course of action was to rewrite the_
_whole thing, and I have done just that. The development took a few years, and I went through_
_a couple of iterations. Finally, with the experience learned from the first version and all the_
_customers’ feedback, I was successful at making the ideal banking trojan.”_
In fact, we can confidently attribute his previous work to be Axebot. Same user Axe has
[another thread on the same forum around 2015-2016 where he advertised another](https://forum.exploit.in/topic/91661/)
banking bot.
-----
[Comparing Axe Bot 1.4.1 and Zloader 1.8.0 C2 source codes, we note that all of their custom](https://github.com/RomaniukVadim/hack_scripts/tree/cc801b36ea25f3b5a82d2900f53f5036e7abd8ad/Dark%20soft/AXE%20Bot/axe_1_4_1_stable)
PHP functions have the prefix CSR, which can either be a naming space or a developer’s
handle.
-----
_AxeBot global.php:_
_Zloader global.php (deobfuscated):_
The description and functionality described in the thread also closely match the capabilities
of the Zloader sample. Among the advertised features we find:
-----
```
Web Injections and Form Grabber
Support for browsers "Google Chrome", Firefox, "Internet Explorer".
HiddenVNC
Works on all OSs with the latest browser versions except Edge.
SOCKS5
The session starts in one click on the bot page in the admin panel.
The server-side utility for the backconnect works only under Windows.
Keylogger
Monitors keystrokes in browsers.
Search by keylogger reports is possible by process name, window title and
content.
Screenshots
It takes screenshots in the area of clicking the mouse button with a size of
400x400, it fires when you enter the url you need.
Screenshots can be searched by process name and window title.
Cookie Grabber
Support for browsers "Google Chrome", Firefox, "Internet Explorer".
Cookies are available for download in NETSCAPE, JSON and PLAIN formats.
Passwords Grabber
From Google Chrome.
```
Axe also claims to use an original obfuscator, described in the following way:
```
Protective gear
An obfuscator was written for the bot, which morphs all code and encrypts
strings + all constant values in the code.
This is not only a banal replacement of arithmetic operations with analogs,
but also decomposition of all instructions, including comparison operations
by functions to processors that perform the operation we need, and we get a
very confusing code at the output.
Decryption of lines occurs on the fly on demand, which will be stored
temporarily on the stack.
Decryption of constant values also occurs on the fly, for each of which has
its own unique function of decryption.
All WinApi calls are made through a handler that searches for the hash API we
need.
Creates fake WinApi calls during code obfuscation, so the bot stores a random
import table.
Critical code (cryptographic algorithms) works in a stacked virtual machine,
VM code also morphs, virtualization is necessary to complicate the analysis.
Thus, with each assembly we get a unique file and any signature will be
knocked down in one click.
Performance was not critically affected.
```
-----
## Distribution
[On Dec 23 2019, this Zloader was observed being dropped by the RIG Exploit Kit (source).](https://www.malware-traffic-analysis.net/2019/12/23/index3.html)
At the beginning, since it was soon after the first release of this malware, the campaigns
were small, and appear to be for testing purposes. The spreading intensified over time, and
the distribution switched to mostly phishing emails.
[In March 2020, it was delivered in a COVID-19 themed spam campaign, as reported by](https://twitter.com/VK_Intel/status/1241187512409903104)
[Vitali Kremez.](https://twitter.com/VK_Intel/status/1241187512409903104)
At that time, the attachments used for dropping the malware were mostly Word documents
with malicious Javascript. The document is a lure trying to convince the user to enable the
active content.
_[dcaded58334a2efe8d8ac3786e1dba6a55d7bdf11d797e20839397d51cdff7e1 - source](https://www.virustotal.com/gui/file/dcaded58334a2efe8d8ac3786e1dba6a55d7bdf11d797e20839397d51cdff7e1/detection)_
Later, the spam with the Invoice template started to be used.
[On Apr 21, 2020 a big campaign was reported by ExecuteMalware](https://twitter.com/executemalware/status/1252384340404649989?s=21)
The used attachments were mostly Excel Sheets with macros embedded on a VeryHidden
XLS sheet. After enforcing the hidden sheet to be displayed, we can see the commands in
the cells:
-----
They were downloading the malicious loader from the embedded URLs.
_Details on deobfuscating this type of loader has been presented in the video by_
_[DissectMalware.](https://www.youtube.com/watch?v=QBoj6GB79wM)_
Another variant of the attachment was a VBS script, where the Zloader was embedded
directly, in obfuscated form:
_[80bb2ee42974630e746bc1cf36e7589a5283ee4532836b66be2c734acbe308df](https://www.virustotal.com/gui/file/80bb2ee42974630e746bc1cf36e7589a5283ee4532836b66be2c734acbe308df/detection)_
Since the distribution may vary, and the campaigns are probably run by third parties (the
clients who rented the malware) we will not go into their details in this paper.
-----
## Elements
The distributed package contains the following elements - malicious as well as harmless,
that are used as helpers:
**Name** **Functionality**
loader-bot32.dll/.exe Loader/installer of the core element
antiemule-loader-bot32.dll/.exe Loader/installer of the core element, with antiemulator evasion techniques
bot32.dll the core element (main bot) - version for 32 bit
system
bot64.dll the core element (main bot) - version for 64 bit
system
hvnc32.dll Hidden VNC (32 bit)
hvnc64.dll Hidden VNC (64 bit)
_zlib1.dll_ harmless: Zlib compression library
_libssl.dll_ harmless: an SSL library for secure communication
_sqlite3.dll_ harmless: an SQLite library for reading SQL
databases
_nss32.dat_ A package containing following harmless PEs:
certutil.exe, libplds4.dll, msvcr100.dll, nss3.dll,
sqlite3.dll, nssdbm3.dll, libnspr4.dll, smime3.dll,
nssutil3.dll, nspr4.dll, softokn3.dll, freebl3.dll,
libplc4.dll
Server-side elements:
**Name** **Functionality**
bcs.exe a server-side Back-Connect utility (deployed on
the machine of botnet operator)
The same binaries are served to all the clients in standard releases, and the only
customization is available via hardcoding a custom configuration. In addition to this, the
author offers custom builds for specific clients.
|Name|Functionality|
|---|---|
|loader-bot32.dll/.exe|Loader/installer of the core element|
|antiemule-loader-bot32.dll/.exe|Loader/installer of the core element, with anti- emulator evasion techniques|
|bot32.dll|the core element (main bot) - version for 32 bit system|
|bot64.dll|the core element (main bot) - version for 64 bit system|
|hvnc32.dll|Hidden VNC (32 bit)|
|hvnc64.dll|Hidden VNC (64 bit)|
|zlib1.dll|harmless: Zlib compression library|
|libssl.dll|harmless: an SSL library for secure communication|
|sqlite3.dll|harmless: an SQLite library for reading SQL databases|
|nss32.dat|A package containing following harmless PEs: certutil.exe, libplds4.dll, msvcr100.dll, nss3.dll, sqlite3.dll, nssdbm3.dll, libnspr4.dll, smime3.dll, nssutil3.dll, nspr4.dll, softokn3.dll, freebl3.dll, libplc4.dll|
|Name|Functionality|
|---|---|
|bcs.exe|a server-side Back-Connect utility (deployed on the machine of botnet operator)|
-----
### Samples
The current analysis focuses on the following samples, captured in live campaigns:
**loader-bot.exe :**
- [becacb52a50004d42538cfe82c8f527f1793727c5f679f46df7f96eade272962 – loader](https://www.virustotal.com/gui/file/becacb52a50004d42538cfe82c8f527f1793727c5f679f46df7f96eade272962/detection)
#1 (dropped by RIG EK)
- [0c1b74345e0300233db0396f78ca121e7589deda31b7bc455baa476274e3f2e5 –](https://www.virustotal.com/gui/file/0c1b74345e0300233db0396f78ca121e7589deda31b7bc455baa476274e3f2e5/detection)
loader #2 (downloaded from: 45.72.3.132/web7643/test2.exe)
- [3648fe001994cb9c0a6b510213c268a6bd4761a3a99f3abb2738bf84f06d11cf - loader](https://www.virustotal.com/gui/file/3648fe001994cb9c0a6b510213c268a6bd4761a3a99f3abb2738bf84f06d11cf/details)
#3 (packed, from malspam)
– [3648fe001994cb9c0a6b510213c268a6bd4761a3a99f3abb2738bf84f06d11cf -](https://www.virustotal.com/gui/file/3eb18cd9033735bc04aa02671e9bd94c4e4d6664107799ba593c5b646dd966ef/detection)
loader #3 (unpacked)
**bot32.dll :**
- [6460f606f563d1fe3c74b215e1252dc7466322e4d2b55b898b9da1bd63454762 -](https://www.virustotal.com/gui/file/6460f606f563d1fe3c74b215e1252dc7466322e4d2b55b898b9da1bd63454762/detection)
sample #1
- [df60102fff5974a55fb6d5f4683f2565b347a0412492514e07be9b03c7c856b7 –](https://www.virustotal.com/gui/file/df60102fff5974a55fb6d5f4683f2565b347a0412492514e07be9b03c7c856b7/detection)
sample #2
-----
## User manual
Following the address of the C2 (Command and Control server) we found an open
directory.
One of the files contained a manual for the bot operator:
-----
Thanks to this manual, we could start the analysis by understanding thoroughly what the
features intended by the author were. The functionality is typical for a banking Trojan,
without much novelty. In a subsequent part of this post, we will present how each feature is
implemented in the bot.
[Not surprisingly, there is an overlap between this manual, and the classic Zeus Bot manual,](https://github.com/Visgean/Zeus/blob/translation/manual_en.html)
available with the leaked source.
The main panel of the C2 is written in PHP.
-----
### Backconnect
One of the described features is backconnect. This feature means that the malware opens a
reverse connection, allowing the operator to interact with the infected machine in spite of
the Network Address Translation (NAT) being in use.
The server-side utility for the backconnect is implemented as an additional executable:
[bcs.exe (hash 9a77409eac7310b0492915aba04f23dafa9f4990dab588df0ab8ffe0871daae8).](https://www.virustotal.com/gui/file/9a77409eac7310b0492915aba04f23dafa9f4990dab588df0ab8ffe0871daae8/detection)
The bot operator must run it with Administrative privileges on their own machine, and
then fill the IP address in the Config section of the C2 panel.
### Commands
According to the author, the bot accepts the following commands:
- `user_execute [URL] [parameters] - download an executable into the %TEMP% folder`
and run it (optionally with parameters)
- `user_cookies_get - steal cookies from all known browsers.`
- `user_cookies_remove - removing all cookies from all known browsers.`
- `user_url_block [url_1] [url_2] … [url_X] - block URL access for the current user.`
- `user_url_unblock [url_1] [url_2] … [url_X]`
- `bot_uninstall - complete removal of the bot from the current user.`
### Webinjects and Webgrabbers
The bot allows for stealing contents of the opened pages (webgrabber), as well as for
modifying it (webinject). The format of webinjects is typical for ZeuS. Example:
```
set_url * G
data_before
data_end
data_after
data_end
data_inject
INJECT
data_end
```
Format of setting condition that executes webinject/webgrabber on a selected page:
```
set_url [url] [options] [postdata_blacklist] [postdata_whitelist]
[matched_context]
```
Options are defined by following characters:
-----
```
P - run on POST request.
G - run on GET request.
L - if this symbol is specified, then the launch occurs as an HTTP grabber,
if not specified, then as an HTTP injection.
H - complements the "L" character, saves content without HTML tag clipping.
In normal mode, all HTML tags are deleted, and some are converted to the
newline or space character.
I - compare the case-sensitive url parameter (for the English alphabet only).
C - compare case insensitive (for the English alphabet only).
B - block execution of the injection.
## Behavioral analysis
```
[Sandbox analysis of the component dropped by RIG EK is available here.](https://app.any.run/tasks/9d63a526-bab1-4794-a957-0c6775471625/)
As we can see in the diagram, the malicious executable first makes an injection into
```
msiexec.exe - which is a very common target of malware based on (or inspired by) ZeuS.
```
Further injections are made to other running processes. It also installs a custom certificate
with the help of certutil.exe.
[The initial component of this malware (i.e. d93ca01a4515732a6a54df0a391c93e3) is a](https://www.virustotal.com/gui/file/becacb52a50004d42538cfe82c8f527f1793727c5f679f46df7f96eade272962/details)
downloader/installer. So, in order to reveal its malicious intent, we need to run it on a
machine connected to the internet, and make sure that we have access to the live C2 server.
Then, the malicious implant running inside msiexec attempts to connect to the C2 server,
and download the important elements from there. The communication with the C2 goes
over HTTPS, but is also additionally encrypted.
-----
-----
The sample content of request-response:
_The analysis of the decrypted traffic is presented in the traffic section._
The bot creates multiple directories with random names inside the %APPDATA% directory.
-----
In some of them we can find files with encrypted content:
In addition to it, it creates registry keys with pseudo-random names, under
```
HKEY_CURRENT_USER\Software\Microsoft. Example:
```
-----
### Persistence
The malware achieves persistence with the help of an Autorun registry key, which is a very
popular, and easy to detect method.
The key points to the loader component that was dropped into a custom folder created in
%APPDATA%:
This way of storing components (creating multiple random-named directories in
APPDATA, and storing the encrypted components there) is typical for malware with ZeuS
heritage.
_During the execution the malware was updated, dropping an alternative loader:_
_[8e73a8a4a35ebfcc3e900ec4255cb296](https://www.virustotal.com/gui/file/eafbd21a0f9f082fa2e94e010569d7fa8512d978087c2633d652b865b922465a/detection)_
Once the initial executable is run, it performs injection into msiexec and then terminates.
-----
_The view from Process Explorer shows how the initial executable (yddieb.exe) runs msiexec_
_and terminates._
The component implanted into msiexec continues running, and performs further injections.
At the beginning of its execution it reads the registry key with the saved configuration.
Then, it reads components that are saved in the folders inside %APPDATA%.
It loads the next stage modules from the previously dropped encrypted files, and then
injects them into msiexec, and into other processes.
### Implants
[We can extract the implanted modules by scanning the system with Hollows Hunter.](https://github.com/hasherezade/hollows_hunter/)
Depending on the process, the injected components may vary. Four different schemes of
injections have been observed, depending on the target process.
1) `msiexec`
Inside the msiexec the core component of the malware runs. We can find several DLLs
implanted there.
-----
_The implants and reports dumped by Hollows Hunter._
The implant at 70000.exe is the loader. Depending on the variant, it can be delivered as an
EXE or DLL. If the loader was implemented as a DLL, the initial redirection (from msiexec
to the loader implant) may be a bit different than in case of the EXE.
For example, in one of the observed cases, the Entry Point of msiexec was patched. The
patch then redirected the execution to the implanted DLL
[(893d85faac45de4ef4bc43e81907e74a ):](https://www.virustotal.com/gui/file/23fba90136c705201e757bec9225f55a37db35f92aed49bfc000cb5fa64120a0/detection)
-----
The EAX is filled by the address of the loader’s Entry Point, and the call redirects the
execution the implant:
The next module: 550000.dll in the dump - is the main module of the bot (bot32/64.dll).
We can also see several other DLLs. By looking at their export tables we can identify them
as: hvnc32.dll, sqlite3.dll, libssl.dll, zlib1.dll.
The libssl.dll is loaded by hollowing mshtml.dll.
2) Other processes (except msiexec)
All accessible processes have implants installed for the purpose of interception of selected
API calls.
We can find there a similar scheme of implants:
_The implants and reports dumped by Hollows Hunter._
There is one malicious DLL (identified as the core component of the bot: bot32/64.dll).
Additionally, two DLLs are hooked: NTDLL, and User32. Their execution is redirected to the
implanted DLL.
[Sample report is given below (where 7430000 is the bot32/64.dll):](https://github.com/hasherezade/pe-sieve/wiki/3.1.-Investigating-hooks-and-patches)
-----
- ntdll.dll
```
45778;NtCreateUserProcess->745decf[7430000+2decf:(unnamed):1];5
```
- user32.dll
```
164c7;TranslateMessage->745e6d9[7430000+2e6d9:(unnamed):1];5
```
The beginning of the function NtCreateUserProcess is patched, and starts by the
redirection into the implanted DLL:
The jump at the beginning of NtCreateUserProcess leads to the following function inside
the implant:
The hook at the beginning of the function TranslateMessage in User32.dll also starts by
the redirection to the implant:
3) Browsers: iexplore (Internet Explorer), firefox, chrome.exe (Chrome)
Browsers processes have implants installed for the purpose of interception of selected API
calls. Just like most of the processes, they have the main bot injected (bot32/64.dll), yet
their hooking scheme is extended. The additional hooks are installed in ntdll.dll.
Sample report is given below (where the 180000 is the bot32.dll):
- ntdll.dll
```
45778;NtCreateUserProcess->1adecf[180000+2decf:(unnamed):1];5
45858;NtDeviceIoControlFile->1ae0cb[180000+2e0cb:(unnamed):1];5
```
-----
- user32.dll
```
164c7;TranslateMessage->1ae6d9[180000+2e6d9:(unnamed):1];5
```
4) `iexplore (Internet Explorer), chrome.exe (Chrome)`
In Internet Explorer and Chrome, the implants are almost the same as mentioned in the
previous paragraph (“browsers”). Yet there are additional hooks in crypt32.dll, that
were not observed i.e. in Firefox.
Sample report (where 180000 is the bot32.dll implant):
- crypt32.dll
```
16ccf;CertGetCertificateChain->1ae635[180000+2e635:(unnamed):1];5
1cae2;CertVerifyCertificateChainPolicy->1ae6a6[180000+2e6a6:(unnamed):1];5
```
- ntdll.dll
```
45778;NtCreateUserProcess->1adecf[180000+2decf:(unnamed):1];5
45858;NtDeviceIoControlFile->1ae0cb[180000+2e0cb:(unnamed):1];5
```
- user32.dll
```
164c7;TranslateMessage->1ae6d9[180000+2e6d9:(unnamed):1];5
```
_The detailed analysis of the hooks, and how they are installed, is presented in the hooks_
_section._
### Modules
[Let’s have a closer look at all the modules dumped by the HollowsHunter.](https://github.com/hasherezade/hollows_hunter)
[First, the core DLL (bot32/64.dll) (ab756f154d266c8ba19bdfa8bcaf1b73) will be](https://www.virustotal.com/gui/file/df60102fff5974a55fb6d5f4683f2565b347a0412492514e07be9b03c7c856b7/detection)
downloaded. It is implanted into the initial msiexec but also into all the accessible
processes. This model of injection is atypical in comparison to most malware seen
nowadays, and very invasive: usually, malware selects only one or two processes where it
injects.
In addition to the injected core, in the main malware process, running under the cover of
```
msiexec we will find more modules, including legitimate DLLs: sqlite3.dll, libssl.dll,
```
zlib1.dll.
-----
_sqlite3.dll – fragment of the Export Table_
-----
_libssl.dll – fragment of the Export Table_
-----
_zlib1.dll – fragment of the Export Table_
The sqlite3.dll is used for the purpose of reading and stealing cookies from the browsers’
databases. The libssl.dll – for establishing the encrypted connections, but also generation of
the custom certificate, that will be used for the purpose of Man-In-The-Browser attacks.
The zlib1.dll is for compression and decompression of data sent and received over HTTP
(gzip).
One more malicious DLL is a VNC module
[(f3d2e4606a8964b8910dd8172b5c98e02f27e00b6082d7af220e2edfdbf7eb40) – that](https://www.virustotal.com/gui/file/f3d2e4606a8964b8910dd8172b5c98e02f27e00b6082d7af220e2edfdbf7eb40/detection)
allows to open a hidden VNC connections to the victim machine.
-----
**Modules for 64 bit system**
On a 64-bit system, Zloader uses one more DLL for the purpose of injections
(64_gate32.dll). It is a 32-bit PE that can access a 64-bit environment with the help of the
[Heaven’s Gate technique. Its usage and technical details will be explained in the further](https://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/)
part of this post.
- [e0a3355b40e6660e35037da9680fcaabef458ee8a6ef7c7cc742324124c8e39](https://www.virustotal.com/gui/file/e0a3355b40e6660e35037da9680fcaabef458ee8a6ef7c7cc742324124c8e396/detection)
-----
There is also a 64-bit version of the main module that will be injected into 64-bit processes:
[3aa6edf03880493e9e16cc5ee1cf79996901c814cbe6e43b001327b6897eea59](https://www.virustotal.com/gui/file/3aa6edf03880493e9e16cc5ee1cf79996901c814cbe6e43b001327b6897eea59/details)
Similarly, a 64-bit version of the VNC is being used.
Looking at the modules, we can find many analogies to banking trojans based on ZeuS.
### Pairing with a browser
The main module inside msiexec runs a local server, to which the other implanted modules
are connecting, and sending the stolen data.
The image below represents the view from Process Explorer, listing the connections opened
by msiexec as well as the ones open by Firefox. One of the connections established by
Firefox links it with the local server, running inside msiexec. We can see a pair of
connections where the msiexec uses local port 18301 and remote 49937 (which is the port
open by Firefox), while Firefox uses local port 49937 and remote 18301 (which is the port
open by msiexec).
-----
### Fake certificates
The malware installs a fake certificate for the Man-In-The-Browser attack. This is how the
connection with the fake certificate looks like in various browsers:
_Fake certificate in Firefox_
Firefox doesn’t show anything alarming at first glance, but when we click on the details of
the connection we will find the message “Mozilla does not recognize this certificate issuer. It
_may have been added from your operating system or by an administrator”. More advanced_
users may get suspicious at this point.
-----
_Fake certificate in Internet Explorer_
In the case of Internet Explorer nothing like this occurs, and only a closer analysis of the
Issuer and Certification Path may raise concerns that the certificate is not legitimate.
-----
-----
_Fake certificate in Chrome_
In the case of Chrome, the situation looks very similar like in the Internet Explorer. We
need to see the certificate’s details, read the Issuer and the Certification Path to find out the
fraud. For the less advanced users, it may be too difficult to notice the alarming indicators.
The differences between how Firefox displays the certificate versus Internet Explorer and
Chrome, are caused by a different way in which the malicious certificate is installed. In the
case of Internet Explorer and Chrome, the malware author patched the functions in
```
crypt32.dll responsible for validation of the certificate in order to bypass the security
```
measures. In the case of Firefox, it just installed the malicious certificate with the help of
the certutil tool.
We will see the implementation of those techniques in the further part of this post.
-----
### Webinjects
When we visit one of the targeted sites, we can also observe a malicious script being
injected into the original website content. In the example below, the login page of
Scotiabank was implanted with a skimmer. The malicious javascript is inlined in the header
of the website.
_The highlighted line shows the malicious script injected in the header._
The difference can be noticed when we compare it with the original source:
The content of the elements that are going to be injected is defined by templates that are
downloaded from the C2.
## Inside
This analysis details on 32-bit modules of the bot. Most of the 64-bit modules are
analogical. Yet, the 64-bit modules are going to be referenced whenever they introduce any
functionality that is not present in the 32-bit version.
The initial sample (loader) that is distributed in campaigns, is usually packed with the help
of some underground crypter. The used crypters change periodically, and most likely
-----
created by a third-party. That’s why this analysis will not include analysis of the packing in
this report. Automated unpacking of the used samples was done with the help of PE-sieve.
### Obfuscation
In order to make analysis more difficult, all of the malicious modules of this Zbot are
obfuscated. The characteristics of the obfuscation indicates that it has been applied on the
source-code, pre-compilation. It contrasts with most malware, where the only protection is
the layer added post-compilation, with the help of a crypter/protector.
Each release of the bot contains randomized obfuscation. Although the resulting code is
different, yet the patterns are similar every time. This indicates that the same code
obfuscator was used for each release, and the generated obfuscation artifacts are being
randomized on each use.
According to the advertisement on the underground forum, the obfuscator is custom,
developed by the author of the bot themselves.
**Constants**
Many of the constants used in the code are obfuscated. Instead of being hard-coded, they
are calculated just before use, by a unique, obfuscated function.
For example, instead of giving a parameter as a value of 2, the dedicated function is being
called to calculate it:
Inside the function calculating the value of 2 we can find calls for various other functions,
and use of globals that may need to be pre-initialized.
This makes emulation of those functions challenging.
-----
**Arithmetic operations**
Various arithmetic operations used by malware, as well as comparisons, are also
obfuscated. Instead of being implemented in a standard way, they are managed by multiple
dedicated functions, each of them is obfuscated.
Example:
Instead of using a comparison operator == the malware implements its own function
```
is_equal(val1, val2), and this function is internally obfuscated, in order to make its role
```
non-obvious.
To make things more complicated, various parts of the code use diverse versions of the
```
is_equal function - and each of them is obfuscated in a randomized way.
```
-----
Some versions also contain redundant parameters.
-----
In between, we can encounter redundant API calls. In the below example, before the
comparison is made additional conditions are being checked, and meaningless calls to
```
RealeaseDC and GetStringTypeW are made.
```
-----
Deobfuscation is difficult also because of the huge diversity of implementations of those
simple functions. A list of various instances of is_equal function in one of the analyzed
samples shows the diversity:
-----
The same is done for other comparators, as well as arithmetic operators such as +, -, ^, &
etc.
**Imports**
It is a common practice among malware authors to obfuscate API calls. Often imported
functions are fetched by their pre-calculated checksums, and mapped to their addresses
just before use. Similarly it is implemented in the analyzed case - yet, it is more complicated
in some ways.
-----
Before the new function can be fetched by a checksum, the initialization of the retrieving
function is required. During this step, addresses of functions LoadLibraryA and
```
GetProcAddress are filled into a global structure.
```
The import is fetched just before use, by a call to the dedicated function. In the example
below, we can see two parameters being pushed on the stack before the retrieving function
(load_func_by_checksum) is called: the DLL’s ID (0), and the function’s checksum
(0x1FEDC07). Based on those two parameters, a needed API is retrieved - in this case it is
```
GetWindowsDirectoryW.
```
The retrieving function has the following prototype:
```
FARPROC __cdecl load_func_by_checksum(DWORD lib_id, DWORD checksum);
```
Internally this function selects a proper DLL by an ID (and eventually loads it if missing),
and then calls a function directly responsible for mapping the checksum to the appropriate
API. Prototype of the called function:
```
FARPROC __cdecl load_function_from_lib_module(HMODULE library, DWORD checksum);
```
In case of failure to retrieve any import, the bot just terminates its execution.
-----
Usually, the DLL is fetched from the libraries loaded in a typical way (using LoadLibrary).
But there are 3 DLLs that are supposed to be loaded manually: libssl.dll, zlib1.dll,
```
sqlite3.dll. (It matches the previous observations, done during behavioral analysis.).
```
Their addresses are supposed to be filled in the internal list.
In common scenarios of malware analysis, once we understand the import loading
mechanism, and know the checksum calculation algorithm, we can easily write a
deobfuscator which will do a reverse lookup, mapping checksums back to function names.
But in this Zbot things are more complicated. The obfuscator diversified the way in which
the checksum is retrieved. Sometimes, the explicit value is hardcoded (as in the example
above). Yet, in many cases, they are calculated first by dedicated functions. For example,
this is how in one of the cases VirtualAlloc is resolved: we don’t know the checksum until
the function that calculates it returns the result.
Another example - fetching the select function. This time neither DLL’s ID nor the
function’s checksum is hardcoded - both are unknown until they are calculated by the
obfuscated functions (denoted on the picture as calc_dll_id(),
```
checks_socket_select()).
```
-----
In such cases, even having the import-retrieving function re-implemented won’t help. We
would be forced to re-implement each and every checksum-calculating function - so that
we could retrieve proper parameters first. Those checksum-retrieving functions are also
obfuscated, and diversified, so reimplementing them would be a laborious task. Example of
the function retrieving the checksum:
[Such problems can be solved with libPEconv. We can call original functions from the](https://github.com/hasherezade/libpeconv/)
malware, just by defining their prototypes and supplying their offsets.
Due to the fact that many constants in the code are obfuscated, it is not even possible to
guess the called function by looking at the passed parameters. The given example shows
how the call to VirtualAlloc may look like: not only is the function name obfuscated, but
also many of the passed arguments.
-----
**Strings**
Most of the strings used by malware are also obfuscated. There are two separate
obfuscation functions: one for ANSI strings, and another for UNICODE. Prototypes of both
are analogical:
```
DWORD __cdecl decode_cstring(const char *in_buf, char *out_buf, int length);
DWORD __cdecl decode_wstring(const wchar_t *in_buf, wchar_t *out_buf, int length);
```
Similarly like in the case of retrieving imports, values of some of the parameters can be
calculated just before the use, by unique, obfuscated functions. So, for example, we don’t
know what the address of the input buffer is until we execute the dedicated function
retrieving it. This makes automatic deobfuscation difficult.
Yet, the string deobfuscation functions alone are pretty simple. After cleaning the
redundant instructions we can see, that all what they do is XORing the input buffer with the
hard-coded key:
```
const char g_StrXorKey[] = "fgK#I6#D!NtdI#!J";
char *decode_cstr(char* in_buf, char* out_buf, int length)
{
for (size_t i = 0; i != length; ++i)
out_buf[i] = g_StrXorKey[i % 16] ^ in_buf[i];
return out_buf;
}
wchar_t *decode_wstring(const wchar_t *in_buf, wchar_t *out_buf, int length)
{
for (size_t i = 0; i != length; ++i)
out_buf[i] = wchar_t(g_StrXorKey[i % 16]) ^ in_buf[i];
```
-----
```
return out_buf;
}
```
**Deobfuscation**
[With the help of a libPEconv library, along with IDA scripts, we managed to deobfuscate all](https://github.com/hasherezade/libpeconv/)
the strings and imports used by the malware. The libPEconv library allowed to import the
constant-generating functions directly from the malware, without the need of
understanding and rewriting the obfuscated code. Then, IDA scripts helped to automate the
[process of extracting the needed values. As a result we got the following listings, which can](https://github.com/hshrzd/zbot_material/tree/master/csv)
[be applied on a binary, i.e. with the help of IFL Ida Plugin. This is how the code with applied](https://github.com/hasherezade/ida_ifl)
tags may look like - strings, as well as the fetched imports, has been added as comments:
After deobfuscation of the bot, we can analyze it statically, i. e. in IDA.
### Used static libraries
Looking at the strings of the module, we can see artifacts hinting that some of the known
[open source libraries have been used. For example, the MinHook library:](https://github.com/TsudaKageyu/minhook/blob/master/include/MinHook.h)
-----
[There are also HTTP messages that suggest usage of HTTP parser from NodeJS.](https://github.com/nodejs/http-parser)
### Plain loader vs antiemule loader
As mentioned in the introduction of the malware elements, the loader can come in one of
two flavors: plain or anti-emule. They do not differ in terms of the core functionality.
However, an anti-emule loader comes with additional loops of junk code that are supposed
to maximally slow down the analysis, if the malware is being executed by an emulator.
Below you can see fragments of logs generated when both flavors of the loader (the same
version number) have been deployed via PIN tracer.
-----
In the case of the plain one, the core functionality of creating the msiexec process, and
injecting itself there, starts right away after the loader is deployed. In case of the anti-emule
one we see a long trace of redundant instructions being called in a loop, before the real
action starts.
### Execution flow
In this part we will follow through the malware execution, starting from the component
[d93ca01a4515732a6a54df0a391c93e3 that was dropped by the RIG Exploit Kit. The](https://www.virustotal.com/gui/file/becacb52a50004d42538cfe82c8f527f1793727c5f679f46df7f96eade272962/community)
version of the analyzed package is 1.0.8.0. Occasionally we will refer to other samples
(higher versions) in order to present the updates.
**The loader (loader-bot32.exe)**
The below diagram shows the components of the malware running in particular processes,
at the loading stage.
-----
First the loader executable is deployed. It runs msiexec, and injects itself there. It
retrieves the next stage (bot32/64) either from local storage, or from the C2 server, and
injects it in the same instance of msiexec.
_The loader’s execution steps:_
A) Initial run (original executable, original entry point)
- inject itself into msiexec and run
B) Inside msiexec (changed entry point)
- initialize internals:
– init imports loader (store pointers to LoadLibraryA and GetProcessAddress in
global variables, that will be used to load import by hash)
– walk through the Import Table and load all the imports (they were not
initialized by the loader component)
– decrypt internal configuration (including C2 URL) with a hardcoded RC4 key #1
(in currently analyzed sample it is fgnukdkakyldcgqnleqe)
- check if compiled as debug: if yes, show an info: BOT-INFO-> It's a debug version..
Check if Proxyfier.exe is running. If Proxifier detected, show a MessageBox informing
about the collision with internal proxy: BOT-INFO->Proxifier is a conflict
```
program, form-grabber and web-injects will not works. Terminate proxifier
for solve this problem..
```
- try to retrieve the installation data from the registry
(HKCU\Software\Microsoft\) - names of the keys are unique for
a particular version of the bot), i.e. HKCU\Software\Microsoft\lolo -> ystu. Decrypt
the value with RC4 key #2 retrieved from the hardcoded configuration.
- if the installation key is not found, install itself: generate the installation data block and
save it in the registry under HKCU\Software\Microsoft\.
Installation block includes RC4 context (initialized with randomly generated RC4 key
#3) that will be used for encrypting files, as well as paths that will be used for storing
those files (in %APPDATA%)
- try to retrieve the core module (bot32/64.dll) saved on the disk (in encrypted file in
```
%APPDATA%). Validate the file. If validation was successful, store the payload internally
```
for further loading.
-----
- If the core module could not be retrieved, try to download it from the C2, following the
URL from the internal configuration. (In older loaders only the hardcoded URLs were
used. In newer versions, also DGA is used)
- If downloading was successful, save the module on the disk (in
```
%APPDATA%/)
```
- Manually load the core module and redirect execution there, or exit on failure.
Implementation details of the selected actions will be given below.
_Injection into msiexec_
The loader can be implemented as a DLL or as EXE. Below we will walk through the process
of loading of the loader implemented as EXE.
At the beginning of loader’s execution we can see a code responsible for creating a new
msiexec process:
-----
The full loader’s PE is copied into a buffer, and obfuscated by XOR:
When we run the downloader we can see that it injects its copy into msiexec, along with
shellcode.
_The memory regions highlighted in the image are the implants: the obfuscated PE and the_
_shellcode._
-----
The injected copy is XOR obfuscated at first, with a random DWORD-sized key. The role of
the additional shellcode is to deobfuscate it, and then redirect execution there. Fragment of
the shellcode processing XOR obfuscated copy of the module presented below:
_The loop in the shellcode processing the obfuscated PE._
After applying the XOR key, the PE is revealed. We can find that it is a copy of the initial
loader - yet, its Entry Point has been replaced: on this run, the execution starts from a
different address.
-----
_After the decoding loop finishes the execution, the PE is revealed._
Beginning of the main function, where the execution starts inside the msiexec:
_Loader’s main function_
Loader’s main function starts from the initialization, involving several steps.
-----
_The init function of the loader, view from x64dbg._
The loader goes through its own Import Table and fills the imports. In addition to the
functions from the Import Table, imports loaded by hashes are going to be used. The
algorithm used for fetching them is the same as explained in the “obfuscation” section.
The malware comes with RC4 encrypted configuration, which is first decrypted with the
help of the hardcoded key (key#1).
-----
We can find there i.e. the ID of the botnet, and the URLs of the C2 gates which are going to
be queried. At the end of the configuration there is another RC4 key (key #2). The details of
the malware configuration and storage are explained in the dedicated section.
After the initialization phase, the malware proceeds with the installation. First, it queries
the special registry key, which is used for storing installation data of the bot.
-----
It also RC4 decrypts a hardcoded 16 byte value, converts it into GUID and uses it as a mutex
name.
Then, it generates a bot ID in a format: %s_%08X%08X consisting of the machine name, and
generated machine ID. The algorithm used for its generation will be presented further.
In case the core bot was already installed, the paths for the components are fetched from
the installation data block. The core bot component is being read from the dedicated files,
and decrypted.
-----
The decrypted data contains the PE file per-pended with the header. The header contains
the bot version - in the current case it is 1.0.8.0. The version must match the one hardcoded
in the loader. Just before the PE content, its size, and then the CRC32 checksum is stored.
The checksum will be verified before the bot is loaded.
In case if the bot could not be retrieved, the loader will try to download it from its C2
server.
_Downloading modules from the C2_
The malware opens internet communication:
-----
First it beacons to the C2:
And it downloads and decrypts the next stage DLL.
_[Decrypted payload ab756f154d266c8ba19bdfa8bcaf1b73](https://www.virustotal.com/gui/file/df60102fff5974a55fb6d5f4683f2565b347a0412492514e07be9b03c7c856b7/details)_
The details about downloading modules are given in the “Traffic analysis” section.
-----
Redirecting the execution:
_The DGA_
In the newer versions of this malware, in addition to the hardcoded C2 URL, a Domain
Generation Algorithm (DGA) is being used. The generated URLs are being queried one after
another, till the successful connection is established.
The Domain Generation Algorithm uses the supplied seed.
-----
Reconstruction of the DGA code is given below:
-----
```
#include
#include
void generate_domains_list(DWORD seed, size_t count)
{
DWORD _seed = seed;
char _next = 0;
while (count--) {
size_t len = 1;
do
{
_next = _seed % 0x19 + 0x61;
std::cout << _next;
_seed = seed ^ (_next + _seed);
} while (len++ < 0x14);
std::cout << ".com\n";
}
}
```
At once DGA generates 32 domains.
The seed is generated based on the local time.
```
unsigned long long make_seed()
{
SYSTEMTIME local_time = { 0 };
GetLocalTime(&local_time);
local_time.wHour = 0;
local_time.wMinute = 0;
local_time.wSecond = 0;
local_time.wMilliseconds = 0;
FILETIME file_time = { 0 };
SystemTimeToFileTime(&local_time, &file_time);
unsigned long long *a1 = (unsigned long long*) &file_time;
return compress_time(*a1);
}
```
The following function is used to convert the retrieved time into a DWORD:
```
#define LODWORD(a1) (a1 & 0x00000000FFFFFFFF)
#define HIDWORD(a1) (a1 & 0xFFFFFFFF00000000)
unsigned long long compress_time(unsigned long long file_time)
{
unsigned long long compressed_time = file_time - 0x19DB1DED53E8000i64;
DWORD a2 = 0x989680u;
unsigned long long v3 = LODWORD(compressed_time) + (HIDWORD(compressed_time) %
a2);
unsigned long long result = LODWORD(v3 / a2) + (HIDWORD(compressed_time) / a2);
return result;
}
```
-----
Then, the RC4 algorithm with the key from the config (key #2) is applied on it:
The final value is the seed for generating the domains. The strings generated by the
algorithm are appended with .com domain extension, and the gate address post.php.
Summing up, the used DGA is a client-side implementation of the same algorithm that is
used in the panel.
Those domains are filled in an internal structure, and then they are picked one by one, till
the responding domain is found.
-----
_The generated domains are aggregated in an internal structure, and queried one by one._
**The core (bot32.dll)**
The below diagram shows the components of the malware running in particular processes,
after the execution got redirected to the main bot (running inside msiexec).
-----
_The bot’s execution steps:_
A) Starting execution at Entry Point (after being loader by the previous - loader
component)
- initialize internals:
– init imports loader (store pointers to LoadLibraryA and GetProcessAddress in
global variables, that will be used to load import by hash)
– walk through the Import Table and load all the imports (they were not
initialized by the loader component)
– init a CRC32 table
– WSA startup (initialize WinSock 2.0)
– decrypt internal configuration (including C2 URL) with a hardcoded RC4 key #1
(in currently analyzed sample it is fgnukdkakyldcgqnleqe)
– InternetSetOptionA: INTERNET_OPTION_MAX_CONNS_PER_SERVER -> 10
– read installation data stored in the registry:Software\Microsoft\ (in the currently analyzed version it is lolo->ytsu). If found, decrypt the
```
information. The data stored in the registry key is encrypted/decrypted with
the help of the RC4 key #2, retrieved from the C2 configuration (in the analyzed
sample it is 90f1e19e2306648e9e22059d47f36016). Those data contains paths
to encrypted components stored in unique directories created in %APPDATA%
– get Volume CLSID for the unique identification of the infected machine
– init default UserAgent string: Mozilla/5.0 (Windows NT 6.3; Win64; x64)
```
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88
Safari/537.36)
```
- fetch path to the VNC module from the information saved in the registry
-----
- fetch the unique Bot ID saved in the registry and store it in a global variable for further
use
- run threads responsible for particular malicious actions, such as:
– command parsing loop: parse commands sent to the bot, and deploy demanded
actions
– upload to the C2 files where the stolen data were collected
– steal data from browsers SQLite databases (cookies)
– install a fake certificate and run the local proxy
– a loop monitoring the processes and injecting the modules in them
– run VNC server
Implementation details of the selected actions will be given below.
_Core bot’s main function_
_[Analysis based on sample: ab756f154d266c8ba19bdfa8bcaf1b73](https://www.virustotal.com/gui/file/df60102fff5974a55fb6d5f4683f2565b347a0412492514e07be9b03c7c856b7/details)_
The execution of the core bot starts by the initialization phase.
The initialization function prepares various elements of the bot for the further
functionality. First, the imports lookup is initialized:
-----
Due to the fact that the loader component didn’t fill the import table, the payload needs to
do it on its own. It walks through the import table and fills the thunks.
-----
Then we can see the initialization of the socket, and of the decryption of the stored
configuration:
-----
The bot collects some data about the execution environment, and retrieves the previously
saved information from the registry:
After the initialization succeeded, the bot continued the execution of the malicious
operations, by deploying various threads.
-----
-----
In the newer versions, one more thread has been added for querying the information about
the network settings.
The data is retrieved simply by querying commands such as:
```
ipconfig /all
net config workstation
net view /all /domain
nltest /domain_trusts
nltest /domain_trusts /all_trusts
```
The output is reported to the C2.
### Storage
The bot keeps its data in encrypted files, stored in %APPDATA%, in directories with
pseudo-random names. In order to keep track of what files are in use, and what are their
purposes, it uses a special structure. This structure is generated at the moment of bot’s
installation, and kept in the encrypted format in a dedicated registry key, which is also
encrypted.
Let’s take a look at the full logic of the malware’s storage.
-----
Both, the loader and the bot, comes with an internal configuration that resides in the .data
section of the PE, and is encrypted with the hardcoded key (key#1).
After decrypting this configuration, we can see data such as the campaign ID, C2 URL, and
also another RC4 key (key#2) - which will be used i.e. for communication with the C2.
This key (key#2) is also going to be used for encrypting/decrypting of the installation
information block, stored in the registry, and shared between the loader and the bot.
At the moment of installation, the first malicious module (loader) creates the installation
registry key, and fills it with the encrypted content of the installation information block.
-----
The loader generates a 0x28 bytes long RC4 key (key#3), that will be further used for
encrypting dropped files:
_The RC4 context is initialized with the random 0x28 byte long key._
-----
The generated context:
_The buffer shown on the picture is the RC4 context data that was initialized with the given_
_key._
Instead of storing this key (as it would be done in typical scenarios) the RC4 context data is
stored inside of the installation data block.
-----
-----
The installation block contains the list of the files used by the malware, as well as other
used registry keys. Overview:
```
header:
- malware version (DWORD)
- size of the data (after the header) (DWORD)
- CRC32 of the data (DWORD)
data:
```
- CLSID of the main VolumeID (retrieved by GetVolumeMountPoint): 16 bytes
- unique bot ID: _ (Unicode string)
- name of the Autorun key (Unicode string)
- RC4 context initialized with the key#3 (it that will be used for decryption
```
of the files)
```
- list of the files (relative to `%APPDATA%`)
- additional registry keys (relative to `HKCU/Software/Microsoft`)
```
padding: random bytes after the data
```
The referenced components (files and registry entries) are encrypted with the RC4
algorithm, using the stored RC4 context (initialized by the loader with RC4 the key#3).
Additionally, some of them are encrypted with a custom, XOR-based algorithm called Visual
Encrypt (described in details in a section C2 Communication ).
### Bot ID
The bot ID consists of two components. First is the string, which is simply a machine name,
retrieved by GetComputerNameW. If the name could not be retrieved, a string UNKNOWN will be
used instead.
-----
After that, the numerical identifier is generated. First the OS version is retrieved by
```
GetVersionExW. Then two keys under Software\Microsoft\Windows NT\CurrentVersion
```
are read: InstallDate and DigitalProductId.
-----
The malware calculates CRC32 checksums from those elements and combines them
together by formatted print.
-----
### Retrieving installed modules
As mentioned before, the files used by the malware are stored in dedicated directories in
```
%APPDATA%. The names of the files, as well as names of the directories are randomly
```
generated at the installation phase. In order to keep track of them, and load them on
demand, the malware keeps a dedicated structure (installation data block). It is stored in
the registry, and decrypted on demand each time it is used, with the help of the RC4
algorithm and the key from the configuration (RC4 key#2).
-----
Example of the files list fetched from the installation data block:
-----
The module is retrieved from the structure by its ID. The following function is responsible:
Each IDs denotes a specific file. The PE modules are denoted by the following IDs:
- 0 : The core bot
- 1 : 64-bit memory reader (only for 64-bit installations)
- 3 : VNC component
- 7 : libSSL
- 8 : Zlib1
- 9 : Sqlite
- 10 : Certutil package (certutil.exe + dependencies)
Elements stored in the installation data structure of the analyzed case:
|ID|Path|Encryption|Role|
|---|---|---|---|
|0|Guuga\ugef.hi|RC4|PE module: zbot.dll|
|1|Gefu\bihad.by|RC4|64-bit memory reader (empty on 32 bit system)|
|2|Gefyf\yddieb.exe|not encrypted|Zloader PE|
|3|Yceho\ugcud.daig|RC4|hvnc.dll|
-----
|4|Ybaf\ofdaofu.gucub|?|report (empty for now)|
|---|---|---|---|
|5|Ecob\deidicy.ifb|5 bytes + encrypted content (RC4 + Visual Encrypt)|report (including screenshot)|
|6|Badabe\buif.ihceg|5 bytes + encrypted content (RC4 + Visual Encrypt)|report|
|7|Agafh\ofgyoc.edeg|RC4|libssl.dll|
|8|Ygubo\acbei.idi|RC4|zlib1.dll|
|9|Hioh\ifahibif.ihudy|RC4|sqlite3.dll|
|10|Heib\dafi.hu|RC4|certutil + DLLs|
|11|Buuge\byadf.efg|5 bytes + encrypted content (RC4 + Visual Encrypt)|certificate|
|12|Buguuha||registry path at HKCU/Software/Microsoft|
||ceefhuod|RC4 + Visual Encrypt|registry value #1 (under HKCU/Software/Microsoft/ Buguuha): C2 data + fake cert|
||difi|?|registry value #2 (under HKCU/Software/Microsoft/ Buguuha)|
### Uploading of the reports
The data stolen from the victim is aggregated in encrypted files, at the specific paths. One of
the threads deployed by the malware is dedicated to regular uploading of those files to the
C2.
Before the upload, the data is decrypted, and encrypted by a different RC4 key: the key
from the config (key #2), along with Visual Encrypt.
-----
In the early versions of the malware, some related debug strings were left, and even a
popup on the upload failure:
-----
### Manually loading PEs
Many of the additional PE modules (including the aforementioned legitimate DLLs: zlib1,
libssl, sqlite3) are loaded manually. The following function is responsible:
After the DLLs are being manually loaded, the pointer to their bases is added into the
internal list, referenced by the function that retrieves the functions by hashes. Then, the
functions from them are retrieved analogically to the functions from the DLLs loaded in the
standard way.
The same PE loading function is also used to load further modules belonging to the
malware, such as VNC Server.
-----
### VNC Server
The VNC server is an additional module of the malware. As mentioned before, its role is to
open a hidden VNC on the attacked machine, giving the attacker remote access. The module
is implemented as a DLL, exporting two functions:
```
int __stdcall VncStartServer(DWORD *a1, QWORD *a2);
BOOL __stdcall VncStopServer(LPVOID vnc_struct);
```
It is stored in one of the encrypted files (as explained in “Execution flow” paragraph). It is
first read from the file, then decrypted and manually loaded.
Let’s first take a quick look at how the VNC server is run by the main bot.
-----
The function VncStartServer is fetched from the loaded module, and called with the
address of the local host and port.
-----
The VNC server operates in the background when the malware is running. When it is
stopped, the termination function is called.
-----
### Inside the VNC component
In contrast to the core component, the VNC DLL does not use obfuscation of API calls. Yet, it
uses obfuscation of some arithmetic operations. We can see inside multiple functions
related to managing a virtual desktop that will be used by the attacker to access the victim’s
machine via graphical user interface.
-----
It also gives access to the keyboard and clipboard of the victim.
-----
### Commands: implementation
One of the threads runs a continuous parsing and executing of the commands received
from the C2 server.
The received command is compared with the hardcoded one, and when the match is found,
a particular function is executed.
-----
The complete list embedded in the module is given below:
- `user_execute`
- `bot_uninstall`
- `user_cookies_get`
- `user_cookies_remove`
- `user_passwords_get`
- `user_files_get`
- `user_url_block`
- `user_url_unblock`
The supported list covers the commands described in the User manual, yet, it contains
some additional ones, such as fetching files, and passwords. It suggests that the authors
keep extending the functionality of the bot.
Detailed explanation of the stealing implementation is described in the further paragraph
stealer functionality.
-----
**user_cookies_get**
This command is responsible for searching databases where cookies of particular browsers
are stored, opening them, and extracting content by SQLite queries. The following queries
are used:
```
select `host`, `name`, `value`, `path`, `expiry`, `isSecure`, `isHttpOnly`,
`sameSite` from `moz_cookies`
select `host_key`, `name`, `encrypted_value`, `samesite`, `path`, `expires_utc`,
`is_secure`, `is_httponly` from `cookies`
```
The analyzed version of the bot searches for cookies from two browsers: Chrome and
Firefox.
**user_passwords_get**
Execution of this command triggers stealing passwords saved in the attacked browsers.
Currently only Chrome is supported. The following query are executed:
```
select `origin_url`, `username_value`, `password_value` FROM logins
```
**user_files_get**
Execution of this command triggers the operation of searching and uploading documents of
the victim (.txt, .docx, .xls, wallet.dat).
### Hooks - code analysis
The overview of the installed hooks was presented in the behavioral analysis, section
**Implants.**
As it was mentioned, almost every process in the system was hooked:
```
ntdll.NtCreateUserProcess and user32.TranslateMessage were affected.
```
In browser processes (iexplore.exe, chrome.exe) we could find additional hooks
installed: ntdll.NtDeviceIoControlFile and crypt32.CertGetCertificateChain,
```
crypt32.CertVerifyCertificateChainPolicy.
```
In firefox.exe only the additional hook in ntdll was applied
(ntdll.NtDeviceIoControlFile).
Let’s connect those observables with the code within the bot that was responsible for
installing them. First, the function (RVA 0x2D81B in the analyzed bot32) is responsible for
collecting the APIs to be hooked. We can find out how different processes are affected.
-----
In all the processes:
- `ntdll.dll`
- `NtCreateUserProcess -> bot32.write_payl_into_process`
- `user32.dll`
- `TranslateMessage-> bot32.grab_forms_and_screenshot`
Depending on Windows version, it may also install:
- `ntdll.dll`
- `NtCreateThread -> bot32.write_payl_into_process_v2`
In firefox.exe, chrome.exe, iexplore.exe
- `ntdll.dll`
- `Nt/ZwDeviceIoControlFile -> bot32.pass_trafic_through_local_proxy`
In chrome.exe, iexplore.exe
- `crypt32.dll`
- `CertGetCertificateChain -> accept_cert_unconditionaly1`
- `CertVerifyCertificateChainPolicy -> accept_cert_unconditionaly2`
The details on the hooks functionality will be explained in the further paragraph.
**The injector and the hooking engine**
_Initialization_
One of the threads run in the main function of the bot is responsible for continuous
monitoring of the processes.
If the current module is 32 bit, and runs on a 64 bit system as Wow64, in order to make
injections into 64 bit processes one more module is used: 64_gate32.dll. This DLL was
presented briefly in section “modules for 64 bit system”. It is an additional DLL of the
malware, manually loaded into the current process.
-----
Just as the name suggests, this 32-bit DLL enables an access to 64-bit environment, using
[the Heaven’s Gate technique. Below - fragment of the DLL’s code calling the “Heaven’s Gate”](https://blog.malwarebytes.com/threat-analysis/2018/01/a-coin-miner-with-a-heavens-gate/)
in order to switch to 64-bit mode:
This DLL exports a simple API, with self-explanatory names:
- `CmpMem64 - compare 64-bit memory`
- `GetMem64 - get 64-bit memory`
- `GetTEB64 - get 64-bit TEB (Thread Environment Block)`
- `X64Call - perform a 64-bit call`
Those functions are being called whenever any access to a 64-bit environment is required.
-----
_The example shows the function GetTEB64 being fetched from the manually loaded DLL, and_
_then called._
If preparation of the injection engine was successful, the malware enters into a function
that enumerates running processes and performs the injection.
-----
_The injecting loop_
The injecting function starts by taking a snapshot of all running processes, using
```
CreateToolhelp32Snapshot, and then walks through it.
```
It injects the current module (main bot) into all accessible processes, except for Microsoft
Edge. When the injection into explorer.exe has failed, information about it will be
appended to the report that is later sent to the C2.
Although the injected payload is the same PE as the current module, yet it’s execution flow
will be different. It is because its execution will start from a different Entry Point.
-----
_Fetching the new Entry Point for the implant_
The function at the new Entry Point is the one responsible for installing hooks inside the
process where the implant was injected.
_The implant’s main function_
As mentioned in the previous paragraph, the installation of the API hooks is performed by
the implanted copy of the bot, with an alternative Entry Point.
_The function at the Entry Point for the implant has three blocks representing the three phases:_
_initialization, main actions, and the exit._
As before, the execution starts with the initialization function. Then there is a call into a
single function responsible for deploying the main actions. Among few other actions, it is
responsible for hooking the API of the DLLs loaded in the current process.
The API hooking function is run as first.
-----
Then, the bot deploys a thread responsible for communicating with the local server, run in
the main component implanted in msiexec.
The implant checks if it has been installed in the explorer.exe - and if so, it reports about
it (“Inject to explorer success.”).
-----
This report is then being sent to the C2. Although all the accessible processes (except Edge)
are being injected, only the injection into explorer is being reported.
Another condition that is checked inside the same function, is, if the implant runs inside
```
iexplore.exe - if so, it may deploy an additional thread for deleting URL cache.
```
Yet, the most important and interesting function that is being deployed, is the hooking
ability.
_The hooking process_
Depending on which process the implant is running, the different hooks will be selected to
apply.
-----
The addresses of the functions to be hooked are retrieved in a typical way - by calling
```
GetModuleHandleW + GetProcAddress. Thanks to this, we can easily follow what functions
```
are being hooked in particular cases.
The function writing hooks takes 3 arguments: the original function (target to be hooked),
the intercepting function, and the trampoline function (which redirects back to the original
[function that is being intercepted) - just like the function MH_CreateHook from MiniHooks](https://github.com/TsudaKageyu/minhook/blob/8fda4f5481fed5797dc2651cd91e238e9b3928c6/include/MinHook.h#L111)
[library which artifacts we noticed in the former part of this analysis:](https://github.com/TsudaKageyu/minhook/blob/8fda4f5481fed5797dc2651cd91e238e9b3928c6/include/MinHook.h#L111)
```
// Creates a Hook for the specified target function, in disabled state.
// Parameters:
// pTarget [in] A pointer to the target function, which will be
// overridden by the detour function.
// pDetour [in] A pointer to the detour function, which will
override
// the target function.
// ppOriginal [out] A pointer to the trampoline function, which will be
// used to call the original target function.
// This parameter can be NULL.
```
-----
```
MH_STATUS WINAPI MH_CreateHook(LPVOID pTarget, LPVOID pDetour, LPVOID
*ppOriginal);
```
The hooking is not done by an atomic write. Instead, in order to avoid concurrency issues,
the hooking function first suspends all the other threads of the current process. After the
hook is set, the threads are resumed.
This model: suspending -> hooking -> resuming is also typical for the MinHook library
[(example: functions Freeze and Unfreeze from MinHook are responsible for suspending](https://github.com/TsudaKageyu/minhook/blob/8fda4f5481fed5797dc2651cd91e238e9b3928c6/src/hook.c#L307)
and resuming threads.
_Reporting to the main component_
After the hooking is done, the malware establishes the connection to the local server, that is
run by the main instance of the malware (implanted in msiexec). The connection is made to
send the information recorded via hooks to the central component.
-----
Example: a captured screenshot (JPG) being sent via local socket:
It also ensures that the main instance is alive. In case if it has terminated, all the hooks are
being removed.
-----
_Hook implementation - example:_
Step 1. The hook installed at the beginning of the function redirects the execution to the
function inside the bot32.dll:
-----
Step 2. Each time the hooked function (i.e. CertGetCertificateChain) is called, the
execution is redirected to the function inside the bot. The original function
```
CertGetCertificateChain will be called from inside, via additional shellcode containing a
```
small wrapper/trampoline function.
-----
The content of the “trampoline” in the additionally allocated memory is presented below. It
is a small wrapper containing the function’s prolog “stolen” from the original version,
before it has been overwritten by the jump instruction:
That’s how the intercepting function still uses the original function
```
CertGetCertificateChain, and just adds a filter on the top of it.
```
**Functionality of the hooks**
_user32.TranslateMessage_
- The hook of the function user32.TranslateMessage:
redirects into a function responsible for keylogging and making screenshots.
```
TranslateMessage is used by the GUI elements to process the events triggered by some
```
actions, such as refreshing of the component, moving a mouse etc. The malware has filters
[set on two messages: WM_KEYDOWN and WM_LBUTTONDOWN - to monitor user typing or](https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-keydown)
clicking in the windows. Any other events - and also a WM_KEYDOWN event, if the pressed key
was ESCAPE - are being skipped, and the navigation goes back to the original
```
TranslateMessage function via trampoline.
```
-----
Otherwise the malware proceeds to record what is happening on the screen: by capturing
the title of the active window, recording the keyboard state, and, eventually making a
screenshot showing the performed activity.
-----
Capturing the window title:
-----
Proceeding to make a screenshot:
The collected information is filled into an internal buffer. The content of this buffer is later
being then sent to the main component via the previously opened connection.
After recording of the action finished, the execution goes back to the original
```
TranslateMessage function via trampoline.
```
_ntdll.NtCreateUserProcess_
- The hook in ntdll.NtCreateUserProcess:
redirects into a function that writes the payload into the process. First the redirection
function executes the trampoline, and allows the new process to be created. Then, it
eventually implants the bot inside and executes it. Again, the Microsoft Edge is being
skipped from this injection by the check on the created process’ name.
As before, the bot injects the copy of itself, yet its execution starts from another variant of
Entry Point.
-----
[The redirection is done via changing the context ( SetThreadContext ) of the main thread of](https://github.com/hasherezade/demos/blob/master/inject_shellcode/src/patch_context.h#L6)
the newly created process.
-----
The values highlighted red on the above image are the modifications of the original context
[that was retrieved before. We can see the VA](https://stackoverflow.com/questions/2170843/va-virtual-address-rva-relative-virtual-address) of the implant’s Entry Point being written. VA:
```
0x61277 -> 0x31277 (Entry Point RVA) + 0x30000 (the implant Base Address).
```
This redirection model uses the fact that in case if the process didn’t start yet, its original
Entry Point is filled in a register (in case of a 32 bit process it is the register EAX). If we
overwrite the EAX in the frozen thread’s context by the value of the implant’s Entry Point,
this will be the first address executed when the thread resumes.
This variant of the implant’s Entry Point is almost identical to the one described in the
section about the hooking implant. It also sets API hooks, communicates with the main
module, etc. The only difference is that this function calls the Entry Point of the original
application afterwards. It happens because the injection model was a bit different than the
former case: now the process was just created, and it’s fresh context was changed, so its
original Entry Point yet has to run.
As we can see, this hook allows the implant to propagate to newly created processes. Not
only the main module is responsible for injections - but each instance of the injected
payload has the ability to inject itself further.
_ntdll.NtCreateThread_
This hook is used to propagate the payload - analogically to hook at NtCreateUserProcess.
_crypt32.CertVerifyCertificateChainPolicy_
For policies other than SSL (CERT_CHAIN_POLICY_SSL) uses the original version of the
function. For SSL, it cleans the error flag unconditionally, approving any certificate as valid.
_crypt32.CertGetCertificateChain_
Accept the certificate unconditionally.
-----
First the original function CertGetCertificateChain is called via trampoline. The
[retrieved CERT_CHAIN_CONTEXT is modified in such a way that its status is always set as](https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/ns-wincrypt-cert_chain_context)
valid:
```
TrustStatus.dwErrorStatus -> CERT_TRUST_NO_ERROR
TrustStatus.dwInfoStatus -> CERT_TRUST_IS_PEER_TRUSTED
```
_ntdll.ZwDeviceIoControlFile_
This function is used to bypass the traffic generated by the browsers through the local
proxy.
Hook on this function is very common in case of malware intercepting network traffic. It is
because ZwDeviceIoControlFile is a low level function that is called from the well-known
winsocks functions, such as connect, send, recv, etc. With the help of
```
ZwDeviceIoControlFile those functions communicate with afd.sys (Ancillary Function
```
[Driver) that executes the network operations.](https://www.file.net/process/afd.sys.html)
The function prototype:
```
NTSYSAPI NTSTATUS ZwDeviceIoControlFile(
HANDLE FileHandle,
HANDLE Event,
PIO_APC_ROUTINE ApcRoutine,
PVOID ApcContext,
PIO_STATUS_BLOCK IoStatusBlock,
ULONG IoControlCode,
PVOID InputBuffer,
ULONG InputBufferLength,
```
-----
```
PVOID OutputBuffer,
ULONG OutputBufferLength
);
```
One of the passed parameters is an IOCTL number for the driver. This number identifies
the operation that will be requested.
The malware is interested only in two IOCTLS: 0x12007 -> AFD_CONNECT (Connect) and
```
0x120C7 -> AFD_X32_CONNECT (SuperConnect). If any other is used, the execution returns
```
back to the original version of the ZwDeviceIoControlFile, via dedicated trampoline.
At the moment when this IOCTL is sent, the driver establishes the connection with the
remote host, the address of which is given in the input buffer. If the malware replaces the
address of the remote host with the address of its own, the connection will be established
with the local proxy instead.
But before the function decides it the traffic should be bypassed in a particular case, some
additional checks are being made.
For example, only connections at port 80 (HTTP) and 443 (HTTPS) are intercepted.
-----
Finally, the host is being replaced:
But the function does not end on this, but also verifies the result of
```
ZwDeviceIoControlFile. If establishing the connection to the proxy was not successful, the
```
implant will try to troubleshoot the issue. First it tries to connect to the main component of
the malware. If the server is not responding, it means that probably the main component
-----
was killed or crashed. In order to not draw the attention of the victim by preventing further
connections, the hook is removed.
### Man-In-The-Browser local proxy
Among the main features of the malware there is formgrabbing as well as webinjects. The
first feature allows attackers to steal data from the open browser windows. The other
feature allows them to modify the content of websites displayed to the victim.
[In order to be able to perform those actions, the malware has to deploy a Man-In-The-](https://en.wikipedia.org/wiki/Man-in-the-browser)
[Browser](https://en.wikipedia.org/wiki/Man-in-the-browser) (MITB) attack, (which is a variant of Man-In-The-Middle). As mentioned before, in
order to do this, the malware has to install its own (fake) certificate, and to run a local
proxy. This part is done by the main bot component, running in the msiexec - while the
component implanted into browsers is responsible for redirecting traffic via this proxy. In
some browsers, additional hooks are being installed, which are responsible for pretending
that the certificate is valid.
In the previous sections, we focused on the hooks. In this section we will focus on how this
proxy is implemented on the side of the main bot.
-----
**Deploying the proxy**
In the main function of the core bot component we can find a function responsible for
running the proxy in a new thread:
Let’s enter this thread's start routine.
At the beginning, the malware has to load additional DLLs that are going to be used: zlib1
and libssl. The zlib library will be needed for encoding and decoding the gzip
compressed traffic, while libssl will be responsible for certificate management, and
encryption of HTTPS traffic. Both of those libraries are among the modules of the malware,
and they are going to be loaded in the same manner as others: decrypted from the
encrypted module, and then manually loaded.
After this initial step is done, malware tries to find and load the certificate that was
previously installed. It is also saved in the encrypted form. If loading the certificate was not
successful, it will try to generate a new one, and then save it in the appropriate data
container.
-----
After the certificate is initialized, the malware will run the local proxy server, using this
certificate for traffic encryption.
After that it will read and delete the cache of Firefox, and of Chrome.
-----
While in Chrome and Internet Explorer the validation of certificates is performed via
hooking, in Firefox it cannot be implemented in the same way. That’s why, in this case, the
certificate will be just installed in the local store. First malware enumerates the certificates
that are already in the store, to check if the installation is required. If the malware’s
certificate was not found, it will drop and run certutil.exe that performs the installation.
The installation is run in a loop that is executed till success.
-----
We can see the certutil commands being deployed here - the same that we observed during
behavioral analysis.
-----
```
9b2b0,"\certutil.exe"
9b250,"cert9.db"
9b2d0,"\"%s\" -A -n \"%s\" -t \"C,C,C\" -i \"%s\" -d \"%s\""
9b330,"\"%s\" -A -n \"%s\" -t \"C,C,C\" -i \"%s\" -d sql:\"%s\""
```
The dropped certificate is being added into Firefox's cert9.db.
-----
**Inside the proxy**
Two parallel threads are run, one serving as a proxy for HTTP, and another for HTTPS
traffic.
The proxy parses the traffic that passes through - that’s why it needs to decompress the
responses that are gzip compressed. After parsing (and eventually modifying, in case of
webinjects) it is compressed back.
-----
The grabbed content is being stored in the report that is first saved into a local file (using
appropriate path in %APPDATA%, from the malware’s directory structure).
Those files are then uploaded to the C2, by another thread.
### Stealer functionality
In addition to grabbing information directly from the browsers via MITB attack, this bot
can work as a classic stealer, retrieving and uploading the data saved on the disk. The
stolen data is copied into a report, which is further uploaded to the C2.
One of the threads run by the main function is responsible for stealing cookies, saved
credentials, and files. The actions that are accumulated in this thread, can be also executed
separately, on demand, by deploying dedicated remote commands.
-----
Since the early versions of the bot, the cookies and credentials were stolen from Firefox
and Chrome. Newer versions introduced improvements, by supporting Chrome version 80
and above, and also targeting Outlook credentials.
The described analysis of this functionality will be focused on version 1.2.23, which was
the latest at the time of writing.
Since in the process of stealing the local SQL databases are going to be queried, the bot has
to load its sqlite3.dll. It is done at the beginning of the stealing function:
If the loading of this module has failed, the stealing will not continue, and the information
about the failed attempt will be saved in the report which is going to be uploaded to the C2.
**Stealing from Outlook**
A new addition to the bot is the capability of stealing outlook credentials.
-----
[The presented methods are similar to the ones described here. The relevant registry keys](https://securityxploded.com/outlookpasswordsecrets.php)
being queried:
```
696e0,"Software\Microsoft\Internet Account Manager\Accounts"
69750,"Identities"
696e0,"Software\Microsoft\Internet Account Manager\Accounts"
69766,"Outlook"
69780,"Software\Microsoft\Internet Account Manager"
697e0,"\Accounts"
69800,"Software\Microsoft\Office\Outlook\OMI Account Manager\Accounts"
69880,"Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging
Subsystem\Profiles\Microsoft Outlook Internet Settings"
69970,"Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging
Subsystem\Profiles\Outlook"
69a30,"Software\Microsoft\Office\15.0\Outlook\Profiles\Outlook"
69766,"Outlook"
```
**Stealing Chrome passwords**
The malware steals saved Chrome credentials. First, it searches the \Google\Chrome\User
```
Data directory.
```
The retrieved database is queried by the following SQL query:
```
select `origin_url`, `username_value`, `password_value` FROM logins
```
-----
The URL, username, and password are saved into the report that is further uploaded to the
C2.
In the version 1.0.8 of the bot (the previous analyzed), only one method was used for
decoding the password. It just retrieved the data from Login Data and decrypted it with
the DPAPI encryption system.
-----
Decrypting the password:
Since this method doesn’t work for the Chrome >= v80, no surprise that the author pushed
the update in the next releases.
Following the update in Chrome, first the encryption key must be retrieved from Local
```
State (more details described here). The encrypted_key is fetched from JSON.
```
-----
Currently two methods for decrypting the passwords are used: DPAPI encryption system
for the older Chrome versions, and AES256-GCM algorithm for the newer.
-----
[The retrieval of the Chrome passwords is similar to the one described here.](https://xenarmor.com/how-to-recover-saved-passwords-google-chrome/)
**Stealing Chrome cookies**
Stealing of the Chrome cookies again starts by searching the \Google\Chrome\User Data
directory. When found, the Cookies file is retrieved.
-----
The retrieved database is queried with the following SQL query:
```
select `host_key`, `name`, `encrypted_value`, `path`, `expires_utc`, `is_secure`,
`is_httponly` from `cookies`
```
As it was in case of passwords, also in case of cookies the decryption will differ in old and
new (>=80) versions of Chrome. Decoding of cookies follows analogical paths: the updated
bot will use DPAPI encryption system for the older Chrome versions, and AES256-GCM
algorithm for the newer.
In order to not block access to the files, the Chrome process may be terminated.
-----
**Stealing Firefox cookies**
The other targeted browser is Firefox. The template of the stealing function is similar like
in the case of Chrome. First the directory is being searched. This time it is
```
\Mozilla\Firefox\Profiles. The name of the file containing the SQL database with
```
cookies is cookies.sqlite.
-----
The retrieved database is queried with the following SQL query:
```
select `host`, `name`, `value`, `path`, `expiry`, `isSecure`, `isHttpOnly`,
`sameSite` from `moz_cookies`
```
**Stealing files**
Stealing files is deployed in a new thread.
First the list of all the dives is being fetched:
Then, for each drive a new thread is being deployed, responsible for searching files at this
drive.
-----
Among the targets are wallets for cryptocurrencies:
But also documents, that are searched by extensions: .txt, .docx, .xls
-----
The files are first copied to the directory in the %TEMP% folder, and further uploaded by
another thread.
-----
The function for stealing documents didn’t seem to evolve across the compared versions.
## Comparison
As mentioned before, the described Silent Night Zbot is based on ZeuS legacy. There is an
ongoing naming confusion between this Zbot and the other ZeuS-based malware that have
been popular in recent years, such as Sphinx or Terdot.
In this chapter we will sum up the most important similarities and differences between
those specific families.
The reference material:
1. The classic ZeuS source-code
2. The Terdot analysis papers:
- [Terdot: Zeus-based malware strikes back with a blast from the past - by Bogdan](https://labs.bitdefender.com/2017/11/terdot-zeus-based-malware-strikes-back-with-a-blast-from-the-past/)
Botezatu and Eduard Budaca from Bitdefender
- [Zbot with legitimate applications on board - by Hasherezade from Malwarebytes](https://blog.malwarebytes.com/cybercrime/2017/01/zbot-with-legitimate-applications-on-board/)
3. Terdot Zbot samples:
- 611d0954c55a7cb4471478763fe58aa791dc4bbf345d7b5a96808e6d1d264f96 loader (unpacked)
– bd44645d62f634c5ca65b110b2516bdd22462f8b2f3957dbcd821fa5bdeb38a2
- payload.dll
– f76e614723432398d1b7d2c4224728204b3bd9c5725e8200a925e8cbf349344
c - client32.dll
4. ZeuS Sphinx samples:
- 07ff5290bca33bcd25f479f468f9a0c0371b3aac25dc5bb846b55ba60ca658ed original sample (packed)
– 2890ba2b242191f762e8f480a854d4b8985593935157026f3984df07071d8b6
3 - unpacked core
– 4c150ec8583d9455eb6f64020bb8dbe0267ba94e76e5c19e9c2389457979f103
- Tor module
### Silent Night (SN) vs classic ZeuS
Similarities:
- Definitions of webinjects typical for ZeuS
- Similar set of commands, and their format
- Similar format of configuration storage
- [Similar pseudo-random names generator](https://github.com/hshrzd/Zeus/blob/translation/source/common/malwaretools.cpp#L21)
- [Usage of RC4, CRC32, Visual Encrypt](https://github.com/hshrzd/Zeus/blob/translation/source/common/crypt.cpp)
- [Encrypted strings - separate function for ANSI and Unicode. Yet, the algorithm in](https://github.com/hshrzd/Zeus/blob/c55a9fa8c8564ec196604a59111708fa8415f020/source/client/cryptedstrings.cpp#L285)
[ZeuS code is different from the one used in Silent Night.](https://github.com/hshrzd/Zeus/blob/c55a9fa8c8564ec196604a59111708fa8415f020/source/client/cryptedstrings.cpp#L285)
- Usage of random padding
- Hook on TranslateMessage in order to deploy on-click screenshot and keylogging
-----
- Hooks in NtCreateThread and NtCreateUserProcess for the purpose of propagation
into new processes
- Functionality: backconnect, VNC
- Similar server-side backconnect component
In the leaked ZeuS version (2.0.8.9), the cookie stealing component is not implemented,
however the code contains a placeholder for it, while both Silent Night and Terdot have it
implemented.
The original ZeuS code also contains API hooks that are not present in Silent Night.
### Sphinx overview
[Sphinx is a Zbot using Tor. It’s first version (1.0.0.0) was released in 2015. The sample that](https://securityaffairs.co/wordpress/39592/cyber-crime/sphinx-variant-zeus-trojan.html)
we used for the comparative analysis
[(07ff5290bca33bcd25f479f468f9a0c0371b3aac25dc5bb846b55ba60ca658ed), tries to](https://www.virustotal.com/gui/file/07ff5290bca33bcd25f479f468f9a0c0371b3aac25dc5bb846b55ba60ca658ed/detection)
connect to the URL: kdsk3afdiolpgejs.onion/sphinx/config.bin in order to fetch config.
[It doesn’t use API obfuscation. Strings are obfuscated by the algorithms typical for ZeuS.](https://github.com/hshrzd/Zeus/blob/c55a9fa8c8564ec196604a59111708fa8415f020/source/client/cryptedstrings.cpp#L285)
In contrast to Silent Night, and Terdot, Sphinx doesn’t need to download the main
component - it is shipped directly inside the initial executable. In the .data section of the
module, there is yet another PE - UPX packed (used for Tor connections). This is a very
different model than in case of Silent Night, where each and every module is downloaded
from the C2, and then kept in a separate, encrypted file.
The main component
[(2890ba2b242191f762e8f480a854d4b8985593935157026f3984df07071d8b63) is](https://www.virustotal.com/gui/file/2890ba2b242191f762e8f480a854d4b8985593935157026f3984df07071d8b63/detection)
injected into explorer.exe (differently than Silent Night, where it is injected into
msiexec.exe). Sphinx runs and infects two instances of explorer.exe.
One of the instances is run without any parameters. The other’s command-line is:
```
explorer.exe socksParentProxy=localhost:9050 - suggesting that this instance is
```
connecting to the local proxy at the given port. Indeed we can find this port open in the first
instance.
As most of the ZeuS based malware, it uses %APPDATA% as its base directory. It creates
there subfolders:
-----
The directories in %APPDATA% are used for the purpose of keeping its modules, as well as
the stolen data, in encrypted form.
-----
As in the case of Silent Night and Terdot, it creates the key under
```
HKCU\Software\Microsoft.
```
The original sample is copied into a new folder created in %APPDATA%, and the original
copy is deleted by a batch file, dropped in a %TEMP% directory (i.e. tmp07810f8b.bat).
```
@echo off
:d
del "C:\Users\tester\Desktop\.exe"
if exist "C:\Users\tester\Desktop\.exe" goto d
del /F "C:\Users\tester\AppData\Local\Temp\tmp07810f8b.bat"
```
Persistence is achieved by the registry key, leading to the copy of the original sample,
dropped in the new directory, in %APPDATA%.
Once it is run, it injects the main bot into other processes, and hooks API. The hooking done
by Sphinx is very invasive - many more API hooks are being installed than in case of Terdot
or Silent Night. The listing of detected hooks is given below.
-----
[Hooks found](https://github.com/hasherezade/pe-sieve/wiki/3.1.-Investigating-hooks-and-patches) in explorer.exe:
Redirections to the main component of the malware, injected at 1830000:
In ntdll.dll:
```
45778;NtCreateUserProcess->19f4ed5[19e0000+14ed5:(unnamed):1];5
622b8;LdrLoadDll->19f4ffe[19e0000+14ffe:(unnamed):1];5
```
In ws2_32.dll
```
3918;closesocket->19f5ed8[19e0000+15ed8:(unnamed):1];5
4406;WSASend->19f5f31[19e0000+15f31:(unnamed):1];5
6f01;send->19f5f10[19e0000+15f10:(unnamed):1];5
```
In wininet.dll:
```
1a33e;HttpQueryInfoA->19f7d16[19e0000+17d16:(unnamed):1];5
1ab49;InternetCloseHandle->19f7c1e[19e0000+17c1e:(unnamed):1];5
1b406;InternetReadFile->19f7c61[19e0000+17c61:(unnamed):1];5
25e5d;InternetQueryDataAvailable->19f7cea[19e0000+17cea:(unnamed):1];5
2ba12;HttpSendRequestW->19f7a3e[19e0000+17a3e:(unnamed):1];5
34a3d;HttpSendRequestExW->19f7ae6[19e0000+17ae6:(unnamed):1];5
4ae46;InternetReadFileExA->19f7ca0[19e0000+17ca0:(unnamed):1];5
91812;HttpSendRequestExA->19f7b82[19e0000+17b82:(unnamed):1];5
918f8;HttpSendRequestA->19f7a92[19e0000+17a92:(unnamed):1];5
```
-----
In crypt32.dll
```
90ddc;PFXImportCertStore->19f536e[19e0000+1536e:(unnamed):1];5
```
_This hook in crypt32.PFXImportCertStore is present in original ZeuS code, but neither in_
_Terdot, nor in Silent Night._
In user32.dll
```
476b;SwitchDesktop->19f6933[19e0000+16933:(unnamed):1];5
5c39;OpenInputDesktop->19f68e3[19e0000+168e3:(unnamed):1];5
6293;RegisterClassExA->19f6d41[19e0000+16d41:(unnamed):1];5
9dc7;GetCapture->19e9a62[19e0000+9a62:(unnamed):1];5
a4b3;GetCursorPos->19e9934[19e0000+9934:(unnamed):1];5
a575;GetUpdateRect->19eb6e5[19e0000+b6e5:(unnamed):1];5
bb1c;DefWindowProcA->19f6997[19e0000+16997:(unnamed):1];5
bc6a;RegisterClassA->19f6ca2[19e0000+16ca2:(unnamed):1];5
ed4a;RegisterClassW->19f6c55[19e0000+16c55:(unnamed):1];5
10162;RegisterClassExW->19f6cef[19e0000+16cef:(unnamed):1];5
11899;GetMessageA->19e9b29[19e0000+9b29:(unnamed):1];5
119a5;PeekMessageA->19e9b7c[19e0000+9b7c:(unnamed):1];5
11b3c;CallWindowProcW->19f6b87[19e0000+16b87:(unnamed):1];5
12d57;GetDCEx->19eb5cc[19e0000+b5cc:(unnamed):1];5
14ab7;GetWindowDC->19eb666[19e0000+b666:(unnamed):1];5
1507d;DefWindowProcW->19f6951[19e0000+16951:(unnamed):1];5
15421;ReleaseDC->19eb6a5[19e0000+b6a5:(unnamed):1];5
1544c;GetDC->19eb627[19e0000+b627:(unnamed):1];5
15d14;BeginPaint->19eb51c[19e0000+b51c:(unnamed):1];5
15d42;EndPaint->19eb58c[19e0000+b58c:(unnamed):1];5
1634a;PeekMessageW->19e9b51[19e0000+9b51:(unnamed):1];5
164c7;TranslateMessage->19f1cda[19e0000+11cda:(unnamed):1];5
1cde8;GetMessageW->19e9b01[19e0000+9b01:(unnamed):1];5
22ba7;GetClipboardData->19f1e40[19e0000+11e40:(unnamed):1];5
271e4;DefDlgProcA->19f6a23[19e0000+16a23:(unnamed):1];5
3150a;DefMDIChildProcW->19f6afb[19e0000+16afb:(unnamed):1];5
3152b;DefFrameProcW->19f6a69[19e0000+16a69:(unnamed):1];5
31c07;GetUpdateRgn->19eb778[19e0000+b778:(unnamed):1];5
325b7;DefFrameProcA->19f6ab2[19e0000+16ab2:(unnamed):1];5
325db;DefMDIChildProcA->19f6b41[19e0000+16b41:(unnamed):1];5
32bd3;CallWindowProcA->19f6bd0[19e0000+16bd0:(unnamed):1];5
35bc1;DefDlgProcW->19f69dd[19e0000+169dd:(unnamed):1];5
36703;GetMessagePos->19e9902[19e0000+9902:(unnamed):1];5
36932;SetCapture->19e99b8[19e0000+99b8:(unnamed):1];5
369f2;ReleaseCapture->19e9a12[19e0000+9a12:(unnamed):1];5
4c1b0;SetCursorPos->19e997b[19e0000+997b:(unnamed):1];5
```
In kernel32.dll
```
4273d;GetFileAttributesExW->19f50e7[19e0000+150e7:(unnamed):1];5
```
-----
As we can see, the hooks installed are very different than in case of Silent Night, and they
suggest different mechanics behind this malware.
### Silent Night (SN) vs Terdot
Similarities:
```
C - common for various malware families
Z - found in ZeuS code, common for ZeuS-based malware
T - found in Terdot, but not in original ZeuS code
```
|Category|Silent Night & Terdot|
|---|---|
|Data storage|subkeys in HKCU\Software\Microsoft (T), encrypted files in %APPDATA%\ (Z)|
|Bot ID|in format %s_%08X%08X, generated by the same algorithm: hostname (string) and a number generated with InstallDate and DigitalProductID read from the registry. CRC32 algorithm applied. (Z)|
|Encryption algorithms|Visual Encrypt (Z) and RC4 (Z,C)|
|Key to encrypt files|RC4 context stored in the installation data in the registry|
|Webinjects definitions|ZeuS-styled (Z)|
|MitM proxy|yes, HTTP and HTTPS with a custom certificate (Z,C)|
|installation of the certificate|in Firefox: by certutil.exe, in other browsers: by hooking API|
|Hooks in the browsers|The same APIs hooked within in the browsers, analogical functionality of the hooks (T) : crypt32.CertVerifyCertificateChainPolicy , crypt32.CertGetCertificateChain, ntdll.ZwDeviceIoControlFile - redirect to the local MitM proxy|
|Hook implementation|Using MinHook library [1]|
|Stealing cookies|Chrome , Mozilla - yet, using different queries [2]|
-----
1. Terdot (client32.dll) using MinHook library:
2. Queries used by Terdot versus queries used by Silent Night:
Terdot:
```
select `host_key`, `name`, `encrypted_value` from `cookies`
select `baseDomain`, `name`, `value` from `moz_cookies`
```
Silent Night:
```
select `host_key`, `name`, `encrypted_value`, `samesite`, `path`,
`expires_utc`, `is_secure`, `is_httponly` from `cookies`
select `host`, `name`, `value`, `path`, `expiry`, `isSecure`, `isHttpOnly`,
`sameSite` from `moz_cookies`
```
Differences:
|Category|Silent Night|Terdot|
|---|---|---|
|Persistence|Run key leading to the loader executable (plain PE)|A. Run key leading to the loader executable (plain PE) ; B. Entry in StartMenu leading to the PHP script, which is run by a dropped php.exe. The script deobfuscates and runs the initial component, which is never stored on the disk as a plain PE.;|
|Obfuscation|API, strings, arithmetic operations, added redundant calls|strings (similar algorithm like classic Zeus), many strings are in plain-text|
|SQL module|manually loaded sqlite3.dll|statically linked SQLite|
|SSL module|manually loaded libssl.dll|statically linked OpenSSL|
|Zlib module|manually loaded zlib1.dll|statically linked Zlib 1.2.5|
-----
|Names of components|loader-bot32.dll/.exe, antiemule-loader- bot32.dll/.exe - loader ; bot32/64.dll - core|payload.dll - loader ; client32/64.dll - core|
|---|---|---|
|Injection order|msiexec.exe(bot- loader.exe/.dll) -> msiexec.exe(bot32/64.dll) - > browsers and other processes (bot32/64.dll)|explorer.exe(payload.dll) - >msiexec.exe(client32.dll) -> browsers and other processes (client32.dll)|
|DGA|based on a current date (year, month, day of the week, day); 20 characters long; 32 domains generated|based on a current date (year, month, day); 16 characters long; 128 domains generated; different algorithm than SN|
|Verification of downloaded modules|checksum only|RSA signature, validated with hardcoded public key|
|Targeted browsers|iexplore.exe, chrome.exe, firefox.exe,|iexplore.exe, microsoftedgecp.exe, chrome.exe, opera.exe, firefox.exe, WebKit2WebProcess.exe|
|Watchdog|No|Yes, in explorer.exe|
|Commands|bot_uninstall, user_execute, user_cookies_get, user_cookies_remove, user_passwords_get, user_files_get, user_url_block, user_url_unblock|bot_uninstall, user_execute, bot_httpinject_disable, bot_httpinject_enable, user_url_block, user_url_unblock|
|Heaven’s Gate|Yes, in a separate DLL|Yes, in the main component|
### Comparison summary
Silent Night bot is distinct from Terdot. Yet, the existing similarities go beyond the
similarity that is obvious due to the common ancestor, ZeuS. They both use a model:
Zloader -> Zbot. The core module is being downloaded from the C2, and kept in encrypted
form. Also the way in which they attack browsers has significant overlap: exactly the same
hooks are being set, and the implementation of the intercepting functions is analogical.
There exists a possibility that the author of Silent Night was also familiar with Terdot’s
code, or involved in its development. Those two Zbots have many similarities on a
conceptual level, but in comparison to Terdot, Silent Night is written with focus on
modularity, and well obfuscated.
Sphinx is different from both of them, and probably based on an unrelated fork of ZeuS.
-----
## C2 Communication
_[You can try this yourself by using the zLoader communications Jupyter notebook for CP 1.0.8.](https://github.com/prsecurity/zloader_c2_comms/blob/master/zloader_comms.ipynb)_
### Communication encryption
The bot talks to C2 over an encrypted channel. There are two types of encryption used:
- RC4
- Visual Encrypt
Visual Encrypt is simply XORing each character of the string with the preceding XORed
character:
```
def v_encrypt(data):
_len = len(data)
for x in range(_len):
data[x] = data[x] ^ data[x-1]
return data
```
Regular bot’s communications are encrypted with both RC4 and Visual Encrypt, while the
binaries use plain RC4.
### The message composition
The message contains the header and the body. Currently, the header only stores the md5
hash of the message body.
The body is further split into records. Each record contains a header with the following
fields:
- Record ID
- Unused
- Body Length
- Unused
Example of code creating a complete message:
```
def pack_data(data):
body = []
for record_id, content in data.items():
record_header = struct.pack('IIII', record_id, 0, len(content), 0)
body.append(record_header + content)
finished_body = b''.join(body)
header = b''.join([b'0'*(md5_size), hashlib.md5(finished_body).digest()])
return b''.join([header, finished_body])
```
-----
### Record IDs
Record IDs are randomly generated per panel version and stored in core/gen.php, for
example CP 1.0.18 defines the following fields:
```
COMP_ID_MAX_CHARS = 100
BOTNET_MAX_CHARS = 20
MARKER_MAX_CHARS = 20
GATE_MAX_CHARS = 64
MAX_NUM_GATES = 10
MAX_SRC_PATH = 1000
SBCID_BOT_ID = 10001
SBCID_BOTNET = 10002
SBCID_BOT_VERSION = 10003
SBCID_NET_LATENCY = 10005
SBCID_PING = 10006
SBCID_OS_INFO = 10012
SBCID_LANGUAGE_ID = 10013
SBCID_PROCESS_NAME = 10014
SBCID_PROCESS_USER = 10015
SBCID_IPV4_ADDRESSES = 10016
SBCID_IPV6_ADDRESSES = 10017
SBCID_PROCESS_LIST = 10020
SBCID_DEBUG = 10022
SBCID_INTEGRITY_LEVEL = 10023
SBCID_NUM_MONITORS = 10024
SBCID_MARKER = 10025
SBCID_MD5_BOT = 10026
SBCID_TIMEZONE = 10027
SBCID_NET_INFO = 10028
SBCID_BUILD_ID = 10029
SBCID_MD5_WEBINJECTS = 10030
SBCID_SCRIPT_ID = 11000
SBCID_SCRIPT_STATUS = 11001
SBCID_SCRIPT_RESULT = 11002
SBCID_SCRIPTS = 11003
SBCID_COUNT_SCRIPTS = 11004
SBCID_ADV_SERVERS = 11010
SBCID_WEBFILTERS = 11011
SBCID_WEBINJECTS = 11012
SBCID_HTTP_PROXY = 11013
SBCID_GET_FILE = 11014
SBCID_GET_FILE_VER = 11015
SBCID_INJECT_STATUS = 11016
CSR_BOT_FILE = 1000
CSR_BOT64_FILE = 1001
CSR_LIBSSL_FILE = 1002
CSR_SQLITE_FILE = 1003
CSR_ZLIB_FILE = 1004
CSR_NSS_FILE = 1005
```
-----
```
CSR_BOT32_FILE = 1006
CSR_HVNC32_FILE = 1007
CSR_HVNC64_FILE = 1008
SBCID_LOADER_UPDATE = 11020
SBCID_LOADER_UPDATE_SUCCESS = 11021
SBCID_WEBINJECTS_UPDATE = 11022
SBCID_WEBINJECTS_UPDATE_SUCCESS = 11023
SBCID_LOG_ID = 11030
SBCID_LOG_ID_EXT = 11031
SBCID_LOG_ERR_CODE = 11032
SBCID_LOG_MSG = 11033
SBCID_BC_IP = 11040
SBCID_BC_CLIENTPORT = 11041
SBCID_BC_HVNC_CLIENTPORT = 11042
SBCID_NUM_REPORTS = 100000
SBCID_BOTLOG = 200000
SBCID_BOTLOG_TYPE = 300000
SBCID_SOURCE = 400000
SBCID_TITLE = 500000
SBCID_TIME_SYSTEM = 600000
SBCID_TIME_TICK = 700000
SBCID_TIME_LOCALBIAS = 800000
BLT_UNKNOWN = 0
BLT_HTTP_REQUEST = 1
BLT_HTTPS_REQUEST = 2
BLT_GRABBED_HTTP = 3
BLT_FILE = 5
BLT_COOKIES = 6
BLT_KEYLOGER = 7
BLT_PASSWORD = 8
BLT_SCREENSHOT = 9
BLT_SOFTWARE_MAIL = 10
CSR_POST_MAX_SIZE = 10
CSR_BACKCONNECT_CRYPT_KEY = 0x55
LOG_ID_LOADER_UPDATE = 1
LOG_ID_WEBINJECTS_UPDATE = 3
LOG_ID_INSTALL_NSS_CERT = 4
LOG_ID_CHECK_POST_MAX_SIZE = 5
LOG_ID_BOT_DETECTED = 6
LOG_ID_PELOADER = 7
LOG_ID_PROCESS_INJECT = 8
LOG_ID_STEALER = 9
LOG_ID_COLLECTOR = 10
PROCESS_INTEGRITY_UNKNOWN = 0
PROCESS_INTEGRITY_LOW = 1
PROCESS_INTEGRITY_MEDIUM = 2
PROCESS_INTEGRITY_HIGH = 3
```
-----
Specifically, the following types of messages are processed based on the gate’s logic:
Always set:
- `SBCID_BOT_ID`
- `SBCID_BOTNET`
New Bot:
- `SBCID_OS_INFO`
- `SBCID_BOT_VERSION`
- `SBCID_IPV4_ADDRESSES`
- `SBCID_PROCESS_LIST`
- `SBCID_INTEGRITY_LEVEL`
- `SBCID_NUM_MONITORS`
- `SBCID_MARKER`
- `SBCID_MD5_BOT`
- `SBCID_TIMEZONE`
- `SBCID_WEBINJECTS`
Script Report:
- `SBCID_SCRIPT_ID`
- `SBCID_SCRIPT_STATUS`
- `SBCID_SCRIPT_RESULT`
Report:
- `SBCID_BOTLOG_TYPE`
- `SBCID_SOURCE`
- `SBCID_TITLE`
- `SBCID_BOTLOG`
File request:
- `SBCID_GET_FILE`
- `SBCID_GET_FILE_VER`
Log:
- `SBCID_LOG_ID`
- `SBCID_LOG_ID_EXT`
- `SBCID_LOG_ERR_CODE`
- `SBCID_LOG_MSG`
Ping:
- `SBCID_PING`
-----
### Response padding
To further randomize the signal, each response from the C2 is padded with a random
string:
## Traffic analysis
In this section we will follow a flow of a typical network traffic generated by the Zbot, and
show how to decrypt the particular parts.
### Downloading elements
First, the loader element beacons to the C2, in the attempt to download the core bot. Then,
the core bot is loaded and run. It establishes its own connection with the C2: downloads
further modules, and runs a thread that is responsible for data exfiltration.
-----
The first request sent to the C2 is a beacon. It is encrypted with RC4 (key#2) and Visual
Encrypt. After decryption we can see its content:
It contains the following elements: header, data, and a random buffer (of random size). The
random buffer is used only as a padding. The hash of the data buffer is stored in the header.
The data is composed of records, which carry various meanings. Each record a header, and
is identified by its specific ID. The fragment of the panel’s code responsible for processing it
is given below. The length of the item header is 16 bytes (4 DWORDs).
```
$list = array();
for ($i = HEADER_SIZE; $i < $dataSize; ) {
$k = unpack("L4", substr($data, $i, ITEM_HEADER_SIZE));
$itemSize = $k[3];
$item = substr($data, $i + ITEM_HEADER_SIZE, $itemSize);
$itemId = $k[1];
$list[$itemId] = $item;
$i += (ITEM_HEADER_SIZE + $itemSize);
}
```
In the presented packet the following items are present: Botnet ID, Bot ID, and a ping item
(this request is identified as a ping). Compare the IDs with the complete list available in the
earlier part of this report: C2 Communication: Record IDs.
-----
_Fields marked in red represent the record ID. Fields marked in light blue represent content_
_size. The content size is followed by the content_
After processing the items, the decision is taken should the bot be given C2 response. There
are several criteria used to decide if the bot is blacklisted. The deciding factors are: the
country, the IP, or the bot ID.
```
if (!CheckAllowCountry($country) ||
CheckBlockCountry($country) ||
CheckBlockIp($ipStr) ||
CheckBlockBot($botId))
{
SaveLog("Block bot {$botId}, {$country}, {$ipStr}");
die();
}
```
If the bot was not blacklisted, the C2 responds to the beacon with a buffer that is also
encrypted with RC4 (key#2) and Visual Encrypt. The decrypted content contains a similar
header and eventual data, and is padded with a buffer of random characters:
The presented packet does not carry any data, and is used as a “keep-alive” message for the
bot.
-----
After that the malware sends another request, formatted and encrypted by the same
pattern like the previous one:
This time it is a request for a module:
_Fields marked in red represent the record ID. Fields marked in light blue represent content_
_size. The content size is followed by the content: marked in dark blue._
The C2 responds sending the first PE module. This time the response is encrypted with RC4
only. Decrypted buffer contains the PE per-pended with a 21 bytes long header (containing:
the module ID (DWORD), the module version (DWORD), ? (DWORD), the size of the PE
(DWORD), and the CRC32 of the PE (DWORD) which is used for the verification), and one
NULL byte for padding:
-----
The same cycle (when the malware sends a request, and C2 responds with a particular
module) repeats till all the modules are downloaded.
In between, the bot downloads also a configuration file for the webinjects. This file is
encrypted with RC4 + Visual Encrypt.
-----
[The content of webinjects.txt follows the standard introduced by ZeuS. After the file](https://gist.github.com/hshrzd/7032d8239d76a5512470a2bc3da1d85f#file-webinjects-txt)
content there is a “keep-alive” content appended.
-----
### Data exfiltration
After all the modules are downloaded, the traffic contains mostly the exchange ping-keep
alive, bot’s reports about performed actions, and exfiltrated data. This time the traffic
between the bot and the C2 is all the time encrypted by the same manner as the beacons:
RC4 (key #2) + Visual Encrypt.
Sample overview of the captured traffic:
Each time after the report from the bot was received, C2 responds with a “keep alive”
packet:
Examples of some interesting reports given below.
-----
A path of the target file: Firefox certificate database:
-----
Report about a successful injection into Explorer:
List of active processes:
-----
Information if the Cookies database was not found:
A longer report containing: 1) stolen Firefox cookies
-----
2) a series of screenshots in JPEG format (each screenshot has a fixed size 500 x 500
pixels)
-----
3) the title of the active window:
Those exfiltration operations work in a loop, deployed in one of the threads. In addition to
this, malware can receive and execute commands from the C2, deploying some of those
operations on demand.
## Panel
We will review the latest Control Panel available at the time of writing version 1.0.18 by
installing it locally and looking at its capabilities.
### Installation
Two interesting features to note:
1. Username Admin is constant
2. RC4 encryption key is set during install and remains constant by design (unless
someone changes through DB). This is useful because Zloader samples can be
clustered based on RC4 keys in the same fashion we cluster Emotet samples on public
keys. At the end of this paper we provide a list of all C2s grouped by RC4 keys found in
the samples for the past 4 month.
-----
### Bot config
To experience the panel, we need a bot. The easiest way to get one is to replace the config
in an existing sample. There are two types of payloads that you may encounter, the general
build and unique private builds for premium customers (who pay $4k/month).
-----
For the sample version 1.2.23, the general built has the config at offset 0x29c08 and the
config RC4 key at the offset 0x29ef7:
[Regardless of the version, the config can be easily decoded and replaced with cyberchef.io:](https://gchq.github.io/CyberChef/#recipe=From_Hex('Auto'/disabled/breakpoint)RC4(%7B'option':'UTF8','string':'ydxcqilakhhdexevnzce'%7D,'Hex','Latin1')To_Hexdump(16,true,false)&input=MEYwMzdCRkU1OEI2MEQ1MDQ3OEQwNzIyODU1Q0EwNTY4Qzg4QThCQTI3NDUyMDMxMEUzRTk3RjQ3RTE4MjBEQUIzQ0M1MDg4RkFGNTgwOEN)
-----
### Stats
The statistics window shows typical data points for all malware, such as number of bots,
markers, etc.
-----
### Bots
In addition to the typical bot info, Silent Night also collects network information by running
and saving the output of the following commands:
```
ipconfig /all
net config workstation
net view /all
net view /all /domain
nltest /domain_trusts
nltest /domain_trusts /all_trusts
```
The bot collects the process list, and allows you to launch SOCKS5/HVNC services via its
backconnect server. Interestingly, the port for them is generated at random from C2 and
fed to the bot, so in theory, you can tell the bot to open up any port on the backconnect
server.
-----
### Backconnect
-----
### Tasks
Reports
The reports are geared towards banking theft. The reports could be of HTTP/S traffic, key
logs, screenshots, cookies, passwords and mail. Reports could be filtered by botnets, bots,
titles, keywords and dates. The functionality is somewhat inconvenient, for example there
is now way to go directly from a bot check-in to its reports.
-----
### Webinjects
-----
### Jabber
The panel admin can choose to be notified via Jabber about certain events. Triggers could
be online status of a bot, arrival of any or specific logs from any or specific bots.
### Panel config
The panel configuration is really the bot configuration. Builder address, license key,
timeout and C2 addresses are fairly straightforward. It’s important to note that the bot can
only communicate via HTTP/S, so if your network requires proxy authentication for web
traffic, the bot simply won’t be able to ping back to the C2 (as of version 1.2.25). Thanks to
[sS55752750](https://twitter.com/sS55752750) for pointing this out.
-----
### Domain Generation Algorithm
Newer releases of Silent Night also support a Domain Generation Algorithm.
-----
The DGA is a function of a date (timestamp) and the bot’s encryption key. Below is PHP
code that generates one sample:
```
function dga2($timestamp, $encryption_key) {
$domain = pack("L", $timestamp);
CsrRc4Crypt($domain, $encryption_key);
$ipWPG = unpack("L", $domain);
$packed_timestamp_1 = $packed_timestamp_2 = $ipWPG[1];
$oAXrC = '';
$counter = 0;
while ($counter < 20) {
$char = 97 + abs($packed_timestamp_1 % 25);
$oAXrC .= chr($char);
$packed_timestamp_1 += $char;
if ($packed_timestamp_1 > 0xffffffff) {
$packed_timestamp_1 &= 0xffffffff;
$packed_timestamp_1 ^= $packed_timestamp_2;
++$counter;
} else {
$packed_timestamp_1 ^= $packed_timestamp_2;
++$counter;
}
}
var_dump("{$oAXrC}.com");
}
```
-----
### Builder
Updater
-----
### Blacklist
Users
The Users menu allows for granular user permission management. Potentially, this allows
panel owners to delegate tasks or sell access to their bots, which makes each C2 a
collaborative environment.
-----
The command and control panel is written in PHP. The version that is distributed to the
[clients is obfuscated with YAK Pro.](https://github.com/pk-fr/yakpro-po)
-----
## Conclusion
The bot has been designed using the ZeuS code as a template, yet, a lot of work has been
put into its modification and modernization. Conceptually, it is very close to Terdot, yet
rewritten with an improved, modular design. We don’t have enough data to say if the
author of Silent Night was previously involved in developing Terdot, or just got inspiration
from it. What we can say is that not all similarities among those two come from the
common ancestor, ZeuS.
The design of Silent Night is consistent and clean, the author’s experience shows
throughout the code. Yet, apart from the custom obfuscator, there is not much novelty in
this product. The Silent Night is not any game changer, but just yet another banking Trojan
based on ZeuS.
Based on the analysis of the bot’s configurations, we may confidently say that there is more
than one customer of the “Silent Night”. However, comparing the frequency of new builds
(based on the variations of the config files) and the different level of sophistication between
the actors, we can say that some users are more proficient than others.
Considering the absence of activity on the exploit.in thread where the bot was originally
sold and the success of previous campaigns, we predict with moderate confidence an
evolution of the bot from something that anyone with a budget can buy, into a vehicle for
one group to conduct banking theft at scale.
-----
## Client Clusters and IoCs
By extracting the configs from the samples and clustering the C2 addresses around RC4
keys, we were able to discover 20 unique C2 panels. Below is the list of RC4 keys and
associated C2 addresses.
### 41997b4a729e1a0175208305170752dd
- ldhly[.]com/wp-parser.php
- 185.180.198[.]32/abbyupdater.php
- todiks[.]xyz/milagrecf.php
- liangzizhineng[.]cn/wp-parser.php
- zgpqjzwrb[.]pw/gravitels.php
- lifeprimary[.]site/wp-parser.php
- botiq[.]xyz/milagrecf.php
- nmttxggtb[.]press/wp-config.php
- gdexordsb[.]icu/wp-config.php
- hwbblyyrb[.]pw/wp-config.php
- aquolepp[.]pw/milagrecf.php
- vfgthujbxd[.]xyz/milagrecf.php
- bhajkqmd[.]xyz/milagrecf.php
- heartsmobileautorepair[.]com/redir.php
- hormonas[.]comegico[.]com[.]mx/wp-parser.php
- rswtgmhf[.]pw/wp-config.php
- cristinneese[.]xyz/gravitels.php
- apprdlbtb[.]pw/wp-config.php
- fwgdhdln[.]icu/wp-config.php
- dcaiqjgnbt[.]icu/wp-config.php
- xyajbocpggsr[.]site/wp-config.php
- gynrhcoe[.]pw/wp-config.php
-----
- heartsmobileautorepair[.]com/123.php
- zoraokorol[.]xyz/gravitels.php
- xaprgnve[.]icu/wp-config.php
- www.wuaiwan[.]cn/wp-content/uploads/2020/04/123.php
- eoieowo[.]casa/wp-config.php
- marlodubberly[.]xyz/gravitels.php
- horatiobrotherton[.]xyz/gravitels.php
- dierdreswensson[.]xyz/gravitels.php
- rizoqur[.]pw/milagrecf.php
- home[.]comegico[.]com[.]mx/wp-parser.php
- soficatan[.]site/milagrecf.php
- jewellerydesigns[.]co[.]za/wp-parser.php
- nncpsedsb[.]host/wp-config.php
- wlqaqife[.]icu/wp-config.php
- ooygvpxrb[.]pw/wp-config.php
- kuaxbdkvbbmivbxkrrev[.]com/wp-config.php
- artiealtiery[.]xyz/gravitels.php
- axelerode[.]club/stuck.php
- jzfozxqe[.]site/gravitels.php
- ydmfemfe[.]pw/gravitels.php
- pqayjeenbbt[.]icu/wp-config.php
- nurgsozebt[.]pw/wp-config.php
- axelerode[.]host/stuck.php
- msrtuhctb[.]pw/wp-config.php
- japanjisho[.]info/wp-parser.php
- blazeseher[.]xyz/gravitels.php
- gavrelets[.]ru/wp-parser.php
-----
- dhteijwrb[.]host/milagrecf.php
- brewaz[.]club/milagrecf.php
- verobani[.]website/milagrecf.php
- maxbiler.dk/wp-parser.php
- basorkiq[.]host/milagrecf.php
- ltuywjafbt[.]icu/wp-config.php
- heartsmobileautorepair[.]com/redir.php
- brihutyk[.]xyz/abbyupdater.php
- avnjila[.]website/stuck.php
- dxdeedle[.]host/gravitels.php
- hopime[.]com/wp-parser.php
- twinsors[.]xyz/gravitels.php
- bwambztl[.]xyz/milagrecf.php
- irfanhaber[.]net/wp-parser.php
- rubense[.]xyz/milagrecf.php
- lgepubbf[.]icu/wp-config.php
- 933988[.]com[.]tw/redir.php
- dcgljuzrb[.]pw/wp-config.php
- siloban[.]pw/milagrecf.php
- fflxcsbtb[.]pw/wp-config.php
- tepbfiafbtt[.]pw/wp-config.php
- luckystatus[.]com/wp-parser.php
- lesson.musicentrance[.]com/wp-parser.php
- ch.theblissbinder[.]com/wp-smart.php
- buhjike[.]host/milagrecf.php
- jtppbycsb[.]space/wp-config.php
- glsunzdf[.]casa/wp-config.php
-----
- barbeyo[.]xyz/milagrecf.php
- leaben[.]pw/milagrecf.php
- ajvwdjtebb[.]pw/wp-config.php
- wgyvjbse[.]pw/milagrecf.php
### dvjh7gIy78g3biuh7wgvH8gFJSHF87HI
- 62.109.2[.]250/gate.php
### 34v5436b4356b4564561
- far.spargroarr[.]org/tv/x.php
- roo.purcererya[.]org/tv/x.php
- far.spargroarr[.]org/tv/x.php
- roo.purcererya[.]org/tv/x.php
### s4sd!@dss2QW11sdsdsa
- adslsticker[.]world/click.php
- adslstickerf1[.]world/click.php
- 213.155.31.199/wwp/gate.php
- adslstickerfone[.]world/click.php
- adslstickerf[.]world/click.php
### Dkj9DsjvyAdue
- ffclubs[.]net/erors.php
- iphonexr[.]top/erors.php
- vipstore.pp.ua/erors.php
- vitog502[.]live/erors.php
- iphonexsmax[.]top/erors.php
- vitog502.digital/erors.php
- calife[.]best/erors.php
- happyiphoneusr[.]top/erors.php
- vitog502[.]life/erors.php
- bluecheese[.]top/erors.php
-----
- vitog502[.]world/erors.php
### 326_M*8*~;2s3252G
- www.deephousesets1.de/music.php
- www.eurodancehitslatm.de/music.php
- www.trancepartysets.de/music.php
- www.danceeruohitslatm.de/music.php
### 90f1e19e2306648e9e22059d47f36016
- 45.72.3[.]132/web7643/gate.php
### 03d5ae30a0bd934a23b6a7f0756aa504
- kasfajfsafhasfhaf[.]com/web/gate.php
- dsdjfhdsufudhjas[.]com/web/gate.php
- dsjdjsjdsadhasdas[.]com
- dskdsajdsahda[.]info/gate.php
- kdsidsiadsakfsas[.]com
- dsjadjsadjsadjafsa[.]info/gate.php
- oajdasnndkdahm[.]com/web/gate.php
- kasfajfsafhasfhaf[.]com
- idisaudhasdhasdj[.]com
- kdsidsiadsakfsas[.]com/gate.php
- jdafiasfjsafahhfs[.]com
- fdsjfjdsfjdsdsjajjs[.]info/gate.php
- dksadjsahnfaskmsa[.]com/gate.php
- dsjdjsjdsadhasdas[.]com/web/gate.php
- iloveyoubaby1[.]pro/gate.php
- dasifosafjasfhasf[.]com
- idisaudhasdhasdj[.]com/web/gate.php
- oajdasnndkdahm[.]com/web/gate.php
- fdsjfjdsfjdsjfdjsfh[.]com/web/gate.php
-----
- idisaudhasdhasdj[.]com/gate.php
- dasifosafjasfhasf[.]com/web/gate.php
- dsdjfhd9ddksaas[.]pro/gate.php
- fslakdasjdnsasjsj[.]com/gate.php
- dsdjfhdsufudhjas[.]com/gate.php
- fdsjfjdsfjdsdsjajjs[.]com/web/gate.php
- dskdsajdsadasda[.]info/gate.php
- fdsjfjdsfjdsjfdjsfh[.]com
- 188.127.226[.]197/gate.php
- dsjdjsjdsadhasdas[.]com/gate.php
- oajdasnndkdahm[.]com/gate.php
- idsakjfsanfaskj[.]com/gate.php
- idisaudhasdhasdj[.]info/gate.php
- djsadhsadsadjashs[.]pro/gate.php
- dasifosafjasfhasf[.]com/gate.php
- dsdjfhdsufudhjas[.]pro/gate.php
- oajdasnndkdahm[.]com
- fdsjfjdsfjdsdsjajjs[.]com/gate.php
- kdsidsiadsakfsas[.]com/web/gate.php
- jdafiasfjsafahhfs[.]com/gate.php
- dsdjfhdsufudhjas[.]com
- dsdjfhdsufudhjas[.]info/gate.php
- kasfajfsafhasfhaf[.]com/gate.php
- fsakjdsafasifkajfaf[.]pro/gate.php
- dskjdsadhsahjsas[.]info/gate.php
- jdafiasfjsafahhfs[.]com/web/gate.php
- fdsjfjdsfjdsjfdjsfh[.]com/gate.php
-----
- fdsjfjdsfjdsdsjajjs[.]com
### M9ihiu7887n78n
- bdr.ubibancaa[.]host/stat.php
- bdr.ubibancaa[.]website/stat.php
- 185.185.24[.]49/gate.php
- bdr.ubibanca[.]pro/stat.php
- bdr.ubibancaa[.]space/stat.php
- bdr.ubibanca[.]xyz/stat.php
- bdr.ubibancaa[.]fun/stat.php
### hZRk7754w3VPlf
- dij49jf39fjd340d[.]com/jbYm9bt/NlGkb4ivk.php
- qwd8s3j8s23h8s[.]com/jbYm9bt/NlGkb4ivk.php
- sldeodjiweiswi[.]com/jbYm9bt/NlGkb4ivk.php
- 23d8s23hs89j239sj23[.]com/jbYm9bt/NlGkb4ivk.php
- 40j9f2j9sj32ssoj[.]com/jbYm9bt/NlGkb4ivk.php
- idjwidj8f4f5ge[.]com/jbYm9bt/NlGkb4ivk.php
- 4f394j89d3j4d89j34d[.]com/jbYm9bt/NlGkb4ivk.php
- 238ehs823s8h23[.]com/jbYm9bt/NlGkb4ivk.php
- s28hs823hs823js[.]com/jbYm9bt/NlGkb4ivk.php
- js823hs23js[.]com/jbYm9bt/NlGkb4ivk.php
- d823hrd9239sdj2[.]com/jbYm9bt/NlGkb4ivk.php
- sifeiwdjiesde[.]com/jbYm9bt/NlGkb4ivk.php
- ifjedssofllvcr[.]com/jbYm9bt/NlGkb4ivk.php
- wd23h8qsh8qhs823qs[.]com/jbYm9bt/NlGkb4ivk.php
- 3reh8rd23js9[.]com/jbYm9bt/NlGkb4ivk.php
- d9j49dj923993[.]com/jbYm9bt/NlGkb4ivk.php
- isfjiaaodwsoi[.]com/jbYm9bt/NlGkb4ivk.php
-----
- oidjweidj34rd3[.]com/jbYm9bt/NlGkb4ivk.php
- mslfiedjssfdes[.]com/jbYm9bt/NlGkb4ivk.php
### 981ojqJqpMamw2K2m191b742jq
- j2888hennene[.]site/library/topikpost.php
- islacangrejo[.]fun/library/topikpost.php
- hostww.enne/gate1.php
- hahwuUmkwioq[.]site/library/topikpost.php
- thoughtlibrary[.]top/library/topikpost.php
- host.ff/gate1.php
- gertibaeronjdkwp[.]site/library/topikpost.php
### f0feba219b4c1b7fc383fd65880dae50
- representis[.]xyz/gate.php
- representis[.]icu/gate.php
### fkdoue9g3WE#g3233dgfd
- givlonest[.]org/tv.php
- givlonest[.]com/tv.php
### kZieCw23gffpe43Sd
- rehoterv[.]org/sound.php
- hustlertest[.]com/sound.php
- penaght[.]org/sound.php
- brosmasters[.]com/sound.php
- teslatis[.]org/sound.php
- lonehee[.]com/sound.php
- polild[.]org/sound.php
- chorbly[.]org/sound.php
- 2.57.38.157/sound.php
- 217.138.205.135/sound.php
- postgringos[.]com/sound.php
-----
- tarsilh[.]com/sound.php
- soceneo[.]com/sound.php
- nexycombats[.]com/sound.php
- banssa[.]org/sound.php
- mioniough[.]com/sound.php
- sigmark[.]org/sound.php
- horcinx[.]org/sound.php
- dandycodes[.]com/sound.php
- smoash[.]org/sound.php
- adird[.]org/sound.php
- sandyfotos[.]com/sound.php
- penaght[.]org/sound.php
- unwer[.]org/sound.php
- dolax[.]org/sound.php
- hesaista[.]org/sound.php
- tilyn[.]org/sound.php
- 162.241.70.164/sound.php
- weako[.]org/sound.php
- welefus[.]com/sound.php
- gilantec[.]org/sound.php
- rutom[.]org/sound.php
- coult[.]org/sound.php
- footmess[.]com/sound.php
- finuclier[.]com/sound.php
- flopperos[.]org/sound.php
- tarynak[.]org/sound.php
- detid[.]org/sound.php
-----
- zernel[.]org/sound.php
- purots[.]com/sound.php
- 185.236.202.226/sound.php
- milsop[.]org/sound.php
- hibsurf[.]com/sound.php
- knalc[.]com/sound.php
- pacallse[.]com/sound.php
- greenrumba[.]com/sound.php
- imosey[.]com/sound.php
- perditta[.]org/sound.php
- hinurs[.]org/sound.php
- banog[.]org/sound.php
- loots[.]org/sound.php
- norpy[.]org/sound.php
- zonaa[.]org/sound.php
- shatskie[.]org/sound.php
- surgued[.]com/sound.php
- rarigussa[.]com/sound.php
- aracp[.]org/sound.php
- evahs[.]org/sound.php
- eirry[.]org/sound.php
- lildor[.]com/sound.php
- rayonch[.]org/sound.php
- retualeigh[.]com/sound.php
- adran[.]org/sound.php
- ginibenio[.]com/sound.php
- bluslias[.]com/sound.php
-----
- calul[.]org/sound.php
- vanagitah[.]com/sound.php
- cersubego[.]com/sound.php
- obeaf[.]com/sound.php
- ficutept[.]com/sound.php
- 185.236.202.235/sound.php
- 51.83.171.27/sound.php
- adandore[.]com/sound.php
- peermems[.]com/sound.php
- buhismus[.]com/sound.php
- vacontd[.]com/sound.php
- maremeo[.]com/sound.php
- 185.236.202.146/sound.php
- gorab[.]org/sound.php
- geost[.]com/sound.php
- smeack[.]org/sound.php
- airnaa[.]org/sound.php
- dentatox[.]org/sound.php
- ciconuati[.]com/sound.php
- finib[.]org/sound.php
- smenard[.]com/sound.php
- spensores[.]com/sound.php
- itachaphi[.]com/sound.php
- starterdatas[.]com/sound.php
- ergensu[.]com/sound.php
- pitinjest[.]org/sound.php
- pitinjest[.]org/sound.php
-----
- ronswank[.]com/sound.php
- klill[.]com/sound.php
- 217.138.205.159/sound.php
- tetraslims[.]com/sound.php
- grually[.]com/sound.php
- giril[.]org/sound.php
- lotio[.]org/sound.php
- naght[.]org/sound.php
- baatiot[.]com/sound.php
- stagolk[.]com/sound.php
- 162.241.115.242/sound.php
- etized[.]org/sound.php
- veckeard[.]com/sound.php
- rhald[.]org/sound.php
- disrelure[.]com/sound.php
- zelacarths[.]com/sound.php
- trebitmore[.]org/sound.php
- spardanos[.]com/sound.php
- invesund[.]org/sound.php
- tirdo[.]org/sound.php
- emearibys[.]com/sound.php
- watae[.]org/sound.php
- 217.138.205.136/sound.php
- namilh[.]com/sound.php
- fotonums[.]com/sound.php
- teamper[.]org/sound.php
- sentspiels[.]com/sound.php
-----
- fibulu[.]org/sound.php
- adobe[.]com/sound.php
- postxer[.]com/sound.php
- kodray[.]org/sound.php
- pheia[.]com/sound.php
- lipurf[.]com/sound.php
- bunap[.]org/sound.php
- tremood[.]com/sound.php
### Ts72YjsjO5TghE6m
- shotroot[.]xyz/data.php
### JuXbeO5P20ewnefR4LZ81NIOZIc80IN
- 124331[.]com/success.php
- 209711[.]com/process.php
- baj3tu[.]xyz/image.php
- mayinakh[.]xyz/plugins.php
- 106311[.]com/comegetsome.php
- baj3tu[.]xyz/thread.php
- 105711[.]com/docs.php
### q23Cud3xsNf3
- april30x3domain[.]com/post.php
- iawfqecrwohcxnhwtofa[.]com/post.php
- nmqsmbiabjdnuushksas[.]com/post.php
- cmmxhurildiigqghlryq[.]com/post.php
- march262020[.]store/post.php
- march262020[.]best/post.php
- pwkqhdgytsshkoibaake[.]com/post.php
- march262020[.]site/post.php
- march262020[.]tech/post.php
-----
- onfovdaqqrwbvdfoqnof[.]com/post.php
- ojnxjgfjlftfkkuxxiqd[.]com/post.php
- marchadvertisingnetwork3[.]com/post.php
- marchadvertisingnetwork6[.]com/post.php
- fyratyubvflktyyjiqgq[.]com/post.php
- wmwifbajxxbcxmucxmlc[.]com/post.php
- nmqsmbiabjdnuushksas[.]com/post.php
- marchadvertisingnetwork[.]com/post.php
- march262020[.]club/post.php
- april30domain[.]com/post.php
- marchadvertisingnetwork10[.]com/post.php
- marchadvertisingnetwork9[.]com/post.php
- march262020[.]network/post.php
- cmmxhurildiigqghlryq[.]com/post.php
- fvqlkgedqjiqgapudkgq[.]com/post.php
- march262020[.]online/post.php
- marchadvertisingnetwork4[.]com/post.php
- marchadvertisingnetwork8[.]com/post.php
- marchadvertisingnetwork2[.]com/post.php
- march262020[.]live/post.php
- fyratyubvflktyyjiqgq[.]com/post.php
- march262020[.]com/post.php
- marchadvertisingnetwork5[.]com/post.php
- snnmnkxdhflwgthqismb[.]com/post.php
- nlbmfsyplohyaicmxhum[.]com/post.php
- marchadvertisingnetwork7[.]com/post.php
-----
### 82732qpweiowe82782732qpweiowe827
- erbscactus[.]at/noagate.php
- representis[.]icu/noagate.php
- interurbanpu[.]at/noagate.php
- representis[.]xyz/noagate.php
### das32hfkAN3R2TCS
- czadvokat[.]info/gate.php
- 195.154.119[.]165/gate.php
- akrisko[.]info/gate.php
- penaz[.]info/gate.php
- advokat-hodonin[.]info/gate.php
### Dg3k4u3rUyEwXQsak4u3rU
- insceos[.]com/post.php
- grimberks[.]com/post.php
- monbrase[.]com/post.php
- plemopomps[.]com/post.php
- pearlsolutionis[.]com/post.php
- onregcan[.]com/post.php
- pressrealbox[.]com/post.php
-----
## About us
Malwarebytes
Malwarebytes is a cybersecurity company that millions worldwide trust. Malwarebytes proactively protects
people and businesses against malicious threats, including ransomware, that traditional antivirus solutions
miss. The company’s flagship product uses signature-less technologies to detect and stop a cyberattack before
[damage occurs. Learn more at www.malwarebytes.com.](http://www.malwarebytes.com/business)
HYAS
Founded by a team of world-renowned security researchers, analysts and entrepreneurs, HYAS enables
enterprises to detect and mitigate cyber risks before attacks happen and identify the adversaries behind
them. HYAS Insight is a threat intelligence and attribution platform that improves visibility and productivity
for analysts, researchers and investigators while vastly increasing the accuracy of their findings. HYAS Protect
uses domain-based intelligence and attribution at the DNS layer to proactively and preemptively protect
enterprises from cyberattacks, independent of protocol or attack vector. Utilized by multiple Fortune 100
enterprises, HYAS fundamentally changes how companies counter, hunt, find, and identify adversaries,
enabling a proactive approach that allows enterprises to identify adversaries specifically targeting them. For
[more information about HYAS, visit www.hyas.com.](https://www.hyas.com/)
Copyright © 2020, Malwarebytes. All rights reserved. Malwarebytes and the Malwarebytes logo are
trademarks of Malwarebytes. Other marks and brands may be claimed as the property of others. All
descriptions and specifications herein are subject to change without notice and are provided without
warranty of any kind.
-----