Millions of automated software development pipelines rely on security tools, such as Trivy and Checkmarx AST, integrated into the build process. It is precisely these trusted solutions recently became the entry point for one of the largest and most dangerous supply chain attacks in modern history. In this post we discuss how to audit automated workflows and secure corporate cloud infrastructure.

Timeline of the attack and known consequences

On March 19, a successful targeted supply chain attack was carried out via Trivy, an open-source vulnerability scanning tool widely used in CI/CD pipelines. The attackers, a group known as TeamPCP, managed to inject malware into official GitHub Actions workflows and Docker images associated with Trivy. As a result, every automated pipeline scan made triggered malware that stole SSH keys, cloud access tokens, cryptocurrency wallets, and other valuable data from compromised systems. Given the critical nature of the incident, it was assigned the identifier CVE-2026-33634 with a near-maximum CVSS4B score of 9.4.

Later that same day, the Trivy team detected the attack and removed malicious artifacts from the distribution channels, halting this phase of the attack. However, the attackers had already gained access to the environments of many Trivy users.

On March 23, a similar incident was discovered in another application security tool: a GitHub Action for Checkmarx KICS, as well as Checkmarx AST.  Three hours later, the malicious code was removed from there as well. TeamPCP also managed to compromise OpenVSX extensions supported by Checkmarx: cx-dev-assist 1.7.0 and ast-results. Reports on when this part of the incident was resolved vary.

On March 24, a popular project using Trivy’s code scanning — the LiteLLM AI gateway, a universal library for access to various LLM providers — was attacked. Versions 1.82.7 and 1.82.8, uploaded to PyPI repository, were compromised. These versions were publicly available for about 5 hours.

But the fact that the attack lasted only a few hours is no reason to dismiss it. Given the popularity of the affected projects, the malicious code could have been executed thousands of times, including within the infrastructures of very large companies.

This allowed attackers to deploy persistent backdoors in Kubernetes clusters, as well as launch the self-replicating CanisterWorm worm across the JavaScript npm ecosystem.

The attackers’ code has destructive capabilities that wipe out a Kubernetes cluster and all its nodes if it detects Farsi as the primary language or the Tehran time zone on the compromised system. In other regions, the malware simply steals data using CanisterWorm.

According to experts, more than 20,000 repositories are considered potentially vulnerable. The attackers claim to have stolen hundreds of gigabytes of data and more than 500,000 accounts.

How Trivy Was Attacked

To compromise Trivy, the attackers used credentials stolen in a previous incident. The previous Trivy compromise, which occurred in late February, was likely not fully contained, and the attackers — the TeamPCP group — returned with a new attack.  Trivy’s developers, Aqua Security, speculate that because credentials were being phased out gradually following the previous incident, the attackers were able to generate new access tokens for themselves before compromised old ones had been revoked.

As a result, TeamPCP was able to compromise GitHub Actions used in CI/CD pipelines. Using credentials with tag-writing privileges, the attackers forcibly overrode 76 out of 77 version tags in aquasecurity/trivy-action and all 7 tags in aquasecurity/setup-trivy, redirecting existing trusted versions to malicious commits. This resembles tactics observed in the Shai-Hulud 2.0 campaign.  As a result, workflows throughout the pipeline began executing the attackers’ code, while the release metadata showed no visible changes.

At the same time, the attackers published an infected Trivy binary (v0.69.4) to official distribution channels, including GitHub Releases and container registries.

LiteLLM Compromise

The compromise of the popular language model access tool LiteLLM could itself trigger a major wave of attacks across the chain of projects that use it. The attack took place on March 24, 2026, when TeamPCP directly published malicious versions of the library (1.82.7 and 1.82.8) on PyPI. Between 10:39 UTC and 16:00 UTC, these compromised packages contained a malware that stole credentials. It was embedded in the proxy_server.py file, and version 1.82.8 also contained a malicious litellm_init file. The stolen data was exfiltrated to the server models.litellm[.]cloud.

Customers using LiteLLM Cloud or the official LiteLLM Proxy Docker image were not affected due to strict version locking, whereas developers and downstream projects that installed unpinned versions via pip during the specified time window were compromised.

Within 3 hours, the malicious packages were removed from PyPI repository, and the LiteLLM team suspended new releases, rotated credentials, and engaged an external incident response process. Teams that use LiteLLM in their projects are advised to immediately check for the litellm_init.pth compromise indicator and routinely rotate all potentially compromised secrets.

Features of the TeamPCP Cloud Stealer malware

Attackers added new logic to GitHub Actions and the Trivy executable while preserving the original functionality. Vulnerability scan results via Trivy appeared normal, but at the same time, valuable data was being searched for and extracted. Malicious code was:

