Threat Analysis: Microsoft Teams Helpdesk Impersonation, Infostealer Sessions and the Leaky Offboarding Problem
Hello, Mauven here.
This is your Daily Threat Analysis for 3rd September 2026.
Three stories today. On the surface they look unrelated. A Microsoft Teams social engineering campaign. An article about what to do when an employee’s credentials turn up in an infostealer log. A case study about a terminated employee who retained access long enough to cost their former employer hundreds of thousands of dollars.
Read them together and you get a very clear picture of where UK SMBs are genuinely exposed right now. It is not exotic. It is access management, and the people who are supposed to be managing it.
Story One: Attackers Are Calling Your Staff Pretending to Be IT
Microsoft Threat Intelligence published confirmation yesterday of an active, human-operated campaign exploiting Microsoft Teams external collaboration features. The attack is straightforward: threat actors contact employees over Teams, impersonating IT helpdesk personnel, and social-engineer them into granting remote access using legitimate remote monitoring and management tools.
Once the remote session is established, the attacker deploys malicious MSI packages through PowerShell, staging a portable Node.js runtime and obfuscated JavaScript payloads. From there, the campaign moves to domain reconnaissance and lateral movement. This is not a phishing email you might catch with a spam filter. It is a phone call, or the Teams equivalent of one, from someone who sounds like they know what they are doing.
What Microsoft’s advisory does not dwell on is why this works so effectively in SMB environments specifically. The answer is straightforward: in many smaller organisations, there is no standard procedure for verifying the identity of an IT support caller. Staff are conditioned to be helpful when someone with apparent technical authority asks them to do something. They install the remote access tool because the person on the other end sounds confident and the request seems routine.
Huntress has separately documented a related pattern: rogue ScreenConnect installations, delivered through social engineering, executing a chain of four VBScript payloads to profile systems, check for security products, establish persistence, and deploy additional tools, with worm-like propagation across unrelated hosts. The TTPs overlap closely with what Microsoft has described. Remote monitoring tools being weaponised through social engineering is not a new tactic. What is notable is the scale and the coordination.
What this means for you: If your organisation uses Microsoft Teams and allows external contacts to message your staff, which is the default configuration, your employees can be reached by anyone with a Teams account. That is the attack surface. The NCSC has published guidance on phishing-resistant controls and caller verification procedures. The fact that campaigns like this continue to work tells you how many organisations have not implemented them.
The immediate controls are not complicated:
- Configure Teams to restrict or require approval for external contact initiation
- Brief staff that legitimate internal IT will never cold-contact them and demand immediate remote access
- Require a verification step, even a callback to a known number, before any remote session is accepted
- Audit which remote access tools are installed on your estate and who authorised them
Story Two: Your MFA Did Not Save You, Because the Session Was Already Stolen
BleepingComputer published analysis today of what to do when an employee credential appears in an infostealer log. The piece covers prioritisation and response steps, but the detail that matters most is buried in the middle: infostealers do not only steal passwords. They steal authenticated session tokens.
This is the part that the standard response playbook misses. An organisation discovers an employee’s email address and password in a stealer log, forces a password reset, ticks the box, and moves on. But if the infostealer captured an active session token, the kind issued after a successful MFA challenge, resetting the password does not invalidate that session. The attacker can still authenticate as that user until the session expires or is explicitly revoked.
The window between credential theft and session expiry varies considerably depending on how the application is configured. For Microsoft 365, default session lifetimes can be measured in days. For some SaaS tools, longer still.
The pattern is compounded by the broader direct-to-IP malware trend documented by Palo Alto Unit 42 this week: nearly half of all malware samples with command-and-control activity establish connections directly to hard-coded IP addresses, bypassing DNS entirely. DNS-based security monitoring, which many SMBs rely on as a primary detection layer, will not catch this traffic. If a stealer on an employee’s machine is exfiltrating session tokens over a direct IP connection, your DNS logs will show nothing.
What this means for you: When you find a credential in a stealer log, the question is not only whether to reset the password. It is:
- Is the session token still active? For Microsoft 365, this means revoking all active sessions through Entra ID, not just resetting the password
- What did the stealer capture beyond the password? Saved browser sessions, VPN configurations, and authenticator app seeds have all been documented in stealer output
- When was the credential likely stolen? Stealer logs are often sold weeks or months after initial compromise. The attacker may have had access for longer than you think
Session revocation is a specific administrative action, separate from a password reset. If your IT provider or MSP does not mention it when handling a compromised credential, ask them directly why not.
Story Three: The Leaver Who Kept Access
The Register reported today on a case where a terminated employee, one who held elevated access beyond standard user privileges, retained that access after leaving because nobody had tracked what needed to be revoked. The financial damage ran to hundreds of thousands of dollars.
I want to be measured here, because the temptation is to say this is obvious and organisations should know better. They should. But the mechanics of how this happens in practice are worth examining.
In many SMBs, access provisioning is informal. An employee needs access to a system, someone grants it, no ticket is raised, no record is kept. When that employee leaves, HR tells IT to disable the primary account. IT does. But the ancillary access, the shared credentials, the cloud service accounts provisioned separately, the vendor portal logins set up for a specific project, none of that is visible in a single place, because it was never documented in a single place.
Elevated access makes this worse. A standard user account is typically managed through Active Directory or Entra ID. But employees with additional responsibilities accumulate access to third-party platforms, admin consoles, and service accounts that exist entirely outside your primary identity management system.
The NCSC has published guidance on identity and access management, including the principle of least privilege and the requirement for joiners-movers-leavers processes. That guidance has been available for years. This case, and cases like it, persist because the guidance is read by the people who already understand the problem and ignored by the organisations that need it most.
What this means for you: Before your next staff departure:
- Conduct an access audit for the departing individual across all systems, not just the primary account
- Include cloud services, SaaS platforms, shared credentials, and any vendor portals they had access to
- Confirm revocation in writing, with a checklist that HR and IT both sign off
- Review whether elevated access was appropriate in the first place, the case described suggests the employee had more access than their role warranted
Offboarding is not an IT task that happens automatically. It is a process that requires a checklist, an owner, and a verification step.
The Pattern
Three stories. One pattern.
The Teams campaign works because nobody verified the caller’s identity before granting access. The infostealer session theft works because organisations reset passwords but leave sessions live. The leaver case cost six figures because nobody tracked what access existed to revoke.
In all three cases, the technical controls exist. The guidance exists. What is missing is the operational discipline to apply them consistently.
If any of today’s three scenarios describes a gap in your own organisation, that gap is almost certainly being tested by someone, somewhere, right now.
Sources
Before the next story: if Threat Analysis is useful to you, follow the show wherever you listen so tomorrow’s briefing lands automatically. And if today’s analysis describes a gap you recognise, pass it to whoever in your organisation owns the answer, because they need the heads-up more than you do.