Which SIEM platforms have a THREAT-C2-GitHubRawContentDeadDropResolver detection rule?

df00tech provides THREAT-C2-GitHubRawContentDeadDropResolver (Command and Control Configuration Resolution via GitHub/Gist Raw Content Dead Drop) detection queries for 7 SIEM platforms: Microsoft Sentinel / Defender, Splunk, Elastic Security (EQL), IBM QRadar (AQL), Sumo Logic CSE, Google Chronicle / SecOps, CrowdStrike LogScale (CQL).

What severity and confidence is the THREAT-C2-GitHubRawContentDeadDropResolver detection?

The THREAT-C2-GitHubRawContentDeadDropResolver detection is rated high severity with medium confidence.

What are common false positives for THREAT-C2-GitHubRawContentDeadDropResolver?

Common false positives for THREAT-C2-GitHubRawContentDeadDropResolver include: Developer workstations and CI/build agents where git.exe, npm, pip, or an IDE extension fetches raw.githubusercontent.com/gist content as part of normal dependency resolution or update checks, and then separately opens an unrelated new connection within the correlation window purely by coincidence; Package managers and dependency-scanning tools that resolve a raw GitHub file as one step of a multi-host installation sequence, followed by a legitimate new connection to a package registry CDN edge; Security tooling (SOAR playbooks, threat-intel feed pullers, IaC pipelines) that legitimately fetch raw configuration or IOC lists from a GitHub-hosted repository on a schedule.

THREAT-C2-GitHubRawContentDeadDropResolver

Command and Control Configuration Resolution via GitHub/Gist Raw Content Dead Drop

Q: What data sources are required to detect Command and Control Configuration Resolution via GitHub/Gist Raw Content Dead Drop (THREAT-C2-GitHubRawContentDeadDropResolver)?

Detecting Command and Control Configuration Resolution via GitHub/Gist Raw Content Dead Drop requires the following data sources: Network Traffic: Network Connection Creation, Network Traffic: Network Connection Content, Microsoft Defender for Endpoint advanced hunting (DeviceNetworkEvents).

Command and Control Last updated: September 13, 2026

Adversaries increasingly host a short, tightly-scoped blob of encoded C2 configuration — typically a base64, hex, or single-byte-XOR-obfuscated IP:port or domain string well under a kilobyte — on raw.githubusercontent.com or gist.githubusercontent.com, the plain-text CDN endpoints GitHub serves repository files and gists from with no HTML wrapper. A dropper or stager fetches the raw file directly with a non-browser HTTP client (PowerShell's WebClient/Invoke-WebRequest, Python requests, a compiled .NET or Go HTTP client, certutil, or curl carrying a non-browser user agent), decodes it locally, and then opens a brand-new outbound connection to whatever address the content resolved to. Because raw.githubusercontent.com and gist.githubusercontent.com are legitimate, CDN-fronted GitHub infrastructure that developer tooling, CI runners, package managers, and IDE extensions all depend on, defenders cannot blocklist the hosts outright without breaking normal engineering workflows — the same constraint that makes dead-drop resolvers effective on Pastebin, Twitter, and Google Docs. What is detectable is the behavioral sequence rather than the host itself: legitimate fetches of these endpoints come from identifiable developer tooling (git.exe, VS Code's update/extension-fetch paths, npm/pip package resolution) and are not followed by that same process opening a connection to a destination it has never contacted before, whereas a dead-drop resolver fetch by a scripting engine or unusual binary is, within minutes, followed by exactly that novel outbound connection — the resolver having just told the implant where to go. This record differs from the T1102.001 base detection, which screens a broad, largely static list of dead-drop hosting platforms (Pastebin, GitHub, Twitter, Google Docs, YouTube, TechNet, and others) for non-browser access alone, by narrowing to the specific code-hosting-CDN pattern and adding the resolve-then-connect temporal correlation, which a static domain list has no way to express and which is what actually separates a malicious dead-drop fetch from the very large volume of legitimate raw.githubusercontent.com traffic on any developer-heavy estate.

What is THREAT-C2-GitHubRawContentDeadDropResolver Command and Control Configuration Resolution via GitHub/Gist Raw Content Dead Drop?

Command and Control Configuration Resolution via GitHub/Gist Raw Content Dead Drop (THREAT-C2-GitHubRawContentDeadDropResolver) maps to the Command and Control tactic — the adversary is trying to communicate with compromised systems to control them in MITRE ATT&CK.

