Skip Navigation
Get a Demo
 
 
 
 
 
 
 
 
 
 

T1105

Ingress Tool Transfer

Ingress Tool Transfer is back for the fourth year running as adversaries continued deploying non-native tools for lateral movement and other post-exploitation activity in 2023.

Pairs with this song

#9

overall rank

11.3%

customers affected

308

threats detected
 

Analysis Icon

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.

Adversaries also often abuse certutil, a command-line utility that is used to display certification authority (CA) configuration information, configure Certificate Services, and back up and restore CA components. Adversaries most often use it to download additional payloads. It can also be leveraged to decode/encode data as well as interact with alternate data streams (ADS). Similar to certutil, certreq is also a built-in Windows binary that interacts with certificates from a Certificate Authority. It also has the ability to download and upload files which adversaries have been taking advantage of to move their tools around.

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

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. You can also consider leveraging the Windows host firewall to block outbound network connections for commonly abused LOLbins.

Visibility icon

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 Icon

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:

  • ProcessId
  • ProcessGuid
  • Image
  • Commandline
  • CurrentDirectory
  • ParentProcessGuid
  • ParentProcessId
  • ParentCommandLine

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:

  • ProcessGuid
  • ProcessId
  • Image
  • Protocol
  • SourceIP
  • DestinationIP
  • DestinationHostname
  • DestinationPort

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:

  • ProcessId
  • ProcessGuid
  • Image
  • TargetFileName

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:

  • ProcessGuid
  • ProcessId
  • QueryName
  • QueryStatus
  • QueryResult
  • Image

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.

Icon-threat detection

Detection opportunities

We have 111 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:

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:

Certreq downloading malicious binaries

Just like certutil, certreq can also be abused by adversaries to download and upload data. The following analytic will look for the execution of certreq.exe with command options that suggest a file is being downloaded:

process== certreq.exe 
&& 
command_includes ('-post' || '-config'|| 'http' || 'get')

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 Icon

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.txt

What 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:
VisibilityTelemetryCollection
Visibility :

Process monitoring

Telemetry:

A powershell.exe and notepad.exe process will start.

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 https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/LICENSE.txt is made.

Collection :

EDR and Sysmon Event IDs 3 and 22 should collect relevant telemetry.

Visibility :

File monitoring

Telemetry:

powershell.exe will write LICENSE.txt to the current directory.

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.

 
 
Back to Top