🔐 MODULE 2 OF 3

🛡️ DEFENSIVE STRATEGIES

Privilege Escalation Defense

System Hardening & Security Controls

Learn how attackers escalate privileges and how to defend against them. Master least privilege principles, secure configuration practices, and implement mandatory access control systems. Discover kernel protection mechanisms, capability restrictions, and enterprise hardening strategies that make your systems resistant to privilege escalation attacks.

Privilege Escalation Concepts

From User to Root: Attack Paths and Defense

📈

What is Escalation?

Privilege escalation occurs when a process or user gains higher privileges than intended. User → Root escalation is most dangerous. Exploitation chain: low-privilege app → kernel bug → root access.

🔓

Local Context

Local escalation requires attacker already has user-level access (compromised app, account takeover). Kernel vulnerabilities, misconfigurations, and weak privilege boundaries enable local escalation.

🌐

Remote Context

Remote escalation requires network access to vulnerable service (web server, SSH, daemon). Service runs at elevated privilege and has code bugs. Remote exploit + escalation = full system compromise.

Typical Privilege Escalation Chain

🚪 Step 1: Initial Access Attacker gains user-level shell. Either remote compromise or local user account. Limited permissions, cannot access system files.

⬇️ Reconnaissance & Exploitation Preparation ⬇️

🔍 Step 2: Vulnerability Discovery Attacker searches for escalation vectors: kernel CVEs, SUID binaries, misconfigured sudo, weak file permissions, unpatched applications, world-writable directories.

⬇️ Exploit Development ⬇️

💣 Step 3: Exploit Execution Attacker runs exploit code targeting vulnerable component. Kernel exploit triggers overflow/race condition/logic bug. Exploit code executes in privileged context.

⬇️ Privilege Gain ⬇️

👑 Step 4: Root Access Exploit succeeds. Attacker's process now runs as root. Can read/write any file, start/stop services, load kernel modules, install rootkits, exfiltrate all data.

                💡 Defense Strategy: Break the chain at every step. Minimize initial access impact,
                eliminate vulnerabilities, restrict privilege boundaries, detect exploitation attempts, implement
                hardening to slow attackers.
            

Hardening Principles

Building Secure Systems from Ground Up

🔐 Least Privilege Model

Core security principle: grant minimal permissions needed to perform function. Remove unnecessary privilege:

Services as Non-Root Users: PostgreSQL should run as 'postgres', not root. Web server should run as 'www-data', not root. Compromise of service ≠ system compromise
Capability Dropping: Process starts with root but drops capabilities to minimum needed. Nginx starts as root to bind port 80, then drops to www-data. After that point, even if code is exploited, it can't regain root
File Permissions: Config files 0600 (owner only), log files 0640 (owner + group readable). World-writable files in system directories = security hole
Sudoers Configuration: Instead of full sudo access, grant specific commands: 'app user can run /usr/bin/service restart without password'. Attacker gains that specific privilege, not all sudo
No Setuid Binaries Needed: Minimize SUID binaries (programs that run as owner regardless of who executes). Each SUID binary = potential escalation path

Implementation: Start with zero privileges, add only what's needed. Remove all others. Regular audit: which processes run as root? Why? Can privilege be dropped?

🎯 Secure Configuration Mindset

Secure defaults require proactive decisions:

Disable Unnecessary Services: Every running service = attack surface. SSH enabled? HTTP server running? Database exposed? Stop everything not actively needed
Remove Unnecessary Software: Development tools, debugging utilities, interpreters shouldn't be on production. Smaller attack surface = fewer vulnerabilities
Kernel Hardening Parameters: Linux exposes thousands of tunable kernel parameters. Defaults are not always secure. Security-focused parameters reduce attack surface
Disable Debug Features: Kernel debugging, performance tracing, verbose logging disabled in production. Debug features leak information used in attacks
Regular Security Updates: Kernel patches, library updates, application patches. Each security update closes known exploit paths. Delaying patches = staying vulnerable

🔒 Access Control Concepts

Two models of access control:

