Evidence formats

Linux log analysis: auth.log, journald and auditd

Copy the logs off the affected host and drop them into a case. NEMUQU reads sshd, sudo, su, account-management and cron messages as structured events, groups audit records into the commands and file writes they describe, and runs its Linux host compromise pack. Each case gets a timeline, findings that cite the exact records behind them, a list of what the evidence cannot establish, and hunts compiled to Defender KQL, Sentinel KQL, Splunk SPL, Elastic ES|QL and Sigma for the tools you already run.

On this page

What you can upload

  • auth.log (Debian, Ubuntu) and secure (RHEL, Fedora), with traditional or RFC 3339 timestamps, and RFC 5424 syslog
  • systemd journal exports from journalctl -o json
  • auditd logs: raw /var/log/audit/audit.log, including the enriched format, and ausearch -i output

How to export it

  1. Copy /var/log/auth.log (Debian, Ubuntu) or /var/log/secure (RHEL, Fedora) as it is. Decompress rotated .gz files first: archives are not extracted.
  2. For the systemd journal, export JSON with journalctl -o json, for example journalctl -o json --since "2026-10-01" > journal.json. Other output modes are read as plain text.
  3. For auditd, copy /var/log/audit/audit.log, or save the output of ausearch -i. The raw file keeps exact UTC times; ausearch -i prints local time without an offset.

What NEMUQU checks

  • Repeated SSH failures from one address followed by a successful sign-in from it, across every account name tried
  • A download piped straight into a shell, such as curl or wget into sh or bash
  • New local accounts, with user ID 0 called out, and additions to sudo, wheel, docker and other root-equivalent groups
  • Changes to sudoers and to SSH authorized_keys files
  • Persistence through crontabs, cron files, systemd units and timers, and boot scripts
  • Shell history or system logs cleared, audit rules deleted or auditd stopped
  • sudo refusing an account that is not allowed to use it
  • The account compromise checks, run over the same sign-ins

Every finding cites the records behind it and states what it does not establish. Statistical signals are reported as rarity within your upload and never become findings. ATT&CK mappings describe what a behavior resembles, not proof that an adversary was present.

What it does not do

  • auth.log records sudo commands, not commands typed in a shell. Those appear only where auditd execve rules or an EDR recorded them
  • The traditional syslog timestamp has no year, so those times are marked low confidence. ausearch -i prints local time with no offset, so its times are low confidence too; raw audit.log keeps exact UTC
  • The logs name files, not their contents: findings say which key, unit, crontab or script to read on the host
  • No memory, disk image, rootkit or container-runtime analysis

Try it

Browse the synthetic demo cases to see a finished investigation without an account. When you are ready, create an account and compare plans.

Other evidence formats