Learn Ethical Hacking series):Welcome to the Learn Ethical Hacking series -- a brand new chapter that builds on top of everything we've done in the Learn Python Series and the Learn Zig Series. If you've been following those, you already have a solid programming foundation. You know how to write scripts, handle network connections, manage memory, work with data structures... all that good stuff.
Now we're going to put that knowledge to a very different kind of use.
But hold on -- why would a programmer need to learn hacking?
Simple. Because the software YOU write -- and the software everyone else writes -- is under constant attack. And the only way to truly defend something is to understand how it breaks. You can't patch a hole you can't see. You can't secure a system you don't know how to compromise.
That's the entire philosophy of this series: offense informs defense.
Here's the single most important thing to understand about cybersecurity, and I'm going to put it in bold because you should tattoo this on your brain:
A defender must protect every possible entry point. An attacker only needs to find one.
Think about that for a second. If you're defending a web application, you need to make sure every input field is sanitized, every API endpoint validates authorization, every dependency is up to date, every configuration file has proper permissions, every server is patched, every password policy is enforced, every employee is trained not to click phishing links.
The attacker? The attacker needs exactly one of those things to fail.
This asymmetry is why breaches keep happening despite billions spent on security. It's not because defenders are stupid (well, sometimes it is ;-) ) -- it's because the game is fundamentally rigged in the attacker's favor.
In 2011, Lockheed Martin (yes, the defense contractor) published a framework that changed how we think about attacks. They called it the Cyber Kill Chain, and it breaks every attack into seven stages:
Reconnaissance -- the attacker researches the target. What technologies do they use? Who are their employees? What's their email format? What subdomains exist? This stage is mostly invisible to the defender.
Weaponization -- the attacker creates or acquires the tool for the job. Could be a modified PDF with an exploit, a phishing email template, a custom piece of malware, or just a known exploit for an unpatched service.
Delivery -- the weapon reaches the target. Phishing email, compromised website, malicious USB drive left in the parking lot, or even a direct connection to an exposed service.
Exploitation -- the vulnerability fires. The employee clicks the link. The buffer overflows. The SQL injection executes. The unpatched server surrenders.
Installation -- the attacker establishes persistence. A backdoor, a reverse shell, a scheduled task, a new user account. Something that survives a reboot.
Command and Control (C2) -- the compromised system phones home. Now the attacker has a remote connection into your network, often hidden inside normal-looking HTTPS traffic.
Actions on Objectives -- the attacker does what they came for. Steal data, encrypt files for ransom, move laterally to more valuable targets, or just sit quietly and observe.
The beauty of this model (from a defender's perspective) is that it gives you seven opportunities to detect and stop an attack. Break any link in the chain, and the attack fails. The ugly truth, though, is that most organizations only detect attacks at stage 7 -- after the damage is done. If they detect them at all.
Let me tell you about some of the biggest breaches in recent history and what kicked them off. You'd expect some kind of sophisticated zero-day exploit, right? Some James Bond level stuff?
Nope.
Target (2013) -- 40 million credit cards stolen. How did the attackers get in? Through an HVAC contractor. Target gave their heating and ventilation vendor network access for remote monitoring. The attackers phished the HVAC company, stole their Target credentials, and used those to reach the payment processing network. An air conditioning company brought down one of the largest retailers in the United States. Total cost: over $300 million.
Equifax (2017) -- 147 million people's social security numbers, birth dates, and addresses exposed. The cause? An Apache Struts vulnerability (CVE-2017-5638) that had a patch available two months before the breach. Equifax just... didn't apply it. Two months. For a known, actively exploited vulnerability. On a system holding the most sensitive data of half the US population.
SolarWinds (2020) -- arguably the most sophisticated supply chain attack in history. Russian intelligence compromised the build system of SolarWinds' Orion IT monitoring software. A malicious update was pushed to 18,000 organizations including the US Treasury, Department of Homeland Security, and Microsoft. The backdoor (called SUNBURST) was so carefully designed it waited 14 days before activating and mimicked legitimate Orion API calls. It took months to discover, and the full scope may never be known.
Colonial Pipeline (2021) -- the largest fuel pipeline in the US shut down for six days, causing fuel shortages across the East Coast. The entry point? A single compromised password for a VPN account that didn't have multi-factor authentication. One password. No MFA. The attackers (DarkSide ransomware group) used it to lock down the pipeline's billing systems, and Colonial paid $4.4 million in Bitcoin ransom.
You see the pattern? It's never the sexy stuff. It's unpatched software. It's reused passwords. It's third-party vendors with too much access. It's a missing checkbox for two-factor authentication.
And in 2025 and 2026? It's AI-generated code with security vulnerabilities baked right in, deployed by developers who trust the output because "the AI wrote it, it must be fine." We'll dedicate an entire episode to this -- the AI slop epidemic -- because it's creating attack surface at a scale the security industry has never seen before.
So if we're teaching people to hack... aren't we just training criminals?
No. And here's why.
The techniques are identical. The tools are identical. The knowledge is identical. What separates an ethical hacker from a criminal is exactly one thing: authorization.
An ethical hacker (also called a white-hat hacker, penetration tester, or security researcher) has explicit, written permission to test a system. They operate under a scope -- clear boundaries that define what they can and cannot touch. They report what they find. They help fix it.
A criminal hacker (black-hat) does the same things without permission. That's it. That's the difference. Same skills, opposite intent.
There's also a gray area -- gray-hat hackers who find vulnerabilities without authorization but disclose them to the vendor instead of exploiting them. The legality here varies enormously by jurisdiction. In some countries, even scanning a public web server without permission is technically illegal. In others, responsible disclosure is protected.
The legal frameworks you need to know about:
The bottom line: never test a system you don't own or have written authorization to test. "I was just looking" is not a defense. "I found a vulnerability and wanted to help" is not a defense. Get it in writing first.
Everything in this series will use controlled lab environments that you set up yourself. We'll build our own vulnerable targets. We'll break our own systems. That's the safe, legal, and professional way to learn.
If you've followed the Learn Python Series, you know how to script, automate, parse data, handle network connections. Those are pentesting fundamentals.
If you've followed the Learn Zig Series, you understand memory layout, stack vs heap, pointers, buffer boundaries, C interop. Those are exploit development fundamentals.
Most security professionals come from either a systems administration background or a software development background, and they learn the other side on the job. You? If you've been following along, you already have both -- the scripting/automation side AND the systems/memory side.
That puts you in a remarkably strong position. The combination of being able to write Python automation scripts, understand low-level memory layout in Zig/C, AND think about security is rare. Most developers can't think like attackers. Most pentesters can't write production code. You're building the skills to do both.
Over the next episodes, we'll systematically learn both offense and defense across every major domain:
Every attack technique comes with its defense. Every exploit comes with its patch. And throughout all of it, we'll keep coming back to one critical theme: AI-generated code is making all of this worse, and you need to understand exactly how and why.
Zullen we dan maar beginnen? ;-)
Exercise 1: Research the Colonial Pipeline attack in detail. Write a one-paragraph summary of the complete attack chain -- from initial access to final impact. Identify at which stage(s) of the Cyber Kill Chain the attack could have been stopped, and what defensive measure would have stopped it.
Exercise 2: Pick any company you use daily (your bank, email provider, a streaming service). Without touching their systems (passive reconnaissance ONLY -- public information), list 5 pieces of information you can find about their technology stack, employee names/roles, or infrastructure. Hint: check job postings, LinkedIn, DNS records, and the HTML source of their login page. Write down what you find and consider what an attacker could do with it.
Exercise 3: Read the text of the Computer Fraud and Abuse Act (CFAA) Section 1030. Identify three activities from this series' curriculum that would be illegal WITHOUT authorization but legal WITH written authorization. For each, explain what "authorization" would look like in practice (a contract clause, a bug bounty program scope, etc.).
@scipio