================================================================================
PRIVILEGE ESCALATION TOOLKIT
================================================================================

!!! This is the first release so there may be even trivial errors, please write Issues if you find them !!!

WARNING: FOR AUTHORIZED SECURITY TESTING ONLY
ILLEGAL USE IS A CRIMINAL OFFENSE

--------------------------------------------------------------------------------
TABLE OF CONTENTS
--------------------------------------------------------------------------------
1.  WHAT IS THIS?
2.  DISCLAIMER AND LEGAL WARNING
3.  TECHNICAL OVERVIEW
4.  SUPPORTED PLATFORMS
5.  HOW IT WORKS (TECHNICAL DETAILS)
6.  INSTALLATION AND COMPILATION
7.  USAGE EXAMPLES
8.  DETECTION AND PREVENTION
9.  ETHICAL USE GUIDELINES
10. FAQ
11. CONTACT AND REPORTING
12. Support

--------------------------------------------------------------------------------
1. WHAT IS THIS?
--------------------------------------------------------------------------------

This is a comprehensive privilege escalation testing toolkit consisting of
two main components:

1. LINUX_ESCALATOR.C - For Linux/Unix systems (including Android via Termux)
2. WINDOWS_ESCALATOR.C - For Windows systems

Purpose: These tools automate the discovery and exploitation of privilege
escalation vulnerabilities in operating systems. They are designed for:
- Security researchers
- Penetration testers (with proper authorization)
- System administrators testing their own infrastructure
- Cybersecurity students in controlled lab environments

The tools automatically scan for multiple privilege escalation vectors and
attempt to exploit them to gain higher privileges (root on Linux, SYSTEM on
Windows).

--------------------------------------------------------------------------------
2. DISCLAIMER AND LEGAL WARNING
--------------------------------------------------------------------------------

CRITICAL LEGAL NOTICE:

1. UNAUTHORIZED ACCESS IS ILLEGAL
- Using these tools on systems you do not own or lack explicit written
permission to test is a criminal offense in most jurisdictions
- Penalties can include imprisonment and significant fines

2. AUTHORIZED USE ONLY
- Only use on your own systems
- Only use with explicit written permission from system owners
- Only use in isolated lab environments for educational purposes

3. NO WARRANTY
- These tools are provided "as-is" with no warranties
- The authors are not responsible for any damage, legal issues, or
consequences resulting from use

4. EXPORT CONTROLS
- These tools may be subject to export control regulations
- Do not share with restricted persons or countries

5. ETHICAL OBLIGATIONS
- Always obtain proper authorization
- Always document your testing
- Always respect privacy and data protection laws
- Report vulnerabilities responsibly

IF YOU ARE UNSURE ABOUT LEGALITY, DO NOT USE THESE TOOLS.

--------------------------------------------------------------------------------
3. TECHNICAL OVERVIEW
--------------------------------------------------------------------------------

Both tools follow a similar architecture:

SCANNING PHASE:
- Enumerate system information (OS, users, privileges)
- Identify potential attack vectors
- Check security mechanisms (SELinux, AppArmor, Windows Defender)
- Detect fake root environments (proot/chroot)
- Detect virtual machines

SAFETY CHECKS:
- Dry-run mode simulation
- Critical file protection
- What-if analysis
- Checklist generation
- VM/proot environment warnings

EXPLOITATION PHASE:
- Attempt multiple exploitation methods in sequence
- Respect safety modes and critical file protections
- Use silent operations to avoid detection

PERSISTENCE PHASE (if successful):
- Establish backdoors for continued access
- Set up automatic re-entry mechanisms
- Hide traces of exploitation

CLEANUP PHASE:
- Remove temporary files
- Clear logs and history
- Restore original files where possible

--------------------------------------------------------------------------------
4. SUPPORTED PLATFORMS
--------------------------------------------------------------------------------

