Securtr

Attackers have crossed a line that most enterprise security teams aren’t prepared for: they’re using your own Microsoft 365 infrastructure — specifically, a legitimate Outlook inbox — as a command-and-control channel, making the malicious traffic look identical to routine business email communication. The GoGra backdoor, previously observed on Windows, has now been ported to Linux, quietly expanding the attack surface to servers, containers, and cloud workloads where endpoint detection is often thinner. If your SOC is tuned to flag suspicious outbound connections to unknown IPs, this campaign will walk right past you — because there are none.

What Is GoGra — and Why the Linux Port Matters

GoGra is a backdoor written in Go that was originally identified targeting Windows environments, attributed to a threat actor with a track record of espionage-focused intrusions. The Linux variant doesn’t just port the code — it signals a deliberate expansion of targeting scope. Linux underpins most enterprise server fleets, CI/CD pipelines, Kubernetes nodes, and cloud VMs. These systems are often managed with a lighter security touch than Windows endpoints: fewer EDR agents, fewer behavioral baselines, and sometimes no centralized log forwarding at all.

What makes GoGra particularly dangerous isn’t sophistication in the traditional sense — there’s no novel kernel exploit, no zero-day. The sophistication is in the channel selection. By using the Microsoft Graph API to communicate through a controlled Outlook mailbox, the malware’s C2 traffic is functionally indistinguishable from everyday Microsoft 365 activity. No suspicious domain. No self-signed certificate. No unusual port. Just HTTPS to graph.microsoft.com — a destination that virtually every enterprise allowlists without question.

How the Attack Works: Outlook as a Dead Drop ⚠️

The technique is a modern implementation of a classic tradecraft concept: the “dead drop.” Instead of a threat actor’s C2 server sitting exposed on the internet, commands are written to an attacker-controlled Outlook mailbox. The implant on the victim machine authenticates to Microsoft Graph API using a hardcoded or stolen OAuth token, reads new emails from the inbox (which contain encrypted commands), executes them locally, and then replies to the same thread with exfiltrated output — all over legitimate TLS to Microsoft’s own endpoints.

From a network inspection standpoint, this is a nightmare scenario. Your firewall sees HTTPS to graph.microsoft.com. Your proxy logs it as Microsoft Office traffic. Your SIEM, if it’s only watching for known-bad IPs or domains, generates exactly zero alerts. The entire C2 loop is authenticated, encrypted, and hosted on infrastructure you’re paying for.

In our enterprise deployments, I’ve seen organizations invest heavily in threat intelligence feeds and domain blocklists — and they would have caught zero of this. The attack deliberately renders that entire detection layer irrelevant. What matters here is behavioral detection on the endpoint and anomaly detection on process-level network activity, not perimeter filtering.

MITRE ATT&CK Mapping

• T1102.002 — Web Service: Bidirectional Communication: Using a legitimate web service (Microsoft Graph / Outlook) as a C2 channel in both directions.
• T1071.001 — Application Layer Protocol: Web Protocols: C2 communication carried over HTTPS to blend with normal traffic.
• T1059 — Command and Scripting Interpreter: Commands received via email are executed on the victim Linux host.
• T1041 — Exfiltration Over C2 Channel: Output is returned via the same Outlook thread used for command delivery.
• T1036 — Masquerading: Traffic masquerades as legitimate Microsoft 365 API communication.
• T1078 — Valid Accounts: OAuth tokens used to authenticate to Graph API may be stolen or hardcoded credentials.

Who’s in the Crosshairs

Attribution details point toward espionage motivations — which means the primary targets are likely government agencies, defense contractors, critical infrastructure operators, and technology companies with valuable intellectual property. But don’t let that create a false sense of security if you’re in another sector. The Linux variant specifically suggests the threat actor is moving up the stack — targeting the servers and cloud workloads that sit behind your Windows endpoints and hold your most sensitive data: databases, secrets managers, build systems, internal APIs.

If your organization runs Linux servers in hybrid Microsoft 365 environments — and nearly every enterprise does — you are within the realistic target population. This is especially true if your Linux hosts have any outbound internet access to Microsoft’s Graph API endpoints, which they almost certainly do if any automation or integration work touches M365.

This threat also connects directly to a growing concern I’ve written about before: the attack surface created when AI agents and automation tools are granted email and API access. Once you normalize programmatic Graph API access across your environment, distinguishing legitimate service accounts from malicious implants becomes significantly harder. 🛡️

How to Detect It: Wazuh Rules and Behavioral Hunting 🔧

Traditional signature-based detection won’t save you here. What you need is process-level network telemetry correlated with behavioral baselines. On Linux, the key signals are: unexpected processes making outbound HTTPS connections to graph.microsoft.com, processes spawned from unusual parent processes that then make network calls, and OAuth token usage from hosts that have no legitimate M365 integration.

Below is a Wazuh custom rule set targeting exactly this behavior — flagging when a non-whitelisted process on a Linux host initiates a connection to Microsoft Graph API endpoints, and when process execution follows suspicious parent-child chains indicative of a backdoor running commands received over the channel.

<!-- /var/ossec/etc/rules/gogra_graph_c2_detection.xml -->
<group name="gogra,linux,c2,graph_api">

  <!-- Rule 1: Detect outbound connection to graph.microsoft.com from unexpected process -->
  <rule id="100400" level="10">
    <if_group>syslog</if_group>
    <match>graph.microsoft.com</match>
    <field name="process.name" negate="yes">Teams|OneDrive|outlook|msedge|chrome|firefox|curl|wget</field>
    <description>Unexpected process connecting to Microsoft Graph API - possible GoGra C2</description>
    <mitre>
      <id>T1102.002</id>
      <id>T1071.001</id>
    </mitre>
  </rule>

  <!-- Rule 2: Detect Go binary (common GoGra artifact) spawning shell commands -->
  <rule id="100401" level="12">
    <if_group>audit</if_group>
    <field name="audit.exe" type="pcre2">/tmp/|/dev/shm/|/var/tmp/