DEV Community: Arashad Dodhiya

Reconnaissance Is Not Hacking (And That's Why It's So Powerful)

Arashad Dodhiya — Sun, 31 May 2026 19:44:27 +0000

When most people hear the word "cybersecurity," they imagine someone furiously typing commands in a dark room trying to break into a system.

Movies have done a great job convincing us that hacking starts with attacking.

In reality, it usually starts with looking.

A lot of looking.

Imagine You're Moving Into a New City

Suppose you're visiting a city you've never been to before.

Before you rent a house, what do you do?

You check:

The neighborhood
Nearby roads
Hospitals
Schools
Traffic
Safety

Nobody would call this "breaking into the city."

You're simply gathering information.

Cybersecurity works the same way.

Reconnaissance Is Just Information Gathering

Before security teams assess a system, they first need answers to basic questions:

What assets exist?
Which websites belong to the company?
What technologies are being used?
Which systems are exposed to the internet?

You can't protect or assess something you don't even know exists.

Think Like a Security Consultant

Imagine a company hires you and says:

"Tell us how secure we are."

You wouldn't immediately start testing systems.

You'd first want a map.

Something like:

Company
│
├── Website
├── API
├── VPN
├── Email Server
└── Cloud Infrastructure

This process is called asset discovery.

Before security comes visibility.

Where Threat Modeling Fits In

Now that you have a map, you can start asking questions.

Which systems are most important?
What happens if they fail?
Who might target them?
What are the possible risks?

This is called threat modeling.

It's less about finding vulnerabilities and more about understanding what could go wrong.

Security Assessments Start Here

A security assessment without reconnaissance is like inspecting a building without knowing how many rooms it has.

You might check the front door.

But what about the side entrance?

The roof?

The basement?

The forgotten storage room nobody uses anymore?

Reconnaissance helps ensure you're looking at the whole picture.

The Biggest Myth

Many people think reconnaissance is the first step of hacking.

That's not entirely true.

Reconnaissance is the first step of understanding.

Attackers use it.

Defenders use it.

Consultants use it.

Security teams use it.

Because before you can secure, test, or improve anything...

You need to know what's there.

Final Thought

The best cybersecurity professionals aren't always the ones who know the most exploits.

They're often the ones who ask the best questions.

And most of those questions start with:

"What are we actually looking at?"

Certificate Transparency Logs: The Internet's Public Diary

Arashad Dodhiya — Sun, 31 May 2026 19:33:03 +0000

Imagine if every time someone built a new house, they were required to register it in a public record book that anyone could read.

Sounds strange, right?

But that's essentially how modern HTTPS certificates work.

Every day, thousands of organizations create new websites, APIs, cloud environments, and internal services. To secure these systems, they obtain SSL/TLS certificates.

What many people don't realize is that these certificates are often recorded in publicly accessible logs.

These records are called Certificate Transparency (CT) Logs.

And for security researchers, they can be a goldmine of information.

The Problem That Created Certificate Transparency

Years ago, there was a major trust problem on the internet.

Browsers trusted Certificate Authorities (CAs) to issue certificates correctly.

For example, if someone wanted a certificate for:

example.com

a trusted CA would verify ownership and issue the certificate.

Simple enough.

But what if a CA accidentally issued a certificate to the wrong person?

Or worse...

What if a certificate was issued maliciously?

The website owner might never know.

The internet needed a way to make certificate issuance visible.

The solution was surprisingly simple:

Make certificate issuance public.

What Are Certificate Transparency Logs?

Certificate Transparency Logs are public, append-only records of issued SSL/TLS certificates.

Think of them as:

The Internet's Public Diary

Every time a certificate is issued, information about it is published to public logs.

For example:

api.company.com
vpn.company.com
mail.company.com

may all appear in Certificate Transparency Logs after certificates are issued.

The goal is transparency.

Nobody can secretly create certificates without leaving evidence behind.

A Real-World Analogy

Imagine a city where every new building permit must be publicly posted on a giant bulletin board.

Anyone can walk by and see:

New Warehouse
New Office
New Shopping Center

Certificate Transparency works in a similar way.

Whenever organizations create new internet-facing services and obtain certificates, they leave traces in these public records.

Why Are Certificates Public?

The answer is trust.

Without transparency:

CA → Issues Certificate
Nobody Knows

With transparency:

CA → Issues Certificate
Certificate Logged Publicly
Everyone Can Verify

