Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0835: Detection of Email Accounts

DET0835 is a detection strategy for adversary-created email accounts associated with ATT&CK technique T1585.002, Email Accounts. Its business value is in e...

EnterpriseDET0835Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0835 is a detection strategy for adversary-created email accounts associated with ATT&CK technique T1585.002, Email Accounts. Its business value is in early warning: these accounts may be prepared before an intrusion to support phishing, information gathering, or other targeting activity. Because the ATT&CK object does not provide a detailed detection method, organizations should treat this as a prompt to validate whether they can recognize suspicious external email-account infrastructure and account-use patterns that may precede direct compromise.

Executive priority

Prioritize this as a readiness question rather than a single tool alert: can the organization identify and investigate email accounts created or used to target employees, customers, partners, or cloud identities before phishing succeeds? This matters for business continuity, incident response speed, and audit evidence around phishing defense, threat intelligence, and identity protection. Budget and control decisions should focus on whether email security, identity, SOC workflows, and threat intelligence processes share enough evidence to connect suspicious sender accounts to targeting activity.

Technical view

The supplied ATT&CK relationship says this detection strategy detects T1585.002, Email Accounts, under resource development on PRE platforms. SOC and detection teams should validate coverage for pre-compromise indicators involving externally created email accounts used in targeting workflows. Since ATT&CK provides no official detection text for DET0835, teams should derive local analytics from email security logs, identity events, reported phishing, threat intelligence enrichment, and case correlation. The key technical question is whether suspicious account creation or account use can be tied to phishing for information, phishing, or infrastructure acquisition context without assuming every new or free-provider email account is malicious.

Likely telemetry

  • Inbound email gateway and message metadata, including sender address, display name, reply-to, sending domain, and authentication results
  • User-reported phishing submissions and SOC case data
  • Identity and access logs for suspicious interactions initiated from email links or messages
  • Threat intelligence enrichment on sender domains, email addresses, and related infrastructure
  • Security awareness or mailbox investigation records showing repeated targeting by similar accounts

Detection direction

  • Validate whether detections distinguish suspicious email-account use from normal consumer or partner email traffic to reduce false positives.
  • Correlate sender-account patterns with phishing reports, targeting of high-risk roles, credential collection attempts, or related infrastructure indicators.
  • Confirm whether SOC workflows preserve message headers and metadata needed for investigation and retrospective hunting.
  • Treat this as pre-compromise/resource-development visibility; absence of an alert does not prove absence of adversary preparation.
  • Document blind spots where personal email providers, encrypted mail services, or limited log retention reduce investigative confidence.

Mitigation priorities

  • Strengthen user reporting, email security controls, and SOC triage paths for suspicious external sender accounts.
  • Ensure identity protections are prepared for downstream phishing outcomes, including suspicious sign-in review and credential abuse response.
  • Maintain threat intelligence and case-management processes that can correlate recurring sender accounts, domains, and campaigns.
  • Retain email and identity telemetry long enough to support retrospective analysis after a phishing or targeting incident.
  • Use findings to support compliance evidence for phishing defense, monitoring, and incident response readiness.
Analyst notes and limits

DET0835 has no official ATT&CK description, detection text, tactics, or platforms specified. The practical interpretation comes from its relationship to T1585.002 Email Accounts, which describes adversaries creating email accounts for targeting and related operations such as phishing or phishing for information.

This take is constrained to the supplied ATT&CK fields and relationship context. It does not establish active exploitation, attribution, specific vendors, guaranteed detections, or environment-specific exposure. Local telemetry, email architecture, identity controls, and reporting processes are required to determine real coverage.

Official MITRE ATT&CK definition

Detection of Email Accounts

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1585.002 Email Accounts Sub-technique This object detects Email Accounts.
Relationship explorer

All related ATT&CK context

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
332ea0c4421aed52...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 332ea0c4421a…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0835
    Open source URL
Source and licensing

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.