SynkLoader — Microsoft Teams IT-Helpdesk Impersonation Loader

SynkLoader is a newly identified modular malware loader first compiled around 2026-07-28 and publicly reported by Expel, BleepingComputer, and others between 2026-08-19 and 2026-08-24. Expel states it discovered the family when EDR flagged a scheduled task in a customer environment on 2026-08-18, after attackers impersonating an "IT Service Desk" contacted the victim over Microsoft Teams and talked them into running an MSI hosted on Microsoft Azure Blob Storage.

The attacker's objective is broader than a single credential grab: the loader combines Python, PowerShell, C#, and C++ components into a toolkit that (1) profiles the host and Active Directory environment, (2) establishes COM-registered scheduled-task persistence, (3) phishes the user's plaintext Windows password with a fake full-screen lock screen, and (4) hands the operator a reverse-proxy pivot, a VNC-style remote-desktop module, and an interactive PowerShell shell — all reachable over a single ChaCha20-encrypted C2 channel that accepts and executes arbitrary Python code sent from the server. The heavy, unprompted AD-profiling focus (domain name, AD computer count, running services) combined with a full "hands-on-keyboard" toolkit is consistent with initial-access-as-a-service or a ransomware-precursor operation rather than a simple credential stealer.

The single highest-value defensive angle is the initial-access step itself: the entire chain requires a user to (a) accept an external Teams contact impersonating IT and (b) run an MSI they downloaded themselves. Teams external-access hardening and AppLocker/WDAC controls on unsigned executables launched from user-writable paths cut off the chain before any of the seven modules ever load. A close second is the fake lock screen's core weakness — it is a borderline GUI window, not a real Secure Desktop, so enforcing genuine Ctrl+Alt+Del (disabling the "do not require CTRL+ALT+DEL" policy) makes PhishLocker structurally unable to intercept the real credential prompt.

Eight sources were fetched this session; five were the task's named primary sources, three were supplementary corroboration pulled up during research. Full fetched text (or, where noted, the best-available reconstruction) is saved verbatim in SynkLoader-Hunt-sources/ for the provenance gate.

Discrepancy flagged during research

The dev.to recap lists C2 domains tripinupdate.net, dondermicapp.net, aroclenetapp.net, while both primary sources (Expel directly, and GBHackers independently) list neversoftmain[.]net, rootfarmapp[.]net, tripinupdate[.]net — matching only on tripinupdate.net. Per this pipeline's dedupe-before-blocking discipline, the two dev.to-only domains are not promoted to the hard Falcon IOC-Management CSV; they are documented here as single-secondary-source and unconfirmed against the primary research.

Anomalous / suspicious content encountered

No content in any fetched source contained text addressed to an AI assistant, prompt-injection attempts, or instructions trying to direct this pipeline's actions — all fetched text was analyzed strictly as threat intelligence.

One accuracy concern was found: a reblog (We Fix PC) attributed the research to "Security researcher Marcus Hutchins (Expel)." Marcus Hutchins is a real, well-known researcher, but no other source — including the reconstructed Expel snapshot itself — names him as author or affiliates him with Expel. This claim is not used anywhere in this pack; it is recorded here only as an anomaly encountered during research.

Hunt hypothesis set (8), ordered by fidelity: H1 MSI/PowerShell delivery chain (high) · H2 randomized-AppData Python runtime launch (high) · H3 fake VC++ runtime DLL write (high) · H4 COM-registered scheduled task (medium) · H5 confirmed C2 domain resolution (high) · H6 ChaCha20 beacon cadence (medium) · H7 GUI-toolkit load as a PhishLocker proxy (low — documented telemetry gap) · H8 internal-host pivot fan-out (medium).

These checks cover the two steps Falcon endpoint telemetry structurally cannot see — the Teams impersonation itself and any downstream cloud credential reuse.

Microsoft Teams admin center

