This weekend I spent some time with Okta’s Identity Engine product, learning about various ways to integrate it with Splunk and other external systems. When I got to Okta’s Event Hooks feature, I exclaimed “Aw, HECk!” (actually I said something a little stronger) and banged my head against my old copy of "Log4J 4 Me and U - A Complete Guide" for a few hours trying to get Event Hooks sending data properly into Splunk’s HTTP Event Collector, or HEC.

With the recent release of Sysmon (System Monitor) for Linux by Microsoft, new opportunities for monitoring, detection development, and defense are now possible. Sysmon for Windows is a very popular tool among detection developers and blue teamers as it provides extensive details from system activity and windows logs. Due to the extensive information this service/driver provides in Microsoft Windows, it is very useful when researching attacks and replicating malicious payloads on lab machines.

It would be hard to overstate the critical importance of security orchestration, automation and response (SOAR) capabilities for the effective mission success of security operations centers (SOC). Without a solid SOAR capability in place, an SOC will be easily overwhelmed with routine and repetitive tasks that in and of themselves could become a vulnerability.

Nowadays, malware used to have several stages before it fully compromised the targeted host or machine. The very well-known initial stager is the “phishing email” that contains a malicious macro code or malicious URL link that will download either the actual loader or the next stager to download the actual payload.

DevOps and Security. One encourages speed, agility, iterative learning, enabling technology to keep up with the pace of business. The other wants to keep you safe, slows things down, crosses all the T's and dots all the I's. They seem to be at odds with one another — but do they need to be? DevSecOps says no, that’s not the way it has to be.

The Splunk SURGe team loves to automate and simplify mundane tasks. Through rapid response blogs, we provide context and analysis on late breaking security events that affect everyone, not just Splunk customers. We are firm believers that through shared knowledge and experience we can help the masses better understand the threat landscape and how they can improve their security posture.

For more information on how to respond to the Log4j vulnerabilities using Splunk products, please see our Log4Shell response overview page. Like most cybersecurity teams, the Splunk Threat Research Team (STRT) has been heads-down attempting to understand, simulate, and detect the Log4j attack vector. This post shares detection opportunities STRT found in different stages of successful Log4Shell exploitation.

SOAR use cases come in all shapes and sizes, but almost all of them rely on threat intelligence to determine the risk posed by the various indicators in the event. Our two new community playbooks leverage Splunk Intelligence Management (previously TruSTAR) to gather intelligence about indicators and enable rapid manual response by an analyst within a single prompt.

The Splunk Threat Research Team recently updated the Active Directory Lateral Movement analytic story to help security operations center (SOC) analysts detect adversaries executing these techniques within Windows Active Directory (AD) environments. In this blog post, we’ll describe some of the detection opportunities available to cyber defenders and highlight detections from the analytic story.

Authors and Contributors: As always, security at Splunk is a family business. Credit to authors and collaborators: Ryan Kovar, Shannon Davis, Marcus LaFerrera, John Stoner, James Brodsky, Dave Herrald, Audra Streetman, Johan Bjerke, Drew Church, Mick Baccio, Lily Lee, Tamara Chacon, Ryan Becwar. If you want just to see how to find detections for the Log4j 2 RCE, skip down to the “detections” sections.