Discretionary Access Control (DAC): Linux traditional model. File owner sets permissions. User can change permissions on their files. Flexible but weak—compromised process inherits all user permissions
Mandatory Access Control (MAC): System enforces security policy regardless of owner settings. Even root can be restricted. SELinux/AppArmor examples. Stronger but more restrictive
Capability-Based Security: Fine-grained permissions. Process has capabilities (CAP_NET_BIND_SERVICE to use ports, CAP_SYS_ADMIN for admin functions). Drop unneeded capabilities
Role-Based Access Control (RBAC): Users have roles. Roles have permissions. SELinux example: 'webserver_t' role can only access web content directory

Combined Approach: Layer controls. DAC at base, MAC policy on top, capabilities for fine-grained rights, RBAC for role enforcement. Defense in depth.

Kernel Protection Mechanisms

Advanced Defense Technologies

🛡️ Security Modules: SELinux & AppArmor

Mandatory access control systems that enforce security policies at kernel level:

SELinux (Security-Enhanced Linux): NSA-developed MAC framework. Every resource (file, socket, process) has security context. Kernel denies access unless policy explicitly allows it. Strict policies allow minimal access. Default deny = more secure than default allow
AppArmor: Profile-based MAC. Programs have profiles defining allowed resources. Profile restricts what application can access even if owner allows it. Simpler than SELinux but less granular
How They Help: Process compromised? AppArmor limits which files it can read. Attacker tries to read /etc/shadow? Kernel denies access regardless of actual file permissions. Tries to execute shell script? Denied if profile doesn't allow. Syscall forbidden? Kernel blocks it
Deployment: SELinux used in Red Hat, CentOS. AppArmor in Ubuntu, Debian. Both add processing overhead but security gains justify cost

📋 Advanced Protection Features

Modern kernel protection layers:

ASLR (Address Space Layout Randomization): Memory layout randomized at each boot. Exploit expecting code at 0x7fff1234 fails when code is at 0x7fff5678. Attacker must leak addresses first, significantly harder
DEP/NX (Data Execution Prevention): Data pages marked non-executable. Stack overflow can't jump to shellcode on stack. Attacker must use ROP (Return-Oriented Programming), much more complex
Stack Canaries: Random value placed on stack. Function return checks if canary still there. Buffer overflow corrupts canary, function detects and aborts. Not perfect but catches naive overflow attempts
Seccomp (Secure Computing Mode): Restrict syscalls available to process. Container might disable 200+ dangerous syscalls. Attacker exploits syscall? If it's blocked, can't execute
Control Flow Integrity (CFI): Restrict where code can jump. Indirect jumps validated at runtime. Exploit uses ROP? CFI detects invalid gadget chain and aborts

Protection	Attack Target	Defense Mechanism	Bypass Difficulty
ASLR	Predictable memory layout	Randomize base addresses	Medium (requires info leak)
DEP/NX	Execute stack code	Mark data non-executable	Medium (requires ROP)
Stack Canaries	Buffer overflow	Check canary value	Medium (guess or leak)
Seccomp	Syscall exploitation	Block dangerous syscalls	High (use allowed syscalls)
SELinux/AppArmor	File/resource access	Policy-based access control	High (requires policy modification)

🔄 Patch Management Strategy

Patches close known vulnerabilities. Unpatched = exploitable:

Zero-Day vs. Known CVEs: Unpatched known CVEs are easiest targets. Patches released publicly, exploit code written by researchers. Attackers scan for unpatched systems
Enterprise Patching: Test patches in staging, validate no breakage, roll out to production gradually. Immediate patching risky but delayed patching dangerous
Kernel Patching: Most critical. Kernel CVEs affect entire system. Backported patches available for older kernels if upgrading isn't possible
Automated Patching: Unattended-upgrades automatically applies security patches. Reduces window of vulnerability. Requires good testing for critical systems
Vulnerability Tracking: Subscribe to CISA alerts, kernel mailing lists, CVE databases. Know what's vulnerable before attackers do

                💡 Layered Protection: No single protection is perfect. ASLR + DEP + Seccomp + SELinux
                + patches together make exploitation extremely difficult. Each layer adds time/complexity to successful
                exploit.
            

