gopherwhisper is using discord, slack and outlook as C2. your egress monitoring won't see it.

eset just disclosed a previously undocumented china-aligned APT they're calling gopherwhisper. it's been active since at least november 2023. the toolset is almost entirely written in go. and the C2 plane is where it gets interesting: discord servers, slack workspaces, microsoft 365 outlook mailboxes, and file.io.

if you're running a network monitoring stack that flags "weird outbound traffic" as your primary detection control for malware C2, gopherwhisper is the second story this month telling you that control category is structurally outclassed. let's walk through what's in the toolset, how the C2 actually works, and what detection looks like when "weird outbound traffic" is no longer the primitive that finds the threat.

the discovery

gopherwhisper surfaced in eset telemetry in january 2025, when researchers found a previously unknown backdoor on the system of a governmental entity in mongolia. eset named that backdoor laxgopher and started tracking the cluster. tracing the development cadence and infrastructure overlap, eset assesses with reasonable confidence that the group has been operationally active since at least november 2023.

the published 49-page eset whitepaper attributes the group as china-aligned based on tooling, victimology and operational hours. eset has not given the group a numeric identifier yet; the gopherwhisper name comes from the fact that almost every tool in the kit is gopher-themed.

confirmed victims so far: roughly 12 systems at one mongolian governmental institution. unattributed but visible victims based on attacker-server telemetry: dozens more. eset has not named the other targets but the mongolian-government starting point and the C2 infrastructure pattern are consistent with a regional intelligence-collection mandate against central asian governments and their counterparts.

the toolset

it's a go-heavy custom toolset with a small c++ outlier:

• laxgopher: go backdoor, the original sample eset found in mongolia, supports command execution, file upload/download, and tasking via discord
• ratgopher: a second go backdoor variant, similar capability profile, separate codebase, used in different infections
• boxoffriends: third go backdoor variant, name suggests collaboration tooling, capability set overlaps with laxgopher and ratgopher
• jabgopher: go injector used to deploy the backdoors against running processes
• friendDelivery: loader stage, also written in go, responsible for staging the backdoor onto disk and starting jabgopher
• compactgopher: exfiltration tool focused on staging and uploading collected data through file.io and outlook attachments
• sslordoor: c++ backdoor, the only non-go tool in the kit, capability set similar to the go backdoors. unclear why the kit has a c++ outlier. possible explanations: legacy holdover from before the go pivot, target-specific deployment when go runtime would be conspicuous, separate developer working on a different track within the same operator group.

what's notable across the kit is the layering: separate loaders, separate injectors, separate backdoors, separate exfil tooling, all interoperating through a shared C2 design. this is mature engineering. it's not "we found a github project and rebadged it."

the C2 design

here's the part that should change how you think about detection.

gopherwhisper does not run its own C2 servers. instead, the entire command-and-control plane lives on:

• discord: attacker-controlled discord servers used for command tasking. the backdoor logs into discord using attacker-provided bot tokens, polls a specific channel for command messages, executes them, and replies with the output as a discord message.
• slack: attacker-controlled slack workspaces, same pattern. the backdoor polls a specific channel for commands, executes, replies. appears to be a fallback path when discord traffic is blocked.
• microsoft 365 outlook: attacker-controlled M365 tenant. the backdoor authenticates against the M365 Graph API using a token embedded in the binary, polls a specific outlook folder, reads message bodies as commands, replies via mail or saves output to the same folder.
• file.io: anonymous file-sharing service used as the staging location for larger payloads and exfiltrated data archives. the backdoor downloads stage-2 components from file.io URLs and uploads larger exfil bundles to it.

what does the network traffic look like from an infected host?

it looks like discord. it looks like slack. it looks like outlook. it looks like file.io. all of those are services the average modern enterprise allows by default at the proxy and firewall level, because every other employee in the building is using them all day. there is no anomalous tunneling, no unusual port, no obscure domain, no encrypted-protocol-on-wrong-port pattern that triggers a netflow rule.

