Inspired by a SANS poster, I wanted to look at a couple of security solutions and see if their logs provided any key insights an analyst could leverage.
The scenario : if given only product-relevant raw data & logs, would X security solution have data on the host that provides any security value and help with our investigation.
This is a specific use case I know. But it's something I find myself needing every day at work
Our conversation is about a singular machine, and the transparency, ease-of-access, and security-value of the logs and raw data of various security solutions. We’ll be staying in Windows world for this particular thread.
In our scenario, we have no GUI access to the AV
We're not talking about the effectiveness of a solution.
We're only taking a look at one very specific thing about it: the security value of raw data it leaves in some kind of retrievable file
Lots of gaps in the data collected, so please contribute and correct where necessary.
Defender is a good standard. It tells you the trigger time, offending file, the parent process, and snitches on the user account responsible.
The categorisation near the top is hit and miss though. And good lord AMSI alerts are useless. TELL ME the PowerShell that was malicious?! Don’t make me go and pull the PwSh Op log?!
For cyber security investigations, internal silos will make or break your efforts 🧱🧱🧱
I'll show you the power from a LACK of siloing, with a piping hot, fresh @HuntressLabs case @xorJosh and I worked
🧵🧶
What are 'silos'.
@keydet89 educated me on the industry problem where departments cannot easily share findings; a threat intel department doesn't have a way to share findings with DFIR department, for example.
IMO, Silos occur when data & people cannot be circulated easily
We aren't perfect by any means at @HuntressLabs, but it's a testament to our founders, engineers, devs (etc) that our infrastructure sets us up for success.
It's difficult for analysts NOT to share reports and data by default; our infrastructure & culture doesn't foster silos
I wanted to share some findings about RDP, Network Layer Authentication, LogonTypes and brute forcing 🔭
Recently, we perused some EventID 4625s (login failures) originating from public IPv4s brute forcing...
🧵
I kept finding LogonType 3s (network)
However only RDP was externally exposed on the machine, which usually records LogonType 10....
When this has happened before, I usually just assume its Windows jank and continue with my investigation 🤷♂️
But this time, I wanted to know WHY
The wise @DaveKleinatland suggested Network Layer Authentication (NLA) would explain this:
"
NLA takes place before the session is started... without NLA things can be exposed before any sort of authentication.... like domain name, usernames, last logged on user, etc
"
- Dave 🧙♂️
In a recent intrusion, we identified a threat actor had compromised the Windows login process, and siphoned cleartext credentials - using a technique known as NPPSPY
@0gtweet’s NPPSPY was fascinating to dissect and remediate.
Our article couldn’t show what this cleartext credential gathering looked like on the compromised machine, but we recreated the electrifying end product
IOCs and Behavior
- T1003
- Values under HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order
◦For our case: logincontroll
- Unexplained entries in HKLM\SYSTEM\CurrentControlSet\Services\<here>\NetworkProvider
◦For our case: logincontroll
Let's chat about how to unravel Cobalt Strike and deny the adversary further access
As ALWAYS, I am showing you data so fresh out the kitchen it hasn't even been cleared by ThreatOps Director @MaxRogers5 👀🧑🍳 🧵
Cobalt Strike can often trigger AMSI alerts in Defender. The frustrating thing about AMSI alerts is that they don't tell you what the offending activity WAS.
The alert here was PowerShell based....so let's dig a lil deeper
Go collect C:\System32\winevt\Logs\Microsoft-Windows-PowerShell%4Operational.evtx , and go get my favourite tool - Chainsaw.