You may notice that Windows Firewall events are not available in Defender for Endpoint Advanced Hunting. This is a quick post on the steps required to enable Firewall audit events.
Olaf Hartong’s excellent series on MDE Internals highlights that some MDE telemetry is based on Kernel call-backs or drivers, making those areas independent of client audit policy and enabled by default.
Other settings, however, do rely on ETW providers and therefore on the MDE client’s security audit policy. Firewall audit events will only be available in MDE if the relevant audit subcategory is enabled.
Enable client-side Firewall auditing
The following auditpol command will enable Windows Firewall client-side auditing and start sending the telemetry to MDE.
auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:enable
It’s fine to keep this enabled during day-to-day use as it will result in the following
- Blocked connections create an audit event in the Security Event Log
- Allowed connections do not create an audit event
- A single audit event is created for each connection attempt, not each packet
I don’t recommend auditing Filtering Platform Connection success events as this will generate a lot of events. You may be tempted to also enable Filtering Platform Packet Drop, but this would also generate a high volume.
Intune
You could of-course use Intune to apply the same setting to an enrolled Windows client. Create a Device Configuration Profile based on the Settings Catalog. Enter Filtering in the settings search and enable Success auditing for Object Access Audit Filtering Platform Connection
Advanced Hunting Query
You can view the Firewall events in MDE Avanced Hunting as follows:
DeviceEvents
| where Timestamp > ago(1d)
| where ActionType startswith "Firewall"
EXAMPLE RESULT:
| Timestamp | ComputerName | ActionType | IPAddress | RemoteIPCountry | RemoteIPAddr | RemotePort | Protocol | Direction | NetworkProfile | InterfaceType | RuleId | RuleName | Action | Application | Service | User | InitiatingProcess | InitiatingProcessPath | InitiatingProcessCommandLine |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2023-02-02T10:30:12.000Z | DESKTOP01 | Firewall | 192.168.1.100 | United States | 54.239.29.192 | 443 | TCP | Outbound | Domain | Wi-Fi | Allowed | Chrome.exe | User1 | chrome.exe | C:\Program Files (x86)\Google\Chrome\chrome.exe | ||||
| 2023-02-02T09:01:30.000Z | DESKTOP02 | Firewall | 192.168.1.200 | United States | 91.189.91.26 | 53 | UDP | Outbound | Public | Ethernet | Blocked | svchost.exe | DNS | User2 | svchost.exe | C:\Windows\System32\svchost.exe | |||
| 2023-02-02T08:45:55.000Z | DESKTOP03 | Firewall | 192.168.1.150 | Canada | 185.104.10.98 | 80 | TCP | Inbound | Private | Wi-Fi | Blocked |
Example Event in Windows Security Log
Log Name: Security
Source: Microsoft Windows Security Auditing
Date: 5/2/2023 10:31:12 AM
Event ID: 5444
Task Category: Filtering Platform Connection
Level: Information
Keywords: Audit Failure
User: N/A
Computer: MyComputer
Description:
A network connection request was blocked.
Subject:
Security ID: S-1-5-18
Account Name: MyComputer$
Account Domain: MYDOMAIN
Logon ID: 0x3E7
Network Information:
Direction: Inbound
Source Address: 192.168.1.100
Source Port: 54321
Destination Address: 192.168.1.200
Destination Port: 80
Protocol: TCP
Filter Information:
Filter Run-Time ID: 157314
Layer Name: Transport
Layer Run-Time ID: 13
Additional Information:
Reason: The rule does not match the traffic.
This article was originally posted on Write-Verbose.com