As promised, we wanted to dedicate a blog to detections and findings from the network operations center (NOC) at Black Hat Asia 2023 as a follow up to our Lessons Learned blog. Some of these discoveries may not surprise the seasoned analyst or senior threat hunter – but will hopefully provide a little entertainment, because the more things change, the more they stay the same.
You’re probably tired of hearing me say how exciting the Black Hat network can be, but I feel the need to emphasize the value in testing detections, integrations, and refining our hunting methodology. Our Corelight Sensor allowed us to see all traffic traveling North/South and East/West communications attempts, which the Palo Alto firewall prevented with great success. We had an optimal vantage point to review the metadata generated from the copious network traffic.
When hunting for threats, there still appears to be a certain mysticism around how to start, what to look for, or when a particular event should be investigated further. And many vendors would have you believe threat hunting begins from an initial indicator only provided by their specific intel, detection, or security platform.
For this post, let's agree on David Bianco's definition: "Threat hunting is the name for any manual or machine-assisted process for finding security incidents that your automated detection systems missed." Over the years, there have been several attempts to establish an industry-standard framework for threat hunting, and each has its merit.
The most recent and exciting hunting framework I know of is Splunk's "Prepare, Execute, and Act with Knowledge," or PEAK Framework, written by Mr. Bianco and others on Splunk's SURGe Security Research Team. Following the three PEAK hunting types outlined, the approach that served us best is categorized as "Hypothesis-Driven Hunting" since "Baseline Hunting" (or searching for potentially malicious deviations after establishing 'normal behavior') on the Black Hat network is quite nearly impossible. We were investigating the network logs looking for appealing items in cleartext communications, large file transfers going either direction, interesting inferences from standard Corelight packages.
By approaching the data with stimulating questions and being able to bounce ideas off of each other in an open fashion, we were able to turn those ideas into queries, collect the data retrieved, analyze the information to determine potential value, and continue to refine those queries for specific information, further improving our hunt.
I'll spare you the details on the iterations we went through, but here small list of some of our intriguing findings from the event:
Of these findings, I'll cover the details on two of my favorite (and least incriminating) below.
We noticed a few specific alerts related to a single host on the wireless network, which piqued our interest. While some of the alert signatures in the screenshot below could be benign if triggered independently, this combination of alerts, including "POSTs with Windows Folder references." This alert information relates to the sensor identifying folder references from the Windows operating system being communicated over the network via HTTP POST methods, and is normally related to host enumeration activities occurring on a compromised asset.
I can't blame you if your eye quickly identifies the URI in the screenshot below as a potential description for what could be a managed security service provider's (MSSP's) EDR offering. I'm not completely positive of this, but when the words "edr", "telemetry", and "CustomerId" appear in sequence, it raises suspicion. While investigating the metadata in the HTTP logs between the endpoint in question and two upstream servers further, we did notice 'CommandLine' strings in the POST body, including what appeared to be the output of a Windows tasklist (similar to wmic process get processid,commandline).
That hypothesis was verified by extracting the PCAP from the streams and inspecting the plaintext output from the network traffic. When all else fails, one may be able to rely on their EDR agent to give full host details to the rest of the network, with no compromise required.
Later, while hunting for traditional protocols being leveraged over non-standard ports, we came across a few plaintext HTTP connections with a User-Agent of "MGUARD_APP_API". Having little to no experience with that User-Agent, we explored the additional details of the transactions, namely the POST body and URI. These details highlighted the username, device id, device authorization token, and latitude & longitude coordinates where the device was currently located.
Simply placing those coordinates into our favorite map platform revealed exactly what we expected … a very accurate user location inside the Black Hat conference area!
If you're wondering which vendor produces this application, the best we could identify regarding its origin is that it may relate to Phoenix's mGuard industrial VPN solution. We'd love to have the ability to collect additional traffic from whatever this application may be.
It goes without saying that network traffic collection is critical to maintaining the security and integrity of modern-day networks. Throughout this blog post, we delved into the significance of monitoring and exploring network traffic and using various techniques for detecting anomalies and potential threats. By leveraging our Open NDR Platform and incorporating traditional threat hunting techniques, we were able to gain valuable insights into traffic patterns and identify suspicious activities promptly.