Today, Facebook announced the successful completion of our work: osquery for Windows.

“Today, we’re excited to announce the availability of an osquery developer kit for Windows so security teams can build customized solutions for their Windows networks… This port of osquery to Windows gives you the ability to unify endpoint defense and participate in an active open source community ready to share experiences and stories.”
— Introducing osquery for Windows

The Windows version of osquery can talk to existing osquery fleet management tools, such as doorman. osquery for Windows has full support for TLS remote endpoints and certificate validation, just like the Unix version. In this screenshot, we are using an existing doorman instance to find all running processes on a Windows machine.

How we ported osquery to Windows

This port presented several technical challenges, which we always enjoy. Some of the problems were general POSIX to Windows porting issues, while others were unique to osquery.

Let’s start with the obvious POSIX to Windows differences:

• Paths are different — no more ‘/’ as the path separator.
• There are no signals.
• Unix domain sockets are now named pipes.
• There’s no glob() — we had to approximate the functionality.
• Windows doesn’t fork() — the process model is fundamentally different. osquery forks worker processes. We worked around this by abstracting the worker process functionality.
• There’s no more simple integer uid or gid values — instead you have SIDs, ACLs and DACLs.
• And you can forget about the octal file permissions model — or use the approximation we created.

Then, the less-obvious problems: osquery is a daemon. In Windows, daemons are services, which expect a special interface and are launched by the service control manager. We added service functionality to osquery, and provided a script to register and remove the service. The parent-child process relationship is different — there is no getppid() equivalent, but osquery worker processes needed to know if their parent stopped working, or if a shutdown event was triggered in the parent process.

Deeper still, we found some unexpected challenges:

• Some code that builds on clang/gcc just won’t build on Visual Studio.
• Certain function attributes like __constructor__() have no supported Visual Studio equivalent. The functionality had to be re-created.
• Certain standard library functions have implementation defined behavior — for instance, fopen will open a directory for reading on Unix-based systems, but will fail on Windows.

Along the way, we also had to ensure that every library that osquery depends on worked on Windows, too. This required fixing some bugs and making substitutions, like using linenoise-ng instead of GNU readline. There were still additional complexities: the build system had to accommodate a new OS, use Windows libraries, paths, compiler options, appropriate C runtime, etc.

This was just the effort to get the osquery core running. The osquery tables – the code that retrieves information from the local machine – present their own unique challenges. For instance, the processes table needed to be re-implemented on Windows. This table retrieves information about processes currently running on the system. It is a requirement for the osquery daemon to function. To implement this table, we created a generic abstraction to the Windows Management Instrumentation (WMI), and used existing WMI functionality to retrieve the list of running processes. We hope that this approach will support the creation of many more tables to tap into the vast wealth of system instrumentation data that WMI offers.

osqueryi, the interactive osquery shell, also works on Windows. In this screenshot we are using osquery to query the list of running processes and the cryptographic hash of a file.

The port was worth the effort

Facebook sparked a lot of excitement when it released osquery in 2014.

The open source endpoint security tool allows an organization to treat its infrastructure as a database, turning operating system information into a format that can be queried using SQL-like statements. This functionality is invaluable for performing incident response, diagnosing systems operations problems, ensuring baseline security settings, and more.

It fundamentally changed security for environments running Linux distributions such as Ubuntu or CentOS, or for deployments of Mac OS X machines.

But if you were running a Windows environment, you were out of luck.

To gather similar information, you’d have to cobble together a manual solution, or pay for a commercial product, which would be expensive, force vendor reliance, and lock your organization into using a proprietary -and potentially buggy– agent. Since most of these services are cloud-based, you’d also risk exposing potentially sensitive data.

Today, that’s no longer the case.

Disruption for the endpoint security market?

Because osquery runs on all three major desktop/server platforms, the open-source community can supplant proprietary, closed, commercial security and monitoring systems with free, community-supported alternatives. (Just one more example of how Facebook’s security team accounts for broader business challenges.)

We’re excited about the potential:

• Since osquery is cross platform, network administrators will be able to monitor complex operating system states across their entire infrastructure. For those already running an osquery deployment, they’ll be able to seamlessly integrate their Windows machines, allowing for far greater efficiency in their work.
• We envision startups launching without the need to develop agents that collect this rich set of data first, as Kolide.co has already done. We’re excited to see what’s built from here.
• More vulnerable organizations -groups that can’t afford the ‘Apple premium,’ or don’t use Linux- will be able to secure their systems to a degree that wasn’t possible before.

Get started with osquery

osquery for Windows is only distributed via source code. You must build your own osquery. To do that, please see the official Building osquery for Windows guide.

Currently osquery will only build on Windows 10, the sole prerequisite. All other dependencies and build tools will be automatically installed as a part of the provisioning and building process.

There is an open issue to create an osquery chocolatey package, to allow for simple package management-style installation of osquery.

If you want our help modifying osquery’s code base for your organization, contact us.

Learn more about porting applications to Windows

We will be writing about the techniques we applied to port osquery to Windows soon. Follow us on Twitter and subscribe to our blog with your favorite RSS reader for more updates.