Skip to content

Back to the catalog

dfir.chwriteup

Oh my .. ! - Suspicious network traffic detected including Ransomware

A DFIR consultant walks through two Microsoft Defender for Endpoint high-severity "Ransomware" alerts that turned out to be benign inbound TCP SYN scans (ConnectionAttempt, not InboundConnectionAccepted) from an IP Microsoft had classified as malicious. The post shares KQL queries against DeviceNetworkEvents to identify internet-facing devices (via RemoteIPType and InboundInternetScanInspected), explains the difference between ConnectionAttempt and InboundConnectionAccepted ActionTypes, and stresses correlating with DeviceLogonEvents before concluding an alert is a false positive.

TL;DR DFIR walkthrough showing how misleading MDE "Ransomware" alerts turned out to be harmless SYN-scan connection attempts, with reusable KQL to spot internet-exposed hosts.
Document

What it is

A DFIR walkthrough of two January 2025 Microsoft Defender for Endpoint (MDE) "Ransomware"-category high-severity alerts that both traced to inbound TCP SYN packets from 185.149.120.3 — one to port 25 (SMTP), one to a mail server. The value beyond the summary is the actual KQL and the correlation logic for deciding whether an accepted connection is real compromise.

How it works

MDE has classified 185.149.120.3 as malicious, so a single inbound SYN (Tcp Flags: 2, 60-byte packet) is enough to fire a high-severity alert — with no useful detail in the GUI. The distinguishing signal is the ActionType: ConnectionAttempt (SYN only) versus InboundConnectionAccepted (connection established). Even InboundConnectionAccepted is not proof of intrusion, because a connection is normally accepted before authentication — you must confirm a successful login separately.

What to do

Export and analyze the full device timeline; the GUI alone is insufficient. Find internet-facing devices (query credited to Roger Eisenecher):

DeviceNetworkEvents
| where RemoteIPType == "Public"
| where ActionType == @"InboundConnectionAccepted"
| distinct DeviceName, InitiatingProcessFileName, LocalPort

Find devices being scanned from the internet:

DeviceNetworkEvents
// Filter on devices that have been scanned
| where ActionType == "InboundInternetScanInspected"
| project IP_Source_ScannerAttempt=LocalIP,Country_Source_ScannerAttempt=tostring(geo_info_from_ip_address(LocalIP).country), PublicScannedIP= RemoteIP,PublicScannedIP_country=tostring(geo_info_from_ip_address(RemoteIP).country), PublicScannedPort= RemotePort,DeviceName

A host appearing in both queries confirms internet exposure. Also check host tags in MDE as a third exposure signal. For InboundConnectionAccepted events (notably RDP port 3389), correlate DeviceNetworkEvents with DeviceLogonEvents to check whether a login actually succeeded in the same window before treating it as compromise.

flowchart TD
  A[MDE Ransomware alert] --> B{ActionType?}
  B -->|ConnectionAttempt SYN| C[No compromise: flagged IP scan]
  B -->|InboundConnectionAccepted| D{Successful login in DeviceLogonEvents?}
  D -->|No| E[Likely benign / exposure only]
  D -->|Yes| F[Investigate as possible access]

Caveats

The customer initially claimed the server was not internet-exposed; the queries proved otherwise — don't trust asserted exposure. An accepted RDP connection with no successful login "does not have to be feared too much," but the author flags exposed RDP as a likely misconfiguration worth closing regardless. The write-up also raises whether such alerts belong under a "Ransomware" category at all, given the underlying event is merely a scan against a malicious-tagged IP.

Organisations named here

  • EDR Internals From a Defenders Perspective
  • Olaf Hartong

Technologies named here

  • Windows Defender for Endpoint
  • Kusto Query Language
  • Windows Server
  • Sysmon
  • Mail server
  • RDP
  • Windows Defender
  • KQL