Coordinated SSPR Reconnaissance Against Corporate Accounts

Executive Summary

On Day 0, an endpoint identity detection platform recorded the main wave: 411 unsuccessful Microsoft Entra self-service password reset (SSPR) flows targeting 404 distinct corporate accounts. The activity used 54 commercial-cloud-hosted IPv4 and IPv6 sources within one generalized hosting network and completed in 43 seconds. A later seven-day Entra review found a related six-account precursor on Day -3 using five sources all reused in the main wave. The timing, account-list consistency, rapid source rotation, and shared infrastructure support a high-confidence assessment of centrally coordinated automation and a probable hostile reconnaissance purpose.

An authoritative Microsoft Graph follow-up covering all 404 accounts through Day +1 found no sign-in from any campaign address, no completed password reset, and no campaign-linked risky sign-in. The exact 43-second campaign produced 404 user-ID submissions and 132 verification-option presentations; the broader Day 0 total of 407 and 135 also includes three later, separate recovery sequences. Those later sequences involved [email protected] stopping after verification options, [email protected] registering/reviewing security information, and [email protected] completing a self-unlock after cancelling a separate password-reset flow. The two completed control actions used MFA, passed Conditional Access, carried no sign-in risk, and matched recent user country/IP behavior. All three require direct owner confirmation, but none currently proves compromise.

95% autonomous investigation. 100% human authority.

TandemTrace AI agents completed 57 of 60 recorded investigation actions autonomously. Human analysts retained assessment approval, escalation, and case-closure authority.

Plain-Language Terms

What is SSPR?

SSPR means Self-Service Password Reset. It is Microsoft Entra’s public account-recovery process that lets a user reset a forgotten password or unlock an account without contacting IT. The user supplies an account identifier and must then prove their identity using allowed registered methods, such as Microsoft Authenticator, SMS, or another configured method.

In the 43-second campaign, automation submitted 404 corporate email addresses to the SSPR process. It did not successfully reset their passwords. However, 132 campaign submissions progressed far enough for Entra to record that verification options were presented. That workflow difference can help an operator identify valid accounts or determine which accounts are eligible for recovery, making it useful reconnaissance for later phishing, password spraying, MFA social engineering, or help-desk impersonation.

Why does cloud hosting appear?

Cloud-hosting providers legitimately rent servers and network capacity to organizations and individuals. Attackers can also misuse rented or compromised cloud infrastructure.

All 54 generalized source labels in this public case mapped to one commercial hosting network. The operator distributed requests across those sources and targeted 404 accounts in 43 seconds, which could reduce the effectiveness of simple per-IP throttling or detection. This does not imply that the hosting provider conducted or knowingly supported the activity. The customer or actor operating the infrastructure remains unknown.

Decision Brief

Key Findings

• Coordinated automation: 411 events occurred in 43 seconds, peaking at 21 attempts and 17 distinct source IPs in one second.
• Deliberate source rotation: Only 14 of 410 adjacent requests reused the same IP. The sources span 37 IPv4 /24 networks and 6 IPv6 /64 networks, but all resolve to a single commercial hosting network.
• Prepared organization-specific target list: 403 of 404 targets follow the organization’s first.last naming convention and all use the corporate domain. Time order has essentially no alphabetical relationship (correlation -0.02), consistent with a randomized list.
• Detector fan-out inflated visible volume: 401 IP/account pairs appear under both endpoint identity detection platform rules. The 812 alerts are not 812 independent reset actions.
• No reset completion: Every individual SSPR alert has raw result Failed. endpoint identity detection platform’s mass-rule narrative explicitly says no password-reset events followed the flows. The mass alert’s raw Success means that the detector matched, not that a reset succeeded.
• Authoritative Entra confirmation: Microsoft Graph returned exactly 404 “User submitted their user ID” audit steps and 132 “User was presented with verification options” steps in the 43-second campaign window. These are workflow-step successes, not password-reset successes. The broader Day 0 totals of 407 and 135 include the three later recovery sequences reviewed separately below.
• Campaign began before the main wave: A live seven-day Entra review found a six-account precursor at Day -3. It used five cloud-hosting addresses that were all reused in the Day 0 wave; two of the six accounts reached verification options and none completed verification or a reset. The same 30-day export also contains two isolated submissions from two later campaign IPs on Day -25. The earliest confirmed coordinated phase is therefore Day -3, while Day -25 is a possible low-volume probe.
• No campaign-source authentication: Across 18,987 interactive tenant sign-in rows, 28,738 target non-interactive sign-ins, and a seven-day source-address hunt, none of the 54 cloud-hosting addresses appeared in an Entra sign-in. log analytics platform also returned zero cloud productivity audit sign-ins for the campaign addresses.
• No confirmed follow-on compromise: No campaign-linked Entra risk detection, endpoint identity detection platform endpoint/identity compromise alert, email security platform threat, password-change timestamp, or completed reset was found through the collection cutoff.
• Not recognized infrastructure: None of the 54 addresses matches the 19 configured authorized/known-scanner addresses. No authorized pentest tool or pentest-node entries are currently configured, so an identity-team confirmation is still required.

