The AI produced malware kill switch

In part one we walked through WindowsAudit.exe, the .NET apphost backdoor we found running as LocalSystem on our client’s network. We covered how it got onto the host, how it persisted, and the surface area of what it could do once it was there.

This is part two. Part one was the malware. Part two is everything that came after: what we did with the binary in front of us, the other organizations we ended up identifying as victims of the same attacker, and the architectural decision in the C2 protocol that we only noticed once the rest of the work was already done.

Unpacking the binary

WindowsAudit is shipped as a .NET apphost: a native, statically linked launcher that stages and runs a managed DLL with the appropriate .NET runtime. The first thing we did once samples were on disk was peel that wrapper apart, extract the embedded WindowsAudit.dll, and run it through a decompiler.

Inside, in plaintext, sitting next to Program.Main, was a Discord bot token. No obfuscation, no XOR layer, no environment lookup. The same string was baked into every copy of the binary on every infected host.

A Discord bot token is a credential. Whoever holds it can authenticate to Discord as the bot: connect to the gateway, read the channels the bot is in, download attachments, post messages. We treated it as exactly that: a stolen credential the attacker had unwittingly handed us by leaving it in the agent.

The config also contained credentials to an MQTT broker which was used as a second C2 channel, however we will not focus on that in this article.

Building the monitor

We were cautious about how we used the token. The client had already blocked the C2 communications at the firewall level, taking every infected host’s bot session offline. Our working assumption was that the attacker ran each campaign from a dedicated bot account — so if we authenticated and the bot went from “all instances offline” to “one instance back online,” they might notice something had reconnected. To avoid that, we built a small monitoring service on our own infrastructure: it authenticated with the token, pulled channel message history, downloaded attachments, and indexed everything it saw.

That caution turned out to be overly cautious. As we’ll get to further down the post, the attacker was running every campaign through the same single bot account, with the bot’s identity shared across every infected host. An extra session showing up under that identity would have been indistinguishable from any other infected machine reconnecting, and would not have stood out at all. But we didn’t know that at the time, and the monitor we built was sufficient regardless.

The token’s permissions mattered. The bot’s configured permissions did not include the ability to list guild members or channel members, so we had no immediate way to enumerate who else was in the server or pull a roster of connected users. What the token did give us was read access to the channels the bot had been added to: their message history, their attachments, and the ability to tail new messages as they arrived. Within those constraints, the monitor gave us four useful things:

• Bus channel history. Because the monitor never registered with the Discord gateway, we never saw the operator’s slash commands as live interaction events: those go from Discord to a connected bot session and don’t otherwise touch the channel. What we did see was every JSON message the bot had posted to the “bus” channel as a result, every response, and every attachment.
• Snowflake metadata. Every Discord ID (guild, channel, message, user, bot) encodes a millisecond-precision creation timestamp in its upper bits. From snowflakes alone we could date the creation of the guild the attacker was using as a console, the bot account, and every channel and message inside the server. Stacked together it gave us a hard timeline of the attacker’s tooling that they had no way to forge or scrub after the fact.
• Live activity tailing. This turned out to be simpler than expected. The bot never spoke on its own: no pings, no heartbeats, no scheduled status updates, nothing. Every bus channel message was the downstream consequence of the operator typing a slash command into their Discord client. So a new message arriving in the channel was, on its own, a near-perfect signal that the operator was at the keyboard. The monitor watched for that and paged us in near-real-time, which let us correlate the operator’s working hours, timezone, and which victims they tended to revisit.
• Tool outputs. When commands like netscan, ad_users, dump_lsass, or screenshot produced output too large to fit in a Discord message, the agent uploaded the result as an attachment. Those attachments stayed in the channel. We pulled and archived all of them.

The stager channel also gave us something operationally useful. The malware’s update mechanism worked by splitting the agent binary into multiple GZip-compressed chunks, then posting each chunk as a Discord message attachment in the stager channel for the infected hosts to download. The chunk messages would arrive first, one attachment per part, followed by a manifest message declaring the version string and the total number of parts. Any infected host that needed to restore or update itself would collect the chunks, use the manifest to verify all parts were present, reassemble them in order, decompress, and execute. In practice this meant that every time the attacker pushed a new build of the malware to their victims, a fresh set of manifest and chunk messages would appear in the channel. Our monitor alerted us each time this happened.

From there, our automation would pull the new sample, unpack the apphost wrapper, extract the embedded DLL, decompile it, and pull the hardcoded configuration — bot token, guild ID, channel IDs, MQTT credentials — along with hashes of every component. Each new build fed directly into new detections without any manual steps.

Occasionally the operator would also fumble a slash command and send it as a regular text message from their own personal Discord account rather than through the bot. Those messages sat in the channel history alongside everything else. Everybody, meet n0rad_:

What we had after downloading everything was effectively the operator’s own loot dump: sortable, searchable, dated. Internal subnet maps. AD enumeration dumps with domain names we didn’t recognize. Hostnames, usernames, file listings, hashes, screenshots of other people’s desktops.

Each of those was a different victim.

Finding the other victims

The attachments were the part that turned this from a single-customer incident into something with an externally-facing footprint.

