Free readiness test
Home / Tool labs / osquery

osquery hands-on lab Why is web-cache-01 at 100% CPU?

Ask your endpoints questions in SQL: processes, sockets, persistence and more.

EndpointIntermediatePro live lab6 objectives
root@web-cache-01:~#
$ SELECT pid, name, path, cmdline FROM processes WHERE on_disk = 0;
+------+-----------+---------------------------------------+-------------------------------------------------------+
| pid  | name      | path                                  | cmdline                                               |
+------+-----------+---------------------------------------+-------------------------------------------------------+
| 4123 | kworkerds | /tmp/.X11-unix/kworkerds (deleted)    | /tmp/.X11-unix/kworkerds -o pool.minexmr.example:3333 |
+------+-----------+---------------------------------------+-------------------------------------------------------+
A fake 'kernel worker' name, running from /tmp, binary deleted: a cryptominer hiding in plain sight.

What is osquery?

osquery exposes the operating system as a relational database. Security teams use it for threat hunting, incident response and compliance checks across fleets of Linux, Windows and macOS machines.

1 Tables

processes, listening_ports, crontab, users, authorized_keys and hundreds more.

2 SQL hunting

Joins and WHERE clauses find anomalies like deleted binaries still running.

3 Fleet scale

Managers like FleetDM run the same query across thousands of hosts.

The scenario: Why is web-cache-01 at 100% CPU?

Monitoring shows web-cache-01 (the Redis host from the Nmap lab) pinned at 100% CPU since Saturday. Start osqueryi and hunt for what's running, where it connects, and how it survives reboots.

Run this lab live in the platform

A simulated terminal with 6 objectives, hints and scenario questions. Included with NERvE Pro.

Open the osquery lab

Step-by-step: osquery commands used in this lab

1Find processes whose binary was deleted from disk

processes table, on_disk = 0

SELECT pid, name, path, cmdline FROM processes WHERE on_disk = 0;

2See where that process connects

process_open_sockets for that pid.

SELECT pid, remote_address, remote_port FROM process_open_sockets WHERE pid = 4123;

3Check scheduled tasks for persistence

The crontab table.

SELECT command, path FROM crontab;

4Look for unauthorised SSH keys

The authorized_keys table.

SELECT uid, key_file, comment FROM authorized_keys;

5Check for extra root-level accounts

users with uid 0

SELECT username, uid, shell FROM users WHERE uid = 0;

Key takeaways

Install osquery and practise for real

Download from osquery.io/downloads, then run: osqueryi

Try the same queries on your own laptop. You'll be surprised what's running. Only scan or test systems you own or are explicitly authorised to assess. Official site: osquery.io · Licence: Apache 2.0 / GPLv2.

Scenario questions

How did the attacker most likely get in?

Answer: The unauthenticated Redis server exposed on the network. Redis with no auth (found in the Nmap lab) lets attackers write cron jobs and SSH keys as the redis user.

Which findings are persistence mechanisms?

Answer: The cron job, the planted SSH key and the extra uid-0 account. Each lets the attacker come back even after the miner is killed.

Best remediation path?

Answer: Rebuild the host from a clean image, rotate credentials, and fix Redis exposure. With root-level persistence, rebuilding is safer than cleaning; then close the original hole.

More open-source tool labs

📡

Nmap

Discover hosts, open ports and services on networks you're authorised to assess.

🦈

Wireshark / tshark

See exactly what's crossing the wire and spot malware calling home.

🔭

Zeek

Turn raw traffic into rich, searchable logs for threat hunting.

🚨

Suricata

Detect attacks in network traffic with signatures, and write your own.

🛡️

Wazuh

An open-source SIEM and XDR: collect logs, detect attacks, respond automatically.

Σ

Sigma

Write a detection once, run it in any SIEM.