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