LINUX VERSION:
- Linux distributions (Ubuntu, Debian, CentOS, RHEL, etc.)
- Unix-like systems (BSD, macOS with modifications)
- Android via Termux (with root access)
- Docker containers (especially privileged containers)
- Embedded Linux systems
- WSL (Windows Subsystem for Linux)

WINDOWS VERSION:
- Windows 7/8/10/11 (32-bit and 64-bit)
- Windows Server 2008/2012/2016/2019/2022
- Windows Embedded systems
- Virtual machines (detected automatically)

NOT SUPPORTED:
- iOS (different architecture and security model)
- Mainframe systems
- Real-time operating systems
- Highly secured systems with full hardening

--------------------------------------------------------------------------------
5. HOW IT WORKS (TECHNICAL DETAILS)
--------------------------------------------------------------------------------

A. LINUX VERSION (linux_escalator.c) - MAIN EXPLOITATION VECTORS:

1. SUID/SGID Binary Exploitation:
- Finds binaries with setuid/setgid bits
- Checks if they are writable or owned by current user
- Replaces them with malicious code that runs with elevated privileges
- Includes critical file protection to prevent system damage

2. Linux Capabilities Abuse:
- Identifies programs with dangerous capabilities (cap_setuid, cap_dac_override)
- Uses capabilities to bypass permission checks
- Example: cap_setuid allows setting UID to 0 (root)

3. /proc Filesystem Vulnerabilities:
- Exploits writable /proc entries (core_pattern, modprobe)
- Uses these to execute arbitrary code with elevated privileges
- Checks permissions before exploitation

4. Container Escape:
- Detects if running in Docker/LXC container
- Attempts namespace escapes
- Exploits Docker socket access

5. SELinux/AppArmor Bypass:
- Attempts to disable or bypass mandatory access controls
- Exploits misconfigured policies
- Uses type transitions to gain privileges

6. Kernel Exploits:
- Checks kernel version for known vulnerabilities
- Suggests appropriate exploits based on kernel version
- Includes safety checks for production systems

B. WINDOWS VERSION (windows_escalator.c) - MAIN EXPLOITATION VECTORS:

1. Service Exploitation:
- Finds services with writable binaries or weak permissions
- Modifies service configuration to run malicious code
- Exploits unquoted service paths
- Includes VM detection for safe testing

2. Token Privilege Abuse:
- Checks for dangerous privileges (SeDebugPrivilege, SeImpersonatePrivilege)
- Uses token manipulation to gain SYSTEM privileges
- Implements Potato-family exploit detection

3. DLL Hijacking:
- Identifies opportunities for DLL search order hijacking
- Plants malicious DLLs in writable directories
- Waits for privileged processes to load them

4. Registry Exploits:
- Checks AlwaysInstallElevated registry keys
- Adds persistence via autorun registry entries
- Exploits Image File Execution Options

5. File System Weaknesses:
- Finds writable system directories
- Exploits weak file permissions
- Uses symbolic link attacks

C. SAFETY FEATURES (BOTH VERSIONS):

1. Dry-Run Mode:
- Simulates exploitation without making changes
- Shows what would be done
- Perfect for planning and testing

2. Checklist Mode:
- Generates step-by-step attack plan
- Lists all files and registry keys to be modified
- Provides safety assessment

3. What-If Analysis:
- Shows potential consequences of successful exploitation
- Lists privileges that would be gained
- Provides risk assessment

4. Critical File Protection:
- Prevents modification of essential system files
- Skips dangerous operations on critical components
- Warns before potentially destructive actions

5. Environment Detection:
- Detects fake root environments (proot/chroot)
- Identifies virtual machines
- Warns about unsafe testing conditions

--------------------------------------------------------------------------------
6. INSTALLATION AND COMPILATION
--------------------------------------------------------------------------------

A. LINUX VERSION COMPILATION:

Basic compilation:
$ gcc -o escalator linux_escalator.c -O2 -Wall

Static compilation (recommended for portability):
$ gcc -o escalator linux_escalator.c -static -O2 -s

