Coming up on my 1 year anniversary with @HuntressLabs ! Taking this opportunity to go over some things myself and the team have seen in intrusions and drop some tips on basic things you can do to make your network more immune to compromise. Let's start with initial access - We see so much VPN compromise, it's by far our number 1 initial access vector - yes 0days for VPN appliance are there, but most of the time the compromise is a result of good ol' fashion credential stuffing or brute force. - Some VPN appliances have decent log retention, others do not and it really sucks when only ~1 hour worth of logs are available - if you're standing up a SIEM or any kind of log collection effort in your org, make sure that devices which are externally exposed are sending their telemetry to the SIEM. If your VPN appliance has different logging settings, check them out and enable as needed - this telemetry is gold during intrusions. - In addition to VPN appliances, we see a lot of RDP / RDS machines get compromised - same story here, no fancy 0days, just weak credentials in use. In some cases, MFA is in use, but has either been bypassed for the compromised user or has "failed open" - if you use RDP for your org, make sure that MFA is enabled somehow on it, if it is enabled, test to see what happens when the process that handles MFA crashes or is turned off. Also, make sure you have good procedures in place for turning MFA bypasses back off when they're applied. - Remember to keep an eye on your web applications, deserialization attacks aren't super common, but happen fairly often. Turn on IIS logging and enable POST request logging if possible. Remember that a standard penetration test often does not deep dive into custom web applications, invest in a good Appsec focused test if you have a custom application exposed externally. Turning to lateral movement - Once inside networks, threat actors move very quickly and unfortunately do not run into a lot of resistance. We typically see multiple accounts compromised in rapid succession, suggesting weak or shared passwords in use. You have no idea how happy it makes me to see "LOGON_TYPE_NOT_GRANTED" in the logs - Yes I know segmenting your network is probably a pain, but its a very effective security control. - In most cases we see, RDP is used for lateral movement and unfortunately, there is often no controls to prevent users from RDP'ing into servers they have no business need to RDP into. Check your Active Directory permissions and see what users can RDP into your file servers and domain controllers, you might be very surprised by what you find! - Impacket & impacket-related tooling is very popular for lateral movement, if you are in charge of defending a network and have telemetry and a lab environment, try to use WMIExec etc for yourself and compare the telemetry you see versus normal activity, this is a great way to build high-fidelity alerts. Aside from that, remove local admin where possible. Local admin rights enable credential access and lateral movement avenues that would be shut right down were a non-admin account in use. Looking at Execution / Impact - Do threat actors use fancy 0days ? Yes of course, but in the cases we work, we rarely see it. Most of the time, "just enough tradecraft" is employed, all a TA needs is FileZilla and 7Zip to ruin your day. - Tunneling tools like ngrok and plink are very popular, most often, these tools are being used to make RDP externally available to the TA - everyone loves a GUI I guess. How do adversaries get credentials ? - Registry credential dumping is extremely popular, same with LSASS credential dumping. Threat actors will also search local file systems and network shares for credentials and - guaranteed - will find them. By segmenting your network, limiting local admin access and hardening authentication silos within your AD environment ( things like a three-tiered admin model, or as close to it as you can get ) will limit the impact of credential theft drastically. - Brute forcing is old and boring I get it, but unfortunately it works, especially for less-monitored environments, some cases we've seen hundreds of thousands brute force attempts for hours before an account is successfully compromised. Don't sleep on brute forcing, ensure you have account lock out policies in place and some kind of monitoring for brute force attacks. Miscellaneous tidbits - Please, please, please - change your default Windows log sizes via GPO. By default, these log channels do not hold a lot of data, if a threat actor undertakes a brute force in the environment, security-relevant telemetry will be clobbered hampering any investigation efforts. - Have a standard naming convention for your organizations' workstations and servers, this makes it so much easier to orientate everything during an investigation and very often bubbles up malicious activity for workstations that don't fit the standard naming convention. - Have a plan in place in case of an incident, it's bound to happen and it's better to be prepared. What happens if certain hosts need to be offline, who do you call to get a potential insurance claim started? What is the threshold for a formal IR engagement - deciding all these things under pressure from an incident is not ideal. I think this post is long enough 😅 so I'll wrap it up 💙