This page provides production-ready detection logic for Command and Control Configuration Resolution via GitHub/Gist Raw Content Dead Drop, covering the data sources and telemetry it touches: Network Traffic: Network Connection Creation, Network Traffic: Network Connection Content, Microsoft Defender for Endpoint advanced hunting (DeviceNetworkEvents). The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic: Command and Control

Microsoft Sentinel / Defender

kusto

let LookbackWindow = 1d;
let PriorContactWindow = 15d;
let CorrelationWindow = 15m;
let DeadDropHosts = dynamic(["raw.githubusercontent.com", "gist.githubusercontent.com", "gist.github.com", "objects.githubusercontent.com"]);
let BrowserProcesses = dynamic(["chrome.exe", "msedge.exe", "firefox.exe", "brave.exe", "opera.exe", "iexplore.exe", "safari.exe"]);
let DevToolProcesses = dynamic(["git.exe", "code.exe", "node.exe", "npm.exe", "pip.exe", "python.exe", "devenv.exe"]);
let ConfigFetch =
    DeviceNetworkEvents
    | where Timestamp > ago(LookbackWindow)
    | where RemoteUrl has_any (DeadDropHosts)
    | where InitiatingProcessFileName !in~ (BrowserProcesses)
    | project FetchTime = Timestamp, DeviceId, DeviceName, FetchProcess = InitiatingProcessFileName,
              FetchCommandLine = InitiatingProcessCommandLine, FetchUrl = RemoteUrl,
              IsDevTool = InitiatingProcessFileName in~ (DevToolProcesses);
let PriorContacts =
    DeviceNetworkEvents
    | where Timestamp between (ago(PriorContactWindow) .. ago(LookbackWindow))
    | where ActionType == "ConnectionSuccess"
    | summarize by DeviceId, RemoteIP;
let NovelConnections =
    DeviceNetworkEvents
    | where Timestamp > ago(LookbackWindow)
    | where ActionType == "ConnectionSuccess"
    | where isnotempty(RemoteIP) and ipv4_is_private(RemoteIP) == false
    | join kind=leftanti (PriorContacts) on DeviceId, RemoteIP
    | project ConnectTime = Timestamp, DeviceId, ConnectProcess = InitiatingProcessFileName, RemoteIP, RemotePort;
ConfigFetch
| join kind=inner (NovelConnections) on DeviceId
| where ConnectTime between (FetchTime .. FetchTime + CorrelationWindow)
| where ConnectProcess =~ FetchProcess
    or ConnectProcess in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "rundll32.exe", "mshta.exe", "wscript.exe", "cscript.exe", "regsvr32.exe")
| extend GapSeconds = datetime_diff('second', ConnectTime, FetchTime)
| project FetchTime, ConnectTime, GapSeconds, DeviceName, DeviceId, FetchProcess, FetchCommandLine, FetchUrl,
          ConnectProcess, RemoteIP, RemotePort, IsDevTool
| sort by FetchTime desc

Detects the resolve-then-connect dead-drop pattern on Microsoft Defender for Endpoint telemetry by correlating two DeviceNetworkEvents arms per device. Arm 1 (ConfigFetch) selects RemoteUrl access to raw.githubusercontent.com, gist.githubusercontent.com, gist.github.com, or objects.githubusercontent.com from a non-browser process. Arm 2 (NovelConnections) computes, per device, outbound TCP connections to a public RemoteIP that a leftanti join shows the device has not successfully connected to in the preceding 15 days — the genuine 'this is a brand-new destination' signal, not just any connection. The two arms are joined on DeviceId with the novel connection required to land within 15 minutes after the fetch, and the connecting process required to match the fetching process or be a common LOLBin/scripting host that a dropper would hand off execution to. ipv4_is_private is used rather than an 'in' list because KQL 'in' performs string equality and cannot evaluate CIDR membership. The IsDevTool flag is carried through rather than used as a hard exclusion, since it is a useful triage signal (git.exe or code.exe matching the pattern is far more likely to be a coincidental developer workflow) without silently dropping a compromised developer tool from view.

high severity medium confidence

Data Sources

Network Traffic: Network Connection Creation Network Traffic: Network Connection Content Microsoft Defender for Endpoint advanced hunting (DeviceNetworkEvents)

Required Tables

DeviceNetworkEvents

False Positives

Developer workstations and CI/build agents where git.exe, npm, pip, or an IDE extension fetches raw.githubusercontent.com/gist content as part of normal dependency resolution or update checks, and then separately opens an unrelated new connection within the correlation window purely by coincidence
Package managers and dependency-scanning tools that resolve a raw GitHub file as one step of a multi-host installation sequence, followed by a legitimate new connection to a package registry CDN edge
Security tooling (SOAR playbooks, threat-intel feed pullers, IaC pipelines) that legitimately fetch raw configuration or IOC lists from a GitHub-hosted repository on a schedule
VS Code, GitHub Desktop, or other developer applications' own update-check or telemetry paths reaching these hosts under a non-browser process name