With all warnings and optimizations:
$ gcc -o escalator linux_escalator.c -O2 -Wall -Wextra -pedantic -static -s

For Android/Termux:
$ gcc -o escalator linux_escalator.c -static -O2 -s

For Docker testing:
$ docker run --rm -it -v $(pwd):/app alpine sh -c "apk add build-base && cd /app && gcc linux_escalator.c -o escalator -static -O2 -s"

Minimal size compilation:
$ gcc -o escalator linux_escalator.c -static -Os -s -fno-ident -Wl,--build-id=none

B. WINDOWS VERSION COMPILATION:

On Linux with MinGW (recommended for cross-compilation):
$ x86_64-w64-mingw32-gcc windows_escalator.c -o windows_escalator.exe \
-ladvapi32 -luser32 -lole32 -lshlwapi -lpsapi \
-static -O2 -s -Wl,--strip-all

On Windows with MinGW:
> gcc windows_escalator.c -o windows_escalator.exe \
-ladvapi32 -luser32 -lole32 -lshlwapi -lpsapi \
-O2 -s

On Windows with Visual Studio:
> cl windows_escalator.c \
advapi32.lib user32.lib ole32.lib shlwapi.lib psapi.lib \
/O2 /MT /Fe:windows_escalator.exe

For stealth (smaller binary, no debug info):
$ x86_64-w64-mingw32-gcc windows_escalator.c -o windows_escalator.exe \
-ladvapi32 -luser32 -lole32 -lshlwapi -lpsapi \
-static -Os -s -Wl,--strip-all -fno-ident -Wl,--gc-sections

C. COMPILATION OPTIONS EXPLAINED:

- -static: Create statically linked binary (no external dependencies)
- -O2: Optimization level 2 (good balance of speed and size)
- -Os: Optimize for size (smallest possible binary)
- -s: Strip debugging symbols (reduces binary size)
- -Wall -Wextra -pedantic: Enable all warnings (improves code quality)
- -Wl,--strip-all: Aggressive symbol stripping (Windows)
- -fno-ident: Remove compiler identification (reduces forensic footprint)
- -Wl,--gc-sections: Remove unused code sections (smaller binary)
- /MT: Static runtime linking (Visual Studio)

D. RECOMMENDED TEST ENVIRONMENTS:

1. Virtual Machines:
- VMware Workstation/Player with snapshots enabled
- VirtualBox with saved states
- Hyper-V isolated virtual networks
- QEMU/KVM with no network connectivity

2. Docker Containers:
$ docker run --rm -it --privileged alpine sh
$ docker run --rm -it -v /:/host ubuntu bash
$ docker run --rm -it --cap-add=SYS_ADMIN debian bash

3. Cloud Instances:
- AWS EC2 spot instances (auto-terminate after testing)
- Google Cloud temporary VMs
- Azure disposable resources
- DigitalOcean droplets with backups disabled

4. Physical Lab:
- Dedicated test machines (no production data)
- Air-gapped network segment
- Hardware write blockers for forensic analysis
- BIOS-level boot protection

--------------------------------------------------------------------------------
7. USAGE EXAMPLES
--------------------------------------------------------------------------------

A. LINUX VERSION:

1. Safety check and analysis:
$ ./escalator -l          # Show exploitation checklist
$ ./escalator -w          # What-if analysis
$ ./escalator -s          # Scan only (no exploitation)

2. Dry-run mode (safe testing):
$ ./escalator -d          # Show actions without executing
$ ./escalator -d -a       # Auto-exploit dry-run

3. Interactive mode:
$ ./escalator             # Default interactive mode
$ ./escalator -a          # Auto-exploit (with safety checks)

4. Force mode (dangerous - bypasses protections):
$ ./escalator -f -a       # Force auto-exploit
$ ./escalator -f -d -a    # Force mode dry-run

5. Cleanup:
$ ./escalator -c          # Cleanup traces only

B. WINDOWS VERSION:

