Microsoft 365 security, Thailand

They Had MFA. The Attacker Logged In Anyway.

By Alex, Founder of Raso Cyber. Published in partnership with Digigen.

Tuesday

The email came from a supplier they had worked with for six years.

It was a quotation, shared through a document link, from a name in the address book that had sent forty other quotations that year. Beam, the IT manager at a Bangkok industrial parts distributor, was not the one who clicked it. The company's operations director was. He was in a taxi on Rama IV, running late, and the link asked him to sign in to Microsoft 365 to view the file.

So he signed in. Email, password, and then the Authenticator prompt on his phone, which he approved without breaking stride.

The document opened. It was a real quotation. Nothing about the experience felt wrong, because nothing about it was wrong. He had authenticated to Microsoft, genuinely and successfully, and Microsoft had issued him a session token to prove it.

The only detail he could not see was that his login had travelled through somebody else's server on the way, and that a copy of the token had been kept.

Ninety seconds later, a machine in a Microsoft Azure data centre in the eastern United States used that token to open his mailbox. No password prompt. No Authenticator push. As far as the tenant was concerned, the operations director had simply opened Outlook on another device, and the multi-factor requirement was already satisfied.

He had. In a sense.

The eleven days nobody noticed

Here is the part that people find hardest to accept: nothing broke.

For eleven days, the attacker read email. That is mostly what they did. They read the finance folder, the supplier correspondence, the payment approval threads. They learned who signed off on what, what the invoice format looked like, which suppliers were slow payers and which were owed money that month. They set up a mailbox rule that quietly moved any email containing the words "bank" or "payment" or "โอนเงิน" into an archive folder the director never opened.

Somewhere in that fortnight they worked out that the operations director's account also carried Global Administrator rights in Microsoft 365. It had carried them for four years, since the migration, because somebody had needed them once and nobody had taken them away.

So the attacker created a new user account. Ordinary name. Looked like a service account. Gave it administrative rights, and from that moment did almost all of their work from the new account rather than the director's, because the new account was theirs and nobody was watching it.

Then they waited for an invoice worth taking.

Monday morning

It fell apart in the most ordinary way imaginable.

A sales coordinator came in on Monday, tried to log in, and could not. Her account did not exist. She assumed she had broken something and walked over to Beam's desk to apologise.

Beam checked. The account was gone. Not disabled. Deleted, and then permanently deleted, which is a thing you have to deliberately choose to do. While he was looking at that, a second person appeared with the same problem.

He opened the audit log and started reading, and the floor went out from under him. Accounts created that he had not created. Licences moved around. Users deleted. And then, when he traced the account that had done most of it, an administrator he had never heard of, created eleven days earlier by the operations director's account at four in the morning.

Beam did what almost everyone does next. He reset the operations director's password, forced MFA re-registration, and felt the relief of having done something decisive.

He was still fully compromised. The attacker did not notice for several hours, and when they did, they simply carried on, because the backdoor administrator account was untouched and the refresh tokens issued to it were still perfectly valid.

By lunchtime the finance manager had a call from a supplier asking why a payment of 1.8 million baht had gone to an account they did not recognise.

What actually has to happen in the first hour

I got the call that afternoon. This is the part of the story that matters most, so I want to be specific about it, because the instinct almost every SME follows is the wrong one.

Do not start by resetting passwords. Reset the password and you have addressed the front door while the attacker is sitting in the living room. What you have to do first is revoke the sessions. In Entra ID that means revoking the refresh tokens for every account you suspect, which invalidates the sessions themselves rather than just the credentials that created them. Until that happens, every other step is theatre.

Then, in order:

1. Find every account the attacker created or touched. Not just the one you found. Sort your users by creation date and read the list with fresh eyes. Anything you cannot explain is suspect until somebody proves otherwise.
2. Check the OAuth consent grants. This is the step nearly everybody skips, and it is how organisations get reinfected a week after they declared the incident closed. If the attacker persuaded a user to consent to a malicious application, that application holds its own access to the mailbox, and it survives password resets, MFA changes, and session revocation. You have to go and look, and you have to revoke what you find.
3. Check mailbox rules and forwarding, for every account, not just the compromised one. Attackers set up rules to hide their own traffic. Ours had been quietly filing away every email that mentioned banking for a week and a half.
4. Preserve the audit log before it ages out. Microsoft 365 audit retention is not indefinite, and the default retention on many SME licences is shorter than the investigation you are about to run. Export it on day one. If you do not have the log, you cannot answer the questions that are about to be asked of you, and some of those questions are legal ones.
5. Then reset credentials, and only then, once the attacker no longer has a live session to watch you do it.

