← Back to Cybersecurity News Center
Severity
HIGH
CVSS
7.5
Priority
0.675
×
Tip
Pick your view
Analyst for full detail, Executive for the short version, or Plain & Simple if you are not a tech person.
Analyst
Executive
Plain & Simple
Executive Summary
A threat actor is running a Google Ads campaign that intercepts ManageWP login credentials and multi-factor authentication codes in real time, allowing immediate account takeover without triggering standard MFA protections. GoDaddy's ManageWP platform is used to manage over one million WordPress sites; a single compromised account can expose every website under that account simultaneously. Organizations with staff who manage WordPress sites through ManageWP face significant risk of mass site defacement, malware injection, data theft, or ransomware deployment across their entire web property portfolio.
Plain & Simple
Here’s what you need to know.
No jargon. Just the basics.
👤
Are you affected?
Probably, if you or someone you pay manages your website through ManageWP.
🔓
What got out
Suspected: ManageWP account username and password
Suspected: One-time login codes sent to your phone or app
Suspected: Access to all websites connected to the account
✅
Do this now
1 Change your ManageWP password right now at app.managewp.com. 2 Go directly to app.managewp.com, do not search for it or click ads. 3 Check your websites for unexpected changes or new admin accounts you did not create.
👀
Watch for these
Unexpected changes to your website content or layout.
Emails saying your ManageWP password was changed and you did not do it.
New admin users appearing in your website dashboard that you do not recognize.
🌱
Should you worry?
If you use ManageWP and clicked a Google search ad to log in recently, your account may be at risk. Changing your password now and checking your sites takes less than ten minutes and is worth doing.
Want more detail? Switch to the full analyst view →
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
HIGH
High severity — prioritize for investigation
Actor Attribution
HIGH
Unknown — Russian-language origin markers identified by Guardio Labs; no named threat actor attributed
TTP Sophistication
HIGH
8 MITRE ATT&CK techniques identified
Detection Difficulty
HIGH
Multiple evasion techniques observed
Target Scope
INFO
GoDaddy ManageWP (all versions using portal login), WordPress sites managed via ManageWP plugin (1M+ sites at risk)
Are You Exposed?
⚠
Your industry is targeted by Unknown — Russian-language origin markers identified by Guardio Labs; no named threat actor attributed → Heightened risk
⚠
You use products/services from GoDaddy ManageWP (all versions using portal login) → 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
Business Context
A single compromised ManageWP account can give an attacker simultaneous control over every WordPress site managed under that account — meaning one successful phishing click can result in mass defacement, malware injection, or data theft across an entire web property portfolio. For organizations whose websites generate revenue, drive customer acquisition, or handle customer data, this translates directly to revenue disruption, brand damage, and potential regulatory exposure if customer data on those sites is accessed or exfiltrated. The multiplier effect — one credential loss equals hundreds of site compromises — makes this disproportionately high impact relative to its technical sophistication.
You Are Affected If
Your organization uses GoDaddy ManageWP to manage one or more WordPress sites via the app.managewp.com portal
Staff access ManageWP by searching for the login page rather than using a saved bookmark or direct URL
ManageWP accounts are protected only by TOTP-based 2FA (Google Authenticator, Authy, or similar) — not hardware security keys or passkeys
Multiple WordPress sites are consolidated under a single ManageWP account, increasing blast radius if that account is compromised
No endpoint or DNS controls are in place to block access to lookalike/phishing domains mimicking ManageWP or GoDaddy login pages
Board Talking Points
Attackers are using paid Google search ads to steal login credentials for our WordPress site management platform, bypassing standard two-factor authentication protections.
IT should immediately enforce bookmark-only access to the ManageWP portal and migrate accounts to phishing-resistant authentication within the next 48 hours.
Without action, a single successful attack on one employee account could result in simultaneous compromise of every website we manage, including potential customer data exposure and public-facing defacement.
Technical Analysis
This is an adversary-in-the-middle (AiTM) phishing campaign, not a software vulnerability, no CVE has been assigned.
The threat actor purchases Google Ads placements targeting users searching for the ManageWP login page, presenting a sponsored result that redirects victims to a phishing proxy.
The proxy transparently relays authentication traffic between the victim and the legitimate ManageWP portal, capturing both credentials and TOTP/2FA codes in real time before passing the session through.
This defeats TOTP-based MFA entirely because the attacker authenticates to the real portal using the intercepted code within its validity window. According to Guardio Labs researchers cited by BleepingComputer, at least 200 victims were confirmed and attacker infrastructure was accessed, identifying a private, operator-driven phishing kit with Russian-language backend markers. The kit supports live operator monitoring, consistent with T1113 (Screen Capture/C2 observation). Relevant MITRE techniques: T1566 (Phishing), T1583.008 (Malvertising), T1557 (Adversary-in-the-Middle), T1078 (Valid Accounts), T1539 (Steal Web Session Cookie). Relevant CWEs: CWE-287 (Improper Authentication), CWE-319 (Cleartext Transmission of Sensitive Information), CWE-384 (Session Fixation), CWE-1021 (UI Layer Rendering). No patch exists, this is an abuse-of-service attack. Mitigation requires procedural and architectural controls, not a software update.
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to senior IR leadership, legal counsel, and data protection officer immediately if any compromised ManageWP account managed WordPress sites that process payment card data (PCI DSS breach notification), collect EU resident PII (GDPR 72-hour notification clock), or store PHI (HIPAA breach assessment required); secondary escalation trigger is confirmation that threat actor has deployed persistent webshells or backdoors across more than 10 managed WordPress sites, indicating automated post-exploitation at scale beyond the team's unaided remediation capacity.
1
Step 1: Containment — Audit all ManageWP accounts immediately. Review ManageWP User Activity log for logins from unrecognized IPs or geolocations. Revoke active sessions for any suspected compromised account via ManageWP account settings > Active Sessions. Rotate credentials for all ManageWP accounts regardless of suspected compromise. (Cite: NIST AC-2 Account Management / NIST AC-12 Session Termination / CIS 5.1 Establish and Maintain an Inventory of Accounts / D3-CRO Credential Rotation)
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy
NIST IR-4 (Incident Handling)
NIST AC-17 (Remote Access)
CIS 5.1 (Establish and Maintain an Inventory of Accounts)
CIS 6.2 (Establish an Access Revoking Process)
Compensating Control
Export ManageWP User Activity log as CSV via dashboard and run: awk -F',' '{print $3}' activity_export.csv | sort | uniq -c | sort -rn to surface repeated or outlier source IPs. Cross-check IPs against your known egress ranges using a free IP geolocation lookup (ip-api.com batch API — free tier supports 15 req/min). For session revocation confirmation without EDR, have users re-authenticate immediately after credential rotation and verify no active sessions persist in the ManageWP Active Sessions panel.
Preserve Evidence
Capture BEFORE revoking sessions: full screenshot and CSV export of ManageWP User Activity log showing timestamps, source IPs, and session tokens for the 72-hour window prior to discovery. Note any source IPs geolocating to residential proxy ranges or hosting ASNs (e.g., AS14061 DigitalOcean, AS16509 AWS) inconsistent with staff locations — AiTM proxy infrastructure typically resolves to these. Preserve browser history on any workstations where staff clicked a Google Ads result for 'ManageWP' or 'ManageWP login', as this captures the phishing relay URL (typically a lookalike domain proxying app.managewp.com). Document active session tokens before revocation for chain-of-custody records per NIST 800-61r3 §3.3.
2
Step 2: Detection — Review ManageWP login history for logins from IPs outside expected geography, rapid sequential logins from different IPs indicating session relay, and logins immediately followed by bulk site actions. Cross-reference against Google Workspace or SSO logs if access is federated. Audit each managed WordPress site for new admin accounts, modified core files, injected scripts in theme or plugin files, and unauthorized plugin installations. (Cite: NIST AU-2 Event Logging / NIST AU-6 Audit Record Review, Analysis, And Reporting / 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 SI-4 (System Monitoring)
CIS 8.2 (Collect Audit Logs)
Compensating Control
For WordPress site-level detection without enterprise tooling, run the following WP-CLI command across all managed sites to enumerate recently created admin accounts: wp user list --role=administrator --fields=user_login,user_registered,user_email --format=csv 2>/dev/null — flag any accounts registered after your earliest suspected compromise timestamp. For file integrity, run: find /var/www -name '*.php' -newer /var/www/wp-config.php -ls to identify PHP files modified after a reference date. For injected scripts in theme files, use: grep -rn --include='*.php' 'eval(base64_decode' /var/www/wp-content/ to detect common webshell obfuscation patterns left by post-AiTM compromise tooling. For Google Workspace log correlation, export Admin > Reports > Login Audit filtered by ManageWP's OAuth app identifier if SSO is configured.
Preserve Evidence
Preserve before analysis: ManageWP login history export for all accounts covering 14 days prior to discovery — specifically flag events where credential authentication and 2FA submission timestamps are separated by under 60 seconds, which is the AiTM relay window for real-time TOTP interception. In WordPress databases, query: SELECT user_login, user_registered, meta_value FROM wp_users JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id WHERE meta_key='wp_capabilities' AND meta_value LIKE '%administrator%' ORDER BY user_registered DESC LIMIT 20; — capture output before any eradication. Preserve wp-content/uploads directory listing and modification timestamps, as threat actors commonly stage webshells or backdoors in uploads directories post-account takeover via ManageWP's bulk file manager. If Google Workspace SSO is in use, export SAML assertion logs for the compromise window.
3
Step 3: Eradication — Enforce bookmark-only or direct-URL access to app.managewp.com for all staff. Block access via search engine result clicks using endpoint DNS filtering or browser policy. Migrate all ManageWP accounts to FIDO2/passkey (phishing-resistant) authentication where supported; TOTP-based 2FA does not protect against AiTM proxy attacks. Apply phishing-resistant MFA to upstream identity providers (SSO, Google Workspace) feeding ManageWP access. (Cite: NIST AC-17 Remote Access / NIST AC-20 Use Of External Systems / CIS 6.3 Require MFA for Externally-Exposed Applications / CIS 6.5 Require MFA for Administrative Access / D3-MFA Multi-factor Authentication / D3-CH Credential Hardening / D3-EBWSAM Endpoint-based Web Server Access Mediation)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication
NIST SI-2 (Flaw Remediation)
NIST SC-20 (Secure Name/Address Resolution Service — Authoritative Source)
NIST IA-5 (Authenticator Management)
CIS 4.4 (Implement and Manage a Firewall on Servers)
CIS 7.3 (Perform Automated Operating System Patch Management)
Compensating Control
Deploy a Pi-hole or pfBlockerNG DNS sinkhole with a custom blocklist targeting known ManageWP-lookalike domains (managewp-login[.]com, manage-wp[.]net patterns — query urlscan.io or URLhaus for current AiTM relay domains associated with this campaign). For browser policy enforcement without enterprise MDM, push a Chrome managed policy via Group Policy or registry key: HKLM\SOFTWARE\Policies\Google\Chrome\URLBlocklist = '*' scoped with a corresponding URLAllowlist = 'https://app.managewp.com/*' to prevent search-engine-click access paths. For FIDO2 enrollment without budget, register free passkeys via any FIDO2-compatible authenticator app (e.g., Google Authenticator passkey support, Bitwarden Passwordless) as an interim measure until hardware tokens are procured. Sigma rule reference: sigma/rules/web/proxy_generic/proxy_suspicious_managewp_lookalike.yml (community rules exist for AiTM proxy domain patterns; search the SigmaHQ GitHub repository for current AiTM detection rules applicable to this infrastructure pattern).
Preserve Evidence
Before enforcing DNS blocks, capture: full DNS query logs from endpoint resolvers or your perimeter DNS forwarder for the 14-day lookback window, filtering for any resolution of domains resembling 'managewp' that are NOT app.managewp.com or managewp.com — these are the AiTM proxy relay domains and constitute primary evidence of staff interaction with the phishing infrastructure. Preserve browser history from all workstations used for ManageWP access: target the Chrome history SQLite database at %LOCALAPPDATA%\Google\Chrome\User Data\Default\History and query the urls table for any domain containing 'managewp' that does not match the canonical app.managewp.com origin. This distinguishes which users clicked a sponsored result versus used a bookmark.
4
Step 4: Recovery — For any confirmed compromised account: rotate ManageWP credentials immediately. Audit all connected WordPress sites for unauthorized admin accounts via ManageWP site overview or WordPress admin Users > All Users. Scan for injected malicious code using file integrity monitoring. Restore affected sites from a known-clean backup predating the compromise window. Confirm ManageWP account recovery email and phone remain under organizational control. (Cite: NIST AC-2 Account Management / NIST AU-11 Audit Record Retention / CIS 5.1 Establish and Maintain an Inventory of Accounts / CIS 6.2 Establish an Access Revoking Process / D3-CRO Credential Rotation / D3-SFA System File Analysis / D3-UAP User Account Permissions)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery
NIST IR-4 (Incident Handling)
NIST CP-9 (System Backup)
NIST SI-7 (Software, Firmware, and Information Integrity)
CIS 7.2 (Establish and Maintain a Remediation Process)
Compensating Control
Run Wordfence CLI (free tier) or Sucuri SiteCheck (free, no install required) against each affected WordPress site URL to identify injected scripts and modified core files before backup restoration. For wp_users auditing without WP admin access, connect directly to the WordPress MySQL/MariaDB database: mysql -u wpuser -p wpdb -e "SELECT user_login, user_email, user_registered FROM wp_users JOIN wp_usermeta ON wp_users.ID=wp_usermeta.user_id WHERE meta_key='wp_capabilities' AND meta_value LIKE '%administrator%';" — remove any unrecognized admin rows before restoring from backup to avoid re-persisting backdoor accounts. For file integrity verification post-restoration, use WP-CLI: wp core verify-checksums and wp plugin verify-checksums --all to confirm core and plugin files match WordPress.org repository hashes. Verify ManageWP recovery email ownership by triggering a test password reset to the registered address and confirming delivery.
Preserve Evidence
Before beginning any restoration, preserve: a complete file system snapshot or tarball of the compromised WordPress site's wp-content directory, including uploads — threat actors using ManageWP bulk access frequently drop PHP webshells in wp-content/uploads (e.g., files named with random alphanumeric strings ending in .php or .php.jpg). Capture the wp_options table entry for 'siteurl' and 'home' to detect URL hijacking redirects. Export the wp_usermeta table filtered on capability = administrator to document all unauthorized accounts created during the compromise window. This evidence must be preserved in immutable storage before any recovery action modifies the filesystem, per NIST 800-61r3 §3.5 and NIST IR-4 (Incident Handling) evidence preservation requirements.
5
Step 5: Post-Incident — This campaign exposes an architectural gap: TOTP is not phishing-resistant. Evaluate and enforce FIDO2/passkey or hardware token authentication across all privileged web application accounts, not only ManageWP. Expand phishing-resistant MFA policy scope to cover all web-based management platforms. Implement a formal policy prohibiting staff from accessing internal administrative tools via sponsored search results; train staff to bookmark portals directly. Establish AU-13-aligned monitoring for open-source disclosures and brand impersonation activity targeting managed tools. (Cite: NIST AC-1 Policy And Procedures / NIST AU-13 Monitoring For Information Disclosure / CIS 6.3 Require MFA for Externally-Exposed Applications / CIS 6.5 Require MFA for Administrative Access / D3-MFA Multi-factor Authentication / D3-CH Credential Hardening)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity
NIST IR-4 (Incident Handling)
NIST IR-8 (Incident Response Plan)
NIST IA-5 (Authenticator Management)
NIST SI-5 (Security Alerts, Advisories, and Directives)
CIS 6.3 (Require MFA for Externally-Exposed Applications)
CIS 6.5 (Require MFA for Administrative Access)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
Compensating Control
For brand impersonation monitoring without a commercial service, set up a free Google Alerts query for 'ManageWP' + 'login' and review weekly for suspicious sponsored content patterns; supplement with manual spot-checks of Google search results for 'ManageWP login' from a clean browser session monthly. To enforce bookmark-only access policy without MDM, distribute a pre-configured browser bookmarks HTML file to all staff via shared drive and document in your acceptable use policy that clicking search ads for administrative tools is a policy violation. For FIDO2 migration planning, reference CISA's Phishing-Resistant MFA guidance (cisa.gov — search 'phishing-resistant MFA fact sheet') as a free policy justification document. Submit a Google Ads policy complaint via ads.google.com/intl/en_us/home/resources/adsense-spam-report/ referencing the impersonating advertiser to request takedown of the malicious ad placement.
Preserve Evidence
Compile a lessons-learned document per NIST 800-61r3 §4 capturing: the specific Google Ads creative and relay domain used in this campaign (preserved from browser history forensics in Step 3), a timeline from first staff click to account compromise to detection, the number of WordPress sites exposed per compromised ManageWP account (blast radius metric), and the delta between TOTP submission and AiTM session replay (establishing the real-time interception window). This document supports both internal control improvement and any regulatory breach notification assessment if compromised WordPress sites processed PII or payment data. Submit campaign IOCs (relay domains, phishing URLs) to CISA's automated indicator sharing program and Google Safe Browsing report portal to protect the broader community.
Recovery Guidance
After restoring WordPress sites from pre-compromise backups, maintain elevated monitoring of ManageWP User Activity logs and WordPress admin audit logs (via WP Activity Log plugin or equivalent) for a minimum of 30 days, specifically watching for re-appearance of unauthorized admin accounts or file modifications that would indicate a persistent backdoor survived the restoration. Verify that all ManageWP-connected WordPress sites have their wp-cron scheduled tasks audited (wp cron event list --format=table) for injected malicious cron jobs, as AiTM-enabled account takeovers frequently establish cron-based persistence to survive credential rotation. Confirm that no ManageWP Safe Updates, bulk plugin installations, or maintenance mode changes were queued by the threat actor during the compromise window, as ManageWP's bulk action capability allows site-wide changes that may execute after account recovery if not cancelled.
Key Forensic Artifacts
ManageWP User Activity log export (CSV): source IPs, session timestamps, and 2FA submission events for all accounts — the AiTM interception mechanism leaves a forensic signature of sub-60-second gaps between credential submission and TOTP entry followed by an immediate login from a distinct proxy IP, distinguishing real-time relay from legitimate authentication
Browser history SQLite databases from all workstations used for ManageWP access (Chrome: %LOCALAPPDATA%\Google\Chrome\User Data\Default\History; Firefox: %APPDATA%\Mozilla\Firefox\Profiles\*.default\places.sqlite) — query for any 'managewp' URL that does not originate from the canonical app.managewp.com domain, identifying which users clicked the malicious Google Ads placement and what AiTM relay domain was used
WordPress wp_users and wp_usermeta database tables from all managed sites: administrator-capability rows created after the earliest suspected compromise timestamp represent accounts planted by the threat actor via ManageWP bulk user management during the post-AiTM account takeover window
WordPress site filesystem snapshot focused on wp-content/uploads and wp-content/plugins directories: AiTM-enabled ManageWP account takeovers enable direct file manager access, and threat actors commonly stage PHP webshells in uploads (filenames matching regex [a-z0-9]{8,16}\.php) or inject base64-encoded eval() payloads into active theme functions.php files
DNS query logs from endpoint resolvers or perimeter DNS forwarder covering 14 days prior to discovery: filter for any resolution of domains lexically similar to 'managewp' (Levenshtein distance ≤ 3 from 'managewp') that resolve to non-GoDaddy infrastructure ASNs — these records identify the AiTM proxy relay domains and establish which endpoints interacted with the phishing infrastructure before the credential interception occurred
Detection Guidance
Primary detection surface is ManageWP's own activity log.
Apply NIST AU-6 (Audit Record Review, Analysis, And Reporting) to review authentication events at defined intervals.
Flag: logins from IPs inconsistent with your team's known locations; multiple successful logins within short intervals from different IPs indicating session relay (AiTM proxy pattern); and logins immediately followed by bulk site actions.
NIST AU-3 (Content Of Audit Records) requires records that establish what occurred, when, where (source IP), and who — confirm ManageWP activity logs capture all five elements before relying on them for detection. Enable log collection per CIS 8.2 (Collect Audit Logs) across all enterprise assets with access to ManageWP. For managed WordPress sites: apply D3-LAM (Local Account Monitoring) — query wp_users for accounts created within the post-compromise window. Apply D3-SFA (System File Analysis) — scan active theme files (functions.php, header.php) and plugin files for base64-encoded injected strings and unauthorized modifications; check wp_options (active_plugins) for unauthorized plugin installations. At the network and DNS layer: monitor for DNS queries or outbound connections to domains mimicking 'managewp' or 'godaddy' that are not the canonical app.managewp.com — this aligns with NIST AU-2 (Event Logging) scoped to network access events. Apply D3-ACA (Active Certificate Analysis) to validate TLS certificates presented by any ManageWP-lookalike domain encountered in DNS or proxy logs; AiTM proxies frequently present certificates for look-alike domains rather than the legitimate certificate chain. If an email security gateway is deployed, flag inbound messages referencing ManageWP login links per NIST AU-13 (Monitoring For Information Disclosure), as secondary phishing lures may accompany the ad campaign. No confirmed public IOC list has been released by Guardio Labs as of this writing; treat any sponsored Google search result for ManageWP as a potential phishing vector until further attribution data is available. Retain all collected audit records per NIST AU-11 (Audit Record Retention) to support post-incident analysis.
Indicators of Compromise (1)
Export as
Splunk SPL
KQL
Elastic
Copy All (1)
1 url
Type Value Enrichment Context Conf.
🔗 URL
app.managewp.com (canonical — verify all login URLs match exactly)
VT
US
Phishing proxies mimic this URL; any sponsored Google search result claiming to lead here should be treated as suspect until campaign is confirmed removed
HIGH
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.
IOC Detection Queries (1)
1 URL indicator(s).
KQL Query Preview
Read-only — detection query only
// Threat: Google Ads Weaponized to Intercept ManageWP Credentials in Real-Time 2FA Bypass
let malicious_urls = dynamic(["app.managewp.com (canonical — verify all login URLs match exactly)"]);
DeviceNetworkEvents
| where Timestamp > ago(30d)
| where RemoteUrl has_any (malicious_urls)
| project Timestamp, DeviceName, RemoteUrl, RemoteIP,
InitiatingProcessFileName, InitiatingProcessCommandLine
| sort by Timestamp desc
MITRE ATT&CK Hunting Queries (2)
Sentinel rule: Phishing email delivery
KQL Query Preview
Read-only — detection query only
EmailEvents
| where Timestamp > ago(7d)
| where ThreatTypes has "Phish" or DetectionMethods has "Phish"
| summarize Attachments = make_set(AttachmentCount), Urls = make_set(UrlCount) by NetworkMessageId, Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation, ThreatTypes
| sort by Timestamp desc
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
No actionable IOCs for CrowdStrike import (benign/contextual indicators excluded).
No hard IOCs available for AWS detection queries (contextual/benign indicators excluded).
Compliance Framework Mappings
T1566
T1078
T1583.008
T1557
T1539
T1598.003
+2
AT-2
CA-7
SC-7
SI-3
SI-4
SI-8
+6
164.312(d)
164.312(e)(1)
164.308(a)(5)(i)
MITRE ATT&CK Mapping
T1566
Phishing
initial-access
T1078
Valid Accounts
defense-evasion
T1557
Adversary-in-the-Middle
credential-access
T1539
Steal Web Session Cookie
credential-access
T1113
Screen Capture
collection
T1566.003
Spearphishing via Service
initial-access
Guidance Disclaimer
