Borrowed Trust, Badly Done
tl;dr
Earlier this year we covered the invisible architecture of modern phishing, where a threat actor borrowed trust from legitimate platforms. This case is the same idea done sloppily.
- A compromised, legitimate mailbox sends the lure, so it arrives with real sender reputation.
- The email is highly likely AI generated.
- A two-stage chain (AWS S3 to a Cloudflare-fronted domain) ends in a Google login.
What to do? Enforce phishing-resistant MFA with passkeys or FIDO2 security keys, restrict which third-party OAuth applications can access Workspace data, and verify payment or banking changes using out of band communication rather than the email.
Borrowed sender, AI generated email
The lure came from a legitimate grocery retailer whose mailbox was compromised. It is a real and established sender that inherits the reputation email gateways trust, so there is no lookalike domain and no spoof to catch. The subject was "Urgent Review Required – Purchase Order and Invoice Discrepancies," pointing to a link named "United Trading Document.pdf."
Last time, the tell was that the email made small human mistakes. This time it is the opposite. We assess that the body was highly likely LLM generated. It is structurally flawless, hits every business correspondence beat, and favours the polite hedging current models produce. It is also generic where a real dispute would be specific, with PO numbers, invoice references, or amounts.
A sloppy chain of lures
The first landing page sits on AWS S3 at projectorg878990[.]s3[.]us-east-1[.]amazonaws[.]com/index.html, dressed up as an "RFP Access Portal" with a trust badge reading "Community Charter School, Verified Community Partner Portal." Submitting an email forwards the victim to purchasesord[.]com, a Cloudflare fronted domain first seen on 25 August 2026. It then serves a legitimate Google sign-in page which uses socket.io to serve the credentials to the threat actor.
As one can begin to see with this chain, none of them agree. A grocery retailer sends an invoice dispute, linking to a trading document, opening a charter school portal, ending at a Google login. The page source explains why. A code comment references swapping in a grant endpoint, and the badge lists the charter school strings. This was a grant or school portal phishing kit repurposed for a financial lure, with the placeholders left in.
Additional infrastructure
Pivoting on shared characteristics of the chain surfaced a small cluster of related domains, such as accessdocuments[.]us. While we assess with low confidence that these indicators are tied to the campaign described above, we assess with high confidence that all are likely malicious. The full list is in the IOC table below.
Taking action
Similar to actions we mentioned in our previous blog, the following security considerations can help prevent and respond to a BEC attack:
- Enforce phishing-resistant MFA. Require passkeys or FIDO2 security keys, especially for admins, finance, and executives.
- Restrict OAuth apps. Use an allowlist model and review newly authorized applications after a suspected compromise. OAuth access can survive a password reset.
- Contain the account, not just the password. Suspend the user or revoke active sessions and tokens.
- Check for persistence. Review forwarding rules, filters, delegates, "send mail as," recovery details, POP/IMAP access, and recent sign-ins. Block external auto-forwarding at the domain level.
- Verify payment changes out of band. Use trusted contact details already on file and require dual approval for banking changes.
- Context-Aware Access. If your edition supports then use it to restrict Gmail and Drive based on device, IP, and location. It is not a replacement for phishing-resistant MFA and will not necessarily eradicate a threat actor who already holds a valid session.
- Build the skills before you need them. Knowing the controls is one thing. Knowing what the compromise looks like in the logs is another. Our Incident Response in the Google Cloud course helps you investigate these kinds of phishing attacks and more.
IOCs
About Invictus Incident Response
We are an incident response company and we ❤️ the cloud and specialize in supporting organizations in preparing and responding to a cyber attack. We help our clients stay undefeated!
🆘 Incident Response support reach out to cert@invictus-ir.com or go to https://www.invictus-ir.com/24-7
Be ready for the next cloud incident.
