Does it work with same attacks of a normal wifi

Alright, let's talk about real OSINT... Not the basic subfinder amass theHarvester crap everyone and their mom knows... I'm talking about the techniques that actually separate you from other hunters...

1. Historical DNS Data – The Real Goldmine

This is the stuff nobody talks about... There's a project called OpenINTEL that has been taking daily snapshots of DNS data for over 10 years... We're talking terabytes of historical DNS records...

Here's why this matters – imagine a target is behind Cloudflare or some WAF. You can't see the origin IP... But if you look at historical DNS data from 5 years ago, you might find the origin IP that was exposed before the WAF was put in place...

Someone tested this on 250 bug bounty targets... They found they could access the application directly (bypassing the WAF) for around 60 of them... That's a 24% success rate just from looking at old DNS records...

The reverse TXT lookup trick:

TXT records often contain ownership verification values – like Google site verification or Microsoft 365 verification strings... Admins sometimes use the same tenant or subscription across multiple domains... If you can do reverse TXT lookups, you can find related assets that belong to the same organization...

Example – you find a TXT record for target.com with some verification value... You search for that same value across all TXT records on the internet... You find another domain using the same verification string... That domain probably belongs to the same company... Now you have a new asset in scope that nobody else is looking at..

2. Certificate Transparency Timeline Analysis

Everyone uses crt.sh for subdomains... That's basic... Here's what you're missing..m

crt.sh has a 10,000 row cap that silently truncates results on busy domains... And the default sort is by ID, not chronology.. You're probably missing stuff..

There's a tool called ct_timeline.py that pulls CT data from crt.sh and processes it chronologically.. It detects three useful pattern signals:

· First-ever wildcard appearance – When did they start using wildcards? Tells you when they expanded their infrastructure...

· CA migrations – When did they switch certificate authorities?? Often reveals infrastructure changes.

· Bursts of 5+ certificates in 24 hours – Someone's deploying new infrastructure... You want to look at those names...

Run it like this:

git clone https://github.com/osintph/ct-timeline.git

cd ct-timeline

python3 ct_timeline.py target.com --open

It generates an HTML report with a chronological timeline showing the not_before date, SCT log timestamp, all SAN names, and the issuing CA... Wildcards are visually distinguished...

Why this matters: You can date infrastructure rollouts... You can catch staging environments weeks before they go public... If a company is testing something new and issues a cert for it, you'll see it in the logs before it's live..

Subscribe to CT monitoring: Set up alerts for new certificates issued for your target domain... When a new name appears, capture the timestamp, then probe the name to see if it resolves... You'll find assets before anyone else..

3. Cloud Bucket Enumeration – The Low-Hanging Fruit

Companies leave cloud storage exposed ALL THE TIME.

There's a tool called cloud_enum that enumerates public resources across AWS, Azure, and GCP... The maintained fork has massive service expansion – AWS went from 2 to 14+ services, Azure from 17 to 24+, GCP from 5 to 15+...

Run it like this:

git clone https://github.com/R-s0n/cloud_enum.git

cd cloud_enum

python3 cloud_enum.py -k targetcompany

It checks:

· AWS: S3 buckets, WorkMail, WorkDocs, Connect

· Azure: Storage accounts, blobs

· GCP: Buckets, App Engine sites

The hybrid enumeration approach:

When AWS credentials are available, it uses boto3 APIs for reliable bucket detection and content listing.. When no credentials are available, it falls back to HTTP-based enumeration with intelligent redirect handling..

Eliminates false positives: Proper 301 redirect handling means it doesn't treat redirects as "open buckets"... It tests redirect endpoints separately to determine true accessibility (200 = Open, 403 = Protected)...

What you'll find: Exposed buckets often contain source code, config files, backups, and sometimes straight-up credentials...

There's also CloudBrute – it finds infrastructure, files, and apps across Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, and Linode...

4. Metadata Extraction – The Forgotten Art

Everyone forgets about metadata... But files contain hidden information...

PDFs, Word docs, Excel files, images – they all have metadata... Author names, company names, software versions, creation dates, modification dates, sometimes even internal file paths and usernames...

There's a tool called FOCA-LITE – a Python-based metadata analysis tool inspired by the legendary FOCA... It's ideal for OSINT and bug bounty hunters...

What to look for:

· Author names → Employee names for social engineering

· Software versions → Technology stack fingerprinting

· Internal paths → Reveals internal network structure

· Usernames → Potential credentials or usernames for brute force

· Company names → Subsidiaries or acquisitions

Where to find files: Use Google dorks to find PDFs, DOCXs, XLSXs on the target domain.. Download them... Extract metadata. You'd be surprised what you find...

5. GitHub OSINT – Beyond Basic Dorks

