Listen to this Post
Introduction: When the Help Desk Becomes the Trap
Microsoft Teams is built around collaboration and trust. Employees expect to receive messages from colleagues, administrators, and IT support teams, especially when something on their computer is not working correctly. That familiarity is exactly what threat actors are exploiting in a new social-engineering campaign that turns legitimate Windows support functionality into the first step of a much deeper compromise.
The campaign described by researchers Ofek Lahiani and Raz Rubin combines fake IT support requests, Microsoft Teams, Quick Assist, signed legitimate applications, malicious DLL sideloading, WMI, encrypted cloud infrastructure, and a localhost reverse shell into a carefully constructed attack chain.
The most concerning part is not any single technique. Each individual component can appear relatively ordinary. Quick Assist is legitimate. FileZilla, Altap Salamander, and Kodi are legitimate applications. msiexec.exe is a legitimate Windows installer utility. WMI is a standard Windows management technology. AWS API Gateway is a legitimate cloud service.
Put them together, however, and they form a sophisticated remote-access framework designed to make malicious activity look like normal Windows administration.
The Attack Starts With a Simple Teams Message
The campaign begins with social engineering rather than an exploit.
Attackers reach potential victims through external Microsoft Teams conversations while pretending to be IT technicians. They claim that the employee has a technical issue and needs assistance.
The request is deliberately mundane.
There may be no suspicious attachment, no obviously malicious URL, and no complicated vulnerability exploitation at the beginning. Instead, the attacker tries to convince the employee to trust a person on the other side of the Teams conversation.
Once the victim accepts the explanation, the attacker asks them to launch Microsoft Quick Assist, Microsoft’s legitimate remote-support application.
That single decision can fundamentally change the security situation.
Quick Assist Gives the Attacker the Hands-On Access They Need
Quick Assist is not malware. It is a legitimate Windows feature designed to allow one person to remotely assist another.
The problem is that legitimate remote-support software can become extremely dangerous when an attacker convinces the victim to authorize the session.
After the victim grants access, the threat actor effectively gains hands-on control of the Windows machine.
From this point onward, the attack no longer depends entirely on persuading the victim to click something. The attacker can interact with the system directly, download files, execute commands, inspect the environment, and establish additional access mechanisms.
This is a classic example of why legitimate remote administration tools can become weapons in the hands of an authenticated or socially engineered attacker.
The Malicious MSI Arrives From Amazon S3
With remote control established, the attacker downloads a malicious Windows Installer package from an attacker-controlled Amazon S3 bucket.
The package is executed through
Observed installer filenames include:
SE15724BW.msi
KB5094126.msi
The second filename is particularly interesting because it resembles the naming convention of a Windows update.
That type of naming can reduce suspicion when someone encounters the file during a remote-support session.
Instead of presenting the victim with something obviously malicious, the attacker creates an environment where the activity can appear to be related to troubleshooting, software installation, or system maintenance.
Signed Software Becomes Part of the Deception
The MSI package does not simply drop an obviously malicious executable.
Instead, the attackers use legitimate, digitally signed applications such as FileZilla, Altap Salamander, or Kodi, accompanied by a malicious DLL.
This is an important part of the
The legitimate executable provides the appearance of normal software while the malicious DLL is loaded alongside it.
For an employee watching the screen, launching a recognizable application may not immediately raise suspicion.
For defenders, the situation is more complicated because the process itself may have a valid signature.
DLL Sideloading Turns Trust Into a Weapon
The next stage relies on DLL sideloading.
The legitimate signed application searches for required DLL files. Windows’ DLL loading behavior can result in the application loading a malicious DLL placed in the same installation directory instead of the legitimate library expected from a trusted system location.
Known malicious DLL names include:
vcruntime140.dll
vcruntime140_1.dll
zlib1.dll
The technique is effective because the malicious code can execute inside the context of a legitimate signed application.
The signature of the executable does not magically make every DLL it loads trustworthy.
This distinction is critical for defenders.
A signed executable can still be part of an attack chain.
AWS Infrastructure Helps Hide the Command Channel
Once loaded, the malicious DLL establishes an encrypted HTTPS connection to an AWS API Gateway endpoint.
The use of infrastructure associated with:
execute-api.amazonaws.com
provides another layer of camouflage.
Cloud services are everywhere inside modern enterprise networks. HTTPS connections to major cloud providers are not automatically suspicious, and blocking them outright would break legitimate business applications.
That gives attackers an attractive environment for command-and-control communication.
Instead of communicating with an obviously suspicious server, the malware can communicate through infrastructure that resembles ordinary cloud traffic.
The Real Trick: Separating the Network Relay From the Shell
The attack becomes even more interesting when the DLL launches the reverse-shell component through Windows Management Instrumentation, or WMI.
The malicious loader uses WMI to start a separate process.
That creates an additional layer between the initial signed application and the interactive shell.
Instead of defenders seeing a simple chain such as:
Malicious DLL → Reverse Shell → Internet
they may instead observe something closer to:
Signed Application → Malicious DLL → WMI → Shell Component
Meanwhile, the network communication is handled separately.
This fragmentation is intentional.
WmiPrvSE.exe Becomes Part of the Attack Chain
One particularly useful detection clue is the appearance of unusual child processes associated with WmiPrvSE.exe.
Researchers observed processes with names including:
File Transfer.exe
Module Agent.exe
SupportHost.exe
The important point is not necessarily the filename itself.
Attackers can rename executables.
The more valuable signal is the relationship between the processes.
A Windows management process unexpectedly creating a suspicious executable, particularly after an externally initiated Quick Assist session, deserves investigation.
The Reverse Shell Stays on Localhost
The reverse-shell component listens on:
127.0.0.1:9001
At first glance, that may seem strange.
Why would malware that needs remote access listen only on localhost?
Because the attacker does not need the shell to communicate directly with the internet.
Instead, the malicious DLL functions as a relay.
The external AWS command-and-control connection communicates with the DLL, while the DLL communicates locally with the reverse shell.
The architecture can therefore be visualized as:
Attacker
|
| HTTPS
v
AWS API Gateway
|
v
Malicious DLL
|
| localhost
v
127.0.0.1:9001
|
v
Reverse Shell
|
v
cmd.exe / ConPTY
This separation is one of the strongest elements of the attack design.
Why Localhost Makes Detection More Difficult
Security products frequently rely on network telemetry to identify malicious remote-control activity.
But in this architecture, the reverse shell does not need to establish an external network connection.
The signed application and malicious DLL handle the external communication.
The shell remains local.
That creates an unusual division of responsibilities:
The component with network access is not necessarily the component executing commands.
And the component executing commands may not have a direct external connection at all.
This can complicate process-to-network correlation and make the attack harder to recognize through simple rules.
ConPTY Makes the Shell Look More Like a Real Terminal
After the local connection is established, the shell agent creates a Windows ConPTY, or pseudoconsole, connected to cmd.exe.
This gives the attacker an interactive command-line experience.
Rather than sending isolated commands through a primitive execution mechanism, the attacker can interact with the victim’s machine in a manner similar to sitting directly in front of it.
That significantly increases operational flexibility.
The attacker can inspect the environment, execute reconnaissance commands, search for files, identify accounts, and potentially move toward additional objectives.
Reconnaissance Begins With Ordinary Windows Commands
Observed commands include:
whoami ipconfig /all net user /dom dsregcmd /status
None of these commands are inherently malicious.
That is precisely why they are useful to attackers.
whoami identifies the current security context.
ipconfig /all provides detailed network configuration.
net user /dom can help enumerate domain users.
dsregcmd /status provides information about device registration and identity configuration, including useful clues about Microsoft Entra-connected environments.
Individually, these commands may be completely legitimate during troubleshooting.
Together, especially following a suspicious remote-support session, they can reveal the attacker’s reconnaissance phase.
Cloud-Synchronized Folders Become Potential Targets
The campaign also involves enumeration of cloud-synchronized document directories.
This is an important development in modern endpoint attacks.
Attackers no longer need to search only for traditional local documents.
Business information may be synchronized through cloud-storage applications, meaning valuable corporate files can exist inside ordinary user directories.
Once an attacker has interactive access, folders containing synchronized documents can become attractive targets for theft, credential discovery, intellectual property collection, or further reconnaissance.
Persistence Can Survive the Initial Support Session
The campaign may also establish persistence through a Startup-folder shortcut named:
salamand.lnk
The shortcut relaunches the signed loader when the user logs in.
This changes the attack from a temporary remote-support incident into something much more persistent.
Even if the original Teams conversation ends and Quick Assist is closed, the malicious components may remain on the system.
The attacker therefore gains a potential path back into the machine without needing to repeat the original social-engineering conversation.
Deep Analysis: How the Attack Chain Works
Stage 1 — Social Engineering
The first stage attacks the employee rather than the operating system.
The attacker impersonates IT support and creates a believable technical problem.
This demonstrates an increasingly important cybersecurity reality: identity and trust can be as important as software vulnerabilities.
Stage 2 — Legitimate Remote Assistance
The victim opens Quick Assist.
From the perspective of endpoint security, the application itself is legitimate.
The dangerous event is the context in which it is being used.
Organizations should therefore investigate unexpected remote-support sessions rather than assuming every session involving a Microsoft-signed support tool is safe.
Stage 3 — MSI Execution
The attacker downloads an MSI package and launches it using:
msiexec.exe /i SE15724BW.msi
Defenders should not automatically classify msiexec.exe as malicious.
Instead, investigate who launched it, where the MSI originated, what it installed, and what processes appeared afterward.
Useful telemetry includes:
Get-Process msiexec
and:
Get-CimInstance Win32_Process | Select-Object ProcessId, ParentProcessId, Name, CommandLine Stage 4 — Signed Binary Proxying and DLL Sideloading
The legitimate application becomes the execution vehicle.
A suspicious installation directory containing a legitimate executable alongside an unexpected DLL should receive particular attention.
For example:
Get-ChildItem "C:\Path\To\Application" | Select-Object Name, Length, LastWriteTime
Security teams should also verify signatures:
Get-AuthenticodeSignature "C:\Path\To\Application\FileZilla.exe"
A valid signature proves the executable was signed by a trusted publisher. It does not prove that every file surrounding it is trustworthy.
Stage 5 — WMI Process Creation
WMI is then used to create the reverse-shell process.
Defenders can investigate WMI activity through Windows event telemetry and process-creation logs.
PowerShell can also help identify WMI-related processes:
Get-CimInstance Win32_Process |
Where-Object {$_.Name -eq "WmiPrvSE.exe"} |
Select-Object ProcessId, ParentProcessId, CommandLine
The key is correlation rather than a single indicator.
Stage 6 — Investigating Port 9001
A local listener on port 9001 can provide a valuable detection opportunity.
Administrators can inspect active listeners with:
netstat -ano | findstr :9001
Or with PowerShell:
Get-NetTCPConnection -LocalPort 9001 -ErrorAction SilentlyContinue
If a listener appears unexpectedly, map the associated PID:
tasklist /FI "PID eq <PID>"
Then investigate the executable path and parent process.
Stage 7 — Inspecting Suspicious Startup Persistence
Defenders should examine user Startup locations for unexpected shortcuts or executables.
For example:
Get-ChildItem "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup" -Force
And:
Get-ChildItem "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp" -Force
A suspicious .lnk file such as salamand.lnk should be treated as a potential persistence mechanism and investigated in context.
Stage 8 — Hunting for the Initial Access Path
Endpoint investigation should not begin and end with the malware.
The original Teams conversation may be the most important evidence.
Security teams should determine:
Who contacted the employee?
Was the account external?
What identity did the attacker claim?
Was Quick Assist launched?
When did the remote session begin?
Which files were downloaded afterward?
Which processes were created?
Did WMI become active?
Was persistence installed?
Without understanding the initial social-engineering event, defenders risk removing the malware while leaving the underlying attack path intact.
What Undercode Say:
Trust Is Becoming an Attack Surface
The most important lesson from this campaign is that attackers do not always need to break Windows.
Sometimes they simply need the employee to help them enter.
Quick Assist Is Not the Villain
Quick Assist is a legitimate support technology.
The problem is the abuse of legitimate functionality through impersonation.
Remote Support Needs Stronger Context
Organizations should monitor remote-support activity based on context rather than treating every Quick Assist session equally.
External Teams Contacts Deserve Attention
Unexpected external Teams conversations claiming to be IT support should immediately raise suspicion.
Digital Impersonation Is Getting Better
An attacker does not necessarily need to compromise an administrator account if they can convincingly pretend to be one.
Signed Does Not Mean Safe
A valid digital signature tells defenders who signed an executable.
It does not guarantee that the entire execution chain is legitimate.
DLL Sideloading Remains Powerful
DLL sideloading continues to be attractive because attackers can hide malicious code behind trusted applications.
Cloud Services Are Difficult to Block
AWS, Microsoft, Google, and other major cloud providers host enormous amounts of legitimate traffic.
That makes cloud-based command-and-control especially challenging.
HTTPS Creates More Noise
Encrypted traffic protects legitimate businesses and attackers alike.
Network defenders increasingly need behavioral signals instead of relying only on destination blocking.
Localhost Can Hide the Relationship
A reverse shell communicating through 127.0.0.1 may not look like a conventional internet-connected backdoor.
Process Correlation Matters
The question is not simply “Is this executable legitimate?”
The better question is:
“Why did this process launch this child process at this exact time?”
WMI Should Be Investigated Contextually
WMI is extensively used by administrators.
But WMI creating unusual executables after a suspicious remote-support session is a very different signal.
Reconnaissance Commands Are Not Automatically Malicious
whoami, ipconfig, and dsregcmd are legitimate administrative commands.
Their value to defenders comes from context and sequencing.
Attackers Need Visibility Before Theft
Before stealing data, attackers need to understand the environment.
That is why reconnaissance commands can provide an early warning window.
Cloud-Synchronized Data Changes the Game
Sensitive documents may now be located inside ordinary synchronized folders rather than traditional network shares.
Persistence Raises the Stakes
A Startup shortcut transforms a temporary compromise into a potentially recurring compromise.
Social Engineering and Malware Are Converging
The campaign demonstrates how human manipulation can become the delivery mechanism for technically sophisticated malware.
The First Five Minutes Matter
The moment a suspicious support session begins, security telemetry should capture the activity.
Endpoint Telemetry Is Critical
Process creation, command lines, network connections, DLL loads, WMI activity, and persistence mechanisms can collectively reveal the attack.
Network Telemetry Alone Is Not Enough
Because the shell communicates locally, network-only monitoring may miss important parts of the execution chain.
EDR Needs Behavioral Detection
An effective detection strategy should connect events rather than simply search for known filenames.
Filenames Are Weak Indicators
SupportHost.exe sounds legitimate.
So does Module Agent.exe.
Names can be changed instantly.
Parent-Child Relationships Are Stronger
A suspicious process launched by WmiPrvSE.exe may provide much more useful evidence than the filename itself.
Attackers Are Building Modular Backdoors
The separation between loader, network relay, WMI launcher, and shell demonstrates modular malware engineering.
Modularity Improves Evasion
Each component has a specific role, reducing the number of obvious malicious characteristics in any single process.
Legitimate Tools Are Becoming Attack Infrastructure
This is not limited to Quick Assist.
Remote administration software, scripting engines, cloud platforms, and system utilities can all become components of malicious campaigns.
Employee Awareness Still Matters
Technical defenses cannot completely compensate for a convincing impersonation attack.
IT Departments Need Verification Procedures
Employees should have a simple method to verify whether an alleged IT technician is genuine before granting remote access.
IT Support Should Not Be Trusted Automatically
The more privileged the requested action, the stronger the verification should be.
Remote Access Should Be Auditable
Organizations should know when remote-support applications are being launched and by whom.
Security Teams Need the Full Timeline
The most useful investigation is chronological:
Teams message → Quick Assist → MSI → signed executable → DLL → WMI → localhost shell → reconnaissance → persistence.
Detection Should Follow the Chain
Finding one indicator is useful.
Finding the entire chain is much more powerful.
Attackers Are Exploiting Normality
The sophistication of this campaign comes from how ordinary every component appears.
Modern Defense Requires Context
The security question is increasingly not “Is this file malicious?”
It is “Does this behavior make sense for this user, device, process, and moment?”
The Human Firewall Still Matters
Employees remain an essential security control.
But they need procedures that make the safe choice easy.
Cloud, Endpoint, and Identity Must Work Together
Teams telemetry alone may not explain the compromise.
Endpoint telemetry alone may not reveal the initial social-engineering event.
Identity logs can connect the pieces.
The Attack Is a Warning About Trust
Every trusted application represents potential functionality an attacker may abuse.
Detection Opportunities Still Exist
The campaign leaves useful signals: unusual Quick Assist activity, suspicious MSI downloads, DLL sideloading, WMI process creation, localhost listeners, reconnaissance commands, and Startup persistence.
The Bigger Lesson
The future of endpoint security will depend less on recognizing one “bad file” and more on understanding how a sequence of normal-looking actions becomes abnormal when connected together.
✅ Legitimate Quick Assist Abuse Is Plausible
Microsoft Quick Assist is a legitimate remote-assistance capability, and social engineering can abuse legitimate remote-access functionality. The important distinction is that the application itself is not inherently malicious.
✅ DLL Sideloading Is a Real Windows Attack Technique
A legitimate executable can load a malicious DLL when attackers exploit DLL search-order behavior. A trusted executable’s signature therefore should not be treated as proof that its entire execution environment is clean.
✅ WMI Can Be Abused for Process Execution
Windows Management Instrumentation is a legitimate administration technology that can also be abused by attackers to execute or launch processes. WMI activity therefore needs contextual monitoring rather than blanket blocking.
✅ Localhost-Based Relay Architectures Can Complicate Detection
Separating external communications from local shell activity can make process-to-network correlation more difficult. This is a legitimate defensive concern when investigating modern multi-stage malware.
❌ A Microsoft-Signed Tool Is Not Automatically Safe
The presence of Quick Assist, msiexec.exe, WMI, or another Microsoft-signed component does not prove an incident is benign. Attackers frequently abuse trusted functionality.
❌ Blocking AWS Is Not a Practical Defense
AWS infrastructure hosts enormous amounts of legitimate business traffic. A stronger defense is behavioral detection and investigation of unusual cloud communications rather than indiscriminate blocking.
Prediction
(+1) Remote-Support Abuse Will Become an Even Bigger Enterprise Threat
As organizations increasingly rely on remote assistance and collaboration platforms, attackers are likely to continue abusing the trust employees place in support personnel.
The next generation of these campaigns will probably combine impersonation with legitimate remote-management tools, cloud-hosted command infrastructure, and increasingly modular payloads.
Security teams will respond by placing greater emphasis on identity verification, remote-support auditing, behavioral EDR detection, and cross-platform telemetry correlation.
The strongest organizations will not simply ask whether Quick Assist was used.
They will ask who initiated the session, who approved it, what happened immediately afterward, what processes were launched, where those processes communicated, and whether the entire sequence makes sense.
That shift—from detecting malicious files to understanding malicious behavior—will become one of the defining requirements of modern enterprise security.
▶️ Related Video (78% Match):
🕵️📝Let’s dive deep and fact‑check.
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
References:
Reported By: cyberpress.org
Extra Source Hub (Possible Sources for article):
https://www.digitaltrends.com
Wikipedia
OpenAi & Undercode AI
Image Source:
Unsplash
Undercode AI DI v2
🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]
📢 Follow UndercodeNews & Stay Tuned:
𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin | 🦋BlueSky | 🐘Mastodon | 📺Youtube
