A new malware campaign is a useful reminder that phishing no longer lives only in email. Security researchers at Expel documented a previously unknown malware family, SynkLoader, delivered after an attacker impersonated an IT help desk through Microsoft Teams and convinced a user to install a fake software package.
The important business lesson is not the malware name. It is the delivery method. Employees increasingly treat Microsoft Teams as a trusted place for real work, vendor communication and internal support. Attackers are taking advantage of that trust. Microsoft Teams phishing can look like an ordinary support conversation, and the dangerous step may be a software install or remote-access request rather than an obvious malicious link.
For leadership, this means collaboration tools need the same security attention as email: clear help-desk verification, controlled software installation, managed endpoints, external-access rules and a simple process for employees to report suspicious requests.
What Happened in the SynkLoader Campaign
Expel reported that it encountered SynkLoader while investigating an incident on August 18, 2026. The researchers found evidence suggesting the malware had been compiled and distributed beginning around July 28.
The initial contact came through Microsoft Teams. Expel recovered metadata showing an attacker using an external Microsoft 365 tenant and presenting as an IT service desk. The target was persuaded to download and install an MSI package presented as a “PowerShell Cleaner”. The installer was hosted on Microsoft Azure infrastructure, which could make the download appear more legitimate to a user who is not expecting a sophisticated attack.
After installation, SynkLoader could deliver different modules depending on the target environment. Expel identified capabilities that included:
- Profiling the device and Active Directory environment.
- Creating persistence so the malware could run again later.
- Displaying a fake Windows lock screen designed to capture the user’s password.
- Creating a network tunnel that could help an attacker reach internal systems through the infected device.
- Providing remote command execution through PowerShell.
- Streaming the victim’s desktop and allowing remote keyboard and mouse control.
Expel observed the malware checking the size of the Active Directory environment and assessed that the campaign may be connected to ransomware operations. That is a researcher assessment, not confirmation that every SynkLoader infection leads to ransomware.
This Is Not a Microsoft Teams Vulnerability
It is important not to describe this as attackers “hacking Teams.” The available evidence points to social engineering: the attacker used legitimate collaboration features, impersonated IT support and persuaded the user to perform the dangerous action.
Microsoft reinforced the same distinction in a September 2026 security report about a separate human-operated campaign. Microsoft observed attackers abusing Teams external collaboration to impersonate IT or help-desk personnel, convince users to grant a remote session, and then deploy a malicious MSI package. Microsoft explicitly noted that this activity did not stem from a weakness in Teams itself. The SynkLoader campaign and Microsoft’s campaign are not the same incident, but they demonstrate a closely related attack pattern.
That distinction matters because patching Teams does not solve a social-engineering problem. The organization has to control what users can approve, install and trust.
Why Microsoft Teams Phishing Is a Business Problem
Email phishing has trained many employees to be suspicious of strange attachments and urgent links. Teams often feels different. A message appears inside a tool employees use all day, sometimes alongside real conversations with coworkers, clients, consultants and vendors.
That trust creates a useful opening for attackers. A fake support request might say that:
- Your account needs to be verified.
- A security or spam-filter update needs to be installed.
- IT needs temporary remote access.
- A Microsoft component needs to be repaired.
- You need to approve a prompt to finish a support task.
Those requests sound close enough to legitimate IT work that employees may comply, especially when they are busy.
This is particularly relevant for construction, architecture and engineering firms. Project teams routinely communicate with outside consultants, owners, contractors, vendors and field personnel. External collaboration is normal, which means the presence of an external Teams contact is not automatically suspicious. The real question becomes whether the person and the request are legitimate.
The Fake Lock Screen Is a Useful Warning
One of SynkLoader’s more unusual modules was designed to imitate the Windows lock screen. Instead of technically extracting the user’s password, the malware displayed a convincing full-screen interface and waited for the user to type the password voluntarily.
Expel noted that the fake screen was still just an application. Using Alt+Tab could expose that other windows remained active, and the module did not actually validate the entered password. But employees should not be expected to diagnose malware under pressure.
The better control is behavioral: if a device suddenly presents an unusual credential prompt after a support interaction, software installation or external Teams conversation, the employee should stop and contact the real IT provider through a known channel.
What Businesses Should Review in Microsoft Teams
Microsoft provides administrative controls for external Teams communication. Organizations can restrict external collaboration to trusted domains, and Microsoft now provides trust indicators, Accept/Block prompts and phishing warnings to help users recognize risky external interactions.
For many organizations, blocking all external Teams communication would interfere with legitimate work. The better question is whether the current settings match the business.
Leadership and IT should review:
- External access. Determine whether users need to communicate with every external domain or only known partners and clients.
- User awareness. Make sure employees recognize external-user labels, Accept/Block prompts and suspicious support requests.
- Reporting. Employees should know exactly how to report a suspicious Teams chat or call.
- Remote-support rules. Define which tools the real IT team uses and when users should expect remote-access requests.
- Help-desk identity. Employees should know the normal names, domains, phone numbers and channels used by IT support.
Microsoft’s current Teams guidance tells users to double-check the sender’s identity, preview suspicious external messages and accept a conversation only when the sender is trusted.
Do Not Rely on Employee Training Alone
Training matters, but a security program that depends on every employee making the perfect decision every time is fragile. People are busy. Good attackers know how to create urgency, authority and confusion.
The stronger approach combines user awareness with technical controls.
- Restrict software installation. Standard users should not automatically be able to install arbitrary MSI packages or tools without an approved process.
- Manage endpoints. Devices should have centralized patching, endpoint protection, monitoring and the ability to isolate a compromised machine quickly.
- Use strong identity controls. MFA, Conditional Access and well-managed administrator accounts reduce what a stolen password can accomplish.
- Monitor remote-management tools. Quick Assist, AnyDesk, TeamViewer and similar tools may be legitimate, but unexpected use should be visible and controlled.
- Review Teams external access. Use the least-restrictive configuration that still supports the business instead of leaving collaboration settings unexamined.
- Control scripting and application behavior. Endpoint security and application-control policies can help restrict suspicious PowerShell, DLL and user-writable execution patterns.
- Create an out-of-band verification process. If “IT” asks an employee to install software, provide remote access or enter credentials, the employee should be able to verify the request using a known phone number, support portal or internal contact.
Microsoft’s September research recommends verifying unsolicited support contact through a known channel, restricting Teams external access to trusted domains where appropriate, and combining collaboration controls with endpoint and identity defenses. CISA’s phishing guidance similarly emphasizes stopping the attack cycle early and having a defined response process when phishing succeeds.
Why This Matters Beyond Microsoft Teams
The larger shift is that attackers follow business communication. As organizations move more work into Teams, Slack, cloud project platforms, file-sharing tools and vendor portals, those systems become attractive phishing channels too.
That means the security question should not be, “Do we have a good spam filter?” It should be:
Can an employee tell when a support request is real, and can our controls limit the damage if they make a mistake?
A strong cybersecurity program connects identity, endpoints, Microsoft 365, user behavior and incident response. A well-managed Microsoft 365 environment also gives leadership clearer control over collaboration, access and user policies rather than leaving those settings at whatever defaults happened to exist when the tenant was created.
What Leadership Should Ask This Week
This does not require a 40-page security project. Start with a short operational review:
- Can employees clearly identify an external Teams user?
- What is the approved process when IT needs remote access?
- Can ordinary users install MSI packages without approval?
- Are remote-support tools monitored and restricted?
- Are MFA and device requirements enforced for important accounts?
- Who reviews Microsoft Teams external-access settings?
- What should an employee do if a suspicious support conversation already occurred?
If leadership cannot answer those questions, the gap is broader than SynkLoader. It means the organization has not clearly defined how support, identity and collaboration security should work.
The Business Lesson From SynkLoader
SynkLoader is technically interesting, but the attack did not begin with some exotic zero-day. It began with a believable conversation.
An attacker presented as IT support, used a familiar business collaboration platform and persuaded a user to install something that appeared legitimate. From there, the malware could profile the environment, capture credentials, establish persistence and provide remote access.
The practical response is not panic and it is not banning Teams. It is making sure employees know how legitimate IT support works, limiting what untrusted software can do, monitoring managed devices and configuring Microsoft 365 collaboration around the way the business actually operates.
Not sure whether your Microsoft 365, endpoint and support controls would stop this kind of attack from becoming a larger incident? Nevada IT Support can review the environment, identify the gaps and give leadership a practical remediation plan through a Technology Gap Review.
Sources and Further Reading
- Expel: SynkLoader threat research – primary research describing the observed malware, Teams delivery method and modules.
- Microsoft Security: Impersonating IT support – primary Microsoft research on a separate Teams help-desk impersonation campaign and recommended mitigations.
- Microsoft Support: Prevent spam or phishing attempts from external Teams chats – current user guidance for suspicious external contacts.
- Microsoft Learn: Reduce the attack surface for Microsoft Teams – administrator guidance for restricting external access and layering Teams defenses.
- BleepingComputer: SynkLoader malware pushed in Microsoft Teams phishing campaign – secondary reporting that surfaced the Expel research.
- CISA: Phishing Guidance – Stopping the Attack Cycle at Phase One – government guidance on reducing phishing impact and responding to successful attacks.
Leave a Reply