this is the harvester / gogra story from last week, mirrored. symantec attributed harvester (russian-aligned per longstanding analysis) to a new linux backdoor called gogra that uses microsoft graph polling every 2 seconds against an outlook folder named "zomato pizza" for command-in-email C2. byte-for-byte indistinguishable from legitimate M365 traffic at the network layer.

two consecutive cycles. one russian-aligned cluster, one china-aligned cluster. same architectural pattern: legitimate-cloud-SaaS-as-C2.

why this is structurally hard to detect

network-egress monitoring works because malware historically used dedicated C2 infrastructure that didn't blend in. attacker-rented VPSes, dynamic DNS providers with bad reputation, IRC servers, custom protocols on weird ports, encrypted tunnels to suspicious geos. all of those things produce signal: signature-rule misses, but reputation-and-anomaly rules hit.

discord, slack, outlook and file.io produce no signal at the network layer. every modern enterprise generates millions of legitimate connections to these services daily. the malware traffic is one needle in a haystack that's already 99.99% needles.

the audit primitives that work for this threat live at a different layer:

• non-human-account auditing in the SaaS admin tier. m365, slack, discord and equivalents log per-account read activity against folders, channels and messages. the malware uses a service-tier account or a token-without-MFA account to poll. that account profile (no interactive login, no UI activity, only API polling) is detectable if you have the audit logs and you're looking.
• anomalous folder polling cadence. a backdoor polling an outlook folder every 30 seconds for command messages produces a different log signature than a human checking email. both look like reads, but the temporal distribution is distinctive. requires audit-log analytics, not network analysis.
• bot-token usage anomalies in discord and slack. a corporate slack workspace generally has a small known set of authorized bots. an unauthorized bot that's been added by a compromised employee account, or an authorized bot whose API usage suddenly spikes against unfamiliar channels, is detectable through slack admin audit and discord audit log review.
• OAuth grant inventory at quarterly cadence. the OAuth-grant-as-persistence pattern (vercel breach via context.ai, harvester via M365 Graph) overlaps. routine review of "what apps have access to my tenant, what scopes do they have, when was each grant issued" finds dormant attacker access that the original grant flow missed.

most security teams in 2026 do not currently have these audit-log analytics plumbed. that's the gap GopherWhisper exposes.

what to do this week

practical detection guidance:

1. enumerate the OAuth grants in your microsoft 365 tenant. flag any non-microsoft, non-known-vendor app with read scopes against mail or files. compare against the list of apps your IT team has approved. anything you can't explain gets revoked, today.
2. pull the audit log for service accounts in your slack and discord. for slack, the admin audit API exposes channel-read events; filter for service accounts and look for high-frequency polling of channels that human users don't visit. for discord (corporate or community-facing), check authorized bots and their channel access.
3. review your M365 audit-log retention. if you're on a license tier that gives you 90 days, that's borderline; the backdoor traffic against an outlook folder polled every few seconds will overwhelm a 90-day window quickly. consider the longer retention SKU if you're in a target sector.
4. add SaaS-tier audit telemetry to your SIEM. if your SOC's primary detection visibility is endpoint plus network plus AAD sign-ins, you are now visibly behind the ESET/Symantec curve. fold in slack/discord/m365-graph/file.io read events, even sampled, as a baseline.

the underlying point

the C2 attack surface has migrated to the saas layer. that migration started earlier (gogra in 2024, several china-aligned clusters using github gist as a staging primitive), but two consecutive vendor disclosures attributing two different state-aligned actors to the same architectural pattern is the signal that this is now baseline tradecraft, not elite-only.

your detection model has to follow. network egress monitoring is not the primary control for legitimate-saas-as-C2. the audit log is. if your SOC doesn't have m365, slack, discord and OAuth-grant audit logs as first-class detection signals, this is the cycle to fix it.

eset called the new actor gopherwhisper. the next one will probably be named after a different animal. the C2 pattern will be the same.

Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if your SaaS-tier audit story needs hardening.