Build a fast, free, and effective Threat Hunting/Incident Response Console with Windows Event Forwarding and PowerBI: aka.ms/WEFFLES
This is a blog post about how to build the lightweight IR console I personally used during my time as a consultant, which a lot of companies still have in place and use. I'm posting it in the hopes of 'commoditizing' security efforts and making things easier for defenders.
Since people asked: I want you ALL to 'steal' this work. Please. Use it, modify it, build on it, help your pentest customers with it, put it in place everywhere you go.
Help people solve the basics so we can level the playing field and get to solving more advanced problems.
Real world use case for Event Logs and Windows Event Forwarding: finding RDP brute force attempts.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Popular attacker trick in corporate networks: change the WDigest UseLogonCredential registry key to 1.
Helpful if you want to transmute RDP brute forced local admin credential into domain credentials without risking a Mimikatz detection.
Why?
WDigest=plaintext creds in memory.
WDigest credentials being available in memory means attackers can use alternate sophisticated tools like taskmanager to get credentials versus bringing cred theft tools that AV might detect. WDigest is disables by default but can be enabled as admin without reboot (just lock.)
Monitoring changes to the WDigest registry key can give you a hint that someone might be interested in weakening your security posture or an attack might be starting.
Attackers don’t make assumptions that security policies are followed - they test them. There’s probably at least one person in your org that thinks Winter2019! is a strong password, and your service account passwords may not be as strong as you assume them to be.
Have a safe, legal, and documented way to verify your user accounts are following password best practices, Password Sprays are a common entry vector because human generated passwords that match ‘complexity’ tend to overlap. microsoft.com/en-us/microsof…
Service account passwords are excellent targets because of Kerberoasting and the availability of credentials via account sharing of use as services - and while these may be assumed to be strong passwords often times they are old and haven’t been rotated.
-Domain Admin accounts that do logon type 4 or 5 to workstations
-Accounts with weak Kerberos configs like DES encryption or no preauth
-GPO settings that allow unexpected admin actions like loading drivers
Why not check for these before they do?
Highly privileged accounts doing logon type 4 or 5 to workstations are useful to attackers because they leave credentials in memory and on disk - so an attacker can transmute one local administrator account into a domain wide compromise.
Weak Kerberos configurations in accounts are useful to attackers because they can be utilized to get offline password hashes to crack, or to modify Kerberos requests. Especially dangerous when combined with a weak/short password or no password required setting.
Windows Event ID 4624 displays a numerical value for the type of login that was attempted. These numbers are important from a forensic standpoint but also for understanding credential exposure and mitigating risks. Descriptions in replies.
Logon type 10: this is a typical RDP alert meaning that terminal services was engaged for the logon. 3rd party software like virtualization consoles and screen share can also generate it. Means credentials were in memory (lsass) and also hit cached credentials.
Logon type 2: interactive logon, typically associated with hands on keyboard. Credentials in memory and cached credentials. This event can also be generated using RunAs - which is why some normal admin behavior is risky.
-new ‘elite’ malware that most well configured/behavioral AV would have caught
-‘junk’ malware used for initial entry
-unpatched servers on the internet
Attackers don’t often encounter networks that require advanced techniques.
Every week we encounter at least one case of malware taking advantage of matching local admin passwords. You can fix that for free with aka.ms/laps
Every week we encounter at least one case of a domain admin level account being available on a web facing/easily compromised server because of doubt about where the account is used and what it might break to remove it. You can figure that out with aka.ms/weffles