Cyber Decision LedgerDecision area
Threat actor
6 public Decision Records in the whole ledger carry this label. Back to the full Ledger →
Decision Records
AnySign4PC watering-hole hunting scope
For Korea-exposed organizations and partners with AnySign4PC or relevant browsing exposure, hunt from the exposure path and browser-to-local-client execution behavior rather than relying only on malware family names; outside that footprint, treat the activity as a regional warning.
Organizations with Korean exposure, AnySign4PC installations, or relevant browsing paths should plan urgent hunting around browser-to-local-client execution behavior. Others should treat the activity as a regional warning unless their exposure matches the described path. Do not publish precise detection rules without separate sample or indicator evidence.
Personnel-security controls for mobile location exposure
Treat mobile roaming and ad-tech location exposure as a personnel-security issue for military-adjacent, diplomatic, defense, energy, media, and similar high-risk personnel. Restrict advertising identifiers, disable unnecessary roaming, review carrier and mobile-device-management telemetry, brief travelers, and use clean-phone rules for travel or crisis environments.
For sensitive travelers and high-risk personnel, treat mobile location exposure from roaming and advertising technology as a personnel-security risk. Reduce advertising identifiers, limit unnecessary roaming, review carrier and device-management telemetry, brief travelers, and apply clean-phone rules in higher-risk travel or crisis contexts. Keep state-linked and specific targeting claims caveated.
Contain unverified internet-facing Gitea Docker deployments pending proxy-auth verification
For internet-facing official Gitea Docker deployments in the packet-described vulnerable set or with unknown reverse-proxy-auth or trusted-proxy configuration, block direct public access, allow only known reverse-proxy or VPN sources, preserve logs, upgrade after staging, and hunt for X-WEBAUTH-USER impersonation, repo changes, token creation, webhook changes, and CI/CD credential abuse.
For internet-facing Gitea Docker deployments with unverified proxy-auth or trusted-proxy configuration, restrict direct public access while configuration and exposure are verified, preserve logs, upgrade through a staged path, and hunt for account, repository, token, webhook, and CI/CD abuse indicators.
Brief incidents as separate lanes with a delegated-trust pattern
Do not brief the day’s incidents as one grand control-plane campaign. Track a narrower delegated-trust abuse pattern across identity, workflows, packages, agents, and cloud services while keeping CMS webshelling, weak wallet randomness, and conventional exploitation in separate operational lanes.
Brief the incidents as separate operational risk lanes while tracking a narrower delegated-trust abuse pattern across identity, workflow, package, agent, and cloud-service contexts. Avoid presenting unrelated CMS exploitation, weak wallet randomness, or conventional exploitation as one campaign.
Keep WhatsApp Desktop/Web VBScript exposure as a conditional same-day hunt item
Where user exposure exists, restrict or block WhatsApp-delivered VBScript attachments, hunt WScript execution from chat or download paths, and isolate endpoints showing downloader or RMM staging behavior.
Where WhatsApp Desktop/Web exposure exists, treat reported VBScript attachment delivery as a conditional same-day containment and hunt item: restrict or block such attachments, hunt WScript launches from chat or download paths, and isolate endpoints showing downloader or RMM staging behavior. Do not broaden this decision to unrelated Linux patching.
Suspected AWS AiTM Exposure Requires Same-Day IAM Containment
Treat suspected AWS AiTM credential/MFA capture as potential active session or token exposure: revoke sessions, invalidate tokens, rotate access keys and console credentials, inspect IAM persistence and console/API activity, and harden conditional-access and break-glass controls.
When AWS AiTM credential or MFA exposure is suspected, contain as if active sessions or tokens may be exposed: revoke sessions, rotate credentials and keys, inspect IAM changes and console/API activity, then harden access controls.