💡Artifacts from our analysis are available on our GitHub.TAMECAT is 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
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 c
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.
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 repositori
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
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.
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 ranso
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.
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 2024chrome-stats lists the number of extensions as high as 145,316Regardless 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. Whil
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.
Entrar
