GitHub Workflow File Creation or Modification

Status: production
Group by: CreationUtcTime, computer_name, event_action, file_access_time, file_acl, file_hash, file_modify_time, file_name, file_size, process_guid, process_id, target_filename, user, vendor_product
Author: Michael Haag, Splunk
Source: github.com/splunk/security_content

The following analytic hunts for any creations or modifications to GitHub Actions workflow YAML files across the organization's Linux or Windows endpoints. This hunting query tracks all workflow file activity under .github/workflows directories to help defenders establish baselines of legitimate CI/CD workflow creation patterns, identify unusual or unauthorized changes, and detect anomalies that may indicate supply chain compromise. GitHub Actions workflows execute with privileged access to secrets and deployment credentials, making them high-value targets for attackers. By monitoring workflow file modifications over time, defenders can identify suspicious patterns such as unexpected workflow creation on developer workstations, modifications outside normal change windows, or activity in repositories that don't typically contain workflows. This data is essential for detecting supply chain attacks like Shai-Hulud that inject malicious workflows across multiple repositories.

MITRE ATT&CK coverage

Tactic	Techniques
Initial Access	`T1195` Supply Chain Compromise
Execution	`T1574.006` Hijack Execution Flow: Dynamic Linker Hijacking
Persistence	`T1554` Compromise Host Software Binary
Stealth	`T1574.006` Hijack Execution Flow: Dynamic Linker Hijacking

Event coverage

Provider	Event	Title
Sysmon	Event ID 11	FileCreate

Rule body splunk

name: GitHub Workflow File Creation or Modification
id: 2a9f3a2e-2c07-4c5f-9e42-8f8f0b6b6a12
version: 2
creation_date: '2025-11-25'
modification_date: '2026-05-13'
author: Michael Haag, Splunk
status: production
type: Hunting
description: |
    The following analytic hunts for any creations or modifications to GitHub Actions workflow YAML files across the organization's Linux or Windows endpoints.
    This hunting query tracks all workflow file activity under .github/workflows directories to help defenders establish baselines of legitimate CI/CD workflow creation patterns, identify unusual or unauthorized changes, and detect anomalies that may indicate supply chain compromise.
    GitHub Actions workflows execute with privileged access to secrets and deployment credentials, making them high-value targets for attackers.
    By monitoring workflow file modifications over time, defenders can identify suspicious patterns such as unexpected workflow creation on developer workstations, modifications outside normal change windows, or activity in repositories that don't typically contain workflows.
    This data is essential for detecting supply chain attacks like Shai-Hulud that inject malicious workflows across multiple repositories.
data_source:
    - Sysmon for Linux EventID 11
    - Sysmon EventID 11
search: |
    | tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime
    
    from datamodel=Endpoint.Filesystem where
    
    Filesystem.file_path IN (
      "*/.github/workflows/*.yaml",
      "*/.github/workflows/*.yml",
      "*\\.github\\workflows\\*.yaml",
      "*\\.github\\workflows\\*.yml"
    )
    
    by Filesystem.action Filesystem.dest Filesystem.file_access_time Filesystem.file_create_time
       Filesystem.file_hash Filesystem.file_modify_time Filesystem.file_name Filesystem.file_path Filesystem.file_acl Filesystem.file_size Filesystem.process_guid Filesystem.process_id Filesystem.user
       Filesystem.vendor_product
    
    | `drop_dm_object_name(Filesystem)`
    | `security_content_ctime(firstTime)`
    | `security_content_ctime(lastTime)`
    | `github_workflow_file_creation_or_modification_filter`
how_to_implement: |
    The detection is based on data that originates from Endpoint Detection
    and Response (EDR) agents. These agents are designed to provide security-related
    telemetry from the endpoints where the agent is installed. To implement this search,
    you must ingest logs that contain filesystem events, specifically file creation
    events. These logs must be processed using the appropriate Splunk Technology Add-ons
    that are specific to the EDR product. The logs must also be mapped to the `Filesystem`
    node of the `Endpoint` data model. Use the Splunk Common Information Model (CIM)
    to normalize the field names and speed up the data modeling process.
known_false_positives: |
    Legitimate engineering activity regularly creates workflow YAMLs. Suppress by repository path allowlisting, CI hosts, change windows, or approval timeframes.
references:
    - https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
    - https://securelist.com/shai-hulud-worm-infects-500-npm-packages-in-a-supply-chain-attack/117547/
    - https://github.com/SigmaHQ/sigma/pull/5658/files
    - https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
analytic_story:
    - NPM Supply Chain Compromise
asset_type: Endpoint
mitre_attack_id:
    - T1574.006
    - T1554
    - T1195
product:
    - Splunk Enterprise
    - Splunk Enterprise Security
    - Splunk Cloud
category: endpoint
security_domain: endpoint
tests:
    - name: True Positive Test - Linux
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1195.001/npm/workflow_yml_sysmon.log
          source: Syslog:Linux-Sysmon/Operational
          sourcetype: sysmon:linux
      test_type: unit
    - name: True Positive Test - Windows
      attack_data:
        - data: https://media.githubusercontent.com/media/splunk/attack_data/master/datasets/attack_techniques/T1195.001/npm/windows_workflow_sysmon.log
          source: XmlWinEventLog:Microsoft-Windows-Sysmon/Operational
          sourcetype: XmlWinEventLog
      test_type: unit

Stages and Predicates

Stage 1: `tstats`

| tstats `security_content_summariesonly` count min(_time) as firstTime max(_time) as lastTime

from datamodel=Endpoint.Filesystem where