1. Safety check and analysis:
C:\> windows_escalator.exe -l          # Show checklist
C:\> windows_escalator.exe -w          # What-if analysis
C:\> windows_escalator.exe -s          # Scan only

2. Dry-run mode:
C:\> windows_escalator.exe -d          # Dry-run simulation
C:\> windows_escalator.exe -d -a       # Auto-exploit dry-run

3. Interactive mode:
C:\> windows_escalator.exe             # Default interactive
C:\> windows_escalator.exe -a          # Auto-exploit

4. Force mode:
C:\> windows_escalator.exe -f -a       # Force auto-exploit

5. Cleanup:
C:\> windows_escalator.exe -c          # Cleanup only

C. PRACTICAL SCENARIOS:

Scenario 1: Initial reconnaissance
$ ./escalator -s            # Scan for vulnerabilities
$ ./escalator -l            # Review attack plan
$ ./escalator -w            # Assess potential impact

Scenario 2: Safe testing
$ ./escalator -d -a         # Dry-run of full attack chain
# Review output, then if safe:
$ ./escalator -a            # Execute with all safety checks

Scenario 3: Emergency response
# If system was previously compromised:
$ ./escalator -c            # Clean all persistence and backdoors

Scenario 4: Educational demonstration
$ ./escalator -d -l -w -s   # Complete analysis without execution
# Show students the attack methodology safely

D. EXPECTED OUTPUT:

Safety warnings (when applicable):
[-] Detected proot/fake root environment
[-] Critical file detected - skipping
[*] DRY RUN MODE - No changes will be made
[!] Running in VM - persistence may not work

Successful exploitation:
[+] PRIVILEGE ESCALATION SUCCESSFUL
[*] Setting up persistence...
[*] Launching elevated shell...

Failed exploitation:
[-] All exploitation attempts failed
[-] System appears to be well-hardened
[+] No vulnerabilities found - system is secure

Scan results:
[*] Found 3 potential SUID targets
[*] 1 writable /proc entry detected
[*] Kernel version may be vulnerable to CVE-XXXX-XXXX

--------------------------------------------------------------------------------
8. DETECTION AND PREVENTION
--------------------------------------------------------------------------------

A. HOW TO DETECT THESE ATTACKS:

1. Behavioral Indicators:
- Multiple privilege escalation attempts in short time
- Service binary modifications during non-maintenance hours
- Registry Run key additions by non-admin users
- Sudden appearance of SUID binaries

2. Forensic Artifacts:
- Temporary directories with "escalate_" prefix
- Backup files ending in ".backup_esc"
- Files with modified timestamps (set to 2020-01-01)
- Unusual library files (libhack.so, evil.dll)

3. Log Entries:
- Failed then successful privilege operations
- Service control manager modifications
- Process injection attempts (SeDebugPrivilege usage)
- Unusual command execution patterns

B. PREVENTION MEASURES:

1. For Linux Systems:
# Regular SUID/SGID audits
find / -type f -perm -4000 -o -perm -2000 2>/dev/null

# Remove unnecessary capabilities
setcap -r /path/to/binary

# Harden /proc filesystem
mount -o remount,hidepid=2 /proc

