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

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

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

Key Takeaways Explain This Topic AI

Mapping a listening socket to its owning process needs netstat -anob or Get-NetTCPConnection on Windows, and ss -tulpn or lsof -i on Linux.

A patch level is assessed on Windows with 'wmic qfe list' or Get-HotFix and on Linux by querying the package manager (rpm -qa, dpkg -l) against vendor advisories.

Enterprise Linux distributions backport security fixes without changing the upstream version number, so patch state must be judged from the package build, not the banner.

Interesting files are those containing credentials, keys or configuration: search by name pattern, by SUID/SGID bit, and by world-writable permission.

Credentialed audit turns the guesswork of remote scanning into definitive local evidence of what is installed and what is missing.

Last updated: September 2026

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:

List processes and their associated network sockets, if any.

Assess patch levels.

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.