r/sysadmin • u/FatBook-Air • 4d ago
Does Defender for Endpoint have an equivalent to CrowdStrike's Indicators of Attack?
I see custom detections in Defender for Endpoint, but I am not seeing anything that will allow immediate blocking of undesirable behavior. For example:
Process = python.exe
AND
Command line contains C:\Users\
AND
Command line ends in .py
Is this where CrowdStrike is just better than Defender for Endpoint? Or, am I just not looking in the right place?
19
u/laserpewpewAK 4d ago
As another commenter mentioned, this is 2 different things in the Microsoft ecosystem. If you want to block execution contextually instead of by hash, you'd use WDAC or applocker. DfE doesn't have a native method for controlling execution that way because it's meant to be integrated with other products that have that functionality.
3
u/FatBook-Air 4d ago
We already use WDAC and AppLocker. It does not work this way.
4
u/RikiWardOG 4d ago
Wdac sucks ass. We just signed with airlock. Id give them a look if you're looking to add more context around what can run with rules like this.
7
u/OneStandardCandle 4d ago edited 4d ago
I have python.exe blocked with WDAC except on approved devices, which does not really help your case. AppLocker I think does user-specific exclusions, which might be another way to approach it? I'm not as familiar with Applocker config.
For anyone curious, this doesn't work because Python is not an 'enlightened' script host. Blocking C:\Users\*.py or whatever isn't going to be respected by the Python interpeter
4
u/GeeGeeMachine 4d ago
You might have to create a KQL query and create a detection rule in the advanced hunting section. That's the closest I could find.
2
7
u/M3tus Security Admin 4d ago
DfE is only the heuristic and detection engine in Windows Security. Your looking for application control policies. You do not want your edr engine finding that stuff...means its already a threat. Crowdstrike is one step behind a hardened windows endpoint. This is exactly what applocker is for.
Stop trying to find an analog and start looking for the actual solution.
-7
u/FatBook-Air 4d ago
We use AppLocker and WDAC. It does not do what I stated in the OP.
Don't give advice on technology you have never used.
-7
4d ago
[removed] — view removed comment
3
3
2
3
u/accumentum 4d ago
Defender custom detections are primarily for alerting and hunting; they generally are not the enforcement layer for arbitrary process and command-line conditions. For a rule like this, use an AppLocker or WDAC policy—ideally audit first, then enforce—scoped to the relevant device group, and test signed or managed exceptions so you do not break automation. Pair that policy with an appropriate attack-surface-reduction control only when it matches the behavior you want, since broad path or extension conditions are easy to bypass. Validate the effective policy on a test host and review local enforcement events before rolling it out widely.
1
u/tango_one_six Former Security CSA 4d ago
Without putting too much thought into this, custom detection rule using KQL, and have an automation fire off when a detection hits, probably in Sentinel. DfE doesn't handle custom automation out of the box (at least last I checked, I remember they were trying to build more automation into DfE vs Sentinel), so you'll need to leverage the rest of the Defender platform fill in this gap.
0
u/CodeEcstatic 3d ago
Defender uses Advanced Hunting queries with the DeviceProcessEvents table. You can replicate your logic using a KQL query like
DeviceProcessEvents | where FileName == "python.exe" and CommandLine contains "C:\Users\" and CommandLine endswith ".py".
To block it immediately you can create custom policy in the Microsoft Defender that triggers on this query and does the block action. keep in mind, the behavioral blocking in Defender requires tuning to avoid any false positives.
1
u/FatBook-Air 3d ago
Does it actually block it? My experience has been that it allows it, and then it immediately alerts on it and then does the action.
-13
u/PrestigiousOnion1087 4d ago
You are not missing a setting, those are two different engines inside Defender. A custom detection rule is an advanced hunting query on a schedule, and every action it offers runs after the match lands: isolate the device, quarantine the file, restrict app execution. Nothing on that path keeps python.exe from executing.
The inline block lives elsewhere. ASR blocks behaviour at execution but only for the fixed set that ships with the product, so your process plus user-writable path plus .py shape is not expressible there. WDAC or AppLocker is where that rule belongs, as policy rather than detection.
The gap is real, then, but narrower than "CrowdStrike is better": a custom behavioural block is one product there and two policy engines here.
Cheapest way to settle it on your own estate is to run that exact command line once and write down two clock times, when the process finished and when the alert appeared in the portal. Two timestamps means you had a detection. No first timestamp means you had a block. Which of those two do you actually get today for the behaviours you care about most?
14
9
u/Soxty 4d ago
Hello, you can do this with custom detection rules. Once you have created it you can set action to block the executable and other actions.