The alert fires, it’s not the blatantly obvious true positive that has dumpster fire written all over it, but it’s not a clear false positive either. How do you make the jump from event to incident? It’s a question that many of SIEMs and tools have tried to answer by selling the Kool-Aid of secret sauce, machine learning, and buzz words all wrapped into expensive over-priced snake oil. The truth is, computers are complex and if it was really that easy, we’d all be out of a job. But, security tools miss, and analysts miss on events too. It’s hard making that jump and I think a large part of why is that analyst make decisions while missing context around the event.
A long time ago, in a galaxy before the year 2020, I took a job as a threat hunter at a financial services company. Most my experience had been on a government network in which you work in a very tight and narrow-minded, I mean narrow-scoped network. I was now seeing things I had never experienced before and really worked to make sense of it all. The perimeter was everywhere, office files were calling servers, and programs had been built on macros. I really struggled to understand security events and anomalous activity I would come across. Out of my struggle to help understand this network and put anomalous events in context, I came up with a saying, P2FUST. Standing for:
[P]rotocols/Network
[P]rocesses
[F]iles
[U]sers
[S]ystems
[T]imes
The basis of P2FUST is when you come across an event, you take the surrounding information to add context. This helps to decide if an event is a true positive or just a waste of time. Take for example, you have an alert fire for Excel launching a process and connecting to an FTP site. Here’s how P2FUST would play out when you fill in the blanks.
[P]rotocols/Network:FTP/DST 10.0.0.21 SRC: 10.0.2.250:21
[P]rocesses:excel.exe launched with command line, “c:\program files\microsoft office\root\office16\excel.exe” “c:\users\%user%\Downloads\invoice20200722.xlsx”
[F]iles:c:\users\%user%\Downloads\invoice20200722.xlsx
[U]sers:John Doe (Role: Accountant)
[S]ystems:WIN10-WORKSTATION
[T]imes:16:07UTC
Based on this information, I would be able to tell that a spreadsheet was downloaded and then launched by the user which started an FTP connection to an internal server. This extra context P2FUST gave me was enough information to be able to declare with confidence this was a false positive. Now, let’s say we had another similar alert for excel and the P2FUST looked like this:
[P]rotocols/Network:HTTP/DST 145.23.25.16 SRC: 10.0.2.250:21
[P]rocesses:excel.exe launched with command line, “c:\program files\microsoft office\root\office16\excel.exe” “c:\users\%user%\AppData\Local\Microsoft\Windows\NetCache\Content.Outlook\IH3E40\InvoicePayment.xlsx”
Child process – regsvr32.exe -s “c: \users\%user%\downloads\reputation.gpx”
[F]iles:C:\users\%user%\AppData\Local\Microsoft\Windows\NetCache\Content.Outlook\IH3E40\InvoicePayment.xlsx
c: \users\%user%\downloads\reputation.gpx
[U]sers:John Doe (Role: Accountant)
[S]ystems:WIN10-WORKSTATION
[T]imes:16:07UTC
In this case, you’d see the user opened a spreadsheet that most likely came from an email, given its file location. After opening the spreadsheet, it then launched a child process that used regsvr32 to load a file and the process also made a connection to the internet. Time to isolate the endpoint from network!
It’s this type of contextual information that can help make the critical decision when you may not have enough information from the alert. Every event has a story to tell, its on us to put the forensic facts together to piece that puzzle together. So, next time you come across that alert you’re not sure about, don’t blindly close it and hope for the best, gather your P2FUST and confidently action the alert.