Splunk

spl

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" (EventCode=22 OR EventCode=3)
| eval ImageLower=lower(coalesce(Image, "unknown"))
| eval QueryLower=lower(coalesce(QueryName, ""))
| eval DestIp=coalesce(DestinationIp, "0.0.0.0")
| eval DestPort=tonumber(coalesce(DestinationPort, "-1"))
| eval IsDeadDropQuery=if(EventCode=22 AND (like(QueryLower, "%raw.githubusercontent.com%") OR like(QueryLower, "%gist.githubusercontent.com%") OR like(QueryLower, "%gist.github.com%") OR like(QueryLower, "%objects.githubusercontent.com%")) AND NOT (like(ImageLower, "%\\chrome.exe") OR like(ImageLower, "%\\msedge.exe") OR like(ImageLower, "%\\firefox.exe") OR like(ImageLower, "%\\git.exe")), 1, 0)
| eval IsPrivateDest=if(cidrmatch("10.0.0.0/8", DestIp) OR cidrmatch("172.16.0.0/12", DestIp) OR cidrmatch("192.168.0.0/16", DestIp) OR cidrmatch("127.0.0.0/8", DestIp), 1, 0)
| eval IsOutboundConnect=if(EventCode=3 AND IsPrivateDest=0, 1, 0)
| where IsDeadDropQuery=1 OR IsOutboundConnect=1
| transaction ComputerName startswith=(IsDeadDropQuery=1) endswith=(IsOutboundConnect=1) maxspan=15m maxevents=2
| eval FetchTime=strftime(_time, "%Y-%m-%d %H:%M:%S")
| table FetchTime, ComputerName, ImageLower, QueryLower, DestIp, DestPort, duration, eventcount
| sort - _time

Splunk equivalent over Sysmon telemetry, since Sysmon Event ID 3 (Network Connection) records only DestinationIp/DestinationPort and has no HTTP host field, so the dead-drop-host arm instead uses Sysmon Event ID 22 (DNS Query), which genuinely does carry QueryName and the resolving Image, to detect resolution of the raw-content hosts by a non-browser process. The transaction command stitches that DNS event to a following Event ID 3 outbound connection on the same host within a 15-minute span using startswith/endswith markers, approximating the KQL version's resolve-then-connect correlation. This variant does not implement the 15-day novel-destination check the KQL version does — Sysmon alone has no lookup of prior connections — so it will flag every qualifying second-stage connection rather than only new destinations; treat matches with an already-known destination IP as lower priority during triage, or add an outputlookup-based first-seen table if your SIEM retention allows it. Private-address exclusion uses cidrmatch, the genuine CIDR-aware SPL function, rather than an IN() equality list.

high severity medium confidence

Data Sources

Sysmon Event ID 22 (DNS Query) Sysmon Event ID 3 (Network Connection) Splunk Add-on for Microsoft Sysmon

Required Sourcetypes

XmlWinEventLog:Microsoft-Windows-Sysmon/Operational

False Positives

Developer workstations where git, an IDE, or a package manager resolves a raw GitHub/Gist host and then coincidentally opens an unrelated new connection inside the 15-minute correlation window
CI/build agents and dependency-scanning tools performing multi-host installation sequences that touch a raw-content host followed by a legitimate package registry connection
Automation, SOAR, or threat-intel tooling that fetches IOC lists or configuration from a GitHub-hosted repository on a recurring schedule
Any second-stage connection to a destination the host has actually contacted before, since this SPL variant lacks the KQL version's novel-destination filter and cannot distinguish a repeat connection from a genuinely new one

Elastic Security (EQL)

eql

