7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

Syllabus item B14 is short but specific. A candidate must be able to perform three host audit tasks with local (usually authenticated) access:

1. List processes and their associated network sockets, if any.
2. Assess patch levels.
3. Find interesting files.

This is the work that happens after a foothold, or during a credentialed vulnerability assessment where the client provides an account. Remote scanning infers; a host audit confirms. Where a banner grab guesses that a host might be vulnerable, a host audit reads the installed package version and the list of applied patches and settles the question.

---

1. Mapping Processes to Network Sockets

The core question is: for every port this host is listening on, which program opened it, and running as whom? An unexpected listener is often the first sign of a backdoor, a forgotten debug service, or a misconfigured application.

Windows

# Classic: -a all connections, -n numeric, -o owning PID, -b owning executable (needs admin)
netstat -anob

# Modern PowerShell equivalent, joined to the process table
Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress,LocalPort,OwningProcess,
    @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}}

# UDP listeners
Get-NetUDPEndpoint

# Full process detail including the command line and owning account
Get-CimInstance Win32_Process |
  Select-Object ProcessId,Name,CommandLine
tasklist /svc          # which service is hosted in each svchost.exe PID

netstat -anob is the single most useful command: -o gives the PID and -b names the executable that owns each socket, so a listener on an odd high port is immediately traced to powershell.exe or an unsigned binary in a user's temp directory.

Linux / Unix

# ss is the modern replacement for netstat: -t TCP, -u UDP, -l listening,
# -p owning process, -n numeric
ss -tulpn

# lsof lists open files, and a socket is a file: -i restricts to network files
sudo lsof -i -P -n

# tie a specific port to its process
sudo lsof -i :445
sudo fuser 445/tcp

# what is each process and who owns it
ps auxww

The output you want links three things together: port -> PID -> executable path -> owning user. A service listening on 0.0.0.0 as root is a bigger finding than the same service bound to 127.0.0.1 as an unprivileged account, and only the local view shows you the bind address and the owning identity reliably.

$ sudo ss -tulpn
Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:22          users:(("sshd",pid=812,fd=3))
tcp   LISTEN 127.0.0.1:5432      users:(("postgres",pid=1140,fd=5))
tcp   LISTEN 0.0.0.0:4444        users:(("python3",pid=9931,fd=3))   <-- investigate

---

2. Assessing Patch Levels

A patch-level assessment answers: what is installed, at what version, and which known-vulnerable versions or missing fixes does that imply?

Windows

wmic qfe list brief /format:table      # installed hotfixes (KB numbers + install date)
Get-HotFix | Sort-Object InstalledOn   # PowerShell equivalent
systeminfo                             # OS build, and the hotfix list at the bottom
[System.Environment]::OSVersion        # precise build number

The OS build number plus the list of installed KB articles is compared against Microsoft's monthly security update catalogue. The gap — updates released but not present — is the missing-patch list. Tools such as Windows Exploit Suggester and wesng automate exactly this comparison by parsing systeminfo output against Microsoft's advisory feed.

Linux / Unix

rpm -qa --last          # RHEL/CentOS/SUSE: every installed package with install date
dpkg -l                 # Debian/Ubuntu: installed packages and versions
yum updateinfo list security   # RHEL: outstanding security advisories
apt list --upgradable   # Debian/Ubuntu: available updates
uname -a                # kernel version and build

The installed package version is checked against the distribution's security advisories (RHSA, DSA, USN). Third-party tools like pompem, linux-exploit-suggester and vendor scanners automate the correlation.

The Backporting Paradox — Why the Banner Lies

This is examinable and catches people out. Enterprise Linux distributions backport security fixes into the version they ship without changing the upstream version string. Red Hat may take the fix for a vulnerability in OpenSSH 9.6 and apply it to the openssh-8.0p1 package it shipped years earlier, releasing openssh-8.0p1-19.el8_9. The service banner still proudly announces OpenSSH_8.0, so a naive remote scanner flags it as vulnerable to every 8.0 CVE — a false positive.

