AOL Account, Government SharePoint, Fake Microsoft Login: A Credential Harvest in Three Steps

The message arrives from an AOL account. The display name matches a real employee listed in the public government directory of the receiving organization. The body contains one thing: a SharePoint link.

To a recipient scanning their inbox, this looks like a colleague sharing a file through the municipal M365 tenant. It is not. The sender has no affiliation with the organization. The name was borrowed from a public roster. And the SharePoint link is a credential harvest.

How authenticate.aspx Becomes a Phishing Page Without Any Phishing Infrastructure

Microsoft 365 SharePoint tenants include a native re-authentication endpoint: authenticate.aspx. When a sharing link includes this path, SharePoint prompts the visiting user to sign in to a Microsoft account before granting access to the shared resource. This is standard SharePoint behavior for externally shared documents and protected folders.

An attacker who knows this can craft a SharePoint-hosted URL that routes a victim through the authenticate.aspx flow on a legitimate government tenant. The login page the victim sees is a real Microsoft login page, served from Microsoft infrastructure, with a legitimate government tenant domain visible in the URL bar. There is no attacker-hosted fake login page. There is no lookalike domain. The page is real. The only thing that is not real is the reason the recipient was sent there.

Credential harvesting operations that exploit legitimate cloud infrastructure, often called living-off-the-land attacks, are increasingly common because they eliminate the infrastructure footprint that threat intelligence systems use to block phishing. There is no attacker domain to flag. There is no newly-registered hosting provider to track. The credential page is hosted by Microsoft, which is on every organization's trusted list.

The link carried in this message pointed to a SharePoint path under a U.S. municipal government M365 tenant. The path included authenticate.aspx as a required step before any resource would load. Had the recipient clicked and entered credentials, those credentials would have been captured through a session hijack or adversary-in-the-middle relay before the legitimate SharePoint session could complete.

The Borrowed Name and What It Does

The display name shown to the recipient was drawn from a real person associated with the municipal government. Government staff directories are frequently public by statute or by practice. Org charts, meeting agendas, public records, and LinkedIn are all sources an attacker can mine in minutes to find a plausible name to display.

The display-name spoofing technique works because most mail clients surface the display name prominently and the actual sender address secondarily or not at all, depending on the client and the reading context. Mobile clients in particular often show only the display name. A recipient who trusts the name has already accepted the premise before they assess the address.

The actual sender address (morris.ophelia@aol[.]com) has no connection to the government organization, no shared domain, no organizational affiliation. It is a consumer AOL account. That account passed SPF, DKIM, and DMARC because AOL runs legitimate outbound mail infrastructure and this message legitimately originated from it. Authentication, again, is working as designed. The issue is that authentication says nothing about the relationship between the sender and the recipient.

See Your Risk: Calculate how many threats your SEG is missing

What the Behavioral Layer Flagged

IRONSCALES Adaptive AI returned a 50% confidence score on this message. The score reflects a genuinely borderline case at the individual-signal level: the authentication was clean, the link went to a legitimate Microsoft tenant URL, and there was no malicious file. What drove the flag was the combination.

A consumer AOL account had no prior communication history with this government mailbox. The display name matched a real person from the organization's directory, but the account sending the message was a consumer service with no organizational relationship. The link destination used a re-authentication path in a context where no legitimate SharePoint share had been initiated.

No single signal is conclusive. The full behavioral profile was.

Defending Against Living-Off-the-Land Credential Attacks

The Microsoft Digital Defense Report 2024 identifies adversary-in-the-middle and session-hijacking techniques that exploit legitimate cloud authentication flows as a rising threat vector. The Verizon DBIR 2026 notes that credential theft continues to be the most common outcome of phishing across all industry verticals. CISA guidance on phishing advises that users should treat any unexpected re-authentication request with skepticism, particularly when it arrives via an unsolicited email. The MITRE ATT&CK framework classifies this delivery method as Spearphishing Link (T1566.002).

For defenders, the practical takeaway has three parts.

Consumer-domain senders reaching government mailboxes warrant elevated scrutiny. An AOL account sending to a municipal government address with a document link is a pattern that warrants automated inspection regardless of authentication status. Consumer mail services are not organizational communication channels.

Authenticate.aspx links arriving in unsolicited messages are a detection signal. Security platforms can be tuned to flag SharePoint URLs that include re-authentication paths when those links arrive in messages with no prior sender-recipient relationship. The path pattern is not malicious in isolation; in this context, it is a reliable indicator.

Verify before you authenticate. Any unexpected re-authentication prompt, even on a page that looks completely legitimate and carries a recognizable URL, should prompt a direct confirmation with the sender through a separate channel before credentials are entered. Legitimate SharePoint shares do not require this kind of verification; they cost nothing. A compromised M365 credential costs considerably more.

---