Tool outputs are full of identifiers. AD dumps name the domain. netscan results expose internal subnets, but more usefully they expose hostnames, and corporate hostnames are often a giveaway, with naming conventions, asset tags, and location codes that are recognizable on sight to anyone who’s worked in IR for any length of time. Inventory commands returned licensed-product names and registered company strings. Screenshots embedded the user’s wallpaper, taskbar, browser tabs, and open documents.

For each candidate organization we built a small dossier: which agent IDs in the channel almost certainly belonged to them, what the operator had already done on those agents, what data had been exfiltrated, and roughly when the compromise had started (snowflakes again: the earliest message bearing that agent’s ID is a hard upper bound on dwell time). In all, we positively identified 25 unique victims in the data, with some still unidentified. We quickly realized that this was not a small campaign, and that this threat actor was actively working away to compromise as many organizations as possible, and appeared to have domain admin access in multiple orgs — a level of access that could support ransomware deployment. All while we watched from our kibana dashboard.

Because several victims were based in Israel, we coordinated notification through CERT-IL, Israel’s national computer emergency response team. The response work that came after is not something we’re going to write up publicly. The reverse engineering and the monitoring were a means to an end. The end was getting other people unstuck.

Then we looked at the protocol itself

It was only after the monitoring infrastructure was up, the victims were identified, and the notifications were in flight that we went back to the recorded channel data and started looking at the protocol itself: the shape of the messages, rather than the contents flowing across them.

Three key observations were made:

1. The bus channel was not just carrying responses from the bots back to the operator. It was also carrying commands to them: JSON messages with a type, requestId, targetAgent, and a payload. Agents read those messages, matched targetAgent against their own hostname or machine GUID, and executed whatever the payload told them to do.
2. The sender of every one of those command messages (the message author metadata in the Discord logs) was the same bot account whose token we already held. The token wasn’t just for receiving commands, it could be used to send them too. It was the identity actually posting the commands the agents were acting on.
3. The bot itself was handling the operator’s slash commands. When the operator typed /exec in their Discord client, Discord delivered the interaction to a connected bot session, and the bot serialized that interaction into the JSON envelope and posted it onto the bus channel for every other infected host to consume.

The flaw

WindowsAudit.exe is monolithic. Every infected machine runs the same binary, and that binary runs two services in parallel: a bot service that connects to the Discord gateway and registers the slash commands, and an agent worker that subscribes to the bus channel and executes anything addressed to it. Discord allows multiple gateway connections to share the same bot token (it’s how sharding works for high-traffic bots), so every infected host is simultaneously a “controller” registering the operator’s slash commands and a “victim” listening on the bus channel.

When the operator types /exec, the interaction doesn’t go anywhere special. Discord routes it to whichever infected host happened to win the gateway lottery for that interaction. That host then writes the command onto the bus channel as the bot. Every other infected host reads it off the bus channel and runs it without any verification of its authenticity, no signing involved.

So the protocol fundamentally requires the bots to be able to write to the bus channel, a huge design flaw.

Pull one sample, unpack, decompile, read the token. You can post commands to the bus channel and every infected host will execute them. There is no separate C2 server for the operator to harden. There is no C2 server. Every running copy of the binary is the C2 server. And the credential to act as the C2 server is shipped with each one.

We never exploited this vulnerability, although one could theoretically uninstall the attacker’s agent from every infected host using this power. The monitoring work needed nothing more than read access, and posting anything to the bus channel ourselves would have rendered in the operator’s own Discord client just as visibly as it would have on the agents, which was exactly the wrong outcome when the goal was a quiet feed of their activity. The point of writing the flaw up here isn’t that it was operationally useful to us; it’s that the architecture handed the entire botnet to anyone willing to spend an afternoon with a decompiler.

Why this design happened

To be honest:

The author wanted the C2 to look like normal Discord traffic. Discord whitelists itself out of most corporate egress filtering, slash commands give you a free polished UI, and attachments give you a free file-transfer plane. On paper, it made sense. But Discord’s bot model is designed around a single bot service running in a trusted environment, with the token kept secret. The author didn’t have a single trusted environment; they had N untrusted endpoints, and they wanted any of them to be able to act as the controller. So they gave them all the same token.

The moment you do that, you’ve collapsed the trust boundary. The bot identity no longer represents “the operator”; it represents “anyone running this binary.” And because Discord’s permission model only understands identities, the protocol cannot tell the difference between an instruction from the operator and an instruction from a malware analyst with a decompiler and a curl command.

You can basically smell the vibe-coding in this setup.

What we kept, what we didn’t

We’ve intentionally left specific tokens, channel IDs, snowflakes, and credentials out of this post. They were useful operationally, briefly, but publishing them now would do nothing except potentially burn collaborators or out the affected organizations.

Why are we publishing this?

You may be asking yourself why we published this. Why not sit on it and collect intel as long as we could? After sharing the information to the Israeli CERT, they published key details about the Discord operation publicly, effectively blowing our cover. If we had waited any longer, the window to warn remaining victims would have closed. Publishing the analysis now lets defenders detect the same indicators before the attacker adapts.

IOCs

This is part two of two. Part one covers the malware itself: the apphost wrapper, the persistence chain, and the WinSAT secondary stage.