Zscalerのブログ

Zscalerの最新ブログ情報を受信

購読する
Security Research

Lyceum .NET DNS Backdoor

NIRAJ SHIVTARKAR, AVINASH KUMAR
June 09, 2022 - 10 分で読了

Active since 2017, Lyceum group is a state-sponsored Iranian APT group that is known for targeting Middle Eastern organizations in the energy and telecommunication sectors and mostly relying on .NET based malwares. 

Zscaler ThreatLabz recently observed a new campaign where the Lyceum Group was utilizing a newly developed and customized .NET based malware targeting the Middle East by copying the underlying code from an open source tool.

 

Key Features of this attack:

 

  1. The new malware is a .NET based DNS Backdoor which is a customized version of the open source tool “DIG.net
  2. The malware leverages a DNS attack technique called "DNS Hijacking" in which an attacker- controlled DNS server manipulates the response of DNS queries and resolve them as per their malicious requirements.
  3. The malware employs the DNS protocol for command and control (C2) communication which increases stealth and keeps the malware communication probes under the radar to evade detection.
  4. Comprises functionalities like Upload/Download Files and execution of system commands on the infected machine by abusing DNS records, including TXT records for incoming commands and A records for data exfiltration. 

 

Delivery mechanism

 

During this campaign, the macro-enabled Word document (File name: ir_drones.docm) shown below is downloaded from the domain “http[:]//news-spot.live” disguising itself as a news report related to military affairs in Iran. The text of the document is copied from the following original report here: https[:]//www[.]rferl[.]org/a/iran-drone-program-threats-interests/31660048.html

 

Image

Fig 1. Attached Macro-enabled Word Document

 

Once the user enables the macro content, the following AutoOpen() function is executed which increases picture brightness using “PictureFormat.Brightness = 0.5” revealing content with the headline, “Iran Deploys Drones To Target Internal Threat, Protect External Interests.”

 Image

Fig 2. AutoOpen() function revealing content to lure the victims

 

The threat actor then leverages the AutoClose() function to drop the DNS backdoor onto the system. Upon closing the document the AutoClose() function is executed, reading a PE file from the text box present on the 7th page of the word document and parsing it further into the required format as shown below with the “MZ” header as the initial two bytes of the byte stream.

 

Image

Fig 3. AutoClose() function reading the PE File

This PE file is then further written into the Startup folder in order to maintain persistence via the macro code as shown below in the screenshot. With this tactic, whenever the system is restarted, the DNS Backdoor is executed. 

Image

Fig 4. DNS Backdoor dropped in the Startup folder


The dropped binary is a .NET based DNS Backdoor named “DnsSystem” which allows the threat actors to execute system commands remotely and upload/download data on the infected machine.

Below, we analyze the dropped .NET based DNS Backdoor and its inner workings.


 

Lyceum .NET DNS backdoor

The Lyceum Group has developed a .NET based DNS Backdoor which has been widely used in the wild in their recent campaigns. As discussed earlier, the backdoor was dropped in the Startup folder of the infected system from a Macro Enabled Word document.

md5: 8199f14502e80581000bd5b3bda250ee

Filename: DnsSystem.exe

 

Attack Chain Analysis

