GitHub pull_request_target Workflow on Self-Hosted Runner

Severity: high
Time window: 90m
Match by: workflow_job.run_id, workflow_run.id
Tags: CI/CD, Workflow, Supply Chain, Self-Hosted, Infrastructure Compromise
Reference: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#hardening-for-self-hosted-runners
Source: github.com/panther-labs/panther-analysis

Detects when a pull_request_target workflow runs on a self-hosted runner. pull_request_target workflows run with elevated privileges and have access to repository secrets even when triggered by external contributors from forks. When these workflows run on self-hosted runners attackers can gain direct code execution on the underlying infrastructure with potential access to internal network, databases, and systems. Unlike GitHub-hosted runners which are destroyed after each job, self-hosted runners persist and can be permanently compromised. This pattern is high risk regardless of whether the PR is cross-fork or same-repository because self-hosted runners represent infrastructure access. GitHub explicitly warns never to use self-hosted runners with public repositories or workflows that can be triggered by untrusted contributors. This configuration allows any GitHub user with read access to your repository to execute arbitrary code on your infrastructure.

MITRE ATT&CK coverage

Tactic	Techniques
Initial Access	`T1195.002` Supply Chain Compromise: Compromise Software Supply Chain
Execution	`T1072` Software Deployment Tools
Privilege Escalation	`T1134` Access Token Manipulation
Lateral Movement	`T1021` Remote Services, `T1072` Software Deployment Tools

Rule body yaml

AnalysisType: correlation_rule
RuleID: "GitHub.PullRequestTarget.WITH.SelfHostedRunner"
DisplayName: "GitHub pull_request_target Workflow on Self-Hosted Runner"
Enabled: true
Severity: High
Tags:
  - CI/CD
  - Workflow
  - Supply Chain
  - Self-Hosted
  - Infrastructure Compromise
Reports:
  MITRE ATT&CK:
    - TA0001:T1195.002  # Supply Chain Compromise: Compromise Software Supply Chain
    - TA0002:T1072  # Execution: Software Deployment Tools
    - TA0008:T1021  # Lateral Movement: Remote Services
    - TA0004:T1134  # Privilege Escalation: Access Token Manipulation
Description: >
  Detects when a pull_request_target workflow runs on a self-hosted runner. pull_request_target workflows
  run with elevated privileges and have access to repository secrets even when triggered by external contributors from forks.
  When these workflows run on self-hosted runners attackers can gain direct code execution on the underlying infrastructure 
  with potential access to internal network, databases, and systems. Unlike GitHub-hosted runners which are destroyed after each job, 
  self-hosted runners persist and can be permanently compromised. This pattern is high risk regardless of whether the PR
  is cross-fork or same-repository because self-hosted runners represent infrastructure access.
  GitHub explicitly warns never to use self-hosted runners with public repositories or workflows
  that can be triggered by untrusted contributors. This configuration allows any GitHub user with
  read access to your repository to execute arbitrary code on your infrastructure.
Runbook: |
  1. Stop the self-hosted runner:
     - SSH/access the runner system
     - Stop the runner service or unregister the runner

  2. Isolate the runner from network:
     - Block outbound connections via firewall
     - Disconnect from internal network if possible

  3. Review the workflow:
     - Disable or delete the workflow file that uses pull_request_target + self-hosted
     - Or modify to use "runs-on: ubuntu-latest"

  4. Check runner system for compromise:
     - Review auth logs for unauthorized access
     - Check network connections: netstat -tunap | grep ESTABLISHED
     - Look for persistence mechanisms (cron, systemd, rc.local)
     - Check for suspicious processes or files
     - Review bash history for malicious commands

  5. Review recent workflow runs:
     - Check all workflows that ran on this runner in past 7 days
     - Look for other suspicious activity
     - Identify if compromise occurred in previous runs

  6. Search for indicators of compromise:
     - Outbound connections to suspicious IPs/domains
     - New user accounts or SSH keys on runner system
     - Modified system files or configurations
     - Cryptocurrency miners or backdoors
     - Data staging areas or compressed archives
Reference: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#hardening-for-self-hosted-runners
Detection:
  - Group:
      - ID: PullRequestTarget
        RuleID: GitHub.Webhook.PullRequestTargetUsage
      - ID: SelfHostedRunner
        RuleID: GitHub.Webhook.SelfHostedRunnerUsed
    MatchCriteria:
      field_name:
        - GroupID: PullRequestTarget
          Match: workflow_run.id
        - GroupID: SelfHostedRunner
          Match: workflow_job.run_id
    EventEvaluationOrder: Chronological
    LookbackWindowMinutes: 90
    Schedule:
      RateMinutes: 60
      TimeoutMinutes: 10
Tests:
  - Name: pull_request_target with self-hosted runner
    ExpectedResult: true
    RuleOutputs:
      - ID: PullRequestTarget
        Matches:
          workflow_run.id:
            "12345678":
              - "2025-10-15T18:31:00Z"
      - ID: SelfHostedRunner
        Matches:
          workflow_job.run_id:
            "12345678":
              - "2025-10-15T18:31:06Z"

  - Name: pull_request_target without self-hosted runner
    ExpectedResult: false
    RuleOutputs:
      - ID: PullRequestTarget
        Matches:
          workflow_run.id:
            "12345678":
              - "2025-10-15T18:31:00Z"

  - Name: Self-hosted runner without pull_request_target
    ExpectedResult: false
    RuleOutputs:
      - ID: SelfHostedRunner
        Matches:
          workflow_job.run_id:
            "12345678":
              - "2025-10-15T18:31:06Z"

  - Name: pull_request_target and self-hosted in different workflows
    ExpectedResult: false
    RuleOutputs:
      - ID: PullRequestTarget
        Matches:
          workflow_run.id:
            "12345678":
              - "2025-10-15T18:31:00Z"
      - ID: SelfHostedRunner
        Matches:
          workflow_job.run_id:
            "87654321":
              - "2025-10-15T18:31:06Z"

  - Name: Multiple self-hosted jobs in same pull_request_target workflow
    ExpectedResult: true
    RuleOutputs:
      - ID: PullRequestTarget
        Matches:
          workflow_run.id:
            "12345678":
              - "2025-10-15T18:31:00Z"
      - ID: SelfHostedRunner
        Matches:
          workflow_job.run_id:
            "12345678":
              - "2025-10-15T18:31:06Z"
              - "2025-10-15T18:32:00Z"

Detection logic

Stage 1: `step PullRequestTarget`

References detection GitHub.Webhook.PullRequestTargetUsage.

Stage 2: `step SelfHostedRunner`

References detection GitHub.Webhook.SelfHostedRunnerUsed.

`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 pull_request_target Workflow on Self-Hosted Runner

MITRE ATT&CK coverage

Rule body yaml

Detection logic

Stage 1: `step PullRequestTarget`

Stage 2: `step SelfHostedRunner`

Keyboard shortcuts

Search operators

GitHub pull_request_target Workflow on Self-Hosted Runner

MITRE ATT&CK coverage

Rule body yaml

Detection logic

Stage 1: step PullRequestTarget

Stage 2: step SelfHostedRunner

Stage 1: `step PullRequestTarget`

Stage 2: `step SelfHostedRunner`