AN0285: Analytic 0285
Detects web-based credential phishing by analyzing traffic to suspicious URLs that mimic login portals and POST credential content.
Analyst context for executives and security teams
This analytic is relevant because credential phishing often becomes a business problem before it becomes a malware problem: stolen credentials can drive account takeover, unauthorized access, and incident response escalation. AN0285 focuses on network-device visibility into web traffic that appears to visit fake login portals and submit credential-like POST content. For leaders, the decision value is whether the organization can see and investigate credential submission to suspicious web destinations, not merely whether email security blocks the initial lure.
Executive priority
Prioritize this as part of identity protection and SOC readiness. Executives should ask whether security teams can produce evidence of suspicious credential-submission traffic from network devices, how quickly those events trigger account-protection actions, and whether monitoring covers the network paths where users actually browse. This also supports audit and incident decision-making by showing whether credential-phishing detection depends only on user reports and email controls or includes network evidence.
Technical view
For SOC and detection teams, validate that network-device telemetry can identify suspicious URLs that resemble login portals and observe HTTP POST activity containing credential-like content or form submissions. Because ATT&CK does not provide a specific detection implementation for this analytic, teams should define local criteria for suspicious URL similarity, login-portal mimicry, and credential-submission indicators. IR teams should connect alerts to identity response workflows such as session review, password reset decisions, and account activity triage. No ATT&CK tactics or relationship context were supplied, so this should be treated as a detection analytic rather than a full behavior-to-technique mapping.
Likely telemetry
- Network device web traffic logs
- URL and domain reputation or categorization data
- HTTP request metadata, including POST method visibility where available
- Proxy, secure web gateway, firewall, or network sensor records
- Destination URL, host, path, referrer, user, source IP, and timestamp fields
Detection direction
- Confirm whether network devices actually capture URL-level detail and POST method metadata; many environments only log domains or connections, which may be insufficient.
- Tune suspicious URL logic for login-portal mimicry while accounting for legitimate identity providers, single sign-on portals, marketing redirects, and business SaaS login pages.
- Correlate suspicious POST activity with user identity, endpoint, and subsequent authentication activity to reduce false positives and support incident triage.
- Document blind spots such as unmanaged networks, mobile users off VPN, encrypted traffic without usable metadata, privacy restrictions, and applications that bypass inspected paths.
- Because official detection logic was not provided, require local testing with approved benign simulations or historical phishing cases before treating the analytic as operational coverage.
Mitigation priorities
- Ensure phishing defense is layered: email controls, user reporting, network visibility, and identity response should reinforce one another.
- Prioritize collection and retention of network-device web telemetry needed to investigate suspicious credential submission.
- Integrate alerts with identity and access management response procedures, including credential reset, session revocation review, and account activity validation where appropriate.
- Maintain allowlists or known-good baselines for legitimate login portals to reduce alert fatigue without suppressing suspicious lookalike domains.
- Use findings from this analytic to inform phishing resilience, compliance evidence, and incident response tabletop scenarios.
Analyst notes and limits
This Glexia take is based only on the supplied ATT&CK analytic fields. The object describes a detection analytic for web-based credential phishing on Network Devices, but provides no official detection implementation, no tactics, and no relationships to techniques, groups, software, or mitigations. The main operational value is validating whether network telemetry can identify suspicious login-portal mimicry and credential-like POST submissions and whether those alerts connect to identity response.
Coverage depends heavily on local network architecture, logging depth, encryption handling, privacy constraints, and whether user browsing traverses monitored network devices. The supplied ATT&CK data does not support claims about active exploitation, adversary attribution, specific tools, guaranteed detection, or business impact severity.
Analytic 0285
Detects web-based credential phishing by analyzing traffic to suspicious URLs that mimic login portals and POST credential content.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | c907ca7220f5… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack AN0285Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.