• Review External Access reports for chats initiated by unfamiliar or newly-observed external tenants, especially messages referencing "IT," "helpdesk," "cleaner," or "PowerShell" tooling.
• If Defender for Office 365 / Teams protection is licensed, review its message-trace and URL-click reports for the same window.
• Check whether "Contact users in domains I haven't listed" is currently set to Allow-all (see Section 13 playbook PB3 if so).

Entra ID sign-in logs

• Pull sign-ins for any user whose host also produced a Q1/Q2 hit within the following 24 hours, watching for logons from unfamiliar IPs/ASNs — consistent with the phished plaintext password being reused externally.
• Cross-reference with Conditional Access sign-in risk flags if Identity Protection is licensed.

Windows Task Scheduler (manual pivot on flagged hosts)

• Get-ScheduledTask | Where-Object { $_.Actions.Execute -match 'AppData' } — the COM-registered task action path points into the randomized AppData directory, unlike a schtasks.exe-created task which is typically more conventionally named/pathed.

DNS / proxy logs (covers non-Falcon devices)

• Query org-wide DNS/proxy logs for the three confirmed C2 domains (Section 4) — this is the cheapest, highest-confidence sweep available and reaches contractor/unmanaged devices Falcon doesn't cover.

Three queries are strong Custom IOA / Scheduled Search candidates (high CONF, low FP): Q1, Q3, and Q5. The remaining five (Q2, Q4, Q6, Q7, Q8) stay investigate-only hunt queries pending a clean baseline period — see Section 11.

IOA-1 · MSI-Delivered Cleaner Payload (from Q1)

Scheduled Search name: DETECT — MSI-Delivered PowerShell Cleaner Payload (SynkLoader)
Description: Fires when msiexec.exe spawns powershell.exe referencing PowershellCleaner/cleaner.ps1/archive6.zip — the SynkLoader Stage-1 delivery signature. Matters because it is the earliest reliable endpoint signal, before any of the seven downstream modules load.
Exclusions: signed internal software-distribution MSIs that happen to share the string "cleaner" in an unrelated context (verify by hash/signer before adding an exclusion).
Deployment path: promote directly to a Custom IOA in Prevention Policy (block) after a 7-day clean detect-only baseline; low FP makes this a reasonable near-term "detect and page" candidate even before the baseline completes.

Alert email subject: [HIGH] Detection: SynkLoader — MSI-delivered PowerShell cleaner executed
Alert body: A host ran a PowerShell process spawned by msiexec.exe referencing PowershellCleaner, cleaner.ps1, or archive6.zip. This matches the SynkLoader initial-execution chain (Teams IT-helpdesk phishing → fake MSI → PowerShell stager). Immediate actions: isolate the host in Falcon RTR, capture the full process tree and any child pythonw.exe processes, and check whether the logged-on user recently received an external Teams message from someone claiming to be IT support.
Triage checklist: (1) Confirm the msiexec.exe→powershell.exe lineage and full command line. (2) Pull the process tree for any pythonw.exe children (Q2). (3) Check for msvcp150/160.dll writes on the host (Q3). (4) Check DNS history for the three confirmed C2 domains (Q5). (5) Interview the user about the originating Teams message and identify the impersonated sender. (6) If any downstream module indicator is present, escalate to full containment (Section 14). (7) Preserve archive6.zip/cleaner.ps1 samples before remediation. (8) Force a password reset for the affected user regardless of confirmed PhishLocker activity, since the credential-phish step is hard to observe directly.
Pivot queries: host-scoped process tree from the flagged PID; environment-wide sweep of Q1 across all hosts for the same 7-day window to size the campaign.

IOA-2 · Fake VC++ Runtime DLL Write (from Q3)

Scheduled Search name: DETECT — Fake msvcp150/160.dll Written Outside System Path (SynkLoader)
Description: Fires when a file named msvcp150.dll or msvcp160.dll is written outside System32/SysWOW64/known redist paths. Matters because these are the profiling and persistence modules specifically — a hit here means AD reconnaissance and/or persistence are actively being staged.
Exclusions: add any internal software-distribution share that legitimately stages VC++ redistributables outside the standard system paths.
Deployment path: promote to Prevention Policy (block on write) once the exclusion list above is confirmed against a 7-day baseline.