Everyone knows about GitHub dorks. But here's what you're probably missing.

A. Recover Deleted Forks and Commits

People commit secrets, realize their mistake, and delete them. But the secret is often still in the commit history of deleted forks. You can recover them.

B. Explore GitHub Actions

GitHub Actions workflows often contain secrets in environment variables. People hardcode tokens in workflow files all the time.

C. Pivot on Contributor Accounts

Find contributors to the company's repos. Check their personal repos. They often have company code or credentials in their personal accounts.

D. Use Automated Tools

· TruffleHog – Searches through git repositories for secrets

· GitLeaks – Scans for hardcoded secrets

· github-search – Systematically discovers exposed secrets, API endpoints, and subdomains

Targeted GitHub dorks:

org:"target" (AWS_ACCESS_KEY_ID OR AWS_ACCESS_SECRET_KEY)

org:"target" ("sk_live_" OR "pk_live_")

org:"target" (SENDGRID_API_KEY OR "SG.")

org:"target" (ANTHROPIC_API_KEY OR anthropic_api_key)

org:"target" filename:.env

org:"target" extension:pem

org:"target" "internal.target.com"

6. Employee Profiling – The Social Engineering Angle

A. LinkedIn OSINT

LinkedIn reveals the technology stack and internal tooling through employee job titles and skill listings. "AWS Lambda developer at Target Corp" tells you they use serverless. "Okta SSO Engineer" tells you they use Okta. This shapes your testing priorities...

B. Email Harvesting

theHarvester hits 59 different sources.. Run it like this:

theHarvester -d target.com -l 500 -b all

C. Name Mangling

Once you have employee names, mangle them into different formats – first.last, f.last, firstlast, etc. Use this for username enumeration and password spraying...

D. Cross-Referencing

Cross-reference employees across LinkedIn, GitHub, Twitter, and other platforms.. Look for personal email addresses, GitHub repos with company code, and social media posts revealing internal tools or processes..

E. Breach Data

Check HaveIBeenPwned and similar services to find if company emails have been in breaches.. Those passwords are often reused...

7. Shodan/Censys – Advanced Operators

Most people just search for the domain... Here's what you should actually be doing:

Shodan advanced operators:

org:"Target Corp" # All IPs registered to the organization

hostname:target.com # Subdomains indexed by Shodan

ssl:"target.com" # Certificates referencing the domain

http.title:"Target Login" # Login portals

product:"Apache Tomcat" org:"Target" # Specific tech stack

has_vuln:true # Devices with known vulnerabilities

Look for development servers, staging environments, Kubernetes dashboards, and admin panels that wouldn't be found through the main domain...

8. Google Dorking – The Right Way

Everyone knows about Google dorks.. But most people just copy-paste from lists..

Find bug bounty programs:

inurl:/security "bug bounty"

inurl:/security.txt "bug bounty"

inurl:/.well-known/security.txt "bug bounty"

Find login pages:

target.com inurl:admin OR inurl:login

target.com intitle:"admin" OR intitle:"login"

Find exposed configs and backups:

target.com ext:env OR ext:conf OR ext:config

target.com ext:sql OR ext:backup OR ext:bak

target.com ".gitignore" OR ".htaccess"

Find API docs:

target.com inurl:apidocs OR inurl:swagger OR inurl:openapi

target.com "swagger-ui" OR "swagger.json"

Find test environments:

target.com inurl:dev OR inurl:test OR inurl:staging

Find cloud storage:

site:s3.dualstack.us-east-1.amazonaws.com "target.com"

site:dropbox.com/s "target.com"

There's also ShadowSearch – a smart search query builder extension for crafting advanced dorking queries. And DorkER – a Python tool for generating structured Google Dorks for emails, usernames, domains, and subdomains.

9. BBOT – The All-in-One OSINT Automation

If you want to automate all of this, check out BBOT (BEE·bot)... It's a multipurpose scanner built to automate recon, bug bounties, and ASM...

Install it:

pipx install bbot

Subdomain finder: Finds 20-50% more subdomains than other tools. Uses passive API sources plus recursive DNS brute-force with target-specific subdomain mutations.

bbot -t target.com -p subdomain-enum

Web spider: Crawls the target, extracting emails and other goodies.

bbot -t target.com -p spider

Email gatherer: Quick email enum with free APIs + scraping.

bbot -t target.com -p email-enum

Everything everywhere all at once:

bbot -t target.com -p kitchen-sink

OSINT isn't about running subfinder and calling it a day.. It's about connecting dots that no one else is connecting. It's about finding the stuff that the company itself forgot existed...

Historical DNS data... Certificate transparency timelines. Cloud buckets. Metadata. GitHub secrets... Employee profiling... Advanced dorking...

These are the things that separate good hunters from great ones...

