Microsoft Defender Now Monitors Remote RPC Activity: What It Catches and How to Hunt

Executive Summary

Microsoft has extended Defender’s existing Windows Filtering Platform (WFP) integration to audit inbound remote RPC calls at OpNum-level granularity — meaning Defender can now see not just which RPC interface a remote peer touched, but which specific function was invoked. The new telemetry is exposed in Advanced Hunting via a fresh ActionType on the DeviceEvents table (InboundRemoteRpcCall) and is already driving detections, including Impacket-style hands-on-keyboard activity, suspicious remote service creation, LSA secrets theft, unusual RPC user / session discovery, and authentication coercion attempts. Workstation coverage is GA; server coverage is rolling out gradually.

For defenders, this is the biggest practical win since SMB enumeration telemetry: a large chunk of post-exploitation tooling — DCSync, SecretsDump, SharpHound, PetitPotam-style coercion, remote service creation for lateral movement — rides on a handful of well-known RPC interfaces (Remote Registry, Service Control Manager, Task Scheduler, WMI, srvsvc, DRSUAPI), and Defender now sees the specific OpNum being called regardless of the transport encryption underneath (SMB3, named pipes, RPC-over-HTTP). Microsoft also published three sample Advanced Hunting queries — remote registry save, remote service creation, and remote session enumeration via srvsvc!NetrSessionEnum — that drop straight into existing hunting playbooks.

What Changed in Defender’s RPC Visibility

RPC is one of those protocols whose ubiquity makes it both a perfect attacker channel and a nightmare to monitor by packet capture. Almost every interesting remote-administration capability on a Windows host — service control, scheduled tasks, the registry, WMI, AD replication, the DNS server, the print spooler — is a thin RPC shim over a kernel or service object. Many of those interfaces also accept RPC traffic over encrypted transports (SMB3 named pipes, TLS-wrapped RPC-over-HTTP), so a network sensor often cannot see the bytes even when it sees the conversation.

The change Microsoft announced is that Defender now hooks RPC dispatch through the existing WFP integration with enough granularity to identify the specific OpNum being called, not just the interface UUID. That distinction matters because the value of a given interface is usually concentrated in two or three operations: Service Control Manager’s RCreateServiceW matters, the rest of its 100+ OpNums are noise; Remote Registry’s BaseRegSaveKey / BaseRegSaveKeyEx matter, basic key opens don’t.

RPC basics, briefly

• Interface — the logical RPC server, identified by a UUID. Examples: Task Scheduler, Remote Registry, Service Control Manager, srvsvc.
• OpNum (Operation Number) — an ordinal into the interface’s function table. RCreateServiceW is OpNum 12 on the Service Control Manager interface; BaseRegQueryValue is OpNum 17 on Remote Registry; NetrSessionEnum is OpNum 12 on srvsvc.

Why so many post-exploitation tools live on RPC

• Lateral movement. Remote service creation via the SCM interface, remote scheduled-task creation via the Task Scheduler interface, and remote WMI execution are the classical lateral-movement primitives, and all three are RPC.
• Credential theft. DCSync abuses the DRSUAPI replication interface to pull credential material out of Active Directory. SecretsDump-style attacks query the SAM and LSA hives through Remote Registry. Both are RPC-on-the-wire.
• Authentication coercion. PetitPotam, PrinterBug, DFSCoerce and friends call benign RPC functions whose side-effect is “the target authenticates somewhere on the attacker’s behalf”.
• Discovery. SharpHound / BloodHound collection leans heavily on srvsvc!NetrSessionEnum, srvsvc!NetrShareEnum, and SAMR-based user enumeration — all RPC.

Microsoft links to Jonathan Johnson’s mapping of RPC interfaces to attack techniques for a more comprehensive index, which is the natural follow-up reading.

How the Audit Path Works

Because RPC volume on a Windows host is enormous, on-wire monitoring at scale is impractical — and encrypted transports often make it impossible. Defender’s solution is to instrument the dispatch path itself rather than the wire. Specifically, Defender extends the existing RPC integration with the Windows Filtering Platform (WFP) to add OpNum-level granularity, so the audit event can identify both the interface and the specific function being invoked.

Three properties of the design are worth pulling out:

• Inbound only. The audit is scoped to remote RPC calls observed on the server side — the target of the call — not on the originating client. Defender doesn’t need any visibility into the source device to flag the call. Local same-host RPC and outbound client-side RPC are explicitly out of scope.
• Audit-only WFP filters. The filters do not block, redirect, or modify RPC traffic. They tap the dispatch path, emit telemetry, and get out of the way. The cost to legitimate workloads is essentially the cost of the audit hook itself.
• Transport-agnostic. Because Defender is hooking dispatch rather than the network layer, it sees the call regardless of whether it arrived over SMB3 named pipes, plain TCP, RPC-over-HTTP, or any other encrypted transport. The encryption protects the bytes on the wire; it doesn’t protect the call from the dispatcher.

Coverage is selective — Defender targets specific operations on a dynamic list of interfaces that includes (but is not limited to) Remote Registry, Service Control Manager, Task Scheduler, and WMI. Workstation rollout is generally available; server rollout is in gradual deployment as of publication.

Detections Already Riding on RPC Telemetry

According to Microsoft, the following Defender detections and disruption triggers are now driven (in whole or in part) by the new inbound remote RPC visibility:

• Ongoing hands-on-keyboard attack via Impacket toolkit — pattern detection across the Impacket suite (psexec.py, smbexec.py, wmiexec.py, secretsdump.py) which all chain a recognisable sequence of RPC interfaces.
• Suspicious service creation initiated remotely — SCM RCreateServiceW / friends from an unusual remote source.
• Indication of local security authority secrets theft — Remote Registry interactions targeting SECURITY / SAM hives, the classic SecretsDump fingerprint.
• Unusual RPC user and session discovery — abnormal-volume or abnormal-source enumeration via srvsvc!NetrSessionEnum, SAMR enumeration, etc.
• Authentication coercion attack — calls on EFSRPC, MS-DFSNM, MS-RPRN, MS-WSP and similar interfaces whose side-effect is to coerce the target into authenticating elsewhere.

(The original post includes Defender XDR alert and detection-details screenshots illustrating these surfacing in the portal. View them at the source article linked at the top.)

Hunting in Advanced Hunting

The new telemetry surfaces in the DeviceEvents table under ActionType == 'InboundRemoteRpcCall', with the interface UUID and OpNum carried inside the AdditionalFields JSON column. Microsoft published three reference KQL queries; each is dropped in verbatim below for reuse in your own hunting playbooks.

Query 1: Remote Registry hive saves (SecretsDump fingerprint)

Targets BaseRegSaveKey (OpNum 20) and BaseRegSaveKeyEx (OpNum 31) on the Remote Registry interface (UUID 338cd001-2244-31f1-aaaa-900038001003). These two operations are exactly what SecretsDump-style attacks call to materialise the SAM, SECURITY, or SYSTEM hives into a file the attacker can read back.

let remoteRegistryInterface = '338cd001-2244-31f1-aaaa-900038001003';
let registrySaveOpnums = dynamic([20, 31]); // BaseRegSaveKey, BaseRegSaveKeyEx
DeviceEvents
| where ActionType == 'InboundRemoteRpcCall'
| extend AdditionalFields = parse_json(AdditionalFields)
| extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum)
| where RpcInterface == remoteRegistryInterface and OpNum in(registrySaveOpnums)

Query 2: Remote Service Creation (lateral movement)

Targets the five service-creation OpNums on the Service Control Manager interface (UUID 367abb81-9844-35f1-ad32-98f038001003): RCreateServiceW (12), RCreateServiceA (24), RCreateServiceWOW64A (44), RCreateServiceWOW64W (45), RCreateWowService (60). Hit-and-disappear remote service creation is the standard Impacket-psexec.py / smbexec.py lateral-movement primitive.

let remoteServicesInterface = '367abb81-9844-35f1-ad32-98f038001003';
let serviceCreationOpnums = dynamic([12, 24, 44, 45, 60]); // RCreateServiceW, RCreateServiceA, RCreateServiceWOW64A, RCreateServiceWOW64W, RCreateWowService
DeviceEvents
| where ActionType == 'InboundRemoteRpcCall'
| extend AdditionalFields = parse_json(AdditionalFields)
| extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum)
| where RpcInterface == remoteServicesInterface and OpNum in(serviceCreationOpnums)

Query 3: NetrSessionEnum (session discovery)

