How SOC Analysts Investigate Suspicious Login Activity Step-by-Step

TECHMONARCH INSIGHTS · SOC OPERATIONS & THREAT INVESTIGATION

A suspicious login alert is a starting point, not a conclusion. What separates a SOC that catches breaches from one that generates false positive reports is the investigation methodology applied in the minutes after the alert fires.

By TechMonarch Editorial Team | 9 min read | SOC Operations & Incident Investigation

A suspicious login alert arrives in the SOC queue at 11:43 PM. An Azure AD sign-in risk event has flagged a successful authentication for a finance department user account. The login came from an IP address in a country where the client has no employees or operations. The analyst has a decision to make, and the quality of that decision in the next several minutes determines whether this becomes a contained credential compromise or a ransomware deployment.

Suspicious login investigation is the most consequential investigative workflow in the SOC because it operates at the threshold between pre-breach and post-breach. An alert that fires on a legitimate attacker authentication is the earliest possible detection opportunity — the moment at which the attacker has access but has not yet acted. What happens in the investigation window directly determines whether that opportunity is exploited or squandered.

This article walks through the complete investigation methodology that TechMonarch SOC analysts apply to suspicious login alerts across MSP client environments. It is structured as a step-by-step workflow because that is how effective investigation actually works — not as a set of principles to be applied by intuition, but as a documented procedure that produces consistent outcomes regardless of which analyst is working the alert.

The methodology applies across on-premises Active Directory environments, Microsoft 365 and Azure AD environments, and hybrid configurations, with specific tooling references for each. The underlying investigation logic is platform-agnostic.

Step 1: Alert Triage — Classify Before You Investigate

The first 60 seconds of a suspicious login investigation should be spent on triage, not investigation. Triage answers a single question: is this alert worth investigating now, or does the available information immediately classify it as low-risk? The triage decision should be documented and should precede any investigation action.

Triage for a suspicious login alert evaluates four dimensions simultaneously. The account type is the first: a successful suspicious login to a global administrator account warrants immediate escalation regardless of any other factor. A suspicious login to a standard user account requires full investigation. A suspicious login to a service account or non-interactive account that should never have interactive logins is an automatic high-priority finding.

The authentication outcome is the second dimension. A successful authentication is higher priority than a failed one, because a successful authentication means the attacker has credentials that work. A pattern of failures followed by a success is higher priority than either alone because it is consistent with a password spray or brute force that achieved its objective.

The timing context is the third. An authentication that occurred during the user’s normal working hours and is flagged by an anomaly rule based on location is a different risk profile than an authentication at 3 AM local time for the user, which should prompt immediate verification because legitimate business activity at 3 AM is uncommon. Off-hours authentications combined with location anomalies are among the highest-confidence indicators of credential compromise.

The client context is the fourth. Some clients have employees who travel internationally or work across time zones as a routine matter. A client whose CEO travels internationally every other week has a different baseline for international authentication events than one whose entire workforce is in a single office. Client profile documentation — accessible in your documentation platform directly from the SOC console — is the reference that prevents false positive escalations and prevents genuine incidents from being dismissed as expected travel.

The triage output is a priority classification: P1 (immediate investigation and potential containment action), P2 (investigate within 15 minutes), or P3 (investigate within the hour). This classification drives the analyst’s next action and, in a white-label SOC context, determines whether the investigation is handled within the current tier or escalated to senior analyst coverage immediately.

“The biggest investigation mistake SOC analysts make is starting with action before completing triage. An analyst who immediately resets a password on a suspicious login alert that turns out to be a legitimate executive on a business trip has disrupted a client and generated a complaint. Triage first — act after.”

Step 2: Source IP Intelligence — What the Login Origin Tells You

The source IP address of a suspicious authentication event is the first concrete data point to investigate. IP intelligence provides context that substantially refines the risk assessment before any account-level investigation is performed.

The first IP check is geolocation against the client’s known user geography. An authentication from a country where the client has no employees, no offices, and no known business relationships is a strong indicator of compromise unless there is a specific, known reason for that geography. This check is fast — most SIEM platforms surface geolocation data directly in the alert context — and it immediately elevates or deflates the risk assessment.

The second check is ASN and hosting provider identification. An authentication originating from an IP address registered to a residential ISP in the user’s home country is a very different risk profile from one originating from a cloud hosting provider ASN. Attacker infrastructure is commonly hosted on cloud providers (AWS, Azure, DigitalOcean, Linode, Vultr) or anonymization services (Tor exit nodes, commercial VPN providers). An authentication from a datacenter IP in a foreign country is not the same as an authentication from a residential IP in the same country, and the distinction matters for the investigation decision tree.