Enterprise Best Practices

Production Hardening Strategies

🏢 Secure Baseline Configuration

Enterprise systems should start from hardened baseline:

Hardened OS Images: CIS Benchmarks (Center for Internet Security) provide security configuration guides. Follow these guides to build baseline images. Test thoroughly before production deployment
Configuration Management: Use Ansible, Puppet, Chef to enforce consistent hardening across fleet. Everyone gets same secure configuration. Manual configurations = inconsistency = misconfigurations
Immutable Infrastructure: Build hardened container images, deploy as-is. Don't install software after deployment. Reduces post-deployment misconfiguration risk
Documentation: Every hardening decision documented: why it's needed, what risk it mitigates, how to monitor it. New team members understand why system is configured certain way

📊 Regular Auditing and Review

Systems drift over time. Regular audits catch misconfigurations:

Configuration Audits: Script checks: all services running as non-root? SELinux enabled? ASLR enabled? Security patches current? Compare to baseline, alert on deviations
Permission Audits: Find world-writable files in sensitive directories. Find SUID binaries that shouldn't exist. Find files owned by deleted users
Process Audits: Which processes run as root? Each one justified? Could they drop privileges? What capabilities do they need? Audit quarterly
Access Control Audits: SELinux policy violations logged? AppArmor denials? Review and adjust policy as needed. Denials might indicate attacks or legitimate use that policy is too strict
Vulnerability Scanning: Scan systems for known CVEs. Missing patches? Vulnerable services? Generate reports, prioritize fixes

🔐 Hardening Checklist

Core hardening items all production systems should have:

✅ Kernel Updated: Running latest stable kernel with all security patches. Enable auto-updates for security patches
✅ Unnecessary Services Disabled: Only required services running. SSH enabled and hardened. All others disabled
✅ ASLR Enabled: Kernel parameter kernel.randomize_va_space = 2
✅ DEP/NX Enabled: CPU supports it and kernel has it enabled. Verify with: dmesg | grep NX
✅ SELinux/AppArmor Enforced: MAC system enabled and running in enforcing mode. Policies reviewed and tuned
✅ Seccomp Enabled: Container runtimes have seccomp profiles. Applications using seccomp where possible
✅ Sudo Hardened: Specific commands in sudoers, not full sudo. Disable root SSH login. SSH key auth only
✅ File Permissions Correct: /etc/shadow mode 0640. SSH config 0600. No world-writable system files
✅ Monitoring Active: Logs centralized and monitored. Alerts for suspicious activity. Failed auth attempts logged
✅ Documentation Current: All hardening decisions documented. New admins understand why system is configured this way

Official Security Resources

Deepen Your Hardening Knowledge

📚 Hardening Guides & Benchmarks

CIS Benchmarks - Industry-standard hardening guidelines for Linux
NIST SP 800-53 - Security controls for federal information systems
DoD SRG (Security Requirements Guide) - DoD hardening requirements
Ubuntu CIS Hardening Guide - Ubuntu-specific hardening
Red Hat Security Hardening Guide - RHEL hardening best practices

🔒 Access Control & Security Modules

SELinux Project - Comprehensive SELinux documentation
AppArmor Project - AppArmor wiki and documentation
Seccomp Filter Documentation - Syscall filtering guide
Linux Capabilities Manual - Complete capabilities reference

⚠️ Vulnerability & CVE Resources

NVD (National Vulnerability Database) - Official CVE database
CISA Alerts - US security agency alerts on critical vulnerabilities
Linux Weekly News - Kernel News - Weekly kernel security updates
Linux Kernel Releases - Official kernel release information

🎓

Verified Certificate

Complete All 3 Modules to Unlock

Complete all 3 modules of this course to unlock your
Verified Cyber Security Certificate
from MONEY MITRA NETWORK ACADEMY

📱 Unique ID + QR Verification
Verified, shareable, industry-recognized credential

Ready for the Final Module?

Progress to Module 3: OS-Level Forensics & Incident Response

Module 2 Progress: ✅ Privilege Escalation & Hardening Complete
Final Module: Forensics & Incident Response for Compromised Systems