The .NET based DNS Backdoor is a customized version of the Open source tool DIG.net (DnsDig) found here: DNS.NET Resolver (C#) - CodeProject. DIG.net is an open source DNS Resolver which can be leveraged to perform DNS queries onto the DNS Server and then parse the response. The threat actors have customized and appended code that allows them to perform DNS queries for various records onto the custom DNS Server, parse the response of the query in order to execute system commands remotely, and upload/download files from the Command & Control server by leveraging the DNS protocol.

Initially the malware sets up an attacker controlled DNS server by acquiring the IP Address of the domain name “cyberclub[.]one” = 85[.]206[.]175[.]199 using Dns.GetHostAddresses() for the DIG Resolver function, which in turn triggers an DNS request to cyberclub[.]one for resolving the IP address. Now this IP is associated as the custom attacker controlled DNS Server for all the further DNS queries initiated by the malware. 

ImageFig 5. Initialize Attacker-Controlled DNS Server

 

Next, the Form Load function generates a unique BotID depending on the current Windows username. It converts the username into its MD5 equivalent using the CreateMD5() function, and parses the first 8 bytes of the MD5 as the BotID for the identification of the user and system infected by the malware.

Image

Fig 6. Generation of BotID using the Windows username


Now, the backdoor needs to receive commands from the C2 server in order to perform tasks.  The backdoor sends across an initial DNS query to “trailers.apple.com” wherein the domain name “trailers.apple.com” is concatenated with the previously generated BotID before initiation of the DNS request. The DNS query is then sent to the DNS server in order to fetch the “TXT” records for the provided domain name by passing three arguments to the BeginDigIt() function: 

  • Name: Target Domain name - EF58DF5Ftrailers.apple.com 
  • qType: Records to be queried - TXT
  • qClass: Dns class value - IN (default)

Image

Fig 7. Setup of DNS Query parameters before execution of BeginDigIt() Function

The BeginDigIt function then executes the main DNS resolver function “DigIt.” This sends across the DNS query in order to fetch the DNS record for the provided target domain name to the DNS server, and parses the response as seen in the code snippet below.

Image

Fig 8. DNS Query DigIt Function 

 

Comparing the Digit Resolver Code DigIt() function strings with the Dig.Net tool output from the screenshot shown below provides us further assurance that the Dig.Net tool has been customized by the Lyceum Group to develop the following .Net based DNS backdoor.    .

Image

Fig 9. Original Dig.net GUI Output 

The malware utilizes a DNS attack technique known as “DNS Hijacking” where in the DNS server is being controlled by the attackers which would allow them to manipulate the response to the DNS queries. Now let's analyze the DNS Hijacking routine below.

As discussed earlier, the backdoor performs initial DNS queries in order to fetch the TXT records for the domain EF58DF5trailers.apple.com. EF58DF5 is the BotID generated based on the Windows user to receive commands from the C2 server.

Image 

Fig 10. DNS query to attacker-controlled DNS server to fetch TXT records.

 

As can be seen in the above screenshot, a DNS query is performed to fetch the TXT records for the domain name: EF58DF5trailers.apple.com to the DNS Server: 85[.]206[.]175[.]199 which is the attacker-controlled DNS server previously initialized.

Here’s where the DNS hijacking happens: As the malware sends across a DNS query to fetch the TXT records to the attacker-controlled DNS server, the attacker controlled DNS server responds with an incorrect response consisting of the commands to be executed by the backdoor such as ipconfig,whoami,uploaddd etc as shown in the screenshot below.

Image

Fig 11. Ipconfig command returned as the TXT record from the attacker controlled DNS server

 

Following is the DIG.Net DNS response received by the backdoor and then further parsed in order to execute commands on the infected machine.

Image

Fig 12. DIG.net output received by the backdoor

The above screenshot consists of the DNS query performed to the attacker controlled DNS server along with the target domain name EF58DF5trailers.apple.com. The Answer section consists of the query response, which includes the target Domain name and the response to the TXT record with two values, “ipconfig” - command to be executed and “1291” - Communication ID

Next, the Dig.net response is parsed using multiple pattern regex code routines which parse out the TXT record values—the aforementioned command and communication ID—from the complete response received by the malware. 

Image

Fig 13. Parsing of TXT Records


Next, depending on the command received in the TXT record from the C2 server, there are three functions which can be performed by the Lyceum backdoor:

  • Download Files - If the command received from the DNS query consists of a string: “downloaddd” it initiates the download routine and downloads the file from the URL using DownloadFileAsync(). The URL would be the first 11 bytes of the TXT record response value, and stores that downloaded file in the Downloads folder as shown below in the code snippet. This functionality can be leveraged to drop additional malware on the infected machine.

Image

Fig 14. Backdoor Download Routine

  • Upload Files - If the command received from the DNS query consists of a string: “uploaddd”, it uploads the local file on the disk using UploadFileAsync() function to an External URL after parsing the TXT record response value into two variables: uriString (external URL) and filename (Local File). This functionality can be leveraged to exfiltrate data.

Image

Fig 14.  Backdoor Upload Routine

 

  • Command Execution - If none of the above strings match the TXT record response then the response is passed on to the Command execution routine. There, the response to the txt record is executed as a command on the infected machine using “cmd.exe /c <txt_record_response_command>” and the command output is sent across to the C2 server in the form of DNS A Records.

Image

Fig 15. Backdoor Command Execution Routine

 

In this case, the TXT record response we received for the DNS query performed against the attacker controlled DNS server is “ipconfig”. This response initiates the Command execution routine of the backdoor and thus the command “ipconfig” would be executed on the infected machine - cmd.exe /c ipconfig

Further, the command output is exfiltrated to the C2 server, encoded in Base64 and then concatenated with the Communication ID and the previously generated BotUID using “$” as the separator.
 

Image

Fig 16. Command Output exfiltration Pattern setup 

        
  Data Exfil Pattern: [base64encoded_command_output]$[communication_id]$[Bot_ID]


Once the command output is encoded in the above mentioned pattern, the DNS backdoor then sends across the output to the C2 server via DNS query in the form of A records in multiple blocks of queries, where the A record values consists of the encoded command output. Once the command output is transmitted completely, an “Enddd” command is sent across in a Base64-encoded data exfil pattern to notify the end of the command output as shown below in the screenshot.

Image

Fig 17. Exfiltration of Encoded Command Output via A records queries on the attacker controlled DNS server
 

Decoded A Records:


IPConfig Command Output -
 

Encoded A record = ICAgSVB2NCBBZGRyZXNzLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDogMTkyLjE2OC4.yLjEw$929$5686BB2F

Decoded A record =
IPv4 Address. . . . . . . . . . . : 192.168.2.10 $ ComID: 929 $ UID: 5686BB2F


End Command - 

Encoded A record = RW5kZGQ=$1291$$EF58DF5F 

Decoded A record = Enddd $ ComID: 1291 $ UID: EF58DF5F


Cloud Sandbox detection

Image

Fig 18: The Zscaler Cloud Sandbox successfully detected the malware.

 

Conclusion

APT threat actors are continuously evolving their tactics and malware to successfully carry out attacks against their targets. Attackers continuously embrace new anti-analysis tricks to evade security solutions; re-packaging of malware makes static analysis even more challenging. The Zscaler ThreatLabz team will continue to monitor these attacks to help keep our customers safe.

 

MITRE ATT&CK mapping:

 

T1059Command and Scripting Interpreter
T1055Process Injection
T1562Disable or Modify Tools
T1010Application Window Discovery
T1018Remote System Discovery
T1057Process Discovery
T1518Security Software Discovery
T1071Application Layer Protocol

 

IOC:

Docm Hash:

13814a190f61b36aff24d6aa1de56fe2

 

Exe Hash:

8199f14502e80581000bd5b3bda250ee

 

Domain and URL's:

cyberclub[.]one

hxxp://news-spot[.]live/Reports/1/?id=1111&pid=a52

hxxp://news-spot[.]live/Reports/1/?id=1111&pid=a28

hxxp://news-spot[.]live/Reports/1/?id=1111&pid=a40

hxxp://news-spot[.]live/Reports/1/45/DnsSystem[.]exe

 

About ThreatLabz

ThreatLabz is the security research arm of Zscaler. This world-class team is responsible for hunting new threats and ensuring that the thousands of organizations using the global Zscaler platform are always protected. In addition to malware research and behavioral analysis, team members are involved in the research and development of new prototype modules for advanced threat protection on the Zscaler platform, and regularly conduct internal security audits to ensure that Zscaler products and infrastructure meet security compliance standards. ThreatLabz regularly publishes in-depth analyses of new and emerging threats on its portal, research.zscaler.com.

Stay updated on ThreatLabz research by subscribing to our Trust Issues newsletter today.

 

form submtited
お読みいただきありがとうございました

このブログは役に立ちましたか?

Zscalerの最新ブログ情報を受信

このフォームを送信することで、Zscalerのプライバシー ポリシーに同意したものとみなされます。