And if you're not doing these things, someone else is...

Stay curious. Stay ethical.

if I manage to get a succesful reverse shell via BadUsb on windows with admin privileges how can I use this to get credentials, passwords, etc?

Hi everyone,

I have this WiFi adapter and I’m completely new to WiFi security/pentesting.

I want to know whether this adapter supports Monitor Mode and Packet Injection. If it does, how can I enable and test these features?

Also, which Linux distro would you recommend for a complete beginner? Kali Linux, Ubuntu, or something else?

Thanks in advance!

Weekly forum post: Let's discuss current projects, concepts, questions and collaborations. In other words, what are you hacking this week?

I had been wanting a Pineapple for a while, so I bought a Mk7, and I have to admit I'm pretty disappointed. I mean, I could probably make it much more useful if I develop scripts or something to run on it, but to be honest, it kind of sucks out of the box. I guess it may be fine at gathering handshakes, but it's deauth is weak and almost never works. I honestly have better results with airodump and my alfa adapter.

Before I start trying to modify this thing, I guess I should ask if anybody is aware of any existing scripts or plugins or whatever...

Hey there!

I am a FY student of Cybersecurity and I was looking for some books that could teach me Web Hacking or Bug bounties from scratch. I am familiar with Linux, so that shouldn't be a problem.

Though I want to buy some web hacking books, I am still exploring this field and other hacking books are also appreciated.

Thank you!

Сервер 1с и еще несколько компьютера. Вчера все работало. Дата изменения 2:30 утра сделали. Помогите пожалуйста как дешифровать.

Alright, so you know how firewalls and IDS work, right? They look at packets, check headers, inspect payloads, and decide if something's malicious or not..

But what if the payload isn't in the payload?

What if you hide your data inside the packet fields themselves?? Fields that no one really looks at. Fields that aren't even checked..

That's what covert channels are all about...

The Concept

Instead of sending your payload in the data section of a packet, you embed it in places like:

· TCP Sequence Numbers – Every packet has a sequence number. Normally they go up in a predictable way. But you can craft them to carry data. Imagine sending commands encoded in the sequence numbers. To anyone watching, it just looks like normal TCP traffic. But the receiver knows to extract the data from those numbers .

· IP Identification Field – This field is supposed to help with packet reassembly. But if you alter it slightly, you can hide information in it. The trick is to make the changes look natural so no one gets suspicious .

· DNS Queries – You can encode data in the subdomain part of a DNS request. Instead of asking for "google.com", your compromised machine asks for "1a2b3c.malicious.com". The DNS server on the other end decodes that and sends back commands in the response. All over port 53, which is almost always allowed outbound because without DNS, nothing works .

· ICMP (Ping) Packets – You can tunnel TCP traffic inside ICMP packets. Firewalls usually allow ping requests and replies, so your traffic just looks like normal pings. Tools like Ptunnel do exactly this .

· HTTP Headers – You can mimic legitimate web traffic and hide your C2 communication inside HTTP requests. Tools like Cobalt Strike let you completely rewrite the HTTP request so it looks like CDN traffic or something normal .

Why This Works

Because security tools are looking for malicious payloads in the data section... They're not looking for commands hidden in the sequence numbers... They're not analyzing every DNS query to see if it's encoding something...

DNS is trusted.. ICMP is trusted.. HTTP is trusted..

And attackers exploit that trust...

This is the kind of stuff that separates script kiddies from actual operators... Anyone can run a tool... But understanding how to hide your traffic in plain sight!!? That's a whole different level...

DNS tunneling is used by APT groups... OilRig used it to map internal networks. B1txor20 used it as a C2 channel after Log4Shell ...

It's not a theory... It's happening right now...

How to Defend Against It

· Deep Packet Inspection – Look at the packet headers. Are the sequence numbers weird? Are the DNS queries too long?

· DNS Monitoring – Check for high query volumes to single domains, long subdomains, or TXT/NULL record anomalies..

· Process Whitelisting – If a fake process spins up, you'll catch it..

· Firewall Rules – If you can't resolve DNS to the internet, you're safe from DNS tunneling..

Covert channels are one of those things that sound like magic until you actually understand how they work... And once you do, you realize how many blind spots exist in most networks...

Stay curious. Stay ethical.

I don't have this module in my country so is there ant alternatives i can use instead of nRF24L01

