The Fake Lock Screen Stole the Password. The Proxy Made the Login Look Internal.
An employee received what appeared to be an IT support request in Microsoft Teams. The download came from Microsoft Azure storage. The installer called itself PowerShell Cleaner. What followed was a modular intrusion chain designed to collect a real Windows password, route traffic through the victim’s own workstation and give an operator interactive control of the machine.
That combination is what makes SynkLoader more consequential than another chat-delivered loader. The malware’s PhishLocker module creates a counterfeit Windows lock screen and waits for the user to type a password. Its TrafficRedirector module then turns the infected computer into a reverse proxy. Together, those components can give an attacker both the credential and a path that makes later access appear to originate from the expected device and corporate network.
Security company Expel discovered the previously undocumented family during an incident on 18 August 2026. Researcher Marcus Hutchins reverse-engineered its command-and-control protocol, built an emulator and persuaded the operators that they had reached a large corporate environment. The operators responded by sending additional modules and eventually attempted hands-on-keyboard activity against the decoy.
The attack began inside Teams
The recovered metadata did not preserve the entire conversation, but it showed an account using an address in the target company’s onmicrosoft.com namespace and the display name IT Service Desk. That presentation was enough to make a support request look local and familiar.
The supposed help desk instructed the employee to install an MSI package hosted on an Azure Blob Storage endpoint. Microsoft infrastructure had not been compromised, and the file’s location did not make it safe. The hosting choice simply borrowed a trusted domain and a familiar cloud provider’s reputation.
The package identified itself as PowershellCleaner. When launched, it extracted cleaner.ps1 and archive6.zip under %LocalAppData%\PowershellCleaner\script. The PowerShell stage reconstructed and decrypted another command in memory, generated a random 16-character installation directory under the user’s roaming profile and unpacked a self-contained Python environment there.
Shipping Python inside the archive allowed the loader to run on Windows systems where Python was not installed. The main script, ss.py, selected one of three embedded command-and-control domains and checked in every 90 to 120 seconds. The randomly generated directory name doubled as the victim identifier.
Expel found compile and file timestamps suggesting the tooling had first been assembled and distributed around 28 July 2026. That is an indicator of age, not proof of the exact start of the campaign.
Everything but the kitchen sink
The name SynkLoader is a play on “sink loader” and its everything-but-the-kitchen-sink construction. The chain crosses Python, PowerShell, C# and C++. Some modules use several of those languages together, increasing complexity and reducing the value of detections that expect a familiar single-language payload.
One DLL was named msvcp150.dll to resemble a Microsoft Visual C++ runtime component. It was actually a custom C# module exposing functions that execute PowerShell in memory. Another component manually mapped later DLLs without writing them to disk, limiting the artefacts available to signature scanners and forensic tools.
The system profiler collected the hostname, user, privilege level, processes, services, domain information and a count of computers in Active Directory. After Expel’s emulator reported a fictitious domain with several thousand systems, the command-and-control service delivered persistence and credential-phishing modules. A randomly named scheduled task launched the loader at user logon and again every day at 10:00 local time.
The full collection observed by Expel included:
- System Profiler: maps the endpoint and measures the apparent size of the Active Directory environment.
- PhishLocker: presents a convincing counterfeit Windows lock screen and captures what the user enters.
- TrafficRedirector: creates a backconnect proxy into internal services and out to internet services through the victim’s connection.
- Interactive Shell: lets the operator issue PowerShell commands and receive the output in real time.
- StreamMaster: streams screenshots and sends mouse and keyboard input to the active desktop session.
- Persistence and status modules: keep the loader running and report which components remain alive.
The fake lock screen was only the credential step
PhishLocker retrieves the current username and the installed Windows lock-screen background, then draws a full-screen borderless application that closely resembles the Windows 11 sign-in experience. It is not the real Windows credential provider and it does not verify the submitted password. Any entry dismisses it and is available to the attacker.
There are clues. Expel’s test showed that the fake screen lacked the normal background blur, and Alt+Tab exposed other windows. The application tried to pull focus back to itself, however, reducing the chance that a hurried user would investigate. Unlike credential dumping, this technique can deliver the raw password that the user believes is being entered into Windows.
The distinction is operationally important in an environment where one password unlocks several systems through single sign-on. A local fake login surface can collect the same secret the user relies on for remote services, VPN access or lateral movement.
The proxy makes identity telemetry less trustworthy
A valid password still needs a plausible place from which to use it. TrafficRedirector supplies that place. The module connects outward to attacker infrastructure, waits for connection instructions and forwards traffic between the operator and a selected destination.
That allows the attacker to reach services that are visible only from the corporate LAN. It can also route access to internet-facing applications through the infected workstation’s public IP address. IP allowlists, geolocation rules and impossible-travel alerts may therefore see a familiar network location even though the person controlling the session is elsewhere.
This does not guarantee that every identity control will be bypassed. Device binding, phishing-resistant authentication, session risk, endpoint telemetry and application behaviour can still expose the intrusion. It does show why source IP and password validity are weak proxies for user legitimacy once an endpoint has become an attacker-controlled relay.
Expel drew the operator into a fake network
Reverse engineering produced more than static malware analysis. Expel recreated the loader’s command-and-control exchanges and returned fabricated profile data that made the decoy look like a large enterprise. The server supplied further payloads, including the credential prompt, tunnel, shell and remote-control components.
When the interactive shell did not behave as expected, the operators retried it repeatedly and delivered another status script. After Expel emulated the shell as well, a person on the other end ran profiling commands, recognised that the environment was not genuine and disconnected. That sequence confirms a live, selectively operated intrusion workflow rather than an entirely automated commodity infection.
The final objective remains unknown. Expel assessed with low-to-medium confidence that the toolkit may belong to a ransomware group or an initial-access broker serving ransomware operators. The assessment rests partly on the Active Directory host count and the loader’s similarity to tooling used in pre-ransomware access operations. No ransomware deployment or specific actor attribution was confirmed.
Detection opportunities sit across chat, endpoint and identity
SynkLoader deliberately spans control boundaries, so no single alert covers the chain. Defenders should correlate the initial Teams contact, cloud-hosted download, MSI execution, PowerShell behaviour, unusual Python runtime, scheduled task, reverse-proxy traffic and later identity activity.
| Layer | Useful signals |
|---|---|
| Teams | A new or external contact presenting as internal IT, display-name impersonation, unsolicited support instructions and links to installer packages. |
| Endpoint | msiexec.exe launching a user-downloaded package, PowerShell extracting into user-writable profile paths, a bundled pythonw.exe, runtime-looking DLL names outside normal application directories and randomly named scheduled tasks. |
| Network | Long-lived outbound connections from an ordinary workstation, repeated low-frequency beacons, reverse-proxy behaviour and a user endpoint connecting to internal services it does not normally reach. |
| Identity | Authentication from a familiar IP combined with new applications, unusual resource access, unexpected session characteristics or endpoint activity inconsistent with the employee’s normal work. |
Expel published installer, script and archive hashes plus command-and-control infrastructure. Several later modules contain victim-specific identifiers, so their hashes can vary by infection. Behavioural detections and cross-layer correlation will age better than a blocklist built only from the first samples.
What security teams should change
First, make help-desk identity verifiable outside the same chat that carries the request. Employees should know that IT will not ask them to install an unsolicited cleaner, and they should have a separate channel for validating an urgent support instruction.
Second, review Teams collaboration and message protections. Microsoft documents near-real-time URL warnings for Teams, and Defender for Office 365 adds Safe Links, Safe Attachments, the tenant allow/block list and zero-hour auto purge for messages later classified as malware or high-confidence phishing. Administrators should confirm that applicable policies are enabled and that exclusions are intentional.
Microsoft’s weaponizable-file protection can block messages containing MSI and other executable extensions. In this incident the MSI was reached through a link rather than attached directly, so file-extension controls cannot replace URL inspection and endpoint application control. Blocking or tightly controlling MSI execution from user-writable locations remains valuable.
Third, treat an unexpected lock screen as a possible security event. Ctrl+Alt+Delete invokes the protected Windows security screen, while Alt+Tab may reveal a fake full-screen application. If a user entered a password into a suspicious prompt, isolate the endpoint, reset the credential, revoke active sessions and investigate access from the device rather than assuming a password change alone ends the intrusion.
Finally, do not allow a familiar source IP to close an identity investigation. When the workstation itself can act as the operator’s proxy, location is part of the compromised infrastructure. Authentication decisions need device state, process and session context, application behaviour and post-login activity.
The trusted path was the attack surface
SynkLoader’s individual ingredients are familiar: help-desk impersonation, cloud-hosted malware, in-memory execution, credential phishing, tunnelling and remote control. Its strength is the order in which they are assembled.
The message arrives in a workplace channel. The installer sits on a Microsoft-owned domain. The credential prompt looks like Windows. The attacker then logs in through the victim’s own machine. Each step borrows trust from the one before it.
The defensive lesson is broader than this loader. Security teams cannot treat collaboration identity, reputable hosting, a native-looking interface, a correct password and a familiar IP address as independent proof that an action is legitimate. SynkLoader turns those signals into a chain of camouflage.
Update: Spring Ring took the Teams lure toward domain control
Palo Alto Networks Unit 42 published a related campaign called Spring Ring on 31 August 2026. Between January and April, operators using external Microsoft Teams accounts impersonated help-desk staff and reached more than 150 employees at at least ten organisations. The attackers moved from Teams chat to live voice calls, then persuaded targets to install remote-management software or custom malware. The pattern reinforces the central SynkLoader lesson: a familiar collaboration interface can make an external identity feel like internal support before any exploit is required.
In the most advanced branch, Unit 42 observed payloads tailored to the victim’s cloud environment, internal SMB scanning and an attempted PetitPotam NTLM relay against a domain controller. That turns the lure into a path from one employee conversation toward domain-level privileges. Defenders should monitor newly created external onmicrosoft.com identities, unexpected Quick Assist or remote-management sessions, and NTLM activity directed at domain controllers after a Teams support call. Unit 42 published the Spring Ring research on 31 August 2026 at 10:00 UTC, which is 12:00 CEST.
Sources and further reading
- Expel: SynkLoader, when you throw in everything but the kitchen sink, published 20 August 2026.
- BleepingComputer: New SynkLoader malware pushed in Microsoft Teams phishing campaign, published 21 August 2026 at 14:01, source timezone not stated.
- Microsoft Learn: Microsoft Defender for Office 365 support for Microsoft Teams.
- Microsoft Learn: Weaponizable file protection in Microsoft Teams.