The only reliable resolution is the local audit: read the full package build/release string (rpm -q openssh gives openssh-8.0p1-19.el8_9) and check the vendor's changelog (rpm -q --changelog openssh | grep CVE-2024-...) to see whether the specific fix is present. This is the single strongest argument for credentialed scanning over unauthenticated scanning, and it recurs throughout the CPSA syllabus.

---

3. Finding Interesting Files

"Interesting" means files that advance the assessment: credentials, private keys, configuration, backups, and anything mis-permissioned enough to be a privilege-escalation lever.

By Content and Name

# Credentials and keys by filename
find / -type f \( -name "*.conf" -o -name "*.config" -o -name "*.ini" \
   -o -name "*.bak" -o -name "id_rsa" -o -name "*.pem" -o -name "*.kdbx" \) 2>/dev/null

# Credentials by content
grep -RInE "password|passwd|secret|api[_-]?key|BEGIN (RSA|OPENSSH) PRIVATE KEY" \
   /var/www /opt /home 2>/dev/null

# Command history and cloud credentials
cat ~/.bash_history ~/.mysql_history 2>/dev/null
ls -la ~/.aws ~/.ssh ~/.kube 2>/dev/null

# Windows: config files and unattended-install answer files that hold passwords
Get-ChildItem C:\ -Include *.config,*.xml,unattend.xml,sysprep.inf,web.config -Recurse -ErrorAction SilentlyContinue |
  Select-String -Pattern "password","connectionString","apikey"

By Permission — the Privilege-Escalation Angle

Files are also "interesting" when their permissions are wrong:

# SUID / SGID binaries: run with the file owner's privileges (see section 9.1)
find / -perm -4000 -type f 2>/dev/null      # SUID
find / -perm -2000 -type f 2>/dev/null      # SGID

# World-writable files and directories
find / -perm -0002 -type f -not -path "/proc/*" 2>/dev/null
find / -perm -0002 -type d 2>/dev/null

# Files owned by root but writable by others - direct escalation candidates
find / -uid 0 -perm -0002 -type f 2>/dev/null

# Windows: files/services whose ACLs let a low-privileged user modify a binary
icacls "C:\Program Files\VulnApp\service.exe"
Get-Acl "C:\Program Files\VulnApp\service.exe" | Format-List

A world-writable file owned by root, a SUID copy of an interpreter, or a service binary a standard user can overwrite each converts "found a file" into "became root". Section 8.5 and section 9.1 cover the Windows and Unix permission models in full; here the point is that enumerating permission anomalies is part of the file audit, not a separate task.

---

4. The Credentialed Audit Workflow

 1. Establish local access        (provided account, or post-exploitation)
 2. Enumerate listeners           ss -tulpn / netstat -anob   -> unexpected sockets
 3. Map sockets to processes      lsof -i / tasklist /svc     -> owning binary + user
 4. Read the patch state          rpm -qa / Get-HotFix        -> installed versions
 5. Correlate to advisories       vendor changelogs / NVD      -> genuine missing fixes
 6. Sweep for interesting files   find / grep / icacls         -> creds, keys, configs
 7. Enumerate permission flaws    SUID/SGID, world-writable    -> escalation levers
 8. Record evidence               command output + timestamps  -> the report's proof

Every step produces primary evidence — the actual command and its actual output — which is what distinguishes a defensible finding from an inference. Capture it into your notes as you go (see the record-keeping section), because "the host was missing KB5030211" is only credible in a report if the Get-HotFix output that proves it is attached.

Finally, remember the boundary: this workflow assumes the host is in scope and you are authorised to run local commands on it. Reading a client's id_rsa or web.config is exactly the kind of action the Rules of Engagement and the Computer Misuse Act govern, so the authority to do it must be established before you do, not after.