We got all of that done in about five hours. The 1.8 million baht was partially recovered, because the receiving bank was Thai and the finance manager had moved fast. Partially. Not entirely.

The clock nobody knew was running

Somewhere around six in the evening, with the tenant finally clean, I asked the managing director a question he had not been expecting.

Personal data had been in those mailboxes. Employee records, customer contact details, supplier information. Under Thailand's PDPA, if a personal data breach poses a risk to the rights and freedoms of the individuals involved, the company has to notify the Personal Data Protection Committee within 72 hours of becoming aware of it. Failure to notify in time carries an administrative fine of up to 3 million baht, entirely separately from any penalty for the inadequate security that allowed the breach in the first place.

Nobody in the room had known that. That is not unusual. The PDPC has been steadily more active through 2025 and 2026, and breach notification failure was cited in every one of the enforcement cases announced in August 2025. The largest penalty issued so far reached 7 million baht against a company that had failed to appoint a DPO, failed to implement adequate security, and failed to notify within 72 hours.

The clock had started that morning, when Beam looked at the audit log. Not when the attacker first got in eleven days earlier. From awareness, not from compromise. They had until Thursday.

They made it, with a day to spare, because the audit log had been preserved and they could actually describe what happened. That is not a coincidence. The companies that miss the deadline are usually the ones that cannot answer the questions, not the ones that do not want to.

What they bought, and what they still had not fixed

Over the following month the company did what a competent organisation does after a bad experience. They bought properly. Advanced identity licensing, a serious email security layer, endpoint detection and response, and third party backup with email archiving.

It is a good stack. It is better than most Thai SMEs have. And when I reviewed it, I asked one question:

Which of these would have stopped the attack?

The honest answer is none of them, not on their own. The root cause was a stolen session token, and a token replay is not stopped by buying a licence. It is stopped by configuration decisions, and most of them were available in the licences they already owned before the incident:

None of that is expensive. Most of it ships in Microsoft 365 Business Premium. What it costs is a few weeks of somebody's attention and a willingness to look at settings that have not been touched since the tenant was built.

The licences were the easy part.

This is not a big company problem

The tooling used against this company is sold as a subscription. Phishing kits capable of exactly this attack start at around USD 120 a month, and Microsoft has tracked a single kit pushing tens of millions of messages at more than 500,000 organisations monthly. Microsoft has reported a 146% rise in adversary-in-the-middle attacks year on year. In one three day window in April 2026, a single campaign harvested credentials and session tokens from over 35,000 users across 13,000 organisations in 26 countries.

Every one of those users had MFA.

The uncomfortable finding for anybody who thinks their size protects them is this: attackers have worked out that the fastest way into a large manufacturer is through the parts distributor that emails them invoices.

Seven questions to ask your IT provider this week

You do not need to understand token binding to have this conversation. You need to ask:

1. If one of our accounts is compromised tomorrow, do we revoke sessions or just reset the password?
2. Who in this company holds Global Administrator rights, and why?
3. Are we using phishing-resistant MFA anywhere, or authenticator codes everywhere?
4. Can a login from an unmanaged device reach our email right now?
5. How long do we retain audit logs, and could we reconstruct eleven days of activity if we had to?
6. Has anyone reviewed which third party applications have consented access to our tenant?
7. Do we know what our PDPA notification obligation is, and who makes that call at 6pm on a Monday?

If the answers are vague, that is your finding.

If you are also weighing up who should be running your tenant day to day, our guide on choosing a Microsoft 365 partner in Thailand covers the questions to put to a provider before you sign.

Digigen builds and runs the platform. We check whether it is locked.

About the author: Alex is the founder of Raso Cyber, an independent cyber security practice that assesses and hardens Microsoft 365 and Google Workspace tenants for businesses in Thailand and Singapore. This post was published in partnership with Digigen, a certified Google Cloud and Microsoft Solutions Partner.