Yes. Attackers can sometimes access Microsoft 365 even when MFA is enabled by stealing or relaying an authenticated session, rather than defeating the MFA check itself. A reported campaign used fake sign-in pages to capture session tokens after users completed MFA. Protecting accounts therefore means controlling access, watching for suspicious changes, and having a response plan, not relying on MFA alone.
How can an attacker get into Microsoft 365 after MFA?
"GDS followed up the next day to make sure the door sensor issue is resolved. That kind of attention shows real customer service."
Kawal, professional services
MFA adds a verification step to a sign-in, such as approving a prompt or entering a code. After successful authentication, Microsoft 365 creates a session so the user can continue working without repeating every sign-in step.
In a token-replay attack, a fake sign-in page relays a user's credentials and MFA response to legitimate services. The attacker may then capture the resulting session token and attempt to reuse it. The user may see a sign-in flow that appears ordinary, even though an attacker is positioned to collect the authenticated session.
As The Hacker News reported on October 26, 2026, a campaign used this approach and compromised 97 accounts at 79 organizations. The report also described device-code phishing and social engineering as ways attackers may obtain access. These are the reported campaign's figures, not a prediction of risk to any particular Atlanta business.
Once an account is accessed, the consequences depend on its permissions and the attacker's actions. A mailbox may expose sensitive conversations, be used to send deceptive messages, or have rules changed to hide important replies. An MFA-approved sign-in is evidence that authentication occurred; it does not prove the session remains under the legitimate user's control.
Reported campaign: 97 accounts compromised at 79 organizations.
The takeaway: protect the authenticated session and account changes, not just the password prompt.
What should an Atlanta business review in its Microsoft 365 protections?
Review the rules that decide who can sign in, what authentication is required, and which devices and applications can access company resources. Check that policies cover the accounts and applications employees actually use, including remote access and business-critical services.
Ask the Microsoft 365 administrator to review Conditional Access policies. Confirm which users, cloud applications, and client types each policy covers, and whether the intended MFA or access-blocking requirements apply. Test policy changes against real workflows before broad deployment so a security improvement does not unexpectedly interrupt essential work.
Review authentication methods and sign-in workflows. The report recommends restricting device-code workflows through Conditional Access. Identify which methods and workflows the business needs, and remove or restrict those that are unnecessary. Keep the rationale and policy ownership documented so later changes do not quietly weaken protections.
Limit administrative privileges to accounts and people that need them. Review account permissions, authentication methods, and registered devices when employees join, change roles, or leave. A compromised account with broad privileges can create a larger investigation and recovery effort than one with limited access.
For help coordinating Microsoft 365 administration and security controls, see GDS Technology's cloud services and cybersecurity services. Agree on the specific scope and responsibilities; no single control can guarantee that an account will never be compromised.
The takeaway: treat identity policies as operating controls that need ownership and review, not as a one-time MFA enrollment task.
What signs could indicate a Microsoft 365 account was compromised?
Look for sign-ins, devices, authentication methods, or account changes that the user and administrator cannot explain. The reported campaign involved attackers adding authentication methods and registering devices. An unfamiliar device is a signal to investigate, not proof of malicious activity; compare it with known users, equipment, and approved changes.
Inspect mailbox rules and forwarding settings. The report describes rules that concealed or deleted messages connected to payroll, deposits, and bonuses, along with messages marked read and deleted. If someone reports missing mail, check whether a rule or forwarding setting could explain it and whether the change was authorized.
Review unexpected outbound messages and application access as well. Unusual mail from a trusted account can mislead customers, vendors, or colleagues. Unexpected applications or permissions may also indicate that access has been changed. Check the affected account's recent activity alongside its mailbox and authentication settings.
Record what you find, when it was observed, and which actions were taken. Separate confirmed facts from open questions. That record gives the administrator, business owner, and incident-response support a shared account of what is known and what still needs investigation.
The takeaway: investigate sign-in activity, mailbox behavior, and account changes together; a password reset alone may miss other unauthorized changes.
What should we do first if we suspect token replay?
Escalate a credible concern promptly, then coordinate containment with the Microsoft 365 administrator and incident-response lead. Move quickly while preserving useful evidence and accounting for the business work that depends on the affected account.
Identify the affected user, the reported symptoms, and any urgent business dependencies. Use a trusted communication channel rather than relying on the potentially compromised mailbox.
Revoke active sessions and reset the password as part of a coordinated response. These steps are recommended in the report, but should not replace investigation of other ways access may persist.
Review the user's authentication methods and registered devices. Remove methods that cannot be confirmed as legitimate, and investigate unfamiliar devices before deleting them. Record relevant details for the incident review.
Inspect mailbox rules, forwarding settings, application access, and recent account activity. Look for messages that were hidden, deleted, or sent externally, and investigate unauthorized changes.
Assess whether other accounts, systems, or business processes may have been affected. Coordinate containment and recovery decisions with the people responsible for those services.
Document actions and keep affected staff informed through a trusted channel. If sensitive or regulated information may be involved, involve appropriate legal, compliance, and leadership contacts to assess obligations.
GDS Technology's incident response service is described as scoped investigation and coordination, including intake, scope and evidence review, containment coordination, investigation activities, recovery coordination, and an incident summary. For planning around business dependencies and recovery, see disaster recovery planning.
The takeaway: contain access, investigate how it may persist, and coordinate recovery instead of assuming one credential change closes the incident.
How can we make the response repeatable?
Document who can authorize session revocation, password resets, and authentication-policy changes. Include contact paths for the affected account owner and the people who can approve operational workarounds. If the response depends on one person remembering undocumented steps, the business may lose time during a stressful incident.
Keep an account and access inventory that supports onboarding, role changes, and departures. Know who has administrative privileges, which authentication methods are allowed, and which devices are expected. Record meaningful changes so responders can distinguish planned maintenance from activity that needs investigation.
Agree on what evidence responders should review and who will do it. A practical checklist can cover sign-in activity, authentication methods, registered devices, mailbox rules, forwarding, application access, and outbound messages. The objective is to establish whether access is contained and what needs to be restored, not to collect information without a clear purpose.
Run a short tabletop exercise around a suspicious sign-in. Confirm who makes decisions, how the team would reach the account owner, and how essential communications would continue while access is secured. Update the procedure when responsibilities, applications, or business processes change.
Legal and regulatory obligations depend on the facts and information involved. A technical checklist cannot determine whether a notification is required. Involve qualified counsel and compliance advisers when an incident may trigger legal or contractual responsibilities.
The takeaway: make account recovery a documented process with clear ownership and a defined way to confirm access is safe to restore.
Frequently Asked Questions
Can attackers bypass MFA on Microsoft 365?
Yes. Some attacks target the authenticated session instead of defeating MFA directly. A fake sign-in page can relay credentials and an MFA response, then capture a session token for attempted reuse. MFA remains valuable, but it should be paired with access controls, account monitoring, and a response plan for suspicious sessions.
Does changing a Microsoft 365 password stop a token-replay attack?
A password reset is a recommended response step, but do not assume it addresses every part of an incident. Also revoke active sessions, review authentication methods and registered devices, and inspect mailbox rules and application access for unauthorized changes. Coordinate actions with the person responsible for the tenant and preserve relevant evidence.
What Microsoft 365 settings should we review after a suspicious sign-in?
Review Conditional Access policies, authentication methods, registered Entra devices, account permissions, and the affected mailbox's rules and forwarding settings. Check for unexpected enterprise applications and outbound messages as well. Validate unfamiliar changes against known users and equipment, then document what was confirmed and what still needs investigation.
How quickly should we respond to a suspected Microsoft 365 compromise?
Begin escalation and containment as soon as a credible concern is identified. The exact sequence depends on the account, business dependencies, and evidence available, so involve the tenant administrator and incident-response lead promptly. Avoid delaying action while trying to prove every detail, but coordinate changes and keep a record of what was done.
Can MFA alone protect a Microsoft 365 account?
No single control should be treated as complete protection. MFA can reduce risk from stolen passwords, while session theft, unexpected authentication changes, or malicious mailbox rules may require other controls and investigation. Review identity policies, limit access appropriately, monitor account changes, and make sure responders know how to revoke sessions and check for unauthorized changes.
