T1105
Ingress Tool Transfer
After gaining a foothold in a victim environment, adversaries often deploy non-native tools for lateral movement and other post-exploitation activity.
Pairs with this song #6
Rank
19%
Percent of customers affected
483
Total threat volume
Threat Sounds
After gaining initial access to a victim system, adversaries often leverage native Windows binaries to drop their own hot tools into an environment.
Analysis
Why do adversaries use Ingress Tool Transfer?
Note: Ingress Tool Transfer has no sub-techniques.
Administrative tooling and other native operating system binaries offer adversaries a rich array of functionalities that are ripe for abuse. While an adversary can accomplish many of their objectives by living off the land, they often require non-native tooling to perform post-exploitation activity and accomplish their goals. The process for bringing their own tools into an environment is known as ingress tool transfer.
How do adversaries use Ingress Tool Transfer?
One way to organize the many variations on ingress tool transfer is to split the activity into two distinct but broad categories:
- transferral via native Windows binaries
- transferral via third-party tooling
Many native system binaries enable adversaries to make external network connections and download executables, scripts, and other binaries. In fact, we observe adversaries leveraging native system binaries to perform ingress tool transfer far more often than not. This is a major part of the reason that we commonly observe the Ingress Tool Transfer technique in tandem with other ATT&CK techniques. As such, we’ll spend the bulk of this section explaining how adversaries abuse legitimate executables for ingress tool transfer.
However, we’ll start with a brief examination of non-native software that adversaries use to transfer tools—hopefully setting the stage for why native tooling is an appealing choice. Almost all command and control (C2) frameworks provide support for uploading and downloading files. Despite this, adversaries frequently choose to abuse native binaries to retrieve additional tools and payloads. There are many nuanced reasons why an adversary might choose a system binary over a C2 functionality, but it mostly boils down to blending in. For example, while it might be highly suspicious for a C2-related process to reach out to an external network address and pull down a binary, it could be completely normal for a legitimate system process to do the same.
Beyond C2 tools, it’s not unusual to see adversaries using remote monitoring and management (RMM) tools to perform ingress tool transfer. RMM software can be problematic for an adversary though, as defenders can simply block the use of tools that aren’t permitted in their environment, which is precisely why adversaries often resort to renaming such tools.
PowerShell is, by a wide margin, the system binary that we detect adversaries leveraging most frequently for ingress tool transfer. Relatedly, Ingress Tool Transfer (T1105) and PowerShell (T1059.001) are the second most commonly co-occurring techniques in threat detections across Red Canary.
Another native system binary commonly abused by adversaries is BITSAdmin. BITSAdmin is a utility that manages BITS jobs (Windows Background Intelligent Transfer Service), primarily for the purpose of downloading Windows Updates, but adversaries use it to download arbitrary files.
The LOLBAS project is a great resource and searchable database that’s mapped to ATT&CK and documents native binaries, scripts, and libraries that adversaries abuse. You can examine a full list of binaries that are used for ingress tool transfer here.
While we haven’t observed it firsthand, numerous threats have reportedly performed Ingress Tool Transfer into cloud-hosted systems to download additional payloads, lateral movement scripts, and more.
Associated threats
- Mimikatz
- Beapy
- Wannamine
- Cobalt Strike
take action
There are countless legitimate reasons for transferring tools between machines in an environment, making it difficult to offer one-size-fits-all advice on how defenders can mitigate Ingress Tool Transfer. However, application control policies that limit the use of tools that adversaries commonly use for Ingress Tool Transfer (e.g., remote management tools) may help. Given that Ingress Tool Transfer often co-occurs with PowerShell, consider reviewing and implementing the mitigation guidance included in the PowerShell section of this report.
Visibility
Note: The visibility sections in this report are mapped to MITRE ATT&CK data sources and components.
Nearly any attack involves some level of ingress tool transfer, so it’s critically important that you have the telemetry necessary to observe and detect it. Luckily, there’s no shortage of data sources offering visibility into this technique, and many of the data sources below can be drawn out of EDR and other widely available security tools.
Process monitoring
Since ingress tool transfer typically involves the use of system processes, process monitoring is among the most important data sources for detecting it. However, unless you’re looking for known malicious or banned processes, you’ll want to build your detection analytics such that process names are supplemented by command-line arguments, file modifications, DLL module loads, and network connections.
Command monitoring
As is almost always the case, command-line arguments are among the best telemetry for observing and detecting adversaries loading malicious tools into your environment, particularly when used in concert with process monitoring and other data sources. Beyond detection, command lines may also serve as a pivot point for investigation, especially in cases where something like a PowerShell or cURL command line includes URLs used to host remote content for download and execution.
Network connections
Network connection telemetry is a great source of enrichment data for detecting ingress tool transfer. While network connections offer fleeting value on their own, they’re extremely valuable in combination with process and command-line monitoring. Almost by definition, if you’re dealing with an adversary who is performing ingress tool transfer, an external network connection is happening somewhere.
Collection
Note: The collection sections of this report showcase specific log sources from Windows events, Sysmon, and elsewhere that you can use to collect relevant security information.
Sysmon Event ID 1: Process creation
The process creation event offers a wealth of information that security teams can use for detection, specifically via the following fields:
ProcessIdProcessGuidImageCommandlineCurrentDirectoryParentProcessGuidParentProcessIdParentCommandLine
As is the case with a commercial EDR product, we can leverage the above to identify what process executed, the process that spawned it, and the commands or arguments that executed in conjunction with it.
Sysmon Event ID 3: Network connection
Though they are disabled by default, network connection events offer a variety of log data that you can use to investigate or detect suspicious ingress tool transfers. While network connections aren’t particularly useful on their own, they’re useful in conjunction with other data, and Event ID 3 collects all of the following:
ProcessGuidProcessIdImageProtocolSourceIPDestinationIPDestinationHostnameDestinationPort
Sysmon Event ID 11: File create
By definition, ingress tool transfers require the creation of files on an endpoint, and file creation events are populated whenever a file is created or overwritten. Since processes constantly create temp files during normal activity, Event ID 11 can be incredibly noisy without thoughtful tuning. However, you can use Event ID 11 to track the file creation history of processes that adversaries frequently abuse (like those listed in the analysis section above). Consider limiting collection to oft-abused processes, directories where adversaries tend to drop malware (AppData\Temp or C:\Users\Public, for example), or specific file extension types like image files, executables, DLLs, and scripts. Event fields of interest are:
ProcessIdProcessGuidImageTargetFileName
Sysmon Event ID 22: DNS event
This is a newer event in Sysmon, but it can provide useful visibility into systems that may be communicating with C2 servers. According to Microsoft, this event will create a log whenever a process executes a DNS query, regardless of whether it succeeds or fails, cached or not. Logs from Event ID 22 offer additional network telemetry that can be incredibly useful in conjunction with the Event ID 3 logs listed above:
ProcessGuidProcessIdQueryNameQueryStatusQueryResultImage
Windows Security Event ID 4688: Process Creation
Process Creation (4688) events with command-line argument logging enabled is a great native source of telemetry for observing ingress tool transfer. A good understanding of baseline process relationships in your environment will help combat potential false positive alerts.
Commercial Endpoint Detection and Response (EDR) tools
EDR tools are perhaps the best starting point for Ingress Tool Transfer, as most of them offer rich visibility into the process starts, command-lines, and network connections needed to observe relevant malicious activity.
Detection opportunities
We have 90 distinct detection analytics mapped to Ingress Tool Transfer, offering defense in depth against this technique. Some of these analytics look for high-impact, low-prevalence threats and rarely generate events, but there are a few relatively simple ones that can offer great value with little effort.
Note: These detection analytics may require tuning.
Suspicious PowerShell commands
As we explained in the analysis section, adversaries leverage PowerShell for ingress tool transfer more than any other tool. As such, monitoring for PowerShell process execution in conjunction with suspicious PowerShell commands in the command line can be a fruitful way to detect malicious ingress tool transfers. The following pseudo-analytic is derived from several Red Canary detectors that collectively triggered on hundreds of confirmed malicious, high-severity threats in 2022 alone:
process == powershell.exe
&&
command_includes ('downloadstring' || 'downloadata' || 'downloadfile' || 'iex' || '.invoke' || 'invoke-expression')If you want to test your ability to operationalize the above detection analytic, try running either of the following Atomic Red Team tests:
CertUtil downloading malicious binaries
Adversaries often bypass security controls by using the Windows Certificate Utility (certutil.exe) to download malicious code. In general, they leverage certutil.exe along with the -split command-line option.
process == certutil.exe
&&
command_includes ('urlcache' && 'split')If you want to test your ability to operationalize the above detection analytic, try running either of the following Atomic Red Team tests:
- T1105: atomic test #7: CertUtil download (urlcache)
- T1105 atomic test #8: CertUtil download (verifyctl)
BITSAdmin downloading malicious binaries
As we explained in the analysis section, it’s not unusual for adversaries, including ones who peddle ransomware, to use BITSAdmin to download arbitrary files from the internet in an effort to evade application blocklisting. The following analytic will look for the execution of bitsadmin.exe with command options that suggest a file is being downloaded:
process== bitsadmin.exe
&&
command_includes (download' || 'transfer')If you want to test your ability to operationalize the above detection analytic, try running the following Atomic Red Team test:
Weeding out false positives
The majority of the telemetry patterns above can also manifest in development pipelines and system management tools. Given this, baselining is highly recommended due to the volume some sources will provide. Additionally, 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:
| Visibility | Telemetry | Collection |
|---|---|---|
| Visibility : Process monitoring | Telemetry: A | Collection : EDR, Sysmon Events ID 1, and Windows Event ID 4688 should collect relevant telemetry. |
| Visibility : Command monitoring | Telemetry: Command-line logging will capture the context of what is executed. | Collection : EDR, Sysmon Event ID 1, and Windows Event ID 4688 should collect relevant telemetry. |
| Visibility : Network monitoring | Telemetry: A connection to | Collection : EDR and Sysmon Event IDs 3 and 22 should collect relevant telemetry. |
| Visibility : File monitoring | Telemetry:
| Collection : EDR and Sysmon Event ID 11 should collect relevant 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.