LINUX OFFENSIVE CHECKLIST

PRIMARY CATEGORY → CHECKLISTS

Mindmap

---

Enumeration

HTTP[s]

Web Application Functionality

• Accesible Web pages functionality while having Burpsuite open

• Non-hidden HTTP Parameters: Look for any type of injection

e.g.

GET/POST Parameters in a Login/Registration Form → SQLi

GET/POST Parameters in Contact Form | Comments | Support Tickets → XSS

A web page with GET Parameters such as File, Page and so on → LFI or RFI

A web application where a logged-in user can update its profile picture by uploading a file → File Upload

• Custom HTTP Response Headers and Cookies

Fuzzing

• Resources: Directories and Files

• Virtual Hosts and Subdomains

• Hidden Parameters

XSS

• Web Page with a Contact Form → Check for XSS

• Web Page with a Comment Section → Check for XSS

• Support Web Page with a Ticket creation Feature → Check for XSS

SQLi

• Login/Registration Panel → Check for Authentication Bypass via SQLi

• Any POST or GET Parameter. Any Cookie and User-Agent value as well

LFI

• Any POST or GET parameter

File Upload

• If the website has a login feature and we are logged in, check for File Upload

Command Injection

• Any POST or GET Parameter

HTTP Verb Tampering

• Try the same request with a different HTTP method (e.g. GET ↔ POST, POST ↔ PUT, GET ↔ HEAD )

IDOR

• Look for any direct object reference in the web application to test for its system control access

XXE

• Search for any HTTP request which sends an XML data structure on its body

FTP

Non-Credentialed Enumeration

• Anonymous Access
• Known CVE (Searchsploit, Google…)

Credentialed Enumeration

• If we can upload files, just try to upload them to a location accesible from the Web Server in order to get an RCE through the Web Shell

---

Exploitation

HTTP[s]

SQLi

• Enumeration: Databases, Tables, Columns, Fields

• Check if the current DB user has Read/Write permissions: FILE Privilege and secure_file_priv empty or set to an interesting path

• If READ permissions → Look for interesting files such as:

Web Server Configuration Files

Virtual Hosts Configuration Files: Web Root (DocumentRoot) Path, .HTPasswd files or another type of sensitive files

Configuration files within the Web Root ( config.php, db_conn.php… )

Service Configuration files that are externally accesible such as FTP, SSH, RSYNC, CIFS, SQUID, SNMP and so on

Home Directory Files such as SSH Keys, Shell History Files and so on

• If WRITE Permissions → Web Shell Deployment on Web Root or any directory on which the system user running the DBMS has write permissions

XSS

• Web Defacement

• Session Hijacking

• Phishing via Login Form Injection

LFI

• Try different Bypasses

Once we are able to exploit the LFI to point to other web files

• Information Leakage e.g. Configuration files

• Source code of Webroot scripts e.g. Other PHP scripts

RCE

• PHP Wrappers e.g. ( data:// | input:// | expect:// )

• File Upload

• RFI

• Log Poisoning

• PHP Session Poisoning

File Upload

• If the Web Application runs X (e.g. PHP), try uploading an X script (e.g. test.php)

If the given upload is not allowed, security filters may have been set up. If so →

• Client-Side Validation Bypass

• Blacklist Bypass

• Whitelist Bypass

• Content-Type Bypass

• MIME Type Bypass

If none of the previous bypasses work →

• Fuzz for allowed extensions (e.g. SVG)

• Check Limited File Uploads

Furthermore, we have to bear in mind that if we discover an LFI vulnerability, we can just fuzz for allowed extensions, add a code snippet (e.g. mini WebShell) within the file before uploading it and request it from a web client. We will gain RCE

Command Injection

• Try a basic command injection to see if there is any input validation or sanitizacion in place

if not, reverse shell and pwned. If so, proceed as follows

• Try to bypass them with different filter evasions and command obfuscation

HTTP Verb Tampering

• Send an OPTIONS HTTP request to know the supported HTTP methods by the web server

• In case of any error or unauthorized operation, simply try changing the HTTP request method to look for differences in the HTTP response

IDOR

This attack vector results from a bad access control system or its absence and a direct object reference

• Simple Direct Object Reference (e.g. <URL>?id=1 ) → Just try changing its value to something else to test the access control system

• More Secure Direct Object Reference (e.g. <URL>?id=6B29FC40-CA47-1067-B31D-00DD010662DA or <URL>?id=098f6bcd4621d373cade4e832627b4f6 ) → Check if the reference is being created in the frontend ( e.g. JS Function ) before being sent to the server

Once we discover the IDOR →

• Mass Enumeration

• Insecure Function Calls

XXE

Once we have located an HTTP request that sends XML data within its body

Data Disclosure →

• Simple XXE

• If the web application runs PHP, try XXE using PHP Filter Wrapper

• If not, try XXE using CDATA

• If our input is not reflected anywhere in the HTTP response, check if the web application handles error properly

• If not, try Error based XXE

• If we are dealing with a Blind XXE, see Blind OOB XXE

• Bear in mind that we can achieve RCE as well

---

Privesc | Lateral Movement

See Linux Prives

Global

• Additional NICs pointing to other subnets ( ip a s, /sys/class/net)
• Interesting System Directories ( /<DIRECTORY>, /opt, /var and so on )
• Running Services that are not externally accesible ( netstat or ss ) and are running as a different user ( More privileged or Root )
• Leaked Credentials on Configuration Files ( /etc, /etc/fstab or web directories → /var/www/worpdress/wp-config.php )
• Cron Jobs: Monitor Processes with Pspy and check /etc/cron.XXX and /var/spool/cron directories
• List current Processes
• SUID/GUID Binaries (PwnKit as well)
• Capabilities
• Logged in Users
• OS Vulnerability
• Kernel Vulnerability ( e.g. DirtyCow, DirtyPipe and so on )
• Sudo version vulnerable
• Installed Packages Vulnerabilities ( screen… )
• Readable Shadow File ( /etc/shadow )
• Password Hashes on /etc/passwd
• Unmounted FS and Additional Drives
• Writable Docker socket files
• TMUX or SCREEN sessions
• NFS Shares with NO_ROOT_SQUASH enabled
• Run Privesc Enumeration Scripts such as LINPEAS

Per User

• Sudo Privileges
• Groups to which the user belongs to
• Look for Sensitive Files on Current User’s home directory ( e.g. Shell History Files, SSH Keys and so on )
• Files and Directories with Write Permissions
• Access other system user directories within /home directory
• Enviromental variables and parameters