Coordination Signals

Two patterns make the event look larger and more complex than a simple series of password-reset attempts: overlapping detections produced duplicate views of the same activity, while the requester continuously rotated infrastructure.

How the Activity Works

1. The operator obtains or generates a list of valid-looking corporate user principal names. The evidence proves possession and use of the list, but not how it was collected.
2. Automation submits each identity to the public Microsoft Entra password-reset workflow. Initiating a flow can create audit evidence even when identity verification is never completed.
3. The operator rotates requests across cloud-hosted IPv4 and IPv6 addresses. This increases throughput and can weaken simple per-IP rate limits or correlation.
4. Response differences or workflow progression may disclose whether an identity exists or is eligible for SSPR. Entra audit data confirms that 132 campaign submissions progressed to “presented with verification options,” demonstrating that the workflow exposed a materially different stage for part of the supplied account list. The logs do not reveal the exact page content seen by the operator.
5. A later campaign could use validated identities for password spraying, targeted phishing, help-desk impersonation, or social engineering intended to make a user approve an SSPR/MFA challenge. No such later stage is confirmed here.

Source Countries and Infrastructure

Country values below are endpoint identity detection platform GeoIP labels for the hosting addresses. They identify likely server regions, not the operator’s nationality or physical location. a commercial hosting provider is a commercial cloud provider, and provider ownership alone is not evidence that a commercial hosting provider participated in the activity.

The infrastructure concentration supports common control: every event reports the same generalized hosting ASN and provider label, is_suspicious_asn=true, and is_common_ip=false. At the same time, is_new_asn=false and is_new_country=false; prior tenant visibility of an ASN or country does not make these particular requests benign.

Evidence Timeline

Authoritative Follow-Up Results

Entra event and compromise review

48-hour closing check at Day +1: A direct Microsoft Graph delta query added 1,183 interactive sign-ins, 2,481 non-interactive sign-ins, and 238 directory-audit rows after the preserved the preserved evidence cutoff evidence cutoff; all pages completed without truncation. It found zero sign-ins from the 54 campaign addresses, zero new target risk detections, and zero new target password-reset, unlock, MFA, or authentication-method mutations. One target sign-in in the combined 48-hour set carried low risk, but Entra had already dismissed it; it succeeded through Conditional Access from unrelated US infrastructure and is not campaign-linked.

Latest Entra delta through Day +1: A further untruncated Microsoft Graph query added 64 interactive and 137 non-interactive sign-in rows. It found zero campaign-source sign-ins, zero new target password/reset/unlock/MFA/security-method audit changes, and zero new target risk detections. Ordinary successful target-user sessions in this delta used unrelated infrastructure and do not establish campaign success.

AlertDeep correlation: 84 AlertDeep documents were created in the same 48-hour window. Only the two consolidated campaign records directly share the campaign source addresses. Five other post-campaign records name members of the 404-user cohort, which is expected for such a broad employee population, but none shares campaign infrastructure. The one MFA-modification record is the already-reviewed security-information registration above; the remaining file-share, SaaS-session, SaaS-download, and endpoint-IOC detections have different sources and no Entra follow-on linkage. No additional AlertDeep provides evidence of campaign-related compromise.

Seven-day SSPR activity review

An authoritative directory-audit review covered Day -6 through Day +1 and returned 647 relevant rows. A separately preserved audit export independently matched the available Day 0 evidence. Ordinary single-user resets, unlocks, and password-policy retries occurred on Days -5 through -1; the only source-correlated multi-account anomalies were the Day -3 precursor and Day 0 main wave.

Start-time conclusion: The main high-volume wave occurred on Day 0, but the related operation started earlier. The strongest precursor is Day -3 because six different targets were submitted in seven seconds from five addresses all reused in the main campaign. Two isolated Day -25 submissions came from two other later-campaign addresses and may be an earlier probe, but their small volume is insufficient to call them a coordinated phase by themselves.

