In Part 2 of this two-part series, our goal is to provide security practitioners with better visibility, knowledge, and capabilities relative to malicious persistence techniques that impact organizations around the world every day. In this post, we’ll explore two additional persistence techniques that are being used by attackers in the wild: Scheduled Tasks (T1053) and BITS Jobs (T1197).

Security teams must protect attack surfaces that are becoming bigger and more distributed due to the growth of remote work, cloud infrastructure, and other dynamics. These teams understand that meeting this challenge at scale requires the successful incorporation of the appropriate technology into their security operations program.

Last month, we hosted a webinar, Hunting for persistence using Elastic Security, where we examined some techniques that attackers use in the wild to maintain presence in their victim’s environment. In this two-part blog series, we’ll share the details of what was covered during our webinar with the goal of helping security practitioners improve their visibility of these offensive persistence techniques and help to undermine the efficacy of these attacks against their organization.

With the release of Elastic Security 7.6, we've announced our creation of a modern detection engine that provides SOC teams with a unified SIEM rule experience through Elastic SIEM detections. The detection engine draws from a purpose-built set of Elasticsearch analytics engines and runs on a new distributed execution platform in Kibana.

Hello, security enthusiasts! This is part seven (can you believe it?) of the Elastic SIEM for home and small business blog series. If you haven’t read the first six blogs in the series, you may want to before going any further. In the prerequisite blogs we created our Elasticsearch Service deployment (part 1), secured access to our cluster by restricting privileges for users and Beats (part 2), then we created an ingest pipeline for GeoIP data and reviewed our Beats configurations (part 3).

Given the complexity of large enterprise environments, coupled with the diversity of the vendor landscape, there is no single, agreed-upon “best” way to buy security. The battles continue between CAPEX or OPEX, net-30 or net-90, annual or multi-year, perpetual or subscription. One thing we do know, however, is that all too often the consumer pays for something he or she does not use.

This blog post is one in an occasional series about how we at Elastic embrace our own technology. The Elastic InfoSec team is responsible for securing Elastic and responding to threats. We use our products everywhere we can — and for more than just logs. By harnessing the power and breadth of capabilities of the Elastic Stack, we are working on tracking risk and performance metrics, threat intelligence, our control framework, and control conformance information within Elastic.

This is the third and final post of a three-part series on understanding kernel extension frameworks for Mac systems. In part 1, we reviewed the existing kernel extension frameworks and the information that these frameworks can provide. In part 2 we covered techniques that could be used in kernel to gather even more details on system events. In this post, we will go into the new EndpointSecurity and SystemExtensions frameworks.

For several months, the Intelligence & Analytics team at Elastic Security has tracked an ongoing adversary campaign appearing to target Ukranian government officials. Based on our monitoring, we believe Gamaredon Group, a suspected Russia-based threat group, is behind this campaign. Our observations suggest a significant overlap between tactics, techniques, and procedures (TTPs) included within this campaign and public reporting.

Hey, there. This is part six of the Elastic SIEM for home and small business blog series. If you haven’t read the first, second, and third blogs, you may want to before going any further. In the Getting started blog, we created our Elasticsearch Service deployment and started collecting data from one of our computers using Winlogbeat. In the Securing cluster access blog, we secured access to our cluster by restricting privileges for users and Beats.