Be it for macOS or my dog eating out of the trash, there is no such thing as a bullet-proof security policy. It’s all about creating a threshold of standards- something to work off of while simultaneously reducing overall risk (you know, like storing your trash can on the counter, for example).

In this blog post I’ll cover osquery’s ability to provide performant behavior and its capabilities to excel at enterprise grade requirements. Many observations covered in this blog will highlight various capabilities of osquery that should aid in your journey toward an enterprise-grade osquery deployment.

Osquery has become a popular source of instrumentation for a wide variety of use cases. On github security showcase, it is currently among the top most popular open source security projects. Given the popularity, a recurring question is what use cases can one address with osquery in an enterprise environment?

As a part of a pretty crazy week (Microsoft/RDS, Apple/Mojave/High Sierra, Adobe Acrobat/ Flash Player) when it comes to security updates, some new speculative execution vulnerabilities were disclosed and fixed.

This previous blog post explored ways to use osquery for macOS malware analysis. Using the same methodology introduced there, we analyzed five additional macOS malware variants and recorded their behavior to understand the techniques they used. Below, you’ll find the techniques used by Calisto, Dummy, HiddenLotus, LamePyre and WireLurker. Read on to explore how to translate the techniques used by these malware into queries you can run to hunt for the active presence or historical artifacts using osquery.

Progress in open source projects thrives on the sharing of information. Yet even with the best of intentions, much of the learning can still be considered tribal knowledge, traded between small groups of closely connected individuals. While, the osquery project certainly isn’t immune to this, the community has absolutely benefited from a passionate and growing base of users, developers, contributors and tinkerers that are dedicated to documenting and sharing what they’ve learned.

Osquery, at its most basic level, is an operating system instrumentation framework that exposes the OS as a SQL database. SQL queries can be run to view information about the systems similar to any SQL database, providing a unified cross platform framework (i.e. endpoints running on multiple operating systems can be queried using the industry standard database language: SQL. This structured approach for collecting and accessing data introduces great flexibility, making it useful for multiple purposes. For example, queries can be constructed to audit infrastructure for compliance, vulnerabilities, malware analysis and intrusion detection, etc. Data collected by osquery can be useful to anybody from IT support teams to CSIRTs. However, in this blog post we’ll narrow our focus and explore how to use osquery specifically for macOS malware analysis (though the methodologies discussed are the same for Windows and Linux operating systems).

You may have heard about “Dirty Sock”, a recently discovered vulnerability targeting snapd sockets, playing on the name of a previous vulnerability called “Dirty Cow”. Snapd allows for the execution of packaged snaps, which are a mechanism to distribute and update applications in a standard format.

The Windows registry is full of information, and with the proper tools, can be a gold mine for attackers and defenders alike. Attackers look to find specific configurations, credentials, or any information that can help them further attack systems, while defenders can use the registry to ensure that settings are configured as they are expected to. This is something that is not always easy to do with standard tools in Windows, or with the right level of performance. Fortunately, osquery solves that for us.

2018: The year of speculative execution bugs

A year ago, in January 2018, three hardware vulnerabilities known as Meltdown, Spectre Variant 1, and Spectre Variant 2 were disclosed to the public.

Although disclosure was supposed to occur on January 9, news outlets found updates in the Linux Kernel and broke word early on January 3, kicking off the year with a pretty big headache for IT and security teams across the globe.