Recently @NinjaParanoid and I had some short discussion about #EDR bypasses.
In this thread🧵 I'd like to share my view on EDR bypasses and it's various types from both
offensive & defences sides.
There are three types of EDR bypasses:
1. Technical capabilities bypass
Everything is simple here. EDR isn't capable to collect some telemetry. This is a technical problem, the lack of the feature. Look at dark blue stripes below from @MITREattack evaluation:
If I remember correctly, @jaredcatkinson called this type of bypass as "pure EDR bypass", I like this name too😉
EDR development team should remove such telemetry collection ability gaps. In some cases it's quite easy, in some - very difficult.
Compare adding a new ETW provider support against getting RPC telemetry, only a few EDRs in the world have the latter.
From offensive side, thanks to MITRE evaluations this type of bypass is kind of "on surface" for every well-known EDR.
2. EDR configuration bypass
As I recently mentioned - nobody needs EDR which affects their PCs, critical servers and finally business.
If EDR is able to collect all telemetry it doesn't necessary mean it does this🤔
That's why EDRs have various aggression level settings and the most aggressive ones are rarely turned on in a real environments.
From defender's perspective EDR config tuning is a constant trade off between performance/EPS & detection capabilities⚖️
From offensive side, EDR's config is hidden this time, as well as bypass vector, but it doesn't mean it's can't be discovered.
3. EDR detection logic bypass
Even with the right collected telemetry every #EDR may be bypassed using particular TTP. But it's very difficult for an attacker to remain undetected during the whole Kill Chain path.
From defensive side, this bypass type is quite easily to eliminate if your hunters team is working hard & have enough time for detection rules development and tuning.
As an evidence of this, we can see how some initially "weak" EDRs demonstrated impressive results during the last @MITREengenuity evaluation. Most likely it means, that EDR already had a good technical collection capabilities and their hunters team have done a great work😤👏
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Our 6th detection & IR quiz is finished, I'm starting posting the answers. I'd like to thank @DebugPrivilege@oskulkin@arekfurt@atn1ght1@PhilipARobson for their great answers👏
If you want to participate go straight to the tweet below:
0. The attack was rapid & merciless. The attacker compromised Exchange server via RCE or valid account (we couldn't find the exact initial vector). After that, the attacker dropped China Chopper web shell and established persistence with SYSTEM privs on the server.
0. h64.exe is a highly customised undetectable by AV Mimikatz which was dropped to Recycle bin (hide artefacts). m.berger is (neglecting security measures) org DA and his credentials were dumped from LSASS memory using h64.exe
Sure) First of all you should know very well which telemetry is available and provided by your OS/detection tools. If it's Windows, you must know which events are on the table and how to enable them using audit policies. (1)
2. If it's EDR you should know how it works and where it gets telemetry. Which kernel callbacks exist, useful ETW providers, minifilter driver capabilities. Learn the structures and fields you get from these sources, analyse them, think how this info may be useful for you.
3. The same approach for Linux. Auditd/Auditbeat/OS Query - learn these tools, telemetry they provide, setup your own mini lab, play with configs, collect events, look at the fields - which of them might be useful for detection?
Thanks to everyone for participating in the 5th detection Quiz!
I'd like to mention @Cyb3rSn0rlax@Antonlovesdnb and @atn1ght1 - great answers folks👏
I'm starting posting answers. If you want to participate, don't look at the answers and go straight to the tweet below:
1. Looking at the events sequence we see that "Medium" IL Powershell.exe spawns "Medium" IL Wusa.exe, then we see consent.exe and "High" IL Wusa start. Finally the most strange event appears - "Medium" powershell starts "High" cmd.exe🤔 What's happening here?
I've recently consulted one company about #NTLM-family protocols. They had various monitoring & hardening questions.
So, I decided to post some of their questions with the answers: 1. LM protocol is old and weak - how can we monitor its usage?
1. In general, you can monitor it using "Package Name" field of 4624/4625 events. But, keep in mind that LM is disabled by default starting with Win7/WS2008R2.
So, if you still have some old machines using it, LM is definitely not the biggest problem for you😵
2. Can we block NTLM protocols on our Firewall?
No. NTLM-family don't have default transport protocol, so there is no default associated ports with these protocols. Most common transports are SMB, HTTP and SMTP.
Other mechanisms exist for disabling them, see below.
I see the Quiz is not easy for many, so let's look at particular events together and learn a little bit.
Let's try to think like an analysts! 1. "Medim" IL powershell.exe spawns "Medium" IL Wusa.exe, UAC is enabled on machine, so this is an expected behaviour:
1.1 As we know, Wusa.exe has "autoElevate" = TRUE in its manifest, that means it will be automatically elevated by UAC without consent prompt (except "AlwaysNotify" mode). So, svchost.exe spawns consent.exe:
1.2 The next part is very interesting. You say - powershell.exe spawns "High" IL wusa.exe. Of course it's not! The real parent of wusa is "System" IL svchost.exe which then replaces the parent process with powershell.exe (as initiator). Look at the event below:
Detection Quiz!💡
Look at the process creation events depicted below:
1. Can you recognise the technique?
2. Map it to the @MITREattack
3. Which tool was most likely used?
4. Detection ideas?