Hacked email account? - Contacts receiving a flood of fake invoices

[Rigo]

Customer is on GoDaddy.
Scam invoice messages are sent from their email address to their contacts, what's the best steps to mitigate this please?
GoDaddy support apparently says their settings are secure, so how can this happen?
I realise their credentials might have been pilfered through some breaches somewhere at some stage, but the scam emails would have to be sent through the GoDaddy system?
They said there were no traces of the the scam message in the Outlook Sent items.

 

[lan101]

This might be a more sophisticated attack but I've had a few clients that had a similar issue in the past and it seemed like changing the email password to something much more secure stopped it. These were usually standard gmail/hotmail/yahoo accounts though.

 

[Rigo]

The customer sent me the attached pic, not sure whether it's in anyway meaningful

 

[xrobwx71]

what's the best steps to mitigate this please?

I kind of favor that blue link "Look unfamiliar? Secure your account."

 

[John Kennedy]

Fairly common issue these days. Usually token theft. Sometimes it can be worse, and GoDaddy's security is laughable. Had a client that despite resetting the password and MFA, revoking all sessions, and making sure they weren't logging into their account anywhere on a web browser, they kept getting their account taken over. I had to migrate them away from GoDaddy to fully resolve the issue.

 

[Rigo]

I kind of favor that blue link "Look unfamiliar? Secure your account."

Thanks, I'll ask them to go through it and do as needed.
They seem to be relatively savvy.
Could you please comment whether those entries might have anything to do with the problem or whether they are just regular events?
I'm clueless with MS 365 admin

 

[Rigo]

Fairly common issue these days. Usually token theft. Sometimes it can be worse, and GoDaddy's security is laughable. Had a client that despite resetting the password and MFA, revoking all sessions, and making sure they weren't logging into their account anywhere on a web browser, they kept getting their account taken over. I had to migrate them away from GoDaddy to fully resolve the issue.

This is indeed the second or third time this has happened to them and they are totally open to the idea of transferring away from GoDaddy.
Will do that after resolving the current issue

 

[fincoder]

Could you please comment whether those entries might have anything to do with the problem or whether they are just regular events?

Well assuming the customer is in Australia, I would say the signins from Texas at 4-5am AEST are very suspicious.

 

[timeshifter]

Whenever I run into this I get a copy of what the recipient got and copy and paste the headers into Claude (preferred) or ChatGPT and ask it to tell me if it really came from the sender and to basically do the hard stuff for me.

 

[Rigo]

is in Australia

yep
Thought so about Texas but since sometimes geolocation for internationally connected systems can be not quite so accurate

 

[Rigo]

Whenever I run into this I get a copy of what the recipient got and copy and paste the headers into Claude (preferred) or ChatGPT and ask it to tell me if it really came from the sender and to basically do the hard stuff for me.

I think everyone was instructed to delete and forget, so not sure whether there'd be any left.
As of now it appears that changing the pwd has made a difference.

 

[HCHTech]

Enforce complex passwords, Change account PW, Reset MFA, enable GEO-IP fencing if you can, create transport rule that doesn't allow incoming emails that are FROM your domain but originate externally, there are lots of things to do to tighten up security on the tenant. Since it's GoDaddy, some of those things might have to involve their support.

 

[YeOldeStonecat]

Often see logins from areas of major data centers (such as...Texas, Virginia, California, New York, etc).

Crack open Entra sign in logs for the user...often see "MFA previously satisfied by token" if it's token theft.

 

[Rigo]

Whenever I run into this I get a copy of what the recipient got and copy and paste the headers into Claude (preferred) or ChatGPT and ask it to tell me if it really came from the sender and to basically do the hard stuff for me.

I might need your help if ok in selecting from the header what to submit to the chatbot.
One of the correspondent still had a copy of the message. This particular one actually interacted with the scammer who guided him to also get infected.
Below is the header of the message my client forwarded to me from his conversation with his customer, not sure whether the relevant part is in there:

Return-Path: <Andy@stabc.com.au>
Delivered-To: info@cmss.com.au
Received: from syn04be.syd6.hostyourservices.net
by syn04be.syd6.hostyourservices.net with LMTP
id OO6bLqSQAWrG2wsAiV8GCQ
(envelope-from <Andy@stabc.com.au>)
for <info@cmss.com.au>; Mon, 11 May 2026 18:17:40 +1000
Return-path: <Andy@stabc.com.au>
Envelope-to: info@cmss.com.au
Delivery-date: Mon, 11 May 2026 18:17:40 +1000
Received: from mail-australiaeastazlp170120004.outbound.protection.outlook.com ([2a01:111:f403:c40d::4]:18513 helo=SY5PR01CU010.outbound.protection.outlook.com)
by syn04be.syd6.hostyourservices.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.99.2)
(envelope-from <Andy@stabc.com.au>)
id 1wMLpa-00000003JW6-1bEV
for info@cmss.com.au;
Mon, 11 May 2026 18:17:40 +1000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none;
b=p4mNo55mMSXjR+o4XsGugP+2GT3+du9iq8h8UpELAZmEBuo4fqHhexQsbmP72G5xjBrcffd79n6eVoiaN4PhQmftEcRWKnMJnbe/DdXeh6EspInz9Szwur0JE2PaU5wWnuG7pI0ey864p+mWmvoADj8OvXv8UV2+fBGEeqgnqenWPE0lyawRECKgLOyUtQUTYnIpR9fHzzyPJ7GhxID8ziY21zxliqOFOXGv9hLif0R7AAe5SD7YmQok91wDp3d+K/pxw7/6u0/3otYLhHF8bncogBmyelL9OKDj7GWO9QACtGifvIK56dMfvMSVrF8zbdVeCD1LpjWEVaq5T+pI7A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector10001;
h=Fromate:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=cItyJKyKatELtg4Ovf0FA0yMSRB6o2NN0xmWhfX3v6s=;
b=lXKYRqOTOUZxZQxJf6THBKRcqb+c0L92oKiHiUhgZjmj0wdVCCZQh7svW9yy0O20jJ8H0cfpl8guO7HT9vwE2kITJDbImTep3iqIYwk6YzIuNAuV2ywMASZxY1wA+FMvq225kKL/wClGllG1oNWuYgWAUG1VXxE6h2kaW+FzC196QGl+9PYC9Ro6QALg/Mso27vPLQRmkuamtgt4yjSDM+ugxVV57xmi8tM8Q8S2dsYWt9fk+XSJ7GCu+unmnlK0511Vlr3A7ZUH3cEa6yD0M15M9R11deyxBOCgab3ZvBXL/4KdocKs9fRsoijYoJHTjBv7wr9gH1DVuqKtqj8mEQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
smtp.mailfrom=stabc.com.au; dmarc=pass action=none header.from=stabc.com.au;
dkim=pass header.d=stabc.com.au; arc=none
Received: from SY5P282MB4918.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:26e::17)
by SY7P282MB6300.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:330::5) with
Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9891.15; Mon, 11 May
2026 08:16:55 +0000
Received: from SY5P282MB4918.AUSP282.PROD.OUTLOOK.COM
([fe80::ddef:294c:d38c:1c00]) by SY5P282MB4918.AUSP282.PROD.OUTLOOK.COM
([fe80::ddef:294c:d38c:1c00%6]) with mapi id 15.20.9891.021; Mon, 11 May 2026
08:16:55 +0000
From: Andy <Andy@stabc.com.au>
To: "info@cmss.com.au" <info@cmss.com.au>
Subject: Fw: STA Invoice - Issued
Thread-Topic: STA Invoice - Issued
Thread-Index: AQHc2/uSc+psBFCGA02nQBz0SKr7DLX+T3TggAABSwyAAOzpK4AAuMgSgAiOLqE=
Date: Mon, 11 May 2026 08:16:54 +0000
Message-ID:
<SY5P282MB4918C5EB727878EB6E35C08BFA382@SY5P282MB4918.AUSP282.PROD.OUTLOOK.COM>
References:
<SY5P282MB49188CACFED103E040460132FA312@SY5P282MB4918.AUSP282.PROD.OUTLOOK.COM>
<MEYP282MB346416E7193DB061D74097B78B312@MEYP282MB3464.AUSP282.PROD.OUTLOOK.COM>
<SY5P282MB49186DE80F07572AF3618968FA312@SY5P282MB4918.AUSP282.PROD.OUTLOOK.COM>
<B769DC0E-7560-4359-B125-0E23507F8103@abolelec.com.au>
<ME0P282MB493086090F4E0DE37D1FB766FA3E2@ME0P282MB4930.AUSP282.PROD.OUTLOOK.COM>
In-Reply-To:
<ME0P282MB493086090F4E0DE37D1FB766FA3E2@ME0P282MB4930.AUSP282.PROD.OUTLOOK.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels:
authentication-results: dkim=none (message not signed)
header.d=none;dmarc=none action=none header.from=stabc.com.au;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: SY5P282MB4918:EE_|SY7P282MB6300:EE_
x-ms-office365-filtering-correlation-id: eb992695-7752-408c-4251-08deaf35a9c2
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam:
BCL:0;ARA:13230040|376014|69100299015|366016|3109299003|1800799024|7049299003|19033499003|38070700021|13003099007|56012099003|22082099003|18002099003|8096899003|3613699012;
x-microsoft-antispam-message-info:
QFP/LCWnCk7+Hkp1rJpbkhlnFbiO2izEdqgpsEzcKvC/4+B/q6aHtyTQKEUGPfQMkkLvXbYiaWrClhHeBHO+rqhAURJd+ClXPBVi/ga7/coMJJuU1hleR5iXWhiNhy5vdSXDCVTiF/UgvteIPwelrkhJUAWGeSog0oKwo1+wZJqIFxXH27sSgaxEakkkSkza1pBfunJxEwnLLOAUwt1fz6lf66PWbq4Lmhn7YRLYgaHzihGXOmJlzAbUSHPq3it6lTAx/NbzXWiXchOUaju67yysg6lSmxyADFLSWr+d3stVHYNKvr69VDlTAR+xX+owyf/1yoD+riXuD8RkoMMjCIwViy/9i1bGyXuA1n/BYpjUr6fBRQAUETMXvGBnOYPKiKkqW7XhwqNFwu8YSm3SNOAw+zOUo52nwpX5zH14sMmyLNd1KqmX1dX1XyRSA/QlSQhTzUBUZgEJMpjM8aBho9pSSGmFgHydGNWr3tZeX+v0+Y+QJXpovT5xErr2DHW6C1agenqiR7MT3hrsO1t+O+dosCcVHO3fkSSFSrseyYAZPNm3N4y9ZltQMvbyJtt0y6ikXLapjZISJahKH+fKgLGWSEuUioL9g1t2K3Eg63OfFjO/GKDJ3xgkDKgEkg5qkX3L8hpp61MTHBfx48AyZt2/lnhAk3nEL9NYBGP7GGaXpZFYXq5clYjMDVae+IY2ffDofiTa2dcBnmpGAuub9g==
x-forefront-antispam-report:
CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SY5P282MB4918.AUSP282.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS13230040)(376014)(69100299015)(366016)(3109299003)(1800799024)(7049299003)(19033499003)(38070700021)(13003099007)(56012099003)(22082099003)(18002099003)(8096899003)(3613699012);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0:
=?utf-8?B?K0VENUxLZWJRelJOVGkwVWlSVGFET2N1NWJaYzV3c3c3WlVoQWZqM0d6cFM5?=
=?utf-8?B?ME1WQXpqODZDNHFLYjFaSlZSOVNvVHhmeS8wcG55TDFwVjFQTnhrVFNxUERS?=
=?utf-8?B?WnVncGFZZ0pOYVJBYzRKZmk3Q2NFcFRta1FDWGVVOFBvckd5d0RkbC9XNlNh?=
=?utf-8?B?NFdhM205M3NWQTJLYVc4ZGt0N3dwRVBhaFpZME4xdFdIYVJsdFp2VGhYUUxm?=
=?utf-8?B?SHlFSmZDUmNPa21yd3hZK1pMU2p5RHkrc0VqR25yUURyMDBlQ3ZxNVk5UW5y?=
=?utf-8?B?bWx5ZEI0WXd2dXpVWU5aNDd6Qi92MXI1QVc5SGpBUnNJeG9MY3p4c2l3VURR?=
=?utf-8?B?ZXdBYk8rclphaFJWSDR1a0hkbFBLenhmcWoydytNWk5sdmZQNnY0SkttTGx1?=
=?utf-8?B?SnpnQ1ZTR0ZQUTdzanlLbkVLQlBKRjgxOFpTaHlJd0I2R29wYllpZjhuTjBC?=
=?utf-8?B?M2pBdEZRTDZGT2dSc1EwdmxPOUJpM0pyeFg3dHpPSlcvdnh5ZEtUbGtwTkVP?=
=?utf-8?B?S0FMTStpSUdmbHBpazR5RVp1bzQyY1lhNkJUT04vSzFsYnRUT1JvcDNNTy9z?=
=?utf-8?B?ZEtORW9INWd6WkZPTjA3UUR0Zm1vOHgxK1FmK2JIZm1QMmZTRDJxYkg5UXZF?=
=?utf-8?B?TndZQXk3dXdoVU1oUTMvWnl4MkRyNk1YdW1LUFd3RWd5dzhmK0htTGc0eE1r?=
=?utf-8?B?YlJBcTBiU0hoRGp5VUFMM0I3UDdUS1R6OWZ6N25QTDBERkovLy9kVTV5Y1Bz?=
=?utf-8?B?QzZRdTNsTDYxdVBzTyt3VlZ2dk5GRG52ZXM3ckpsN2pMSElBaUlRelh6V1hG?=
=?utf-8?B?WUk4YmlwbkZYVjBNb0tWeU9POWRRUXZSdTJnU08xdnhtcHd3Z0lVcUtXWE95?=
=?utf-8?B?Z2NVcWpiOUNzeXpYdTR6SjNCMEpzM0NjS0ExQWo0V1NVTVJrWVBXMTZNUTF5?=
=?utf-8?B?NjFsNkJNZ1BxdnBsSWxSYzd1SWdoV242ckN0bXpIWXRBS3dVanlyU0ZEU3J5?=
=?utf-8?B?VDhzcTFSb2ROcnYvaDcrN1JySkRjdWQvVWZxZjkxYVd1azN0dFhoLzNXN0Q2?=
=?utf-8?B?YXZ6UTZpT0t5dGIrT1RlUmNJaTdPOVpzOFNLNkhpYlBhRncrOEFMYTl0R1dM?=
=?utf-8?B?R09yb2hUVHVYQ2xkRG9TYXZ4bXBBdDhZSE9WU0ViQk5hM3VNdnpvRnM3Y0Jo?=
=?utf-8?B?dS9xRDlFMEIxTXg4MjYrdlp6RUlGZ3QzaDdNanVZQW0xUjU1aFBjbDVoazho?=
=?utf-8?B?QnJocTk5MXZ4YTF4bVlydG4wYlVZZnZOQ1psUTFpMXRybTFGa2FiRG1xdWta?=
=?utf-8?B?T1NUNVBrZmpPWG9nZklydWpYdUtkRUFXbmo4TEVTM2UwK0c2ZlpZWHhBbjJw?=
=?utf-8?B?YmYydHY2LzIwdWt4emRxU2U3ZWs2K01SRHpaSk01b2xURXVhb2puT29JWVdI?=
=?utf-8?B?TmxoMDh5ei8wcWtnOUdhbXd3elRxV3NwSzczY3pzL0V2MXVQbXVIUUhtVUF2?=
=?utf-8?B?MWNlaklaZ0pyd0pzWEJYVFdlUGZnbzEyRTl1aFJmdTZhaE9wbVJEU21qc3Ro?=
=?utf-8?B?VXFmTzdZcWFyNHJxbVdwOGVwR1JOSndIaXl6SFFweHJ1bGRJTFN1WTVwZ0U4?=
=?utf-8?B?ZHlmSmc4T1hpb1JwMUtoWWJXS0lKSWd3cnRpSzlMdFBpaU0zdjVyNnB5WXdH?=
=?utf-8?B?WEJJWXc0RS9YYTZUZi9wWkFwK2VoM3U3SmpsZ1lXOXhXQ0FGSlphbnc4aytr?=
=?utf-8?B?SmJmVnFPQlRGVHcyaENVSWFOV2Z6UHJxSFFHa0x5MWxxUVU5aFBydERtUU4x?=
=?utf-8?B?b3JsdHQ5RW54eTBiT2RkbDZFaTY1eTNNVFlXd0p1K1A0WEdqZ3ZrNDF2Ujcw?=
=?utf-8?B?YXZHdFFEZUZFZ3dWbHJJNEgyUXZRR3ZsOEs0Y1VyTUtUc3pjaDhoWjVudzlx?=
=?utf-8?B?UDBST2ZZNDZuMEJ1Rm5sYTNSSEp2eDdaaG9FSEtZZWZMRmx3Y0tBNjNxSFhZ?=
=?utf-8?B?WmFRd0k0VUxTVTVIMUpkWWxNZ1dnak1Ibk8zSU1SYWR5QzR5UkRvR3NSdGxC?=
=?utf-8?B?QURkTWFhdDZ4a1UwQnkzeWNSVVZuR28xL2lrbTIrOU1vWWZFMmYwWGp5UTky?=
=?utf-8?B?VElTNDVvQVJVQ29xNTBDNXJaaUxYV0x2MWV3MW4zZXVGWkh2YVBjelorNXE3?=
=?utf-8?B?OFlUd0RZT0ppajJlT2tyY0dXaTArYWJjMHFRVFJ0djRYMVZOa25zMVQvQmpO?=
=?utf-8?B?RjZSVDFzMVFYMHNTc1VaRWxxUG01dEpZSENteWFsMXF2ZHZQQXBFRC9uZzRZ?=
=?utf-8?Q?5CkEZwQLh28OdncmXc?=
Content-Type: multipart/alternative;
boundary="_000_SY5P282MB4918C5EB727878EB6E35C08BFA382SY5P282MB4918AUSP_"
MIME-Version: 1.0
X-OriginatorOrg: stabc.com.au
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SY5P282MB4918.AUSP282.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: eb992695-7752-408c-4251-08deaf35a9c2
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2026 08:16:54.9357
(UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 22e8a8b7-b305-4bc9-8471-7c20a973860f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 9NNF1GXq0aomciBrNJu5ouz8SBzy9AE/GhykhalsrrOfQtQfCOLtj9kdS4ToRr5G+7QgJkWYMtxXY0iGG/eO6w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY7P282MB6300
X-Spam-Status: No, score=0.8
X-Spam-Score: 8
X-Spam-Bar: /
X-Ham-Report: Spam detection software, running on the system "syn04be.syd6.hostyourservices.net",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
root\@localhost for details.
Content preview: here is the email trail with Andrew Bolitho where the hacker
responded below before we could let him know. Thanks Jess
Content analysis details: (0.8 points, 5.5 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.5000]
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
blocked. See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information.
[URIs: permassist.com.au]
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 HTML_MESSAGE BODY: HTML included in message
0.0 KAM_DMARC_STATUS Test Rule for DKIM or SPF Failure with Strict
Alignment
X-Spam-Flag: NO

 

[Rigo]

Often see logins from areas of major data centers (such as...Texas, Virginia, California, New York, etc).

Crack open Entra sign in logs for the user...often see "MFA previously satisfied by token" if it's token theft.

Thx, but not sure how to actually go about doing this.
They are on a M365 Standard account, whether that would have access to what you're suggesting.

 

[timeshifter]

Claude said:

"
The email itself passed SPF, DKIM, and DMARC — meaning this specific forward genuinely came from Andy's real Microsoft 365 mailbox at stabc.com.au. So Andy's account is the one to look at hardest. Either:

• Andy's mailbox was the one compromised (attacker sent the fake invoice from inside it), or
• Andy is the messenger forwarding evidence of someone else's compromise"

I'm not sure who's who in your email. Here's the full response I got from Claude.

https://claude.ai/share/76c77159-e605-42d6-94dd-5f68819ec4c5

 

[frase]

Are there any external forwarding rules occuring? As sounds like a “Mailbox compromise with external forwarding rule.”
The receiver in the middle (the malicious user) will intercept the email in the middle and can edit the email/attachments to suit, then sends through as per nothing occured.

 

[Rigo]

Claude said:

"
The email itself passed SPF, DKIM, and DMARC — meaning this specific forward genuinely came from Andy's real Microsoft 365 mailbox at stabc.com.au. So Andy's account is the one to look at hardest. Either:

• Andy's mailbox was the one compromised (attacker sent the fake invoice from inside it), or
• Andy is the messenger forwarding evidence of someone else's compromise"

I'm not sure who's who in your email. Here's the full response I got from Claude.

https://claude.ai/share/76c77159-e605-42d6-94dd-5f68819ec4c5

Correct in your assessment
Andy @ +++.com.au is the one whose email account got compromised.
Andrew Bolitho @ ++++.com.au is one of his customer who received the fake invoice and followed up with an enquiry with Andy as he wasn't aware of the issue. Unfortunately the query also got intercepted by the hacker.
info@++++.com.au - that's me
Since the email servers are on M365 how could the message be sent through the account without being recorded in the sent items?
They did find some rule had been set which they disabled.

 

[timeshifter]

I'd recommend you head over to claude.ai and put this information in yourself.

Basically it seems that the attacker was working from within Andy's account. Here's what claude told me when I put in your follow up info.

So the situation is:

• Andy (stabc.com.au) — your friend's client. His mailbox is the compromised one.
• Your friend (cmss.com.au) — the IT guy who needs to remediate.
• Andrew Bolitho (abolelec.com.au) — Andy's contact who got the fake invoice, replied to it, and got intercepted by the attacker before Andy could warn him.

This is a textbook BEC. The "hacker responded below before we could let him know" line is the smoking gun — the attacker was sitting inside Andy's mailbox in real time, watching replies come in and answering them faster than Andy could.


What your friend is walking into


The fact that this email from Andy passed SPF/DKIM/DMARC means Andy's actual Microsoft 365 account is sending mail. That's consistent with the attacker either still being in there, or having been kicked out but having left artifacts behind. Either way, the mailbox needs a full BEC sweep, not just a password reset.


The remediation checklist your friend should run (in roughly this order):

1. Force sign-out of all sessions on Andy's account (Microsoft 365 admin → revoke sessions). This kicks the attacker out immediately if they're still connected.
2. Reset Andy's password to something new and strong.
3. Enable / enforce MFA if it wasn't already on. If it was on, check the registered MFA methods — attackers often add their own phone number or authenticator as a second factor so they can keep getting back in even after a password reset. Remove anything Andy doesn't recognise.
4. Check inbox rules— this is the #1 BEC artifact. Look for rules that:
   • Forward mail externally
   • Move messages from specific senders (like Andrew Bolitho, or anything containing "invoice", "payment", "bank") to RSS Feeds, Archive, Deleted Items, or Conversation History
   • Mark messages as read automatically
   Attackers create these so the legitimate user can't see the replies they're intercepting.
5. Check mailbox forwarding at the mailbox level (separate from inbox rules) — both the Outlook setting and the Exchange-level forward.
6. Check connected apps / OAuth grants — attackers sometimes plant a malicious enterprise app so they retain access even after password+MFA reset.
7. Check sign-in logs (Entra ID → Sign-in logs) for unfamiliar IPs, countries, or successful logins from suspicious locations. Note the timeframes — that's the window during which the attacker had access.
8. Review Sent Items and Deleted Items for the period of compromise — what other invoices or messages went out? Anyone else who needs to be warned?
9. Check for new mailbox delegates or full-access permissions granted to other accounts.

The communications side


This part is just as important as the technical cleanup:

• Phone Andrew Bolitho directly (not email — his inbox conversation with "Andy" is poisoned). Tell him: the invoice is fake, do not pay it, and any bank details he received from "Andy" recently should be treated as fraudulent.
• Identify everyone else Andy emails about invoices or payments and warn them out-of-band (phone or text).
• If Andy uses an accounting system (Xero, MYOB, QuickBooks) that's linked to his email, check whether the attacker pivoted there too.
• Andy should consider whether to notify the ACSC / ReportCyber (this is Australia based on the .com.au domains) — it's free and helps the broader pattern tracking even if no money was lost.

One thing worth flagging to your friend specifically


If Andrew Bolitho already paid the fake invoice, that's a different and much more urgent track — Andrew's bank needs to be called within hours, not days, because there's a small window where funds can sometimes be recalled before they're laundered out. The preview line suggests Andrew may have been mid-conversation rather than mid-payment, but worth confirming on that phone call.


Anything specific your friend is stuck on, or is this more of a "what am I looking at" question for him?