Alert email subject: [HIGH] Detection: SynkLoader — fake VC++ runtime DLL written to non-system path
Alert body: A file masquerading as a Microsoft Visual C++ runtime library (msvcp150.dll or msvcp160.dll) was written outside its legitimate system location. This is the SynkLoader AD-profiling or persistence module. Immediate actions: isolate the host, capture the file and its SHA256, and check for an associated COM-registered scheduled task (Q4 / native pivot in Section 7).
Triage checklist: (1) Hash and quarantine the file for analysis. (2) Check Task Scheduler for a COM-registered task pointing into AppData (Section 7). (3) Review AD/domain-controller logs for unusual enumeration activity from this host around the write timestamp. (4) Check for pythonw.exe/Q2 activity on the same host. (5) Escalate to containment if persistence is confirmed.
Pivot queries: same-host Q4 (scheduled task) and Q2 (python launch); environment-wide Q3 sweep to find every host with the fake DLL.

IOA-3 · Confirmed C2 Domain Resolution (from Q5)

Scheduled Search name: DETECT — DNS Resolution of Confirmed SynkLoader C2 Domain
Description: Fires on any DNS resolution of neversoftmain[.]net, rootfarmapp[.]net, or tripinupdate[.]net. Matters because a hit here means an implant is live and actively beaconing, not merely staged.
Exclusions: none expected; if security-tooling OSINT lookups are a concern in your environment, exclude your threat-intel platform's egress IP/process.
Deployment path: promote immediately to a Falcon Custom IOC blocklist entry (network-containment / DNS-sinkhole action) in addition to the Scheduled Search — this is the highest-confidence, lowest-FP indicator in the pack.

Alert email subject: [CRITICAL] Detection: SynkLoader — active C2 beacon confirmed
Alert body: A host resolved a confirmed SynkLoader C2 domain. This indicates an active, beaconing implant rather than a staged-but-inert infection. Immediate actions: isolate the host in Falcon RTR immediately, do not wait for further triage, and begin the full containment runbook (Section 14).
Triage checklist: (1) Immediate network containment. (2) Identify the beaconing process (Q6) and its full parent chain back to Q1/Q2. (3) Check for TrafficRedirector-consistent internal pivot (Q8) — if present, widen the investigation to every internal host it contacted. (4) Assume credential compromise; force password reset. (5) Pull AD profiling evidence (Q3) to scope what the attacker learned about the domain. (6) Notify IT helpdesk leadership — the impersonation abuses their identity and they should warn staff org-wide. (7) Preserve full packet capture / connection metadata if available before isolation completes. (8) Open a formal incident if any RAT/interactive-shell command execution is confirmed post-beacon.
Pivot queries: Q6 (beacon cadence) and Q8 (internal pivot) scoped to the same host; environment-wide Q5 sweep for every other beaconing host.

Investigate-only queries (Q2, Q4, Q6, Q7, Q8)

These stay hunt/investigate-only pending a 7–14 day clean baseline in your tenant (Section 11). Each carries its own pivot guidance in its query card above; none should be wired to an automated block action yet given medium-or-higher FP.