The third check is threat intelligence enrichment. The source IP should be checked against threat intelligence feeds for known malicious infrastructure, prior association with credential stuffing campaigns, or inclusion in blocklists. Most SIEM platforms support automated threat intelligence enrichment at alert generation, but analysts should verify the enrichment has run and check the timestamp — an IP that was clean six months ago when the enrichment cache was last updated may have been added to threat intel feeds since.

The fourth check, available for Microsoft 365 environments, is impossible travel validation. Azure AD Identity Protection performs this natively, but analysts should manually verify the calculation for high-priority alerts: if the user had a successful authentication from Location A two hours before this alert, and physical travel between Location A and the alert location in two hours is physically impossible, then either the earlier authentication or the current one (or both) involves compromised credentials. This is one of the most reliable indicators of account compromise available from authentication logs alone.

Step 3: Account History Review — Establishing the Behavioral Baseline

Understanding whether a suspicious authentication represents a genuine anomaly for this specific account requires reviewing the account’s authentication history against a defined baseline window. The investigation should not treat a suspicious login as anomalous in isolation — it should compare it to what is normal for this user.

For Microsoft 365 environments, the Azure AD sign-in log provides the baseline. The analyst should query the sign-in log for the past 30 days for this specific account, looking for: the locations from which the user normally authenticates, the devices and device compliance states associated with normal authentications, the time-of-day pattern of authentications, and any prior risk events that were generated and how they were resolved. A user who has never previously authenticated from outside the client’s home country presents a different risk profile than one who authenticates from multiple countries weekly as a normal pattern.

For on-premises Active Directory environments, the domain controller Security Event Logs provide the equivalent baseline, though the query tooling is different. The analyst should pull Event ID 4624 (successful logon) and 4625 (failed logon) records for the account across the past 30 days from the domain controller logs in the SIEM, filtering for the workstation name and source IP fields to establish the normal authentication pattern.

The account history review should specifically look for recent password change events (Event ID 4723 in Active Directory, password change events in the Azure AD audit log), recent MFA method changes, recent mailbox permission modifications in Exchange Online, and any recent administrative actions taken by or for this account. An attacker who has compromised an account will frequently attempt to change the password to prevent the legitimate user from regaining access, add a secondary MFA method they control, or create inbox rules that forward email to an external address — all of which leave audit trail evidence in the logs.

Step 4: Post-Authentication Activity Review — What Did the Session Do?

For successful authentications that survive the triage and account history review with elevated risk indicators, the most critical investigation question is: what did the session that followed this authentication do? A successful attacker authentication that was followed by no activity — perhaps because the attacker was testing credentials or was interrupted — is a different response scenario than one followed by mailbox access, file downloads, or further lateral movement.

For Microsoft 365 environments, the Unified Audit Log is the primary source for post-authentication activity review. The analyst should query the UAL for all events associated with the account in the 4-hour window following the suspicious authentication, looking specifically for: email access events (MailItemsAccessed in Exchange Online), file access and download events in SharePoint and OneDrive, mail forwarding rule creation (New-InboxRule events with ForwardTo or RedirectTo parameters), OAuth application consent grants, Teams conversation access, and any administrative actions performed using the authenticated session.

For hybrid environments with on-premises resources, the post-authentication activity review extends to SMB file share access logs (Event ID 5140 and 5145 on file servers), VPN session activity if the authentication was via VPN, and any resource access events on application servers that are covered by application logging.

The post-authentication activity review frequently reveals the answer to whether the alert represents a genuine compromise. An authentication from an anomalous location that was immediately followed by bulk email access across multiple mailbox folders, a new inbox forwarding rule, and 40 file downloads from a SharePoint library containing financial documents is not ambiguous. An authentication from an anomalous location that was immediately followed by a failed MFA prompt and no further activity may represent a credential stuffing attempt where MFA successfully blocked access despite valid credentials.

“The authentication event is the door opening. The post-authentication activity review tells you whether the person who walked through that door was the legitimate user or an attacker, and if an attacker, what they did in the environment before detection. This is where the investigation becomes forensic evidence.”

Step 5: Lateral Movement Check — Has the Compromise Spread?

If the investigation to this point has produced evidence consistent with a genuine compromise, the lateral movement check determines the scope of the incident. The median time from initial access to lateral movement in SMB environments is approximately 10 minutes according to recent threat intelligence data, which means that by the time an analyst reaches Step 5 of this workflow, lateral movement may already have occurred if the initial authentication was not detected immediately.

The lateral movement check queries authentication logs for other successful logins originating from the same source IP as the suspicious authentication, or for authentications using the compromised account to resources beyond the user’s normal access pattern. In Active Directory environments, Kerberos ticket issuance logs (Event ID 4768 and 4769) reveal which resources the compromised account requested access to following the initial authentication. Network authentication events (Event ID 4624 with logon type 3, indicating a network logon rather than an interactive logon) on systems other than the user’s normal workstation are a reliable indicator of lateral movement using the compromised account.

