Lab 10 — Test your detections: run Atomic Red Team and catch it in Wazuh

In a Kali terminal, check the two services and the log file:

systemctl is-active wazuh-agent rsyslog
sudo test -r /var/log/auth.log && echo 'auth.log is readable'
sudo grep -F '/var/log/auth.log' /var/ossec/etc/ossec.conf

Expect two active lines, the readable-file message, and an auth.log entry in the agent configuration. An entry alone does not prove it is enabled: it must be inside an active <localfile> block using syslog. If these checks fail, fix collection using Lab 08 before continuing.

In Wazuh → Threat Hunting, choose Last 15 minutes, refresh, and filter to your VM:

agent.name:"kali-lab"

Confirm the agent is Active and note the most recent event time. Leave this view open. The Linux hostname can differ from the Wazuh agent name.

Why check first. A missed alert is useful evidence only when you know the test ran and the log could reach the manager.

Open the fixed revision of the official test definition. Use its first test, Create a user account on a Linux system, under T1136.001. Its GUID is 40d8eabd-e394-46f6-8785-b9bfa1d011d2. The link fixes the source version so a future repository update cannot silently change this exercise.

Read the executor and cleanup_command sections. The executor is Bash and requires elevated rights. We will supply sg-atomic10 for the username input.

The command uses -M to avoid creating a home directory, -N to avoid a new same-name group, and -r to create a system account. It sets a Bash shell and an account comment. It supplies no password; standard useradd defaults leave password authentication locked. This is still a real account, so cleanup matters.

We use Atomic Red Team's documented manual execution method: run the selected test's command with its input filled in. This test needs no downloaded payload or execution framework. The command in step 03 preserves its flags; sudo supplies the required privilege.

Write the prediction. “Creating sg-atomic10 on my monitored Kali VM will leave a useradd event in auth.log and a new-account alert in Wazuh.” Save the GUID and source link beside it.

In Kali, record the time and hostname, then run this guarded block. It refuses to create the account if that name already exists:

date -Is
hostname
if getent passwd sg-atomic10 >/dev/null; then
  echo 'STOP: sg-atomic10 already exists. Do not alter or delete it.'
else
  sudo useradd -M -N -r -s /bin/bash -c evil_account sg-atomic10 &&
  getent passwd sg-atomic10
fi

A successful run prints an account record beginning sg-atomic10:. The numeric IDs depend on your VM. If you see STOP or a useradd error, the test did not create a new account: resolve that before claiming a result. Do not delete an account that predated this lab.

Record the printed timestamp as Run 1. Keep this account unused: do not set a password, add privileges, or log in as it.

What you just tested. Local account creation is ATT&CK sub-technique T1136.001. You already had sudo rights; this command does not demonstrate an initial compromise or privilege escalation.

Look for the account-creation event in Kali's auth.log:

sudo grep -E 'useradd\[[0-9]+\]: new user: name=sg-atomic10,' /var/log/auth.log | tail -n 5

Find the line containing useradd[ and new user: name=sg-atomic10,, with a timestamp matching Run 1. Save the complete line in your notes. A sudo line that merely mentions the command is not the same evidence.

If nothing appears, check the journal as well:

sudo journalctl -t useradd --since "15 minutes ago" --no-pager

If the journal has the creation event but auth.log does not, investigate rsyslog and the Lab 08 file-collection setup. If neither has it, check the command result and time window. Do not manufacture a log line to make the exercise pass.

Follow the evidence. The account record proves a state change. The useradd line proves a local log was written. The next step tests whether Wazuh received and classified it.

Return to Threat Hunting, refresh, and use this search. Widen the time picker to Last 1 hour if the lab has taken longer:

agent.name:"kali-lab" AND full_log:"sg-atomic10"

Expand a result and inspect full_log. Choose the useradd new-user event from Run 1. A sudo alert mentioning the username proves only that the command was logged. Record these fields from the creation alert:

• timestamp and agent.name — does the event belong to this run and this VM?
• rule.id, rule.level and rule.description — which detection classified it?
• full_log — does it contain the same account and creation event you saved on Kali?
• rule.mitre.id — which ATT&CK identifier did your ruleset attach?

The upstream syslog rules provide a useful reference: rule 5902, level 8, with the description “New user added to the system.” Its mapping is the parent technique T1136; the Atomic test is the more specific T1136.001. Record what your installed ruleset actually shows. Searching only for the sub-technique can hide a valid parent-mapped alert.

Once you have confirmed that your creation alert uses 5902, narrow the search:

agent.name:"kali-lab" AND rule.id:5902 AND full_log:"sg-atomic10"

What a pass means. Wazuh detected this account-creation event through this log source. An alert does not mean the action was blocked, and one passing test does not prove coverage of every way to create an account.

After saving the evidence — or before leaving a failed attempt — remove only the account you created in step 03. In Kali, run the test's cleanup command with the same input:

sudo userdel sg-atomic10

Now check that the account is gone:

if getent passwd sg-atomic10; then
  echo 'STOP: the account still exists; investigate cleanup.'
else
  echo 'Clean: sg-atomic10 is absent.'
fi

Expect the Clean message. If userdel reports an error, investigate it; do not force deletion or kill unrelated processes. This test created no home directory or same-name group, so its cleanup does not need recursive file deletion.

Refresh the broader username search from step 05. A deletion event may appear under rule 5903 (level 3 in the upstream rules), depending on your alert threshold. Keep the original creation evidence. Removing the account does not remove its historical alerts.

Cleanup is part of the test. A working detection exercise ends with a checked system state, even if its alert search failed.

With the account confirmed absent, repeat steps 03–06 once. Record a fresh timestamp as Run 2 and find its new creation event. Compare timestamps and event details so an old Run 1 alert cannot count as your second success. Finish with the account absent again.

Copy this record into your lab notes and fill it with your own observations:

Test: T1136.001 | GUID 40d8eabd-e394-46f6-8785-b9bfa1d011d2
Method/input: manual Bash executor | username=sg-atomic10
Source revision: e2115e52c0fb1e67c4f23c73eeb83cb022805dc4
Environment: Kali version / Wazuh manager and agent versions
Run 1: start time + timezone / hostname / agent name
Run 1 evidence: source log / alert timestamp / rule ID / level / ATT&CK ID
Run 2: start time + timezone / new source log / new alert timestamp
Cleanup: account absent after each run? yes/no
Result: detected / local log only / execution failed
Interpretation: what this proves, and what remains untested

Take a screenshot of the expanded Wazuh creation alert with its host, time, rule and full_log visible. Pair it with the source log and cleanup check. If the two runs disagree, document the difference and work through the checks below.

Why repeat. Repeatable evidence gives you a baseline you can compare after an agent upgrade, a collection change or a ruleset change.