← Back to Cybersecurity News Center
Severity
CRITICAL
CVSS
9.5
Priority
0.850
×
Tip
Pick your view
Analyst for full detail, Executive for the short version.
Analyst
Executive
Executive Summary
Threat actors redirected all version tags for two widely-used GitHub Actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, to malicious commits, causing any CI/CD pipeline referencing those actions by tag to automatically execute attacker-controlled code. The payload actively exfiltrates CI/CD secrets, credentials, and tokens to an attacker-controlled domain. The same infrastructure connects to the 'Mini Shai-Hulud' npm supply chain campaign, attributed to TeamPCP with high confidence per Wiz research, confirming a coordinated, multi-ecosystem operation that puts software build pipelines and everything they touch at direct risk of compromise.
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
CRITICAL
Critical severity — immediate action required
Actor Attribution
HIGH
TeamPCP
TTP Sophistication
HIGH
8 MITRE ATT&CK techniques identified
Detection Difficulty
HIGH
Multiple evasion techniques observed
Target Scope
INFO
GitHub Actions: actions-cool/issues-helper (all tag-referenced versions), actions-cool/maintain-one-comment (all tag-referenced versions); npm @antv ecosystem packages (scope per Mini Shai-Hulud campaign)
Are You Exposed?
⚠
Your industry is targeted by TeamPCP → Heightened risk
⚠
You use products/services from GitHub Actions: actions-cool/issues-helper (all tag-referenced versions) → Assess exposure
⚠
8 attack techniques identified — review your detection coverage for these TTPs
✓
Your EDR/XDR detects the listed IOCs and TTPs → Reduced risk
✓
You have incident response procedures for this threat type → Prepared
Assessment estimated from severity rating and threat indicators
Business Context
If your software development pipelines used these GitHub Actions, attackers may have already obtained the credentials your build systems use to deploy software, publish packages, and access cloud infrastructure — giving them the ability to push malicious code into your products or move laterally into your cloud environment. A successful downstream compromise could disrupt software releases, expose customer data, or result in malicious code shipping to your customers, creating liability under data protection regulations and significant reputational damage. The coordinated, multi-ecosystem nature of this campaign — spanning both GitHub Actions and npm — indicates a threat actor actively targeting developer infrastructure, not opportunistic scanning.
You Are Affected If
Your repositories contain workflow files (.github/workflows/*.yml) that reference actions-cool/issues-helper or actions-cool/maintain-one-comment by mutable tag rather than a pinned commit SHA
Those workflows ran after the tags were redirected (approximately May 2026 — verify exact compromise window against current advisories)
CI/CD secrets, cloud provider credentials, API tokens, or npm publish tokens were available as environment variables or GitHub Actions secrets in those workflow runs
Your organization uses npm packages within the @antv scope and has not audited those dependencies against the Mini Shai-Hulud advisory
You have not yet rotated credentials accessible to affected workflow runs
Board Talking Points
Attackers hijacked tools used inside our software build systems to steal the credentials that control how we deploy and publish software.
We are auditing all affected pipelines and rotating compromised credentials now — full remediation requires pinning all third-party build tools to verified versions, which we are implementing this week.
If we do not act, attackers retaining stolen credentials could push malicious code into our products or access cloud systems without triggering standard authentication controls.
Technical Analysis
TeamPCP compromised actions-cool/issues-helper and actions-cool/maintain-one-comment by force-pushing malicious commits and reassigning all existing mutable Git tags to those commits.
Any workflow referencing these actions by tag (e.g., @v3, @latest), rather than a pinned commit SHA, executed the malicious payload on its next scheduled or triggered run.
The payload performs credential exfiltration (T1552.001 ) via outbound data transfer (T1041 , T1567 ) to an attacker-controlled domain, targeting CI/CD secrets, API tokens, and environment variables.
No CVE has been assigned because this attack exploits Git's mutable tag architecture (a design characteristic), not a patched vulnerability or code flaw. Remediation is architectural (SHA pinning), not a patch deployment. Relevant CWEs: CWE-829 (Inclusion of Functionality from Untrusted Control Sphere), CWE-312 (Cleartext Storage of Sensitive Information), CWE-494 (Download of Code Without Integrity Check). MITRE techniques include T1195.001 (Supply Chain Compromise: Compromise Software Dependencies), T1078.004 (Valid Accounts: Cloud Accounts), T1059 /T1059.007 (Command and Scripting Interpreter: JavaScript), and T1553 (Subvert Trust Controls). The exfiltration infrastructure overlaps with the Mini Shai-Hulud campaign targeting the @antv npm scope (per Wiz research), indicating shared tooling or operator overlap within TeamPCP. No patch exists, remediation is architectural: pin all Actions to verified commit SHAs. Affected scope: all tag-referenced versions of both actions; any npm @antv packages in scope of the parallel campaign.
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to CISO, legal counsel, and potentially affected cloud/registry providers immediately if forensic review of GitHub Actions runner logs or cloud IAM audit trails confirms that GITHUB_TOKEN, AWS access keys, npm publish tokens, or other credentials were read by the malicious actions-cool payload and subsequently used outside of expected CI/CD activity — this constitutes confirmed credential exfiltration and may trigger breach notification obligations if the pipeline had access to customer data, PII, or regulated environments.
1
Step 1: Containment — Audit all .github/workflows/*.yml files across every repository for references to actions-cool/issues-helper or actions-cool/maintain-one-comment by mutable tag. Disable any workflow referencing these actions by tag until SHA pinning is confirmed. Treat all secrets accessible in affected runs as compromised and initiate rotation immediately. (Cite: NIST AC-20 — Use Of External Systems; NIST AC-6 — Least Privilege; CIS 2.3 — Address Unauthorized Software; D3-UAP — User Account Permissions)
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy
NIST IR-4 (Incident Handling)
NIST CM-2 (Baseline Configuration)
NIST SI-7 (Software, Firmware, and Information Integrity)
CIS 2.3 (Address Unauthorized Software)
CIS 4.6 (Securely Manage Enterprise Assets and Software)
Compensating Control
Run this one-liner across all repos to enumerate affected workflow files immediately: grep -r 'actions-cool/issues-helper\|actions-cool/maintain-one-comment' .github/workflows/ --include='*.yml' -l. For orgs with many repos, use the GitHub CLI: gh repo list YOUR-ORG --limit 1000 --json name -q '.[].name' | xargs -I{} sh -c 'gh api repos/YOUR-ORG/{}/contents/.github/workflows --jq ".[].name" 2>/dev/null | xargs -I%% gh api repos/YOUR-ORG/{}/contents/.github/workflows/%% --jq ".content" | base64 -d | grep -l actions-cool'. Disable affected workflows immediately by renaming the .yml extension to .yml.disabled via git commit to main, or set branch protection rules to require SHA review before re-enabling.
Preserve Evidence
Before disabling any workflow, capture the following: (1) Full text of each affected .github/workflows/*.yml file — screenshot or git-export to preserve the mutable tag reference (e.g., uses: actions-cool/issues-helper@v3) that was in place at time of compromise. (2) GitHub Actions run history for each affected repo via the GitHub UI or API: GET /repos/{owner}/{repo}/actions/runs — capture run IDs, triggered timestamps, triggering actor, and conclusion status for all runs after approximately May 1, 2026. (3) The malicious commit SHA that tags were redirected to — retrieve via: git ls-remote https://github.com/actions-cool/issues-helper.git 'refs/tags/*' and compare against known-good SHAs documented in public disclosures. Preserve this as the attacker-controlled commit reference before GitHub potentially remediates the repo.
2
Step 2: Detection — Review GitHub Actions run logs for jobs invoking the affected actions. On self-hosted runners, examine outbound network connections during workflow execution windows for calls to unrecognized domains. Query the GitHub audit log for workflow_run events tied to these actions. Cross-reference secrets access events with cloud provider IAM logs for API calls from CI/CD service accounts at anomalous times or from unexpected source IPs. (Cite: NIST AU-6 — Audit Record Review, Analysis, And Reporting; NIST AU-2 — Event Logging; NIST AU-3 — Content Of Audit Records; CIS 8.2 — Collect Audit Logs; D3-LAM — Local Account Monitoring; D3-SFA — System File Analysis)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis
NIST IR-5 (Incident Monitoring)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST AU-12 (Audit Record Generation)
NIST SI-4 (System Monitoring)
CIS 8.2 (Collect Audit Logs)
Compensating Control
For teams without SIEM: (1) Pull raw GitHub Actions logs per run via GitHub CLI: gh run view RUN_ID --log > run_RUN_ID.log, then grep for 'curl\|wget\|http\|GITHUB_TOKEN\|AWS_\|SECRET' across all captured logs. (2) If runners are self-hosted, review /var/log/syslog or journalctl output on runner hosts for outbound TCP connections during the window of suspect runs; use tcpdump -i any -w capture.pcap 'not port 22' if active runner traffic can be replicated. (3) For AWS IAM: run aws cloudtrail lookup-events --lookup-attributes AttributeKey=Username,AttributeValue=CICD-SERVICE-ACCOUNT-NAME --start-time 2026-05-01 to surface API calls made under pipeline credentials. (4) For npm publish token abuse tied to Mini Shai-Hulud/TeamPCP: check npm audit log at ~/.npm/_logs/ and query the npm registry for unexpected publish events under your org scope.
Preserve Evidence
Capture these artifacts before any log rotation occurs: (1) Full GitHub Actions runner logs for every run of affected workflows — these are available for 90 days by default and contain stdout/stderr of every step, including any curl/wget exfiltration commands executed by the malicious actions-cool payload. (2) GitHub Actions environment variable exposure events: in runner logs, search for lines matching 'echo ::add-mask::' (legitimate masking) vs. unmasked variable prints or 'env' command output that would reveal GITHUB_TOKEN, AWS credentials, or npm tokens to the attacker's step. (3) DNS query logs from your corporate resolver or cloud DNS (Route 53 Resolver Query Logs, Cloudflare Gateway) for queries to attacker-controlled exfiltration domains from runner IP ranges during the exposure window — this is the primary network indicator of successful exfiltration. (4) Cloud provider IAM access logs (AWS CloudTrail, GCP Audit Logs, Azure Activity Log) filtered on the service account identity used by CI/CD runners, looking for API calls to sensitive services (S3 GetObject, secretsmanager:GetSecretValue, iam:CreateAccessKey) timestamped concurrently with suspect workflow runs. (5) npm registry publish logs for packages under your org scope — unexpected publishes during the exposure window indicate the attacker leveraged an npm publish token obtained via the TeamPCP/Mini Shai-Hulud payload.
3
Step 3: Eradication — Replace all mutable tag references (e.g., @v3, @latest) with pinned commit SHAs verified against the known-good state of each action's repository. Rotate all secrets, tokens, API keys, and credentials accessible in any affected workflow environment, including GitHub Actions secrets, cloud provider access keys, and npm publish tokens. Revoke any access tokens showing anomalous usage. (Cite: NIST AC-2 — Account Management; NIST AC-3 — Access Enforcement; CIS 4.6 — Securely Manage Enterprise Assets and Software; CIS 6.2 — Establish an Access Revoking Process; D3-CRO — Credential Rotation; D3-CH — Credential Hardening)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication
NIST IR-4 (Incident Handling)
NIST SI-2 (Flaw Remediation)
NIST IA-5 (Authenticator Management)
NIST CM-2 (Baseline Configuration)
CIS 5.2 (Use Unique Passwords)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 7.2 (Establish and Maintain a Remediation Process)
Compensating Control
SHA pinning procedure for a 2-person team: (1) Resolve the known-good SHA for each action: git ls-remote https://github.com/actions-cool/issues-helper.git HEAD — use only SHAs documented in the vendor's official advisory or pinned to a pre-compromise tag. (2) Replace all instances of 'uses: actions-cool/issues-helper@v3' with 'uses: actions-cool/issues-helper@SHA256HASH' in every .yml file. Use sed -i 's|actions-cool/issues-helper@v[0-9]*|actions-cool/issues-helper@VERIFIED_SHA|g' .github/workflows/*.yml for bulk replacement. (3) Credential rotation sequence — GitHub secrets: Settings > Secrets > delete and recreate each secret; AWS: aws iam create-access-key then aws iam delete-access-key for old key; npm: npm token revoke TOKEN_ID then npm token create --read-only or --automation as appropriate. (4) Use StepSecurity's free Action pinning tool (app.stepsecurity.io/securerepo) to automate SHA pinning PRs across repos without enterprise tooling budget.
Preserve Evidence
Preserve before rotating credentials: (1) Screenshot or export of all GitHub Actions secrets names (not values — GitHub never exposes secret values in UI) from Settings > Secrets > Actions for each affected repo — this documents the blast radius of what was accessible to the malicious action. (2) AWS IAM credential report (aws iam generate-credential-report && aws iam get-credential-report) run before key rotation to establish a baseline of key age, last-used timestamps, and access patterns for the compromised service account keys. (3) List of all npm tokens associated with your org's publish scope before revocation: npm token list — capture token IDs and creation dates as evidence of the pre-incident authentication state. (4) Git log of the malicious commit the tags were redirected to, captured via git log --format='%H %an %ae %ai %s' on the actions-cool repos before any remediation by the vendor — this establishes the attacker-controlled code version that executed in your pipeline.
4
Step 4: Recovery — After rotating credentials, re-run affected workflows under controlled conditions and confirm expected behavior. Validate that all workflow files reference pinned commit SHAs. Monitor CI/CD pipeline logs and cloud IAM audit logs for 30 days post-remediation for anomalous access patterns. Confirm no unauthorized packages were published to registries under your organization's scope during the exposure window. (Cite: NIST AU-6 — Audit Record Review, Analysis, And Reporting; NIST AU-11 — Audit Record Retention; NIST AC-3 — Access Enforcement; CIS 8.2 — Collect Audit Logs; D3-LAM — Local Account Monitoring)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery
NIST IR-4 (Incident Handling)
NIST SI-7 (Software, Firmware, and Information Integrity)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST AU-11 (Audit Record Retention)
CIS 7.3 (Perform Automated Operating System Patch Management)
CIS 7.4 (Perform Automated Application Patch Management)
Compensating Control
For controlled workflow re-execution: trigger affected workflows manually in a non-production fork first using 'workflow_dispatch' with the pinned SHA in place, and verify the actions-cool steps complete without outbound network calls to non-GitHub domains by reviewing the raw runner log output. For npm registry validation: run npm search --scope=@YOUR-ORG and cross-reference publish timestamps against your release history — any package with a publish date during the exposure window and no corresponding internal release ticket is a suspected unauthorized publish. For 30-day monitoring without SIEM, set up a daily cron job to pull AWS CloudTrail events for the new service account keys: aws cloudtrail lookup-events --start-time $(date -d '1 day ago' +%Y-%m-%dT%H:%M:%S) --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=NEW_KEY_ID >> /var/log/cicd-audit.log.
Preserve Evidence
Before declaring recovery complete: (1) Diff of all .github/workflows/*.yml files showing before/after state — mutable @v3 tags replaced with explicit commit SHAs — committed to the repo's git history as a permanent audit record. (2) GitHub Actions run summary for the first post-remediation execution of each previously-affected workflow, confirming the SHA-pinned action resolved correctly and no unexpected steps or network calls appeared. (3) npm registry publish history for your org's @antv-scope or equivalent packages for the full exposure window — retrieve via: npm view @YOUR-SCOPE/PACKAGE-NAME time --json — to confirm no unauthorized versions were published under your credentials. (4) Cloud IAM access review confirming the old compromised keys show 'N/A' or pre-rotation last-used timestamps and the new keys' first-use timestamps align with expected post-rotation pipeline runs.
5
Step 5: Post-Incident — Implement a policy requiring all third-party GitHub Actions to be pinned by commit SHA, enforced via automated tooling (e.g., OpenSSF Scorecards, StepSecurity Harden-Runner, or Dependabot for Actions). Add workflow file scanning to your CI/CD pipeline to flag mutable tag references before merge. Audit npm dependencies for @antv scope packages per the Mini Shai-Hulud advisory. Update your software inventory to include third-party Actions as tracked components and establish a formal review process for their adoption and updates. (Cite: NIST AC-20 — Use Of External Systems; NIST AC-1 — Policy And Procedures; CIS 2.1 — Establish and Maintain a Software Inventory; CIS 2.2 — Ensure Authorized Software is Currently Supported; CIS 7.1 — Establish and Maintain a Vulnerability Management Process; CIS 7.2 — Establish and Maintain a Remediation Process; D3-SICA — System Init Config Analysis; D3-UAP — User Account Permissions)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity
NIST IR-4 (Incident Handling)
NIST IR-8 (Incident Response Plan)
NIST SI-2 (Flaw Remediation)
NIST SA-12 (Supply Chain Protection)
NIST RA-3 (Risk Assessment)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 2.2 (Ensure Authorized Software is Currently Supported)
CIS 2.1 (Establish and Maintain a Software Inventory)
Compensating Control
For teams without enterprise tooling: (1) Add a free GitHub Actions workflow using zizmor (open-source GitHub Actions static analysis) to scan all workflow files on every PR for mutable tag references: run zizmor .github/workflows/ and fail the check if any 'uses:' line references a tag rather than a full 40-character SHA. (2) Use OpenSSF Scorecard's free GitHub Action (github.com/ossf/scorecard-action) to automatically score all third-party actions you depend on and surface those lacking SHA pinning or with low supply chain scores. (3) For @antv npm package audit tied to Mini Shai-Hulud/TeamPCP: run npm audit --json | jq '.vulnerabilities | keys[]' against all repos and cross-reference package names against the public Mini Shai-Hulud IOC list; also run npm ls --all | grep @antv to enumerate the full transitive dependency tree for affected scope packages. (4) Add an osquery scheduled query to runner hosts: SELECT name, version, install_time FROM npm_packages WHERE name LIKE '@antv/%' to continuously inventory @antv-scoped packages on self-hosted runners.
Preserve Evidence
For the lessons-learned record and updated threat model: (1) Final inventory of all repositories, workflow files, and run timestamps affected by this campaign — this constitutes the documented scope of the incident per NIST IR-5 (Incident Monitoring) requirements. (2) Timeline reconstruction artifact: a chronological log correlating actions-cool tag redirect timestamps (from public disclosure and git history), your earliest affected workflow run, and credential rotation completion — this establishes dwell time for the attacker's access to your pipeline secrets. (3) The OpenSSF Scorecard output for all third-party GitHub Actions currently referenced across your org, run post-remediation, as a baseline for ongoing supply chain risk tracking. (4) npm dependency tree snapshot (npm ls --all --json > dep-tree-post-incident.json) for all affected repos, preserving the state of @antv-scoped transitive dependencies at time of discovery for comparison against the Mini Shai-Hulud advisory's IOC list.
Recovery Guidance
After credential rotation, validate recovery by confirming that all GitHub Actions secrets, cloud provider access keys, and npm publish tokens show first-use timestamps no earlier than their post-rotation creation date — any earlier usage indicates a credential copy was retained by the attacker. Monitor cloud IAM logs (AWS CloudTrail, GCP Audit Logs, or Azure Activity Log) for the rotated service account identities for a minimum of 30 days, specifically watching for API calls to secrets managers, container registries, and package publish endpoints that deviate from your established CI/CD baseline. Additionally, monitor your organization's npm scope for unauthorized package publishes for the same 30-day window, as TeamPCP/Mini Shai-Hulud attribution suggests the threat actor's end goal includes registry-level supply chain persistence beyond simple credential theft.
Key Forensic Artifacts
GitHub Actions raw runner logs (.zip archives downloadable per run via GitHub API: GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs) for all workflow runs invoking actions-cool/issues-helper or actions-cool/maintain-one-comment after approximately May 1, 2026 — these logs will contain stdout output of the malicious action steps, including any env variable dumps, curl/wget exfiltration calls, and the specific attacker-controlled domain contacted during the tag-hijack payload execution.
Git object database entries for the attacker-controlled commit SHA that version tags (e.g., v3, v1) were redirected to in actions-cool/issues-helper and actions-cool/maintain-one-comment — capture via 'git cat-file -p MALICIOUS_SHA' and 'git show MALICIOUS_SHA --stat' before GitHub potentially force-pushes remediation, as this preserves the exact payload code that executed in your pipeline.
Cloud provider IAM/audit logs filtered on the CI/CD runner service account identity during the exposure window — specifically AWS CloudTrail events for 'secretsmanager:GetSecretValue', 'iam:CreateAccessKey', 's3:GetObject', and 'sts:AssumeRole'; GCP Audit Logs for 'iam.serviceAccounts.actAs' and 'secretmanager.versions.access'; these reveal whether the exfiltrated GITHUB_TOKEN or cloud credentials were used for secondary access beyond the initial pipeline run.
DNS query logs from runner infrastructure (corporate resolver, Route 53 Resolver Query Logs, or Cloudflare Gateway logs) filtered on source IPs belonging to GitHub-hosted or self-hosted runner subnets, for the exposure window — the TeamPCP/Mini Shai-Hulud payload exfiltrates to attacker-controlled domains, making DNS telemetry the highest-fidelity network indicator of successful exfiltration and the primary artifact for establishing which runs successfully transmitted secrets.
npm registry publish audit trail for your organization's package scope — retrieve full publish history via 'npm view @YOUR-SCOPE/* time --json' for all packages and cross-reference against internal release records; unexpected publish events during the exposure window, particularly for @antv-scoped packages matching the Mini Shai-Hulud IOC list, indicate the attacker leveraged stolen npm publish tokens to inject malicious package versions into your supply chain downstream of the CI/CD compromise.
Detection Guidance
Detection for this campaign operates across four log sources, each mapped to verified KB controls.
1.
Workflow File Audit (D3-SFA — System File Analysis; CIS 2.3 — Address Unauthorized Software): Grep all .github/workflows/*.yml files for 'actions-cool/issues-helper' or 'actions-cool/maintain-one-comment'.
Any reference not followed by a full 40-character commit SHA is a mutable tag reference and must be treated as potentially compromised.
This is a static configuration check, not a runtime alert — run it immediately and on every pull request that modifies workflow files.
2. GitHub Audit Log Analysis (NIST AU-6 — Audit Record Review, Analysis, And Reporting; NIST AU-3 — Content Of Audit Records; CIS 8.2 — Collect Audit Logs): Query the GitHub organization audit log for workflow_run events associated with the affected actions. Cross-reference with secrets access events. AU-3 requires audit records to establish what occurred, when, and from where — confirm your GitHub audit log export captures workflow execution context, not just authentication events.
3. Runner Network and Process Monitoring (NIST AU-2 — Event Logging; D3-LAM — Local Account Monitoring; D3-SICA — System Init Config Analysis): For self-hosted runners, review outbound network connections from runner hosts during workflow execution windows. Flag any connections to domains outside your approved egress list, particularly curl or wget calls initiated by runner processes. D3-SICA applies here — the malicious payload modifies runtime behavior at the process startup configuration level. GitHub-hosted runner logs do not expose full network telemetry; shift detection focus to secrets access patterns for those runners.
4. Cloud IAM and Secrets Manager Logs (NIST AU-6; NIST AC-3 — Access Enforcement; D3-LAM — Local Account Monitoring): Review cloud provider IAM logs for API calls using CI/CD service account credentials at unusual hours, from source IPs inconsistent with GitHub Actions runner IP ranges, or accessing resources outside normal pipeline scope. Flag any reads of CI/CD-scoped secrets in your secrets manager that occurred during the exposure window. AU-6 requires periodic review and analysis of audit records for anomalous activity — this review should be triggered immediately given confirmed exposure, not deferred to a scheduled cycle.
5. Outbound Data Transfer Detection (NIST AC-4 — Information Flow Enforcement; D3-PBWSAM — Proxy-based Web Server Access Mediation): If your self-hosted runners route egress through a proxy, use D3-PBWSAM to inspect and log outbound HTTP/S connections during workflow runs. AC-4 requires enforcing approved authorizations for information flow between systems — unapproved exfiltration destinations from runner hosts constitute a violation of this control. Block runner egress to non-approved domains at the network layer where operationally feasible.
Note: The KB does not include NIST SI-family controls in the provided reference data. SI-4 (System Monitoring) would be the canonical reference for continuous monitoring recommendations in this context but is not available in the current KB snapshot. Recommendations above are grounded solely in verified KB controls.
Indicators of Compromise (1)
Export as
Splunk SPL
KQL
Elastic
Copy All (1)
1 domain
Type Value Enrichment Context Conf.
⌘ DOMAIN
See Wiz Mini Shai-Hulud advisory for confirmed exfiltration domains
VT
US
Exfiltration infrastructure shared between the actions-cool tag hijacking campaign and the TeamPCP Mini Shai-Hulud npm operation — specific domains confirmed in Wiz research at https://www.wiz.io/blog/mini-shai-hulud-teampcp-hits-antv-supply-chain
MEDIUM
Platform Playbooks
Microsoft Sentinel / Defender
CrowdStrike Falcon
AWS Security
🔒
Microsoft 365 E3
3 log sources
Basic identity + audit. No endpoint advanced hunting. Defender for Endpoint requires separate P1/P2 license.
🛡
Microsoft 365 E5
18 log sources
Full Defender suite: Endpoint P2, Identity, Office 365 P2, Cloud App Security. Advanced hunting across all workloads.
🔍
E5 + Sentinel
27 log sources
All E5 tables + SIEM data (CEF, Syslog, Windows Security Events, Threat Intelligence). Analytics rules, playbooks, workbooks.
Hard indicator (direct match)
Contextual (behavioral query)
Shared platform (review required)
MITRE ATT&CK Hunting Queries (2)
Sentinel rule: Sign-ins from unusual locations
KQL Query Preview
Read-only — detection query only
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize Locations = make_set(Location), LoginCount = count(), DistinctIPs = dcount(IPAddress) by UserPrincipalName
| where array_length(Locations) > 3 or DistinctIPs > 5
| sort by DistinctIPs desc
Sentinel rule: Suspicious PowerShell command line
KQL Query Preview
Read-only — detection query only
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe")
| where ProcessCommandLine has_any ("-enc", "-nop", "bypass", "hidden", "downloadstring", "invoke-expression", "iex", "frombase64", "new-object net.webclient")
| project Timestamp, DeviceName, FileName, ProcessCommandLine, AccountName, InitiatingProcessFileName
| sort by Timestamp desc
Falcon API IOC Import Payload (1 indicators)
POST to /indicators/entities/iocs/v1 — Weak/benign indicators pre-filtered. Expiration set to 90 days.
Copy JSON
[
{
"type": "domain",
"value": "See Wiz Mini Shai-Hulud advisory for confirmed exfiltration domains",
"source": "SCC Threat Intel",
"description": "Exfiltration infrastructure shared between the actions-cool tag hijacking campaign and the TeamPCP Mini Shai-Hulud npm operation \u2014 specific domains confirmed in Wiz research at https://www.wiz.io/bl",
"severity": "medium",
"action": "detect",
"platforms": [
"windows",
"mac",
"linux"
],
"applied_globally": true,
"expiration": "2026-08-19T00:00:00Z"
}
]
Route 53 DNS — Malicious Domain Resolution
Query Preview
Read-only — detection query only
fields @timestamp, qname, srcaddr, rcode
| filter qname in ["See Wiz Mini Shai-Hulud advisory for confirmed exfiltration domains"]
| sort @timestamp desc
| limit 200
Compliance Framework Mappings
T1078.004
T1041
T1552.001
T1059
T1059.007
T1553
+2
CA-7
SC-7
SI-4
CM-7
SI-3
SI-7
+2
MITRE ATT&CK Mapping
T1041
Exfiltration Over C2 Channel
exfiltration
T1552.001
Credentials In Files
credential-access
T1059
Command and Scripting Interpreter
execution
T1553
Subvert Trust Controls
defense-evasion
T1567
Exfiltration Over Web Service
exfiltration
T1195.001
Compromise Software Dependencies and Development Tools
initial-access
Guidance Disclaimer
The analysis, framework mappings, and incident response recommendations in this intelligence
item are derived from established industry standards including NIST SP 800-61, NIST SP 800-53,
CIS Controls v8, MITRE ATT&CK, and other recognized frameworks. This content is provided
as supplemental intelligence guidance only and does not constitute professional incident response
services. Organizations should adapt all recommendations to their specific environment, risk
tolerance, and regulatory requirements. This material is not a substitute for your organization's
official incident response plan, legal counsel, or qualified security practitioners.
View All Intelligence →