Today we are going to talk about one of the biggest threats that is spreading in these days, in particular in Italy: Dreambot, the most recent version of a malware also known as Ursnif, or Gozi.
Summary
- The Threat
- The Check-In phase
- Encryption routine
- Injected Internet Explorer? Or not?
- Conclusion
Ursnif belongs to the category of Infostealers. It was already analyzed by a lot of skilled researchers. I list just some of the best analysis you could find:
In this article, we'll focus on the initial communication with the Command & Control infrastructure.
At the time of the compilation of the malware, spreaders can choose a list of domains that will be hardcoded in the sample in an encrypted form.
For example, the following image shows 3 different domains uploaded into the memory of one of the variant that we analyzed.
The malicious agent tries to perform its initial communication with the first of the list, then, if it fails, it would try with the next and so on.
We underline that this "beacon" is always performed via plain HTTP while the following steps of communication are done via SSL encryption and custom certificates.
This is important because, with the right eye, even without SSL interception, we can pretty easily spot if something is going wrong.
The following image shows 3 different attempts to communicate with the C2 server in a sandbox environment.
If the pattern is not known, an untrained analyst could be misleaded by this behaviour while performing threat hunting on network logs or artifacts.
The file extension ".avi" refers to video files. Also, the path "/images/" is deceptive. In addition, it's performed as a "GET" request. All of this evidence could be seen as a normal download of a video file from a site hosting media. In fact it's the check-in of the malware that is sending basic information about the compromised machine, hiding them in plain sight in the URI path.
Example:
Decoded data:
- fjidtflrb -> junk param, always present at the start of the URI to generate randomness (and always different)
- soft -> major version
- version -> minor version
- user -> unique user id
- server -> unique c2 server id
- id -> bot group id
- crc -> payload to retrieve (1-DLL 32bit, 2-DLL64 bit, 3-ps1)
- uptime -> time elapsed from initial infection (seconds)
The following image represents the phase when the malware creates the first parameter:
After having seen a lot of this kind of patterns on Ursnif samples in last years, I decided to create a simple and raw tool that is able to decrypt the URL created by the malware on the fly.
In this way it's possible to spy the configuration sent to the Command & Control server and, at the same time, to check if the URL is related to this threat.
All of this without any need of manual reverse engineering.
You can check the simple tool that I created on the following link on: GitHub
This is an example of how to run the script:
and the related output:
The custom algorithm starts with a symmetric encryption that leverages the Serpent cipher in CBC mode and a null IV (initialization vector).
Afterwards the result is encoded with a classic base64. Considering that base64 encoding is pretty easy to spot, malware authors decided to change things a little more. They removed padding characters("=") and substituted the other special characters ("+", "/") with the relative ASCII code, after having prepended them by an underscore ("_2f", "_2b"). The last tweak is to add slashes at specified offsets to let the URI to appear like a real one.
Obviously, the Serpent encryption needs a key. We can find it hardcoded on the malware sample. Some code level analysis could be required to get that info.
However, observations led to the fact that the key is usually shared among a lot of samples and rarely changed.
If you don't have one, just run the script: it would try a predefined list of known keys for you.
It's really appreciated if you want to share new keys that you find with us. Feel free to contact us on Twitter or LinkedIn
While investigating the check-in phase, we noticed an unusual fact that we think it's worth to mention.
As you can see from the analysis of AnyRun , the malicious beacon seems to be sent by an Internet Explorer instance after the malware has run.
Considering that Ursnif is known to perform injection on browsers to steal information, an unaware analyst could think that the malware already decided to perform some form of memory injection into a new spawned instance of Internet Explorer to masquerade the communication as a legit one.
However this is unecessary. It's enough to use the COM (Wikipedia) library that is provided by Microsoft. Looking at the code, we can detect this behaviour with the finding of the function CoCreateInstance that were made just before the network communication.
This one is a stealthy way that could mislead both analysts and security products if it has not been taken in consideration.
If you like to have a more detailed explanation on COM and, in general, on how to detect malware C2 communications while reverse engineering, I suggest the following reading: FireEye Blog
Ursnif has been trying for years to make analysis difficult for people and detection for security products.
We went deep into the communication performed during the check-in phase and created a new tool to help to analyze and detect the malware.
Certego is actively monitoring every day threats to improve its detection and response methods, continuously increasing the effectiveness of the incident response workflow.
8793af5f5ad8a2ca9b2ae6af5e70e63f
8f0195472ede691b129913465eec0c9e
If you know something more about protocols used by Ursnif for C2 communications or if you'd like to improve the tool(GitHub), feel free to contact me at any time.