Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
A likely lone wolf actor behind the EncryptHub persona was acknowledged by Microsoft for discovering and reporting two security flaws in Windows last month, painting a picture of a "conflicted" individual straddling a legitimate career in cybersecurity and pursuing cybercrime.
In a new extensive analysis published by Outpost24 KrakenLabs, the Swedish security company unmasked the up-and-coming cybercriminal, who, about 10 years ago, fled his hometown in Kharkov, Ukraine, to a new place somewhere near the Romanian coast.
The vulnerabilities were credited by Microsoft to a party named "SkorikARI with SkorikARI," which has been assessed to be another username used by EncryptHub. The flaws in question, both of which were fixed by Redmond as part of its Patch Tuesday update last month, are below -
CVE-2025-24061 (CVSS score: 7.8) - Microsoft Windows Mark-of-the-Web (MotW) Security Feature Bypass Vulnerability
CVE-2025-24071 (CVSS score: 6.5) - Microsoft Windows File Explorer Spoofing Vulnerability
EncryptHub, also tracked under the monikers LARVA-208 and Water Gamayun, was spotlighted in mid-2024 as part of a campaign that leveraged a bogus WinRAR site to distribute various kinds of malware hosted on a GitHub repository named "encrypthub."
In recent weeks, the threat actor has been attributed to the zero-day exploitation of another security flaw in Microsoft Management Console (CVE-2025-26633, CVSS score: 7.0, aka MSC EvilTwin) to deliver information stealers and previously undocumented backdoors named SilentPrism and DarkWisp.
According to PRODAFT, EncryptHub is estimated to have compromised over 618 high-value targets across multiple industries in the last nine months of its operation.
"All data analyzed throughout our investigation points to the actions of a single individual," Lidia Lopez, Senior Threat Intelligence Analyst at Outpost24, told The Hacker News.
"However, we cannot rule out the possibility of collaboration with other threat actors. In one of the Telegram channels used to monitor infection statistics, there was another Telegram user with administrative privileges, suggesting potential cooperation or assistance from others without a clear group affiliation."
Outpost24 said it was able to piece together EncryptHub's online footprint from the "actor's self-infections due to poor operational security practices," uncovering new aspects of their infrastructure and tooling in the process.
The individual is believed to have kept a low profile after moving to an unspecified place near Romania, studying computer science on their own by enrolling for online courses, while seeking computer-related jobs on the side.
All of the threat actor's activity, however, abruptly ceased in early 2022 coinciding with the onset of the Russo-Ukrainian war. That said, Outpost24 said it has found evidence to suggest that he was jailed around the same time.
"Once released, he resumed his job search, this time offering freelance web and app development services, which gained some traction," the company said in the report. "But the pay likely wasn't enough, and after briefly trying bug bounty programs with little success, we believe he pivoted to cybercrime in the first half of 2024."
One of EncryptHub's earliest ventures in the cybercrime landscape is Fickle Stealer, which was first documented by Fortinet FortiGuard Labs in June 2024 as a Rust-based information stealer malware that's distributed via multiple channels.
In a recent interview with security researcher g0njxa, the threat actor claimed that Fickle "delivers results on systems where StealC or Rhadamantys (sic) would never work" and that it "passes high-quality corporate antivirus systems." They also stated that the stealer is not only being shared privately, it's also "integral" to another product of theirs dubbed EncryptRAT.
"We were able to associate Fickle Stealer with an alias previously tied to EncryptHub," Lopez said. "Additionally, one of the domains linked to that campaign matches infrastructure connected to his legitimate freelance work. From our analysis, we estimate EncryptHub's cybercriminal activity began around March 2024. Fortinet's reporting in June likely marks the first public documentation of these actions."
EncryptHub is also said to have relied extensively on OpenAI's ChatGPT to assist with malware development, even going to the extent of using it to aid in translating emails and messages and as a confessional tool.
"EncryptHub's case highlights how poor operational security remains one of the most critical weaknesses for cybercriminals," Lopez pointed out. "Despite technical sophistication, basic mistakes – like password reuse, exposed infrastructure, and mixing personal with criminal activity – ultimately led to his exposure."
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/lpVAsgt
via IFTTT
The North Korean threat actors behind the ongoing Contagious Interview campaign are spreading their tentacles on the npm ecosystem by publishing more malicious packages that deliver the BeaverTail malware, as well as a new remote access trojan (RAT) loader.
"These latest samples employ hexadecimal string encoding to evade automated detection systems and manual code audits, signaling a variation in the threat actors' obfuscation techniques," Socket security researcher Kirill Boychenko said in a report.
The packages in question, which were collectively downloaded more than 5,600 times prior to their removal, are listed below -
The end goal of the campaign is to infiltrate developer systems under the guise of a job interview process, steal sensitive data, siphon financial assets, and maintain long-term access to compromised systems.
The newly identified npm libraries masquerade as utilities and debuggers, with one of them – dev-debugger-vite – using a command-and-control (C2) address previously flagged by SecurityScorecard as used by the Lazarus Group in a campaign codenamed Phantom Circuit in December 2024.
What makes these packages stand out is some of them, such as events-utils and icloud-cod, are linked to Bitbucket repositories, as opposed to GitHub. Furthermore, the icloud-cod package has been found to be hosted within a directory named "eiwork_hire," reiterating the threat actor's use of interview-related themes to activating the infection.
An analysis of the packages, cln-logger, node-clog, consolidate-log, and consolidate-logger, has also uncovered minor code-level variations, indicating that the attackers are publishing multiple malware variants in an attempt to increase the success rate of the campaign.
Regardless of the changes, the malicious code embedded within the four packages function as a remote access trojan (RAT) loader that's capable of propagating a next-stage payload from a remote server.
"The Contagious Interview threat actors continue to create new npm accounts and deploy malicious code across platforms like the npm registry, GitHub, and Bitbucket, demonstrating their persistence and showing no signs of slowing down," Boychenko said.
"The advanced persistent threat (APT) group is diversifying its tactics — publishing new malware under fresh aliases, hosting payloads in both GitHub and Bitbucket repositories, and reusing core components like BeaverTail and InvisibleFerret alongside newly observed RAT/loader variant."
BeaverTail Drops Tropidoor
The disclosure comes as South Korean cybersecurity company AhnLab detailed a recruitment-themed phishing campaign that delivers BeaverTail, which is then used to deploy a previously undocumented Windows backdoor codenamed Tropidoor. Artifacts analyzed by the firm show that BeaverTail is being used to actively target developers in South Korea.
The email message, which claimed to be from a company called AutoSquare, contained a link to a project hosted on Bitbucket, urging the recipient to clone the project locally on their machine to review their understanding of the program.
The application is nothing but an npm library that contains BeaverTail ("tailwind.config.js") and a DLL downloader malware ("car.dll"), the latter of which is launched by the JavaScript stealer and loader.
Tropidoor is a backdoor "operating in memory through the downloader" that's capable of contacting a C2 server to receive instructions that make it possible to exfiltrate files, gather drive and file information, run and terminate processes, capture screenshots, and delete or wipe files by overwriting them with NULL or junk data.
An important aspect of the implant is that it directly implements Windows commands such as schtasks, ping, and reg, a feature previously also observed in another Lazarus Group malware called LightlessCan, itself a successor of BLINDINGCAN (aka AIRDRY aka ZetaNile).
"Users should be cautious not only with email attachments but also with executable files from unknown sources," AhnLab said.
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/dcaqSYD
via IFTTT
Cybersecurity researchers have uncovered malicious libraries in the Python Package Index (PyPI) repository that are designed to steal sensitive information.
Two of the packages, bitcoinlibdbfix and bitcoinlib-dev, masquerade as fixes for recent issues detected in a legitimate Python module called bitcoinlib, according to ReversingLabs. A third package discovered by Socket, disgrasya, contained a fully automated carding script targeting WooCommerce stores.
The packages attracted hundreds of downloads before being taken down, according to statistics from pepy.tech -
"The malicious libraries both attempt a similar attack, overwriting the legitimate 'clw cli' command with malicious code that attempts to exfiltrate sensitive database files," ReversingLabs said.
In an interesting twist, the authors of the counterfeit libraries are said to have joined a GitHub issue discussion and unsuccessfully attempted to trick unsuspecting users into downloading the purported fix and running the library.
On the other hand, disgrasya has been found to be openly malicious, making no effort to conceal its carding and credit card information stealing functionality.
"The malicious payload was introduced in version 7.36.9, and all subsequent versions carried the same embedded attack logic," the Socket Research Team said.
Carding, also called credit card stuffing, refers to an automated form of payment fraud in which fraudsters test a bulk list of stolen credit or debit card information against a merchant's payment processing system to verify breached or stolen card details. It falls under a broader attack category referred to as automated transaction abuse.
A typical source for stolen credit card data is a carding forum, where credit card details pilfered from victims using various methods like phishing, skimming, or stealer malware are advertised for sale to other threat actors to further criminal activity.
Once they are found to be active (i.e. not reported lost, stolen, or deactivated), scammers use them to buy gift cards or prepaid cards, which are then resold for profit. Threat actors are also known to test if the cards are valid by attempting small transactions on e-commerce sites to avoid being flagged for fraud by the card owners.
The rogue package identified by Socket is designed to validate stolen credit card information, particularly targeting merchants using WooCommerce with CyberSource as the payment gateway.
The script achieves this by emulating the actions of a legitimate shopping activity, programmatically finding a product, adding it to a cart, navigating to the WooCommerce checkout page, and filling the payment form with randomized billing details and the stolen credit card data.
In mimicking a real checkout process, the idea is to test the validity of the plundered cards and exfiltrate the relevant details, such as the credit card number, expiration date, and CVV, to an external server under the attacker's control ("railgunmisaka[.]com") without attracting the attention of fraud detection systems.
"While the name might raise eyebrows to native speakers ('disgrasya' is Filipino slang for 'disaster' or 'accident'), it's an apt characterization of a package that executes a multi-step process emulating a legitimate shopper's journey through an online store in order to test stolen credit cards against real checkout systems without triggering fraud detection," Socket said.
"By embedding this logic inside a Python package published on PyPI and downloaded over 34,000 times, the attacker created a modular tool that could be easily used in larger automation frameworks, making disgrasya a powerful carding utility disguised as a harmless library."
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/cOxAaXE
via IFTTT
AI is quickly becoming a core part of modern applications, but running large language models (LLMs) locally can still be a pain. Between picking the right model, navigating hardware quirks, and optimizing for performance, it’s easy to get stuck before you even start building. At the same time, more and more developers want the flexibility to run LLMs locally for development, testing, or even offline use cases. That’s where Docker Model Runner comes in.
Now available in Beta with Docker Desktop 4.40 for macOS on Apple silicon, Model Runner makes it easy to pull, run, and experiment with LLMs on your local machine. No infrastructure headaches, no complicated setup. Here’s what Model Runner offers in our initial beta release.
Local LLM inference powered by an integrated engine built on top of llama.cpp, exposed through an OpenAI-compatible API.
GPU acceleration on Apple silicon by executing the inference engine directly as a host process.
A growing collection of popular, usage-ready models packaged as standard OCI artifacts, making them easy to distribute and reuse across existing Container Registry infrastructure.
Keep reading to learn how to run LLMs locally on your own computer using Docker Model Runner!
Enabling Docker Model Runner for LLMs
Docker Model Runner is enabled by default and shipped as part of Docker Desktop 4.40 for macOS on Apple silicon hardware. However, in case you’ve disabled it, you can easily enable it through the CLI with a single command:
docker desktop enable model-runner
In its default configuration, the Model Runner will only be accessible through the Docker socket on the host, or to containers via the special model-runner.docker.internal endpoint. If you want to interact with it via TCP from a host process (maybe because you want to point some OpenAI SDK within your codebase straight to it), you can also enable it via CLI by specifying the intended port:
docker desktop enable model-runner --tcp 12434
A first look at the command line interfaceCLI
The Docker Model Runner CLI will feel very similar to working with containers, but there are also some caveats regarding the execution model, so let’s check it out. For this guide, I’m going to use a very small model to ensure it runs on hardware with limited resources and provides a fast and responsive user experience. To be more specific, we’ll use the SmolLM model, published by HuggingFace in 2024.
We’ll want to start by pulling a model. As with Docker Images, you can omit the specific tag, and it’ll default to latest. But for this example, let’s be specific:
docker model pull ai/smollm2:360M-Q4_K_M
Here I am pulling the SmolLM2 model with 360M parameters and 4-bit quantization. Tags for models distributed by Docker follow this scheme with regard to model metadata:
{model}:{parameters}-{quantization}
After having the model pulled, let’s give it a spin by asking it a question:
docker model run ai/smollm2:360M-Q4_K_M "Give me a fact about whales."
Whales are magnificent marine animals that have fascinated humans for centuries. They belong to the order Cetacea and have a unique body structure that allows them to swim and move around the ocean. Some species of whales, like the blue whale, can grow up to 100 feet (30 meters) long and weigh over 150 tons (140 metric tons) each. They are known for their powerful tails that propel them through the water, allowing them to dive deep to find food or escape predators.
Is this whale fact actually true? Honestly, I have no clue; I’m not a marine biologist. But it’s a fun example to illustrate a broader point: LLMs can sometimes generate inaccurate or unpredictable information. As with anything, especially smaller local models with a limited number of parameters or small quantization values, it’s important to verify what you’re getting back.
So what actually happened when we ran the docker model run command? It makes sense to have a closer look at the technical underpinnings, since it differs from what you might expect after using docker container run commands for years. In the case of the Model Runner, this command won’t spin up any kind of container. Instead, it’ll call an Inference Server API endpoint, hosted by the Model Runner through Docker Desktop, and provide an OpenAI compatible API. The Inference Server will use llama.cpp as the Inference Engine, running as a native host process, load the requested model on demand, and then perform the inference on the received request. Then, the model will stay in memory until another model is requested, or until a pre-defined inactivity timeout (currently 5 minutes) is reached.
That also means that there isn’t a need to perform a docker model run before interacting with a specific model from a host process or from within a container. Model Runner will transparently load the requested model on-demand, assuming it has been pulled beforehand and is locally available.
Speaking of interacting with models from other processes, let’s have a look at how to integrate with Model Runner from within your application code.
Having fun with GenAI development
Model Runner exposes an OpenAI endpoint under http://model-runner.docker.internal/engines/v1 for containers, and under http://localhost:12434/engines/v1 for host processes (assuming you have enabled TCP host access on default port 12434). You can use this endpoint to hook up any OpenAI-compatible clients or frameworks.
In this example, I’m using Java and LangChain4j. Since I develop and run my Java application directly on the host, all I have to do is configure the Model Runner OpenAI endpoint as the baseUrl and specify the model to use, following the Docker Model addressing scheme we’ve already seen in the CLI usage examples.
And that’s all there is to it, pretty straightforward, right?
Please note that the model has to be already locally present for this code to work.
OpenAiChatModel model = OpenAiChatModel.builder()
.baseUrl("http://localhost:12434/engines/v1")
.modelName("ai/smollm2:360M-Q4_K_M")
.build();
String answer = model.chat("Give me a fact about whales.");
System.out.println(answer);
Finding more models
Now, you probably don’t just want to use SmolLM models, so you might wonder what other models are currently available to use with Model Runner.? The easiest way to get started is by checking out the ai/ namespace on Docker Hub.
On Docker Hub, you can find a curated list of the most popular models that are well-suited for local use cases. They’re offered in different flavors to suit different hardware and performance needs. You can also find more details about each in the model card, available on the overview page of the model repository.
What’s next?
Of course, this was just a first look at what Docker Model Runner can do. We have many more features in the works and can’t wait to see what you build with it. For hands-on guidance, check out our latest YouTube tutorial on running LLMs locally with Model Runner. And be sure to keep an eye on the blog, we’ll be sharing more updates, tips, and deep dives as we continue to expand Model Runner’s capabilities
As more organizations adopt containerization, Kubernetes adoption is at an all-time high. A key component to any Kubernetes cluster is allowing and managing external traffic to the services organizations are building. Enter, Ingress. As a powerful component and set of resources that expose services to the outside world, Ingress’ power and complexity lends itself to a considerable risk profile when compromised.
In this post, we dive into a grouping of critical vulnerabilities dubbed IngressNightmare and share actionable mitigation and detection strategies, including multiple ways in which SentinelOne’s Singularity Platform can highlight both IngressNightmare vulnerability exposure and possible exploitation in runtime.
Beyond this specific security risk, given understanding challenges in Ingress is crucial to maintaining a resilient Kubernetes environment, this post additionally contains troubleshooting tips to tackle common Ingress issues like SSL misconfigurations, routing anomalies, and performance bottlenecks. Understanding and overcoming these challenges is important in maintaining a resilient Kubernetes environment.
What is Ingress?
In Kubernetes, Ingress acts as a traffic manager, routing external access to services within your cluster. Ingress is composed of two key components: Ingress resources that define routing rules based on hostnames and paths, and an Ingress Controller (like the Ingress NGINX Controller) that implements these rules, typically by configuring a load balancer or reverse proxy (in this case, NGINX).
Below is an example of a YAML file wherein the Ingress resource defines the following routing rules:
example.com/ → frontend-service
example.com/api → backend-service
Example YAML of Ingress resource routing rules
Using the above example, below is a Kubernetes architecture diagram showcasing Ingress routing traffic to specific services:
Flow of external traffic to internal services via ingress controller within the cluster
What Is IngressNightmare?
A series of critical security vulnerabilities, collectively known as IngressNightmare, have been discovered in the Ingress NGINX Controller for Kubernetes. These flaws, CVE-2025-1097, CVE-2025-1098, CVE-2025-24514, and the most severe, CVE-2025-1974, allow unauthenticated remote code execution (RCE) via the controller’s admission webhook, potentially enabling attackers to access all secrets across namespaces and take over entire clusters. CVE-2025-1974 is assigned a CVSS v3.1 base score of 9.8, making it a critical vulnerability in the context of the ingress-nginx controller.
These Ingress NGINX Controller vulnerabilities are tracked respectively as:
Successful exploitation of these vulnerabilities can result in:
Unauthorized access to all Kubernetes Secrets across namespaces within a cluster,
Lateral movement within the cluster, and even
Complete cluster takeover by the adversary.
Affected Ingress NGINX Controller Versions:
All versions prior to v1.11.0
Versions v1.11.0 through v1.11.4Version v1.12.0
Stages of IngressNightmare | How the Attack Works
IngressNightmare works by exploiting weaknesses in Kubernetes Ingress NGNIX by leveraging misconfigurations and unauthorized access points. This is a multi-stage attack that starts with identifying vulnerable clusters and ends with an attacker gaining full control over them. Let’s briefly outline the stages of this attack:
Discovery & Targeting – Attackers scan for clusters using Ingress NGINX, often those with publicly exposed admission controllers. The adversary is seeking vulnerable targets susceptible to this attack.
Crafting Malicious Ingress Object – Once found, a specially crafted ingress object is created, containing injected malicious NGINX configurations.
Sending Malicious Request – The malicious object is sent as an unauthenticated AdmissionReview request to the admission controller.
NGINX Configuration Generation – The controller generates an NGINX configuration from the ingress object. Here, injected directives are incorporated.
NGINX Configuration Validation (Exploitation) – When the controller validates the configuration using nginx -t, the injected code is executed, resulting in RCE.
Gaining Access & Privilege Escalation – With the controller’s elevated privileges, attackers access all cluster secrets and can move laterally, eventually taking over the cluster.
IngressNightmare Attack
Validation & Mitigation
Our recommendation is to first establish whether or not your clusters are vulnerable to this attack. Run the following command to check for vulnerable installations:
If your clusters are leveraging Ingress NGINX Controller and on a vulnerable version, we recommend the following.
Immediate Action
As always, the best way to avoid vulnerability exploitation is to update/patch. In this instance update out of the risk zone by patching your Ingress NGINX Controller to v1.11.5, v1.12.1, or a later version.
Fixing the code that allows reading of all cluster secrets
If it isn’t possible to update, there are temporary mitigations available.
Temporary Mitigations
Restrict Access – Enforce strict network policies so that only the Kubernetes API Server can access the admission controller.
Disable Admission Controller – Temporarily disable the admission controller component if you cannot upgrade immediately.
If using Helm – Reinstall with controller.admissionWebhooks.enabled=false.
If installed manually – Delete the ValidatingWebhookConfiguration named ingress-nginx-admission and remove the --validating-webhook argument from the controller’s Deployment or DaemonSet.
How SentinelOne Helps You To Protect Kubernetes
There are a number of ways in which SentinelOne keeps Kubernetes clusters safe. To focus on IngressNightmare as a specific threat, Singularity Platform identifies whether the vulnerabilities are present, validates if they are externally accessible (which is a high likelihood given the nature of ingress), and maps the affected resources. Additionally, SentinelOne is able to detect and respond to this attack as it unfolds, and has powerful capabilities to threat hunt potential adversary activity that would be seen post-exploit.
The range of detections are common for SentinelOne as we look to provide proactive alerts about your cluster health to help you reduce your exposures and attack surface as well as powerful reactive runtime defensive capabilities. The proactive capabilities are found within SentinelOne’s Cloud Native Security (CNS), and in this instance, its Kubernetes Security Posture Management (KSPM) and Offensive Security Engine features.
KSPM helps protect Kubernetes Clusters by identifying misconfigurations and vulnerabilities that may otherwise go unnoticed. Below is a screenshot of one of CNS’ KSPM policies that hunts for this specific vulnerability:
The KSPM Policy: Potential IngressNightmare vulnerability found inside Kubernetes Cluster
With its “attacker’s mindset” and scanning capabilities, the Offensive Security Engine goes a step further. It establishes where the vulnerability is externally accessible and identifies the connected exposed assets vulnerable to IngressNightmare. Finally, because of the nature of the Offensive Security Engine, each alert is verified with evidence. Below is a screenshot of an alert prompted by the Offensive Security Engine:
Offensive Security Engine alert for proven Kubernetes clusters at risk from IngressNightmare
As we shift our focus from proactive to reactive security, we go from a passive to active view of this threat and any potential exploitation. SentinelOne’s Cloud Workload Security agent, deployable via DaemonSet, provides runtime detection in both on-prem and cloud-managed Kubernetes clusters. As adversaries look to leverage the IngressNightmare vulnerabilities to impact the cluster, for example via credential harvesting, the malicious processes are detected in real time.
A malicious process stemming from NGINX Ingress Controller is detected
Moving outside a process view, below is an example of Cloud Workload Security’s graphical view of affected assets and an alert for an adversary attempting a reverse shell post initial exploitation:
A malicious process stemming from NGINX Ingress Controller is detected
Hunting Queries
Finally, for SentinelOne customers looking to proactively hunt for potential exploitation of IngressNightmare, we recommend checking for anomalies such as Behavioral Indicators present in the ingress-nginx namespace.
event.type = 'Behavioral Indicators' and (k8sCluster.namespace='ingress-nginx' or k8sCluster.containerImage contains 'ingress-nginx/controller')
Customers can review destination IPs in outbound connections originating from Ingress Nginx to identify potentially compromised instances.
(k8sCluster.namespace='ingress-nginx' or k8sCluster.containerImage contains 'ingress-nginx/controller') event.type = 'IP Connect' event.network.direction='OUTGOING'
For instances of Ingress Nginx configured to use a namespace other than the default (ingress-nginx), the below query can help with a starting point for hunting and review of runtime activities.
dataSource.name = 'SentinelOne' and endpoint.os = 'linux' and tgt.process.name = 'nginx' and tgt.process.cmdline contains 'nginx-cfg' and tgt.process.cmdline contains ' -t'
Staying Ahead of Common Ingress Nightmares
Beyond IngressNightmare and other security vulnerabilities, Kubernetes Ingress can be challenging to manage in day-to-day operations. Here are some practical steps to diagnose and resolve frequent issues.
Nightmare #1: SSL Certificate Problems
Symptoms:
Browser warnings: “Your connection is not secure”
Inconsistent behavior between environments
Troubleshooting Steps:
Verify Secret and Certificate Presence: kubectl describe secret your-tls-secret -n your-namespace. Ensure both tls.crt and tls.key are correctly set.
DNS Verification: Ensure your DNS correctly resolves to your Ingress IP.
Nightmare #2: Routing Gone Wild
Symptoms:
Random 404 errors
Inconsistent routing behavior
Troubleshooting Steps:
Review Path Rules:
rules:
- host: example.com
http:
paths:
- path: /api
pathType: Prefix # or Exact, based on your need
backend:
service:
name: api-service
port:
number: 80
Test with Curl: curl -v https://example.com/api. Analyze the verbose output to track where the request is routed.
Securing Kubernetes clusters demands a multi-faceted approach inclusive of both proactive and reactive strategies. Threats like IngressNightmare highlight the need to have continuous visibility of your Kubernetes exposures alongside runtime security, and as always underline the criticality of immediate patching. The operational challenges of ingress though often require robust troubleshooting practices to help ensure smoother operation. By combining rigorous security measures with detailed diagnostics, you can safeguard your Kubernetes environment and maintain reliable service delivery.
Call to Action:
For Security – Upgrade your Ingress NGINX Controller immediately to v1.11.5, v1.12.1, or later.
For Operations – Implement the troubleshooting steps provided, and consider adding visual aids (like flowcharts) to your team’s documentation for faster diagnosis.
For customers of SentinelOne – Validate your risk to this threat via Cloud Native Security, and consider running quick hunts for post-exploitation activity.
For Security Tooling – Should the tooling not be in place, consider investing in a Cloud Native Application Protection Platform (CNAPP) to secure Kubernetes and cloud environments.
For those seeking further information on how Singularity Cloud Security provides both proactive and reactive security for on-premise and cloud hosted Kubernetes clusters.
Improve prioritization, respond faster, and surface actionable insights with Singularity Cloud Security, the comprehensive, AI-powered CNAPP from SentinelOne.
Apr 04, 2025Ravie LakshmananVulnerability / Open Source,
The cascading supply chain attack that initially targeted Coinbase before becoming more widespread to single out users of the "tj-actions/changed-files" GitHub Action has been traced further back to the theft of a personal access token (PAT) related to SpotBugs.
"The attackers obtained initial access by taking advantage of the GitHub Actions workflow of SpotBugs, a popular open-source tool for static analysis of bugs in code," Palo Alto Networks Unit 42 said in an update this week. "This enabled the attackers to move laterally between SpotBugs repositories, until obtaining access to reviewdog."
There is evidence to suggest that the malicious activity began as far back as November, 2024, although the attack against Coinbase did not take place until March 2025.
Unit 42 said its investigation began with the knowledge that reviewdog's GitHub Action was compromised due to a leaked PAT associated with the project's maintainer, which subsequently enabled the threat actors to push a rogue version of "reviewdog/action-setup" that, in turn, was picked up by "tj-actions/changed-files" due to it being listed as a dependency via the "tj-actions/eslint-changed-files" action.
It has since been uncovered that the maintainer was also an active participant in another open-source project called SpotBugs.
The attackers are said to have pushed a malicious GitHub Actions workflow file to the "spotbugs/spotbugs" repository under the disposable username "jurkaofavak," causing the maintainer's PAT to be leaked when the workflow was executed.
It's believed that the same PAT facilitated access to both "spotbugs/spotbugs" and "reviewdog/action-setup," meaning the leaked PAT could be abused to poison "reviewdog/action-setup."
"The attacker somehow had an account with write permission in spotbugs/spotbugs, which they were able to use to push a branch to the repository and access the CI secrets," Unit 42 said.
As for how the write permissions were obtained, it has come to light that the user behind the malicious commit to SpotBugs, "jurkaofavak," was invited to the repository as a member by one of the project maintainers themselves on March 11, 2025.
In other words, the attackers managed to obtain the PAT of the SpotBugs repository to invite "jurkaofavak" to become a member. This, the cybersecurity company said, was carried out by creating a fork of the "spotbugs/sonar-findbugs" repository and creating a pull request under the username "randolzfow."
"On 2024-11-28T09:45:13 UTC, [the SpotBugs maintainer] modified one of the 'spotbugs/sonar-findbugs workflows to use their own PAT, as they were having technical difficulties in a part of their CI/CD process," Unit 42 explained.
"On 2024-12-06 02:39:00 UTC, the attacker submitted a malicious pull request to spotbugs/sonar-findbugs, which exploited a GitHub Actions workflow that used the pull_request_target trigger."
The "pull_request_target" trigger is a GitHub Actions workflow trigger that allows workflows running from forks to access secrets – in this case, the PAT – leading to what's called a poisoned pipeline execution attack (PPE).
The SpotBugs maintainer has since confirmed that the PAT that was used as a secret in the workflow was the same access token that was later used to invite "jurkaofavak" to the "spotbugs/spotbugs" repository. The maintainer has also rotated all of their tokens and PATs to revoke and prevent further access by the attackers.
One major unknown in all this is the three-month gap between when the attackers leaked the SpotBugs maintainer's PAT and when they abused it. It's suspected that the attackers were keeping an eye out on the projects that were dependent on "tj-actions/changed-files" and waited to strike a high-value target like Coinbase.
"Having invested months of effort and after achieving so much, why did the attackers print the secrets to logs, and in doing so, also reveal their attack?," Unit 42 researchers pondered.
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/bFsiQ7T
via IFTTT
The Good | DoJ Seize $8.2 Million in Cryptocurrency Linked to Romance Baiting Schemes
The DoJ has seized over $8.2 million in USDT (Tether) cryptocurrency, all stolen through ‘romance baiting’ scams, formerly known as ‘pig butchering’. Victims are manipulated into making investments on fake websites or apps after being promised substantial returns. They are then led to believe they are making profits so invest even more, only to run into a multitude of issues when trying to make any withdrawals. At this point, the scammers have already made off with all of the victim’s funds.
The FBI backward-traced the laundering patterns across multiple platforms and networks starting from centralized exchanges, then Ethereum and TRON, through DeFi protocols, and finally, into storage wallets owned by the fraudsters. Analysis on the investigation noted that U.S. state investigators were able to file a dual legal forfeiture under charges of wire fraud and money laundering.
Tether Limited cooperated by freezing the stolen funds, burning the original tokens, and reissuing them to law enforcement-controlled wallets. The asset seizure was successfully completed in November 2024, and now enables potential restitution for victims as the FBI continues to trace affected accounts.
Source: TRM Labs
One filed complaint identifies 38 cryptocurrency accounts victimized by these scams, with total losses exceeding $5.2 million. Five named victims from Ohio, Michigan, California, Utah, and North Carolina collectively lost over $1.6 million, with the worst case involving someone liquidating their retirement account, leading to a $650,000 loss. These major seizures showcase the DOJ’s commitment to dismantling sophisticated cryptocurrency scams and ensuring justice for victims.
The Bad | China-linked Threat Actor Exploits Ivanti Bug CVE-2025-22457
A critical vulnerability in several Ivanti products is being actively exploited in the wild, with attackers using it to gain remote access, deploy malware, and establish long-term persistence in victim environments.
Tracked as CVE-2025-22457, the flaw is a stack-based buffer overflow vulnerability with a CVSS score of 9.0, affecting Ivanti’s Connect Secure, Policy Secure, and Neurons for ZTA Gateways. The bug allows remote, unauthenticated attackers to execute arbitrary code on vulnerable systems.
Ivanti says the issue stems from how the gateway handles certain limited character inputs—specifically, periods and numbers. While the flaw was initially assessed as not meeting the criteria for remote code execution or denial of service, subsequent analysis revealed that it could be exploited through sophisticated methods and evidence of active exploitation in the wild has since emerged.
A campaign abusing the vulnerability was observed in mid-March 2025 and attributed to a China-linked threat actor tracked as UNC5221. The attackers employed TRAILBLAZE, an in-memory dropper, to deliver the initial payload. Once access is established, BRUSHFIRE, a memory-resident backdoor, is injected into the web process of the Ivanti appliance, enabling remote command execution without writing to disk. To maintain persistence and expand access, the attackers leveraged a malware framework known as SPAWN, with capabilities for log tampering, memory extraction, and other post-exploitation activity.
Vulnerable edge devices attract threat actors like honey. UNC5221 (China-linked Threat Actor) has been actively exploiting CVE-2025-22457 (CVSS 9.0) a critical Ivanti VPN vulnerability since mid-March 2025. Patch version 22.7R2.6
#CVE #Exploited #POC #patch #vulnerability
To mitigate the threat, Ivanti released a patch for Connect Secure 22.7R2.6 on February 11, 2025. Fixes for Policy Secure (22.7R1.4) and Neurons for ZTA Gateway (22.8R2.2) are scheduled for release later this month. Ivanti says that Policy Secure should not be exposed to the public internet and that Neurons for ZTA Gateway is not exploitable in production deployments.
Ivanti strongly encourages its customers to update to Connect Secure 22.7R2.6 as soon as possible. The company’s full mitigation advice can be found here.
The Ugly | New WRECKSTEEL Malware Used in Cyber Espionage Campaigns Targeting Ukraine
Ukraine’s computer emergency response team, CERT-UA, has reported at least three cyberattacks from March focused on targeting government agencies and critical infrastructure using a new malware dubbed ‘WRECKSTEEL’. This is a targeted espionage campaign now attributed to the threat cluster tracked as UAC-0219 that has been active since fall of 2024 and is known for employing phishing emails to spread malicious links.
Attackers compromised the government accounts to send messages with links to public file-sharing services such as Google Drive and DropMeFiles. In one phishing attempt, the attackers masqueraded as a Ukrainian government agency, sending out fake salary reduction notices to lure employees into clicking malicious links. Clicking the links triggered the download of a Visual Basic Script (VBS) loader, which then executed a PowerShell script designed to collect documents, images, PDFs, and presentations with specific extensions to capture screenshots.
While early versions of UAC-0219 relied on EXE files, VBS stealers, and the IrfanView image editor for data extraction, the integration of the screenshot functionality directly into the PowerShell script to perform espionage confirms the continued development of the malware.
While CERT-UA did not directly attribute the attacks to a nation, similar phishing campaigns have historically originated from Russia. The attacks reflect increasing sophistication, using PowerShell-based techniques to bypass detection and collect targeted data. CERT-UA released a full list of IoCs to help organizations detect and mitigate these threats.
There's a virtuous cycle in technology that pushes the boundaries of what's being built and how it's being used. A new technology development emerges and captures the world's attention. People start experimenting and discover novel applications, use cases, and approaches to maximize the innovation's potential. These use cases generate significant value, fueling demand for the next iteration of the innovation, and in turn, a new wave of innovators create the next generation of use cases, driving further advancements.
Containerization has become the foundation of modern, cloud-native software development, supporting new use cases and approaches to building resilient, scalable, and portable applications. It also holds the keys to the next software delivery innovation, simultaneously necessitating the evolution to secure-by-design, continuously-updated software and serving as the means to get there.
Below, I'll talk through some of the innovations that led to our containerized revolution, as well as some of the traits of cloud-native software development that have led to this inflection point – one that has primed the world to move away from traditional Linux distros and towards a new approach to open source software delivery.
Iteration has moved us closer to ubiquity
There have been many innovations that have paved the way for more secure, performant open source delivery. In the interest of your time and my word count I'll call out three particular milestones. Each step, from Linux Containers (LXC) to Docker and ultimately the Open Container Initiative (OCI), built upon its predecessor, addressing limitations and unlocking new possibilities.
LXC laid the groundwork by harnessing the Linux kernel's capabilities (namely cgroups and namespaces), to create lightweight, isolated environments. For the first time, developers could package applications with their dependencies, offering a degree of consistency across different systems. However, LXC's complexity for users and its lack of a standardized image distribution catalog hindered widespread adoption.
Docker emerged as a game-changer, democratizing container technology. It simplified the process of creating, running, and sharing containers, making them accessible to a broader audience. Docker's user-friendly interface and the creation of Docker Hub, a central repository for container images, fostered a vibrant ecosystem. This ease of use fueled rapid adoption, but also raised concerns about vendor lock-in and the need for interoperability.
Recognizing the potential for fragmentation, the OCI (Open Containers Initiative) stepped in to standardize container formats and runtimes. By defining open specifications, the OCI ensured that containers could be built and run across different platforms, fostering a healthy, competitive landscape. Projects like runC and containerd, born from the OCI, provided a common foundation for container runtimes and enabled greater portability and interoperability.
The OCI standards also enabled Kubernetes (another vendor-neutral standard) to become a truly portable platform, capable of running on a wide range of infrastructure and allowing organizations to orchestrate their applications consistently across different cloud providers and on-premises environments. This standardization and its associated innovations unlocked the full potential of containers, paving the way for their ubiquitous presence in modern software development.
[Containerized] software is eating the world
The advancements in Linux, the rapid democratization of containers through Docker, and the standardization of OCI were all propelled by necessity, with the evolution of cloud-native app use cases pushing orchestration and standardization forward. Those cloud-native application characteristics also highlight why a general-purpose approach to Linux distros no longer serves software developers with the most secure, updated foundations to develop on:
Microservice-oriented architecture: Cloud-native applications are typically built as a collection of small, independent services, with each microservice performing a specific function. Each of these microservices can be built, deployed, and maintained independently, which provides a tremendous amount of flexibility and resiliency. Because each microservice is independent, software builders don't require comprehensive software packages to run a microservice, relying only on the bare essentials within a container.
Resource-conscious and efficient: Cloud-native applications are built to be efficient and resource-conscious to minimize loads on infrastructure. This stripped down approach naturally aligns well with containers and an ephemeral deployment strategy, with new containers being deployed constantly and other workloads being updated to the latest code available. This cuts down security risks by taking advantage of the newest software packages, rather than waiting for distro patches and backports.
Portability: Cloud-native applications are designed to be portable, with consistent performance and reliability regardless of where the application is running. As a result of containers standardizing the environment, developers can move beyond the age-old "it worked fine on my machine" headaches of the past.
The virtuous cycle of innovation driving new use cases and ultimately new innovations is clear when it comes to containerization and the widespread adoption of cloud-native applications. Critically, this inflection point of innovation and use case demands has driven an incredible rate of change within open source software — we've reached a point where the security, performance, and innovation drawbacks of traditional "frozen-in-time" Linux distros outweigh the familiarity and perceived stability of the last generation of software delivery.
So what should the next generation of open source software delivery look like?
Enter: Chainguard OS
To meet modern security, performance, and productivity expectations, software builders need the latest software in the smallest form designed for their use case, without any of the CVEs that lead to risk for the business (and a list of "fix-its" from the security teams). Making good on those parameters requires more than just making over the past. Instead, the next generation of open source software delivery needs to start from the source of secure, updated software: the upstream maintainers.
That's why Chainguard built this new distroless approach, continuously rebuilding software packages based not on downstream distros but on the upstream sources that are removing vulnerabilities and adding performance improvements. We call it Chainguard OS.
Chainguard OS serves as the foundation for the broad security, efficiency, and productivity outcomes that Chainguard products deliver today, "Chainguarding" a rapidly growing catalog of over 1,000 container images.
Chainguard OS adheres to four key principles to make that possible:
Continuous Integration and Delivery: Emphasizes the continuous integration, testing, and release of upstream software packages, ensuring a streamlined and efficient development pipeline through automation.
Nano Updates and Rebuilds: Favors non-stop incremental updates and rebuilds over major release upgrades, ensuring smoother transitions and minimizing disruptive changes.
Minimal, Hardened, Immutable Artifacts: Strips away unnecessary vendor bloat from software artifacts, making sidecar packages and extras optional to the user while enhancing security through hardening measures.
Delta Minimization: Keeps deviations from upstream to a minimum, incorporating extra patches only when essential and only for as long as necessary until a new release is cut from upstream.
Perhaps the best way to highlight the value of Chainguard OS's principles is to see the impact in Chainguard Images.
In the below screenshot (and viewable here), you can see a side-by-side comparison between an external <python:latest> and <cgr.dev/chainguard/python:latest> Chainguard Image.
Aside from the very clear discrepancy in the vulnerability count, it's worth examining the size difference between the two container images. The Chainguard image comprises just 6% of the open source alternative image.
Along with the minimized image size, the Chainguard image was last updated just an hour prior to the screengrab, something that happens daily:
A quick scan of the provenance and SBOM data illustrates the end-to-end integrity and immutability of the artifacts — a kind of complete nutrition label that underscores the security and transparency that a modern approach to open source software delivery can provide.
Each Chainguard image stands as a practical example of the value Chainguard OS provides, offering a stark alternative to what has come before it. Perhaps the greatest indicator is the feedback we've received from customers, who have shared how Chainguard's container images have helped eliminate CVEs, secure their supply chains, achieve and maintain compliance, and reduce developer toil, enabling them to re-allocate precious developer resources.
Our belief is that Chainguard OS's principles and approach can be applied to a variety of use cases, extending the benefits of continuously rebuilt-from-source software packages to even more of the open source ecosystem.
If you found this useful, be sure to check out our whitepaper on this subject or contact our team to talk to an expert on Chainguard's distroless approach.
Note:This article is expertly written and contributed by Dustin Kirkland — VP of Engineering at Chainguard.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/w0cQSsB
via IFTTT
Microsoft is warning of several phishing campaigns that are leveraging tax-related themes to deploy malware and steal credentials.
"These campaigns notably use redirection methods such as URL shorteners and QR codes contained in malicious attachments and abuse legitimate services like file-hosting services and business profile pages to avoid detection," Microsoft said in a report shared with The Hacker News.
A notable aspect of these campaigns is that they lead to phishing pages that are delivered via a phishing-as-a-service (PhaaS) platform codenamed RaccoonO365, an e-crime platform that first came to light in early December 2024.
Also delivered are remote access trojans (RATs) like Remcos RAT, as well as other malware and post-exploitation frameworks such as Latrodectus, AHKBot, GuLoader, and BruteRatel C4 (BRc4).
One such campaign spotted by the tech giant on February 6, 2025, is estimated to have sent hundreds of emails targeting the United States ahead of the tax filing season that attempted to deliver BRc4 and Latrodectus. The activity has been attributed to Storm-0249, an initial access broker previously known for distributing BazaLoader, IcedID, Bumblebee, and Emotet.
The attacks involve the use of PDF attachments containing a link that redirects users to a URL shortened via Rebrandly, ultimately leading them to a fake Docusign page with an option to view or download the document.
"When users clicked the Download button on the landing page, the outcome depended on whether their system and IP address were allowed to access the next stage based on filtering rules set up by the threat actor," Microsoft said.
If access is allowed, the user is sent a JavaScript file that subsequently downloads a Microsoft Software Installer (MSI) for BRc4, which serves as a conduit for deploying Latrodectus. If the victim is not deemed a valuable enough target, they are sent a benign PDF document from royalegroupnyc[.]com.
Microsoft said it also detected a second campaign between February 12 and 28, 2025, where tax-themed phishing emails were sent to more than 2,300 organizations in the U.S., particularly aimed at engineering, IT, and consulting sectors.
The emails, in this case, had no content in the message body, but featured a PDF attachment containing a QR code that pointed to a link associated with the RaccoonO365 PhaaS that mimics Microsoft 365 login pages to trick users into entering their credentials.
In a sign that these campaigns come in various forms, tax-themed phishing emails have also been flagged as propagating other malware families like AHKBot and GuLoader.
AHKBot infection chains have been found to direct users to sites hosting a malicious Microsoft Excel file that, upon opening and enabling macros, downloads and runs a MSI file in order to launch an AutoHotKey script, which then downloads a Screenshotter module to capture screenshots from the compromised host and exfiltrate them to a remote server.
The GuLoader campaign aims to deceive users into clicking on a URL present within a PDF email attachment, resulting in the download of a ZIP file.
"The ZIP file contained various .lnk files set up to mimic tax documents. If launched by the user, the .lnk file uses PowerShell to download a PDF and a .bat file," Microsoft said. "The .bat file in turn downloaded the GuLoader executable, which then installed Remcos."
The development comes weeks after Microsoft warned of another Storm-0249 campaign that redirected users to fake websites advertising Windows 11 Pro to deliver an updated version of Latrodectus loader malware via the BruteRatel red-teaming tool.
"The threat actor likely used Facebook to drive traffic to the fake Windows 11 Pro download pages, as we observed Facebook referrer URLs in multiple cases," Microsoft said in a series of posts on X.
"Latrodectus 1.9, the malware's latest evolution first observed in February 2025, reintroduced the scheduled task for persistence and added command 23, enabling the execution of Windows commands via 'cmd.exe /c .'"
The disclosure also follows a surge in campaigns that use QR codes in phishing documents to disguise malicious URLs as part of widespread attacks aimed at Europe and the U.S., resulting in credential theft.
"Analysis of the URLs extracted from the QR codes in these campaigns reveals that attackers typically avoid including URLs that directly point to the phishing domain," Palo Alto Networks Unit 42 said in a report. "Instead, they often use URL redirection mechanisms or exploit open redirects on legitimate websites."
These findings also come in the wake of several phishing and social engineering campaigns that have been flagged in recent weeks -
Use of the browser-in-the-browser (BitB) technique to serve seemingly realistic browser pop-ups that trick players of Counter-Strike 2 into entering their Steam credentials with the likely goal of reselling access to these accounts for profit
Use of information stealer malware to hijack MailChimp accounts, permitting threat actors to send email messages in bulk
Use of SVG files to bypass spam filters and redirect users to fake Microsoft login pages
Use of trusted collaboration services like Adobe, DocuSign, Dropbox, Canva, and Zoho to sidestep secure email gateways (SEGs) and steal credentials
Use of fake security warnings related to suspicious activity on Windows and Apple Mac devices on bogus websites to deceive users into providing their system credentials
Use of fake websites distributing trojanized Windows installers for DeepSeek, i4Tools, and Youdao Dictionary Desktop Edition that drop Gh0st RAT
To mitigate the risks posed by these attacks, it's essential that organizations adopt phishing-resistant authentication methods for users, use browsers that can block malicious websites, and enable network protection to prevent applications or users from accessing malicious domains.
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/n8EGKuJ
via IFTTT
Written by: John Wolfram, Michael Edie, Jacob Thompson, Matt Lin, Josh Murchie
On Thursday, April 3, 2025, Ivantidiscloseda critical security vulnerability, CVE-2025-22457, impacting Ivanti Connect Secure (“ICS”) VPN appliances version 22.7R2.5 and earlier. CVE-2025-22457 is a buffer overflow vulnerability, and successful exploitation would result in remote code execution. Mandiant and Ivanti have identified evidence of active exploitation in the wild against ICS 9.X (end of life) and 22.7R2.5 and earlier versions. Ivanti and Mandiant encourage all customers to upgrade as soon as possible.
The earliest evidence of observed CVE-2025-22457 exploitation occurred in mid-March 2025. Following successful exploitation, we observed the deployment of two newly identified malware families, the TRAILBLAZE in-memory only dropper and the BRUSHFIRE passive backdoor. Additionally, deployment of the previously reportedSPAWN ecosystem of malwareattributed to UNC5221 was also observed. UNC5221 is a suspected China-nexus espionage actor that we previously observed conducting zero-day exploitation of edge devices dating back to 2023.
A patch for CVE-2025-22457 was released in ICS 22.7R2.6 on February 11, 2025. The vulnerability is a buffer overflow with a limited character space, and therefore it was initially believed to be a low-risk denial-of-service vulnerability. We assess it is likely the threat actor studied the patch for the vulnerability in ICS 22.7R2.6 and uncovered through a complicated process, it was possible to exploit 22.7R2.5 and earlier to achieve remote code execution.
Ivanti releasedpatchesfor the exploited vulnerability and Ivanti customers are urged to follow the actions in theSecurity Advisoryto secure their systems as soon as possible.
Post-Exploitation TTPs
Following successful exploitation, Mandiant observed the deployment of two newly identified malware families tracked as TRAILBLAZE and BRUSHFIRE through a shell script dropper. Mandiant has also observed the deployment of theSPAWN ecosystem of malware, as well as a modified version of the Integrity Checker Tool (ICT) as a means of evading detection.
Shell-script Dropper
Following successful exploitation of CVE-2025-22457, Mandiant observed a shell script being leveraged that executes the TRAILBLAZE dropper. This dropper injects the BRUSHFIRE passive backdoor into a running/home/bin/webprocess. The first stage begins by searching for a/home/bin/webprocess that is a child process of another/home/bin/webprocess (the point of this appears to be to inject into thewebprocess that is actually listening for connections). It then creates the the following files and associated content:
/tmp/.p: contains the PID of the/home/bin/webprocess.
/tmp/.m: contains a memory map of that process (human-readable).
/tmp/.w: contains the base address of thewebbinary from that process
/tmp/.s: contains the base address oflibssl.sofrom that process
/tmp/.r: contains the BRUSHFIRE passive backdoor
/tmp/.i: contains the TRAILBLAZE dropper
The shell script then executes/tmp/.i, which is the second stage in-memory only dropper tracked as TRAILBLAZE. It then deletes all of the temporary files previously created (except for/tmp/.p), as well as the contents of the/data/var/coresdirectory. Next, all child processes of the/home/bin/webprocess are killed and the/tmp/.pfile is deleted. All of this behavior is non-persistent, and the dropper will need to be re-executed if the system or process is rebooted.
TRAILBLAZE
TRAILBLAZE is an in-memory only dropper written in bare C that uses raw syscalls and is designed to be as minimal as possible, likely to ensure it can fit within the shell script as Base64. TRAILBLAZE injects a hook into the identified/home/bin/webprocess. It will then inject the BRUSHFIRE passive backdoor into a code cave inside that process.
BRUSHFIRE
BRUSHFIRE is a passive backdoor written in bare C that acts as anSSL_readhook. It first executes the originalSSL_readfunction, and checks to see if the returned data begins with a specific string. If the data begins with the string, it will XOR decrypt then execute shellcode contained in the data. If the received shellcode returns a value, the backdoor will callSSL_writeto send the value back.
SPAWNSLOTH
As detailed in ourprevious blog post, SPAWNSLOTH acts as a log tampering component tied to the SPAWNSNAIL backdoor. It targets thedslogserverprocess to disable both local logging and remote syslog forwarding.
SPAWNSNARE
SPAWNSNARE is a utility that is written in C and targets Linux. It can be used to extract the uncompressed linux kernel image (vmlinux) into a file and encrypt it using AES without the need for any command line tools.
SPAWNWAVE
SPAWNWAVE is an evolved version of SPAWNANT that combines capabilities from other members of theSPAWN* malware ecosystem. SPAWNWAVE overlaps with the publicly reportedSPAWNCHIMERAandRESURGEmalware families.
Attribution
Google Threat Intelligence Group (GTIG) attributes the exploitation of CVE-2025-22457 and the subsequent deployment of the SPAWN ecosystem of malware to the suspected China-nexus espionage actor UNC5221. GTIG has previously reported UNC5221 conducting zero-day exploitation of CVE-2025-0282, as well as the exploitation CVE-2023-46805 and CVE-2024-21887.
Furthermore, GTIG has also previously observed UNC5221 conducting zero-day exploitation of CVE-2023-4966, impacting NetScaler ADC and NetScaler Gateway appliances. UNC5221 has targeted a wide range of countries and verticals during their operations, and has leveraged an extensive set of tooling, spanning passive backdoors to trojanized legitimate components on various edge appliances.
GTIG assesses that UNC5221 will continue pursuing zero-day exploitation of edge devices based on their consistent history of success and aggressive operational tempo. Additionally, as noted in our prior blog post detailing CVE-2025-0282 exploitation, GTIG has observed UNC5221 leveraging an obfuscation network of compromised Cyberoam appliances, QNAP devices, and ASUS routers to mask their true source during intrusion operations.
Conclusion
This latest activity from UNC5221 underscores the ongoing sophisticated threats targeting edge devices globally. This campaign, exploiting the n-day vulnerability CVE-2025-22457, also highlights the persistent focus of actors like UNC5221 on edge devices, leveraging deep device knowledge and adding to their history of using both zero-day and now n-day flaws. This activity aligns with the broader strategy GTIG has observed among suspected China-nexus espionage groups who invest significantly in exploits and custom malware for critical edge infrastructure.
Recommendations
Mandiant recommends organizations immediately apply the available patch by upgrading Ivanti Connect Secure (ICS) appliances to version 22.7R2.6 or later to address CVE-2025-22457. Additionally organizations should use the external and internal Integrity Checker Tool (“ICT”) and contact Ivanti Support if suspicious activity is identified. To supplement this, defenders should actively monitor for core dumps related to the web process, investigate ICT statedump files, and conduct anomaly detection of client TLS certificates presented to the appliance.
Acknowledgements
We would like to thank Daniel Spicer and the rest of the team at Ivanti for their continued partnership and support in this investigation. Additionally, this analysis would not have been possible without the assistance from analysts across Google Threat Intelligence Group and Mandiant’s FLARE, we would like to specifically thank Christopher Gardner and Dhanesh Kizhakkinan of FLARE for their support.
Indicators of Compromise
To assist the security community in hunting and identifying activity outlined in this blog post, we have included indicators of compromise (IOCs) in aGTI Collectionfor registered users.
Code Family
MD5
Filename
Description
TRAILBLAZE
4628a501088c31f53b5c9ddf6788e835
/tmp/.i
In-memory dropper
BRUSHFIRE
e5192258c27e712c7acf80303e68980b
/tmp/.r
Passive backdoor
SPAWNSNARE
6e01ef1367ea81994578526b3bd331d6
/bin/dsmain
Kernel extractor & encryptor
SPAWNWAVE
ce2b6a554ae46b5eb7d79ca5e7f440da
/lib/libdsupgrade.so
Implant utility
SPAWNSLOTH
10659b392e7f5b30b375b94cae4fdca0
/tmp/.liblogblock.so
Log tampering utility
YARA Rules
rule M_APT_Installer_SPAWNANT_1
{
meta:
author = "Mandiant"
description = "Detects SPAWNANT. SPAWNANT is an
Installer targeting Ivanti devices. Its purpose is to persistently
install other malware from the SPAWN family (SPAWNSNAIL,
SPAWNMOLE) as well as drop additional webshells on the box."
strings:
$s1 = "dspkginstall" ascii fullword
$s2 = "vsnprintf" ascii fullword
$s3 = "bom_files" ascii fullword
$s4 = "do-install" ascii
$s5 = "ld.so.preload" ascii
$s6 = "LD_PRELOAD" ascii
$s7 = "scanner.py" ascii
condition:
uint32(0) == 0x464c457f and 5 of ($s*)
}
rule M_Utility_SPAWNSNARE_1 {
meta:
author = "Mandiant"
description = "SPAWNSNARE is a utility written in C that targets
Linux systems by extracting the uncompressed Linux kernel image
into a file and encrypting it with AES."
strings:
$s1 = "\x00extract_vmlinux\x00"
$s2 = "\x00encrypt_file\x00"
$s3 = "\x00decrypt_file\x00"
$s4 = "\x00lbb_main\x00"
$s5 = "\x00busybox\x00"
$s6 = "\x00/etc/busybox.conf\x00"
condition:
uint32(0) == 0x464c457f
and all of them
}
rule M_APT_Utility_SPAWNSLOTH_2
{
meta:
author = "Mandiant"
description = "Hunting rule to identify strings found in SPAWNSLOTH"
strings:
$dslog = "dslogserver" ascii fullword
$hook1 = "g_do_syslog_servers_exist" ascii fullword
$hook2 = "ZN5DSLog4File3addEPKci" ascii fullword
$hook3 = "funchook" ascii fullword
condition:
uint32(0) == 0x464c457f and all of them
}
from Threat Intelligence https://ift.tt/IskWLVS
via IFTTT
Cloud Security