• performing reconnaissance (collected network data and environment variables);
• searching for tokens and credentials to access AWS and GCP cloud environments;
• scanning memory (/proc/*/mem) to extract secrets stored in the memory of Runner.Worker and Runner.Listener processes;
• extracting Kubernetes secrets (/run/secrets/kubernetes.io/serviceaccount);
• collecting data for connecting to database servers (MySQL, PostgreSQL, MongoDB, Redis, Vault);
• collecting any other API keys and secrets from environment files and CI/CD configuration files (.env, .json, .yml);
• searching for webhooks for Slack and Discord channels;
• searching for data related to crypto wallets (variables related to the Solana blockchain, as well as rpcuser and rpcpassword data).

The collected data was encrypted and uploaded to a server with a name similar to the name of the Trivy’s developers (scan.aquasecurtiy[.]org). As a backup mechanism, the attackers provided a way for uploading data to a repository named docs-tpcp.

The attack on CheckMarx and LiteLLM used a similar tactic with other typosquatting domains: models.litellm[.]cloud and checkmarx[.]zone.

Response and Defense Strategies for CVE-2026-33634

Existing signature-based checks and dependency scanning in public registries are no longer sufficient, as the malicious code was injected directly into trusted, signed actions and evaded detection until behavioral monitoring was applied. CI/CD pipelines have become the “new perimeter” of security.

Immediate Actions.  Ensure that all workflows use secure versions (Trivy binary 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6).

CI/CD pipeline administrators and security teams should immediately review their dependances to Checkmarx (kics-github-action, ast-github-action) and Trivy (setup-trivy and trivy-action) solutions. If workflows referenced a version tag rather than a specific SHA hash, carefully review your workflow execution logs for the duration of the active supply chain attack.

You should also check your network logs for traffic to the domains scan.aquasecurtiy[.]org, checkmarx[.]zone, and models.litellm[.]cloud. The presence of such traffic indicates that sensitive data has been successfully exfiltrated.

If a repository named docs-tpcp has appeared on organization’s GitHub, this may also indicate a successful data breach.

In any case, a proactive threat hunting should be conducted, assuming that the systems have been successfully compromised and that the attackers have rapidly advanced within the affected systems.

It is recommended to restore the affected environments from verified backups.

Dependency pinning and secret management. Ensure that exact dependency versions are pinned using cryptographic hashes in all pipelines and Dockerfiles. We advise transition from long-lived tokens to short-lived credentials by using a secrets manager tool and implementing OIDC integrations where they are supported. Minimize the injection of secrets into the runtime environment — do so only when it is absolutely necessary. Ensure that secrets are not stored on disk or in temporary files, and are not reused across different processes.

Other security measures. Allow only GitHub Actions from a list approved by the organization; block new and unverified processes. Configure GITHUB_TOKEN and other access keys in accordance with the principle of least privilege. Do not grant write permissions unless absolutely necessary.

To enhance the security of GitHub Actions, there are several open-source tools available:

• zizmor — a tool for static analysis and detection of configuration errors in GitHub Actions;
• gato and Gato-X — two versions of a tool that helps identify structurally vulnerable pipelines;
• allstar — a GitHub application developed by OpenSSF to configure and enforce security policies in GitHub organizations and repositories.

 

If you want to learn more about supply chain attacks, we invite you to look at our analytical report Supply chain reaction: securing the global digital ecosystem in an age of interdependence. It’s based on insights from technical experts and reveals how often organizations face supply chain and trusted relationship risks, where protection gaps remain, and what strategies to employ to improve resilience against this kind of threats.

Kaspersky official blog – ​Read More

DDoS attacks are no longer only an infrastructure problem. They can quickly turn into a business issue, affecting uptime, customer experience, and operational stability. Kamasers is a strong example of this new reality, with broad attack capabilities and resilient command-and-control mechanisms that allow it to remain active under pressure.

Let’s explore the Kamasers botnet through both technical and behavioral analysis, looking at the commands it receives, the geographic distribution of its attacks, and the functions implemented in the malware sample. Together, these elements help reveal how Kamasers operates and why it poses a serious threat to organizations worldwide

Key Takeaways 

• Kamasers is a sophisticated DDoS botnet that supports both application-layer and transport-layer attacks, including HTTP, TLS, UDP, TCP, and GraphQL-based flooding. 

• The malware can also act as a loader, downloading and executing additional payloads, which raises the risk of further compromise, data theft, and ransomware deployment.

• Its C2 infrastructure is resilient, using a Dead Drop Resolver (DDR) through legitimate public services such as GitHub Gist, Telegram, Dropbox, Bitbucket, and even Etherscan to retrieve active C2 addresses. 

• Analysis showed that Railnet ASN repeatedly appeared in malicious activity tied to multiple malware families, making it a notable infrastructure element in the broader threat landscape. 

• Kamasers was observed being distributed through GCleaner and Amadey, showing that it fits into established malware delivery chains. 

• The botnet’s activity is international, with strong submission visibility in Germany and the United States, while targeting extends across sectors including education, telecom, and technology.

The Business Risk Behind Kamasers 

Kamasers is a flexible attack platform that can turn compromised enterprise systems into operational liabilities, external attack infrastructure, and potential entry points for deeper compromise: 

• Corporate infrastructure can be turned against others: Infected enterprise systems may be used to launch DDoS attacks on third parties, creating reputational, contractual, and even legal risk for the organization. 

• A broader incident can follow quickly: Because Kamasers can function as a loader, a single infection may lead to additional payload delivery, raising the risk of data theft, ransomware, and deeper intrusion. 

• Visibility gaps become harder to defend: The malware uses legitimate public services to retrieve C2 information, making malicious communication more difficult to detect and increasing the chance of delayed response. 

• Response costs rise fast: Investigating infected hosts, validating external impact, restoring systems, and handling possible IP blacklisting can create significant operational and financial strain. 

• Business trust can be affected early: If company infrastructure is linked to malicious traffic, customers, partners, and providers may react before the full incident is even understood. 

Kamasers highlights a serious enterprise risk: attackers can use resilient C2 discovery, flexible attack methods, and follow-on payload delivery to turn a single compromise into an incident with operational, financial, compliance, and reputational consequences. 

Kamasers Threat Overview 

Kamasers is a malware botnet family designed to carry out DDoS attacks using both application-layer and transport-layer vectors. It supports HTTP GET/POST floods, API-targeted attacks, defense evasion techniques, TLS handshake exhaustion, connection-holding methods, as well as UDP and TCP floods. Infected nodes receive commands from the command-and-control infrastructure and generate the corresponding traffic. In addition, Kamasers can also function as a loader, downloading and executing files from the network. 

ANY.RUN previously observed activity associated with Udados, which is most likely an evolution or updated version of Kamasers. As such, Udados can be considered part of the Kamasers family. 

You can find public sandbox analysis sessions related to the Kamasers family with the following Threat Intelligence Lookup query: 

threatName:”kamasers” 

If a corporate host becomes part of a botnet and is used to carry out DDoS attacks, the organization may face financial risks related to incident response, system recovery, network costs, and potential contractual penalties, as well as regulatory scrutiny if inadequate security measures are identified, especially in cases involving data compromise. 

An additional risk stems from the malware’s ability to act as a loader, downloading and executing third-party payloads. This increases the likelihood of further intrusion, data exfiltration, ransomware deployment, and the resulting operational and reputational damage. 

C2 and Infrastructure  

As part of the analysis, it was observed that the bot received the !httpbypass control command, which initiates an HTTP flood attack against a specified URL with defined intensity and duration parameters. After completing the attack, the bot reported its status and returned to standby mode. 

View analysis session 

 In the sandbox analysis session, we can see how a DDoS attack targets a domain: 

In a number of analysis sessions, the command-and-control server was used not only to coordinate DDoS activity, but also to deliver additional payloads. Specifically, the bot received the !downloadcommand, after which it downloaded and executed a file from an external domain, then confirmed successful session completion to the C2 server: 

View analysis session 

In one observed case, the bot received the !descargar command, the Spanish-language equivalent of !download, to retrieve an executable file from an external domain. 

View analysis session with C2 command in Spanish 

In some cases, the Kamasers botnet was observed using public blockchain infrastructure as an auxiliary mechanism for obtaining the C2 address. Specifically, infected hosts queried the Etherscan API(api.etherscan.io) to retrieve data containing the URL of the command-and-control server: 

View session querying the Etherscan API 

After obtaining the URL, the bot connects to the C2 server and sends information about its ID, command execution status, bot version, privileges on the infected host, C2 discovery source, and system information: 

In a number of cases, Kamasers uses public services, including GitHub, as an auxiliary source of configuration: 

Check how Kamasers uses public services  

Behavioral analysis of Kamasers showed that the botnet frequently establishes connections to IP addresses associated with Railnet LLC’s ASN.

Railnet is regularly mentioned in public reporting as a legitimate front for the hosting provider Virtualine. This provider is known for the absence of KYC procedures, and some research has noted that the associated infrastructure is used to host malicious services and facilitate attacks. 

Railnet infrastructure has previously been observed in campaigns targeting both government and private-sector organizations across several European countries, including Switzerland, Germany, Ukraine, Poland, and France. 

There are also documented cases of Railnet infrastructure being used to distribute other malware families, including Latrodectus, which a number of reports link to activity associated with groups such as TA577. 

At the time of analysis, ANY.RUN data showed that Railnet’s ASN consistently appeared in reports tied to a wide range of malicious activity and was being used by multiple malware families. These were not isolated incidents, but a recurring pattern: the same ASN was repeatedly involved across different campaigns, making it a convenient infrastructure hub for threat actors. 

The current picture of Railnet activity can be quickly verified using ANY.RUN’s Threat Intelligence Lookup. Searching by ASN makes it possible to assess how extensively it is involved in malicious chains, which malware families interact with it, and how the nature of that activity changes over time: 

destinationIpAsn:”railnet” 

In the analyzed sandbox sessions, Kamasers was distributed via GCleaner and Amadey, a delivery pattern that has also been observed in other DDoS campaigns.

Attack Geography and Targeting 

Among the observed DDoS targets were companies in the LATAM region. However, according to ANY.RUN’s threat intelligence data, the targeting profile is broader: the education sector is affected most often, along with telecommunications and technology organizations. 

By geographic distribution of observed submissions, the largest share comes from Germany and the United States, with separate cases also recorded in Poland and other countries. During the analysis, control commands in Spanish were also observed. This may indirectly suggest that the botnet may have originated from, or evolved within, a Spanish-speaking operator environment, although its actual activity is clearly international in scope. 

It is also important to consider that the botnet uses the infrastructure of infected hosts to carry out attacks. If corporate systems are compromised, the organization may not only become a potential target itself, but also inadvertently serve as a source of attacks against third parties. This creates reputational risks, the possibility of IP address blacklisting, and additional financial costs related to investigation and infrastructure recovery. 

Technical Breakdown of Kamasers  

To better understand the Kamasers botnet architecture, a detailed sample analysis was conducted. The starting point was the sample from this ANY.RUN sandbox session:

Check analysis session 

This was followed by reverse engineering of the binary. The analysis focused primarily on how the malware receives and processes commands from the C2 server, as well as the attack capabilities implemented in the sample. 

After launch, the malware begins retrieving commands through a Dead Drop Resolver mechanism. It uses public services such as GitHub Gist, Telegram, Dropbox, and Bitbucket as intermediary sources. From these sources, the bot extracts the address of the real C2 server and then establishes a connection to it. 

Command processing takes place in several stages. First, the bot verifies that the command format is valid. All valid commands must begin with the “!” character. If this prefix is missing, the command is rejected and not executed. 

After validating the prefix, the bot matches the command against an internal handler table. The analysis showed that Kamasers uses a handler caching mechanism. If the previously used handler matches the current command index, the bot takes a fast path without performing another lookup. Otherwise, it triggers the dynamic resolution routine. 

This mechanism can be briefly described as shown in the pseudocode above. 

One of the most illustrative commands is !udppro. It implements a high-speed UDP flood with support for source IP spoofing. Code analysis shows the standard sequence for creating a UDP socket via the WinSock API using the AF_INET, SOCK_DGRAM, and IPPROTO_UDP parameters. 

After initializing the socket, the malware configures the packet transmission parameters. Support for IP spoofing enables reflection and amplification attacks through public NTP and DNS servers. In such scenarios, the victim receives responses that are significantly larger than the original requests, leading to a sharp increase in load.  

The !download command is also present, implementing a Download & Execute mechanism. The bot retrieves an executable file from the specified URL, checks for the MZ signature, allocates memory, maps the sections, and transfers execution to the entry point. If successful, it sends a task completion message; if an error occurs, it generates a failure notification. 

Implementation of Dead Drop Resolver Channels

Kamasers uses four Dead Drop Resolver channels: GitHub Gist, a Telegram bot, a file hosted on Dropbox, and a Bitbucket repository. Importantly, links to these services are not stored in the sample in plain form. Instead, they are constructed and unpacked dynamically at runtime, which is why such strings do not appear during static analysis of the binary. 

The Dead Drop Resolver (DDR) mechanism serves as an intermediary layer between the bot and the primary C2 server. After launch, the malware sequentially sends HTTP GET requests to each of the public resources. The content hosted there contains the current address of the command-and-control server. Once a response is received, the bot extracts the C2 address and establishes a direct connection to continue receiving commands. 

If the first source returns a valid address, no further requests are made. If the connection fails or the response is invalid, the bot automatically falls back to the next channel: Telegram, then Dropbox, and finally Bitbucket. 

All of these resources ultimately point to the same C2 infrastructure: 

If none of the DDR channels responds, the malware falls back to a built-in list of backup domains. 

Catching Kamasers Early: A Practical Detection Approach 

Kamasers shows how a single malware infection can quickly turn into a broader business problem. Beyond DDoS activity, the botnet can also download and execute additional payloads, increasing the risk of deeper compromise. 

For security teams, the challenge is not only spotting the malware itself but also understanding whether an infected host is being used for external attacks, communicating with resilient C2 infrastructure, or pulling in follow-on payloads. 

Early detection depends on moving quickly from suspicious network activity to confirmed malicious behavior. 

1. Monitoring: Spot Malicious Infrastructure and Unusual Network Behavior Early 

Kamasers relies on external infrastructure to receive commands, retrieve C2 addresses, and in some cases download additional payloads. It also uses public services such as GitHub Gist, Telegram, Dropbox, Bitbucket, and even Etherscan as part of its Dead Drop Resolver logic. 

Monitoring for suspicious outbound connections, newly observed infrastructure, and repeated communication with known malicious hosting can help teams detect activity before the infection leads to larger operational impact. 

ANY.RUN’s Threat Intelligence Feeds help surface suspicious indicators early, giving SOC teams faster visibility into malicious domains, IPs, and infrastructure patterns linked to emerging threats. 

2. Triage: Confirm Botnet Activity with Behavior-Based Analysis 

With threats like Kamasers, static detection alone may not show the full risk. A suspicious file may appear inconclusive until its real behavior is observed during execution. 

Running the sample inside the ANY.RUN interactive sandbox makes it possible to confirm the full execution flow, including: 

• retrieval of C2 data through Dead Drop Resolver channels 
• connection to the active command-and-control server 
• receipt and execution of DDoS commands 
• download-and-execute behavior through commands like !download or !descargar 
• status reporting back to the C2 infrastructure 

This helps teams quickly determine whether the malware is only participating in DDoS activity or whether it also creates risk of further payload delivery and deeper compromise. 

3. Threat Hunting: Pivot from One Sample to Related Infrastructure 

Once Kamasers is confirmed, the next step is understanding how far the activity may extend. 

Using ANY.RUN’s Threat Intelligence Lookup, teams can pivot from the initial sample to uncover related infrastructure, connected sessions, and recurring patterns across the broader campaign. 

This makes it possible to: 

• identify other samples tied to the Kamasers family 
• trace infrastructure linked to the botnet’s C2 activity 
• investigate repeated use of ASN-linked hosting such as Railnet
• expand detection based on shared behavior and network indicators 

threatName:”kamasers” 

By pivoting from one confirmed sample, security teams can turn a single investigation into broader visibility across related botnet activity. 

Conclusion 

Kamasers is a sophisticated DDoS botnet with a well-designed architecture. Its use of a Dead Drop Resolver through legitimate services makes its C2 infrastructure highly resilient to takedown efforts. The presence of 16 different attack methods, including modern vectors such as GraphQL and HTTP bypass, along with advanced implementations of classic techniques, makes Kamasers a highly versatile tool for carrying out DDoS attacks. 

For business leaders, Kamasers shows that resilient, multi-vector botnets can threaten not only infrastructure, but also uptime, customer experience, and revenue-critical operations. 

Power faster, clearer investigations with ANY.RUN ➜ 

About ANY.RUN 

ANY.RUN, a leading provider of interactive malware analysis and threat intelligence solutions, fits naturally into modern SOC workflows and supports investigations from initial alert to final containment.  

It allows teams to safely execute suspicious files and URLs, observe real behavior in an interactive environment, enrich indicators with immediate context through TI Lookup, and continuously monitor emerging infrastructure using Threat Intelligence Feeds. Together, these capabilities help reduce uncertainty, accelerate triage, and limit unnecessary escalations across the SOC.  

ANY.RUN also meets enterprise security and compliance expectations. The company is SOC 2 Type II certified, reinforcing its commitment to protecting customer data and maintaining strong security controls.  

Complete List of Kamasers Commands 

Indicators of Compromise (IOCs)   

• F6c6e16a392be4dbf9a3cf1085b4ffc005b0931fc8eeb5fedf1c7561b2e5ad6b
• Dd305f7f1131898c736c97f43c6729bf57d3980fc269400d23412a282ee71a9a
• hxxp://45[.]151[.]91[.]187/pa[.]php
• hxxp://91[.]92[.]240[.]50/pit/wp[.]php
• 071a1960fbd7114ca87d9da138908722d7f1c02af90ea2db1963915fbe234c52
• hxxp://178[.]16[.]54[.]87/uda/ph[.]php

C2 Infrastructure (DDR): 

• gist[.]github[.]com/pitybugak/5d16b75e8bd071e15b04cc9c06dcfafa[.]js
• api[.]telegram[.]org/bot8215158687:AAFgSmsaxfsJozcHIIYPv-HytZ3eCEaUrKg
• dl[.]dropboxusercontent[.]com/s/jqvpmc0kwg6ffi1mineh2/fj[.]txt
• Bitbucket[.]org/serky/repyx/raw/main/fq[.]txt

Fallback domains: 

• pitybux[.]com
• ryxuz[.]com
• toksm[.]com
• Boskuh[.]com

Yara rules: 

rule Kamasers { 

    meta: 

        description = “Detects Kamasers DDoS botnet” 

        author = “ANY.RUN” 

        date = “2026-02-11” 

        threat = “Kamasers” 

    strings: 

        $cmd1 = “!stop” ascii fullword 

        $cmd2 = “!download” ascii fullword 

        $cmd3 = “!visiturl” ascii fullword 

        $cmd4 = “!httpget” ascii fullword 

        $cmd5 = “!httpgetpro” ascii fullword 

        $cmd6 = “!httppost” ascii fullword 

        $cmd7 = “!tlsflood” ascii fullword 

        $cmd8 = “!httpbypass” ascii fullword 

        $cmd9 = “!graphql” ascii fullword 

        $cmd10 = “!httphulk” ascii fullword 

        $cmd11 = “!fastflood” ascii fullword 

        $cmd12 = “!proloris” ascii fullword 

        $cmd13 = “!slowread” ascii fullword 

        $cmd14 = “!udppro” ascii fullword 

        $cmd15 = “!tcppro” ascii fullword 

        $cmd16 = “!tcphold” ascii fullword 

        $msg1 = “Task completed:” ascii fullword 

        $msg2 = “Task completed: GraphQL Flood on” ascii fullword 

        $msg3 = “Task completed: HULK on” ascii fullword 

        $msg4 = “Task completed: UDPPRO Flood on” ascii fullword 

        $msg5 = “Task completed: TCPPRO Flood on” ascii fullword 

        $msg6 = “Task completed: TCP HOLD on” ascii fullword 

        $msg7 = “Task completed: Download & Execute from” ascii fullword 

        $msg8 = “Task completed: Visit URL” ascii fullword 

        $msg9 = “Starting GraphQL Flood on” ascii fullword 

        $msg10 = “Starting HULK on” ascii fullword 

        $msg11 = “Starting UDP PRO on” ascii fullword 

        $msg12 = “Starting TCP PRO on” ascii fullword 

        $msg13 = “Starting TCP HOLD on” ascii fullword 

        $msg14 = “Starting Visit URL task on” ascii fullword 

        $msg15 = “Runtime error in D&E task:” ascii fullword 

        $msg16 = “Unknown exception in DownloadAndExecuteTask” ascii fullword 

        $msg17 = “Awaiting task” ascii fullword 

        $msg18 = “Downloading file from:” ascii fullword 

        $msg19 = “Downloaded file disappeared (AV/EDR?)” ascii fullword 

        $msg20 = “Download failed with HRESULT:” ascii fullword 

        $msg21 = “HTTP GET Flood” ascii fullword 

        $msg22 = “HTTP GET PRO” ascii fullword 

        $msg23 = “HTTP POST Flood” ascii fullword 

        $msg24 = “HULK_POST” ascii fullword 

    condition: 

        uint16(0) == 0x5A4D and 

        (10 of ($cmd*)) and 

        (8 of ($msg*)) 

} 

The post Kamasers Analysis: A Multi-Vector DDoS Botnet Targeting Organizations Worldwide  appeared first on ANY.RUN’s Cybersecurity Blog.

ANY.RUN’s Cybersecurity Blog – ​Read More

A variety of AI-powered app builders promise to bring your ideas to life quickly and effortlessly. Unfortunately, we know exactly who’s always on the lookout for new ideas to bring to life — mostly because we’re rather good at spotting and blocking their old ones. We’re talking about phishers, of course. Recently, we discovered they’ve added a new trick to their arsenal: generating websites using the Bubble AI-powered web-app builder. It’s highly likely that this tactic is now available through one or more phishing-as-a-service platforms, which virtually guarantees these decoys will start appearing in a wide range of attacks. But let’s break this down step-by-step.

Why are phishers using Bubble?

Including a direct link to a phishing site in an email is a one-way ticket to failure. There’s a high probability the message won’t even reach its destination, as security filters will likely block it before a user ever sees it. Similarly, using automated redirects has long been a major red flag for modern security solutions. What about QR codes? While having a victim scan a code with their phone instead of clicking a link might work in theory, phishers inevitably lose traffic at that step — not everyone is willing to enter corporate credentials on a personal device. This is where automated code-generation services come to the rescue for the cybercriminals.

Bubble positions itself as a no-code platform for developing web and mobile applications. Essentially, a user describes what they need through a visual interface, and the platform generates a finished solution. Phishers have adopted this technology to create web apps whose addresses they then embed in their phishing emails. While the actual function of these apps boils down to the same old automated redirect to a malicious site, there are a couple of specific nuances at play.

First, the resulting web application is hosted directly on the platform’s servers. The URL ready for use in a phishing email looks something like https://%name%.bubble.io/. From the perspective of security solutions, this appears to be a legitimate, long-standing site.

Second, the code for this web application doesn’t look like a typical redirect. To be honest, it’s hard to say what it looks like. The code generated by this no-code platform is a massive jumble of JavaScript and isolated Shadow DOM (Document Object Model) structures. Even for an expert, it’s difficult to grasp what’s happening at first glance; you really have to dig through it to understand how it all works and what the purpose is. Automated web-code analysis algorithms are even more likely to get tripped up, frequently reaching the verdict that this is just a functional, useful site.

What are these phishing platforms, and what is the end goal?

Today’s phishers rarely develop and implement new tricks from scratch. Most use phishing kits — essentially DIY builders for launching fraudulent schemes — or even full-scale phishing-as-a-service platforms.

These platforms provide attackers with a sophisticated (and highly frustrating) toolkit that’s constantly evolving to improve email delivery and bypass anti-phishing defenses. For example, these tools allow attackers, among many other things, to do the following: intercept session cookies; conduct phishing through Google Tasks (a tactic we covered in a previous post); execute adversary-in-the-middle (AiTM) attacks to validate two-factor authentication (2FA) and bypass it in real time; create phishing sites equipped with honeypots and geofencing to hide from security crawlers; and use AI assistants to generate unique phishing emails. To make matters worse, the infrastructure for these platforms is usually hosted on perfectly legitimate services like AWS, making their tactics even harder to spot.

The same platforms are used to make the final destination page that harvests credentials. In this specific case, the web app hosted on Bubble redirects victims to a site — complete with a Cloudflare verification check — that mimics a Microsoft sign-in window.

Apparently, in the attackers’ parallel universe, Skype is still a viable communication tool, but otherwise, the site looks remarkably convincing.

How to protect your company from sophisticated phishing attacks

In today’s digital landscape, employees need to clearly understand that corporate credentials should only be entered on services and websites that undeniably belong to the company. You can raise your team’s awareness of modern cyberthreats using Kaspersky Automated Security Awareness Platform for online training.

Of course, even the most cautious employee might occasionally take the bait. We recommend equipping all internet-connected workstations with robust security solutions that’ll simply block any attempt to visit a malicious site. Finally, to cut down on the number of dangerous emails cluttering up corporate inboxes in the first place, we suggest deploying a gateway security product with advanced anti-phishing technologies.

Kaspersky official blog – ​Read More

The 2025 Talos Year in Review is now available to view online.

The pace and scale of adversary activity in 2025 placed sustained pressure on security teams across industries. As with each annual report, our goal at Talos is to provide the security community with a clear analysis of the tactics, techniques, and procedures that shaped adversary operations, and to help organizations prioritize the actions that reduce exposure and strengthen defenses.

What defined 2025

Three themes emerged consistently across Talos’ threat research, telemetry, and incident response engagements:

1. Exploitation at both extremes

New large-scale vulnerabilities were operationalized almost immediately, but adversaries also continued to exploit CVEs that have been exposed for years. This rapid operationalization of new vulnerabilities reflects a rise in automated exploit development, public proof-of-concept code, and mature adversary coordination.

React2Shell, released in December, ranked first by year’s end only three weeks after disclosure, while a vulnerability disclosed 12 years ago ranked seventh. That range tells a story about organizational technical debt: Long-standing exposure continues to be reliably and successfully exploited.

2. The architecture of trust

In 2025, adversaries focused on the systems that manage authentication, authorization, and device trust.

Attackers who gained access through compromised credentials stealthily extended that access through internal phishing and abuse of identity controls within network infrastructure. Control of identity often meant control of the environment.

3. Targeting centralized systems for more leverage

Threat actors targeted centralized infrastructure, management platforms, and shared frameworks to expand the impact of a single compromise.

Approximately 25% of the vulnerabilities in the Top 100 targeted list affected widely used frameworks and libraries that are embedded deep within the software stack. Because these components underpin applications and network appliances across vendors, a single CVE can create mass exploitation potential across industries. Compromising these shared foundations enabled lateral movement across environments. 

Read the full report

View the full report online (it’s not gated and never will be) to see where attackers are gaining ground, and how to disrupt their playbook. 

Cisco Talos Blog – ​Read More

Cybersecurity researchers have taken a close look at the inner workings of the Predator spyware, developed by the Cyprus-based company Intellexa. Rather than focusing on how the spyware initially infects a device, this latest research zooms in on how the malware behaves once a device has already been compromised.

The most fascinating discovery involves the mechanisms the Trojan uses to hide iOS camera and microphone indicators. By doing so, it can covertly spy on the infected user. In today’s post, we break down what Predator spyware actually is, how the iOS indicator system is designed to work, and how this malware manages to disable these indicators.

What Predator is, how it works, and what… Alien has to do with it

We previously took a deep dive into the most notorious commercial spyware out there in a dedicated feature — where we discussed the star of today’s post, Predator, among the others. You can check out that earlier post for a detailed review of this spyware, but for now, here’s a quick refresher on the essentials.

Predator was originally developed by a North Macedonian company named Cytrox. It was later acquired by the aforementioned Intellexa, a Cyprus-registered firm owned by a former Israeli intelligence officer — a truly international spy games collaboration.

Strictly speaking, Predator is the second half of a spyware duo designed to monitor iOS and Android users. The first component is named Alien; it’s responsible for compromising a device and installing Predator. As you might’ve guessed, these pieces of malware are named after the famous Alien vs. Predator franchise.

An attack using Intellexa’s software typically begins with a message containing a malicious link. When the victim clicks it, they’re directed to a site that leverages a chain of browser and OS vulnerabilities to infect the device. To keep things looking normal and avoid raising suspicion, the user is then redirected to a legitimate website.

Besides Alien, Intellexa offers several other delivery vehicles for landing Predator on a target’s device. These include the Mars and Jupiter systems, which are installed on the service provider’s side to infect devices through a man-in-the-middle attack.

Predator spyware for iOS comes packed with a wide array of surveillance tools. Most notably, it can record and transmit data from the device’s camera and microphone. Naturally, to keep the user from catching on to this suspicious activity, the system’s built-in recording indicators — the green and orange dots at the top of the screen — must be disabled. While it’s been known for some time that Predator could somehow hide these alerts, it’s only thanks to this research that we know how exactly it pulls it off.

How the iOS camera and microphone indicator system works

To understand how Predator disables these indicators, we first need to look at how iOS handles them. Since the release of iOS 14 in 2020, Apple devices have alerted users whenever the microphone or camera is active by displaying an orange or green dot at the top of the screen. If both are running simultaneously, only the green dot is shown.

Just like other iOS user interface elements, recording indicators are managed by a process called SpringBoard, which is responsible for the device’s system-wide UI. When an app starts using the camera or microphone, the system registers the change in that specific module’s state. This activity data is then gathered by an internal system component, which passes the information to SpringBoard for processing. Once SpringBoard receives word that the camera or microphone is active, it toggles the green or orange dot on or off based on that data.

From an app’s perspective, the process works like this: first, the app requests permission to access the camera or microphone through the standard iOS permission mechanism. When the app actually needs to use one or both of these modules, it calls the iOS system API. If the user has granted permission, iOS activates the requested module and automatically updates the status indicator. These indicators are strictly controlled by the operating system; third-party apps have no direct access to them.

How Predator interferes with the iOS camera and microphone indicators

Cybersecurity researchers analyzed a captured version of Predator and uncovered traces of multiple techniques used by the spyware’s creators to bypass built-in iOS mechanisms and disable recording indicators.

In the first approach — which appears to have been used during early development — the malware attempted to interfere with the indicators at the display stage right after SpringBoard received word that the camera or microphone was active. However, this method was likely deemed too complex and unreliable by the developers. As a result, this specific function remains in the Trojan as dead code — it’s never actually executed.

Ultimately, Predator settled on a simpler, more effective method that operates at the very level where the system receives data about the camera or microphone being turned on. To do this, Predator intercepts the communication between SpringBoard and the specific component responsible for collecting activity data from these modules.

By exploiting the specific characteristics of Objective-C — the programming language used to write the SpringBoard application — the malware completely blocks the signals indicating that the camera or microphone has been activated. As a result, SpringBoard never receives the signal that the module’s status has changed, so it never triggers the recording indicators.

How to lower your risk of spyware infection

Predator-grade spyware is quite expensive, and typically reserved for high-stakes industrial or state-sponsored espionage. On one hand, this means defending against such a high-tier threat is difficult — and achieving 100% protection is likely impossible. On the other hand, for these same reasons, the average user is statistically unlikely to be targeted.

However, if you’ve reason to believe you’re at risk from Predator or Pegasus-class spyware, here are a few steps you can take to make an attacker’s job much harder:

• Don’t click suspicious links from unknown senders.
• Regularly update your operating system, browsers, and messaging apps.
• Reboot your device occasionally. A simple restart can often help “lose the tail”, forcing attackers to reinfect the device from scratch.
• Install a reliable security solution on all the devices you use.

For a deeper dive into staying safe, check out security expert Costin Raiu’s post: Staying safe from Pegasus, Chrysaor and other APT mobile malware.

Curious about other ways your smartphone might be used to spy on you? Check out our related posts:

• How smartphones build a dossier on you
• Are your Bluetooth headphones spying on you?
• How to track anyone via the Find My network
• How to stop being tracked via Bluetooth beacons like AirTag
• Operation Triangulation: the most sophisticated iOS spyware we’ve ever found

Kaspersky official blog – ​Read More