Forum Discussion
Blocked IP In IOC In MDE, however the traffic is not blocked from the source
We added the suspicious ip in MDE indicator list to block the traffic from that ip accross all devices, however the traffic from that source still observed with inbound connection accepted action.
Hi,
We ran into exactly the same issue in our environment.
The main reason: MDE IP indicators only block OUTBOUND connections. They're enforced through Network Protection, which inspects connections that the device itself initiates. Connections coming IN from that IP to your devices are not blocked by the indicator, which is why you still see "InboundConnectionAccepted" in DeviceNetworkEvents.
I am not sure if you found your solution but If you are still seeing outbound connections getting through, these are worth checking:
1. Network Protection must be in Block mode, not Audit or Off. On a device, run: Get-MpPreference | Select EnableNetworkProtection (1 = Block, 2 = Audit, 0 = Off).
2. Custom network indicators must be turned on under Settings....Endpoints.....Advanced features.
3. Microsoft Defender Antivirus must be in active mode, not passive mode.
4. The indicator's scope should include correct device group.
5. Only single public IP addresses are supported. CIDR ranges and internal/private IPs aren't supported in IP indicators.
How we fixed it:
Since our traffic was inbound, the indicator was never going to stop it. We blocked it at the firewall level instead by [creating an inbound block rule for the IP in Windows Defender Firewall, deployed through Intune (Endpoint security > Firewall) / adding the IP to our perimeter firewall block list]. We kept the MDE indicator in place so any outbound connections to that IP are blocked as well.
We then confirmed it was working with this Advanced Hunting query:
DeviceNetworkEvents
| where Timestamp > ago(1d)
| where RemoteIP == "x.x.x.x"
| summarize Connections = count() by ActionType, DeviceName
After the firewall rule, the inbound accepted connections stopped showing up.
Hope this helps.
6 Replies
Hi,
We ran into exactly the same issue in our environment.
The main reason: MDE IP indicators only block OUTBOUND connections. They're enforced through Network Protection, which inspects connections that the device itself initiates. Connections coming IN from that IP to your devices are not blocked by the indicator, which is why you still see "InboundConnectionAccepted" in DeviceNetworkEvents.
I am not sure if you found your solution but If you are still seeing outbound connections getting through, these are worth checking:
1. Network Protection must be in Block mode, not Audit or Off. On a device, run: Get-MpPreference | Select EnableNetworkProtection (1 = Block, 2 = Audit, 0 = Off).
2. Custom network indicators must be turned on under Settings....Endpoints.....Advanced features.
3. Microsoft Defender Antivirus must be in active mode, not passive mode.
4. The indicator's scope should include correct device group.
5. Only single public IP addresses are supported. CIDR ranges and internal/private IPs aren't supported in IP indicators.
How we fixed it:
Since our traffic was inbound, the indicator was never going to stop it. We blocked it at the firewall level instead by [creating an inbound block rule for the IP in Windows Defender Firewall, deployed through Intune (Endpoint security > Firewall) / adding the IP to our perimeter firewall block list]. We kept the MDE indicator in place so any outbound connections to that IP are blocked as well.
We then confirmed it was working with this Advanced Hunting query:
DeviceNetworkEvents
| where Timestamp > ago(1d)
| where RemoteIP == "x.x.x.x"
| summarize Connections = count() by ActionType, DeviceName
After the firewall rule, the inbound accepted connections stopped showing up.
Hope this helps.
Hi Bezakheal,
Thank you for the info and for providing the idea to block the inbound connection.
I think there are two separate things worth checking here.
First, regarding propagation time: Microsoft currently documents that IP/URL indicator policies can take up to 48 hours to become effective, although they normally take effect in less than two hours. So waiting can be relevant, but I would not stop troubleshooting there.
The more interesting part is your InboundConnectionAccepted observation.
MDE IP and URL indicators are enforced through SmartScreen and Network Protection. Microsoft describes Network Protection as protection for outbound connections from the endpoint. It is not the equivalent of creating an inbound Windows Defender Firewall rule for a remote source IP.
So if this really is unsolicited inbound traffic from the IP towards the endpoint, I would not expect the MDE custom indicator to behave like an inbound firewall block. In that case I would use Windows Defender Firewall or an upstream network control to explicitly block the source.
If you are testing an outbound connection from the endpoint to the blocked IP, then I would check:
- Custom network indicators are enabled in Defender
- Network Protection is actually running in block mode
- Defender AV is active and the required cloud connectivity is available
- The indicator scope includes the affected device
Also be careful when validating the result only through DeviceNetworkEvents. Microsoft explicitly documents that a ConnectionSuccess event can still appear because the TCP handshake is logged before Network Protection makes its blocking decision.
So the first thing I would clarify is whether the traffic you are seeing is genuinely inbound or whether you are validating an outbound connection through the Defender network telemetry.
Hi Marcel,
Thank you for your comment.
These traffic were observed after 4 days of adding IP in the blocklist.
I was expecting whenever the we add ip in the block list , it will block both inbound and outbound traffic but as per your info it will only block the outbound traffic even network protection is enable. May be this is the reason why we are observing the inbound traffic.
IoC rules can take up to 24 hours to reflect. How long did you wait before testing again?
Hi Rahul,
Thank you..
The traffic were observed after 4 days of adding in the blocklist
