Malware Hiding in Microsoft 365? Why Your RMM Needs Deeper Visibility

If you are managing endpoints today, you likely operate under a fundamental assumption: traffic flowing to Microsoft 365 or Azure is safe. You open the firewalls, you whitelist the IPs, and you tell your monitoring tools to ignore those alerts because it’s just “normal business traffic.”

But the recent discovery of the TWINLOOT malware framework by Ontinue’s Cyber Defense Center has shattered that safety net. This isn't just another phishing attack; it’s a sophisticated Python-based implant that turns your own trusted infrastructure against you.

TWINLOOT uses SharePoint Online as a dead drop for files, leverages Microsoft Teams’ TURN infrastructure for communication, and—perhaps most worryingly—spawns a headless instance of the victim's Edge browser to send commands via the Microsoft Graph API. All of this traffic terminates at legitimate Microsoft IP addresses.

For the IT manager or the MSP technician, this creates a nightmare scenario: your RMM and monitoring tools are likely flagging the environment as “Healthy” because the processes observed (msedge.exe, teams.exe) are signed, trusted, and communicating with approved domains. The attack is hiding in plain sight, buried under the mountain of “normal” data that your current siloed tools don't know how to correlate.

The Problem: When Your RMM Is Blind to Context

Why is this so hard to catch with traditional tooling? The issue lies in the architecture of most IT stacks today.

1. Siloed Data Creates Blind Spots

In a typical environment, your RMM handles patching and remote control, your helpdesk handles tickets, and your monitoring tool handles alerts. When TWINLOOT spins up a headless Edge browser:

• The RMM sees a valid Microsoft process running and reports “Status: OK.”
• The Firewall sees traffic heading to a Microsoft IP and allows it.
• The Helpdesk sees nothing because the end-user hasn't reported an issue yet (the malware is designed to be stealthy).

None of these tools talk to each other. The RMM doesn’t know that the Edge browser was launched without a user session. The monitoring tool doesn’t know that this specific Graph API request is coming from a scripted automation rather than a human user.

2. The “Green Light” Illusion

The real-world pain for sysadmins is the false sense of security. You look at your dashboard, everything is green, but the network is compromised. By the time you detect the anomaly—perhaps through unusual data usage or a third-party breach notification—the attacker has been lurking for weeks.

This leads to the frantic “all-hands-on-deck” weekends. Technicians burn out trying to manually hunt across disconnected systems to find the patient zero. You are switching between your RMM console to check processes, your log viewer to check traffic, and your documentation to see who accessed what. It’s inefficient, slow, and exactly what attackers are betting on.

How AlertMonitor Solves This: Unified RMM for Speed and Context

AlertMonitor is built on the premise that speed kills malware. When you have to switch between three different tabs to investigate a suspicion, you lose the critical window to contain a threat like TWINLOOT.

Correlation in a Single Pane of Glass

AlertMonitor combines infrastructure monitoring, RMM, and alerting into one unified platform. When TWINLOOT tries to use the Graph API:

1. Intelligent Alerting: Instead of ignoring Edge traffic, AlertMonitor’s intelligent alerting can be configured to flag when a trusted process behaves unexpectedly (e.g., high resource usage or network activity during off-hours).
2. Instant Script Execution: You don’t just stare at a graph. With our built-in RMM, you can immediately deploy a diagnostic script to all endpoints or a specific suspicious group to check for headless browser instances.
3. Integrated Timeline: The script result isn't hidden in a separate RMM log. It feeds directly into the main timeline alongside the network alert. You see the spike in Graph API traffic and the script result confirming the headless browser in the same view.

The Remediation Workflow

In a fragmented world, fixing this involves remoting into the machine via one tool, killing the process via another, and documenting the ticket in a third. In AlertMonitor:

• You receive the alert.
• You click the endpoint in the NOC dashboard.
• You open the integrated remote session or push a kill-script immediately.
• The resolution time drops from hours of investigation to minutes of action.

Practical Steps: Hunting for Headless Browsers with AlertMonitor

You don't need to wait for a vendor to release a signature for TWINLOOT. With AlertMonitor’s RMM capabilities, you can be proactive right now.

Since TWINLOOT specifically utilizes a headless instance of Microsoft Edge, we can use a simple PowerShell script to hunt for processes that are running Edge without a visible window. This is a practical IT admin task that you can push to your Windows fleet today to audit your environment.

Run this script via the AlertMonitor script scheduler across your device groups to identify potential anomalies:

# Script to detect Headless Edge instances (Potential TWINLOOT Indicator)
# Returns Process ID and Command Line arguments for analysis.

$suspiciousProcesses = Get-CimInstance Win32_Process -Filter "Name='msedge.exe'" | 
                       Where-Object { $_.CommandLine -like '*--headless*' -or $_.CommandLine -notlike '*--type=*' }

if ($suspiciousProcesses) {
    Write-Host "WARNING: Potential headless or suspicious Edge processes found:"
    foreach ($proc in $suspiciousProcesses) {
        Write-Host "PID: $($proc.ProcessId)"
        Write-Host "CommandLine: $($proc.CommandLine)"
        Write-Host "--------------------------------"
    }
    # Exit with error code to trigger AlertMonitor Alert
    exit 1
} else {
    Write-Host "No suspicious headless Edge processes detected."
    exit 0
}

How to use this in AlertMonitor:

1. Navigate to the Script Library in AlertMonitor.
2. Create a new script, paste the code above, and save it as Audit-HeadlessEdge.ps1.
3. Select your Windows Server or Workstation groups.
4. Schedule it to run every 15 minutes.
5. Configure a Monitor Policy to trigger a Critical Alert if the script returns an exit code of 1.

Now, you have a custom, behavior-based detection rule integrated directly into your RMM and monitoring workflow. If TWINLOOT—or any other malware—tries to spin up a hidden browser, you’ll know before the data exfiltration completes.

Don't let your RMM be a passive bystander that only trusts signed executables. Use AlertMonitor to actively interrogate your endpoints and close the gaps that modern malware exploits.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources