Loading today’s stories
Build1 distinct publisher3 min readUpdated
Expel's writeup describes a chain with no exploit in it: an external-tenant Teams message, an MSI from Azure Blob, a COM-made scheduled task, a fake lock screen, and a relay into the LAN.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Expel lists the preconditions for this chain plainly, and not one of them is a software flaw: the user has to run the MSI, PowerShell and Python and COM task creation have to be unblocked, the user has to type a valid Windows password into the fake lock screen, and C2 delivery has to succeed [12]. There are no CVEs in the writeup and no attributed group [17]. Everything that makes SynkLoader work is a configuration somebody chose, or declined to make.
The traffic side is not quiet if you measure it. A beacon with 90 to 120 second jitter [11] works out to roughly 720 to 960 callbacks per device per day [1]. It survives on destination rather than volume, and one of the three domains Expel names is tripinupdate.net, which is the shape of a string a network reviewer skims past [10].
Module delivery is selective, from multiple C2 servers [9]. Two infected hosts in the same organisation need not be carrying the same payloads, so a sweep for the PhishLocker fake lock screen [6] can come back clean on a machine that is already relaying traffic outward [7]. The stage common to every variant is the cheaper thing to hunt: a randomly named 12-character scheduled task, created through COM, running ss.py under pythonw.exe at logon and again at 10:00 each day [5].
The relay is also why a password reset does not close the ticket. Expel's response sequence puts credential rotation and session revocation alongside cross-checking internal and external authentication from the victim's IP address, investigating the PowerShell and VNC activity that follows the proxy, and hunting for other users contacted by the same external tenant [15]. That last step is the one that decides whether this was one employee or a mailbox-wide sweep of the org.
Of the four mitigations listed, three are blocks applied after the lure lands: MSI execution, Azure Blob downloads and obfuscated PowerShell; COM Task Scheduler creation; C2 and reverse proxy egress [14]. Only restricting external-tenant Teams contact acts before msiexec runs [14], and Expel points the detection work at Teams audit logs rather than email [13], which is a different log source with a different owner in most shops.
Read the confidence ladder in the report before you escalate: it separates an external Teams contact or MSI URL with no execution from confirmed user action, confirmed loader and task creation, and confirmed post-compromise proxy and VNC activity [18]. That distinction is doing real work here, because the first rung will be the most common finding and the cheapest to close. One caveat on sourcing: this account is a dev.to summary crediting Expel as the original [19], with a second writeup listed alongside it on the same campaign [20] rather than an independent confirmation of the artefacts.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Expel published a report titled "SynkLoader: when you throw in everything but the kitchen sink" dated 2026-08-20, rated severity high.
Attackers contact victims on Microsoft Teams while posing as an IT Service Desk from an external Microsoft 365 tenant.
Victims are tricked into downloading and running a PowershellCleaner MSI from Azure Blob Storage; the report cites retrieval of 331.msi from filereserve.blob.core.windows.net and deployment via msiexec.
The MSI extracts cleaner.ps1 and archive6.zip to LocalAppData, and an obfuscated PowerShell script launches a Python loader.
A randomly named 12-character scheduled task is created via COM; it runs ss.py with pythonw.exe at logon and daily at 10:00 AM.
The PhishLocker module collects entered passwords using a fake full-screen Windows lock screen.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but single-vendor and secondhand
The technical chain is specified at artifact level - named files, an MSI hash-free but URL-anchored delivery path, specific C2 domains, a beacon interval, and an explicit confidence ladder tying each conclusion to observed telemetry. That is well above typical threat-blog rigour. It is nevertheless one vendor's report, reproduced by a third-party summarizer whose body text is truncated, with no independent replication, no CVE anchor and no attribution to cross-check against other reporting.
One confirmed detection, footprint unstated
The only documented real-world occurrence is a single EDR detection in one Expel customer environment on 18 August 2026, plus a referenced related report headline describing a Teams phishing campaign. No victim counts, sectors, geographies or campaign duration are given, so the observed footprint is minimal even though the technique set is generic enough to be reusable.
Slightly overstated by severity, not by technique
The technical description is calibrated: preconditions are stated, findings are graded, and the writeup does not claim an exploit. The mild overstatement comes from a 'high' severity rating and campaign framing sitting on one confirmed detection with no prevalence data, while the chain requires the user to run an installer and type a real password into a fake lock screen. The reverse-proxy and IP-allowlist-bypass impact, by contrast, is arguably underplayed relative to how much identity tooling still trusts source IP.
MDR vendor research plus aggregator amplification
Expel is a commercial detection and response provider, and the report's central proof point is that its own EDR monitoring caught the scheduled task - a direct marketing benefit from publishing. The dev.to account restates the report for reach without adding scrutiny or disclosing that incentive. The offsetting factor is that the report publishes concrete indicators and explicit preconditions, which is costly behaviour for a purely promotional piece.
Moderate: internally consistent, externally unverified
Claim-level detail is consistent and self-limiting, so the description of the chain is likely accurate as reported. Confidence is held down by the single-publisher cluster, the secondhand and truncated rendering, the absence of any prevalence or corroborating telemetry, and the fact that the only adoption datapoint comes from the reporting vendor itself.
security
SynkLoader arrives by Teams help-desk chat and an Azure MSI, so the mail gateway sees nothing1 distinct publisher
build
Force the tool call, then hand Lightsail a long-lived key1 distinct publisher
build
A cache hit is a quota refund: semantic caching with trigrams and no vector database1 distinct publisher
build
Stop timing your GraphQL tests and start counting loader calls1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 21, 2026