PB1 · Enforce Ctrl+Alt+Del at Unlock (defeats PhishLocker's core weakness)

Prerequisites: Domain Admin or local admin rights on the target GPO/registry scope; test on a pilot OU before org-wide rollout.
Reboot required: No (policy applies at next Group Policy refresh / logon).
Rollback: Re-enable "Do not require CTRL+ALT+DEL" (set DisableCAD back to 1) if a business application depends on the legacy behavior — none typically do, since this is a Microsoft-default-secure setting.

1. Open Group Policy Management, edit the target GPO (or a new "SynkLoader Hardening" GPO):
   Computer Configuration > Policies > Windows Settings > Security Settings >
   Local Policies > Security Options >
   "Interactive logon: Do not require CTRL+ALT+DEL" = Disabled

2. Equivalent direct registry path (for out-of-band/local application, e.g. via RTR):
   reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" ^
     /v DisableCAD /t REG_DWORD /d 0 /f

3. Force policy refresh on a pilot host:
   gpupdate /force

4. Verify:
   (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System').DisableCAD
   # Expected: 0 (or the value/key absent, which also means CAD IS required)

Rollback:
   reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" ^
     /v DisableCAD /t REG_DWORD /d 1 /f

PB2 · AppLocker Deny Rule for Unsigned Execution From User-Writable Paths

Prerequisites: AppLocker (or WDAC) available on target Windows edition (Enterprise/Education, or Pro with limitations); pilot in Audit mode for at least one full business week before Enforce.
Reboot required: No (Application Identity service restart is sufficient, see step 4).
Rollback: Set the rule collection back to "Not Configured" / delete the deny rule, then restart the Application Identity service; no reboot needed.

1. Open Local Security Policy or GPO editor:
   Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker

2. Create Executable Rule (deny) scoped to user-writable paths:
   Action: Deny
   User/Group: Everyone
   Path condition: %APPDATA%\*  and  %LOCALAPPDATA%\Temp\*
   (Apply the same deny to a Script Rule collection for .ps1/.vbs/.js if scripts
   are not otherwise controlled by Constrained Language Mode)

3. Keep the default AppLocker "Allow Everyone - All files located in Program Files"
   and "All files located in Windows folder" rules in place so legitimate software
   is unaffected.

4. Enable the Application Identity service (required for AppLocker enforcement):
   Set-Service -Name AppIDSvc -StartupType Automatic
   Start-Service -Name AppIDSvc

5. Deploy in Audit mode first, review Event ID 8003/8006 (AppLocker log) for one
   business week, add exclusions for legitimate line-of-business tools launching
   from AppData, THEN switch the collection to Enforce.

Verify:
   Get-AppLockerPolicy -Effective | Select -ExpandProperty RuleCollections

Rollback:
   Set-AppLockerPolicy -PolicyObject (New-Object -TypeName Microsoft.Security.ApplicationId.PolicyManagement.PolicyModel.AppLockerPolicy) -Merge:$false
   Stop-Service -Name AppIDSvc

PB3 · Restrict Teams External Access / Unmanaged-Tenant Contact

Prerequisites: Teams Administrator or Global Administrator role in the Microsoft 365 admin center; confirm with business stakeholders which external domains are legitimately needed before restricting to an allow-list (a default-deny can break real vendor/partner collaboration if rolled out without review).
Reboot required: No (cloud tenant setting, effective immediately to a few hours for client sync).
Rollback: Revert "Choose which domains your users have access to" back to "Allow all external domains" if the allow-list breaks legitimate business communication before the exception list is complete.

1. Microsoft 365 admin center > Teams admin center > Users > External access

2. Under "Choose which domains your users have access to," select:
   "Allow only specific external domains" and build the allow-list from your
   confirmed vendor/partner tenant domains (start from your current traffic,
   not a blank list, to avoid breaking real collaboration).

3. Alternatively, via PowerShell (Teams module):
   Connect-MicrosoftTeams
   Set-CsTenantFederationConfiguration -AllowedDomains (Get-CsAllowedDomain -Identity "vendor1.onmicrosoft.com"), (Get-CsAllowedDomain -Identity "vendor2.onmicrosoft.com")
   Set-CsTenantFederationConfiguration -AllowFederatedUsers $true -AllowTeamsConsumer $false

4. Publish organization-wide guidance: real IT support never asks staff to
   install software via an unsolicited Teams message from an external tenant.

Verify:
   Get-CsTenantFederationConfiguration | Select AllowedDomains, AllowFederatedUsers

Rollback:
   Set-CsTenantFederationConfiguration -AllowFederatedUsers $true
   # then remove the AllowedDomains restriction to return to prior (broader) access

Every query passed the required validation gates in Section 11 before being written into this map; Q1/Q3/Q5 are ready for IOA promotion today, the rest need the baseline period noted there.

Full fetched/reconstructed text for every source above is saved verbatim in SynkLoader-Hunt-sources/ alongside this file.