This creates accountability.

Organizations can monitor for unauthorized certificates.

Browsers can verify legitimacy.

Researchers can identify suspicious activity.

The entire ecosystem becomes more trustworthy.

What Information Is Visible?

Certificate Transparency Logs can reveal:

Subdomains
Certificate Issuer
Issue Dates
Expiration Dates
Domain Names

For example, a company may publicly advertise only:

www.company.com

But CT logs may reveal:

api.company.com
dev.company.com
staging.company.com
vpn.company.com

Suddenly, you have a much clearer picture of the organization's infrastructure.

Why Security Researchers Love CT Logs

In cybersecurity, visibility is everything.

One of the first questions during reconnaissance is:

What assets exist?

Organizations often have hundreds or thousands of internet-facing systems.

Many of these aren't linked from the main website.

However, if certificates were issued for them, CT logs may reveal their existence.

This makes Certificate Transparency one of the most valuable passive reconnaissance sources available today.

Passive Reconnaissance: Learning Without Touching

One reason CT logs are so powerful is that they're passive.

Instead of directly interacting with a target:

Researcher → Target

the researcher simply examines public records:

Researcher → Public Logs

The target is never contacted.

No requests are sent.

No alerts are triggered.

It's similar to reading public records at a city office rather than knocking on someone's door.

The Benefits of Certificate Transparency

1. Detecting Unauthorized Certificates

Organizations can monitor CT logs for certificates issued in their name.

If a suspicious certificate appears:

fake-company.com

vpn.company.com

they can investigate immediately.

2. Increased Trust

Certificate Authorities become more accountable.

Everything they issue becomes publicly visible.

3. Improved Security Monitoring

Security teams can track infrastructure changes.

New services often appear in CT logs before they are publicly announced.

4. Faster Incident Detection

Unexpected certificates can indicate:

Misconfigurations
Shadow IT
Forgotten assets
Potential compromise

The Privacy Debate

Transparency improves security.

But it also creates challenges.

Consider a company building a secret project:

project-phoenix.company.com

Before launch, they obtain a certificate.

The moment that certificate is logged, the subdomain may become visible to anyone monitoring CT logs.

This means transparency can sometimes reveal infrastructure that organizations would prefer to keep private.

The Risks of Certificate Transparency

Infrastructure Discovery

CT logs can expose:

dev.company.com
staging.company.com
internal-api.company.com

These systems may not be intended for public discovery.

Attack Surface Expansion

Every discovered asset becomes another system that must be secured.

Attackers and defenders often see the same information.

The difference is what they do with it.

Information Leakage

Subdomain names sometimes reveal:

Internal project names
Business initiatives
Technologies
Development environments

A poorly chosen subdomain can unintentionally disclose sensitive information.

Certificate Transparency and Modern Reconnaissance

Years ago, discovering hidden infrastructure required significant effort.

Today, public data sources reveal a surprising amount of information.

Certificate Transparency Logs have become one of the most valuable resources for:

Security Researchers
Blue Teams
Asset Discovery Programs
Bug Bounty Hunters
Attack Surface Management Teams

They help answer a fundamental cybersecurity question:

What exists?

And in security, that's often the most important question of all.

Final Thoughts

Certificate Transparency Logs were created to make the internet safer and more trustworthy.

They succeeded.

But they also created something unexpected:

A public historical record of internet infrastructure.

For defenders, CT logs provide visibility.

For researchers, they provide discovery.

For organizations, they provide accountability.

And for anyone learning cybersecurity, they offer a fascinating reminder that sometimes the most valuable information isn't hidden at all—it's sitting in a public diary that anyone can read.

Key Takeaways

Certificate Transparency Logs are public records of issued SSL/TLS certificates.
They were created to improve trust and accountability.
Security researchers use them to discover internet-facing assets.
Organizations use them to monitor unauthorized certificates.
CT logs provide enormous security benefits but can also reveal infrastructure details.
Understanding CT logs is fundamental to modern reconnaissance and attack surface management.

The Castle Analogy: Understanding Attack Surface Through Subdomains

Arashad Dodhiya — Sun, 31 May 2026 13:11:45 +0000

Most beginners think a company's website is just a single website.

For example:

company.com

Simple, right?

Not exactly.

In reality, modern organizations are more like massive castles with dozens of gates, towers, secret passages, storage rooms, and sometimes even forgotten buildings that nobody remembers anymore.