Precursor targets: On Day -3, [email protected] from campaign-source-02 and [email protected] from campaign-source-03 reached verification options. [email protected], [email protected], [email protected], and [email protected] stopped after ID submission. None started or completed verification, reset a password, or unlocked an account. On Day -25, [email protected] and [email protected] each stopped after ID submission from later-campaign addresses.

Priority account review

Containment decision: No blanket reset or mass session revocation was performed. Current evidence does not meet that threshold. Account-specific containment is pre-authorized by this playbook only if any follow-up user denies the observed action or a later query finds a completed reset, unapproved method change, anomalous successful sign-in, or malicious cloud/endpoint activity.

Assessment

Overall judgment: Treat this as a probable coordinated hostile identity-reconnaissance campaign with a confirmed Day -3 precursor, a Day 0 main wave, and confirmed SSPR workflow enumeration, but no confirmed compromise through the evidence cutoff. Three later recovery sequences were reviewed: employee-a stopped at verification options, while the employee-b and employee-c control actions are more consistent with legitimate mobile self-service activity than attacker follow-on. All require direct confirmation. A benign explanation still requires a named owner and approved test record matching the generalized cloud-hosting infrastructure; no matching authorization record was available.

Action Status and Remaining Actions

Follow-Up Hunts

• Closing Entra query: At or after Day +1, rerun the exact 404-user and 54-address query through that time and document any new reset, unlock, registration, risky sign-in, or authentication-method event.
• Three-user confirmation: Obtain explicit confirmation from employee-a for the incomplete recovery check, employee-b for the security-info registration, and employee-c for the self-unlock. Treat denial or non-response under the organization’s incident SLA as an escalation condition.
• Privileged/risk reconciliation: Confirm the current role posture of both registry-priority users and resolve the older medium-risk state that predates the campaign.
• Organizational sources: Search help-desk, red-team/pentest approvals, and mailbox audit systems that are not connected to TandemTrace. Record a named owner and ticket reference.
• Ongoing address watch: Retain all 54 indicators for seven days after the campaign and alert on any successful sign-in or identity-control change. Keep detections source-neutral; do not rely on a provider-wide block.

Detection and TandemTrace Correlation

Recommended campaign rule

Create a source-neutral SSPR campaign rule over Microsoft Entra AuditLogs. Trigger when either threshold is met and the events share a source relationship:

• At least 10 distinct submitted identities within one minute; or
• At least 25 distinct submitted identities within five minutes; and
• The same source IP, ASN, network provider, or a coordinated group of rotating source IPs is observed.

Raise severity when verification options are presented for many accounts, a privileged account is targeted, verification starts or completes, a reset/unlock/authentication-method registration follows, or a subsequent successful sign-in uses a new IP, device, ASN, or country.

TandemTrace correlation pattern

TandemTrace correlates audit records around the triggering event and through a bounded follow-on window. It groups submitted identities across shared or rapidly rotating infrastructure while limiting the stored public case context to generalized campaign metrics.

The model distinguishes a successful workflow step from a completed password reset. Verification completion does not itself prove that a password changed. Unlocks, security-method registrations, and sign-ins remain separately named so the narrative does not inflate one outcome into another.

A controlled replay reconstructed the campaign without exposing raw queries, tenant identifiers, source addresses, evidence locations, or internal storage details. Metrics count distinct affected identities per workflow step to avoid double-counting.

Notes and Limitations

• Calendar dates, clock times, source addresses, provider identifiers, and evidence references are generalized in this public edition.
• This public edition uses synthetic account identifiers and generalized source labels. It must not be used to infer the identity of the affected organization or its employees.
• Authoritative Microsoft Entra audit records were directly queried through Day +1. The requested through the closing-review threshold review cannot be completed before that time and remains an explicit closing action.
• No result in log analytics platform, a reputation service, or a reputation service is not proof of absence or benign intent.
• “Success” on an Entra SSPR progress audit row means that a workflow step completed. It does not mean the password was reset. Likewise, ordinary successful sign-ins by targeted users are baseline activity unless linked by time, source, risk, device, or control mutation.
• The report does not infer the actor’s nationality from server GeoIP and does not attribute the campaign to a named threat group.
• Public reporting shows that SSPR can be abused as part of social-engineering campaigns, but no linkage to a publicly named campaign is claimed here.