Every technique an attacker uses is available to a defender; the only thing separating the two is written permission. Here is what that permission has to say, what an engagement actually involves, and how to build the skill without committing a crime.

Key takeaways
  • Ethical hacking is defined by written permission, not by technique or intent. The tools and commands are identical to an attacker's.
  • The law asks one question first: were you authorised. Your motive is something a court weighs afterwards, if at all.
  • An engagement is mostly reconnaissance and reporting. Exploitation is usually the smallest part of the work.
  • Passive testing reads what a system already publishes and can be pointed at anything. Active testing sends crafted input, can break production, and needs a signed scope.
  • Practise in a lab, on a CTF, or inside a bug bounty scope. Testing a live site you do not own is an offence whether or not you meant well.

Permission is the whole difference

There is no technical distinction between ethical hacking and the other kind. The same port scanner, the same request, the same payload. A penetration tester and an intruder can run identical commands against identical software and produce identical output. What separates them is a document.

That is not a technicality, and it is worth being blunt about it, because a great deal of writing on this subject implies the difference is attitude or intent. It is not. Under the Computer Misuse Act in the UK and the Computer Fraud and Abuse Act in the United States, the offence is access without authorisation. Your motives are, at best, something a court considers after it has decided you were unauthorised.

So the first skill of an ethical hacker is not technical. It is getting the scope in writing before touching anything.

What authorisation has to say

A useful authorisation is specific enough that both sides know what happens if something breaks. At minimum it names:

  • The targets. Domains, IP ranges, applications, and explicitly what is out of scope. "Our website" is not a scope; a third-party payment iframe on your checkout page belongs to somebody else, and testing it is testing them.
  • The window. When testing may run, and who is awake if a service falls over.
  • The techniques permitted. Denial-of-service testing, social engineering and physical access are each their own conversation. Assume none of them unless named.
  • The handling of data. What happens if you reach real customer records. The answer should be "stop, record that you could, do not exfiltrate".
  • Who to call. A named person, reachable during the window.

Cloud providers add a layer: testing infrastructure you rent still touches hardware you do not own, and AWS, Google Cloud and Azure each publish their own rules about what is permitted without notice. Read them before scheduling.

The five phases, and where most of the work is

Engagements are usually described in five phases. The proportions surprise people who expect the job to be mostly exploitation.

  1. Reconnaissance. What exists, what it runs, who operates it. Mostly public information: DNS records, certificate transparency logs, job adverts naming an internal stack.
  2. Scanning and enumeration. Turning "this host exists" into "this host runs that version of that software". Our guide to vulnerability scanning covers how that matching works and where it is wrong.
  3. Gaining access. The part everybody pictures, and typically the smallest.
  4. Maintaining access. Proving persistence is possible, because a real intruder would not leave.
  5. Reporting. The only deliverable. An unreported finding helped nobody, and a report that says "critical: SQL injection" without the request that triggered it and the fix to apply is a bill, not a service.

Reconnaissance and reporting take most of the time. If that sounds unglamorous, it is worth knowing before choosing the career.

Two different jobs: passive and active

Security testing splits along a line that matters more than the black-hat and white-hat labels.

Passive testing reads what a system already tells the world. A browser making an ordinary request, a DNS lookup, a TLS handshake, the response headers that come back. It cannot break anything because it does nothing a visitor does not already do. That is why it can be pointed at a supplier, a competitor or a link somebody emailed you.

Active testing sends input designed to provoke a response the developer did not intend: a quote in a form field, a traversal sequence in a path, an oversized header. It finds a class of problem that passive work cannot see, and it can take a production system down. It needs the written scope above.

Most real compromises begin with something the passive half can already see: an expired certificate, a missing security header, a .git directory served to the public, a JavaScript library with a published CVE, an out-of-date plugin. You can check all of those on any site you are responsible for with our website vulnerability scanner, which runs 179 read-only checks and sends no payloads at all. Our methodology page lists every request each scanner makes, so the claim is checkable rather than promised.

How to practise without committing a crime

The single most common way into trouble is scanning something you do not own "just to see". Here is the legal route to the same skills, roughly in order of how quickly you will learn.

  • Build a lab. A virtual machine running deliberately vulnerable software: OWASP Juice Shop, DVWA, Metasploitable. Your own hardware, no scope document needed.
  • Capture the flag. Hack The Box, TryHackMe and PicoCTF are designed to be attacked. The exercises are contrived, which is the point: you learn the technique before the noise.
  • Bug bounty programmes. HackerOne, Bugcrowd and the many self-hosted programmes publish a scope you may test, which is authorisation in the form the law recognises. Read it twice; the payout is not the risky part, the boundary is.
  • Your own estate. Whatever you already run is fair game, and is the only target where you will feel the difference between a finding and an outage.

What you must not do is test a live third-party site because its security looks bad. Unsolicited "I found a vulnerability" emails have been prosecuted, and the fact that you were helpful is not a defence. If you find something by accident, our responsible disclosure page sets out the route that does not end badly.

The toolkit

The tools are not the skill, but they are the vocabulary.

  • Reconnaissance: nmap for hosts and ports, Amass and subfinder for subdomains, Shodan for what is already indexed.
  • Web applications: Burp Suite or OWASP ZAP as the intercepting proxy, which is where most of the actual thinking happens.
  • Exploitation: Metasploit for known vulnerabilities, sqlmap for injection.
  • Passive reconnaissance of your own estate: the free tools on this site cover TLS configuration, security headers, SPF, DKIM and DMARC and WordPress plugins and core. Our full tool list shows what each one answers.

For an estate rather than a page, the paid plans point every scanner at one domain in a single pass and crawl the whole site rather than a sample — the pricing page explains what a full audit covers. The free scanners are the same checks; the difference is scale.

Certifications, honestly

They open doors and they prove less than their marketing suggests. The OSCP is respected because it is a practical 24-hour exam rather than multiple choice. The CEH is widely recognised by human resources departments and lightly regarded by practitioners. CREST and the UK's CHECK scheme matter if you want to test regulated infrastructure.

None of them substitute for a portfolio. A public write-up of a CTF you solved, or a CVE you reported responsibly, does more in an interview than a certificate number.

Frequently asked questions

Is port scanning illegal?

It depends where you are, and the honest answer is that it is unsettled. Some jurisdictions have treated an unauthenticated port scan as unauthorised access; others have not. Scanning something you do not own is a risk you are choosing to take, and "it was only a scan" has not always worked.

What is the difference between a vulnerability scan and a penetration test?

A scan is automated and finds known problems by matching versions and configurations. A penetration test is a person chaining findings into an actual compromise. A scan tells you the door is unlocked; a test tells you what is in the room. Most organisations need the scan running continuously and the test occasionally.

Can I become an ethical hacker without a degree?

Yes, and many of the best did not take one. What is not optional is demonstrable work: a lab, a write-up, a bounty report, a CVE.

Is it legal to scan my own website?

Yes. It is your system. Be aware that your hosting provider's terms may still say something about load, and that if your site shares infrastructure, aggressive testing can affect somebody else's tenancy.

Where to start today

If you own a site, start with what is already visible from outside it: run the website scanner against it, read the explanation behind every check it flags, and fix in the order the report gives you. That is the same reconnaissance an attacker begins with, and it costs nothing.

If you want the discipline rather than the checklist, our complete guide to security scanning is the longer route through the same ground.