sequence by host.id with maxspan=15m
  [ dns where event.category == "network" and
      dns.question.name : ("*raw.githubusercontent.com", "*gist.githubusercontent.com", "*gist.github.com", "*objects.githubusercontent.com") and
      not process.name : ("chrome.exe", "msedge.exe", "firefox.exe", "brave.exe", "git.exe", "git") ]
  [ network where event.type == "start" and network.direction == "outbound" and
      not cidrmatch(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16", "127.0.0.0/8", "169.254.0.0/16") ]

Elastic EQL sequence correlating a DNS resolution of a raw-content GitHub/Gist host by a non-browser process with a subsequent outbound network connection from the same host within 15 minutes. cidrmatch evaluates true CIDR membership for the private-address exclusion, unlike a destination.ip 'in' list which only performs literal equality. EQL sequences have no built-in 'has this host ever contacted this destination before' predicate, so this rule — like the SPL variant — approximates the KQL version's novel-destination filter by relying on the tight 15-minute window and process exclusions rather than true historical novelty; pair with a saved Kibana search bucketing destination.ip by host.id over 15 days if a stronger novelty check is required.

high severity medium confidence

Data Sources

Elastic Defend DNS events (ECS dns.* fields) Elastic Defend network events (process attribution for TCP sessions) Packetbeat DNS module (alternative DNS source where endpoint DNS logging is unavailable)

Required Tables

logs-endpoint.events.network-* logs-endpoint.events.dns-*

False Positives

Developer and CI hosts where git, an IDE, or a package manager resolves a raw-content host and coincidentally opens an unrelated new connection within the 15-minute window
Security or IaC automation legitimately pulling configuration or IOC feeds from a GitHub-hosted repository on a schedule
Any second connection to infrastructure the host has actually used before, since this variant lacks a true historical-novelty check
Renamed or portable browser installs whose process.name does not match the exclusion list

IBM QRadar (AQL)

sql

SELECT
    sourceip AS ClientIP,
    "DNS Query" AS QueriedDomain,
    COUNT(*) AS QueryCount,
    MIN(devicetime) AS FirstSeen,
    MAX(devicetime) AS LastSeen
FROM events
WHERE
    devicetime > (NOW() - 2592000000)
    AND (
        "DNS Query" ILIKE '%raw.githubusercontent.com%'
        OR "DNS Query" ILIKE '%gist.githubusercontent.com%'
        OR "DNS Query" ILIKE '%gist.github.com%'
        OR "DNS Query" ILIKE '%objects.githubusercontent.com%'
    )
GROUP BY sourceip, "DNS Query"
HAVING COUNT(*) >= 1
ORDER BY FirstSeen ASC

QRadar AQL over the events table populated by a DNS-logging DSM, isolating resolutions of the raw-content GitHub/Gist hosts by normalised DNS query name. QRadar's DNS-category DSMs typically do not carry process attribution, so this is the resolver-arm only — it establishes which internal hosts resolved a dead-drop-capable domain, not which process did so or whether a follow-on connection occurred. Correlate matches against the endpoint DSM (Sysmon or the native EDR DSM) for the initiating process, and against the flows table for a new outbound connection from the same sourceip within 15 minutes, before treating a hit as more than a lead. Replace the fixed 2592000000ms (30-day) window with your DSM's actual devicetime semantics if it differs.

medium severity low confidence

Data Sources

DNS-logging DSM (BIND query log, Windows DNS Server debug log, or Infoblox DSM) IBM QRadar events table Endpoint/EDR DSM (companion arm for process attribution)

Required Tables

events

False Positives

Developer and CI infrastructure resolving raw-content hosts as part of normal dependency or update workflows
Security automation or IaC tooling fetching configuration from a GitHub-hosted repository on a recurring schedule
Any resolution not followed by a genuinely new connection, since this AQL variant does not implement that correlation on its own
DNS caching/forwarding infrastructure that logs a resolution on behalf of many downstream clients under one sourceip

Google Chronicle / SecOps

yaral

rule github_raw_dead_drop_resolver_c2 {
  meta:
    author = "Detection Engineering"
    description = "Detects a non-browser DNS resolution of a raw GitHub/Gist content host followed by a new outbound connection from the same host, consistent with dead-drop C2 configuration resolution."
    mitre_attack_tactic = "Command and Control"
    mitre_attack_technique = "T1102.001"
    severity = "HIGH"
    priority = "MEDIUM"

  events:
    $fetch.metadata.event_type = "NETWORK_DNS"
    $fetch.network.dns.questions.name = /raw\.githubusercontent\.com|gist\.githubusercontent\.com|gist\.github\.com|objects\.githubusercontent\.com/ nocase
    not $fetch.principal.process.file.full_path = /(chrome|msedge|firefox|git)(\.exe)?$/ nocase
    $host = $fetch.principal.hostname

    $connect.metadata.event_type = "NETWORK_CONNECTION"
    $connect.network.ip_protocol = "TCP"
    not net.ip_in_range_cidr($connect.target.ip, "10.0.0.0/8")
    not net.ip_in_range_cidr($connect.target.ip, "172.16.0.0/12")
    not net.ip_in_range_cidr($connect.target.ip, "192.168.0.0/16")
    $host = $connect.principal.hostname

  match:
    $host over 15m

  outcome:
    $connection_count = count($connect.metadata.id)
    $observed_domains = array_distinct($fetch.network.dns.questions.name)

  condition:
    $fetch and $connect
}

Chronicle YARA-L 2.0 rule matching a NETWORK_DNS UDM event for a raw-content GitHub/Gist host from a non-browser principal process, joined to a NETWORK_CONNECTION UDM event from the same principal.hostname within a 15-minute match window. net.ip_in_range_cidr is Chronicle's genuine CIDR predicate, used here for the private-destination exclusion. Like the EQL and SPL variants, YARA-L's match/outcome model has no direct 'has this host ever reached this destination before' aggregation across a long lookback, so this rule relies on the tight time window and process exclusion rather than true historical novelty; a companion rule bucketing $connect.target.ip by $host over a 15-day match window can be added where a stronger novelty signal is required.

high severity medium confidence

Data Sources

Google Chronicle SIEM Chronicle UDM NETWORK_DNS events (endpoint or DNS-forwarder forwarders) Chronicle UDM NETWORK_CONNECTION events (EDR and NGFW forwarders)

Required Tables

NETWORK_DNS (UDM event type) NETWORK_CONNECTION (UDM event type)

False Positives

Developer and CI hosts resolving a raw-content host and coincidentally opening an unrelated new connection within the match window
Security or IaC automation legitimately pulling configuration from a GitHub-hosted repository on a schedule
Any follow-on connection to previously-contacted infrastructure, since this rule lacks a true historical-novelty check
Renamed or portable browser installs whose process path does not match the exclusion regex

CrowdStrike LogScale (CQL)

cql

#event_simpleName = DnsRequest
| DomainName = /raw\.githubusercontent\.com|gist\.githubusercontent\.com|gist\.github\.com|objects\.githubusercontent\.com/i
| !(ImageFileName = /\\(chrome|msedge|firefox|git)\.exe$/i)
| groupBy(
    [aid, ComputerName],
    function=[
      count(as=QueryCount),
      collect([DomainName, ImageFileName], limit=10),
      min(field=@timestamp, as=FirstSeen),
      max(field=@timestamp, as=LastSeen)
    ]
  )
| test(QueryCount >= 1)
| sort(field=FirstSeen, order=asc)

CrowdStrike Falcon LogScale query over DnsRequest sensor events, isolating resolutions of raw-content GitHub/Gist hosts with the resolving ImageFileName excluding common browsers and git.exe. This is the resolution arm only; join during triage against NetworkConnectIP4 events for the same aid within 15 minutes to identify the follow-on connection, and against a 15-day NetworkConnectIP4 history for that aid to assess whether the destination is genuinely new — LogScale groupBy aggregation alone does not express that historical-novelty check in a single query. Falcon's DnsRequest event, unlike a plain DNS server log, does carry ImageFileName, which is what makes the process-level exclusion possible here without a separate join.

high severity medium confidence

Data Sources

CrowdStrike Falcon sensor DnsRequest events CrowdStrike Falcon sensor NetworkConnectIP4 events (companion arm for follow-on connection) CrowdStrike LogScale (Humio)

Required Tables

DnsRequest NetworkConnectIP4

False Positives

Developer and CI endpoints resolving raw-content hosts as part of routine dependency or update workflows
Security automation or IaC tooling fetching configuration from a GitHub-hosted repository on a schedule
Any resolution not corroborated with a genuinely new follow-on connection, since this query alone does not perform that join
Renamed or portable browser installs whose ImageFileName does not match the exclusion regex

Sigma rule & cross-platform mapping

The detection logic for Command and Control Configuration Resolution via GitHub/Gist Raw Content Dead Drop (THREAT-C2-GitHubRawContentDeadDropResolver) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for THREAT-C2-GitHubRawContentDeadDropResolver Sigma rules on detection.fyi

Platform-specific guides for THREAT-C2-GitHubRawContentDeadDropResolver

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)

Last updated: 2026-09-13 Research depth: deep

References (7)

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

Test 1Fetch Encoded Config from a GitHub Raw Content URL via PowerShell, Then Connect (Windows)
Expected signal: MDE DeviceNetworkEvents / Sysmon Event ID 22: a DNS/HTTP access to raw.githubusercontent.com initiated by powershell.exe. Within seconds, a second network event (Sysmon Event ID 3 / MDE ConnectionSuccess) shows powershell.exe connecting to the decoded test destination and port.
Test 2Fetch Config from a Gist Raw URL via curl, Then Connect (Linux)
Expected signal: EDR-for-Linux process and network telemetry: curl execution reaching gist.githubusercontent.com, followed within seconds by a new outbound TCP connection from the same shell session to the decoded test host and port.
Test 3Benign Raw-Content Fetch with No Follow-On Connection, Negative Control (Windows)
Expected signal: A single DeviceNetworkEvents/Sysmon Event ID 22 record for the raw.githubusercontent.com access from powershell.exe, with no accompanying new outbound connection in the following 15 minutes.

Response Playbook

Triage

Confirm the fetching process is not a recognised developer or CI tool (git, code.exe, npm, pip). A scripting engine (powershell.exe, wscript.exe, mshta.exe) or an unsigned/renamed binary fetching a raw GitHub/Gist URL is a far stronger indicator than the same fetch from an IDE or package manager.
Pull the actual raw content that was fetched, if it is still reachable at the URL or recoverable from proxy/EDR content capture. A short blob (well under 1KB) that decodes as base64/hex to an IP:port or domain string is strong confirmation of a dead-drop resolver rather than legitimate file content.
Check whether the destination reached immediately after the fetch is genuinely novel for that host — a first-ever connection to an address is materially more suspicious than a connection to infrastructure the host talks to routinely.
Review the file/repository/gist itself for edit history if it is still public: dead-drop resolvers are frequently updated (new commit, new gist revision) shortly before or during active operations to rotate the C2 address without touching the malware binary.
Identify the process that made the follow-on connection and whether it is the same process that fetched the content, was spawned by it, or is an injected/hollowed process — this establishes whether the resolver output was consumed directly or handed off.
Search for the same raw-content URL, repository, or gist ID appearing across other hosts in the environment, which would indicate a shared dropper rather than an isolated event.

Containment

Isolate the endpoint via EDR network isolation rather than relying solely on a URL/domain block, since raw.githubusercontent.com and gist.githubusercontent.com cannot be blocklisted wholesale without breaking developer and CI workflows.
Block the specific resolved C2 destination IP/domain at the perimeter and in EDR once identified from the follow-on connection, understanding that the operator may republish an updated dead-drop pointing elsewhere.
Terminate the process that consumed the dead-drop content and any child process it spawned, preserving process memory first where the decoded C2 address may still be resident.
Where the specific gist ID or repository path is identifiable and clearly malicious, report it to GitHub for takedown, and separately hunt for any other host in the estate that has fetched the same URL.

Evidence Collection

The raw content payload itself (captured via proxy, EDR content inspection, or a timely re-fetch), plus the exact URL, gist ID, or repository path and commit/revision hash if recoverable.
Full DeviceNetworkEvents/Sysmon history for the host spanning both the fetch and the follow-on connection, plus at least 15 days prior to establish whether the follow-on destination is genuinely novel.
Process creation and command-line telemetry for the fetching process and any process it spawned or handed off to, including parent-process lineage back to the initial dropper or delivery vector.
Any locally cached or dropped file containing the decoded configuration (temp directories, ADS, registry run keys) that would show how the resolved address was persisted or consumed.

Escalation Criteria

! The fetching process is a scripting engine, LOLBin, or unsigned/renamed binary rather than recognised developer tooling, and it is followed by a genuinely novel outbound connection within minutes.
! The decoded dead-drop content resolves to infrastructure with existing threat-intelligence associations, or the same gist/repository is referenced by known malware samples.
! The same dead-drop URL or resolved destination appears across multiple hosts in a short window, indicating operator-deployed tooling rather than an isolated developer coincidence.
! The activity occurs on a server, domain controller, build/CI system, or other privileged host rather than an ordinary developer workstation.
! Post-resolution host behaviour shows staging, credential access, or collection activity, indicating the dead-drop successfully bootstrapped an active C2 channel.

Investigation Guide

Forensic Artifacts

> Proxy or EDR-captured HTTP response body from the raw-content fetch, which contains the encoded configuration and is the single most direct piece of evidence available.
> DeviceNetworkEvents (MDE) or Sysmon Event ID 22 + Event ID 3 pairs showing the DNS resolution of the raw-content host followed by the novel outbound connection.
> Process creation and command-line history for the fetching process, establishing whether it was an interactive user action, a scheduled task, or a headless dropper.
> Browser or application cache/history (if the fetch went through a browser-embedded control) versus the absence of any browser artefact (if it went through a bare HTTP client), which helps distinguish a user click from an automated fetch.
> GitHub's public commit/revision history for the repository or gist, when still accessible, showing how and when the dead-drop content was last changed.

Tuning Guidance

Build the developer/CI allowlist first: run the fleet-wide non-browser fetch hunt over 30 days, identify every process name and host role (build agents, IDE update paths, package managers) that legitimately and routinely touches raw.githubusercontent.com or gist.githubusercontent.com, and exclude those specific DeviceId/process-name pairs rather than excluding the hosts entirely, since the same hosts are exactly what a dead-drop resolver depends on. Do not drop the novel-destination requirement (the KQL leftanti join) to simplify the rule — it is what separates 'this process fetched a raw file and also happened to make a connection' from 'this process fetched a raw file and then went somewhere it has never been,' and removing it will produce far more noise on any estate with active development activity. Where a network sensor or proxy captures response body size or content, layer in the short-response hunting query as a corroborating signal before escalating a match that has no independent confirmation. If your environment cannot support the 15-day prior-contact lookback at scale, shorten it rather than removing it — even a 3-to-5-day window still filters out a host's routine, repeatedly-contacted infrastructure and preserves most of the detection's value.

Hunting Queries

Fleet-wide baseline hunt for any non-browser resolution of the raw-content GitHub/Gist hosts over 30 days, independent of any follow-on connection. This is the right starting point for building an allowlist of legitimate developer and CI processes that routinely touch these hosts, against which the correlated detection's remaining hits can be triaged much faster.

Hunting — KQL

kql

// Hunt: any non-browser fetch of a GitHub/Gist raw-content host in the last 30 days, regardless of follow-on activity
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any ("raw.githubusercontent.com", "gist.githubusercontent.com", "gist.github.com", "objects.githubusercontent.com")
| where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe", "firefox.exe", "brave.exe", "opera.exe")
| summarize FetchCount = count(), Urls = make_set(RemoteUrl, 20), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by DeviceName, InitiatingProcessFileName
| sort by FirstSeen asc

Hunting — SPL

spl

index=windows sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=22
| eval QueryLower=lower(coalesce(QueryName, ""))
| eval ImageLower=lower(coalesce(Image, "unknown"))
| where (like(QueryLower, "%raw.githubusercontent.com%") OR like(QueryLower, "%gist.githubusercontent.com%") OR like(QueryLower, "%gist.github.com%"))
| where NOT (like(ImageLower, "%\\chrome.exe") OR like(ImageLower, "%\\msedge.exe") OR like(ImageLower, "%\\firefox.exe"))
| stats count as FetchCount, values(QueryLower) as Queries, min(_time) as FirstSeen, max(_time) as LastSeen by ComputerName, ImageLower
| eval FirstSeen=strftime(FirstSeen, "%Y-%m-%d %H:%M:%S"), LastSeen=strftime(LastSeen, "%Y-%m-%d %H:%M:%S")
| sort FirstSeen

Hunts for unusually small response bodies from raw-content hosts, which is the size signature of a short encoded config blob rather than genuine source code, a README, or a binary release asset. This is a content-shape signal that is independent of the process-identity and timing correlation used in the primary detection and works well as a second, orthogonal pass over the same data source.

Hunting — KQL

kql

// Hunt: short (sub-1KB) responses from raw-content hosts, a size profile consistent with dead-drop config rather than source/binary content
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any ("raw.githubusercontent.com", "gist.githubusercontent.com")
| where isnotempty(ResponseBodySizeInBytes)
| where ResponseBodySizeInBytes < 1024
| summarize HitCount = count(), Urls = make_set(RemoteUrl, 20), FirstSeen = min(Timestamp), LastSeen = max(Timestamp) by DeviceName, InitiatingProcessFileName
| sort by FirstSeen asc

Hunting — SPL

spl

index=proxy ("raw.githubusercontent.com" OR "gist.githubusercontent.com")
| eval resp_bytes=tonumber(sc_bytes)
| where resp_bytes < 1024 AND resp_bytes > 0
| stats count as HitCount, values(cs_uri_stem) as Urls, min(_time) as FirstSeen, max(_time) as LastSeen by c_ip, cs_user_agent
| eval FirstSeen=strftime(FirstSeen, "%Y-%m-%d %H:%M:%S"), LastSeen=strftime(LastSeen, "%Y-%m-%d %H:%M:%S")
| sort FirstSeen

Atomic Red Team Tests

Test 1 Fetch Encoded Config from a GitHub Raw Content URL via PowerShell, Then Connect (Windows)

windows

Simulates the core two-stage pattern: PowerShell fetches a small base64 string from a raw.githubusercontent.com URL using Invoke-WebRequest (a non-browser client), decodes it locally, and immediately opens a new TCP connection to the decoded (attacker-controlled test) address. Use a raw file you control in a scratch repository/gist containing only a harmless base64 string, and point the decoded connection at a benign test listener you control — never at a real third party.

Command

powershell

$raw = Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/<your-test-org>/<your-test-repo>/main/config.txt' -UseBasicParsing
$decoded = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($raw.Content.Trim()))
Write-Host "Decoded dead-drop content: $decoded"
$parts = $decoded -split ':'
Test-NetConnection -ComputerName $parts[0] -Port ([int]$parts[1]) | Out-Null
Write-Host 'GitHub raw dead-drop fetch-then-connect test complete'