For cloud environments, the lateral movement equivalent is privilege escalation and cross-service access. An attacker with a compromised M365 user account may attempt to access Azure resources if the account has Azure RBAC assignments, may attempt to register new OAuth applications to maintain persistent access, or may attempt to enumerate other user accounts and their permissions to identify higher-privilege targets. The Azure AD audit log and the Unified Audit Log together provide the visibility needed for this analysis.

The lateral movement check result determines the containment scope. A compromise confined to the initially authenticated account requires account-level containment. A compromise that has spread to additional accounts or systems requires broader containment actions and triggers a full incident response process rather than a single-account remediation.

Step 6: Disposition Decision — True Positive, False Positive, or Inconclusive

The disposition decision closes the investigation and determines the next action. There are three possible dispositions, and the standard for each should be clearly defined in the SOC’s operating procedures.

A true positive disposition means the investigation has produced evidence that the suspicious authentication represents a genuine compromise or an in-progress attack. The evidence threshold for a true positive should require at least two independent corroborating indicators — for example, an impossible travel flag combined with post-authentication mailbox access that is inconsistent with the user’s normal behavior. A single anomaly indicator without corroboration generally does not meet the true positive threshold, though it may meet the threshold for a false positive exclusion if the explanation is clear and verified.

A false positive disposition means the investigation has produced a satisfactory, documented explanation for the suspicious authentication that is consistent with legitimate activity. The explanation must be specific — “user confirmed they were traveling in Germany for a client meeting” is a valid false positive disposition; “could not find evidence of compromise” is not. False positives should be documented with enough detail to inform detection rule tuning — if the same scenario is generating repeated false positives, the detection rule needs adjustment.

An inconclusive disposition means the investigation has not produced sufficient evidence for either a true positive or false positive determination. This disposition requires escalation to a senior analyst, not ticket closure. Inconclusive dispositions are often the result of insufficient log coverage — if the post-authentication activity window is empty because the client’s Unified Audit Log was not enabled or the relevant log sources are not being collected, the analyst cannot clear the alert with confidence.

Step 7: Containment Actions for Confirmed Compromises

When the disposition is true positive, the containment sequence must be executed rapidly and in the correct order. The sequence matters because actions taken out of order can alert the attacker, destroy forensic evidence, or result in incomplete containment.

The correct containment sequence for a compromised M365 account begins with revoking all active sessions using the Revoke-AzureADUserAllRefreshToken command or the equivalent portal action. This terminates any active attacker session without yet alerting the attacker that detection has occurred, because the session termination appears as a normal token expiry from the attacker’s perspective. Immediately following session revocation, disable the account rather than resetting the password as the first action. Account disablement prevents re-authentication while preserving the audit trail of the compromise intact. Password reset comes after the forensic review is complete, not as the first containment action.

Any inbox forwarding rules, OAuth application consents, or MFA methods added during the compromise window must be identified and removed as part of the containment action. These are the persistence mechanisms that allow an attacker to maintain access even after the initial credential compromise is remediated. A compromised account that has been password-reset but still has an active forwarding rule sending email to an attacker-controlled address has not been fully remediated.

If lateral movement has been confirmed, the containment scope expands to include all compromised accounts and any systems the attacker accessed. In ransomware-precursor scenarios — where the investigation suggests an attacker is performing reconnaissance before deploying ransomware — network segmentation and broader containment actions may be necessary, and the escalation path moves from SOC analyst to incident response leadership.

Step 8: Client Communication and Documentation

Client communication following a confirmed compromise is the step that determines the client’s perception of the SOC’s value in the incident. A client who finds out about a compromise from their own users before hearing from the SOC has experienced a communication failure, regardless of how well the technical containment was handled. The communication protocol should specify who is notified, with what information, at what point in the investigation, and through what channel.

For a confirmed compromise, the client’s designated security or IT contact should be notified at the point of true positive disposition — before containment actions are taken if possible, or simultaneously with containment if the urgency of the situation does not allow for pre-containment notification. The notification should clearly state: what was detected, what evidence supports the conclusion that this is a genuine compromise, what containment actions have been or are being taken, and what the client needs to do (if anything) as a result.

The incident ticket should be closed with a complete investigation timeline documenting every step of the investigation workflow, every data source consulted, every finding at each step, the disposition reasoning, the containment actions taken with timestamps, and any recommended follow-up actions. In a white-label SOC context, this documentation is what your internal team reviews before delivering the post-incident report to the client, and it is what demonstrates the investigative rigor that justifies the managed security service investment.

Suspicious login investigation done with this level of methodology is the operational capability that separates a SOC that protects clients from one that generates reports. The 61% of breaches that start with compromised credentials represent the opportunity — and the obligation — to intervene at the earliest possible point. Every minute of attacker dwell time that this methodology eliminates is direct, measurable security value delivered to the client whose credential was targeted.