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.
Security teams have never had more visibility, yet rarely have they felt more uncertain. Signal pours in from endpoints, identities, cloud workloads, and a sprawling mix of third-party tools. Dashboards are full, alerts keep coming, but the hardest question of the day remains unanswered: of everything happening right now, what actually matters to us, and what do we do about it?
That space between knowing a threat exists and acting on it is the intelligence-to-action gap, and it’s where most breaches are won or lost. It doesn’t close with another feed or another dashboard. It closes with expertise: seasoned defenders who know your environment, interpret what global signal means for your risk, and stay with you from the first indicator to the final response.
Today we’re announcing a new service, Microsoft Defender Experts Threat Intelligence, and we are expanding Microsoft Defender Experts MDR to include new third-party and multi-cloud coverage. Together, these human-led offerings are designed to close the intelligence-to-action gap at the two moments that decide the outcome: before a campaign reaches you, and as it moves through your environment.
Upstream: See the campaign before it reaches you
The earlier you see a campaign forming, the more options you have, and the cheaper every decision becomes. Yet most threat intelligence still arrives as raw feeds or static reports: high in volume, low in context, and disconnected from what’s exposed in your estate. Teams end up with more to read and no more clarity on what to do about it.
Microsoft Defender Experts Threat Intelligence is a new, expert-delivered service that closes that distance. Built on Microsoft’s visibility across endpoints, identity, cloud, and evolving attacker activity, it gives your team periodic, curated insight into the threats most likely to target you. Designated Microsoft experts interpret the global landscape through the lens of your industry, geography, and environment, then translate it into clear, prioritized guidance your team can act on.
As campaigns evolve, experts continuously refine that guidance with newly observed infrastructure, tactics, and targeting patterns, helping your team adjust hunting, hardening, and response activities. The insight is tailored for both leadership and defenders, providing executive-ready context alongside technical recommendations so the entire organization can act from a shared understanding of the threat landscape. The goal is simple: help you reduce risk before an attack reaches your environment, not explain what happened after the fact.
In practice, your team receives:
Early-warning alerts on emerging campaigns relevant to you
Campaign-evolution updates as activity unfolds
Contextualized intelligence tied to your risk profile
Recurring briefings from your designated expert, rotating across geopolitical, industry, and global perspectives, on a scheduled basis
Microsoft Defender Threat Intelligence Now Integrated into Defender
While this new expert-delivered service helps customers turn threat intelligence into action through direct engagement with Microsoft analysts, we’re also continuing to bring that same type of insight closer to defenders’ day-to-day workflows. Today we’re announcing that Microsoft Defender Threat Intelligence (MDTI) capabilities are now fully converged into the Defender portal. Intelligence is available real-time across detection, investigation, response, hunting, and automation, reducing context switching and helping teams move more quickly from signal to action within a unified SecOps experience.
In your environment: Follow the threat everywhere it moves
Modern attacks rarely stay in one place. They cross from email to endpoint to identity to cloud, and increasingly traverse disparate security tools. Even when organizations have visibility into those environments, connecting multi-vendor and multi-domain signals into a coherent attack story remains a challenge.
That’s the gap we’re closing on the response side: Microsoft Defender Experts MDR (formerly Microsoft Defender Experts for XDR) is expanding with new third-party and multi-cloud coverage powered by Microsoft Sentinel. Defender Experts MDR provides a fully managed detection and response service that reduces noise, adds expert context, and drives action. With support for leading non-Microsoft sources across cloud, identity, email, network, and endpoint environments, our experts can follow attacks wherever they move, not just where Microsoft products operate.
The service is backed by Microsoft’s vast threat intelligence, and combines expert-authored detections and analytics, investigation and response automation, and ongoing operational guidance to help customers strengthen security outcomes across their environment.
In practice, customers gain:
24/7 monitoring and investigation by Microsoft experts who distil high‑volume telemetry into high‑confidence, prioritized incidents that dramatically reduce analyst fatigue and accelerate response.
Cross-platform threat analysis that correlates signals across Microsoft and non-Microsoft environments to deliver a single incident narrative with actionable, vendor‑aware guidance.
Ongoing recommendations to optimize security operations, from detection tuning and data integration to content management in Sentinel.
Business-aligned summaries of top risks, posture gaps, and recommended improvements across the security estate.
This expanded coverage is available through Microsoft Defender Experts MDR Plan 2. Everything available today as Defender Experts for XDR carries forward unchanged as Microsoft Defender Experts MDR Plan 1, while Plan 2 extends that same expert-led triage, investigation, and response beyond Microsoft’s own estate.
See it live at Black Hat USA
Every one of today’s announcements aims at the same outcome: shrinking the distance between a signal arriving and a decision being made. That’s the measure that matters in the end—not alerts triaged, but decisions made faster and with more confidence.
Come see it at Black Hat. Join our session Mind the Gap: Turning Threat Intelligence into Decisive Action with Expert-Led Defense, where Wes Malaby, General Manager of Customer Success at Microsoft Security, will demonstrate how expert-led intelligence and defense can change the trajectory of a threat campaign from the earliest warning signs through response and remediation. After the session, stop by theMicrosoft Security booth to connect with our experts and learn how these services fit into your broader security strategy, or attend our reception on August 5 for a more conversational environment.
Mandiant security assessments frequently identify publicly exposed serverless applications that lack authentication, often as a result of specific business requirements. Serverless deployments typically run custom-developed code that incorporates third-party packages, making them targets for a wide range of application-level attacks, including:
Local and Remote File Inclusion (LFI/RFI)
Command Injection
Successful exploitation of these vulnerabilities can grant an attacker full control over the underlying container instance. Such access can serve as a foothold that may ultimately lead to a full compromise of the victim’s cloud environment.
Based on lessons learned in customer engagements, in this blog post we describe attack scenarios and provide actionable guidance on how to secure serverless environments. While this analysis focuses on hardening strategies for Google Cloud Run services and functions that must remain publicly accessible, these principles apply universally to any public serverless deployment.
What are Serverless Applications?
Serverless applications, also described as Function-as-a-Service (FaaS), allow the deployment of individual blocks of code as microservices within a flexible, decoupled, and event-driven cloud architecture without the need to manage underlying infrastructure. These services enable applications and automations to scale automatically and deploy instantly, removing operational overhead. Serverless services underpin major e-commerce, media, payment processing applications, and AI usage.
The rapid expansion of generative AI adoption is a significant driver of increased serverless architecture use. AI workflows, including chatbot interactions, image generation, “vibe-coding”, and multi-step AI agents rely on serverless functions to complete tasks for users. This growth has made securing serverless environments a more pressing challenge for enterprise security teams.
Risks of Serverless Application Attacks
Publicly exposed serverless workloads can serve as an initial access point for threat actors. As noted, these services may contain vulnerabilities within the code, imported packages, or the underlying runtime environment.
Once an entry point is exploited, attackers typically attempt to escalate privileges or move laterally. Common techniques observed include:
Extracting secrets stored directly within the application code.
Reviewing application logic and sensitive data to identify further attack vectors within the environment.
Exfiltrating service account bearer tokens from the metadata server following successful Remote Code Execution (RCE).
Leveraging these compromised secrets or service accounts allows threat actors to pivot to adjacent systems and workloads, potentially resulting in a total environment takeover if proper hardening strategies are not in place.
Example Attack Scenarios
The following simplified scenarios illustrate how serverless functions can be compromised and how attackers pivot after achieving initial code execution.
Local File Inclusion (LFI)
In the following Cloud Run example, a Python/Flask function accepts user-controlled input to open a file without performing proper validation. This pattern is an example of a Local File Inclusion (LFI) vulnerability.
import functions_framework
@functions_framework.http
def hello_http(request):
request_json = request.get_json(silent=True)
request_args = request.args
if request_json and 'file' in request_json:
file = request_json['file']
elif request_args and 'file' in request_args:
file = request_args['file']
# VULNERABILITY: The 'file' parameter is used directly in open()
# without validation, allowing arbitrary file access
with open(file, 'r') as resp:
filedata = resp.read()
return 'local file data {}!'.format(filedata)
Figure 1: Vulnerable Python/Flask function accepting unvalidated user input to open files
This vulnerability allows an attacker to request sensitive files from the Cloud Run instance by using curl to send a POST request via the file parameter:
curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "main.py"}'
Figure 2: curl POST request targeting the file parameter
The response provides the complete main.py source code. An attacker can analyze the code for:
Hardcoded secrets such as API keys, database credentials, or authentication tokens
Business logic flaws and additional injection points
Internal service endpoints and architecture details
Import statements revealing the technology stack and potential CVE exposure
Additionally, attackers can leverage standard ../ directory traversal sequences to retrieve sensitive system files:
curl -X POST https://cloudrun01-abc.europe-west3.run.app/ -H "Content-Type: application/json" -d '{"file": "../../../etc/passwd"}'
Figure 3: curl POST request leveraging directory traversal sequences
An LFI vulnerability allows an attacker to retrieve and fuzz various files directly from the container. Key examples include:
requirements.txt, package.json, go.mod: Used to identify installed packages and versions with known vulnerabilities.
.env files: Frequently contain sensitive environment variables or hard coded secrets.
Application configuration files: May contain database credentials, API keys, or service endpoints if not securely managed.
/etc/passwd, /proc/self/environ: Contains user information, environment variables.
Application logs: may contain auth tokens or PII data.
Best Practice: Never store secrets or credentials within the source code or local container files. Utilize a dedicated secrets management solution, such as Secret Manager.
Code Execution/Command Injection
In the following scenario, a Python function uses shell execution methods with unsanitized user input, allowing an attacker to execute arbitrary commands.
import functions_framework
import subprocess
@functions_framework.http
def hello_http(request):
request_json = request.get_json(silent=True)
request_args = request.args
if request_json and 'input' in request_json:
input = request_json['input']
elif request_args and 'input' in request_args:
input = request_args['input']
result = subprocess.run(input, shell=True,capture_output=True, text=True)
return format(result)
Figure 4: Python function utilizing shell execution with unsanitized user input
This allows an attacker to execute a subsequent curl request targeting the GCP metadata service to retrieve the service account’s bearer token.
The following request extracts the service account's OAuth 2.0 bearer token, which remains valid for 1 hour:
Figure 5:Extraction of a GCP service account bearer token via a curl request
Once obtained, an attacker can use it on an attacker-controlled system to execute Google Cloud CLI commands. For example the CLOUDSDK_AUTH_ACCESS_TOKEN environment variable can be set using the stolen bearer token.
Attackers can then leverage Google Cloud Cloud CLI within the security context of the Cloud Run Compute service account. If deployed without best practices and thoughtful configuration controls, for example, if the Cloud Run service runs as the default compute service account with Editor permissions, this would be equivalent to a full GCP project takeover, and allow the attacker to:
Read/write/delete most GCP resources
Deploy new services and modify existing configurations
Access secrets and encryption keys
Exfiltrate data across all accessible storage systems
Establish persistent backdoors through new service accounts or SSH keys.
Hardening Recommendations
Mandiant recommends that organizations implement parallel approaches for effective serverless security:
Secure Software Development Lifecycle (S-SDLC): integrate security scanning, code review, least-privilege IAM into CI/CD pipelines before deployment and integrate continuous security testing;
Vibe Coding: Mandiant recommends multi-layered security enforcement for AI-generated code or "vibe coding." Organizations should isolate AI experimentation within dedicated sandbox environments and enforce strict data egress controls to protect production systems and internal data. Furthermore, development environments should be restricted to approved IDEs with human-in-the-loop capabilities, utilizing only verified plugins operating under least privilege to mitigate supply chain vulnerabilities. Finally, organizations must ensure this AI-generated software follows Secure Software Development Lifecycle (S-SDLC) controls while establishing clear internal guidelines regarding permitted use cases. Comprehensive security fundamentals for vibe coding are documented in detail within the Wiz Vibe Coding Security Fundamentals blog.
Compensating Runtime Controls: Implement the following defense-in-depth measures to limit and contain compromise even when application vulnerabilities exist;
Segregate Public Services
Host public-facing Cloud Run services consumed by untrusted external entities in a dedicated, isolated Google Cloud project. This ensures a compromise does not provide an immediate path to critical internal resources. The implementation of this 'Service Project' model is beyond the scope of this post; however, it is documented in detail within the secured serverless architecture blueprint.
Identity and Access Management (IAM)
Mandiant recommends using a custom service account for service authentication rather than the default Compute Engine service account, following the principle of least privilege. Grant only the specific permissions necessary for the Cloud Run function to operate, for example:
Cloud Storage Bucket Access: If the service only requires read access to objects from a Cloud Storage bucket, grant the Storage Object Viewer (roles/storage.objectViewer) role restricted to that specific bucket.
Secret Manager Access: If the service requires access to secrets, grant the Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) role only to the individual secrets required. For further details on secret access from Cloud Run, refer to the GCP documentation on configuring secrets.
Restrict ingress traffic for serverless functions to internal only and use an external Layer 7 ALB to manage internet exposure. This provides:
Centralized Traffic Management: Granular control over headers and SSL policies.
Cloud Armor Integration: Web Application Firewall (WAF) support to harden applications against vulnerabilities such as Local/Remote File Inclusion (LFI/RFI) and Server-Side Request Forgery (SSRF).
Traffic Shaping: Implementation of rate limits and request limitations to prevent abuse.
Enhanced Visibility: Robust logging and log-forwarding capabilities for security monitoring.
Identity-Aware Proxy (IAP): integration support for scenarios requiring specific identity-based authentication for internal users.
Web Application Firewall (WAF) — Cloud Armor
Cloud Armor provides WAF protections that can be integrated with the Load Balancer to filter malicious traffic. The following examples demonstrate how to configure Cloud Armor security policies to block the specific local file inclusions, remote code execution and traversal attacks previously outlined.
Local File Inclusion
The lfi-v33-stable preconfigured WAF rules can block common local file inclusion attacks (local file inclusion reference).
Figure 10: Verification of Cloud Armor blocking Remote Code execution, resulting in a 403 forbidden
Serverless Architecture Controls
Hardening Cloud Run services is only one part of a secure architecture. Because these services often connect to other Google Cloud resources, a single compromise can expose additional services. Implementing defense-in-depth is critical. Specifically, when using direct VPC egress or VPC Access connectors, use VPC Service Controls to restrict lateral movement and exfiltration through granular access policies.
Secure Software Development Lifecycle (S-SDLC)
While the previously outlined hardening strategies are critical, the ideal standard remains the proactive identification of vulnerabilities during the initial development stages. A deep dive into "Shift-Left" security is beyond the scope of this analysis, which focuses on mitigating risks within existing code. However, a Secure Software Development Lifecycle (S-SDLC) remains a fundamental principle. Robust code validation and continuous security testing are essential to neutralize threats before serverless functions are published externally.
Cloud Run Threat Detection
Beyond the hardening recommendations outlined in this post, Google Cloud Security Command Center (SCC) provides built-in services to detect control plane attacks against Cloud Run resources. These include detectors for credential access, reconnaissance, and the execution of scripts or reverse shells. The Cloud Run Threat Detection service is available for Premium and Enterprise tiers.
Conclusion
Serverless applications drive agility and rapid business value. While "vibe-coding" has made it easier than ever to deploy code, this breakneck speed demands that teams integrate security early in the development lifecycle, move beyond default configurations, and prioritize a defense-in-depth strategy centered on identity and architecture.
Acknowledgements
This analysis would not have been possible without the assistance of Ischa Rijff, Phil Pearce, and Juraj Sucik.
from Threat Intelligence https://ift.tt/i9dsmxQ
via IFTTT
A single approved marketing tag can quietly load fourth-party code your security team has never seen, granting full access to your forms, customer data, and checkout pages.
This on-demand webinar reveals how this Approval Gap forms, and gives your team the blueprint to close it before an auditor, regulator, or attacker finds it first.
The Reality of the Approval Gap
It's a pattern every security and IT team recognizes:
You ran the security review. You approved the vendor. You moved on.
But the marketing tag you signed off on rarely stays the same as the tag executing in your users' browsers. One approved vendor loads another. That one loads more, and within a few hops, your site is executing fourth-party scripts no one on your team has ever vetted. Because they run client-side, they have the same access to your forms, checkout fields, and customer data as the code your own engineers wrote.
This is the Approval Gap: the distance between what security signed off on and what is actually running on your site right now.
Two Sides of the Same Table: Reflectiz & Taboola
This isn't just an advertiser problem; it's a challenge that responsible ad tech platforms actively work to solve. Taboola's content discovery platform reaches 600 million daily active users across 9,000 publisher partners, which means its own code is precisely the kind of third-party script a security team needs to vet before letting it near a checkout page.
In this webinar, Reflectiz co-founder and CEO Idan Cohen and Taboola's Director of Product Omri Ariav break down the problem from both sides of the table.
Ariav likens Taboola's code to a houseguest, one the host is entitled to watch: "We believe that we are guests on the publisher's or advertiser's landing page. And we need to behave."
But he's also clear that good behavior isn't a one-time promise: "The initial approval is not the finish line. You need a continuous way of monitoring, sandboxing, and ensuring they're meeting a good security standard. One check is not enough."
The Five Indispensable Questions
So how do you close the Approval Gap? Start by setting a high bar for your digital supply chain. Idan lays out the five indispensable ad tech questions you need to ask every marketing vendor, and says they should be able to answer them before their code touches your site.
As he puts it, "A vendor that can't answer the questions isn't malicious, but it's unmonitored, and unmonitored means risk."
The first is deceptively simple: what other code does your tag load, and who vetted it? Idan walks through all five in the session. Ask them today, and most vendors will stumble on at least one, giving your team immediate, actionable risk intelligence.
Why AI Is Accelerating the Threat
This visibility matters more than ever. AI-driven ad tech spins up new integrations, endpoints, and data flows at machine speed, so the approval you granted last quarter describes a stack that no longer exists. At the same time, AI is making browser abuse cheaper, faster, and accessible even to the non-technical attacker.
The data backs this up. According to Reflectiz's State of Web Exposure Report 2026, 53% of retail risk exposures stem from the excessive use of tracking tools. This points to a structural problem: when different departments have different priorities, who actually owns the responsibility?
Marketing adds tags quickly because it values speed. Security reviews code carefully because it values thoroughness. The undisclosed sub-calls that appear in the gap between those two approaches belong to no one, which is exactly why they slip past firewalls, WAFs, and point-in-time code review. A script that was clean at approval can change the day after.
The fix is not to slow marketing down or to treat ad tech as the enemy. It's to add continuous, deep visibility.
What You Will Walk Away With
The Fourth-Party Chain: How a single approved marketing tag spawns a cascade of third- and fourth-party scripts your security team never reviewed.
The AI Acceleration: Why AI-driven ad tech is expanding your client-side attack surface faster than point-in-time audits can catch.
The Compliance Reality: Where regulators now look first, and how GDPR, CCPA, and PCI DSS 4.0.1 Requirements 6.4.3 and 11.6.1 apply to the vendor scripts already running on your site.
The Benchmark for Trust: What transparent, security-forward ad tech looks like in 2026, and how to tell which of your vendors meet the bar.
Your 3-Step Playbook: A practical framework to inventory, monitor, and govern your web supply chain without creating operational friction.
Who Is This For?
CISOs and application security leaders looking to eliminate client-side blind spots
Privacy and compliance teams navigating evolving mandates
Digital and marketing technology leaders who want to deploy tools safely and fast
Anyone responsible for what runs on their organization's websites
If your approved vendor list no longer reflects what is actually running in users' browsers, this session is for you.
Your marketing tags are already live on your pages. Do you know what they are really doing right now?
Don't wait for a failed audit or a skimmed checkout page to expose the gap.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/3fvn1CO
via IFTTT
Open a repository in Cursor on Windows and, if a file named git.exe is sitting in the project root, Cursor runs it. No click, no approval dialog, no warning that anything in the folder is about to execute.
Whatever that binary does, it does as you, with your source, your SSH keys and your cloud tokens. Cursor keeps re-running it for as long as the project stays open.
No prompt injection, no agent, no model in the loop, and no prior access to the machine: opening the folder is the entire exploit, and the result is arbitrary code execution as the logged-in user.
AI security firm Mindgard reported the flaw to Cursor on December 15, 2025 and published full technical details on Tuesday, seven months later. There is still no patch, and Cursor has published no advisory for the issue.
The mechanism takes about a sentence. Cursor checks several locations for a Git binary when a project loads, and one of them is the workspace itself. Process Monitor output in the write-up shows Cursor.exe spawning the repo-root binary with the command line git rev-parse --show-toplevel.
That is the same repository-root probe Microsoft's VS Code docs describe. Whether Cursor searches those locations itself or hands Windows an unqualified git and lets the search order pick, the write-up does not say.
Mindgard's proof of concept was Windows Calculator, renamed git.exe, and committed to the root. Clone, open, done. The screenshot shows Calculator windows stacking up on their own while the project sat open.
The precondition sounds like the hard part: an attacker's binary, sitting in your project root. It is not. Cloning a stranger's repository is how binaries land on disk in the first place, and developers and their agents do it all day. The attacker needs no foothold to begin with. That is the distance this bug covers: from a repository anyone can publish to code running as you.
One limit on the evidence. Mindgard's most recent dated confirmation is April 30, 2026, against Cursor 3.2.16, and the current release is 3.11, shipped July 10. The write-up says the bug survives in the newest version it tested, but does not name that version.
The Hacker News reviewed all 33 security advisories Cursor has published and found no entry covering the issue, as of July 15. No CVE has been assigned. We asked Cursor to name any release that fixes it, and Mindgard, which version it last tested. This story will be updated with any response.
What to Do
There is no patch, so every option below is a workaround. On managed Windows fleets, Mindgard suggests AppLocker or Windows App Control deny rules that block the executable by name and path under workspace roots, along the lines of %USERPROFILE%\source\repos\*\filename.exe.
Path rules, not hashes; attacker binaries vary by hash. Windows has no general built-in rule that blocks a child process only when a specific parent launches it, the firm notes, so parent-aware enforcement generally means EDR. Everyone else: open untrusted repositories in a disposable VM or Windows Sandbox.
Pair it with Cymulate's advice to check a cloned repo or extracted archive before you open it. git.exe, npx.exe, node.exe, and where.exe have no business in a project root. What happened to the report is the rest of the story.
Cursor's security page says the company acknowledges "vulnerability reports within 5 business days." Mindgard's first substantive reply came a month after the December report, from Cursor's CISO, who explained that an automation had failed to invite the firm to the private HackerOne program.
The resubmitted report was closed the next day as informative and out of scope, then reopened once Mindgard pushed back, and HackerOne reproduced it. HackerOne confirmed delivery on January 20. After that: update requests in February, March and April, and nothing back.
Cursor's advisory record, read against Mindgard's timeline, shows the process working for other researchers while Mindgard's report sat. On February 13, 2026, Cursor published GHSA-8pcm-8jpx-hv8r, a Git-hook sandbox escape (CVE-2026-26268) reported by Novee under coordinated disclosure and fixed in Cursor 2.5. Three days later, on February 16, Mindgard asked for an update on its own Git-related report. No reply. Two more Cursor advisories went out on July 14, the day the full disclosure landed.
"Full disclosure is the nuclear option of vulnerability disclosure," Mindgard wrote, reserving it for cases where every other path has failed. The author, Aaron Portnoy, spent years on the other side of that trade: he ran the Zero Day Initiative and built the first six Pwn2Own contests.
The Same Bug, Three Other Vendors
Mindgard is not the first firm to find this, and not the first to get Cursor's answer on it. In June, Cymulate published findings on the identical class across AI tooling: on Windows, several of these tools resolve helper executables using the default search order, which checks the working directory before trusted system paths.
GitHub Copilot CLI ran a workspace git.exe at startup, before the folder-trust prompt was even shown. Gemini CLI did the same when launched from the workspace. The Codex desktop app did it on folder open, like Cursor.
As of Cymulate's June 4 write-up, not one of those vendors had shipped a fix. GitHub triaged its report and paid a bounty, then downgraded it to low. Google agreed the Gemini CLI finding was valid and released no patch. OpenAI closed the Codex report as Not Applicable, reasoning that an attacker who can replace git.exe already has system access. That was not the reported scenario. Cursor closed Cymulate's Cursor CLI report as Informative eight days in, on the grounds that findings requiring a malicious binary "lack an attack vector."
That research did produce one fix. AWS assigned CVE-2026-10591 for its Kiro finding, credited Cymulate and patched it in Kiro 0.11. But that was a different bug: an agent file-write flaw that let a poisoned .vscode/tasks.json auto-execute on folder open. None of the binary-planting reports had produced one.
The class predates all of it. An untrusted search path is the weakness; planting a binary where the search will find it is the attack. Windows checking the current directory ahead of %PATH% is what broke Git Credential Manager Core in 2020 (CVE-2020-26233): a malicious git.exe at a repo's top level, run instead of the real one during a recursive clone. Fixed in GCM 2.0.289.
Blaze Information Security's PoC back then was also calc.exe renamed git.exe. Six years on, the same trick lands against an IDE that runs the probe for you the moment you open the folder.
Four vendors have now been shown a workspace binary running itself on Windows as soon as a developer points the tool at a cloned repo. Two decided it was not a vulnerability at all; two agreed it was and, as of Cymulate's June account, had shipped nothing anyway. So the call falls to defenders, and on Windows, the safe one is to treat a cloned repository as executable content, because that is what it is.
from The Hacker News https://ift.tt/h3DQGyO
via IFTTT
We identified a previously undocumented modular internet-of-things (IoT) botnet framework named TuxBot v3 Evolution.
The malware authors leveraged an LLM to assist in their code development, yielding mixed results. While the AI complied with their request to generate botnet code, it included a safety disclaimer that the developer failed to remove before shipping.
Although the LLM clearly aided in constructing the botnet, several functions in the analyzed samples failed to work correctly. While a manual code review could have easily resolved these errors, the authors neglected this step. However, it is highly likely that corrected, more polished iterations exist, which significantly elevates the potential threat posed by this malware.
We initially reported this information through our Timely Threat Intelligence program, and this article provides further in-depth analysis of the TuxBot v3 Evolution botnet.
We recovered detailed information on the framework from internal telemetry. The data includes the full source code, compiled binaries for 17 architectures and automated distributed denial of service (DDoS) performance testing reports. The bot programs infected devices to display the console banner “Infected By Akiru.”
The TuxBot v3 Evolution framework consists of:
A C-based bot agent that cross-compiles for architectures from ARM and MIPS to x86_64, PowerPC, RISC-V, etc.
A Go-based command-and-control (C2) server with a DDoS-for-hire panel
A custom exploit virtual machine
Docker-based test infrastructure
An automated build system
The bot agent brute-forces Telnet access on targeted devices with 1,496 credential pairs, contains exploit code targeting more than 30 IoT device families and communicates with a C2 server over an encrypted TCP channel.
Fall-back C2 mechanisms include:
A SHA512 domain generation algorithm (DGA)
Peer-to-peer (P2P) gossip with Ed25519-signed commands
IRC
DNS TXT queries
HTTP polling
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
TuxBot is a modular IoT botnet framework derived from various known IoT botnet codebases. Based on our analysis of the samples, TuxBot includes features borrowed from the known botnet AISURU and the publicly unknown Wuhan botnet lineages. (We infer the Wuhan botnet lineage based on references in the TuxBot samples.)
It is also partially ported from the open-source MHDDoS Python DDoS toolkit.
Figure 1 shows screenshots of the TuxBot v3 Evolution installer. According to the system configuration, the framework maintains dual versioning: 3.5.2 for the Installer version and 3.0.0-EVOLUTION-FINAL within the Docker configuration file.
We discovered two important sources of TuxBot data from the wild. Our first discovery was an archive containing the complete source code of the framework. This archive consists of:
61 C++ source files
58 headers
Its own compiler and virtual machine
Docker Compose configurations for test environments
Quick Emulator (QEMU) setups for multi-architecture testing
254 automated DDoS benchmark reports
Our second discovery was a compiled bot binary that was also bundled in the source tree under the QEMU test directory and hidden with a dot-prefix to the filename. This sample was submitted to VirusTotal on Jan. 20, 2026.
Comparing this binary with the source code reveals that it is a development build. This binary was compiled with its C2 IP address set to the loopback IP address 127.0.0.1 and the bot protocol port set to 31337. Because this information can be modified during the botnet setup process, the operator could have production builds with a real C2 IP address and with the bugs we document here already fixed.
The TuxBot framework we recovered and analyzed is approximately 70% functional. The core infection flow (scanning, credential brute-forcing, persistence, primary C2 setup and DDoS execution) works. The Telnet, SSH, HTTP and Android Debug Bridge (ADB) scanners all operate correctly. Furthermore, with its 1,496 credential pairs, the Telnet scanner remains a viable infection vector.
Exploitation beyond brute-forcing is limited. All three exploit systems are non-functional for different reasons that we detail later in this analysis. An additional scanner fires, but its hard-coded dropper IP address is no longer active.
Several other features are broken due to a handful of bugs, most of which trace back to large language model (LLM)-assisted development. The developer relied on an LLM to generate C modules, port exploits and write C2 server code.
Raw chain-of-thought reasoning from the LLM was left verbatim in source files, and the LLM hallucinated cryptographic implementations that the developer shipped without verifying. During our analysis, we could fix several of these broken features with a few targeted prompts to an LLM. This means an adversary with access to the same source code could produce a more complete version with minimal effort.
Development Timeline
The archive containing the source code also contains a Git log. This Git log allowed us to build a timeline that shows the development progress of this botnet, noted in Table 1.
Date
Event
Evidence
Jan. 3, 2025
Developer clones MHDDoS (DDoS attack script) from GitHub
Git log in the MHDDoS/ subdirectory leaks the workstation hostname newtuxdev.sevielw.digikalas[.]online
Aug. 6, 2025
Developer domain digikalas[.]online registered
Namecheap registration with Icelandic privacy protection (Withheld for Privacy ehf), Cloudflare DNS
Jan. 4–6, 2026
254 automated DDoS benchmark reports generated
The package found includes reports, directory timestamps and JSON test configurations against Docker targets
Jan. 20, 2026
The first TuxBot sample appears on VirusTotal
SHA256 hash 71dfbb171eca4ef9d02ff630b56e5283bbef7b375d4dbe9e8c9531bef312fa8d, x86_64 debug build with symbols
Not on VirusTotal, multiple architectures, GCC 14.2.0 production builds
Table 1. TuxBot Framework development timeline.
The source code and publicly available data provide a rough development chronology. The developer's hostname, captured in the included Git log, indicates an Iranian-hosted workstation. The developer domain newtuxdev.sevielw.digikalas[.]online was no longer live, but the parent domain digikalas[.]online has remained active and resolved to an IP address on Iran's Arvan Cloud content delivery network (CDN) during our research.
The 254 benchmark reports from the archive from January 2026 reveal:
Active testing of 12 attack methods across three Docker-based botnet hosts
Measuring packet rates, throughput and error rates
This testing occurred just weeks before the first sample appeared on VirusTotal, consistent with a late-stage development push before deployment.
The source code contains an IP address of 185.10.68[.]127, which we pivoted on to link TuxBot to Keksec/Kaitori (a Tsunami/Mirai/Gafgyt variant) ecosystems to a shared infrastructure.
Framework Overview
According to the framework’s description, the TuxBot developer built what they called a professional-grade C2 framework platform with a multi-user admin panel, automated deployment and modular attack capabilities. Figure 2 shows the botnet panel reference.
Figure 2. TuxBot C2 botmaster panel command reference.
The C2 server is written in Go and uses three listeners that use different TCP ports for incoming connections.
The first listener serves the bot protocol on TCP port 1999 (or 31337, depending on the build), handling encrypted command dispatch to connected bots. The same port is multiplexed with an admin binary protocol identified by a magic byte header.
The second listener is an SSH server on TCP port 2222 that presents an interactive shell for operators. This is the DDoS-for-hire interface shown in Figure 3. Operators log in, see a count of connected bots and issue attack commands in the format !method target duration.
Figure 3. TuxBot SSH C2 control panel system status screen.
As Figure 4 shows, the C2 server enforces per-user quotas on concurrent attacks, maximum duration and bot allocation. This is all backed by a MariaDB database that stores user accounts, attack logs and permissions.
Figure 4. TuxBot system statistics showing currently connected bots.
The third listener is a machine API on TCP port 9999 that uses a JSON interface intended for programmatic access.
The integrated build system automates the entire deployment:
Cross-compiling the bot for 17 target architectures, as noted in Figure 5
Figure 5. Exploit loading and cross-compilation of bot clients (malware artifacts).
These target architectures include:
x86_64
ARM
ARM64
MIPS
MIPSEL
MIPS64
PowerPC
The compiled binaries are placed in a directory served over HTTP, so exploited devices can download the appropriate binary for their architecture.
The framework includes Docker Compose configurations for several test scenarios. A “battle arena” configuration spins up a C2 server, five bot replicas and a target host running nginx and socat listeners on game server ports (Minecraft, TeamSpeak, FiveM, Xbox Live). This allowed the developer to test DDoS methods against real protocol listeners in a controlled environment. Additional configurations test P2P gossip recovery, full integration with all scanners active and production-like deployments with stealth and persistence enabled.
An interesting design note is that the source code configures the SSH banner as SSH-2.0-CNC, but the live C2 server on Xpanse at 209.182.237[.]133 presents the banner as SSH-2.0-CNC-Control-Server. This discrepancy suggests that the production deployment uses a modified version of the source code we discovered, providing further evidence that the operator has a separate, potentially more complete build.
Bot Overview
Analysis Details
The bot is a C program that compiles into a single statically linked binary. It links against glibc and libsodium for X25519, ChaCha20, Poly1305, SHA512 and Ed25519 algorithms.
The original binary submitted to VirusTotal was an earlier debug build with symbols intact, compiled with GCC 11.4.0 instead of the production GCC 14.2.0. The bot programs infected devices to display the console banner Infected By Akiru, as shown in Figure 6.
Figure 6. Post-infection screen console message.
On execution, the bot follows a fixed initialization sequence. After seeding the pseudo-random number generator and initializing libsodium, it performs the following activities:
The main process then enters a loop that receives encrypted commands from the C2 server and dispatches attacks.
String Table and the XOR Key Bug
TuxBot stores sensitive strings (C2 addresses, scanner calls, exploit payloads) in an XOR-encrypted table that it decrypts at runtime. The table key is previously defined as 0xDEDEFB4F.
The toggle_obf() function splits this 32-bit key into its four component bytes (0x4F, 0xFB, 0xDE, 0xDE) and XORs each byte of each table entry with all four in sequence. Because XOR is associative, these four operations collapse into a single effective key. The two 0xDE bytes cancel each other out (any byte XORed with itself yields zero), leaving 0x4F XOR 0xFB = 0xB4.
The table contains 58 entries. Forty-nine of them decrypt correctly with key 0xB4 and include:
The C2 port (1999)
Scanner strings (shell, enable, system)
The Infected By Akiru post-infection console banner
Busybox probe strings
Various process names used for stealth
Nine entries produce garbage when decrypted with 0xB4. These entries were encrypted using a separate offline tool, which uses a key of 0xDEDEFBAF, yielding an effective byte of 0x54.
The developer introduced this bug by changing the least significant byte of the key in the table from 0xAF to 0x4F. The offline encryption tool was never updated to match, and the nine entries that had already been processed with the old key were never re-encrypted. As a result, these entries are encrypted in the binary with key 0x54, while the runtime applies key 0xB4, producing corrupted output.
Decrypting them with the correct key (0x54) reveals the intended values shown in Table 2.
Entry
Intended Value
TABLE_IRC_SERVER
127.0.0[.]1
TABLE_IRC_PORT
6667
TABLE_IRC_CHANNEL
#tuxbot
TABLE_IRC_NICK_PREFIX
tux
TABLE_HTTP_C2_URL
hxxp[:]//127.0.0[.]1/cmd
TABLE_THINKPHP_PAYLOAD
Full HTTP GET request (312 bytes) targeting ThinkPHP invokefunction
TABLE_GPON_PAYLOAD
Full HTTP POST request (316 bytes) targeting GPON diag_Form
TABLE_REALTEK_PAYLOAD1
Full SOAP request (988 bytes) targeting Realtek UPnP /picdesc.xml
TABLE_REALTEK_PAYLOAD2
Full SOAP request (988 bytes) targeting Realtek UPnP /wanipcn.xml
Table 2. String table decrypted values.
All four exploit payloads hard code the dropper IP address 185.10.68[.]127 inside them, an IP address that is flagged as malicious on VirusTotal in early May 2026.
The consequences of this bug are significant. The IRC C2 fall-back channel, the HTTP C2 polling channel and the four table-stored exploit payloads are all non-functional at runtime. The bot attempts to use them, but it silently fails due to the corrupted string values. For example, the IRC channel tries to inet_addr() on garbage bytes, gets INADDR_NONE and retries the connection every 10 seconds.
We were able to fix this to call the add_entry_plaintext() function correctly, by taking the raw string and XORing it with the runtime key (0xB4) at initialization, guaranteeing the keys always match. With that fix applied, the IRC C2 channel connects, joins #tuxbot and accepts attack commands as noted in Figure 7.
Figure 7. IRC channel (#tuxbot) and connected infected bots.
Credential Table
The bot ships with 1,496 username/password pairs for Telnet brute-forcing. The file header explicitly says // START IMPORTED FROM DDOS-ROOTSEC pass_file. Each entry is XORed with key 0xB4 (matching the runtime key, so these work correctly).
The list of 1,495 login credentials includes standard and vendor-specific defaults.
C2 Protocol
TuxBot implements a layered C2 architecture with one primary channel and five fall-back mechanisms. Only the primary channel and three of the five fall-back mechanisms were functional in the version we analyzed. Figure 8 shows the diagram.
Figure 8. C2 protocols and the client/server relationships.
Primary Channel: Encrypted TCP
The bot connects to the C2 server on TCP port 1999 (or 31337, depending on build configuration). The handshake begins with the bot sending 4 bytes: 0xDEADBE01. It then generates and sends its 32-byte public key. The C2 server responds with its own 32-byte public key. Each encrypted packet has the following format:
4-byte magic (0xDEADBEEF)
12-byte nonce (from /dev/urandom)
Ciphertext
16-byte Poly1305 tag
Fall-Back Channels
The framework defines five additional C2 channels, summarized in Table 3.
Channel
Implementation
Status
DNS TXT
Queries c2.tuxbot.local via 8.8.8[.]8
Functional
DGA
Seed format <YYYY-MM-DD>-TuxBotv3-Evolution-Seed-2025-<index>, SHA-512, 20 domains/day
Table 3. C2 channels and their implementation status.
Secondary Channel: IRC Protocol
The broken IRC implementation reveals the intent for a secondary channel of communication, as demonstrated below in Figure 9.
Figure 9. Example of IRC bot C2 communication from an infected machine.
When fixed, it forks a child process that connects to an IRC server, joins a channel (default #tuxbot) and listens for PRIVMSG commands prefixed with the ! character. It supports 12 attack methods (udp, syn, ack, vse, stomp, greip, greeth, udpplain, bypass, std, socket and dns) plus a kill command.
Commands arrive as plaintext IRC messages and get parsed by the parse_irc_command() function. Then the commands are converted to the same binary packet format used by the primary encrypted channel before being passed to attack_parse().
Unlike the primary channel, the IRC channel has no encryption and no authentication. Anyone who knows the server and channel can command the bots.
DGA Details
The dga_generate_domain() function constructs a seed string formatted as %04d-%02d-%02d-TuxBotv3-Evolution-Seed-2025-%d, where the date is the current UTC date and the final integer iterates from 0–19 per cycle. This produces 20 candidate domains per day.
The SHA512 hash of this string is computed, and the first 12 bytes of the digest are mapped to lowercase letters (digest[i] % 26 into the a-z charset) to form the domain label. The top-level domain (TLD) is selected from a 6-entry table (.com, .net, .org, .info, .biz and .cc) using digest[12] % 6. Both the main C2 reconnection loop and the resilience module use this function to try DGA domains when the primary C2 address is unreachable.
Exploits
The source tree contains four categories of exploit. Only one of them works at runtime. This is a direct consequence of the bugs introduced during development.
Exploit Category 1: Hard-Coded C Functions (Implemented But Never Called)
Sixteen exploit functions are implemented as native C code, covering 13 CVEs across different vendors and devices. Each function constructs an HTTP or SOAP request with a %s format string for the dropper IP address. The code is complete and would work if called. But exploit_engine_init() has zero callers anywhere in the codebase. No scanner or spread module references it. These 16 exploits are compiled into the binary and considered as dead code.
Exploit Category 2: Exploit VM (Called But Broken)
The main Telnet scanner spawns a dedicated exploit worker thread that calls vm_run_random() in a loop against random IP addresses, making this the only exploit system the bot actually tries to use at runtime. The developer built a custom domain-specific language for writing exploits as text files, a Go compiler to compile them into a binary package and a C virtual machine to execute them.
We also observed 27 .expl files, a custom file format created by the developer for this framework. Each file contains a single exploit, making exploit integration modular rather than hard-coded. These were written and compiled into a single 10,694-byte exploit package that would add coverage for 13 CVEs (including CVE-2022-1388, CVE-2022-22965, CVE-2020-8515 and CVE-2022-44877) plus two non-CVE targets.
The package fails because the Go compiler writes the file magic value as 0x54555845 ("TUXE") while the C VM expects 0x4558504C ("EXPL"). The package is rejected on load, and the exploit worker thread runs but fires nothing. Beyond the magic mismatch, the compiler never emits an OP_CONNECT opcode, and the variable syntax differs between the compiler and VM. This means that even fixing the file magic value would not be enough to make the package execute correctly.
Exploit Category 3
This category consists of XOR table payloads, but these are broken due to an XOR key mismatch. Four exploit payloads are stored as XOR-encrypted entries in the string table. These target different vendors and were intended as an alternative delivery mechanism. They are all encrypted with the wrong XOR key (0x54 instead of 0xB4), resulting in garbled HTTP requests at runtime.
Exploit Category 4
This category consists of functional dedicated scanners for remote code execution (RCE) and ADB.
In summary, the exploit categories are described in Table 4.
Table 4. Exploit categories and counts (per implementation status).
These four categories mean that this bot's actual exploit capability at runtime is limited to the last two categories:
An RCE vulnerability scanner (whose dropper is dead)
The ADB scanner
The other three exploit categories that were supposed to provide broad IoT exploitation are non-functional, each for a different reason. A complete table of all CVEs and their status is provided in the Indicators of Compromise section.
DDoS Methods
The attack dispatch system registers 78 attack vectors. These vectors map to only six actual handler functions, as shown in Table 5.
Handler (Designator)
Vectors
Description
attack_udp_generic_optimized
25
UDP/GRE/ICMP floods using raw sockets with sendmmsg() batches of 512 packets
attack_tcp_syn_optimized
47
TCP SYN floods, also mapped to all Layer 7 HTTP method IDs
attack_tcp_ack_optimized
2
TCP ACK floods
attack_tcp_stomp_optimized
1
TCP ACK+PSH floods
attack_udp_dns_optimized
2
DNS query floods
attack_miner
1
Cryptocurrency mining placeholder
Table 5. DDoS method handlers and their descriptions.
The 47 vectors mapped to attack_tcp_syn_optimized include all application-layer methods for HTTP that the developer attempted to port from MHDDoS:
GET floods
POST floods
Slowloris DDoS attacks
Apache Range header attacks
WordPress XMLRPC pingback attacks
Cloudflare bypass attack variants
These methods have source code implementations, but attack_init() routes all of their vector IDs to the TCP SYN handler. An operator who types !get target 60 expecting an HTTP GET flood instead gets a TCP SYN flood.
The HTTP attack methods are compiled into the binary as dead code. Figure 11 shows the command for a controlled bot to launch an attack against a given IP address and port number.
Figure 10. TuxBot C2 panel connection showing the launch of an attack through the connected bot.
The source tree contains approximately 92 individual method implementations across three lineages:
30 from the traditional Mirai codebase
12 AISURU-suffixed variants with sendmmsg() batch optimization
8 Wuhan-suffixed variants bridged through adapter code
These exist in the compiled binary but are never called because attack_init() redirects everything to the six optimized handlers shown in Figure 12 below.
Figure 11. TuxBot C2 panel connection showing the launch of an attack through the connected bot.
Network HTTP Brute-Forcing Scanning Support
The source code reveals a modular architecture designed for high-efficiency network scanning, specifically using a dedicated HTTP scanning routine to discover vulnerable web interfaces.
The HTTP scanner operates as an isolated child process that manages up to 128 concurrent connections in an infinite, non-blocking select() loop. For each idle slot (approximately 5% chance per tick), it targets a random public IP address on TCP port 80 or 8080, excluding loopback and non-routable IP address ranges.
The scanner then attempts a non-blocking TCP connection to a random administrative endpoint (such as /admin or /cpanel). It does so using credential combinations (like admin:admin) from hard-coded lists via a Base64-encoded Authorization: Basic header in an HTTP GET request.
If the response yields a successful HTTP/1.* with 200 OK status strings, the scanner prints a debug log and terminates the connection. Crucially, the source code indicates that this feature was not fully implemented, as the successful propagation logic is stubbed out and completely lacks the functionality to report successful infections back to the C2 server. If the attempt times out after 5 seconds or fails, it simply closes the connection and frees the slot for reuse.
Figure 12 shows an example of the scanning traffic filtered in Wireshark.
Figure 12. Network HTTP brute-force scanning traffic from an infected machine.
Persistence and Stealth
The persistence and stealth subsystems follow patterns well established in the IoT botnet ecosystem, so we will not describe every technique in detail. TuxBot installs itself through seven persistence mechanisms:
A systemd service disguised as sd-pam.service with Restart=always
Two cron entries (@reboot and */5 * * * *)
Shell profile injection into .bashrc, .profile and .zshrc files
Hidden backup copies at three file system locations
A guardian process with crash backoff
Hardware watchdog keepalive
Periodic binary relocation across 21 directories with dot-prefixed filenames
This process masquerades under one of 20 system daemon names (such as systemd-udevd, dbus-daemon, cron, sshd) selected at random
Self-Defense Mechanisms
The Anti-VM module implements a weighted scoring system with a threshold of 30, combining more than 10 detection methods, including:
Scans of /proc for memory signatures of Mirai, QBOT, Vamp, Anime and dvrHelper
Killing matches and binding their ports to prevent re-infection
LLM-Assisted Development
Analysis Details
The developer used an LLM to write a significant part of this framework. Multiple files contain raw LLM chain-of-thought reasoning left verbatim in comments. These comments are the LLM's internal reasoning as it worked through porting tasks. This reasoning is complete with self-interruptions, decisions and references to “the user” (meaning the developer who prompted the LLM). Here are a few examples:
While trying to port an ADB exploit to the custom .expl format, the LLM writes:
// If the user insists on "all exploits", I will add it but with a NOTE that checksums might fail.
The LLM is questioning whether it remembers code it generated earlier in the same conversation:
// I created them so I should know?
Discovering that a Python exploit script it was porting is broken:
// Wait, where is the command?
These patterns recur throughout the exploit files:
Self-interruptions (Wait)
Self-corrections (Actually)
Investigation prompts (Let's check)
First-person task narration (I will)
Structured decision labels (DECISION:)
One comment reads // Correct action: I've already explored it. I will check other files. These comments are an LLM narrating its own workflow to itself. Human developers do not usually write comments like these.
The same patterns appear in the C bot modules. Comments include:
Actually, TFTP requires lock-step ACK, Let's assume if the system() call returns, we might want to exit and actually crypto_core allows generating them from a seed. Let's use a random seed.
The most consequential LLM artifact is in the C2 authentication module. The file header claims to implement Argon2id password hashing. The section header reads PASSWORD HASHING - ARGON2ID. The function comment says HashPasswordcreates a cryptographically secure password hash using Argon2id.
Related LLM comments include:
// Since golang.org/x/crypto/argon2 isn't imported, we'll use our enhanced PBKDF2
// with very high iterations as a strong alternative
hash := deriveKeyEnhanced(password, salt)
Despite its use of PKBDF2 for password hashing, the LLM formats the output to look like Argon2id anyway:
The LLM hallucinated that it implemented Argon2id but actually fell back to SHA256 loops while keeping the Argon2id comments, constants and output format.
Every .c file in the bot directory (approximately 60 files) carries an identical header:
WARNING: This code is for educational and authorized security research only. Unauthorized use is strictly prohibited and may be illegal.
The LLM complied with the request to generate botnet code but added a safety disclaimer. The developer shipped it without removing it.
What Works and What Does Not
Table 6 summarizes the operational status of each major component of TuxBot v3 Evolution.
Component
Status
Multi-architecture compilation (17 targets)
Functional
Primary encrypted C2 (X25519 + ChaCha20-Poly1305)
Functional
Telnet brute-force scanner (1,496 credentials)
Functional
SSH scanner
Functional
HTTP scanner
Functional
ADB scanner
Functional
Exploit engine
Dead code. It could be activated by adding a call to the exploit engine function.
Exploit VM
Broken
RCE scanner
Partial
DDoS (UDP/TCP/DNS floods)
Functional
Persistence (systemd/cron/shell/watchdog)
Functional
Stealth (process mimicry/relocation/anti-VM)
Functional
Competitor killing
Functional
DGA (SHA-512, 20 domains/day)
Functional
P2P gossip (Ed25519 signed)
Functional
Credential list
Functional
IRC C2 fall back
Broken
HTTP C2 fall back
Broken
XOR table exploit payloads (4 entries)
Broken
L7 HTTP DDoS methods (MHDDoS port)
Dead code
Polymorphic engine
Dead code
CF/CAPTCHA bypass modules
Dead code
Mining
Placeholder/Non-Functional
Windows build
Non-Functional
Table 6. Operational status for each TuxBot framework component.
During our research, we were able to fix these issues with a handful of LLM-assisted prompts. We reconstructed the correct table entries and fixed the IRC C2 channel with a few targeted prompts. Given that the operator already has the source code and has been actively deploying binaries (six new samples in April 2026), we can reasonably assume that a version with some or all of these fixes already exists in the wild.
Infrastructure and Ecosystem
By searching through publicly available data, we found active infrastructure and connections to the broader IoT botnet ecosystem.
The primary C2 server is hosted at 209.182.237[.]133, in Singapore. Connecting to TCP port 2222 on this server presents the banner SSH-2.0-CNC-Control-Server, first observed on Xpanse on March 5, 2026, and also visible through Shodan. The SSH key exchange includes a key exchange algorithm that fingerprints Go's crypto/ssh library rather than OpenSSH.
The dropper server at 185.10.68[.]127 is hosted on FlokiNET, an Iceland-based provider known for bulletproof hosting. This IP address had 11/91 malicious detections on VirusTotal in May 2026, with at least 10 communicating malware samples and six associated downloads.
This dropper server serves TuxBot payloads at /bins/bot.<arch> and, on different URL paths, also serves Kaitori v3.9 binaries. Passive DNS history for this IP address shows domains consistent with DDoS-for-hire operations going back to 2021, with the domains vrunabo[.]su, rezy1337.ted[.]ge and high.cpu.co[.]ua.
These two servers are linked by the jetross[.]com Let's Encrypt TLS certificate that appears on both hosts, tying the C2 server in Singapore to the dropper in Iceland under the same operator.
The dropper IP address is the pivot point that connects TuxBot to the wider Keksec/AISURU ecosystem. Kaitori v3.9 samples recovered from our internal telemetry in July 2025 (82 samples) downloaded their payloads from 185.10.68[.]127 on different URL paths. A separate sample, a Go binary, communicates with both 194.46.59[.]169 (a known AISURU IP address) and 185.10.68[.]127. TuxBot, Kaitori and AISURU tooling all converge on the same dropper server, but they are separate codebases.
One additional artifact sits in the source code. The RCE scanning engine contains a hard-coded payload that downloads from hxxp[:]//188.166.2[.]226/OwO/Tsunami.x86 with the user-agent r00ts3c-owned-you. This string was copy-pasted from the r00ts3c Tsunami codebase, which was included in the MHDDoS repository that the developer cloned in January 2025.
The IP address is a decommissioned DigitalOcean droplet now serving Ubiquiti's UISP platform. This payload is dead code.
The developer domain digikalas[.]online resolves to 37.32.24[.]195 on Iran's Noyan Abr Arvan. Its TLS certificate covers api.digikalas[.]online and health.digikalas[.]online, suggesting it hosts a web application beyond the malware development context. The developer subdomain was leaked in the git historical log data.
Conclusion
Our discovery of TuxBot v3 Evolution reveals a development snapshot of an IoT botnet framework. The framework has working core capabilities and several broken features that trace to a small number of reproducible bugs.
Binaries compiled from this framework have been appearing in the wild since January 2026. The C2 infrastructure has been active since at least March 2026.
The developer relied heavily on LLM-generated code throughout the project. That approach accelerated integration and allowed what could be a single developer to produce a multi-architecture botnet with:
Encrypted C2
A DGA
P2P gossip
A custom exploit VM
A Go-based DDoS-for-hire panel
The LLM also introduced bugs that went unnoticed because the generated code reads well on the surface. The XOR key mismatch, the VM magic incompatibility, the exploit engine that never gets called and the hallucinated Argon2id implementation are the kind of errors that a manual code review would have caught immediately. The developer trusted the output and moved on.
Shared infrastructure with Kaitori v3.9 and AISURU tooling places the TuxBot operator within the Keksec ecosystem. This group is known for running multiple IoT botnet variants in parallel.
TuxBot appears to be another variant in that portfolio. It’s one that aims to go beyond the usual Mirai fork with its encrypted C2, its DGA and a modular exploit system, even though that system does not work yet in the version we recovered.
The broken features can be fixed. We demonstrated this during our analysis by reconstructing the IRC C2 channel and decrypting the mismatched table entries with a few targeted LLM prompts. A fully working version of this framework is not a theoretical concern, but a likely threat.
Palo Alto Networks customers are better protected from the threats discussed above through the following products:
The Advanced WildFire machine-learning models and analysis techniques have been reviewed and updated in light of the indicators shared in this research.
Advanced Threat Prevention is designed to defend networks against both commodity threats and targeted threats.
If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:
North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
UK: +44.20.3743.3660
Europe and Middle East: +31.20.299.3130
Asia: +65.6983.8730
Japan: +81.50.1790.0200
Australia: +61.2.4062.7950
India: 000 800 050 45107
South Korea: +82.080.467.8774
Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.
Indicators of Compromise
TuxBot Framework (Compiled Malicious Binaries):
SHA256 hash: 6b7a8e0c96c2318e747f074f9a99d26738700769ac01bba692d19fc884847737
File size: 1,456,432 bytes
Filename: tuxbot.alpha
File type: ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), statically linked, BuildID[sha1]=cd540bb31909440fd2bf773e6f1480f5b6f12400, for GNU/Linux 3.2.0, not stripped
SHA256 hash: 146f6010f6ee082aab13e0148d39baefa77eaba4ff65817b511b08c2092bdfd2
File size: 1,234,964 bytes
Filename: tuxbot.arm
File type: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, BuildID[sha1]=877b804892ab218a53420b6dfbd0a2837368d0b5, for GNU/Linux 3.2.0, not stripped
SHA256 hash: bd6431fb06e4689142ef597cf00382e38ae20a5393a4d9277e45a3f5b3cbcff9
File size: 1,329,000 bytes
Filename: tuxbot.arm64
File type: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=b21cdc5e1b96c640a1d553ed518c49729e367823, for GNU/Linux 3.7.0, not stripped
SHA256 hash: a03b0d41f5ef03328150331ffa0ed970998883f7e0343d79b2d3b95330d8e7c1
File size: 972,032 bytes
Filename: tuxbot.arm7
File type: ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), statically linked, BuildID[sha1]=a70cea846442c18ad265f311b5ced29a4071771d, for GNU/Linux 3.2.0, not stripped
SHA256 hash: eb2fa179fde2f097c18d5d700ad87d660fc238ee14cbe5477032e60856859621
File size: 1,352,256 bytes
Filename: tuxbot.hppa
File type: ELF 32-bit MSB executable, PA-RISC, 1.1 version 1 (GNU/Linux), statically linked, BuildID[sha1]=69dc276dde8efcb409411508da55d4cbe28d5600, for GNU/Linux 3.2.0, not stripped
SHA256 hash: a8d70d16509e227d8306be361bc37a3dc9fe34bf476f51e361e55e6d293c2b3f
File size: 1,160,756 bytes
Filename: tuxbot.m68k
File type: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), statically linked, BuildID[sha1]=adf267caab78a74c4b4dfabe7b578b0a4d639782, for GNU/Linux 3.2.0, not stripped
SHA256 hash: 0f8bcca3ed65e980da2a1f90a767b7d543be32eeea3e9338d09d4d635a497988
File size: 1,431,220 bytes
Filename: tuxbot.mips
File type: ELF 32-bit MSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, BuildID[sha1]=a8fd13f6b1bdfa87c0f466df69b7e81325b5dd15, for GNU/Linux 3.2.0, not stripped
SHA256 hash: 96b1f96efca3b9df2dea85678d60da27e3265b4a00e39e20e64b27bb985e1561
File size: 1,468,624 bytes
Filename: tuxbot.mips64
File type: ELF 64-bit MSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), statically linked, BuildID[sha1]=befb0e4d1cd7d2b4139b55f811993af2c8839e75, for GNU/Linux 3.2.0, not stripped
SHA256 hash: c7a36d6b8128c41f93a32413675401a10a2b5769b221bbaa8c5c309585b73ceb
File size: 1,403,096 bytes
Filename: tuxbot.mips64el
File type: ELF 64-bit LSB executable, MIPS, MIPS64 rel2 version 1 (SYSV), statically linked, BuildID[sha1]=e0f8dd23e4fb0086feb42ea0a5dcef70d7b4d17c, for GNU/Linux 3.2.0, not stripped
SHA256 hash: 246c97957651de568e61eba1abe572f0b0f960456209995d43d53a0d7cc494a1
File size: 1,431,268 bytes
Filename: tuxbot.mipsel
File type: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1 (SYSV), statically linked, BuildID[sha1]=7ad840b1945cc346012987727ebcc062431965a4, for GNU/Linux 3.2.0, not stripped
SHA256 hash: 3ec016d637e4c9cd331edd2580a229621ad638e924a4aa29ac0342e9144ace19
File size: 1,492,228 bytes
Filename: tuxbot.ppc
File type: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), statically linked, BuildID[sha1]=4e1483737f769e1cee80fa4d7a056a5d8e3b537e, for GNU/Linux 3.2.0, not stripped
SHA256 hash: 2f2c3551762c03da126e45dca6fc2f997c63f0f1bfc21fd0ceed680ac6f083ce
File size: 1,721,904 bytes
Filename: tuxbot.ppc64le
File type: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (GNU/Linux), statically linked, BuildID[sha1]=4cba585d9f208bd712b28f867f908e503ccc9cfe, for GNU/Linux 3.10.0, not stripped
SHA256 hash: 9cd5e7e3c8bad321ef6c3d47fe25b3b56e9487f703a7eeee52db4067e6bafe61
File size: 1,185,264 bytes
Filename: tuxbot.riscv64
File type: ELF 64-bit LSB executable, UCB RISC-V, version 1 (GNU/Linux), statically linked, BuildID[sha1]=64af594c7f91793813e3d769e63816b143102396, for GNU/Linux 4.15.0, not stripped
SHA256 hash: e3a5296e762e9ee16010399666441d663beeea956382e97cca032a6a5ad06811
File size: 1,542,064 bytes
Filename: tuxbot.s390x
File type: ELF 64-bit MSB executable, IBM S/390, version 1 (GNU/Linux), statically linked, BuildID[sha1]=2774a5f5991657eb9b0062cd3da0391c9bad2643, for GNU/Linux 3.2.0, not stripped
SHA256 hash: f1efb78887bb8783d7781c07cd13b53c9c79ebe5baa81f335838d0a6e73dec7e
File size: 1,096,720 bytes
Filename: tuxbot.sh4
File type: ELF 32-bit LSB executable, Renesas SH, version 1 (SYSV), statically linked, BuildID[sha1]=304e14a138b92135aad27bb37f4e9db440401ec2, for GNU/Linux 3.2.0, not stripped
SHA256 hash: f324a45fcd2a9db4e542c09486c21b08bc42d6bf76fbd5f17871090361b10815
File size: 2,240,240 bytes
Filename: tuxbot.sparc64
File type: ELF 64-bit MSB executable, SPARC V9, Sun UltraSPARC1 Extensions Required, relaxed memory ordering, version 1 (GNU/Linux), statically linked, BuildID[sha1]=74fba0bad93bbb0e1eedb196b6efe6af1c0bf23d, for GNU/Linux 3.2.0, not stripped
194.46.59[.]169 - AISURU infrastructure (yamux Go tool)
Historical IP addresses:
188.166.2[.]226 - Tsunami dropper (dead code in RCE exploit). Now serves Ubiquiti UISP. Blocking will affect legitimate services.
154.6.197[.]43 - Present in the bot source code as scan/server domain. Successful Telnet logins are reported to this IP address. Flagged as a scanner by GreyNoise.
Domains:
c2.tuxbot.local - DNS fall-back C2 domain (hard coded in binary)
cfcybernews[.]eu - Test domain leaked by CF bypass module
captcha.kanfetka[.]site - Test domain leaked by CAPTCHA bypass module
digikalas[.]online - Developer domain
jetross[.]com - TLS certificate linking the C2 server to the dropper
Host Indicators:
Infected By Akiru - Console output after bot execution
/bin/busybox Akiru - Busybox probe during Telnet scanning
Akiru: applet not found - Expected response to busybox probe
sd-pam.service - Systemd persistence service name
/tmp/.%08x.lock - Lock file format for single-instance enforcement