Filesystem.file_path IN (
  "*/.github/workflows/*.yaml",
  "*/.github/workflows/*.yml",
  "*\\.github\\workflows\\*.yaml",
  "*\\.github\\workflows\\*.yml"
)

by Filesystem.action Filesystem.dest Filesystem.file_access_time Filesystem.file_create_time
   Filesystem.file_hash Filesystem.file_modify_time Filesystem.file_name Filesystem.file_path Filesystem.file_acl Filesystem.file_size Filesystem.process_guid Filesystem.process_id Filesystem.user
   Filesystem.vendor_product

Stage 2: `search`

| `drop_dm_object_name(Filesystem)`

Stage 3: `search`

| `security_content_ctime(firstTime)`

Stage 4: `search`

| `security_content_ctime(lastTime)`

Stage 5: `search`

| `github_workflow_file_creation_or_modification_filter`

Indicators

Each row is a field, operator, and value that the rule matches. The corpus column counts how many other rules in the catalog look for the same combination: high numbers point to widely-used, community-vetted indicators. Blank or 1 shows that the indicator is specific to this rule.

Field	Kind	Values
`Filesystem.file_path`	in	`"/.github/workflows/.yaml"` `"/.github/workflows/.yml"` `"\\.github\\workflows\\.yaml"` `"\\.github\\workflows\\.yml"`

`j` / `k`	Scroll down / up
`d` / `u`	Half-page down / up
`gg` / `G`	Top / bottom
`h` / `l`	History back / forward
`f`	Follow link (`Shift` = new tab)
`/`	Focus search
`?`	Toggle this help
`↑` / `↓`	Navigate search results
`Enter`	Open highlighted result
`Esc`	Close results / dialog

`type:`	`events` / `rules` / `providers`
`vendor:`	`sigma` / `elastic` / `splunk` / `kusto` / `chronicle` (vendor name alone also works: `sigma:`, `kql:`, `secops:`…)
`tactic:`	TA-id, slug, or name: `credential_access`, `TA0006`
`technique:`	technique or sub-technique ID: `T1003`, `T1003.001` (alias `tech:`)
`severity:`	`critical` / `high` / `medium` / `low` / `informational` (alias `sev:`)
`risk_score`	Numeric comparison on the Elastic risk score (0 to 100): `risk_score>50`, `risk_score<=20`, `risk_score=99` (alias `risk`; Elastic rules only)
`stages:`	Rules with exactly N pipeline stages
`correlation:`	`single_event` / `sequence` / `alternatives` / `alternatives_cross_log` / `all_required` / `correlated`
`with:`	Co-occurrence event-id; stacks (`with:4624 with:4769`) to require all, while a comma list in one occurrence (`with:4624,4769`) is an either-or group. Implies multi-event
`like:`	Structural neighbors of a rule slug (equivalents + subsumption stricter / broader): `like:comsvcs_lsass_memory_dump-splunk-sysmon`
`groupby:`	Entity-grouping substring match against `group_by_keys`: `groupby:user`, `groupby:host`
`uses:`	Rules whose predicate tree touches the field (any kind, any value): `uses:CommandLine`
`excludes:`	Rules with top-level `not()` clauses on the field (FP whitelists): `excludes:ParentImage`
`field:` / `value:`	Predicate search; narrows rule cards to those with a matching leaf and drives the indicator tier. Unquoted = substring, wildcards allowed (`value:mimikatz`)
`indicator:`	Shorthand for `field:F value:V`: `indicator:Image=*\powershell.exe`
`kind:`	Filter by predicate kind. Narrows rule cards to those carrying a matching predicate leaf (`vendor:elastic kind:cidr_match`) and drives the indicator tier: `contains` / `starts_with` / `ends_with` / `regex` / `cidr` / `eq` / `in` … (operator aliases `op:`/`match:`)
`has:` / `no:`	`sample`, `field`, `notes`, `refs`, `trace`, `thirdparty`, `rule`, `pattern`, `timewindow`, `threshold`, `newterms`, `sigma`/`elastic`/`splunk`/`kusto`/`chronicle`
`-op:val`	Exclude matches; works on most operators but not `type:`/`like:`/`has:`/`no:` (use `no:<flag>` to exclude a rule flag): `tactic:execution -vendor:splunk`. Standalone `-kind:`/`-field:`/`-value:` drop every rule carrying a matching predicate leaf (`type:rules -kind:is_null`)
`field:"…"` / `value:"…"`	Quoted value = anchored exact match (also allows spaces): `value:"net user"`
`a,b`	Comma = OR inside one operator (`vendor:sigma,elastic`, `severity:high,critical`); repeating a facet merges the same way. `field:`/`value:` never split (literal commas)
`vendors:` / `stage:`	Singular and plural spellings fold to the canonical operator and value: `tactics:` = `tactic:`, `type:event` = `type:events`, `correlation:sequences` = `correlation:sequence`, `has:thresholds` = `has:threshold`
`"quoted phrase"`	Exact-match a multi-word phrase (free text)

GitHub Workflow File Creation or Modification

MITRE ATT&CK coverage

Event coverage

Rule body splunk

Stages and Predicates

Stage 1: `tstats`

Stage 2: `search`

Stage 3: `search`

Stage 4: `search`

Stage 5: `search`

Indicators

Keyboard shortcuts

Search operators

GitHub Workflow File Creation or Modification

MITRE ATT&CK coverage

Event coverage

Rule body splunk

Stages and Predicates

Stage 1: tstats

Stage 2: search

Stage 3: search

Stage 4: search

Stage 5: search

Indicators

Stage 1: `tstats`

Stage 2: `search`

Stage 3: `search`

Stage 4: `search`

Stage 5: `search`