Pairs with this song Analysis
Why do adversaries use Ingress Tool Transfer?
Upon gaining access to a system, adversaries need to perform post-exploitation actions to achieve their objectives. While victim operating systems offer an abundance of built-in functionality, adversaries frequently rely on their own tools to continue compromising an endpoint and network after initial entry. Ingress Tool Transfer is a technique adversaries leverage to bring their own tools into a compromised network.
How do adversaries use Ingress Tool Transfer?
There are many native system binaries that enable adversaries to make external network connections and download executables and scripts; many native processes allow for these files to get executed in memory without the file being written to disk. No matter the method used, an adversary must be able to download files to successfully perform Ingress Tool Transfer.
We commonly observe Ingress Tool Transfer in tandem with other techniques. This is due in part to how ATT&CK is structured—Ingress Tool Transfer falls under the Command and Control (C2) tactic, but in order for it to be performed, it typically requires some type of Execution (a different tactic) to occur as well.
Historically, adversaries have relied on vulnerabilities found in processes that would allow them to perform remote code execution. However, in 2020, we observed adversaries performing Ingress Tool Transfer with system binaries (often referred to as living-off-the-land binaries, or LOLBINs)— commonly BITSadmin, Certutil, Curl, Wget, Regsvr32, and Mshta. The most common execution technique we observed adversaries using in tandem with Ingress Tool Transfer was our most prevalent technique in general: PowerShell. For example, Smominru malware (also known as “MyKings”) uses the PowerShell command iex(New-Object Net.WebClient).DownloadString to download additional files, as seen below:
We observed this same Ingress Tool Transfer + PowerShell combination in many other threats in 2020, including our ninth most prevalent threat, TrickBot.
Emerging Ingress Tool Transfer tradecraft
Adversaries are constantly coming up with novel ways to perform Ingress Tool Transfer that are harder for defenders to identify and detect. We are seeing adversaries leveraging macros and VBA code to make system calls directly (such as the HttpOpenRequestA function) to download their tools. The Lazarus Group also uses methods within the libcurl library instead of calling curl to perform Ingress Tool Transfer. Behaviors such as these disguise Ingress Tool Transfer within the process, making it more challenging to identify as malicious.
In a similar vein, adversaries have started weaponizing RTF files to inject shellcode into Microsoft’s Equation Editor to download their tools, leveraging lesser known LOLBINs that have the ability to download from the internet (such as the bug in Windows Defender discovered and fixed late last year).
On the network side, many monitoring and prevention tools can identify and block executable and script files from being transferred into the network. In an effort to evade these defenses, adversaries have combined Ingress Tool Transfer with Masquerading, hiding their tool within JPEG files that many network monitoring tools allow to pass through into the network.
Definition
Detection
Collection requirements
Command-line monitoring
Data sources that show process execution and command-line arguments (EDR tools, Sysmon, Windows Event Logs) are likely your best source of observing and detecting malicious use of Ingress Tool Transfer. These tools will allow you to look for a download or transfer taking place, as well as provide leads for further investigation. Using command-line arguments, you can examine remote systems and content used to facilitate the transfer. For example, PowerShell and curl command lines often include URLs used to host remote content for download and execution. This data point provides an interesting pivot at which to proceed during investigations.
Process monitoring
EDR tools and other data sources that show process telemetry can also be useful in identifying malicious use. As a rule, more data is usually better than less. In ideal scenarios, we recommend process monitoring tools that provide process name, command-line arguments, file modifications, DLL module loads, and network connections. The sum of this telemetry helps paint a picture of what capabilities exist inside unknown processes or scripts.
Network connections
Telemetry showing network connections is often essential during investigations. While network connections on their own aren’t suspicious, combining network connection data with the known and expected behaviors of processes can yield breathtaking results. In addition, correlating network connections with other data points—such as file modifications or time of day—can help suspicious activity stand out from the crowd. A good example of this correlation would be certutil.exe making network connections. On its own, the utility doesn’t typically make connections, but it may make file modifications. If a network connection occurs from certutil.exe alongside the file modifications, you can more reasonably assess that certutil.exe enabled Ingress Tool Transfer.
Packet capture
Finally, web filters, firewalls, and Intrusion Prevention Systems (IPS) that are capable of performing deep content inspection can be useful for identifying executables and DLLs being transferred into the network. Despite adversaries’ attempts at obfuscation, well constructed security architecture can enable defenders to spot useful patterns in traffic ingressing to the network from adversary-controlled systems. Good examples of these patterns include MZ headers in executable content and portions of script content. This sort of data enables defenders to also use additional types of analytics or rules, such as those for Snort or Suricata detections. By supplementing endpoint detection capabilities with network data, your security team can become a relentless defensive force.
Detection suggestions
Suspicious commands
By far the most fruitful method by which we have identified malicious Ingress Tool Transfer use is examining PowerShell command lines for keywords and certain patterns. Look for the execution of powershell.exe with command lines containing the following keywords:
downloadstringdownloaddatadownloadfileto a temporary/non standard location (temporappdata) or in combination with execution (invoke-expression)
You should also consider alerting on certain patterns in PowerShell command lines, like bitsadmin.exe with download in the command line or certutil using urlcache or with split in the command line.
Another suspicious command pattern that warrants monitoring is curl or wget making an external network connection immediately followed by writing or modifying an executable file, particularly to a temp location.
Other LOLBINs such as mshta.exe, csc.exe, msbuild.exe, or regsvr32.exe making external network connections to URLs ending with an executable or image extension, suspicious domains, and/or unusual IP addresses are inherently suspicious and warrant monitoring.
Weeding out false positives
The majority of the telemetry patterns above can also manifest in development pipelines and systems management tools. Given this, and as is the case for many detection ideas in this report, you may want to do an environment audit and figure out if these potentially suspicious behaviors are being employed by any legitimate tools or people in your environment.
Once you understand legitimate use cases, you can tune those out as exceptions and focus your detection efforts on seeking out behaviors that are more likely to represent malicious instances of Ingress Tool Transfer.
Testing
Start testing your defenses against Ingress Tool Transfer using Atomic Red Team—an open source testing framework of small, highly portable detection tests mapped to MITRE ATT&CK.
Getting started
View atomic tests for T1105: Ingress Tool Transfer. In most environments, these should be sufficient to generate a useful signal for defenders.
Run this test on a Windows system using PowerShell:
(New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/redcanaryco/atomic-red-team/4042cb3433bce024e304500dcfe3c5590571573a/LICENSE.txt') | Out-File LICENSE.txt; Invoke-Item LICENSE.txtWhat to expect
The above test will download a file to LICENSE.txt and display it with notepad.exe. For safety purposes, the command only downloads and displays text rather than downloading and executing executable content.
Useful telemetry will include:
| Data source | Telemetry |
|---|---|
| Data source: Process monitoring | Telemetry: A |
| Data source: Process command-line parameters | Telemetry: Command-line logging will capture the context of what is executed. |
| Data source: Network protocol analysis | Telemetry: A connection to |
| Data source: File monitoring | Telemetry:
|
Review and repeat
Now that you have executed one or several common tests and checked for the expected results, it’s useful to answer some immediate questions:
- Were any of your actions detected?
- Were any of your actions blocked or prevented?
- Were your actions visible in logs or other defensive telemetry?
Repeat this process, performing additional tests related to this technique. You can also create and contribute tests of your own.