Cleanup

powershell

Remove-Variable raw, decoded, parts -ErrorAction SilentlyContinue

Expected Telemetry

MDE DeviceNetworkEvents / Sysmon Event ID 22: a DNS/HTTP access to raw.githubusercontent.com initiated by powershell.exe. Within seconds, a second network event (Sysmon Event ID 3 / MDE ConnectionSuccess) shows powershell.exe connecting to the decoded test destination and port.

Expected Detection

The KQL rule's ConfigFetch arm matches the powershell.exe access to the raw-content URL, and the NovelConnections arm matches the immediate follow-on connection provided the test destination has not been contacted by the host in the prior 15 days — use a fresh, never-before-contacted test listener to guarantee this. The two arms join on DeviceId within the 15-minute correlation window and the rule fires. The SPL transaction-based rule fires equivalently on the DNS-query-then-connect pair.

Test 2 Fetch Config from a Gist Raw URL via curl, Then Connect (Linux)

linux

Simulates the same pattern on Linux using curl (a non-browser HTTP client) against a gist.githubusercontent.com raw URL, followed by a netcat connection to the decoded test address. Use a gist you control containing only a benign hex-encoded string.

Command

bash

raw=$(curl -s 'https://gist.githubusercontent.com/<your-test-user>/<gist-id>/raw/config.txt')
decoded=$(echo "$raw" | xxd -r -p)
host=$(echo "$decoded" | cut -d: -f1)
port=$(echo "$decoded" | cut -d: -f2)
timeout 5 bash -c "cat < /dev/null > /dev/tcp/${host}/${port}" 2>/dev/null || true
echo 'Gist raw dead-drop fetch-then-connect test complete'

