Lesson 1 of 12

Introduction to Ethical Hacking

Discover what ethical hacking is and how it differs from malicious hacking. You will learn the mindset, methodology, and legal boundaries that define a professional penetration tester. This lesson sets the foundation for everything that follows in the course.

Learning Objectives — Deep Dive

Each objective below is broken down into plain English so you know exactly what you are learning, why it matters, and what you will be able to do when you are done. Mark each one complete as you work through the lesson.

0/4

In plain English

This is asking you to build a clear mental model of the concept — not just memorize a definition, but genuinely understand what it means, why it exists, and how it connects to everything else you are learning. When you can explain "ethical hacking and distinguish it from malicious hacking" in your own words to someone who has never heard of it, you have truly learned it.

Why this matters

This objective builds a foundational skill that every security professional uses regularly. Mastering it gives you the vocabulary, mental models, and practical ability to tackle more advanced topics with confidence — and to communicate clearly with both technical and non-technical colleagues.

Real-world analogy

Think of it like learning to drive. You do not need to understand how the engine works to drive safely, but knowing the basics helps you diagnose problems and avoid mistakes that could cause accidents. The same principle applies here — foundational knowledge prevents costly errors.

What you will be able to do

Apply this skill in a real lab environment, explain it clearly to a colleague or client, and use it as a building block for the more advanced techniques that come later in this course.

Beginner tip

Do not try to memorize everything at once. Read through the material once to get the big picture, then go back and work through the lab. The hands-on practice is what makes the concepts stick — passive reading alone will not get you there.

Introduction to Ethical Hacking · Objective 1 of 4

VIDEO

Loading video…

Navigate to HackerOne and explore public programs

Open your browser and go to hackerone.com/programs to browse real companies paying ethical hackers to find vulnerabilities. Click on a well-known program like Shopify or Twitter and read the full program page carefully. Notice how each program defines exactly what is in-scope, what is out-of-scope, and what vulnerability types they want reported. This is the foundation of ethical hacking: every action you take must be explicitly authorized by the target organization. A common beginner mistake is assuming that because a company has a bug bounty program, everything on their infrastructure is fair game — read the scope section word by word before touching anything.

open https://hackerone.com/programs

Read and annotate the scope section carefully

Within any program page, scroll to the Scope section and read every line before taking any action. In-scope assets are typically listed as specific subdomains, IP ranges, or mobile apps, while out-of-scope assets often include third-party services, employee email systems, and production databases. Write down the exact in-scope and out-of-scope boundaries in your notes before doing anything else. A common pitfall is testing an asset that looks related to the company but is not explicitly listed as in-scope — this can result in legal action even if your intent was good. When in doubt, send a message to the program asking for clarification rather than assuming.

Research the three hacker hat categories with real examples

Open a text editor and write definitions for white-hat, grey-hat, and black-hat hackers, then find one real-world news example of each category. White-hat: a security researcher who found a critical flaw in a bank and reported it through their bug bounty program. Grey-hat: a researcher who accessed a system without permission but then notified the company rather than exploiting it — still illegal despite good intentions. Black-hat: a criminal hacker who stole credit card data for financial gain. Understanding these distinctions matters because the same technical skill set can be used legally or illegally — the difference is entirely about authorization and intent, not technical capability.

Look up the Computer Fraud and Abuse Act (CFAA)

Search for 18 USC 1030 CFAA and read the key provisions on law.cornell.edu, paying particular attention to section (a)(2) which criminalizes accessing a computer without authorization to obtain information. Note that the CFAA does not require malicious intent — simply accessing a system you were not authorized to access is sufficient for prosecution, regardless of what you intended to do with the access. The maximum penalty for a first offense can be up to 5 years in federal prison, and repeat offenses can result in up to 10 years. Write down three specific actions that would violate the CFAA and three that would not, to test your understanding of where the legal line is drawn.

open https://www.law.cornell.edu/uscode/text/18/1030

Draft your personal ethics statement

Write a one-paragraph personal ethics statement that defines your boundaries as a security researcher, including three specific commitments. First, what you will always do: obtain written authorization before testing any system you do not personally own. Second, what you will never do: access data beyond the defined scope, even if you technically can reach it. Third, how you will handle discovered vulnerabilities: report them through proper channels and give the organization reasonable time to patch before any public disclosure. This exercise forces you to think through ethical edge cases before you encounter them in practice, when the pressure of the moment can cloud judgment. Revisit and update this statement as you gain experience.

Create a pre-engagement authorization checklist

Build a reusable checklist covering every item you need before starting any security engagement: written scope document signed by an authorized representative, specific IP ranges and domains listed explicitly, testing window with start and end dates, emergency contact information for the client, agreement on what happens if you find critical vulnerabilities during testing, and confirmation that the client has legal authority to authorize testing of all listed systems. A common pitfall is starting work before all parties have signed — verbal authorization is not sufficient and will not protect you legally if something goes wrong. Save this checklist as a template and make completing it a non-negotiable step before every engagement, no matter how small or informal.

Back to course Next Lesson