A Fake IT Support Call Can Become an Active Directory Incident
An employee grants remote access to someone posing as IT support. The next security question is how far that session can reach. Microsoft's September reporting makes that a practical issue for every business running Active Directory.
BlackSight Team
Offensive security & threat analysis
Published
What Microsoft reported in September
On September 2, 2026, Microsoft published an investigation into attackers impersonating IT support through external Teams conversations. After obtaining a remote session, the operators used malware and ordinary administration tools to investigate Active Directory and attempt movement toward domain controllers and certificate authorities. Read Microsoft's campaign investigation.
Which boundaries should stop that path?
Microsoft's September 17 follow-up emphasizes controls that work across identities, endpoints, and networks. For this campaign, it highlights restrictions on remote-support software and Windows Remote Management (WinRM), alongside stronger access controls and endpoint protections. See Microsoft's guidance on reducing these attack paths.
Our recommendation is to turn those controls into questions your team can answer with evidence:
- How does an employee verify an unexpected support request through a known channel?
- Which approved tools can start remote sessions, and who reviews their use?
- Which accounts and devices can administer servers or reach identity infrastructure?
- Can responders connect the support session, endpoint activity, and later access attempts?
A useful review names an owner for each boundary. If the service desk owns support procedures, the infrastructure team owns remote administration, and security operations owns detection, the exercise should include all three. Otherwise, each team can report that its own settings look correct while the path between them remains untested.
Turn the incident pattern into a scoped AD test
You do not need to reproduce the malware campaign to investigate the same business concern. Start an authorized assessment from a representative employee network segment and an agreed standard domain account. Define which servers may be contacted, which permissions may be validated, and where the tester must stop to request further approval.
For example, a regional office might want to know whether access from an ordinary workstation can reach the administration interfaces used at headquarters. Write that question into the scope. Record the starting permissions, the expected restriction, the observed outcome, and whether the security team saw the activity. A finding then describes a specific boundary that needs attention, with enough context for its owner to reproduce and fix it.
Include certificate services only when agreed. Treating every system connected to AD as automatically authorized creates operational confusion. The same applies to testing from branch offices, VPN connections, and third-party support networks: each starting point should have a clear purpose and a named contact.
Ask for evidence your team can use
A useful report explains what access was required, what was actually reached, what remained blocked, and which change would close the gap. Keep recommendations connected to business systems and owners. After remediation, repeat the agreed check and record the result rather than closing the finding solely because a setting changed. BlackSight's Active Directory penetration testing can be delivered worldwide, remotely or on site, with the starting access and operational boundaries agreed before testing.
Common questions
How can a fake IT support call lead to an Active Directory incident?
In Microsoft's September 2026 report, attackers persuaded users to grant remote access, then investigated the domain and attempted movement toward identity infrastructure. The route combined social engineering, endpoint access, and internal administrative tools.
Does this mean Microsoft Teams has an unpatched vulnerability?
That is not what Microsoft reported. The campaign abused legitimate collaboration and remote-support workflows, including persuading users to override warnings. Restricting access and validating support requests are therefore part of the response.
Can an AD pentest begin from a normal employee account?
Yes. An agreed assumed-breach assessment can start with a standard domain account and an internal test host, then validate access boundaries and detection. Domain controllers, certificate services, and any higher-impact actions must be explicitly scoped.