I expected some internal test data, or even results from previously identified activity.
So you can imagine my surprise when I saw results that were from a handful of hours ago
Evidence of lateral movement?! In front of my very eyes!!
So I honed in the host machine in question. The aim here was to contextualise the activity, and identify what other facets of the adversarial campaign were visible
But the results were complicated....
@HuskyHacksMK later commented on this with the exact mix of emotions I was feeling.
An executable - nddc.exe - was directly associated with this lateral movement-like activity.
Instead of MORE malicious evidence, the existing 'malicious' evidence was brought into question.
For comparison, I have included what Impacket's WMIExec would look like in the SIEM
My next step was to go the host itself. Initially, I was going to reverse engineer the executable under the assumption it was malicious.
But something felt 'off' about treating it like malware.
It seemed too legit in it's directory placement
Some like to turn to Google straight away. This is a valid approach
Before I go down search tunnels, I let the 'data speak'. This means I do not impose a hypothesis or conclusion but let the evidence guide me.
Google will add context, but it will not let YOUR data speak. 📢
Instead, I leveraged global prevalence as @MaxRogers5 would advise.
If a significant number of machines display the same behaviour, this is an informative finding.
And we got back fascinating results: other machines in other domains are also displaying this behaviour, uniformly
Drilling down further on a machine, we can see that this weird NDDC.exe activity also has a ‘beaconing’ pattern, which suggests it is scheduled with precise regularity
Once I've saturated the raw data and it can't tell me any more, I turn to google to fill in the gaps.
My initial searches were just to ascertain what NDDC is.
I find out its Network Detective Data Collector, a Kaseya-related tool.
This by itself doesn't absolve the activity.
Reading the docs justifies why Network Detective (nddc.exe) behaves this way with SMB shares during a network audit.
And the end result of our investigation was to contribute to an awesome, growing repo of false positive behaviours.
The efforts of our investigation on Network Detective mean the infosec community may not have to go to these lengths next time.
Instead, they can benefit from our findings! 🤝
This is what it's all about: contributing back to the community that we all borrow tools and tips from
In conclusion, we pulled on a suspicious thread that we ultimately unraveled as legitimate (but weird), and shared our findings with our peers via WTFbins.
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.