A suspicious login is an investigation signal, not automatically proof of account compromise. The right MITRE ATT&CK mapping depends on what the authentication evidence shows, what happened before and after the login, and how confident the team can be.
Short answer: record the observed authentication behavior first, then map it to a candidate ATT&CK technique such as Valid Accounts, Brute Force, External Remote Services, or MFA Interception only when the evidence supports that hypothesis.
MITRE ATT&CK techniques describe adversary behavior. They do not replace identity investigation, impact assessment, or incident severity decisions.
Start with the authentication facts
Capture the facts before selecting a technique:
- Account, role, and privilege level.
- Source IP, device, geography, network, and provider context.
- Authentication method and result.
- Time, frequency, and sequence of attempts.
- Target application, service, or remote-access path.
- MFA prompt, approval, failure, or bypass information.
- User confirmation or denial.
- Activity after a successful authentication.
- Related alerts, sessions, tokens, or password changes.
The same unusual location can mean travel, a corporate proxy, a new service provider, a false positive, or attacker activity. Context determines the investigation.
Candidate ATT&CK techniques for login investigations
Valid Accounts: T1078
Consider Valid Accounts when there is evidence that an account was used to access a system or service and the activity may represent adversary use of legitimate credentials.
The technique has sub-techniques for default, domain, local, and cloud accounts. Select the appropriate level only when the account context is known.
An unsuccessful login attempt alone usually does not demonstrate Valid Accounts. Record it as an authentication event or investigation signal unless further evidence supports the technique.
Brute Force: T1110
Consider Brute Force when the pattern shows repeated attempts intended to guess or obtain credentials. A single failed login is not enough.
Review the rate, account spread, source pattern, authentication method, lockout response, and whether the attempts were successful.
External Remote Services: T1133
Consider External Remote Services when the account was used through an externally accessible remote service, such as a remote access gateway or exposed management path.
The technique describes the access route, not proof that the account was compromised. Combine it with evidence about the account, service, and subsequent activity.
Multi-Factor Authentication Request Generation: T1621
Repeated or suspicious MFA prompts may support investigation of MFA request abuse. The ticket should record whether the user approved a prompt, denied it, reported it, or did not see it.
Do not label a prompt as an ATT&CK technique solely because MFA was involved. The pattern and supporting identity-provider evidence matter.
Use a ticket structure that preserves uncertainty
| Field | Example |
|---|---|
| Observed behavior | Successful login to a privileged cloud account from an unusual device and source network |
| Candidate tactic | Initial Access, Persistence, or Defense Evasion depending on evidence and context |
| Candidate technique | Valid Accounts: Cloud Accounts, pending confirmation |
| Evidence | Identity-provider sign-in record, device state, MFA result, session history |
| Confidence | Medium because the user has not yet confirmed the activity |
| Investigation question | Was the session followed by unusual resource access or account changes? |
| Action | Confirm with the user, revoke the session if required, review activity, preserve logs |
| Owner | Identity or incident-response owner |
The tactic and technique are working hypotheses until the evidence supports a stronger conclusion. Keep the original facts and the reason for any mapping change.
Investigate the activity before and after the login
The login event is only one point in the timeline.
Review:
- Earlier failed attempts or password-reset activity.
- New devices, tokens, sessions, forwarding rules, or MFA changes.
- Privileged actions after authentication.
- Access to sensitive applications or data.
- Changes to accounts, groups, permissions, or recovery methods.
- Similar activity involving other users.
The result may be a benign event, an attempted compromise, a confirmed account takeover, or an incident where the root cause remains uncertain. Record that distinction clearly.
Avoid common mapping errors
Treating geography as a technique
An unusual country or IP is context, not an ATT&CK technique. It may support a hypothesis when combined with identity and activity evidence.
Treating a failed attempt as successful access
A failed login can indicate probing or a user mistake. Do not record a successful-account-use technique without successful-access evidence.
Using the most specific sub-technique too early
Start with the level supported by the data. Narrow the mapping when the account type, platform, or access path is confirmed.
Letting the mapping determine severity
Severity still depends on privilege, affected assets, data, scope, business impact, confidence, and containment status.
Connect login findings to response and controls
The response may require session revocation, credential reset, MFA review, device isolation, access review, or additional log preservation. The correct action depends on the facts and the organisation’s incident process.
For the broader ticket model, see How MITRE ATT&CK Mapping Improves Incident Response Quality. For the link from incidents to control improvements, see How Incident Data Reveals Weaknesses in Security Controls.
IncidentAI can support structured incident records, triage, ownership, timelines, evidence, and ATT&CK context where relevant. It does not decide whether a login was malicious, determine legal reportability, or replace accountable human decisions.
Quick FAQ
Does a suspicious login mean Valid Accounts?
Not automatically. Valid Accounts requires evidence that legitimate account access was used in a way that may represent adversary behavior. A suspicious or failed login is an investigation signal until the facts are clearer.
Can one login map to several ATT&CK techniques?
Yes, but only when the evidence supports each mapping. A successful login through a remote service may involve both Valid Accounts and External Remote Services, while later account changes may support another technique.
What should the ticket say when the mapping is uncertain?
State the observed behavior, candidate technique, evidence, confidence, and next investigation action. Uncertainty is useful information when it is explicit.