Understanding this idea is one of the most important concepts in cybersecurity: Attack Surface.

Let's explore it through a castle.

Imagine a Castle

Suppose you're standing outside a medieval castle.

From the outside, you can only see the main entrance.

Castle
│
└── Main Gate

If someone asked you how many ways there are to enter the castle, you might answer:

"Just the main gate."

But that's rarely true.

A large castle may also have:

Castle
│
├── Main Gate
├── Side Gate
├── Merchant Entrance
├── Guard Entrance
├── Secret Tunnel
├── Storage Building
└── Watch Tower

Every additional entry point increases the number of places that must be protected.

This is exactly how modern organizations work.

The Website You See Is Usually Just the Main Gate

When you visit:

www.company.com

you're usually seeing the main entrance.

Most people stop there.

But security researchers know that there are often many more systems behind the scenes.

For example:

www.company.com
api.company.com
mail.company.com
vpn.company.com
dev.company.com
staging.company.com

These are called subdomains.

Think of them as different buildings or entrances inside the castle.

What Is Attack Surface?

Attack Surface is simply the total number of places that could potentially be interacted with, accessed, or misconfigured.

A small attack surface:

Castle
│
└── Main Gate

A larger attack surface:

Castle
│
├── Main Gate
├── Side Gate
├── Secret Tunnel
├── Watch Tower
├── Storage Room
└── Guard Entrance

More entrances don't automatically mean insecurity.

However, they do mean there are more things that must be managed and monitored.

The Forgotten Tower Problem

Now imagine a castle that has been expanding for twenty years.

Every new king builds something.

Year 1  -> Main Gate
Year 5  -> Watch Tower
Year 8  -> Storage Building
Year 12 -> Secret Passage
Year 15 -> Merchant Entrance
Year 20 -> New Tower

Over time, some structures stop being used.

Maybe nobody visits the old watch tower anymore.

Maybe the storage building is abandoned.

Maybe everyone forgot the secret passage even exists.

The same thing happens in technology.

Developers create systems such as:

dev.company.com
test.company.com
old.company.com
legacy.company.com

Projects end.

Teams move on.

Employees leave.

The systems remain.

Why Attackers Look Beyond the Main Website

Imagine you're trying to enter a castle.

Would you attack the heavily guarded main gate?

Or would you look for:

An unlocked side door
A forgotten tunnel
An abandoned watch tower

Most people would choose the easier path.

Attackers think the same way.

The main website is often heavily monitored and regularly updated.

Forgotten systems may not be.

This is why security professionals spend significant time identifying all assets that belong to an organization.

Real-World Example

A company may actively maintain:

www.company.com

with the latest security updates.

However, there could also be:

old.company.com

running software that hasn't been updated in years.

From a business perspective, it may have been forgotten.

From an attacker's perspective, it may be the most interesting system the company owns.

Visibility Comes Before Security

One of the most important lessons in cybersecurity is:

You cannot secure what you don't know exists.

Before defending systems, organizations must first discover and inventory them.

Security teams often perform asset discovery to answer questions such as:

What systems do we own?
Which services are publicly accessible?
Which environments are still active?
Which systems should be retired?

Without visibility, security becomes guesswork.

The Modern Castle

Today's organizations are no longer simple websites.

They are ecosystems.

A single company might have:

www.company.com
api.company.com
auth.company.com
mail.company.com
vpn.company.com
staging.company.com
dev.company.com
blog.company.com

Each one serves a purpose.

Each one must be maintained.

Each one becomes part of the organization's attack surface.

The challenge isn't building the castle.

The challenge is remembering every door you've ever added.

Final Thoughts

When people first learn cybersecurity, they often focus on vulnerabilities.

But before vulnerabilities come assets.

Before assets come visibility.

And before visibility comes understanding how organizations are structured.

The next time you visit a website, don't think of it as a single page on the internet.

Think of it as a castle.

Because in cybersecurity, the most interesting discoveries are rarely behind the main gate-they're usually hidden somewhere deeper inside the walls.

If WhatsApp Can Edit Messages, Why Can't Gmail Edit Emails?

Arashad Dodhiya — Sun, 31 May 2026 05:47:06 +0000

A few days ago, I was editing a message on WhatsApp after sending it and a random question came to mind:

If WhatsApp lets us edit messages, why can't Gmail let us edit emails after they're sent?

At first, it feels like both should work the same way. After all, both are sending text over the internet.

