Hardening Techniques in Practice

Example 1 · Default Credentials — The Unlocked Door

A penetration tester is conducting an internal network assessment for a regional manufacturer. During the reconnaissance phase, they use Nmap to scan the internal network and identify live hosts. One host responds on port 80 and 443 with an HTTP response header identifying it as a specific model of industrial network switch from a well-known vendor. The tester opens a browser and navigates to the management interface URL for that switch model.

Browser: http://192.168.10.15/admin
Response: Vendor management login page for [Model SG-3048P]

Tester looks up default credentials in vendor documentation (publicly available):
Default username: admin
Default password: admin

Login attempt: admin / admin
Result: AUTHENTICATED — full administrative access granted

Tester now has access to:
  - VLAN configuration (can reroute network traffic between segments)
  - Port mirroring (can capture all traffic through the switch)
  - Firmware update (can potentially install malicious firmware)
  - Spanning tree and routing configuration (can cause network outage)
  - CDP/LLDP neighbor discovery (reveals entire network topology)

How this should have been prevented — hardening steps for this device:

1. Change the default credentials immediately upon deployment. The moment the switch is powered on for the first time, before it is connected to the production network, the admin password must be changed to a strong, unique credential. This single step would have prevented this compromise entirely.
2. Restrict management interface access to the management VLAN. The switch's web management interface (ports 80/443) should be accessible only from the management VLAN (e.g., 10.0.40.0/24), not from the general internal network at 192.168.10.0/24. A tester on the production network should not be able to reach the management interface at all.
3. Enable MFA or centralized authentication. Integrate the switch with RADIUS/TACACS+ authentication tied to the organization's directory service. This eliminates local accounts, enforces password policy, and provides centralized audit logging of all management access.
4. Disable HTTP; require HTTPS only. The management interface should require TLS-encrypted connections — cleartext HTTP exposes credentials to anyone on the same network segment who can perform a man-in-the-middle attack.

Scope of the finding: The tester subsequently discovered 14 additional devices on the network — additional switches, a wireless controller, two IP cameras, a building access control panel, and a network-attached storage device — all still running default credentials. This is not an unusual finding; it represents a systemic gap in the deployment process: no hardening checklist was applied when these devices were installed.

Example 2 · EDR Behavioral Detection — Catching What Antivirus Misses

A financial services firm is targeted by a nation-state threat actor using a custom, never-before-seen implant. The attacker delivers the implant through a spear-phishing email with a malicious Excel attachment containing an embedded macro. The macro exploits a legitimate Excel feature to execute a PowerShell command. The firm's legacy antivirus has no signature for this malware — it was written specifically for this campaign.

What the antivirus sees:

User opens Q3_Forecast.xlsx
Excel executes embedded macro
Macro spawns powershell.exe with encoded command
PowerShell downloads payload from external server
AV scans downloaded payload: no signature match → PERMITTED
Payload executes → implant installs → attacker has persistent access

What the EDR sees (behavioral analysis):

Process tree alert triggered:
  EXCEL.EXE (PID 4812) → spawned → POWERSHELL.EXE (PID 6247)
  [BEHAVIORAL RULE: Office application spawning script interpreter = HIGH RISK]

Network connection alert:
  POWERSHELL.EXE (PID 6247) → outbound TCP → 185.220.x.x:443
  [BEHAVIORAL RULE: Script interpreter initiating external connection = HIGH RISK]

File write alert:
  Downloaded binary written to C:\Users\jsmith\AppData\Local\Temp\svchost32.exe
  [BEHAVIORAL RULE: Executable written to user temp directory = SUSPICIOUS]

Persistence mechanism alert:
  Registry write: HKCU\Software\Microsoft\Windows\CurrentVersion\Run
  Value: "WindowsUpdate" → C:\Users\jsmith\AppData\Local\Temp\svchost32.exe
  [BEHAVIORAL RULE: Run key modification outside of software installation = HIGH RISK]

EDR AUTOMATED RESPONSE:
  1. Endpoint WS-FIN-042 isolated from network (C2 communication severed)
  2. svchost32.exe quarantined
  3. Registry run key removed
  4. Full process tree logged for forensic analysis
  5. Alert sent to SOC console: CRITICAL — Suspected spear-phishing implant
Total elapsed time from Excel open to endpoint isolation: 4 seconds

The antivirus had no signature for this specific implant and permitted it. The EDR had no signature either — but the behavioral pattern (Office spawning PowerShell, which downloaded and ran an executable, which modified run keys) is a well-known attack sequence that triggered multiple behavioral rules simultaneously. The implant never needed to be previously seen for the EDR to recognize and respond to it.

Root cause analysis (performed automatically by EDR): The EDR traced the attack chain back to Q3_Forecast.xlsx, identified the sending email address, flagged the user's account for review, and generated a MITRE ATT&CK-mapped incident report (T1566.001 - Spearphishing Attachment, T1059.001 - PowerShell, T1547.001 - Registry Run Keys). The security team's investigation started with a fully documented incident rather than an unexplained anomaly.

Example 3 · Open Port Discovery — The Nmap Audit

A newly hired security engineer conducts a hardening audit of a web server that has been in production for three years. The server's documented purpose is to host the company's public-facing website. The security engineer runs a basic Nmap scan to verify the server's port profile.

$ nmap -sV -p 1-65535 203.0.113.45

PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.2p2 (protocol 2.0)
80/tcp open http Apache httpd 2.4.18
443/tcp open https Apache httpd 2.4.18
3306/tcp open mysql MySQL 5.5.47
5432/tcp open postgresql PostgreSQL DB 9.3.24
8080/tcp open http-proxy PHP development server
21/tcp open ftp vsftpd 3.0.2
23/tcp open telnet Linux telnetd
27017/tcp open mongodb MongoDB 3.2.22

