Webinar
February 26
Better SOC with Interactive Sandbox
Practical Use Cases
0
Inside Kamasers: How a Six-Mode DDoS Botnet Uses Your Own Infrastructure Against You
Key Takeaways
- Kamasers is a multi-vector DDoS botnet with loader capabilities that supports HTTP GET/POST floods, slowloris, TCP SYN/ACK floods, UDP floods with IP spoofing, GraphQL-targeted attacks, and TLS handshake exhaustion.
- By retrieving C2 addresses from GitHub Gist, Telegram, Dropbox, Bitbucket, and even the Ethereum blockchain API (Etherscan), Kamasers hides command infrastructure behind trusted services that most enterprise networks whitelist by default.
- Infected systems can be used to attack third parties, creating legal and reputational risk.
- The threat is distributed through established malware delivery chains. Kamasers arrives via GCleaner and Amadey.
- It is actively observed in education, telecom, and tech sectors.
- ANY.RUN's Threat Intelligence Lookup lets security teams hunt Kamasers proactively. Analysts can surface related sandbox sessions, pivot across infrastructure, and track emerging Kamasers campaigns before they reach their own environment.
Kamasers sandbox samples found in TI Lookup
- Because Kamasers constructs its DDR links at runtime and encrypts its C2 addresses, static analysis alone cannot confirm infection. Executing the sample in ANY.RUN's Interactive Sandbox exposes the full kill chain, from DDR queries to C2 connection, DDoS execution, and payload download, within minutes.
Kamasers fresh sample analysis in Interactive Sandbox
What is Kamasers Malware?
Kamasers is a malware botnet family engineered to carry out distributed denial-of-service (DDoS) attacks using a wide range of techniques. Unlike older, simpler botnets that relied on a single flood method, Kamasers combines multiple attack vectors across both the application layer (Layer 7) and the transport layer (Layer 4), giving its operators a flexible toolkit for disrupting nearly any internet-accessible target.
The malware gets its name from the User-Agent string it uses during network communication with its command-and-control (C2) server — a naming convention that abuse.ch researchers noted when the threat was first publicly identified.
Beyond its DDoS capabilities, Kamasers can function as a loader, receiving commands from the C2 to download and execute additional files, significantly elevating the risk that a single infection could lead to data theft, ransomware deployment, or deeper persistent access.
The botnet uses a Dead Drop Resolver (DDR) mechanism to retrieve C2 addresses from legitimate public services including GitHub Gist, Telegram, Dropbox, Bitbucket, and even the Etherscan blockchain API making its infrastructure resilient and its malicious traffic difficult to distinguish from legitimate web activity.
ANY.RUN has also observed a related variant named Udados, assessed to be an evolution or updated version of Kamasers, and therefore considered part of the same family.
The Evolution of Kamasers
Kamasers variants and timeline
How Kamasers Threatens Businesses and Organizations
DDoS attacks are no longer purely a technical infrastructure problem. They escalate quickly into business crises — and Kamasers is specifically designed to maximize that escalation.
Corporate infrastructure weaponized against others. The infected company becomes, unwittingly, a source of attacks, creating reputational liability, potential contractual violations, and even legal exposure depending on jurisdiction and the nature of the targeted entities.
Single infection, multi-stage compromise. Because Kamasers operates as a loader as well as a botnet, a single successful infection can serve as the entry point for ransomware, infostealers, or remote access tools.
Detection blind spots from legitimate service abuse. By retrieving C2 addresses through services that are whitelisted in virtually every corporate network, Kamasers makes it extremely difficult for perimeter defenses and network monitoring tools to flag its communications as malicious. The malware's DDR links are also dynamically constructed at runtime, meaning static analysis of the binary will not reveal them.
Escalating response costs. Once Kamasers is identified on a corporate network, the organization must investigate infected hosts, validate whether they were used as attack sources, restore systems, address potential IP blacklisting, and manage regulatory scrutiny if any data compromise is identified. These costs accumulate rapidly.
Business trust erodes before the incident is contained. If customers, partners, or ISPs observe attack traffic originating from company infrastructure, trust may be damaged before the organization even understands the scope of what happened.
Victimology: Which Industries Are Most at Risk?
Kamasers is international in scope, with observed activity in Europe, North America, and Latin America. According to ANY.RUN threat intelligence data, the sectors most frequently targeted include:
Education: Large attack surfaces, often under-resourced security teams.
Telecommunications: High-value uptime targets; DDoS attacks cause immediate revenue and service impact.
Technology: API-heavy infrastructure makes GraphQL and HTTP flood attacks particularly disruptive.
Government / Public Sector: Railnet infrastructure linked to campaigns targeting European government organizations.
Financial Services: Not a primary observed target to date, but loader capability raises ransomware risk.
LATAM businesses (general): Direct DDoS targeting observed; C2 commands in Spanish suggest regional operator presence.
How Kamasers Gets Into Systems and Spreads
Kamasers does not arrive through zero-day exploits or self-propagating worms. Instead, it relies on established malware delivery ecosystems:
GCleaner. A pay-per-install malware distribution service that purchases access from other threat actors and redistributes payloads to systems already compromised by other means. GCleaner has been linked to numerous malware families.
Amadey. A well-documented loader/botnet used extensively by cybercriminals to deliver secondary payloads. Once Amadey has infected a host, it can be instructed to download and execute Kamasers.
This means Kamasers infections typically follow prior compromises. Common initial infection vectors feeding into these delivery chains include:
Phishing emails with malicious attachments or links
Trojanized software distributed through unofficial channels
Drive-by downloads from compromised or malicious websites
Exploitation of unpatched vulnerabilities leading to initial loader installation
Once Kamasers is deployed on a host, it connects to C2 infrastructure and begins receiving attack commands. The infected host becomes a bot node in the wider botnet. If the C2 issues a !download (or !descargar) command, additional payloads are fetched and executed, potentially spreading the compromise further within the same environment or establishing persistent access.
How Kamasers Functions
C2 Discovery via Dead Drop Resolver
After execution, Kamasers does not connect directly to a hardcoded C2 address. Instead, it uses a Dead Drop Resolver (DDR) mechanism: it sends HTTP GET requests to public services to retrieve the current C2 server address. The DDR channels used include:
GitHub Gist,
Telegram bot,
Dropbox-hosted file,
Bitbucket repository.
These links are not stored in plain text in the binary. Tthey are constructed and unpacked dynamically at runtime, defeating static analysis. The C2 address embedded in these resources is encrypted with AES-CBC and encoded in Base64.
If the first DDR channel fails, Kamasers falls back to the next in sequence. If all four channels are unavailable, it falls back to a built-in list of hardcoded backup domains. Additionally, in some observed cases, Kamasers queries the Etherscan API (api.etherscan.io) to retrieve the C2 address, leveraging public blockchain infrastructure as yet another evasion layer.
Command Processing Architecture
Once connected to the C2, the bot registers itself by transmitting its ID, current command execution status, bot version, privilege level on the infected host, C2 discovery source, and system information.
All valid commands must begin with the “!” character prefix. The bot validates this before processing. Kamasers uses a handler caching mechanism: if the previously used command handler matches the current command, the bot takes a fast path without performing a fresh lookup. Otherwise, it triggers dynamic resolution.
DDoS Attack Capabilities
Kamasers DDoS commands
Sandbox Analysis of Kamasers Sample
See the detonation of Kamasers
ANY.RUN sandbox revealing Kamasers killchain in real time
In the sandbox analysis session, we can see how a DDoS attack targets a domain:
DDoS attack targeting a domain, exposed inside ANY.RUN sandbox
As part of the analysis, it was observed that the bot had 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.
Communication between the infected host and the C2 server
In a number of analysis sessions (view another one), the command-and-control server was used not only to coordinate DDoS activity, but also to deliver additional payloads. Specifically, the bot received the !download command, after which it downloaded and executed a file from an external domain, then confirmed successful session completion to the C2 server:
Example of a C2 command used to download a malicious file
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:
Querying the Etherscan API to retrieve data
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:
Victim request to the C2 server
Behavioral analysis of Kamasers showed that the botnet frequently establishes connections to IP addresses associated with Railnet LLC’s ASN.
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.
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:
Query for RAILNET ASN in ANY.RUN’s TI Lookup
How Can Businesses Proactively Protect Against Kamasers
Kamasers relies on external infrastructure to receive commands, retrieve C2 addresses via DDR channels, and download additional payloads. Early detection therefore depends on monitoring for suspicious outbound connections and newly observed infrastructure before they can cause operational damage.
ANY.RUN's Threat Intelligence Feeds deliver continuously updated, actionable indicators of compromise (IOCs) — malicious domains, IPs — directly into a security team's existing stack (SIEM, firewalls, EDR). Since Kamasers frequently routes traffic through Railnet/Virtualine ASN infrastructure, feeds that surface ASN-level and IP-level indicators give SOC teams an early signal before a host begins actively participating in attacks.
Threat Intelligence Feeds features and integrations
Once Kamasers activity is confirmed on a host, the next priority is understanding how far the infection extends. ANY.RUN's Threat Intelligence Lookup allows analysts to search across a broad dataset of sandbox analysis sessions using structured queries.
From a single confirmed sample, TI Lookup enables pivoting to related infrastructure, identifying additional C2 servers, uncovering other malware families sharing the same ASN or delivery chain, and tracking how Kamasers campaigns evolve over time. This context is essential for distinguishing a contained infection from an ongoing, broader compromise.
Additional Protective Measures
Network monitoring and segmentation. Monitor for unexpected outbound connections to GitHub Gist, Telegram, Dropbox, Bitbucket, and Etherscan from hosts that have no business reason to access these services. Segment networks so that compromised hosts cannot easily communicate with or download files from external sources.
Endpoint protection and EDR. Deploy endpoint detection and response solutions capable of identifying the behavioral signatures of Kamasers: anomalous outbound HTTP GET requests, process injection, and execution of downloaded PE files.
Patch management. Because Kamasers arrives through loaders like Amadey and GCleaner, reducing the initial attack surface through consistent patching of known vulnerabilities is critical.
Email and web filtering. Block phishing vectors and malicious downloads that feed the delivery chains supplying Kamasers.
IP and ASN blocklisting. Use TI Feeds to maintain up-to-date blocklists covering known associated IP addresses.
Incident response planning. Prepare for the possibility that an infected host may have been used to attack third parties. Incident response plans should include external impact assessment and communication procedures for partners, customers, and legal counsel.
User awareness training: Run simulated phishing campaigns using the exact lure types TrustConnect employs: meeting invites, bid requests, tax notices, DocuSign.
Network monitoring: Alert on outbound WebSocket connections to unexpected hosts; monitor for anomalous screen-sharing or RDP-over-browser traffic patterns.
Incident response planning: Ensure IR playbooks explicitly address MaaS RAT scenarios with follow-on RMM persistence.
Conclusion
Kamasers demonstrates that DDoS threats have matured well beyond simple volumetric attacks. By combining multiple attack vectors, a resilient DDR-based C2 architecture that hides behind legitimate public services, a loader capability that can deliver ransomware or credential stealers as follow-on payloads, and delivery through established malware ecosystems, Kamasers is designed to cause maximum business disruption while remaining difficult to detect and attribute.
For organizations in the education, telecommunications, technology, and government sectors (and increasingly for any enterprise with internet-accessible infrastructure) Kamasers represents a credible and evolving threat. The botnet's operators appear to be actively developing it (as evidenced by the rapid language shift from Go to C and the emergence of the Udados variant), suggesting it will remain a fixture of the threat landscape.
Proactive defense, built on timely threat intelligence, behavioral sandbox analysis, and continuous monitoring of suspicious infrastructure, is the most effective response. Understanding how Kamasers operates — technically, tactically, and at the business level — is the first step in that defense.
Trial TI Lookup to start gathering actionable threat intelligence on the malware that threatens your business sector and region: just sign up to ANY.RUN.
