Walkthrough

What a Blackglass scan looks like

A real Linux host can drift in dozens of ways an attacker would exploit. Below are eight scenarios Blackglass detects on the next scan — each with the exact severity, rationale, and remediation our customers see in the console. To watch the full loop (baseline → drift → detect → propose → human approval → verify) on your own systems, book a live demo.

Book a live demo →Start free trial

Scenario 1 · LISTENERS

high

Backdoor port listener on TCP 4444

An unexpected process is listening on TCP 4444. This port is commonly used by reverse shells and C2 frameworks such as Metasploit. It was not present in the host's baseline.

Suggested remediation (3) ▾

→Identify which service is listening on the suspicious port using your normal host-inspection workflow.
→Stop the listener and remove the associated programme or installer after change approval.
→Look for scheduled jobs or services that would bring the listener back after reboot.

Scenario 2 · SUDOERS

critical

NOPASSWD sudoers entry added

A sudoers rule now allows password-less privilege escalation. This was not present in the baseline. Any process running as this user can silently gain root.

Suggested remediation (3) ▾

→Edit sudo policy through your approved admin path and remove passwordless root escalation for untrusted accounts.
→Review supplemental sudo policy files for anything that was not in the approved baseline.
→Correlate privileged activity in your logging stack to see who used the new rule.

Scenario 3 · USERS

high

Rogue user account 'attacker-ssh' created

User account 'attacker-ssh' (UID 1002) was not present in the baseline. Unauthorised accounts are a primary persistence mechanism — they survive reboots and password rotations.

Suggested remediation (3) ▾

→Confirm whether the new account is authorised; if not, treat it as incident response.
→Review SSH keys, scheduled jobs, and running sessions tied to that account.
→Remove the account and its home directory through your standard identity procedure.

Scenario 4 · SUDO_GROUP

critical

Rogue user added to sudo group

The 'attacker-ssh' account was added to the `sudo` group, granting full privileged-command access. Combined with the NOPASSWD entry above, this is a clear path to silent root.

Suggested remediation (3) ▾

→List members of the administrators group and remove anyone who should not have full sudo access.
→Compare group membership to the frozen baseline snapshot.
→Rotate credentials for any account that may have been misused.

Scenario 5 · SSH_CONFIG

critical

sshd PermitRootLogin set to yes

The sshd_config now permits direct root login. This deviates from the baseline (which had it disabled) and dramatically expands the attack surface — every brute-force attempt now targets root directly.

Suggested remediation (3) ▾

→Restore the SSH server policy so interactive root login is not allowed.
→Reload the SSH service using your change window and validation checklist.
→Review authentication logs for successful root sessions after the drift appeared.

Scenario 6 · CRON

critical

Cron-based C2 beacon installed

A new cron entry pipes `curl` output to `bash` every 5 minutes from an external IP. This is a textbook command-and-control beacon — it executes whatever the attacker serves, with root privileges.

Suggested remediation (3) ▾

→Delete the unauthorised scheduled job that downloads and executes remote content.
→Inspect outbound connections initiated by scheduled tasks.
→Block the remote destination at your firewall or egress filter until the incident is closed.

Scenario 7 · FILE_INTEGRITY

high

SUID binary planted in /usr/local/bin

A new SUID-root binary was planted outside any package's manifest. SUID binaries execute with the file owner's privileges regardless of who runs them — this is a stealthy privilege-escalation backdoor.

Suggested remediation (3) ▾

→Find newly added set-user-ID binaries outside your software catalogue.
→Verify whether the file belongs to an installed package; if not, escalate as malware.
→Remove the binary and review who executed it in your command logging.

Scenario 8 · FILE_INTEGRITY

critical

/etc/passwd set to world-writable

`/etc/passwd` permissions changed from 0644 to 0666. Any local user can now add a new UID-0 account by appending a single line — this is one of the simplest local-to-root paths in Linux.

Suggested remediation (3) ▾

→Restore strict file permissions on the system account database.
→Inspect the file for hidden administrator accounts or duplicate user IDs.
→Review authentication and shell history logs around the time permissions changed.

See it run on your own host

A 20-minute live walkthrough on a real Linux VM. We capture a baseline, introduce controlled changes, and watch Blackglass classify each one with severity and context. Suggested fixes can be validated in an isolated environment first, then approved for production — automation never runs blindly against your live systems.

Book a live demo →