What should be open on a production web server:

• Port 443 (HTTPS) — public website traffic
• Port 22 (SSH) — admin access; should be restricted to management subnet only
• Port 80 (HTTP) — acceptable if used to redirect to HTTPS only

Problems found — and what they mean:

Outcome: A server that the organization believed was "just a web server" was actually running four exposed database services, a development server, a cleartext FTP server, and Telnet — all accessible from the internet, all completely undocumented. This is typical of systems that have never been through a formal hardening process: software accumulates over years of ad-hoc administration and no one has a complete picture of what is running. The Nmap scan took 3 minutes. Remediation (stopping services, applying firewall rules) took 2 hours. The server had been in this state for an estimated three years.

Example 4 · Unnecessary Software — The Legacy Java Runtime

A vulnerability scanner flags 340 workstations at an insurance company for a critical Java runtime vulnerability (CVE-2021-44228 equivalent — remote code execution via the logging library). The security team investigates and discovers that none of the workstations' users have knowingly used Java in the past two years. The Java runtime was installed by a legacy insurance quoting application that was decommissioned 18 months ago when the company migrated to a web-based platform — but the Java runtime was never uninstalled.

Current state — silent attack surface:

Java Runtime Environment 8u251 — installed on 340 workstations
Last patched: 18 months ago (at time of legacy app decommission)
Java auto-update: disabled (was disabled for compatibility with legacy app)
Current known CVEs: 23 high/critical vulnerabilities (18 months of unpatched Java)
Users actively using Java: 0
Users aware Java is installed: 0 (of 340 surveyed)
Attack vectors: malicious .jar file via phishing email; malicious web applet via drive-by download; vulnerability in Java update mechanism itself

Why this is a hardening failure, not a patching failure:

The correct response to "we decommissioned the application that required Java" is to uninstall Java at the same time. Instead, the Java runtime was left in place — unpatched, unmonitored, and unknown to users. The patching team did not patch it because it was not on their authorized software list. The security team did not monitor it because it was not in the software inventory. 340 workstations had a known RCE vulnerability for 18 months with no owner.

Two different remediation paths — and why one is better:

1. Patch Java to current version: Closes the 23 known CVEs. But Java will continue to accumulate new CVEs and require patching indefinitely. The patching team now must track and maintain software that serves no business function. This approach accepts ongoing risk from future Java vulnerabilities.
2. Uninstall Java from all 340 workstations: Permanently eliminates the Java attack surface. No future Java vulnerabilities can affect these systems. The patching team's workload decreases by one software component. This is the correct hardening response — the application that required Java is gone; the runtime should be gone too.

Process improvement to prevent recurrence: When an application is decommissioned, the decommission checklist must include "identify all dependencies installed for this application and uninstall them if not required by any remaining application." Software inventory must be maintained — the organization should know what is installed on every workstation at any time. Vulnerability scanner integration with the software inventory allows automatic identification of unowned software with known CVEs.

Exam Scenario · Endpoint Hardening Design

Scenario: A healthcare organization has experienced three security incidents in 18 months: (A) a laptop containing patient records was stolen from a physician's car — the data was fully accessible to the thief; (B) a ransomware attack encrypted files on 40 workstations — the initial infection spread from a single workstation where the user had local administrator rights; (C) an attacker gained access to a network switch management interface using the factory default credentials. For each incident, identify the hardening control that would have prevented or limited it, and explain why.

Incident A — Stolen laptop with accessible patient data:

Control: Full Disk Encryption (BitLocker). FDE encrypts the entire storage volume with a TPM-bound key. When the drive is removed from the stolen laptop and connected to another machine, the TPM is absent and the key is unavailable — the drive presents only ciphertext. The thief cannot access any patient records. This event becomes a hardware loss (cost: one laptop), not a HIPAA data breach (cost: regulatory penalties, breach notification to patients, reputational damage). The single organizational policy "BitLocker must be enabled on all portable devices" would have prevented this incident entirely.

Incident B — Ransomware spreading from a single workstation:

Control: Least privilege (remove local administrator from standard user accounts) + EDR.

• Least privilege: The ransomware's ability to spread depended on the initial user having local admin rights — the malware inherited those rights. Without admin rights, the ransomware could not install kernel-level persistence, could not disable the endpoint protection service, and could not modify system directories where ransomware typically writes its cryptographic infrastructure. The infection would have been limited to user-accessible files on the initial workstation.
• EDR: Ransomware exhibits specific behavioral patterns — it rapidly enumerates files, opens each for reading, then writes an encrypted version. EDR behavioral analysis detects this file-access pattern (mass read-write of diverse file types at high speed) and can terminate the process and isolate the endpoint within seconds of the pattern appearing, before significant data is encrypted. On the other 39 workstations, EDR would have blocked the lateral spread attempt by detecting the ransomware's behavior regardless of whether the specific ransomware variant had a signature.

Incident C — Switch management access via default credentials:

Control: Default credential change + management interface access restriction.

• Change default credentials: The factory default admin/admin credentials should have been changed before the switch was placed in production. This single step eliminates the specific attack vector used — the attacker could not have authenticated if the credential was not the published default.
• Restrict management access to management VLAN: Even if the attacker somehow obtained the updated credentials, the management interface should not be reachable from the network segment the attacker was on. Restricting management interface access to a dedicated management VLAN means an attacker on the production or guest network cannot reach the login page at all — the connection is blocked before authentication is attempted.
• MFA: Add a second factor (TOTP or hardware key) for all management interface logins, providing defense even if the password is compromised.