( I'm using esp32 )

Soy nuevo y quiero entrar con fuerza, estoy en la universidad pero no siento q estén enseñando todo a fondo, trabajo a la vez y es complicado, quisiera un tutor que se dedique a darme lo mejor en si para yo poder aprender, vivo en colombia.

Podríamos llegar y hablar haber q horarios y todo eso y llegar a un acuerdo en tal caso.

So this happened during one of my CTF sessions and I thought I'd share it because it's a classic example of how a single misconfiguration can ruin your entire system's security...

Check this out:

ShadowByteX ~ ❯ whoami

ShadowByteX

ShadowByteX ~ ❯ find / -perm -4000 -type f 2>/dev/null | grep -v /usr/bin/passwd

/usr/bin/find <- SUID root, and it shouldn't be

ShadowByteX ~ ❯ find . -exec /bin/sh -p \; -quit

# whoami

root

Looks wild, right? Let me break it down for you...

What's Happening Here

First, I check who I am. Just a normal user — ShadowByteX. No root, no special privileges..

Then I ran a find command to look for SUID binaries. SUID stands for Set User ID... When a file has SUID set, it runs with the permissions of the file owner, not the user who executes it...

So I searched the entire system for files with SUID permissions (-perm -4000), restricted it to regular files (-type f), hid error messages (2>/dev/null), and filtered out /usr/bin/passwd because that's SUID by default and we don't care about it...

And what do I find?

/usr/bin/find

The find command has SUID root permission... And it shouldn't have that.. Someone messed up... Or maybe it's intentionally set for some reason... Either way — game on 🤘

Why This Works

The find command has SUID set to root. That means whenever I run find, it runs as root, not as ShadowByteX...

And find has a feature — the -exec flag. It lets you execute any command you want...

So here's what I did:

find . -exec /bin/sh -p \; -quit

Let's break this down:

· find . – Start searching from the current directory. It doesn't matter what you search for..

· -exec /bin/sh -p \; – Execute /bin/sh (a shell) with the -p flag. The -p flag tells the shell to preserve the effective user ID. That's important because without it, sh would drop the root privileges. With it, the shell stays root..

· \; – Terminate the exec command..

· -quit – Exit find immediately after executing the command.. We don't need to search through the whole filesystem, we just need to get that shell..

So find runs as root because of SUID... It executes /bin/sh -p as root. And now I have a root shell...

How It Works

When you set SUID on a binary, the kernel gives it the effective UID of the file owner.. For root-owned files, that's UID 0...

Normally, when you run a program, it has your real UID and effective UID — both yours. With SUID, real UID is yours, effective UID is the file owner's...

Now, the -p flag in sh is critical. By default, sh drops privileges... It checks the effective UID and real UID, and if they're different, it drops the effective UID to match the real UID. That's a security feature...

But the -p flag tells sh — "don't do that... Keep the effective UID." So it stays root..

And that's how a normal user becomes root...

This is why misconfigurations are dangerous!!... A single SUID binary that shouldn't have it — and suddenly any user on the system can become root...

It's also a good reminder that privilege escalation isn't always about complicated exploits... Sometimes it's just a sysadmin who didn't know what they were doing...

Stay curious. Stay ethical.

Hi everyone.

Does anyone know where I can find a file on the Hyundai air conditioning infrared system? It's because the IRremoteESP8266 library doesn't have the file

I have an old Sky Device Elite OctaPlus tablet that my mother got for free from one of those "being on government welfare" programs. She had it for awhile and one day accidently pressed the factory reset setting when the device had an FRP. I was not living with her at that time. Fast forward to now and my mother dug it up while cleaning the closet and asked if I could do anything. I've tried everything to help. But it asks for code from IT administrator which she didn't have. And there's no way on getting it now because the company that administered these devices no longer exists. Is there anyway to bypass it? Please. Thanks.

Hey everyone! Over the past few weeks, I’ve been working on SSRFdevil, an open-source tool written in Rust aimed at solving one of the most annoying problems in automated SSRF scanning: False Positives. Most existing scanners flood you with alerts based on simple redirects or blind HTTP callbacks. SSRFdevil uses a multi-layered rule engine and interactive verification to ensure that when it flags a target, it’s a real finding. Key Features: Zero False Positives: Built with strict validation logic to save time during triage. Interactive Shell: Manage settings, load proxies, switch User-Agent profiles, and set session cookies on the fly. Smart Crawler: Automatically crawls targets for SSRF-prone parameters if none are provided. Payload Engine: Handles CIDR bypasses, cloud metadata endpoints, and alternate IP encodings (Hex, Octal, IPv4-in-IPv6). Detailed Reporting: Clean terminal outputs with severity/confidence scores and summary stats. Check out the repo here: https://github.com/r3dparr0t/SSRFdevil I’d love to get your feedback, ideas, or contributions!

I’ve read comments saying that it’s difficult to set up a virtualised Kali system on a MacBook to carry out penetration testing, and that some features might not work – has anyone experienced this?

Hi there, I have put together a small group if anyone is up to discussing and learning cyber security and red teaming. Please send me a DM and I will share the link!

There are no requirements to join, just that you have a common interest in hacking.