Amid escalating tensions between the US and Iran, Iranian cyber threats are facing increased attention and scrutiny. The Pulsedive research team recently analyzed a series of loader scripts added to Malware Bazaar by Security Researcher @JAMESWT_WT. These scripts caught our attention because they were associated with malware intrusions, in which Telegram was used for Command and Control (C2) - a tactic recently outlined in an FBI FLASH Report. Released on March 20, 2026, the FLASH Report outlined how threat actors aligned with Iran’s Ministry of Intelligence and Security (MOIS) leveraged Telegram as command-and-control infrastructure in cyber operations, using Telegram bots to exfiltrate data from user devices. In this blog, we dive into numerous loader scripts identified as being used in intrusions that leveraged Telegram as the C2. We provide an analysis of the scripts, mitigation recommendations, and a list of observed indicators of compromise.
Walkthrough of an intrusion
The FBI FLASH report highlights that the intrusions began with social engineering, in which threat actors attempted to convince victims to install malware on their devices. The actors targeted victims via social media applications, posing as technical support or famous personas. The goal of the social engineering campaign was to convince the victim to execute malware on their device. The FBI notes that the malware masquerades as well-known applications.
Figure 1: The malware delivered to victims masqueraded as popular applications, including communication applications. Source: FBIFigure 2: Stages of the intrusions as outlined by the FBI. Source: FBI
Moreover, reports note that the malware used PowerShell to execute malware and modified registry keys to establish persistence. Malware observed in this campaign was capable of recording screen and audio activity, collecting information from the cache, and creating compressed file archives. These archive files were then exfiltrated using Telegram.
Figure 3: File names for malware that was used to exfiltrate data. Source: FBI
Script Analysis
Figure 4: Samples were shared on Malware Bazaar and X by @JAMESWT_WT. Source: XFigure 5: Screenshots of the samples of Malware Bazaar: Source: Malware Bazaar
PowerShell Script 1 - ps.ps1
The first sample we will analyze is a simple PowerShell script, available on Malware Bazaar. The script is a one-liner that executes base64 encoded content with the PowerShell window hidden.
The decoded base64 content indicates that the script is attempting to download additional files and execute them. This script attempts to download two additional files and execute them. At the time of analysis, both files were unavailable.
Figure 7: Base64-decoded content present within the script.
The script attempts to download files from Vultr Object Storage. The files are downloaded to the temp directory and then executed. The contents of the zip archive are extracted to the path C:\ProgramData\ssh-cache-default\, and the executable RuntimeSSH.exe is executed.
Figure 8: Details about the URL where ok.txt is hosted. Source: PulsediveFigure 9: Details about the URL where RuntimeSSH_17.zip is hosted. Source: Pulsedive
Powershell Script 2 - cmd.ps1
The second sample is almost identical to the first script. The similarity between the scripts is confirmed by the ssdeep value, which only differs by two characters. The only difference is that it specifies "C:\Windows\System32\cmd.exe" before the PowerShell command.
💡
Learn more about ssdeep hashing in this blog post.
Figure 10: Almost identical ssdeep values for script 1 (top) and script 2 (bottom). This shows that the content of the scripts is almost identical.
The ssdeep hashes of script 1 and script 2 confirm that the files are almost identical. The hashes only differ by two characters.
Figure 11: Content of cmd.ps1.
❗
For an explanation of the decoded content, please refer to the analysis available for script 1 above.
VBScript 1 - لیست شماره های افراد نیازمند شماره های افراد نیازمند خیلی خدمات شماره های شماره های افراد نیازمند افراد نیازمند به توانبخشی.vbs
Also available on Malware Bazaar is a VBS script that is significantly larger than the PowerShell scripts discussed thus far. The script is a one-liner that executes base64 encoded content with the PowerShell window hidden.
لیست شماره های افراد نیازمند شماره های افراد نیازمند خیلی خدمات شماره های شماره های افراد نیازمند افراد نیازمند به توانبخشی.vbs
The file consists of 63791 lines. The bulk of these lines are blank and contain no characters. Once the empty lines of code are removed, we are left with 11 lines of code.
Figure 12: content of the VBScript show large blobs of text and empty lines.
Of those 11 lines, there are two large blobs of text that serve no function. These are the first and last lines of the file. The code executed consists of a string, an array of numbers, a for loop, string-manipulation operations, and a function that executes the manipulated string.
Figure 13: Content of the VBScript with blank lines removed.Figure 14: Key code identified within the script which is used to deobfuscate additional code.
The first line of the For loop iterates over the array of numbers. The first step is to extract a character from the i-th position of the string in the af789f342e5024051 variable. The next line gets a number from the i-th minus 1 position in the array. From there, the script decodes a character by subtracting the value from step 1 from the value obtained in step 2, then converting the result to a character. This value is then added to an array, which is executed at the end of the loop.
The decoded content reveals that the script attempts to query the disk size. If the disk size exceeds 50 GB, it attempts to execute the PowerShell commands outlined in Scripts 1 and 2.
Figure 15: Deobfuscated content present within the VBScript. This content attempt to download the sample payloads that are highlighted in PowerShell script 1 (ps.ps1) and PowerShell Script 2 (cmd.ps1).
The Malware Bazaar collection contains another PowerShell that is similarly inflated at 183,069 bytes. This file contains the same content as the VBS script, as confirmed by the ssdeep values of the files.
Figure 16: ssdeep hashes for the VBScript (top) and bloated PowerShell script (bottom) showing that the content is almost identical.
Smqdservice.exe
While not the zip archive observed in the scripts we analyzed in our blog, Malware Bazaar contains the payload mentioned in the FBI report. This is a zip archive containing several .pyd files and smqdservice.exe. Sandbox results of the sample are available on Any.Run.
The executable attempts to evade detection by adding exclusions within Microsoft Defender. This is done using PowerShell to exclude the path %ALLUSERSPROFILE%\SMQDServicePackages\ and C:\Users\Power\Downloads\Telegram Desktop
Figure 18: PowerShell is used to add an exclusion path in Defender for the Telegram installed within the Downloads folder. Source: Any.Run
Once the exclusions are in place, the malware executes the smqdservice.exe binary, which loads various Python modules, including python311.dll, which was present in the zip archive.
The following Telegram bot details were extracted from the binary.
Figure 19: Telegram Bot details extracted from the Binary: Source Any.Run
Connecting to the URL specified in the get info parameter provides details about the Telegram bot, including its username, ID, and enabled permissions.
Figure 20: Details of the Telegram bot including some permissions assigned to it.
Conclusion
The loaders analyzed in the blog are very basic. Their singular goal is to download additional content that is hosted on Vultr Object Storage. The PowerShell scripts contain base64-encoded content that, once decoded, reveals that the loader attempts to download a zip archive. The zip archive contains a file called RuntimeSSH.exe, which was identified in the FBI FLASH report. The report outlines that this file is used to exfiltrate sensitive information from the compromised device. Telegram is frequently used as C2 infrastructure, as it blends in with legitimate traffic and is relatively easy to create Telegram bots. Moreover, Telegram has served as an online marketplace for cybercrime actors where groups actively advertise malware, exfiltrated data, and services. This makes Telegram a popular tool, allowing threat actors to expand their capabilities without burning through in-house-developed tools. Iranian-affiliated groups like Handela Hack have been active on Telegram, where posts detail their operations.
Recommendations
Methods to mitigate the risks posed by malware include:
Deploy EDR/AV solutions: EDR or AV solutions can detect malicious process chains and anomalous activity that may indicate a malware infection.
Restrict the ability to install applications: Enforce policies that allow users to install only applications from approved sources, such as App Stores.
Expand PowerShell logging: Consider enabling script-block logging to ensure security analysts can view the contents of executed scripts.
Secure PowerShell in Corporate Environments: Organizations can enforce script execution policies that allow only signed scripts to run. Moreover, PowerShell usage should be restricted to users who need to use it.
User Education: Users can help mitigate the risk of phishing emails and targeted social engineering campaigns. Users should also be wary of unsolicited attachments or senders that pressure them to open attachments or download files.
Indicators of Compromise
The table below lists network IOCs that have been identified and added to the Pulsedive platform.
The TTPs table uses Tactics and Techniques available in MITRE ATT&CK v19. One of the biggest changes in this version of the framework is that the Defense Evasion tactic has been separated into Stealth (TA0005) and Defense Impairment (TA0112).
Botnets are always an interesting threat to discuss, simply because of their prevalence and the difficulty of restricting and mitigating them. Spamhaus noted that July to December 2025 saw a 24% increase in the number of botnet command & control servers identified when compared to the previous 6-month period. This blog started off as a focused discussion of Aisuru-Kimwolf, what it is, and what has been observed recently; however, since there are so many botnet families that are related to each other, we decided to expand the scope and treat this as more of a technical primer to botnets. This blog will describe observations on several botnets and discuss their key similarities and differences.
Figure 1: Number of DDoS attacks tracked by Cloudflare. Source: Cloudflare
💡
For more details about DDoS attacks in Q4 of 2025, please review Cloudflare's report.
Figure 2: Top locations for botnet C2s. Source: Spamhaus
What is a Botnet?
Before diving into a discussion about different botnets, let’s establish what a botnet is, fundamentally. A botnet is a network of computers (bots) infected with malicious software and controlled by a single group or actor. These compromised computers can be used to initiate large-scale distributed denial-of-service (DDoS) attacks. Botnets can also be leveraged by attackers to conduct intrusions or phishing campaigns while masking their infrastructure, as they can route commands through the compromised network.
On March 19, 2026, the U.S. Department of Justice announced disruption actions against IoT botnets. The press release indicated that law enforcement attempted to take down Command and Control infrastructure used by the Aisuru, KimWolf, JackSkid, and Mossad botnets. The disruption actions took place across Canada and Germany. Authorities attempted to seize DigitalOcean droplets (virtual servers) used as C2 servers for KimWolf.
💡
Detail about the takedown can be found in the Affidavit.
Figure 3: The affidavit states that Digital Ocean Droplets were used as C2 servers for the KimWolf botnet. Source: District of AlaskaFigure 4: IP addresses of the servers that were used as KimWolf C2s. Source: District of AlaskaFigure 5: Definitions of bots and botnets as listed in case number 2015R00240/SW in the District of New Jersey. Source: Justice Department
The Akamai graph below illustrates how a brute-force attack using botnets would work.
Figure 6: How attackers can use botnets in brute force attacks. Source: Akamai
Mirai - One of the Most Influential Modern Botnets
Mirai scans the internet for devices that are running on ARC processors. ARC runs a stripped-down version of Linux. Mirai was first identified in 2016 and is used to target vulnerable Internet of Things (IoT) devices. Initial compromise occurs through the exploitation of vulnerabilities on these devices or by using the device's default credentials.
Figure 7: Early timeline of Mirai. Source: UsenixFigure 8: URLs associated with the Mirai botnet. Source: URLHausFigure 9: Malware samples associated with Mirai. Source: Malware Bazaar
The Many Different Variants of Mirai
Figure 10: The many variants of Mirai
The public availability of Mirai’s source code has led to the creation of many variants. Researchers Ya Liu and Hui Wang released a paper about tracking Mirai variants at Virus Bulletin 2018. In this paper, they outlined different variants based on the samples analyzed.
Figure 11: Mirai variants presented by Ya Liu and Hui Wang. Source: Virus Bulletin
The same authors also presented at BotConf in 2023 and outlined that the clustering and classification techniques previously discussed identified 116 different branches from over 21,000 samples.
Figure 12: Additional Mirai variants outlined in a presentation by Ya Liu and Hui Wang. Source: BotConf
Satori
Satori is a Mirai-based botnet that was first identified in late 2017. Shortly after its discovery, it infected over 260,000 routers typically used in small-office/home-office environments or in homes. The botnet spreads by exploiting vulnerabilities that typically allow for remote code execution on these devices. One such vulnerability that is abused is an OS command injection vulnerability in D-Link DSL-2750B devices.
Figure 13: Part of the Metasploit code used to exploit D-LINK DSL-2750B devices. Source: Exploit DBFigure 14: A GET request is used to exploit the vulnerability and download a script from the adversary's infrastructure. The script is subsequently executed on the D-Link device. Source: RadwareFigure 15: Shell script executed on vulnerable devices. Source: Radware
This script is used to download and execute files hosted on a different server on the compromised host. The script first creates a file in each subdirectory of the /tmp/ folder. From there, it creates a file named after the shell interpreter's environmental variable. Then it downloads a file from different URIs before making it executable. Each file is executed. Each file targets a different CPU architecture; the script downloads and executes them all to attempt to compromise as many devices as possible.
Figure 16: Install script for Satori. Source: Lumen
The install function in this script is almost identical to the one shown in Figure 15.
Aisuru-Kimwolf
Aisuru-Kimwolf is a botnet used to conduct large-scale DDoS attacks. The Aisuru and Aisuru-Kimwolf variants have compromised approximately 1-4 million hosts globally. Cloudflare notes that Aisuru-Kimwolf is responsible for the largest DDoS attacks to date, including a 31.4 Terabit-per-second attack and a 14.1 billion packet-per-second attack. The botnet can randomize packet characteristics, making it more difficult for security tools to detect attacks. Aisuru encodes a list of C2 IPs in TXT records, associated with the C2 domains.
Figure 17: Distribution of KimWolf IP addresses. Source: KrebsonSecurity
Kimwolf
Kimwolf is a botnet that targets Android devices, including Smart TVs and mobile devices. Kimwolf has compromised approximately 2 million devices globally. Kimwolf is considered a subvariant of Aisuru and is an Android-specific variant. Kimwolf uses the DDoS functionality provided by Aisuru, which has been modified to target Android devices. The operators behind Aisuru and Kimwolf have monetized their operations by selling access to the compromised devices to other cybercrime actors. Access to these botnets is sold through services like Discord or Telegram and depends on the attack's size and duration.
Figure 18: Details about KimWolf C2s from the District of Alaska Affidavit. Source: District of Alaska
Kimwolf has rapidly infected a large number of devices through residential proxy networks. Residential proxies are networks that route internet tariffs through addresses assigned to homeowners. IPIDEA is a residential proxy that was used by Aisuru and Kimwolf in recent times. Attackers used IPIDEA nodes to mask their activity. In an attempt to disrupt residential proxy abuse, Google took action to take down C2 domains and domain advertising IPIDEA products. Following the announcement of the takedown, there were reports that Kimwolf has switched to leveraging The Invisible Project. The Invisible Project is a decentralized, encryption communications network designed to anonymize and secure communication. The move to I2P can be an attempt to evade takedown attempts.
Figure 19: Discussion about I2P being overloaded with KimWolf devices. Source: KrebsonSecurityFigure 20: How KimWolf abuses residential proxy infrastructure. Source: Synthient
KimWolf Script Analysis
The first part of the script attempts to download various files from an adversary-controlled server. These files include .apk files; for downloaded files, the script attempts to execute them before starting services.
Figure 21: Install script executed by KimWolf. Source: Synthient
Conclusion
Botnet activity has surged over the last year, with Spauhaus noting 26% and 24% increases in the two six-month periods Jan - Jun 2025 and Jul - Dec 2025, respectively. This increase is associated with bots and nodes appearing in the United States, as shown in Figure 2. The increase in activity from the US is substantial enough to have overtaken China as the country with the most botnet C&C servers, a rank China has held since the third quarter of 2023. The increase also stems from the availability of source code for botnets such as Mirai. Mirai offshoots and variants are responsible for some of the largest DDoS attacks by volume. Since these botnets exploit vulnerabilities in home routers, it can be expected that there will always be a threat, as these devices are seldom patched.
Recommendations
The impact of botnets can be mitigated using solutions such as:
DDoS Protection: Network providers often offer solutions to detect and proactively block bot activity.
Protective DNS: Protective DNS solutions can filter DNS requests and identify suspicious activity.
Patch Edge Devices: Ensure that, at a minimum, any publicly accessible network devices are patched regularly.
Rotate Default Credentials: Ensure that the default credentials for networking devices are not being used. These should be changed during device setup.
Indicators of Compromise
The table below lists a subset of the Aisuru-Kimwolf network IOCs that have been identified and added to the Pulsedive platform. This data can be queried in Pulsedive using the Explore query threat=Aisuru-Kimwolf and is available for export in multiple formats (CSV, STIX 2.1, JSON).
Artifacts from our analysis are available on our GitHub.
TAMECATis a PowerShell-based malware that can execute various commands to collect sensitive information. Reporting from the Israel National Digital Agency dives into the modular nature of the TAMECAT and its functionality. The malware is used by APT42, an Iranian state-sponsored cyber-espionage actor, during its espionage operations. Reporting from Israel indicates that TAMECAT was observed being deployed in espionage campaigns targeting high-value senior defense and government officials. The group leverages social engineering to build rapport with victims over an extended period before gaining access to their environments. This blog will outline TAMECAT’s capabilities and how it exfiltrates data.
This overview includes:
Malware Analysis
Recommendations
Indicators of Compromise
MITRE ATT&CK TTPs
Israel’s National Digital Agency shared a breakdown of the in-memory modules available with TAMECAT. This included the ability to extract data from Microsoft Edge using remote debugging, screen captures, and suspending Chrome for data collection.
In the analysis, the researchers noted that the malware received commands from a Telegram bot. The malware used messages from the bot to download additional scripts.
The intrusion sample that we analyze in this blog starts with a VBScript script that downloads TAMECAT’s first stage. This script checks which antivirus products are running on the system. This check determines whether the script uses conhost and PowerShell or cmd.exe and curl to download the second stage. The sample used in this analysis is available on VirusTotal.
When the VBScript file is executed, it uses WMI to retrieve a list of installed antivirus products on the host. The returned list is then used to determine which scripting interpreter is used to download the second stage. If the antivirus list contains “indows”, the VBScript uses conhost to launch PowerShell. The PowerShell script uses wget to download the loader TAMECAT (081419a484bbf99f278ce636d445b9d8). Once the file is downloaded, the script is executed using PowerShell. The script uses an obfuscated command to execute the downloaded PowerShell Script.
Figure 4: Code used to launch PowerShell and download TAMECAT.Figure 5: Obfuscated Invoke-Expression command.
This obfuscated command decodes as the following:
Obfuscated Command
Deobfuscated Command
gcm
Get-Command
*e-e?p*
Invoke-Expression
If the antivirus list does not contain Windows, then the VBScript uses cmd.exe and curl to download another piece of malware. At the time of analysis, the link was down, so the payload could not be analyzed.
Figure 6: If the computer does not contain Windows within the AV list, it uses curl to download a secondary payload.
Nconf.txt (TAMECAT PowerShell Loader)
This is the TAMECAT loader that was hosted on tebi[.]io. This script contains several variables containing arrays of values, as well as two functions. The functions are used to decode data and execute additional code. The sample is available on Triage and VirusTotal.
Figure 7: Code of the nconf.txt.Figure 8: Functions within nconf.txt PowerShell Script.
The Gorba function defines two parameters called $te12 and $k12ey. The values of these parameters are defined at the end of the script and are shown in the table below.
The value stored in the $k12ey parameters is the same one identified by Volexity in a variant of PowerStar. The Yara rule shared by Volexity closely matches the commands observed in this analysis.
From there, the script attempts to download the next stage of TAMECAT from a base64-encoded URL. The PowerShell script uses a hardcoded user-agent within the network traffic. The script uses the downstring command to retrieve text from tebi[.]io. The URL is base64-encoded in the script, and before it is decoded, the script drops the first 3 bytes of the encoded string. The file attempts to download text within a file called df32s.txt, which holds base64-encoded content.
Figure 9: The encoded URL stored within the PowerShell file.
User-Agent
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36
Figure 10: Content hosted on the encoded URL.Figure 11: Data manipulation code used to transform the encoded data.
The script base64-decodes the file's contents and then performs the following actions on each byte:
Perform a bitwise not on each bit and convert to base2
Convert to a string and extract 8 characters starting from the 24th character
Convert to Byte
Once this manipulation is complete, the script converts the bytes to a UTF-8-Encoded string.
Figure 12: The decoded Borjol function.
The decoded content reveals an additional function that is executed with the value stored in $te12. This function defines an AES decryptor used to decrypt the value stored in $te12 after it is base64-decoded.
AES Settings
Value
Block Size
128
Key Size
256
Key
kNz0CXiP0wEQnhZXYbvraigXvRVYHk1B
IV
0T9r1y1M2e0N0o1w
Figure 13: Decrypted data from Figure 9.
This decoded string is passed to the Borjol function.
Figure 14: Decoded content from Figure 13.
This decrypted data contains functions that manipulate data in the following ways.
Function Name
Description
Borjoly
Decodes base64-encodes data and then decrypts it using AES
Borpos
Encrypts data using AES
x
Converts a base64-encoded character and encodes it into a UTF8-encoded string
xs
Generates a random 16-character string
The PowerShell script uses these functions to manipulate data while attempting to exfiltrate it. The script writes an alphanumeric string, which Google believes to be a victim identifier to %LocalAppData%\config.txt.
Figure 15: Unique identifier being stored within config.txt.
The script then creates a new directory called Chrome in %LocalAppData%. From there, the script defines the SessionUrl, the hostname used for network communication. The value for this parameter is a hxxps://accurate-sprout-porpoise[.]glitch[.]me, which was defined as a global parameter in the function Borjol.
Figure 16: Code used to define the SessionUrl using parameters from the Borjol function.
From there, the script collects details about the operating system, including:
OS
ComputerName
Token (GILNH9LX6TCZ9V8ZZSUF) - the value specified in the $configtxt parameter.
This data is then passed to the Borpos function for encryption before being exfiltrated via a POST request to the domain hxxps://accurate-sprout-porpoise[.]glitch[.]me. The key is the value kNz0CXiP0wEQnhZXYbvraigXvRVYHk1B, while the initialization vector is created using the xs function. The script also adds the header Content-DPR, which stores the IV value.
Figure 17: Code of the Borpos function.
function xs() {
return - join ((65..90) + (97..122) | Get - Random - Count 16 | % {
[char]$_
}
)
}
The malware then waits for the C2’s response. If the status code is not 400 and the response is not empty, then the script calls the Borjoly function to decode the response from the C2. The data is separated by ¶ and contains the following four values:
language
Command
ThreadName
StartStop
Figure 18: Code of the Borjoly function.
The command is in base64-encoded format. Google identified that the $Language parameter will be used to execute either PowerShell or C# code, and the $StartStop will be used to download additional content, execute, or terminate a command.
Figure 19: Code that is run based on the response from the C2 server.
Conclusion
TAMECAT is a PowerShell-based malware used by APT42 during its espionage campaigns. It has gone through several iterations, with different variants sharing several similarities. These similarities include the use of Base64-Encoded strings within arrays, the use of array fragments to generate code, and PowerShell string replacement and wildcards. The developers behind TAMECAT have also been observed using platforms such as Discord and Telegram as C2 channels.
Recommendations
Methods to mitigate the risks posed by malware, such as TAMECAT, include:
Deploy EDR/AV solutions: EDR or AV solutions can detect malicious process chains and anomalous activity that may indicate a malware infection.
Monitor for wscript launching other scripting interpreters: VBS scripting launching PowerShell or cmd.exe is often suspicious.
Expand PowerShell logging: Consider enabling script-block logging to ensure security analysts can see the contents of scripts that were executed.
Secure PowerShell in Corporate Environments: Organizations can enforce script execution policies that allow only signed scripts to run. Moreover, PowerShell usage should be restricted to users who need to use it.
User Education: Users can help mitigate the risk of phishing emails and targeted social engineering campaigns. Users should also be wary of unsolicited attachments or senders that pressure them to open attachments or download files.
The table below lists TAMECAT network IOCsthat have been identified and added to the Pulsedive platform. This data can be queried in Pulsedive using the Explore query threat=TAMECAT and is available for export in multiple formats (CSV, STIX 2.1, JSON).
For our previous blog on Shai-Hulud, please click here.
💡
Artifacts from this blog are available within our GitHub Repository.
On November 24, 2025, multiple security vendors reported a new Shai-Hulud campaign that compromised several popular npm packages. The compromised packages include those from Zapier, ENS Domains, PostHog, and Postman. Researchers from Wiz identified that the earliest evidence of malicious npm packages being added to npm is from around 03:00 UTC on November 24th, 2025. The compromise results in a GitHub repository containing stolen information. GitHub has been removing repositories; however, as of 15:00 EST on November 25, 2025, some remain accessible.
ℹ️
A detailed timeline of events can be found in this Wiz blog.
This blog will walk through the malicious code present in the second iteration of the Shai-Hulud compromise.
How Does the Compromise Work?
The malicious versions of the NPM packages contained two files called setup_bun.js and bun_environment.js. These were made to look like the package was introducing the Bun runtime, which is a JavaScript runtime environment, package manager, and test runner. According to researchers at HelixGuard, the setup_bun.js file contains code that masquerades as Bun setup code and invokes the bun_environment.js file.
Figure 1: Content of setup_bun.js. Source: HelixGuard
The bun_environment.js file is an obfuscated JavaScript file, around 10 MB in size, that contains code for collecting secrets and exfiltrating information.
Figure 2: File size of bun_environment.jsFigure 3: Content of bun_environment.js
The malicious code attempts to add workflows to the infected machines. One such workflow is .github/workflows/discussion.yaml, which executes commands by opening a discussion in the GitHub repo.
Figure 4: Content of discussion.yaml.
The malicious code collects information about the system and collects secrets from AWS, GCP, and Azure.
Figure 5: References to system checks and cloud secret collections in bun_environment.js.
The collected content is double base64-encoded before being added to the public GitHub repo. Reporting from socket.dev states that the exfiltrated content was triple base64-encoded and that some repositories also contained a file called actionSecrets.json. This file was not present in the repositories we reviewed, but scanners for Sha1-Hulud reference it.
Propagation is similar to that seen in the first campaign. Once the worm identifies a valid NPM token, it fetches the maintainer’s package (limited to 100 packages) and updates each package using the updatePackage() function.
The updatePackage() function adds the setup_bun.js and bun_environment.js files to the package, updates the package.json file to add the preinstall script, and increments the patch version before publishing the compromised version.
Socket.dev also reported on the destructive capabilities of the worm. If the worm cannot find a GitHub token or an NPM token, it attempts to delete files. For Windows environments, the worm uses cmd.exe to delete all files in %USERPROFILE% (the current user’s profile directory) and overwrites the free space using the cipher /wcommand. This command overwrites deleted data in a drive's free space, making it unrecoverable.
In Linux or macOS environments, the worm finds all of a user’s writable files and overwrites them with the shred command before deleting the empty directories.
Figure 7: Linux man page for the shred command. Source: Linux
Scope of Compromise
The worm creates a GitHub repository with the description Sha1-Hulud: The Second Coming. These repositories contain exfiltrated data. As of 19:45 EST on November 24, 2025, approximately 22,600 GitHub repositories had the description Sha1-Hulud: The Second Coming.
Figure 8: Search results on GitHub for repositories containing the phrase Sha1-Hulud: The Second Coming
Each of these repositories contain .json files with base64-encoded data. The files included in the repository are:
cloud.json
contents.json
environment.json
Some repositories also had a file called truffleSecrets.json.
Exfiltrated Information
cloud.json
The cloud.json file contains any secrets extracted from AWS, GCP, and Azure. The content is double base64-encoded, and the decoded text is a JSON object.
Figure 9: Decoded content of the cloud.json file.
contents.json
The contents.json file contains information about the system, including operating system, architecture, user details, and GitHub account details. The content is double base64-encoded, and the decoded text is a JSON object.
Figure 10: Decoded content of the contents.json file.
environment.json
The environment.json file contains build information. The content is double base64-encoded, and the decoded text is a JSON object.
Figure 11: Decoded content of the environment.json file.
Figure 12: Decoded content of the environment.js file.
truffleSecrets.json
This file contains all of the data collected by TruffleHog, including credentials and secrets for various platforms. Like the other JSON files, this file is also double base64-encoded.
Figure 13: Decoded content of the truffleSecrets.json file.
Mitigation Recommendations
As highlighted in the previous Shai-Hulud blog, it is always difficult to detect and respond to supply chain compromises. It is not always clear where these packages are used and what other libraries use them. We recommend taking the following actions:
Review the list of compromised packages below and audit your development environment for them
Rotate all GitHub, npm, cloud, and CI/CD secrets
Check GitHub for repositories that have been made public
Check GitHub for repositories that have the description Sha1-Hulud: The Second Coming
Audit GitHub for any unauthorized workflows
Deploy phishing-resistant MFA solutions for CI/CD pipelines and developers
Monitor any newly published npm packages within the organization
Disable post-install scripts
Compromise Packages
This list of packages below is accurate as of 15:00 EST on November 24, 2025. As this is an evolving situation, this list may not be complete and is expected to change over time.
All the samples and copies of the data exfiltrated by this sample referenced in this research blog can be found on our GitHub Repo
Last month, our team came across a few X posts about indicators of compromise related to Kimsuky, a North Korean threat group that has been active since 2012. Kimsuky is predominantly responsible for conducting espionage operations against government entities, think tanks, and subject matter experts. The initial post that we saw contained a network IOC, a file hash, and the names of some LNK files. Security researcher @naumovax subsequently shared snippets of network traffic and a link to an Any.Run Sandbox submission. This blog analyzes the initial sample, how it downloads additional stages, and the network traffic observed within the infection chain.
Figure 1: Posts about the Kimsuky samples from researchers on X
Initial Sample Details
Figure 2: Intrusion stages identified during analysis
The first file observed within this intrusion chain is a JavaScript file called Themes.js. This file starts the intrusion chain by downloading an additional payload from the adversary-controlled infrastructure. The initial JavaScript file is not obfuscated, and its only purpose is to download and execute content from a website. The entire code is encapsulated within a try-catch block. The file initiates a GET request to iuh234[.]medianewsonline[.]com. to the URI /dwnkl[.]php with the parameters:
URI Parameter
Description
uid
Computer name of the compromised device
key
The value is hardcoded to kx
Median News is a website that allows users to create subdomains for websites or other projects. While the medianewsonline website is not inherently malicious, threat actors can create subdomains on it that can be used for malicious activity.
Figure 3: Landing page of medianewsonline[.]comFigure 4: Example GET requests captured within VirusTotal with different computer names as the uid. Source: VirusTotal.Figure 5: GET request from sample being analyzed. Source: Any.RunFigure 6: Functionality of the initial script
The initial JavaScript file initiates a GET request to an adversary-controlled infrastructure, with the computer name being passed as a parameter in the URI. The script then attempts to execute the data returned by the server.
Figure 7: Breakdown of the second stage's functionality
The server responds to the GET request with some more JavaScript code. This code consists of five functions and a try-catch block. The code attempts to collect system information, a list of running processes, and a list of files in the Users folder. Once each set of data has been collected, the code attempts to upload the command's output to the adversary-controlled domain. Once all the data has been exfiltrated, the code tries to delete any temporary files created.
Figure 8: The main code that is to be executed
The script attempts to run four commands, with three commands attempting to collect system and file information from the compromised host. The final command is used to delete temporary files that have been created (these files are used to hold the information to be exfiltrated).
The first command executed collects system information, an example of which is shown in Figure 16. The following command is used to obtain a list of all running processes on the host (Figure 17). The last reconnaissance command navigates to the C:\\Users directory and lists all the files and subdirectories within it by listing the newest files first. This command also lists the attributes for each file within that directory. An example of this is illustrated in Figure 18. After each command is executed, its results are uploaded to the C2 server. The last function changes the working directory to the %TEMP% directory and deletes any .tmp file within that directory.
Execute Command
Figure 8: The ExecuteCommand does not contain calls to other user created functionsFigure 9: Code defined in the ExecuteCommand function
The execute command is used to modify the registry key HKCU\\Console\\CodePage by creating the key with the value 65001. This sets the input and output encoding to UTF-8. The code then creates a file in the %TEMP%directory with a randomly generated file name. This is used to hold the content of the commands that were executed.
Upload Result
Figure 10: UploadResult makes use of other helper functionsFigure 11: Code used to exfiltrate data via POST requests
Data is exfiltrated to the URI /umprl.php?uid= with the computer name specified as a parameter. The JavaScript code then creates a file to hold the content of the data to be exfiltrated. The data is exfiltrated as part of a POST request where the request body contains the cabinet file with the exfiltrated data.
Helper Functions
Make File
Figure 12: Code used to create a file name
The strPrefix variable is an empty string, so any newly created file will be named after the date it was made.
Read File
Figure 13: Code used to create the content of a file
This function takes a file name as a parameter, opens a buffer to read the file, and then closes it.
Prepare File for Upload
Figure 14: Code used to create cabinet files that will be exfiltrated
All content to be exfiltrated is turned into a .cab (cabinet) file and encoded using the certutil LOLBIN.
Exfiltrated Data
Data is exfiltrated through POST requests to iuh234[.]medianewsonline[.]com/umprl[.]php?uid=. The first request exfiltrates system information, while the second one contains details about all the processes running on the system at that time. The last request includes details about files and directories within the C:\Users directory.
Figure 15: Example of cabinet file being exfiltrated via a POST requestFigure 16: The first data that is exfiltrated included content from systeminfoFigure 17: Process information that was exfiltratedFigure 18: Directory information collected by the sample
Third Stage - A Word Document
Figure 19: Functionality of the third JavaScript file
For every POST request sent by the second stage, the C2 server returns the same content. This is another JavaScript file that executes two functions. The webpage return is resized to 0 and moved off the display window in an attempt to further hide the code.
Figure 20: Portion of the HTTP response issued by the server is response to data sent by the second stage
Establishing Persistence (MKSCHD Function - Make Scheduled Task)
Figure 21: Functionality of the MKSCHD function
This stage begins by calling the MKSCHD function with the string "Windows Themes Manager". This function contains hardcoded data that is URI percent-encoded data. Before the content is decoded, the JavaScript modifies the HKCU\\Console\\CodePage registry by adding an entry with the value 65001. When decoded, the data is the code outline in the initial sample.
Figure 22: Functionality used to establish persistence
Figure 23: The encoded content above decodes to the initial sample
The decoded content is written to a file called Themes.js, which is written to the %APPDATA%\\Microsoft\\Windows\\Themes\\Themes.js. Once the file is written to disk, a scheduled task is created that runs every minute with the task name Windows Theme Manager, which calls wscript.exe to execute the file.
Figure 24: Function used to write content to disk
OPDOM
Figure 25: Functionality of the OPDOM function
The next function, OPDOM, is called, which takes the value E-CARD.docx as a parameter. This function contains base64 encoded data, which is saved to a file called L298306.tmp in the %Public% directory. This file is then decoded using the certutil LOLBIN, after which the temp file is deleted.
Figure 26: Truncated content of the OPDOM function
Decoding the base64 data within the function reveals that it is a Word document. Running the Word document through a sandbox reveals an empty document.
Figure 27: Screenshot of the downloaded Word document
Conclusion
Analysis of the Kimsuky sample revealed two additional JavaScript files and a Word Document. Since the Word document is empty and does not run any macros in the background, it may be a lure. Moreover, as the initial access vector is unknown, we cannot say how the initial Theme.js file is delivered to the user.
Recommendations
Methods to mitigate the risks posed by malware include:
Deploy EDR/AV solutions
EDR or AV solutions can detect malicious process chains, anomalous activity, and suspicious files that may indicate a malware infection.
User Education
Users can help mitigate the risk of information-stealing malware infections by avoiding suspicious websites and using authorized software in corporate environments.
Indicators of Compromise
The table below lists network IOCs identified during our analysis.
Additional IOCs related to Kimsuky can be queried in Pulsedive using the Explore query threat=Kimsuky, and are available for export in multiple formats (CSV, STIX 2.1, JSON).
MITRE ATT&CK TTPs
Technique
Tactic
Execution
Command and Scripting Interpreter: JavaScript (T1059.007)
Scheduled Task/Job: Scheduled Task (T1053.003)
Persistence
Modify Registry (T1112)
Scheduled Task/Job: Scheduled Task (T1053.003)
Privilege Escalation
Scheduled Task/Job: Scheduled Task (T1053.003)
Defense Evasion
Indicator Removal: File Deletion (T1070.004)
Obfuscated Files or Information: Command Obfuscation (T1027.010)
Discovery
System Information Discovery (T1082)
File and Directory Discovery (T1083)
Collection
Data from Local System (T1005)
Data Staged: Local Data Staging (T1074.001)
Command and Control
Application Layer Protocol: Web Protocols (T1071.001)
In September 2025, multiple NPM packages were compromised. Some of the compromised packages were highly popular, with millions of downloads per week. Two different sets of compromises were observed:
The first compromise occurred around September 8th, 2025, when the packages were embedded with the ability to replace cryptocurrency wallets with adversary-controlled ones.
The second compromise utilized the Shai-Hulud worm, which was employed to exfiltrate sensitive information from GitHub repositories.
Initial reports about the Shai-Hulud worm emerged on September 15, 2025. GitGuardian observed activity related to this compromise from September 15 at 03:46 to September 16 at 13:42.
GitHub's Response: In response to the Shai-Hulud attack, GitHub removed over 500+ compromised packages from the npm registry. Additionally, npm blocked new packages that contained known indicators of compromise from being uploaded to the registry.
This blog will walk through both compromises and provide insights into the functionality of the malicious packages, as well as response recommendations.
First Compromise: September 8th Campaign
The campaign was first reported on September 8th, 2025, and the list of compromised packages included chalk and debug. Both are very popular npm packages, each of which is downloaded over 250 million times a week. The packages were modified to include malicious code that was subsequently executed.
I have no access to my account at the moment. It's in npm's hands for now. Sindre has already booted me off and published over chalk.
debug and color/color-string/color-convert are still affected, along with many others I'm sure.
Email came from support [at] npmjs [dot] help.
Figure 1: Bluesky posts about maintainer about compromised npm packages. Source: Bluesky
Figure 2: Phishing email from npmjs[.]help email used for initial access. Source: Aikido
This attack began by compromising a maintainer’s account with a phishing email and using the account to modify the packages. The threat actor registered the domain npmjs[.]help on Porkbun on September 5th, 2025.
Figure 3: Obfuscated code was added to the index.js file within version 0.3.3 of the is-arrayish npm package. Source: Aikido
A GitHub Gist contains the index.js file for the compromised version of the chalk npm package. The same code shown on line 12 of Figure 3 above is also present in the Gist.
The obfuscated code can be deobfuscated using tools such as deobfuscate.io. The first round of deobfuscation reveals code containing a list of cryptocurrency wallets, including Bitcoin, Bitcoin Cash, Litecoin, TRON, and Solana. While still heavily obfuscated, analysts can still review the code and understand its functionality.
Figure 5: Result of a single iteration of deobfuscation on code shown in Figure 4. Source: GitHub Gist
Various cryptocurrency wallets are hardcoded within the file, and there are references to different types of cryptocurrency.
Figure 6: Cryptocurrency wallets hardcoded within the malicious file. Source: GitHub GistFigure 7: Code with string references to different cryptocurrencies. Source: GitHub Gist
The malicious code also contains RegEx to match different types of cryptocurrency wallets. The malware intercepts connections to cryptocurrency platforms and replaces the wallet in the request with one of the hardcoded wallets. This allows them to replace payment destinations for adversary-controlled ones, achieved by either injecting itself into functions such as fetch, XMLHttpRequest, or through wallet APIs.
Figure 8: Calls to a wallet API is used to get a list of accounts owned by the user. Source: GitHub GistFigure 9: RegEx used to identify cryptocurrency wallets. Source: GitHub Gist
Second Compromise: Shai-Hulud Attack
The Shai-Hulud compromise differed from the previous attack in that it didn’t target cryptocurrency transactions, but was instead used to exfiltrate secrets from GitHub repositories. Significantly more npm packages were compromised in this subsequent attack. GitGuardian observed activity related to this compromise from September 15 at 03:46 to September 16 at 13:42. The malware utilized the TruffleHog tool to locate and collect credentials and secrets. Any data that was collected was exfiltrated via GitHub actions to the webhook[.]site domain.
As part of the attack, GitHub workflows were used to convert private repositories to public ones. The repositories that were turned into public ones had the description “Shai-Hulud Migration”, and the term -migration" was added to the name.
The malware also attempts to exfiltrate the following credentials:
The malware has self-propagation functionality through the updatePackage function. This queries the NPM registry to download the packages owned by the maintainer. Once these are downloaded, the bundle.js file containing the malware is written to the package. Once this file has been written, the package is republished.
Figure 12: Function used to get packages owned by a maintainer.Figure 13: Once packages owned by a maintainer are downloaded, the malware writes the malicious file to them to propagate the worm.
Apart from updating other packages owned by the compromised maintainer, the malware downloads TruffleHog to collect secrets stored within the repo. The first step in running TruffleHog is to check the operating system architecture and type. From there, the latest version of TruggleHog is downloaded and installed.
Figure 14: Code used to download the latest version of TruffleHog from GitHub.Figure 15: Attempts to retrieve information from AWS.
Apart from collecting secrets and staging them for exfiltration, it creates a repo with the description “Shai-Hulud” as shown in Figure 16 below.
Figure 16: Data that is collected for exfiltration and the call to the makeRepo function with the string "Shai-Hulud" being passed to it.
The data is exfiltrated using a GitHub workflow. The content of the workflow is hardcoded in the malicious file.
Figure 17: Code used to setup the GitHub workflow used for exfiltration.
Figure 18: The GitHub workflow as shown within a compromised GitHub repo.
Mitigation Recommendations
Responding to a supply chain compromise is always a challenging task, as pinpointing where packages are used or their versions may not always be easily verifiable. Nevertheless, a dependency review should be conducted for software that leverages npm. The yarn.lock or package-lock.json files may provide details about the packages in use.
When responding to npm supply chain compromises, once compromised packages have been identified and removed, it is recommended to clear the npm cache before reinstalling the package. In addition to reinstalling packages, consider resetting secrets and user credentials that may have been exposed.
GitHub’s Response
As of September 22, 2025, GitHub outlined a plan for securing the npm supply chain in response to these attacks. Included within this plan are the following actions:
MFA required for local publishing
Time-based OTPs will be deprecated
Users will be moved to FIDO-based MFA
Users will no longer be able to bypass MFA for local publishing
Thorium is a malware analysis platform designed to simplify analyst workflows by consolidating tools into a single interface. CISA describes it as “a highly scalable, distributed malware analysis and data generation framework”. Sound familiar? We released a guide on a similar open-source malware analysis tool called Assemblyline earlier this year (see below for a comparison of the two). Thorium is available as a GitHub repo, which is maintained by CISA. This blog outlines what Thorium is and how to use it.
Thorium is an open-source malware detection tool designed to simplify incident response, triage, and file analysis by providing secure file ingestion and storage, along with automated analysis. The platform also makes it easy for analysts to access storage copies of analyzed files and their metadata.
When to use Thorium?
Thorium is great for teams that conduct file triage or analysis. Being able to store the results of their analyses in place makes it easy for other analysts to review the results and quickly search for additional information.
Key Features
Scalable platform for analysis
Static and dynamic analysis sandboxes
Easy-to-use interfaces
REST APIs for automation purposes
Multi-tenant capabilities
Full-test search
Key/Value tagging for data labels
CaRT and safely sharing files
A common problem faced by all malware analysts and researchers is how to store and share files safely. Some do this by storing them in password-protected zip archives or by changing the file extension to something that renders the file unable to execute. In some cases, these work to prevent accidental execution of malicious files; however, they can still be quarantined by security solutions.
This is where CaRT (which stands for Compressed and RC4 Transport) comes in. CaRT is used to store and transfer malware, as well as its metadata. This is a product developed by the CSE in Canada, encrypting files to prevent them from being executed or quarantined by security solutions. Any file uploaded to Thorium is converted to CaRT format. They are also downloaded in CaRT format and must be “unCaRTed” to be executed.
Thorium Architecture
Thorium was designed to run within a K8s cluster. For deployment on a cluster, CISA mentions that a Block Storage Provider and S3 storage will be required. CEPH is recommended for on-premise solutions.
Components
API
The rest API allows the different Thorium components to coordinate activity and complete tasks. The API allows multiple instances to run on various components. This setup enables high availability, meaning that if one server with the API running fails, the entire Thorium platform remains operational.
Different databases are used to store various types of information.
Database
Resources
Redis
Reactions
Scheduling Streams
Scylla
File metadata
Reaction logs
Elastic
Tool Results < 1 MiB
S3
All files
Tool request > 1MiB
Jaeger
API request logs
Scaler
The scaler is used to determine when reactions or jobs are created. This system enables priority jobs to be executed on a portion of the platform while the rest of the platform executes other jobs.
Agent
The agent is used to run tools by:
Downloading the required data
Executing tools
Streaming logs via API
Uploading results
Cleaning up temporary artifacts
Reactor
The reactor uses the Thorium API to get information about its nodes and creates or terminates workers to match the workload.
Tracing/Logging
Logging is performed by tracing. Unified tracing is used to log to a central file server or disk.
Event Handler
The event handler is responsible for triggering reactions (instances of a pipeline being run) based on actions that took place within Thorium.
K8s Deployment
ℹ️
This blog will not delve into the deployment of Thorium on a Kubernetes (K8s) cluster.
The Kubernetes cluster requires a storage provisioner that can allocate persistent volume claims for the database and tracing services. Admins also need account credentials and permissions to create buckets within an S3-compatible storage interface.
The components that make up the Thorium deployment include:
Traefik
Rook
Redis
Scylla
Elastic
Tracing
Quickwit
Jaeger
Detailed installation for each of these services is available in the GitHub repo here.
Local Deployment
Minithor uses minikube to deploy Thorium to a single instance. This type of deployment is not recommended for production use and should only be used for development and testing purposes. Minithor implementations do not provide the scalability factor that Thorium was intended to give teams.
The content of the GitHub repo was used during the instructions below.
Deploy Miniduke
Install and run Miniduke by executing the script
./install-linux
The content of the install script is provided below:
#!/bin/bash
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube && rm minikube-linux-amd64
# set resources for VM
minikube config set cpus 8
minikube config set memory 15976
# alias kubectl command to minikube subcommand and add to .bashrc/rshrc
touch ~/.bashrc
if [[ $SHELL == *"bash"* ]] && ! grep -q "alias kubectl=\"minikube kubectl --\"" ~/.bashrc; then
echo "alias kubectl=\"minikube kubectl --\"" >> ~/.bashrc
source ~/.bashrc
fi
touch ~/.zshrc
if [[ $SHELL == *"zsh"* ]] && ! grep -q "alias kubectl=\"minikube kubectl --\"" ~/.zshrc; then
echo "alias kubectl=\"minikube kubectl --\"" >> ~/.zshrc
source ~/.zshrc
fi
# start of k8s cluster
minikube start --cni calico
# add required plugins
minikube addons enable csi-hostpath-driver
minikube addons enable ingress
minikube addons enable ingress-dns
Once MiniKube is installed, you need to create a file called .dockerconfigjson that contains the authentication credentials for the user account associated with the Thorium container. Following that, dependencies can be installed using the deploy script.
User Roles
Groups are used to grant permissions and access to resources for different users. All resources are owned by the person who creates them.
System Roles
System Roles are used to perform actions at the global level. The roles include:
User
Analyst
Developer
Admin
The user role can use Thorium to conduct analysis, but cannot create new Pipelines. The developer role has more permissions than the user role. The admin roles allow users to modify any resource within Thorium.
Figure 2: Description of each user role available within Thorium. Source: CISA
Group Roles
Groups are used to restrict a user’s ability to conduct operations on a group’s resources. Group resources include:
Images
Pipelines
Repos
Files
Tag
Comments
Analysis results
Figure 3: Permissions assigned to different roles. Source: CISA
File Origins
File origins are a feature within Thorium that can be used to describe any relationships that exist within the files.
Figure 4: Upload screen within Thorium. Source: CISA
The table below lists the various file origins available within the platform.
Type of File Origin
Explanation
Downloaded
The file was downloaded from a URL
Transformed
The file was obtained through transformations
Unpacked
The file was unpacked
Wire
The file was captured through the network
Incident
The file collected during an incident
Memory Dump
The file was obtained from a memory dump
Carved
The file was extracted from another file
PCAP
The file was extracted from a network capture
Unknown
The file was obtained from an unknown source
Figure 5: Subfields for each of the file origins. This subfields are used to provide insights for each identified file.
Images & Pipelines
Tools are referred to as Images within Thorium. As of September 4th, 2025, no tools have been released as part of the Thorium build; however, users and organizations can add their own tools as needed. Images can be created using the Developer role.
Images can be added via the Web UI. This is done through the Image confirmation settings, where users can specify the name, Group, and Image required, among other settings. Once the relevant information has been entered, Thorium is able to use the tool and display its output.
Figure 6: UI used to create an Image: Source: CISAFigure 7: Parameters used to configure Images.
Pipelines
Pipelines are a way to run multiple Images through in an automated fashion. These are used to run different tools and collect their outputs sequentially. They are created in the Pipelines creation menu, where users will provide a Pipeline name, the SLA, Image order, and Group.
Figure 8: Dialog shown when creating a Pipeline. Source: CISA
💡
Images must already be created for them to be used as part of a Pipeline in Thorium.
Thorium enables organizations to help scale and standardize their file triage and analysis steps. The ability to have tools contained within a single platform helps analysts with file analysis and management. Pipelines and their use in automating processes are an interesting concept that can be employed to perform static analysis on files using multiple tools, with the resulting information ready for review by a human analyst when required.
Thorctl
Thorium is also accompanied by a command-line tool that can be used to perform different operations. The CLI tool can be used to:
Upload files or Git repos
Download files or repos
Start reactions
Download results
List files
Download instructions for both Unix and Windows are available here.
An example of the CLI usage is provided below:
$ thorctl files upload --help
Upload some files and/or directories to Thorium
Usage: thorctl files upload [OPTIONS] --file-groups <GROUPS> [TARGETS]...
Arguments:
[TARGETS]... The files and or folders to upload
Options:
-g, --groups <GROUPS> The groups to upload these files to
-p, --pipelines <PIPELINES> The pipelines to spawn for all files that are uploaded
-t, --tags <TAGS> The tags to add to any files uploaded where key/value is separated by a deliminator
--deliminator <DELIMINATOR> The deliminator character to use when splitting tags into key/values [default: =]
-f, --filter <FILTER> Any regular expressions to use to determine which files to upload
-s, --skip <SKIP> Any regular expressions to use to determine which files to skip
--folder-tags <FOLDER_TAGS> The tags keys to use for each folder name starting at the root of the specified targets
-h, --help Print help
-V, --version Print version
Conclusion
As a new entrant to the malware analysis space, Thorium provides cybersecurity teams with a highly customizable and free platform to enhance malware analysis, triage, and incident response workflows. By combining several essential capabilities in one tool, it helps analysts with organizational file sorting, storage, analysis, and collaboration. While still relatively immature, Thorium is a promising option to consider for teams seeking affordable and flexible solutions.
KiwiStealer is a file stealer that was first identified in 2024. The first report on the malware was posted on the platform ctfiot. Subsequent reporting from ThreatRay revealed that the malware was observed being used by the threat group Bitter APT in late 2024. The malware collects some system information before attempting to collect files from specific directories. This blog outlines the malware’s capabilities and how it exfiltrates data via HTTP POST requests. This overview includes:
Malware Analysis
Network Traffic Analysis
Recommendations
Indicators of Compromise (IOCs)
MITRE ATT&CK TTPs
Malware Analysis
Figure 1: Exfiltration Criteria used by KiwiStealer.
The file analyzed as part of this blog can be found on VirusTotal. The following table shows information about the sample, including hash values.
Figure 2: VirusTotal Results for the sample. Accurate as of August 13, 2025, at 10:29 EST. Source: VirusTotal
The malware collects the username and computer name, appending this information to the C2 URI and including it in HTTP requests to the C2 server. The URI is itself hardcoded within the malware and is decoded using string reversal and a modified Caesar Cipher (ROT2). The sample also created a mutex rabadaisunique, to ensure that multiple instances of the malware cannot be executed on a compromised host.
Figure 3: Hardcoded C2 URL that is obfuscated. Source: ThreatRay
KiwiStealer iterates through several directories to identify files that can be exfiltrated. These directories are shown in the screenshot below.
Figure 4: Directories targeted by KiwiStealer. Source: ThreatRay
The malware will only exfiltrate files that are less than 50 MB in size and that have been modified in the last year. The file extensions that the malware targets are outlined in the table below.
.z7
.txt
.doc
.docx
.xls
.xlsx
.ppt
.pptx
.pdf
.rtf
.jpg
.zip
.rar
.apk
.neat
.err
.eln
.ppi
.er9
.azr
.pfx
.ovpn
After successfully extracting files, the malware appends the file name to a file called winlist.log along with the time it was exfiltrated. When the sample was detonated by a sandbox, two files were exfiltrated, and their names were added to winlist.log.
Figure 5: Winlist.log contains the list of files exfiltated.
The malware exfiltrates information to its C2 server via HTTP POST requests. The POST request returns files containing data about the file. The PCAP contains two POST requests. The requests are to the domain ebeninstallsvc[.]com, to the URI /uplh4ppy.php. The request to the domain includes the computer name and user name of the compromised host.
Figure 6: Traffic capture showing the hostname and username being passed as URI parameters.
WHOIS data for the domain ebeninstallsvc[.]com shows that it was registered with NameCheap on 2023-10-27 at 07:08:18 UTC.
Figure 7: WHOIS data for the C2.
The first request sends back an RTF file titled 20240712_173213__ukdescribed.rtf to the server. If this file is successfully transmitted to the server, the C2 responds with the response line success.
Figure 8: RTF being sent to the C2 server.
This RTF document was stored on the desktop and exfiltrated by the malware.
Figure 9: Content of the exfiltrated RTF file.
The second POST request sends back an image to the C2 server.
Figure 10: Network traffic showing the exfiltration of a jpg file.
The image can be decoded using CyberChef using the recipe shown in the screenshot below. The picture was extracted from the PCAP using the export functionality within Wireshark.
Figure 11: Exfiltrated image rendered using CyberChef
A larger version of the image is shown below. This particular image was stored on the sandbox and exfiltrated by the malware.
Figure 12: Exfiltrated Image
ThreatRay’s report also includes screenshots of other traffic associated with the malware. This particular screenshot contains information about the collected files.
Figure 13: Additional files being exfiltrated by the malware. Source: ThreatRay
Conclusion
KiwiStealer is a malware that exfiltrates files from compromised machines. The malware targets a specific set of file extensions and only attempts to exfiltrate files that have been modified in the past year and are less than 50MB in size. Unlike other malware variants that have advanced capabilities, KiwiStealer is a relatively simple malware whose sole purpose is to exfiltrate files.
Recommendations
Methods to mitigate the risks posed by malware such as KiwiStealer include:
Deploy EDR/AV solutions
EDR or AV solutions can detect malicious process chains and anomalous activity that may be indicative of a malware infection.
User Education
Users can help mitigate the risk of information-stealing malware infections by avoiding suspicious websites and using authorised software in corporate environments.
Indicators of Compromise
The table below contains a list of KiwiStealer network IOCs that have been identified and added to the Pulsedive platform. This data can be queried in Pulsedive using the Explore query threat="KiwiStealer" and is available for export in multiple formats (CSV, STIX 2.1, JSON).
In the field of cyber threat intelligence (CTI), IP addresses and domain names are commonly shared indicators of compromise. They are commonly used solely to create blocklists on tools such as firewalls and other networking devices. Blocking these atomic indicators of compromise is a viable solution when consuming threat intelligence feeds, but they can also be used to enrich alerts, provide context, and expand detection logic. This blog outlines how IP addresses and domains can provide additional value within the disciplines of threat intelligence, detection engineering, and threat hunting. Moreover, this blog will share details and guidance on how to conduct IP and domain analysis to draw conclusions, as well as showcase examples of data processing from Pulsedive and popular analyst tools.
The Pyramid of Pain
Any discussion about value within threat intelligence will likely touch upon the Pyramid of Pain. The Pyramid of Pain, coined by David Bianco, is a model used in CTI to illustrate the difficulty experienced by adversaries and threat actors when defenders detect and respond to different types of indicators during an attack. Moving up the pyramid from hash values to TTPs is correlated with the increased "pain" inflicted on the adversary, becoming more challenging to replace or adapt. IP addresses and domain names make up two of the lower tiers in the pyramid and may not cause as much pain to threat actors as detecting tools or TTPs. This is because IP addresses and domains can be ephemeral. Threat actors can quickly rotate through IP addresses during campaigns, negating the impact of blocking individual addresses. Similarly, domain names can be registered in bulk; with various registrars, it is easy for a threat actor to spin up network infrastructure fairly quickly.
Figure 1: The Pyramid of Pain
Since these indicator types are ephemeral, even adding these indicators to blocklists may provide limited value. Blocking provides value when a threat actor consistently uses the same IP address or domain name across a campaign. Once they rotate to a new IP address or domain, the blocked indicators cease to provide value outside of retroactive investigations. In the short term, blocking IP addresses and domain names can yield timely results and identify malicious or suspicious activity. However, these lists need to be actively maintained and regularly purged to remove indicators that are no longer active or have been removed by vendors.
💡
How long until an IOC should be or is retired will depend on several factors, including: - The confidence level associated with that IOC - When was the indicator last seen? - Is this indicator associated with other threats? - Storage limitation on tools (blocklists have a finite size)
Uses of IPs and Domains
Providing Context During Investigations
Security analysts often spend time either manually enriching data to gain additional information about events or leveraging automated lookups to provide this context. Enriching IP addresses can include leveraging IP geolocation data, reputation data, and provider data. Geolocation data can give an approximation of the user’s location when a specific activity is performed and can be used to identify compromised accounts when multiple login sessions or actions are performed by the same user, but from physical locations that are not possible. Reputation data is another valuable enrichment during investigations, as it sheds light on the IP addresses and the other activities associated with them. Common reputation clues include if it has been reported by other users for exploitation or scanning activity, or if it belongs to a VPN provider.
Examples of how Pulsedive users leverage this enrichment data:
Manual Approach: An analyst visits Pulsedive, performs a scan, and collects the relevant information to help during an investigation.
Hybrid/Automated Approach: A SIEM/SOAR solution integrates with Pulsedive and is configured to retrieve data about IP addresses and domains. An alert may be triggered based on suspicious activity, where an analyst then uses this data to investigate an alert and make a determination about this activity.
Figure 2: A sample workflow of a Pulsedive client using enriched data during an investigation.
Atomic indicators can also be used to hunt for malicious activity in an environment. Simpler to conduct than behavioral threat hunting, indicator-based hunting focuses on the presence of known malicious indicators of compromise (IOCs) to identify malicious activity in historical network logs. Security tools can be used to search for the presence of IOCs that security researchers have shared throughout an environment. Hits on these IOCs may lead to the discovery of previously undetected intrusions.
Research
Indicators can be tied together to identify particular malware families and reveal commonalities that make it easier to identify other artifacts associated with that threat. For example, Pulsedive threat research used IP addresses, domains, and content served on web pages to track and identify additional Mystic Stealer control panels back in July 2023.
When we encountered research from other vendors regarding Mystic Stealer, we utilized the IOCs to identify commonalities between them before attempting to identify additional domains to track. Our approach involved looking at the following items for each identified IOC:
Figure 3: Pivot points used during our investigation.
Based on information shared by security researchers, we observed that the HTML title for the control panel was "Mystic Stealer - Login". We used this information to pivot to tools such as FOFA, Shodan, and Binary Edge to identify additional IP addresses and domains associated with Mystic Stealer Control Panels.
Figure 4: HTML content reveals that the console page has an HTML title of "Mystic Stealer - Login".Figure 5: Mystic Stealer Control Panels identified on Shodan during our investigation in 2023
IP Analysis Tools
💡
The Curated Intel team shared a GitHub repository that contained tools to collect information about an IP address.
Depending on the use case and the information we want to obtain, many tools can provide information about IP addresses. This information can include:
IP Reputation
IP Geolocation
Is it a Cloud/CDN IP?
Is it a VPN, Tor node, or proxy?
IP WHOIS
ASN
Open Ports & Services Running
Figure 6: Information that can be obtained from an IP address.
During investigations, some of the first items analysts commonly check for are the reputation and geolocation of an IP address. IP reputation can show if an IP address has been observed by others performing scans or attempting to exploit vulnerabilities.
Figure 7: IP addresses associated with CVE-2024-8963 exploitation attempts within GreyNoise.Figure 8: ASN information provided by ipinfo for an IP address seen in Figure 7.Figure 9: An IP address previously associated with Mystic Stealer.
Tools such as Spur or IP Quality Score can be used to detect VPN or Proxy usage. This information is valuable during investigations, as it can explain differences in geolocation and be used to track activity against specific devices or sessions. Moreover, the use of specific VPN providers or proxies can be used to cluster activity to different threat groups. For example, security researchers have identified that Famous Chollima frequently uses Astrill VPN during intrusions.
Figure 10: IP address from SilentPush that was observed being used by Famous ChollimaFigure 11: Mind map of how ASN data can be utilized in Threat Hunting and security investigations. Source: Huntress
Other Analysis Tools
Data collected about domains can also be used to cluster activity back to a particular threat or actor. In some cases, this will be as simple as examining X.509 certificates to identify common names. In contrast, in other cases, it will require a wealth of data from both the domain and the IP addresses to recognize patterns.
Some of the information that can be collected about domains includes:
WHOIS/RDAP Information
Date registered
Registrar Information
Content hosted
Certificate Details
Favicons
Meta Tags
Figure 12: Pivot points associated with domains.
X.509 certificate data contains a wealth of information that can be used to identify additional IOCs.
Figure 13: Some key items that make up an X.509 certificate. Complete details are available in RFC5280.Figure 14: List of distinguished names available for subject and issuer names. Source: Cryptosys.
Taking an entry for DCRat from the SSL Blacklist provides us with a SHA1 fingerprint, Subject Name, and Issuer Name. Any of these can be used to search tools like Censys to identify additional IP addresses using the same certificate.
Figure 15: SSL Blacklist entry for a certificate used by DcRat.Figure 16: Censys results showing 46 IPs that use an SSL certificate where the subject common name contains 'DCRat'.
Searching Censys for the value DCRat in the subject common name yields 46 results. Drilling into the IP 203[.]104[.]42[.]92, the certificate details reveal that the subject common name is the same, but the issuer distinguished name is different.
Figure 17: X.509 certificate details for the IP 203[.]104[.]42[.]92
Unique values within certificate data can also be incorporated into detections. A blog by Corelight contains network signatures that focus on the content of the TLS certificate.
Figure 18: Corelight detections for AsyncRAT and other variants.
Conclusion
The ephemeral nature of IP addresses and domains means that they may not seem as valuable within threat intelligence and detection engineering as other artifacts. This is true to a certain extent, but analyzing IP addresses and domains can help researchers and analysts uncover additional detections useful in identifying additional IOCs or malicious activity.
Analysis of IP addresses and domain names can reveal patterns or unique identifiers, such as particular proxies being used to initiate connections. X.509 certificates contain specific values that allow security teams to detect additional suspicious or malicious data. Moreover, analysis can help cluster activity based on commonalities between artifacts to identify a particular threat or actor. The speed of sharing, ease of automation, and availability make these IOCs a component of a holistic threat intelligence program. When contextualized alongside other indicators higher up in the pyramid of pain, teams can gain valuable insights into threat actor behavior, which may lead to additional detection opportunities.
Albabat, also known as White Bat, is a ransomware that has been observed since late 2023. The ransomware binary is written in Rust and encrypts files based on a configuration file. Version 0.1.0 was first observed in November 2023, with version 0.3.0 identified in late December 2023. Version 0.3.3 was seen in January 2024. Newer versions of the ransomware target Windows but can also gather system information from Linux and macOS devices. A Trend Micro report from March 2025 states that the ransomware’s configuration data was hosted on GitHub and is retrieved during execution.
Security Research @JAMESWT_WT on X shared several samples of Albabat on Malware Bazaar. One such sample is also present on Any.Run and serves as the source for the content in this analysis. The blog explores the configuration file used by the Albabat ransomware version 2.0.0 to identify any commands the ransomware executes, what files are targeted, and details about the ransom note.
#Albabat Ransomware at @AnyRun with https://api.github[.com/repos/billdev1/abbt/contents/content/ config.json wpp.jpg icon.ico db.html
The sample contacts GitHub to download several files. The first file is the configuration file, which is a .json file. After that, the binary requests the Albabat wallpaper and icon along with a template of the ransom note.
Figure 3: Network Traffic showing connections to GitHub. The ransomware requests its config, wallpaper and HTML ransom note from GitHub.Figure 4: The Albabat wallpaper.
The icon file requested by the ransomware sample is just a bat logo that is also present within the wallpaper.
Figure 5: A CyberChef recipe used to decode the icon file that was requested from GitHub.
The binary also initiated requests to ifconfig[.]co and ipify[.]org. The first request is to ifconfig and is used to get geolocation about the IP, whereas the request to ipify just returns the public IP address of the device.
Figure 6: HTTP traffic to ifconfig[.]co showing the IP address and geolocation of the device.Figure 7: HTTP traffic to ipify[.]org returning the IP address of the device.
Details within the configuration file
Figure 8: Information within the configuration file indicates that this is version 2.0.0. Also present is a link to DailyMotion video.
To download the config.json file, the binary connects to GitHub using the user-agent Awesome App and a hardcoded authorization token. The connection is to a repo hosted by the user billdev1.
❗
The complete config.json file is present within Appendix 1.
💡
The Trend Micro blog on Albabat contains more details about the GitHub repo.
Figure 9: HTTP Traffic to GitHub showing the config.json file being requested.
The response to the request is a file included in base64 encoding format. The entire file is available within the content parameter. This file can be decoded using CyberChef, a web-based utility that allows analysts to manipulate or transform inputs based on a series of steps called a recipe; the short recipe we used to decode it is provided below.
Figure 10: Decoded configuration file showing command to device executed on Windows, Linux and macOS.
The config.json file also contains a link to a Dailymotion video. The video shows a user opening several files, which may be used to show that decrypted files open as intended. The link was opened in Any.Run and can be viewed here.
The config.json file contains connection information for a Postgres database. This database stores information exfiltrated from the compromised device.
Figure 11: Postgres Database connection details present within config.json.
The information consists of identifying information used to provide details about the device and the victim. The information stored within the database includes:
pin
key
extension
version
type_encryption
qtd_encrypted
paid_out
btc_address
ip
operational_system
av
machine_name
user_name
full_name
email
mac_address
cpu_name
motherboard_name
country
city
region_name
latitude
longitude
This connection takes place over port 5432/TCP.
Figure 12: Traffic to the Postgres server.Figure 13: TCP Stream showing details sent to the Postgres database. System information is added to the database via an insert command.Figure 14: System information exfiltrated from the compromised device.
The details sent to the database show that the files were encrypted using c20p1305 (ChaCha20 and Poly1305).
Commands Executed
Windows
The ransomware binary executes several commands on Windows devices to collect information, evade detection, and inhibit system recovery.
System Information Discovery
The binary uses wmic commands to collect information about the operating system, anti-virus software on the device, motherboard, CPU, and MAC address information.
Figure 15: Command hardcoded within the config.json. These are used to collect system information from Windows devices.
During execution, the binary also attempted to execute the net session command to identify all active sessions on the device.
Evade Detection
The ransomware sample attempts to tamper with Microsoft Defender by modifying several parameters using PowerShell. The sample attempts to:
Disable real-time monitoring
Require consent for all samples before they are submitted
Disable the auto-exclusion feature on the device
Disable controlled folder access
Stop sending information to Microsoft as part of the Microsoft Active Protection Service
Figure 16: Commands used to tamper with Microsoft Defender.
Inhibit System Recovery
The binary attempts to make it more difficult for users to recover impacted devices by deleting shadow copies, using bcdedit to modify the boot process to ignore errors, and disabling automatic Windows recovery features. Moreover, the binary modifies registry keys to disable Windows command line and task manager.
Figure 17: Commands that will be executed to prevent system recovery.
Linux
The commands run on Linux devices are to collect system information. These include gathering the OS version, motherboard details, CPU model information, and the device's MAC address.
Figure 18: System information commands that will be executed on Linux.
macOS
Similarly, the commands executed on macOS also collect information about the device. These commands include getting the product name, version, CPU type, and MAC address.
Figure 19: System information commands that will be executed on macOS.
Encrypting Files
The configuration file contains exclusions categorized as folders, file extensions, and files. These exclusions ensure that when the ransomware starts encrypting files, it only targets personal files and does not render the endpoint unusable. These are shown in Figure 20 below. The ransomware appears to encrypt files with a random file extension. The encrypted files in the sample we reviewed had the file extension .kZwtY8rR.
Figure 20: Exclusions specified within the config.json.
The folders ignored by the ransomware are:
Searches/
AppData/
$RECYCLE.BIN/
System Volume Information/
windows.old/
steamapps/
perflogs/
ansel/
tmp/
node_modules/
cache/
vendor/
target/
Mozilla/
venv/
Chrome/
google-chrome/
pypoetry/
vimfiles/
viminfo
site-packages/
scoop/
go/
temp/
The folders ignored by the ransomware are:
~$
.src
.ico
.cur
.theme
.themepack
.bat
.com
.cmd
.cpl
.prf
.icls
.idx.
.mod
.pyd
.vhdx
._pth
.hta
.mp3
.CHK
.pickle
.pif
.url
.ogg
.tmp
.dat
.exe
.lnk
.win
.vscdb
.bin
.cab
.inf
.lib
.tcl
.cat.
.so
.msi
.vpk
.vc
.ini
.bik
.sfx
.xnb
.ttf
.otf
.woff
.woff2
.vfont
.resource
.N2PK
.log
.pkg
.desktop
.dll
.pkr
.arc
.sig
.bk2
.arz
.swf
.qt
.wma
.mp2
.vdf
.pdb
.nfo
.whl
.mui
.srm
.dic
.lock
.pyc
.TAG
.locale
.store
.sdi
.library-ms
.acf
.po
.mo
The files ignored by the ransomware are:
ntuser.dat
ntuser.ini
iconcache.db
Thumbs.db
.DS_Store
Terminate Applications
The ransomware binary terminates several processes before encrypting files. The binary calls the taskkill command-line utility and passes the image name as a parameter to terminate processes, as shown in Figure 22. The configuration file separates the items to terminate into Windows processes, Linux processes, and Windows services.
Figure 21: Processes to be terminated across different operating systems.
The complete list of applications that the binary attempts to kill is shown below.
Windows Processes
taskmgr.exe
processhacker.exe
regedit.exe
code.exe
excel.exe
powerpnt.exe
winword.exe
msaccess.exe
mspub.exe
msedge.exe
virtualboxvm.exe
virtualbox.exe
chrome.exe
cs2.exe
steam.exe
postgres.exe
mysqlworkbench.exe
outlook.exe
mysqld.exe
windowsterminal.exe
powershell.exe
cmd.exe
sublime_text.exe
microsoft.photos.exe
photosapp.exe
Linux Processes
code
chmore*
Windows Services
VBoxSDS
We believe that the chmore process listed in the Linux processes is a spelling error and that the threat actor wanted to terminate the Chrome process.
Figure 22: The binary uses the taskkill command to terminate running processes.
The ransomware sample uses a hardcoded public key within the config.json file for encryption.
Figure 23: Hardcoded RSA Public Key present within the config.json file.
❗
A text-based version of the RSA key is available within Appendix 3.
The config.json file also contains other settings used by the binary during encryption. These settings include whether or not to open the ransom note, deploy it in multiple directories, and kill specified processes.
Figure 24: Other parameters present within the config.json. These are related to encryption parameters and whether or not to terminate processes.
Apart from the excluded directories, file extensions, and file names mentioned above, the ransomware iterates through a device's drives and encrypts files within each drive. Moreover, the config.json also contains paths for database locations targeted for encryption.
Figure 25: File paths that are targeted for encryption.
The config.json file also specifies the locations where the ransom note will be dropped.
Ransom Note Analysis
The ransomware note is an HTML file with multiple pages. The first page contains all the relevant details for the victim. Upon opening the ransomware note, the victim is presented with a table that includes their PIN and the file extension used during the encryption process. The PIN is a unique identifier used to identify the victim during conversations with the threat actor.
❗
The complete ransom note is provided in Appendix 2.
Figure 26: The ransom note contains the extension used by the ransomware and a unique PIN.
Further down the page is a description of Albabat ransomware and some information about the folders it created. The ransomware drops four files in a folder under the current user’s profile. These are:
The ransomware note
Logger.log
Ping.txt
Wallpaper.jpg
The logger.log file will contain a list of all the encrypted files. In our case, this file was empty.
The README file also outlines that the PIN will be used within the decryption key and serves as a unique identifier.
Figure 27: Details about how the PIN is used.Figure 28: Details about the logger.log file and the encrypted files.
The ransomware note specifies that communication occurs predominantly via Session, a secure messaging application. The ransom note contains a Session ID to communicate with the ransomware operators. Apart from the chat ID, the ransom note lists a Mail2tor email.
Figure 29: Contact details present within the ransom note. These were also present in the config.json file.
Following the contact information is all the payment information required to pay the ransom.
Figure 30: Payment information include Bitcoin addresses within the ransom note.
The last section of the ransom note’s main page is about decryption. This outlines how to use the decryption tool to decrypt files.
Figure 31: The ransom note contains details about the decryptor and its usage.
The other pages of the ransom note are an FAQ page, a credits page, and a translator function that leverages Google Translate to translate the ransom note from English into a language of the victims' choosing.
Figure 32: FAQ page present within the ransom note.Figure 33: Credit pages listing the name of the developer.Figure 34: Google Translate is used to translate the ransom note to different languages.
💡
ID Ransomware is a great tool for identifying ransomware based on the ransom note, encrypted file, or contact information provided.
Bitcoin Wallet Analysis
The configuration file contains a Bitcoin address and the ransom amount (Figure 8) mentioned in the ransom note as shown above. As of May 7th, 2025, 17:00 EST, this wallet contained no bitcoins, and several tools that track cryptocurrency transactions indicate no associated activity for that address.
Figure 35: The Bitcoin address mentioned in the ransom note does not contain any Bitcoin nor does it have any transactions.
Security vendor WatchGuard has a page on Albabat ransomware, which includes several details about the ransomware and screenshots of its ransom note. WatchGuard’s page lists a different Bitcoin address from the sample. This address also has no transactions associated with it and is empty.
Moreover, WatchGuard’s report lists the ransom demand as 0.0016 BTC, whereas the configuration file hosted on GitHub demands 0.0018 BTC.
Figure 37: WatchGuard's page on Albabat mentions that the group was asking for 0.0016 BTC. Source: WatchGuard
Trend Micro’s blog on Albabat indicates that the ransomware is still under development, with researchers finding a config file for version 2.5.0 of the ransomware. A notable difference in this config file is the inclusion of other cryptocurrency addresses and a new Bitcoin one. The configuration file indicates that the operators behind Albabat will now accept payment in Bitcoin, Ethereum, Solana, and BNB.
Figure 38: config.file for Albabat version 2.5.0 includes additional cryptocurrency wallets. Source: Trend Micro
Conclusion
Albabat version 2.0.0 uses a configuration file hosted on GitHub to determine what files to encrypt, processes to terminate, and Postgres connection information. This configuration file also contains details used to create the ransom note. Public reporting of version 2.5.0 highlights the threat actor's continued use of the config.json file and how it has moved to accept additional cryptocurrencies as payment mechanisms. The config.json file potentially allows the threat actor to expand capabilities or modify how it operates without rebuilding the binary itself.
Recommendations
Maintain regular backups
Backups of critical data can be used to mitigate the risk of ransomware by allowing organizations to restore key systems with minimal data loss.
For backups to be effective, they must be taken frequently, and restoration processes must be tested regularly.
Establish Vulnerability Management Practices
All devices should be regularly scanned for vulnerabilities, and any found should be patched based on their vulnerability and asset criticality.
Risk registers should be used to track software and assets that cannot be patched, and other risk mitigation strategies should be considered.
Incident Response Plans and Preparedness
As ransomware remains a significant threat to organizations worldwide, an incident response plan is crucial for effectively detecting, containing, and mitigating security breaches when they occur.
This plan should outline which parties should be involved in the response, what actions should be taken, and at what point additional stakeholders should be involved.
In addition to having an incident response plan, organizations should go through incident response tabletop exercises to ensure stakeholders are familiar with the plan and their role during an incident.
💡
CISA offers various "Cybersecurity Scenarios" Tabletop Exercise Packages for different cyber threats.
Rilide is an example of an information stealer masquerading as a browser extension. First reported in April 2023, the malware targets Chromium-based browsers such as Google Chrome and Microsoft Edge. It is designed to take screenshots of information, log passwords, and collect credentials for cryptocurrency wallets.
Rilide is delivered via malicious advertisements or phishing pages. When users interact with these payloads, a loader installs the Rilide extension. Security researchers have observed Rilide impersonating Google Drive and Palo Alto extensions. Associated IoCs can be accessed using Pulsedive’s Explore feature.
This blog outlines:
How Rilide is delivered
Walkthrough of an intrusion chain that dropped Rilide
Mitigation strategies
How Rilide is Delivered
Threat researchers have identified multiple delivery mechanisms used to drop Rilide, with phishing websites being the most common. Versions from August 2023 were adapted to work with Chrome Extension Manifest V3. These changes include removing the ability to execute external logic using executeScript(), eval(), and new Function(). Moreover, Manifest V3 no longer allows developers to load and execute remotely hosted files; as such, all the logic must be part of the extension package itself.
The newer Rilide versions were delivered using three different mechanisms.
The first campaign uses a PowerPoint lure with a phishing website to fetch the Rilide stealer.
The second campaign leverages Twitter as the initial lure. When interacting with the Twitter lure, the user is redirected to a phishing website that downloads an executable file that sets up the malicious extension using an LNK file.
Researchers at Trustwave grouped two separate vectors into a third campaign. One intrusion chain is similar to the second campaign, with the only exception being the use of Google Ads instead of Twitter. The rest of the intrusion chain remains the same. The last intrusion chain uses a PowerShell loader to install Rilide. It is unclear how the user receives the PowerShell Loader.
Figure 1: Campaigns leading to Rilide. This version of Rilide has been adapted to comply with the Chrome Extension Manifest V3 requirements. Source: Hacker News
The sample we analyzed for this blog belongs to campaign 3, which uses a PowerShell loader to install the malicious extension.
An Intrusion Dropping Rilide
A PowerShell Dropper
Toward the end of November 2024, VMRay shared details about a PowerShell script used to drop a Rilide sample. As of March 15, 2025, VirusTotal indicates that only four vendors flag the script as malicious. The earliest sample in the intrusion chain starts with the PowerShell script identified by VMRay; however, the exact way the script was delivered to the user is unknown. Figure 2 shows the complete intrusion chain observed during analysis.
Figure 2: Intrusion chain observed during analysisFigure 3: VirusTotal results for the PowerShell script as of March 15, 2025. Source: VirusTotal
When the PowerShell script is run, it launches another PowerShell instance that executes base64 encoded commands without displaying the PowerShell window to the user.
Figure 4: Encoded PowerShell command captures within VMRay. Source: VMRay
The base64 encoded content can be decoded using CyberChef’s From Base64 recipe. The decoded content contains a base64 encoded string, which is manipulated by replacing characters and XOR operations before being passed to the PowerShell function DownloadString as the URI.
Calling the parameter that holds the ASCII values for the URI returns the array string shown in Figure 6 below.
Figure 6: ASCII values holding the second stage domain
The array of ASCII values can be decoded using the PowerShell command $mdKyK = [System.Text.Encoding]::ASCII.GetString($CJC2W); or using CyberChef’s From Decimal recipe.
Figure 7: The ASCII values converted into text to reveal the second stage URI.
WHOIS data for the decoded domain shows that it was registered with NameCheap. Moreover, the domain was registered on October 5, 2024, approximately a month before the post from VMRay.
Figure 8: WHOIS data within the Pulsedive platform for tcl-black[.]com
The domain was unreachable as of March 15, 2025, but historical data was stored on URLscan.io. The webpage contained obfuscated code that the PowerShell script manipulates by replacing certain characters before converting it from base64. Once the command is decoded, it is executed using PowerShell.
Figure 9: A historical scan showing the content hosted on the decoded URL. Source: URLscan.io
The character conversations employed during this stage are:
Original Value
New Value
!
l
*
d
`”
T
‘
H
;
F
Figure 10: Decoded content from tcl-black[.]com reveals additional PowerShell Commands
Second Stage
The decoded script contains another blob of base64 that goes through a series of manipulations before being executed using the iex command. The first manipulation is a series of character replacements that change certain symbols into characters within the base64 character set. The replacements are:
Original Value
New Value
%
d
$
a
!
b
@
B
This data is converted from base64 and XORed with a byte array. Following the XOR operation, the data is decrypted using AES256 in Cipher Block Chaining mode with a padding of PKCS7. The decryption key and initialization vector are stored as hardcoded variables that are base64 encoded.
Figure 11: The decoded PowerShell script pulled from tcl-black[.]com
Third Stage - Setting up Rilide
The decrypted data is additional PowerShell code that is executed. This code is used to install the Rilide extension. The PowerShell script's primary function is FCZoL, which first attempts to gather the current user's SID.
Figure 12: Decrypted content from the second stage PowerShell Script that shows additional PowerShell commands.Figure 13: The script uses PowerShell cmdlets to get the local user
The script then generates a random string that is 80 characters long and consists of alphanumeric characters. The following line of the script converts a string of bytes into a UTF-8 encoded string. This string contains a base64 blob containing JSON data that appears to be related to the Rilide extension.
Figure 14: Character set returned from a function within PowerShell.Figure 15: Base64 content reveals content that is later added to the Secure Preferences for managing settings for a Chrome Profile. Figure 16: Extension details added to Secure Preferences.
The PowerShell script then creates strings that hold paths to web browsers. The browsers targeted, and the paths specified in the malware are:
Figure 17: PowerShell code used to create paths to web browser content on disk.
Web Browser
Path
Chrome
%localappdata%/Google/Chrome/User Data
Brave
%localappdata%/BraveSoftware/Brave-Browser/User Data
Edge
%localappdata%/Microsoft/Edge/User Data
Opera
%appdata%/Opera Software/Opera Stable
The PowerShell script contains all the content that makes up the Rilide files as hardcoded base64 strings. These strings are within the function aRUC2M. This function takes the previously created character set and the directory name where the extension will be stored. In this case, the directory name is $MxNC2$JJ0wH, as shown in the figure below.
Figure 18: Path where the Rilide files are saved on disk.
The script attempts to create the path shown in Figure 18 and then tries to create files within that directory.
Figure 19: Code used to create the $MxNC2$JJ0wH directory and drop the Rilide files.
Each file that makes up the Rilide extension and its content is stored as base64-encoded pairs. The first variable is the file name, and the second is the actual content. The script writes the file for any file name containing the extension *.png. If the file is contains the string manifest.json, a set of character replacements occurs before it is written to disk. For all other files, the script just writes the content to a file on disk.
The last step in the PowerShell script is to add the extension to the different web browsers specified within the script itself.
Figure 20: Function calls to add the Rilide extension to the targeted web browsers.
Before installing the malicious extension, the PowerShell script terminates any running instances of the web browsers targeted before the extension is enabled. The extension is installed only for the user who is logged in when the script is running. It then attempts to modify the Secure Preferences or the Preferences file (for MSedge) within the Default or Profile subdirectories. The content shown in Figure 16 is updated to reflect the path shown in Figure 18. Once this modification occurs, it is added to the Secure Preferences JSON file. The script also checks if the extension is installed; if it is, the content is updated to API content extracted by the script. Otherwise, it adds the content to the file.
Figure 21: Code used to add the content shown in Figure 16 to files used by the web browsers. This is used to add the extension to the web browser.
Once the extension path is added to the preferences file, the PowerShell script waits 4 seconds before launching the web browser.
Figure 22: The content from Figure 16 is updated to reflect the path to Rilide. The path was previously shown in Figure 18.
Rilide Browser Extension
Like TrustWave's reporting, the malware masquerades as a Google Drive utility that claims to save content to Google Drive. The extension's permissions indicate that it can interact with cookies, clipboard data, and system information. Rilide uses injected scripts to steal credentials and cryptocurrency and take screenshots.
Figure 23: Functionality present within Rilide. Source: Hacker News
The extension masquerades as a Google Drive utility that aims to help users save content to Drive. This is indicated by the name and description specified in the manifest.json file and the extension’s icon.
Figure 24: A screenshot showing Rilide installed in Google Chrome.Figure 25: Details about the Rilide extension within Google Chrome.Figure 26: The malware uses the Google Drive icon as its icon.
The main files in the extension are:
config.js
manifest.json
rules.json
ico.png
src/ToggleTest.js
src/content/OpenRemove.js
src/content/AlertReceive.js
src/content/Release.js
The extension’s directory contains other JavaScript files with helper functions that expand its functionality. These files are essential to the three scripts injected into each webpage.
Figure 27: Files within the Rilide directory.
manifest.json
The extension’s manifest.json shows that the extension can query system information such as CPU and storage information. It can also access the browser’s local storage. Moreover, the extension allows access to the clipboard for reading and writing capabilities. The service worker is a file called ToggleTest.js. The extension injects three scripts into every webpage, collecting information from the pages. The scripts are:
OpenRemove.js
AlertReceive.js
Release.js
Figure 28: Content of the manifest.json fileFigure 29: The manifest.json file shows the injected scripts and declarative_net_request specifications.
💡
For more information about how Browser Extensions work, please read our blog.
The rules.json is specified as part of the declarative_net_request objects, an API that blocks or modifies web requests. In this case, the API adjusts the content security policy to help remove headers.
rules.json
Figure 30: The rules declared within the rules.json that are used to remove content security policies.
The rules.json file is used to modify headers in network requests and removes any content security policy values set by the web pages.
config.js
Figure 31: Configuration parameters for Rilide, including the ability to set up a Telegram C2 channel.
The config file contains references to Telegram and Web-based panels. However, this sample does not appear to have a Telegram panel, as shown by the lack of details within the TelegramPanel object.
ToggleTest.js
ToggleTest.js is a heavily obfuscated file that imports functions from other JavaScript files. The file call functions to collect system information, execute commands, and take screenshots.
Figure 32: Functions imported by the service worker, ToggleTest.js, to expand its functionality.
OpenReceive.js
This file was heavily obfuscated and used event listeners to collect messages from cryptocurrency exchanges and other websites, such as Facebook and Google Pay. Before grabbing information, the malware checks local storage in the web browser to obtain settings used to gather what information Rilide collects.
Figure 33: Code used to create event listeners that look for cryptocurrency details.
AlertReceive.js
The AlertReceive.js file is used to read and write text from the clipboard.
Figure 34: Code used to interact with the clipboard.
Release.js
This file collects content from email applications. The injected code checks whether the web page is Outlook, Yahoo, or Gmail. Once the email application has been identified, the script examines the DOM content on the web page to collect information about the emails.
Figure 35: Deobfuscated code from Release.js that looks for Outlook, Yahoo, and Gmail pages.
Research from Trellix outlines that Rilide looks for messages from cryptocurrency exchanges and modifies their content to collect credentials from users when they attempt to log in to the exchange.
Figure 36: Notes from Trellix indicate that Rilide modified emails to lure users into signing into their cryptocurrency accounts. Source: Trellix
Network Traffic
💡
A packet capture of Rilide network traffic and SSL decryption keys are provided as a reference.
Rilide queries different blockchain services to obtain the C2 server, which is stored as a base58-encoded value in another cryptocurrency address. The blockchain services queried include:
Blockstream
Bitcoin Explorer
Blockcypher
Mempool
Bitcore
The Bitcoin address that the malware looks up is bc1qkljhfktumxjqa52yle0xzz9nd4jl40vzyyc066.
Figure 37: Cryptocurrency transaction to the BitCoin address the malware looks up. Source: Blockchain.comFigure 38: Requests to blockstream.info that return another BitCoin address that also doubles as the C2 address for the malware. Figure 38: Requests to Blockcypher showing the second BitCoin address.
The address is 1Aybhtfb3TM36MDmULVXJVAFni8V8tR4aS and decodes to the C2 server memento-mori[.]com
Figure 39: The second BitCoin address can be decoded into the C2 domain using base58.
C2 Communication
Once the C2 server has been identified, the extension starts exfiltrating information back to it. The malware returns system information data to the C2 server via a POST request to the URI /api/machine/init.
Figure 40: System information exfiltrated by Rilide.
The information includes:
CPU details
Operating System information
Display information
Extension details
Other commands observed within network traffic include:
/api/machine/injections
/api/machine/commands
/api/machine/settings
/api/machine/clipper
/api/machine/screenshot-rules
/api/machine/set-command
Figure 41: Phases returned by the C2 used to determine what information Rilide targets. This command also returns a reverse proxy address if the malware uses one.
Mitigations
Extension Management
Avoid installing extensions from untrusted sources or third-party websites.
While using Browser Extensions Stores significantly reduces the risk of downloading malicious extensions, it does not eliminate the risk. Our blog, Compromised Browser Extensions - A Growing Threat Vector, highlights compromised extensions on the Chrome Store.
Users should review permissions used by extensions before installing them.
Users should periodically review installed extensions to identify any that are no longer needed and remove them.
The table below contains a subset of additional Rilide network IoCs that have been added to the Pulsedive platform. This data can be queried in Pulsedive using the Explore query threat=Rilideand is available for export in multiple formats (CSV, STIX 2.1, JSON).
Browser extensions often improve user experience and allow users to work more efficiently. Sources estimate that the Chrome Extension store hosts over one hundred thousand unique extensions:
Site DebugBear reported 111,933 extensions in August 2024
chrome-stats lists the number of extensions as high as 145,316
Regardless of the exact number, most users have several extensions installed within their browsers. These can stem from Ad blockers, citation generators, or punctuation or writing aides.
While most extensions provide value to users, there have been several cases of malicious browser extensions being used to target users. There are different ways by which threat actors deploy malicious browser extensions. The first is compromising existing plugins by exploiting vulnerabilities or compromising developer accounts. This gives a threat actor access to an existing plugin and its code, which can be modified to include malicious capabilities such as keylogging. This is how malicious code was added to the Cyberhaven extension, which is covered in-depth below. Similarly, compromising upstream libraries used by browser extensions may allow a threat actor to deploy code to benign plugins. Lastly, threat actors can design malware that operates as a browser extension. Rilide is an example of an information stealer deployed as a browser extension.
This blog outlines:
How browser extensions work
Details about the compromised extensions identified at the beginning of January 2025, including the Cyberhaven and GraphQL Network Inspector extension
Mitigation strategies for home and corporate environments
While this blog examines compromises from January 2025, these are just a few examples in recent years where malicious browser extensions have been found. We expect to continue observing malicious browser extensions in the wild and recommend proper permissions review and policy enforcement to mitigate risks.
How Browser Extensions Work
Browser extensions are small software applications that provide additional functionality and capabilities within a web browser. Browser extensions are usually written in HTML, CSS, or Javascript. Chrome extensions may consist of several items, including:
A manifest file
Service workers
Content scripts
Toolbar action
Side Panel
DeclarativeNetRequest
An explainer on the parts of the Chrome Extension is available here.
Manifest File
The manifest file is a JSON file within the extension’s dirextension's provides essential information about the extension and the files it uses. Figure 1 below contains the manifest file for the Chrome extension OneTab.
Figure 1: manifest.json file for OneTab.
OneTab is a productivity plugin that converts all tabs open in a browser into a list, saving memory by reducing the number of tabs open at any given time. The tabs can be opened from the list as required by the user. The manifest file shows the name of the extension along with a description. It also includes any scripts that are run in the background. Content scripts or service workers are where the extension’s functionality is defined. In the case of Figure 1, the manifest includes a reference to the service worker ext-onetab-concatenated-sources-background.js. The manifest file also consists of the list of permissions that the extension uses.
The action API controls the extension’s icon in the browser’s toolbar. The action must be specified in the manifest.json to use this API. In Figure 1, the action defines the default_icons array, a set of images from which one is displayed as the extension's icon in the browser's toolbar.
Service Workers
Service workers are event handlers used by the extension. These scripts run in the background and handle events. Chrome’s developer documentation mentions that these do not have access to DOM content.
Content Scripts
Content scripts are files run on web pages. These use the DOM to read details about the web page, make changes to them, and collect information. Statically declared scripts are listed in the manifest.json file under the content_scripts key.
Figure 2: Content scripts as defined in the manifest.json for the Zotero extension.
Statically defined scripts need a matches key to determine if the script will be injected into the page. The run_at key indicates when the scripts will be injected into the page. The three values here are:
document_start: script is injected after any CSS files but before DOM is created
document_end: script is injected after DOM is complete but before resources like images and frames are loaded
document_idle: The browser chooses when the script is injected between the document_end and the window.load event triggers.
Viewing Extension Files
Installed extensions are stored in a subdirectory within the profile path defined for Chrome for a particular user. In most cases, the location will be:
Extensions are saved by their extension IDs, as shown in Figure 3.
Figure 3: Chrome extensions installed on a Windows device.
Two ways to get the name of the extension:
Open the extension directory and view the manifest.json
Go to the extensions page in the browser -> enable Developer Mode -> IDs should be visible for each extension.
January 2025 Compromised Browser Extensions
The new year started with reports identifying at least 33 compromised Chrome browser extensions. A FieldEffect blog indicates that over 2.6 million users were impacted, and the compromised extensions were used for up to 18 months. One compromised browser extension was from Cyberhaven, a Data Loss Prevention software provider whose extension prevents users from entering data into unauthorized platforms.
Cyberhaven has released extensive details about how the compromise occurred and what they uncovered from their investigation. Access was obtained through a phishing email that targeted the extension's developers. The email claimed to be from the Chrome Web Store and outlined items that violated Google’s policy and threatened to remove the extension from the Chrome Web Store. Users who interacted with the email granted OAUTH permissions to the malicious application. Once the malicious application was granted access, the threat actor used it to upload the malicious Cyberhaven extension to the Web Store.
Figure 4: Attack chain observed in the Cyberhaven CompromiseFigure 5: Content of the phishing email sent to Cyberhaven developers Figure 6: The login prompt launched when the developers interacted with the email, as shown in Figure 5. - Source: CyberhavenFigure 7: Request to grant an extension access. This was used to publish the malicious version of the Cyberhaven extension. - Source: Cyberhaven
The malicious Cyberhaven was identified as version 24.10.4 and was similar to previous benign versions of the extensions with some minor additions. The additions allowed the extension to reach out to a command and control server to download configurations and collect data from hard-coded websites. Based on an analysis of the malicious files, the threat actors only sought to collect information from domains related to facebook.com.
💡
While the configuration file downloaded from the C2 server only contained Facebook domains, the threat actor could have modified this at any point to expand their collection capabilities.
Compromised Extensions
Including Cyberhaven, 20 extensions were compromised as part of this campaign. News outlet Ars Technica published a list of the compromised versions and their identifier values for reference. A subset of the compromised extensions are listed below. The extensions below all targeted information.
Extension Name
ID
Version
VPNCity
kkodiihpgodmdankclfibbiphjkfdenh
2.0.1
Parrot Talks
kkodiihpgodmdankclfibbiphjkfdenh
1.16.2
Uvoice
oaikpkmjciadfpddlpjjdapglcihgdle
1.0.12
Internxt VPN
dpggmcodlahmljkhlmpgpdcffdaoccni
1.1.1
Bookmark Favicon Changer
acmfnomgphggonodopogfbmkneepfgnh
4.0.0
Castorus
mnhffkhmpnefgklngfmlndmkimimbphc
4.40
Wayin AI
cedgndijpacnfbdggppddacngjfdkaca
0.0.11
Search Copilot AI Assistant for Chrome
bbdnohkpnbkdkmnkddobeafboooinpla
1.0.1
VidHelper - Video Downloader
egmennebgadmncfjafcemlecimkepcle
2.27
Cyberhaven security Extension v3
pajkjnmeojmbapicmbpliphjmcekeaac
24.10.4
AI Assistant ChatGPT and Gemini for Chrome
bibjgkidgpfbblifamdlkdlhgihmfohh
0.1.3
Bard AI Chat
pkgciiiancapdlpcbppfkmeaieppikkk
1.3.7
GraphQL Network Inspector
ndlbedplllcgconngcnfmkadhokfaaln
2.22.6
A further 13 compromised extensions were also identified. However, these looked to capture data that could related to payments. Secure Annex released a spreadsheet of the compromised extensions split by code similarities in the malicious versions.
💡
This technical analysis by John Tuckner at Secure Annex provides more details about these 13 extensions.
Cyberhaven Investigation Results
💡
A report released by Booz Allen Hamilton outlined findings based on their malware analysis of the compromised extension.
Cyberhaven’s investigation indicated that the only compromised version of their extension was version 24.10.4, consisting of worker.js and content.js files. The worker.js file was used to establish communication with the C2 server and download configurations from it. The content.js file was used to collect information on websites. The content.js file was static injected into all URLs before creating the DOM.
Figure 8: Differences in the manifest.json between the malicious version and the clean version - Source: Booz Allen Hamilton
The content.js decodes base64 encoded data from a file called `config-block.txt`. The config file contained references to Facebook domains and the C2 used by the extension.
Figure 9: Service worker script that connects to the C2 server to download a configuration file - Source: Cyberhaven
GraphQL Network Inspector Extension Analysis
Sekoia also identified that version 2.22.6 of the GraphQL Network Inspector extension was compromised. Similar to the compromised version of the Cyberhaven extension, this extension includes malicious Javascript files - background.js and context_responder.js.
💡
The malicious files are available as gists on GitHub and in the appendix at the end of this blog.
background.js operates as a service worker. It downloads a configuration from the C2 server and stores it in the browser’s storage. The configuration includes a list of URLs to target. Unlike in Cyberhaven, where the threat actor targeted Facebook, the URLs are related to ChatGPT.
Figure 10: Decoded configuration file - Source: SekoiaFigure 11: background.js for the GraphQL Network Inspector Connector has similar code to the malicious Cyberhaven extension service worker shown in Figure 9 - Source: Sekoia
The code to download the configuration from the C2 is the same as the Cyberhaven one, except for the C2 URL and the full name of the storage key.
Similarly, the context_responder.js file is injected into all pages and used to decode the configuration downloaded from the C2 server.
Figure 12: The context_responder.js file decodes data from the configuration file (Content has been truncated). Source - Sekoia
Mitigation Strategies
For Home Users: Being aware of what extensions are enabled and the permissions they grant is often the best way to prevent malicious extensions. Consider only installing essential extensions. Before installing any extension, review the permissions it requires and the details in the privacy section of its web store listing. Users can also use information on the web store, such as the number of users, owner, reviews, and last update time, to gain more information about the extension and its overall trustworthiness. Moreover, users should periodically review installed extensions to identify any that are no longer needed and can be removed.
For Corporate IT teams that control web browser settings for employees can use tools like Intune to enforce policies determining what extensions can be installed. Before restricting browser extensions within an environment, it would be beneficial to identify what extensions are currently used within the organization. This will allow teams to determine which extensions are required for business use.
The following steps can be used to deploy an Intune policy to restrict extensions on Chrome.
Open Intune Admin Center
Navigate to the devices section
Go to Manage Devices -> Configuration
Create a Policy
Select the platforms to apply the policy to
Provide a name and description
Click on `Add Settings`
Search for `extension installation blocklist`
Click on the application (for example, Google)
Check the option to configure a blocklist
Deploy a blanket block list using wildcards
Configure an allowlist and enter the extension IDs that are allowed
💡
Jeffrey Appel’s blog on checking and blocking browser extensions via Defender and Intune offers additional details on configuring policies that can be applied to Microsoft Intune.
Rilide At a Glance - An Information Stealing Browser Extension
Rilide is an example of an information stealer masquerading as a browser extension. The malware, which was first reported in April 2023, targets Chromium-based browsers such as Google Chrome and Microsoft Edge. It is designed to take screenshots of information, log passwords, and collect credentials for cryptocurrency wallets.
Rilide is delivered via malicious advertisements or phishing pages. When users interact with these payloads, a loader installs the Rilide extension. Security researchers have observed Rilide impersonating Google Drive and Palo Alto extensions. Associated IOCs can be accessed using Pulsedive Explore.
While analysts can individually analyze files, that process takes time and may require a plethora of tools. Having a single source that provides an automated approach to initial analysis and detection mechanisms allows analysts to sift through noise and focus on files that require more attention. This is where Assemblyline, an open-source tool created by the Canadian Center of Cyber Security (CCCS), comes in. Assemblyline allows files to be scanned with various tools (called ‘services’) within the platform and for information about the files to be collected in one place. This blog explores:
What is Assemblyline?
Installing Assemblyline using Docker
Maldoc analysis using Assemblyline
What is Assemblyline?
Assemblyline is an open-source malware detection tool that allows cybersecurity analysts to triage files within a single platform quickly. The tool consists of different modules called services that collect information about the file and can be used to alert on suspicious artifacts. The key benefit of a tool like Assemblyline is that it tags submissions with results from services as it is being analyzed and can detect duplicate submissions. Moreover, the tool assigns a score to each file based on the information collected. This score can be used to identify malicious files or files that may warrant further investigation.
Who should use Assemblyline? Assemblyline is ideal for security research and defense teams, threat researchers, and incident response professionals who need to automate and streamline the analysis, classification, and prioritization of malware samples. It is especially helpful for security teams handling large volumes of malware and seeking a scalable, customizable solution for efficient triage.
Services Available within Assemblyline
Services are modules available within Assemblyline that analyze the submitted file and extract items that may indicate maliciousness. Services fall under two categories: Assemblyline services and community services.
Assemblyline services are services or modules bundled with the Assemblyline build and are maintained by the Assembyline development team.
Community services have been created by the community to augment existing functionality.
Assemblyline Services
The table below contains an overview of some of the services maintained by the Assemblyline team. The complete list, along with links to the service manifests, are available here.
Service Name
Description
Batchdeobfuscator
Deobfuscates batch files
CAPA
Tool that identifies capabilities in executable files
ConfigExtractor
Extracts malware configurations including list of C2
CAPE
Sandbox for dynamic malware analysis
DeobfuScripter
Static script de-obfuscator
Floss
Extracts obfuscated strings within files
Oletools
Tools that extract data from OLE and XML documents
PeePDF
Python based tool to analyze PDF files
Suricata
Network based detections for scanning network captures
Note: The GitHub Repos for services created by NVISO indicate that they have been archived and may not be under active development. As such, they may refer to older versions of Assemblyline.
Details on how to build a community service are available here.
Installing and Configuring Assemblyline
💡
Assemblyline is also available on AWS as a subscription that can be deployed with minimal user interaction.
Assemblyline can be deployed on a single instance or in a clustered environment. The way in which a team chooses to deploy Assemblyline depends on its objectives. CCCS claims that both deployment mechanisms have the same analysis capabilities, but clustered environments scale better whilst offering redundancy and failover capability.
❗
Certain external resources will need to be run on external sources.
Figure 1 below compares the features of the different deployment mechanisms:
Figure 1: Feature Comparison of the different Assemblyline Deployment Mechanisms. Source: Installation Manual
Installation Steps
The instructions below are from the Docker Installation Guide for Assemblyline:
Figure 2: A Kibana dashboard used to display metrics of an Assemblyline instance.
The deployment steps are the same, except for which directory gets copied into the folder. The minimal_appliance directory will only setup Assemblyline while the full_appliance directory will also setup ELK for monitoring:
💡
In this walkthrough we deployed to the directory ~/deployments; users can deploy to other directories, given that the file system has sufficient space for the installation.
mkdir ~/deployments
cp -R ~/git/assemblyline-docker-compose/minimal_appliance ~/deployments/assemblyline
cd ~/deployments/assemblyline
To deploy Assemblyline and the ELK stack for metrics use the code snippet below:
mkdir ~/deployments
cp -R ~/git/assemblyline-docker-compose/full_appliance ~/deployments/assemblyline
cd ~/deployments/assemblyline
This will move config files into the deployment directory ~/deployment/assemblyline. The config/config.yaml file is pre-configured for use with docker-compose and the .env file contains all the default passwords.
Once the docker containers have fully been stood up, the services are up and running and can be accessed through the GUI. The web interface should be accessible on 127.0.0.1:443 using the default credentials specified in the .env located in ~/deployments/assemblyline.
If the web interface is not reachable through that address, check the logs to ensure that services are up and running and check the docker process using docker ps to see which port is being used by the nginx frontend.
Figure 10: Result of the docker ps command showing that the Nginx Web Server is available at 127.0.0.1:443Figure 11: Login Page for the Assemblyline Web UI.
Updating a Dockerized Assemblyline Instance
A Docker deployment of Assemblyline can be updated using the following commands:
cd ~/deployments/assemblyline
sudo docker-compose pull
sudo docker-compose build
sudo docker-compose up -d
Checking Logs
Assemblyline logs are separated into logs for the core components and logs for specific components.
For the core components:
cd ~/deployments/assemblyline
sudo docker-compose logs
For specific components:
cd ~/deployments/assemblyline
sudo docker-compose logs ui
MalDoc Analysis Example
One of the benefits of Assemblyline is that it keeps the results of multiple analyzers in one place, making it easy for analysts or responders to review results. In this example, we upload a Word document that uses remote template injection to download additional payloads.
The Word document is an agreement for enterprise services. When opened the file will connect to the hardcoded url in the relationship file _rels\document.xml.rels and load content from there. The hardcoded URL is used to load an RTF file from an adversary-controlled domain as shown in Figure 13.
Figure 12: Content of the Maldoc. Source: TriageFigure 13: Content of the _rels\document.xml.rels. The malicious RTF file is highlighted in yellow.
Once a user uploads the file to Assemblyline, it starts the analysis process where each service runs against the file and results are collated. The verdict is updated at the end of the analysis based on the information returned by the services.
Figure 14: Submission results of the malicious document once analysis is completed indicates the file is malicious.
Each submission is given its own unique identifier and the submission information shows details about the analysis features that have been selected. Users can choose which services to use in an effort to speed up scans and adjust priority.
Under the Submission Information section, is Heuristics which outlines the results of the analysis.
Figure 15: The Heuristics section indicating a known IOC was identified and content within the XML files were identified as suspicious.
Here, the services identify an IOC that is part of a blocklist. Clicking on any of the heuristics will provide more information about the finding. In the case of Badlisted IOC, the results show that a domain that was within the document was part of the threatview.io domain blocklist.
Moreover, OLETools identify an external relationship within the document. The service identifies a hardcoded URL that would be used to establish a connection to a malicious domain.
Figure 16: The OLETools Service identified the IOC shown in Figure 13 within the XML files that make up the Word document.
Potential indicators of compromise are shown in a separate section on the submission page. The ‘Indicators of Compromise’ section can be used to quickly see any IPs, domains, or hashes related to the submitted file. In this example, the IOCs include the URL identified by OLETools and its domain. The tool also identifies several Microsoft URLs, but color-coded them green to indicate that they are not malicious.
Figure 17: All identified IOCs are color-coded based on their reputation. Green indicates that the value is likely benign.
When a user clicks on a particular IOC, the associated file will be highlighted. This can be used to streamline manual analysis flows by pinpointing which file a user should look into. Furthermore, the ’Files’ section highlights all the files identified within the sample. In our example, the Word document contains several XML files, one of which Assemblyline has flagged as malicious. Each file is extracted and run through the services for individual analysis. The results for these files can be viewed by clicking on the filename under the Files section.
When we dig deeper into the extracted file named 9177f499.xml we see where it originated from using the ancestry service. This tree illustrates the relations to the original file submitted and any services that generated findings.
Figure 18: The Ancestry service showing the relation of the XML file to the submission file.Figure 19: Each service is run on the extracted files. The FrankenStrings service identified several URLs within the XML file.Figure 20: The IOC identified in Figure 13 appears in a TI vendor
Assemblyline helps reduce the number of benign files that investigators spend time analyzing during the day. By running files through an automated pipeline of services, investigators can get a sense of what the file is doing prior to manual inspection and prioritize threats more effectively. This process, combined with the fact that the submission resultsare stored on a central platform, allows for the platform to serve as a single triage source for samples. For additional resources on Assemblyline and its capabilities, check out the references below.
This blog aims to highlight some of the major incidents and events in cyberspace in 2024. Looking back, it feels like 2024 flew by with a steady stream of issues constantly grabbing the attention of defenders (and the media). Apart from the continued targeting of public-facing sources such as firewalls and other networking appliances, this year will be remembered for law enforcement takedowns and the CrowdStrike outage.
Read on for a review of:
Our predictions for 2024 from last year
Key exploited vulnerabilities
Top malware
Outages
Law enforcement actions
Looking ahead to 2025
Pulsedive rewind
Recap
Looking back at our predictions for the year
Vulnerability and Exploitation Predictions
In 2023, we predicted that exploitation attempts against public-facing infrastructure and the rapid exploitation of these appliances will continue to increase in 2024. Unfortunately, this prediction appeared to come true, with several vulnerabilities within public-facing applications being exploited for initial access into environments being observed throughout the year. This blog's Key Exploited Vulnerabilities section below discusses some notable exploited vulnerabilities.
Ransomware Predictions
We expected ransomware to continue being one of the more prominent threats organizations faced in 2024. This was observed as ransomware attacks continued to grab headlines as threat actors targeted organizations worldwide. We also observed several groups deploying ransomware at healthcare organizations. Defenders and law enforcement had some success against ransomware, with takedowns against LockBit.
Key Exploited Vulnerabilities
💡
This section is not intended to serve as an exhaustive list of vulnerabilities exploited in 2024 but rather as a summary of some memorable ones that affected security teams.
Cleo File Transfer Software
On December 3rd, 2024, Huntress released a blog outlining the exploitation of Cleo Harmony, Cleo VLTrader, and Cleo LexiCom software, which led to unauthenticated remote code execution. Organizations use these file transfer software programs to share files with other users. Initially released as CVE-2024-50623, it was quickly discovered that the patches for this vulnerability did not mitigate the risk, and patches for CVE-2024-55956 addressed the issues.
CVE-2024-55956 allowed an unauthenticated threat actor to import and execute bash or PowerShell commands using the Autorun directory. This vulnerability allowed the attacker to access external infrastructure to download files used in post-exploitation attempts.
BleepingComputer reported that the Cl0p ransomware group used this vulnerability to exfiltrate data from organizations.
Figure 1: Cl0p confirms that they are responsible for intrusions that exfiltrated data from Cleo instances. Source: BleepingComputer
Exploitation of Public Facing Infrastructure
Threat actors heavily targeted networking software and file transfer appliances throughout 2024. These software and appliances are public-facing and may offer access to corporate environments. Because they are more accessible, they remain high-priority targets, and we observed threat actors rapidly exploit these vulnerabilities once they are made available.
Some of the notable vulnerabilities in public-facing software observed this year included:
CVE-2024-3400 - PAN-OS: Arbitrary File Creation Leads to OS Command Injection Vulnerability in GlobalProtect
CVE-2024-3400 is an arbitrary file creation vulnerability in the Global Protect feature of PAN-OS. It can lead to OS command injection and has been used to exfiltrate data from the server or run commands. Palo Alto tracked the exploitation of this vulnerability as Operation MidnightEclipse.
Figure 2: Level of exploitation as categorized by Palo Alto. Source: Palo Alto
CVE-2024-8190 is an OS command injection vulnerability in the Ivanti Cloud Services Application (CSA). For versions 4.6 Patch 518 and before, exploiting this vulnerability could allow an unauthenticated attacker to execute code remotely. CISA has added this vulnerability to its known exploited vulnerability catalog.
CVE-2024-47574 (FortiJump) - Authentication Bypass in FortiClientWindows
CVE-2024-47575, also called FortiJump, is an authentication bypass in Fortinet FortiClientWindows versions 7.4.0, 7.2.4 through 7.2.0, 7.0.12 through 7.0.0, and 6.4.10 through 6.4.0. This vulnerability allowed a threat actor-controlled FortiManager device to execute code against vulnerable FortiManager devices. Mandiant observed exploitation of the vulnerability as early as June 27, 2024.
Figure 3: An adversary-controller FortiManager being added to a victim's FortiGate devices. Source: Google
One of the year's biggest stories, CVE-2024-3094, is a vulnerability that affected the xz compression libraries in Linux distributions. The affected versions (5.6.0 and 5.6.1) of the xz libraries contained malicious code that allowed unauthorized access.
xz is a data compression format within Linux distributions. It helps compress and decompress large files into smaller sizes. The multi-stage backdoor is used to extract a shared object liblzma_la-crc64.fast.o, which is added to the compilation of the liblzma. The shared object replaced a function name, and when any process loads liblzma, the malicious code interferes with the function resolution process. OpenSSH’s RSA_public_decrypt function uses the liblzma, and the malicious code could be used to extract a command from the authenticating client’s certificate and use it for remote code execution.
Figure 5: How the compromised liblzma library could be used by sshd. Source: Akamai
Malware
This year, information stealers, like Agniane and Mystic Stealer, and other malware-as-a-service continued to be used against users and organizations. Information stealers served as the initial stages of intrusions, either collecting credentials or deploying other malware. Ransomware continued to be a major threat to organizations, with several groups targeting healthcare organizations and other critical industries.
Ransomware Targeting Healthcare
ALPHV targeted Change Healthcare, a revenue and payment management provider, in February 2024. 100+ million individuals had their data stolen in the attack, impacting the operations of healthcare organizations that used Change Healthcare. Change Healthcare appeared to pay a ransom of $22 million before ALPHV performed an exit scam, including deploying a fake law enforcement seizure banner on their data leak site.
Qilin targeted Synnovis with ransomware, which disrupted the operation of several NHS Trust locations in June 2024. For the NHS, Synnovis, a lab services provider, was hit with ransomware that disrupted their IT systems. The group was able to exfiltrate sensitive patient information, including names, dates of birth, NHS numbers, and test descriptions.
In May 2024, Ascension Health suffered a ransomware attack by Black Basta. The attack impacted hospital operations by taking Ascension’s MyChart, an electronic health record system, offline. While the service was down, healthcare professionals had to resort to manual documentation. Following an investigation, Ascension identified that 5.9 million individuals had their data stolen. The data exfiltrated during the attack included patient and employee names, as well as medical and payment information.
In addition to continuing ransomware attacks and identifying new malware types, malware authors continued experimenting with different methods of deploying their malware onto devices. One method that grew in popularity this year is ClickFix.
ClickFix
This social engineering tactic manipulates users into executing code on their devices. The user is presented with a document or a web page with a banner with instructions for the user to follow, similar to figures 6 - 8.
The banner will instruct the user to:
Launch the run dialog
Paste in content that is in their clipboard (an older version of ClickFix required the user to copy the malicious code, while newer versions automatically add it to the user’s clipboard)
Run the command
Figure 6: A ClickFix lure within a Word document. Source: McAfeeFigure 7: A ClickFix lure displayed on a web page. Source: McAfeeFigure 8: ClickFix lure that doesn't require users to copy commands. Source: Sekoia
CrowdStrike BSOD Outage
On July 19th, CrowdStrike pushed a detection update to its Falcon sensors. This update included a problematic configuration file that caused the Windows operating system to crash, causing users to observe the blue screen of death. Computers experiencing the blue screen of death caused this outage, which led to business disruptions as the impacted organization no longer had access to its devices.
Threat actors quickly took advantage of the situation by registering domains for phishing attempts. These phishing scams capitalized on the outage and operated by offering recovery software or processes in exchange for money. The goal was to get users to send the money or deploy malware.
Figure 9: IOCs related to the CrowdStrike BSOD incident can be found using the explore query threat=“Crowdstrike BSOD Impersonation”.
Figure 10: Banner placed on LockBit site after Operation Cronus. Source: Trend Micro
In February 2024, law enforcement agencies disrupted LockBit operations through Operation Cronus. This multi-agency investigation resulted in the freezing of over 200 cryptocurrency accounts tied to LockBit and the UK’s National Crime Agency (NCA) taking over the group's infrastructure. The investigation also led to the publication of details about the group using the seized infrastructure.
Figure 11: Results of Operation Cronus. Source: EuropolFigure: Law enforcement using LockBit's Data Leak Site to announce the disruption operation. Source: Trend Micro
Authorities also made decryption keys available, which helped victims of LockBit with recovery efforts. The decryption tool is available through NoMoreRansom.
In addition to the takedown efforts in February, the US Department of Justice announced charges against Rostislav Panev, a Russian and Israeli national, who was arrested in Israel on December 20, 2024. The DOJ press release indicated that Panev was responsible for developing the LockBit ransomware and maintaining technical infrastructure. The DOJ has also indicted Dmitry Yuryevich Khoroshev, who is thought to be LockBitSupp, the persona used by LockBit to communicate on forums such as XSS.IS.
While LockBit appeared to recover from Operation Cronus and was able to deploy ransomware at organizations throughout the year, the arrest of its developer may impact future operations. While the takedown of technical infrastructure benefits defenders and such law enforcement action should be applauded, arresting those behind these groups will significantly disrupt operations.
💡
For a recap of 2024’s cyber trends, we recommend reading BushidoToken’s “Top 10 Cyber Threats of 2024” blog.
We expect 2025 to be similar to 2024 regarding the types of threats defenders will have to deal with. Threat actors will continue to target public-facing applications and servers, and prioritizing patching these applications will become increasingly important. However, solely relying on patch management will not be sufficient, and a layered defensive approach is required to mitigate risks. This includes host—and network-based monitoring to identify anomalous processes and the traffic related to these applications.
Remote management and monitoring (RMM) tools were heavily abused in 2024, continuing the trend from prior years. These tools allowed threat actors to access environments and establish persistence while blending in. The use of tools already present within a victim’s environment will continue, requiring defenders to track tool usage and deploy policies through device management solutions to restrict access to authorized applications.
Finally, generative AI (Gen AI) is another avenue we expect threat actors to abuse heavily in 2025. We anticipate threat actors using Gen AI to create more effective social engineering lures and aid in developing malicious tools.
Pulsedive Rewind
As we close out the year, we also wanted to share a few of our highlights. In 2024, we strengthened our infrastructure and capabilities across our products. We were energized by our community of Pulsedive users and clients - some of whom we were lucky to meet at various events throughout the year. Check out what our team was up to, plus some of our favorite moments below.
New and Favorite Integrations
We added integrations with OpenCTI, ServiceNow, and Torq.
Your favorite integrations? Palo Alto Cortex XSOAR, Cisco SecureX, SpiderFoot, Tines, and pfSense pfBlockerNG.
Top Blogs
Our CyberChef tutorial and example walkthrough quickly became top blog. We hear you: expect more helpful guides on free resources and tools in 2025.
Threat Research: Loaders, Stealers, Ransomware, and More
With an unending cycle of threats, news, and vulnerabilities, it’s hard to stay on top of every development. We focused on providing clear summaries with unique insights to help analysts and researchers stay in the know. Here’s which threats piqued your interest the most:
This year, we presented our research on sharing at the SANS CTI Summit, volunteered in our local community’s SECONNJ and Alice in Cyberspace conferences, pulled back the curtains to share stories about the realities of bootstrapping at BSidesNYC, served on the CFP review panel for Cyberjutsu, donated licenses for live NOC demonstrations with our partner Cisco at BlackHat and RSA, and more. It’s always an amazing time meeting with users and clients from all over the world. Two of our recorded talks include:
In 2024, our team released improvements to our free add-on, introduced MFA to all users, improved our scanning infrastructure, updated our STIX/TAXII docs, and a bunch more in the backend. Up next, you can expect improvements to scanning performance, risk scoring, searchable properties, and downloadable content from scans.
We can’t say it enough: feedback from our community keeps us motivated and committed to making Pulsedive better every year. When we get messages out of the blue like “I just want to send a HUGE thank you and congratulations to all of the team that built and maintains this awesome platform!” and “You folks are great, thanks for being such a wonderful group in the Intel space”, it continues to solidify why we do what we do, and how we do it every day.
We thank you from the bottom of our hearts for your support and for being part of our journey. On to 2025.
Entrar