# Implement mandatory access controls
setenforce 1
aa-enforce /etc/apparmor.d/*

2. For Windows Systems:
# Regular service permission audits
sc.exe query type= service state= all

# Enable security features
Enable-WindowsOptionalFeature -Online -FeatureName "Windows-Defender-ApplicationGuard"

# Implement least privilege
net localgroup administrators

# Regular registry audits
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

3. General Security Practices:
- Regular patching and updates
- File integrity monitoring
- Least privilege principle enforcement
- Network segmentation
- Security awareness training

C. SPECIFIC COUNTERMEASURES:

Against SUID/SGID exploits:
# Find and remove unnecessary setuid bits
find / -type f -perm -4000 -exec ls -la {} \; | grep -v "/usr/bin"
find / -type f -perm -2000 -exec ls -la {} \; | grep -v "/usr/bin"

Against service exploitation:
# Windows service hardening
sc.exe sdshow <servicename>
icacls "C:\Windows\System32\servicename.exe"

Against persistence mechanisms:
# Monitor startup locations
ls -la /etc/init.d/ /etc/systemd/system/
reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"
dir "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup"

--------------------------------------------------------------------------------
9. ETHICAL USE GUIDELINES
--------------------------------------------------------------------------------

BEFORE TESTING:
1. Obtain written authorization specifying scope, timing, and methods
2. Document testing methodology and success criteria
3. Set up isolated test environment with no production data
4. Create full system backups and verify restoration process
5. Establish communication channels and emergency contact procedures

DURING TESTING:
1. Always start with dry-run mode (-d) to preview actions
2. Use checklist mode (-l) to review and document attack plan
3. Run what-if analysis (-w) to understand potential consequences
4. Stay strictly within authorized scope and testing windows
5. Document all actions with timestamps and screenshots

AFTER TESTING:
1. Execute cleanup mode (-c) on all test systems
2. Verify system integrity and functionality
3. Remove all persistence mechanisms and backdoors
4. Provide detailed technical report to stakeholders
5. Assist with remediation and hardening of found vulnerabilities

REPORTING VULNERABILITIES:
1. Follow responsible disclosure policies of affected vendors
2. Contact vendor security team through established channels
3. Provide clear, concise proof-of-concept without weaponized code
4. Allow reasonable time for patch development and deployment
5. Coordinate public disclosure timing with vendor after fixes are available

LEGAL DOCUMENTATION:
1. Maintain signed authorization letters with scope definition
2. Keep detailed testing logs with timestamps and actions
3. Document all data accessed, modified, or collected
4. Follow applicable data protection regulations (GDPR, CCPA, HIPAA, etc.)
5. Consult legal counsel for compliance with local and international laws

--------------------------------------------------------------------------------
10. FAQ
--------------------------------------------------------------------------------

Q1: Is this legal to use?
A1: Only with explicit written permission from system owner. Unauthorized use is illegal.

Q2: What safety features are included?
A2: Dry-run mode, checklist generation, what-if analysis, critical file protection, environment detection.

Q3: Will antivirus detect these tools?
A3: Modern AV/EDR solutions may detect these activities. The tools include some evasion but are not fully stealthy.

Q4: Can this damage my system?
A4: Yes, if used improperly. Always test in isolated environments first and use dry-run mode.

Q5: Why use static compilation?
A5: Static binaries have no dependencies, work on more systems, and are easier to transfer between environments.

Q6: What is dry-run mode?
A6: Shows all actions that would be taken without actually executing them. Perfect for planning and testing.

Q7: How do I know if I'm in a fake root environment?
A7: The tool automatically detects proot/chroot environments and warns you.

Q8: Can this bypass all security measures?
A8: No. Modern well-hardened systems with defense-in-depth can prevent most of these attacks.

Q9: When should I use force mode?
A9: Only in controlled lab environments when you fully understand and accept the risks.

Q10: How do I completely remove the tool if needed?
A10: Use cleanup mode (-c), restore from backups, or reinstall the operating system.

--------------------------------------------------------------------------------
11. CONTACT AND REPORTING
--------------------------------------------------------------------------------

SECURITY ISSUES IN THESE TOOLS:
If you find vulnerabilities in these tools themselves, please report responsibly.

EDUCATIONAL USE:
For educational purposes, use only in controlled lab environments with proper supervision.

LEGAL QUESTIONS:
Consult with legal counsel before use. The authors provide no legal advice.

DISCLAIMER REMINDER:
The authors assume no liability for any use or misuse of these tools.
Users are solely responsible for complying with all applicable laws.

--------------------------------------------------------------------------------
12. CONTACT AND REPORTING
--------------------------------------------------------------------------------

If you liked my work then I would be happy to support:
https://ko-fi.com/ferki

================================================================================
END OF DOCUMENT
================================================================================