But once I started digging into it, I realized the answer has a lot to do with how these systems are designed and even touches on some interesting cybersecurity concepts.

WhatsApp and Email Are Not the Same Thing

Most people think of WhatsApp messages and emails as the same type of communication.

They're not.

When you send a WhatsApp message, Meta controls:

The app on your phone
The server in the middle
The app on the recipient's phone

Because everything is part of the same ecosystem, WhatsApp can update a message after it has been sent.

When you edit a message, WhatsApp isn't magically changing history. It simply tells the server:

"Update message #123 with this new content."

The recipient's app then receives the updated version and displays the little "Edited" label.

That's why message editing works.

Email Works More Like Physical Mail

Email follows a completely different model.

Imagine sending a physical letter.

Once the letter reaches the recipient's mailbox, you can't walk into their house and replace it with a new version.

Email works in a similar way.

Let's say:

you@gmail.com → friend@yahoo.com

When Gmail sends that email, Yahoo receives its own copy.

At that point, Google no longer controls the message.

The email has already been delivered.

That's why Gmail cannot simply "edit" the email afterward.

Then What About Gmail's "Undo Send"?

This was the most surprising part for me.

Many people think Gmail recalls an email after it has been sent.

It doesn't.

What actually happens is much simpler.

When you click Send, Gmail waits a few seconds before delivering the message.

If you click Undo, Gmail simply cancels the delivery before the email leaves Google's servers.

The email was never truly sent.

No recall. No editing. Just a delayed send.

The Cybersecurity Side of This

Now imagine if email editing actually existed.

An attacker could:

Send a harmless email.
Let it pass security checks.
Edit it later into a phishing email.

For example:

Original email

Meeting scheduled for tomorrow.

Edited version

Your account has been suspended.
Click here to reset your password.

That would create serious security problems.

Email is often used for:

Contracts
Business communication
Audit records
Legal documentation

Because of this, email systems are designed to preserve the original message once it's delivered.

In cybersecurity, this principle is called immutability—once something is recorded, it shouldn't silently change later.

The Real Difference

The answer isn't really about WhatsApp versus Gmail.

It's about control.

WhatsApp

Centralized platform
One company controls everything
Editing is easy

Email

Distributed system
Multiple organizations own different servers
Editing becomes difficult and potentially dangerous

The moment data leaves a system you control and enters someone else's system, your ability to modify it usually disappears.

And that's why you can edit a WhatsApp message but not an email.

Have you ever wondered how many everyday apps work differently behind the scenes even though they look similar on the surface? This was one of those moments for me.

Starting My Cybersecurity Learning Journey 🚀

Arashad Dodhiya — Sun, 31 May 2026 04:37:52 +0000

Starting My Cybersecurity Learning Journey 🚀

Hey everyone 👋

I'm Arashad, and this is my first post on Dev.to.

Over the last few months, I've been diving deep into cybersecurity. What started as simple curiosity quickly turned into late nights reading documentation, setting up labs, breaking things, fixing them, and asking myself a lot of questions.

One thing I've learned is that cybersecurity is huge.

There are so many topics-networking, web security, cryptography, operating systems, authentication, reconnaissance, cloud security, malware analysis, and much more. Sometimes it feels like the deeper you go, the more you realize how much there is still to learn.

That's exactly why I'm starting this blog.

Why I'm Writing

I'm not an expert.

I'm a learner.

And honestly, I think that's a good thing.

As I study different concepts, I often find explanations that are either too complex or assume you already know a lot of background information. So whenever I finally understand something, I write it down in simple words.

Instead of keeping those notes to myself, I thought I'd share them publicly.

Maybe they'll help someone who's learning the same things I am.

What You'll Find Here

Most of my posts will focus on:

Cybersecurity fundamentals
Networking concepts
Reconnaissance and enumeration
Nmap and scanning techniques
Web application security
Authentication and authorization
Cryptography concepts
Vulnerability research
Security tools and labs
Beginner-friendly explanations

My goal is simple:

Learn. Build. Share. Repeat.

What Makes This Blog Different?

I won't be pretending to know everything.

If I learn something interesting, I'll write about it.

If I make mistakes, I'll correct them.

If I discover a better explanation, I'll share it.

Think of this blog as a public notebook documenting my journey through cybersecurity.

What's Coming Next?

Some topics I'm currently learning and planning to write about:

Why Hosts Block ICMP but Nmap Still Finds Them
Encoding vs Hashing vs Encryption
NTLM Authentication Explained
Kerberoasting for Beginners
NoSQL Injection Basics
HTTP Request Smuggling Explained
Reconnaissance Methodology for Beginners

Let's Connect

If you're also learning cybersecurity, feel free to follow along.

And if you're experienced in the field, I'd love to learn from your feedback and suggestions.

Thanks for stopping by and reading my first post.

Here's to learning something new every day. 🍻

See you in the next post.

Linux for Cybersecurity: The Commands That Actually Matter (Reality Check)

Arashad Dodhiya — Wed, 24 Dec 2025 04:17:08 +0000

When I started learning cybersecurity, Linux felt overwhelming.

People talk about “master Linux” like you need to memorize hundreds of commands before you can do anything useful. That mindset almost made me quit early.

Reality:
You don’t need all Linux commands.
You need the right ones, and you need to understand why they matter from a security point of view.

This post is a practical breakdown of the Linux commands that actually matter for cybersecurity beginners — not for flexing in terminals, but for real understanding.

Navigation & File System (You Can’t Secure What You Can’t See)

Before hacking anything, you need to know where things live.

Commands that matter

pwd
ls
cd
tree

Why this matters in security

Config files, logs, credentials — everything is just files
Attackers look for interesting locations, not random commands
You need to move fast and confidently inside unknown systems

Security mindset

If you don’t understand the Linux filesystem, you’ll never understand privilege escalation or misconfigurations.

Reading Files (Logs Are Gold)

Commands that matter

cat
less
more
head
tail

Why this matters

Logs reveal authentication attempts
Config files reveal secrets and bad permissions
You’ll constantly inspect:
- /etc/passwd
- /etc/shadow
- /var/log/auth.log
- .env files

Pro tip

tail -f /var/log/auth.log

This lets you watch logins in real time — very useful for learning.

File Permissions & Ownership (This Is Where Most Vulnerabilities Live)

Commands that matter

ls -l
chmod
chown
id
whoami

Why this matters

Misconfigured permissions = easy privilege escalation
You must understand:
- Read (r)
- Write (w)
- Execute (x)
Who owns what — and who shouldn’t

Security example

If a sensitive script is writable by everyone:

-rwxrwxrwx

That’s a huge vulnerability.

Searching for Interesting Files (Attackers Don’t Browse — They Search)

Commands that matter

find
grep
locate

Real use cases

find / -perm -4000 2>/dev/null

👉 Finds SUID binaries (very important for privilege escalation)

grep -R "password" /etc

👉 Finds hardcoded secrets (common beginner mistake)

Processes & Services (What’s Running = What Can Be Attacked)

Commands that matter

ps
top
htop
systemctl
service

Why this matters

Running services expose attack surfaces
Misconfigured services = easy targets
You need to see:
- What’s running
- Under which user
- With what permissions

Example

ps aux

Shows everything running — attackers love this.

Networking Basics (Your First Recon Tool Is Linux Itself)

Commands that matter

ip a
ip route
ss
netstat
ping
curl
wget

Why this matters

Before Nmap, understand local networking
Check:
- IP addresses
- Open ports
- Listening services

ss -tuln

👉 Shows open ports without fancy tools

User & Login Information (Who Has Access?)

Commands that matter

who
w
last
su
sudo

Why this matters

See who’s logged in
Identify admin users
Detect suspicious activity

last

👉 Shows login history (great for blue team learning)

Package Management (Attackers Love Outdated Software)

Commands that matter

apt
apt update
apt upgrade
dpkg

Why this matters

Old packages = known vulnerabilities
Knowing what’s installed helps:
- Attackers find exploits
- Defenders patch systems

Commands You Don’t Need (At the Beginning)

You can safely ignore (for now):

Advanced shell scripting
Kernel compilation
Custom init systems
Exotic filesystem tuning

Learn depth, not breadth.

Final Reality Check

Cybersecurity Linux is not about:

Memorizing commands
Showing off terminal tricks
Using Kali tools blindly

It’s about:

Understanding systems
Reading configurations
Spotting mistakes
Thinking like an attacker

If you master these commands and the reasons behind them, you’ll be far ahead of most beginners.

What I’m Doing Next

Practicing on real labs
Reading logs daily
Breaking small systems safely
Learning why vulnerabilities exist

If you’re learning cybersecurity too - slow down, learn Linux properly, and don’t chase tools too early.