Targets NetrSessionEnum (OpNum 12) on the srvsvc interface (UUID 4b324fc8-1670-01d3-1278-5a47bf6ee188) — SharpHound / BloodHound’s primary mechanism for mapping which users are logged into which hosts. The summarize step groups by calling principal, which is usually the more useful axis for ranking suspicious enumeration.

let srvsvcInterface = '4b324fc8-1670-01d3-1278-5a47bf6ee188';
let netrSessionEnumOpnum = 12;
DeviceEvents
| where ActionType == 'InboundRemoteRpcCall'
| extend AdditionalFields = parse_json(AdditionalFields)
| extend RpcInterface = tostring(AdditionalFields.RpcInterfaceUuid), OpNum = toint(AdditionalFields.RpcOpNum)
| where RpcInterface == srvsvcInterface and OpNum == netrSessionEnumOpnum
| summarize dcount(DeviceId) by AccountName, AccountDomain, AccountSid

Key Takeaways

• Defender now sees specific RPC operations, not just interfaces. OpNum-level granularity is the difference between “someone hit Remote Registry” (noise) and “someone called BaseRegSaveKey on Remote Registry” (SecretsDump).
• The hook lives at WFP, not the wire. Encrypted transports (SMB3 named pipes, RPC-over-HTTP, etc.) don’t blind the new audit because the audit is at dispatch time, not packet time.
• Inbound-only, server-side scope. Defender does not need any visibility into the calling host to flag the call. Local same-host RPC and outbound client-side RPC are out of scope.
• The Advanced Hunting hook is DeviceEvents | where ActionType == 'InboundRemoteRpcCall', with interface UUID and OpNum inside the AdditionalFields JSON. Easy to compose with existing detections.
• Five named detections already ride on the new telemetry: Impacket hands-on-keyboard, suspicious remote service creation, LSA secrets theft, unusual user/session discovery, and authentication coercion.
• Workstations GA, servers rolling out. Plan hunting playbooks for asymmetric coverage during the rollout window.
• The hunting playbook generalises trivially. Any technique with a known UUID + OpNum signature is a one-line filter on AdditionalFields.RpcInterfaceUuid and AdditionalFields.RpcOpNum.

Defensive Recommendations

• Adopt the three Microsoft-published queries as baseline hunts. Remote Registry hive saves, remote service creation, and NetrSessionEnum abuse cover most of the Impacket / SharpHound surface for free.
• Build a coercion query. Add InboundRemoteRpcCall filters on the EFSRPC (MS-EFSR), MS-DFSNM, MS-RPRN, and MS-WSP interfaces — PetitPotam-style coercion calls into those.
• Pair the new telemetry with Authenticated-Source / Logon-Type joins. An InboundRemoteRpcCall row plus IdentityLogonEvents in Defender for Identity tells you who called what from where in one query.
• Baseline normal callers per interface. Many of these RPC interfaces have a small population of legitimate callers (vulnerability scanners, MDM agents, monitoring tools). Allowlist by service principal before alerting.
• Verify server rollout against your fleet. While server-side coverage is gradually rolling out, confirm InboundRemoteRpcCall events exist on member servers and DCs before relying on the new detections for high-fidelity alerting on those tiers.
• Constrain the interfaces themselves where you can. The Remote Registry service can be disabled on most workstations; RestrictRemoteSAM and Group Policy LSASS restrictions reduce SAMR / LSA exposure; RPC filter policies (netsh rpc filter) can block remote use of specific interfaces entirely.
• Don’t ignore client-side telemetry just because Defender doesn’t capture it. Outbound RPC client calls remain valuable signal at the source host — Sysmon Event ID 22 (DNS) and Event ID 3 (network connect) plus ETW Microsoft-Windows-RPC capture client-side activity Defender’s new feature is not designed to surface.

Conclusion

OpNum-level visibility on inbound remote RPC closes a long-standing gap between “we know an attacker is using RPC for everything” and “we can actually tell which RPC operation just happened on this server”. The technique catalogue the new telemetry unlocks — Impacket-style lateral movement, SecretsDump-style credential extraction, BloodHound enumeration, coercion attacks — is exactly the high-value middle of modern post-exploitation. Pair Microsoft’s three sample queries with a coercion-interface filter and a baseline of legitimate callers, and most of the practical AD-attack toolkit becomes a one-line KQL match in Advanced Hunting.

Original text: “Microsoft Defender now monitors RPC activity” by EdanZwick at Microsoft Tech Community / Microsoft Defender for Endpoint Blog.