Cleanup

bash

unset raw decoded host port

Expected Telemetry

EDR-for-Linux process and network telemetry: curl execution reaching gist.githubusercontent.com, followed within seconds by a new outbound TCP connection from the same shell session to the decoded test host and port.

Expected Detection

The KQL/EQL correlated rules fire on the fetch-then-connect pair from the same DeviceId/host.id within the 15-minute window, provided the test destination is genuinely new to the host. This test also exercises the Elastic EQL sequence rule's dns-then-network correlation.

Test 3 Benign Raw-Content Fetch with No Follow-On Connection, Negative Control (Windows)

windows

Fetches the same raw.githubusercontent.com URL via PowerShell but performs no subsequent network activity, validating that Arm 1 alone (without a correlated novel connection) does not trigger the primary correlated detection and only surfaces in the broader baseline hunting query.

Command

powershell

Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/<your-test-org>/<your-test-repo>/main/config.txt' -UseBasicParsing | Out-Null
Start-Sleep -Seconds 60
Write-Host 'Negative control fetch-only test complete'

Cleanup

powershell

None required.

Expected Telemetry

A single DeviceNetworkEvents/Sysmon Event ID 22 record for the raw.githubusercontent.com access from powershell.exe, with no accompanying new outbound connection in the following 15 minutes.

Expected Detection

The correlated KQL/SPL/EQL rules should NOT fire, since the NovelConnections/endswith arm never materialises. The event should appear only in the fleet-wide baseline hunting query, confirming the primary rule's correlation requirement is functioning as a noise-reduction control rather than alerting on the fetch alone.

Related Detections

What is THREAT-C2-GitHubRawContentDeadDropResolver Command and Control Configuration Resolution via GitHub/Gist Raw Content Dead Drop?

MITRE ATT&CK

Data Sources

Required Tables

False Positives

Data Sources

Required Sourcetypes

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Data Sources

Required Tables

False Positives

Sigma rule & cross-platform mapping

Platform-specific guides for THREAT-C2-GitHubRawContentDeadDropResolver

Testing Methodology

Response Playbook

Triage

Containment

Evidence Collection

Escalation Criteria

Investigation Guide

Forensic Artifacts

Tuning Guidance

Hunting Queries

Atomic Red Team Tests

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Command

Cleanup

Expected Telemetry

Expected Detection

Related Detections

Tactic Hub

Parent Technique

Related Techniques

Same Tactic: Command and Control

Popular Detections

Get new detections in your inbox