Finding Initial Access

I recently ran across a comment from a SOC manager on social media that said, “Finding initial access is difficult.”

I thought about it for a moment, and had to ask, “why is that?”

For context, I transitioned from military service in 1997, and shortly thereafter, was running vulnerability assessment engagements, leading teams on-site to do the work, and completing reporting to the customer. I did “war dialing” (which was a lot of fun), and full-on, enterprise-wide data collection as part of overall vulnerability assessments. I then transitioned into DF/IR work, doing both consulting and FTE work, and I’ve also worked as a SOC analyst, and even run an internal, global SOC for a while. During my time in consulting, I’ve been certified to run PCI forensic investigations (did that for 3 yrs), I’ve done internal investigations in support of HR and legal counsel, and I’ve done enterprise/global “targeted threat actor” investigations. 

Something I’ve learned along the way is that finding initial access has very little to do with “zero day” exploits, or any of the other descriptions that include words like “sophisticated”. No, most often, determining initial access into an infrastructure has to do with the fact that we actively avoid doing basic IT hygiene, and we do very little to develop or implement lessons learned. 

Here’s an example of something I’d seen in the early 2000s, and I’ve seen as recently as the last month, even just last week…SQL injection. Someone receives an alert based on commands run via sqlservr.exe, and as part of the investigation, no initial access beyond the commands themselves is determined. A lot of this has to do with the MSSQL instance being installed in it’s default configuration, which means failed login attempts are recorded, but successful logins are not. As such, the successful connections to the MSSQL server are not available in the logs, and in most of the SQL injection cases I’ve seen, there aren’t many failed login attempts. The next step I generally take is to look and see if there’s a web server running, and sometimes that’s just looking to see if there’s a C:\inetpub folder. From there, it’s not hard to line up web server logs with the malicious activity, and sometimes you even see sqlmap scanning or some other indications of SQL injection vulnerability discovery. Sometimes, there are no logs available, because someone went in and disabled web server logging, via appcmd.exe.

Not only do we have to deal with the fact that default installations often not only mean easy access, but there are also vulnerabilities that don’t leave traces in log files when they’re successfully exploited. Now, reading CVE documentation doesn’t really get you there; sometimes, you have to try the exploit or PoC yourself, and take a thorough look at the exploited endpoint to locate indications of a successful exploit, or activity leading up to it. A good many SOC and DF analysts aren’t aware that there are other, ancillary locations where indications of an exploit may be found; sometimes, rather than, say, web server logs, we have to look in the Application Event Log, or some other log file. 

So, yes, finding initial access can be difficult, but it doesn’t have to be. Develop an asset inventory, perform attack surface reduction, take a multi-layered approach to protection and detection, and have a tested response plan available that makes sense for your organization. As part of attack surface reduction, don’t run default installations of the OS, and when you install an application, make sure that you’re aware of whatever else is installed along with it. 

All of this then leads to much more effective monitoring, because when an alert is generated, you have much greater confidence that it’s a true positive detection, how to respond, and then how to bake IR findings back into the process, increasing control efficacy.