What Is Ethical Hacking — Ethical Hacking

What "Ethical" Means

Ethical hacking is the practice of identifying and exploiting security weaknesses in systems, networks, and applications with the explicit permission of the owner, with the goal of improving defenses. The key word is permission. The difference between an ethical hacker and a criminal attacker is not in the techniques they use — many are identical — but in the authorization, the intent, and the respect for agreed boundaries.

An ethical hacker, also called a pentester or offensive security professional, simulates the methods of a real adversary to discover flaws before a malicious actor does. They always work under a contract, document everything they do, and deliver their findings to the client so issues can be remediated. The value lies in turning attacker knowledge into concrete, actionable defense.

It is essential to understand that ethics is not an optional detail tacked on at the end: it is the foundation that makes the entire activity legal and professional. Without authorization, the same actions constitute computer crimes in nearly every jurisdiction.

Ethical framing: every activity described in this course assumes written authorization, a defined scope, and agreed-upon rules of engagement. Without those, the same actions constitute a crime. Never practice these techniques against systems you do not own or do not have explicit permission to assess.

How the Professional Thinks

Technical skill is only half the craft. The other half is a way of thinking. A good offensive professional does not ask "which tool do I run?" but rather "how would a real attacker get in, what do they care about, and how far would they go?". That mindset — sometimes called thinking like the adversary — forces you to look at the whole system: people, processes, and technology, not just an open port.

The why matters too. Organizations do not commission a test out of curiosity: they want to reduce real risk before it turns into a costly breach. Every finding you report should answer the business question: what could the company lose if this is exploited, and how likely is it? A finding without impact context is noise; a well-framed finding is an investment decision.

That is why the professional cultivates three habits: disciplined curiosity (explore thoroughly, but within scope), documentary rigor (record every step so the work is reproducible and defensible), and humility (report what you found, not what you wished you had found). Reputation in this field is built on trust, and trust is lost with a single unethical shortcut.

The Hats: White, Grey, and Black Hat

The security community historically classifies hackers by "hats." A white hat operates with full authorization, following the law and a code of ethics; this is the role of the professional pentester and the internal security team. Their work is governed by contracts, rules of engagement, and responsible reporting.

A black hat acts without permission and with malicious intent: data theft, extortion, sabotage, or illicit profit. Their actions are criminal regardless of their technical skill. A grey hat occupies an ambiguous zone: they may access systems without prior authorization but without clearly malicious intent, for example reporting a flaw they found without permission. Even if the intent may seem good, the grey hat still operates outside the law and takes on real legal risk.

As a professional, your goal is to always operate as a white hat. Even discovering a vulnerability "out of curiosity" in someone else's system without permission can have serious legal consequences. Responsible disclosure through bug bounty programs or official channels is the proper path when you find something outside a formal engagement.

The Legal Framework

Hacking activities are regulated by specific laws in each country. In the United States, the Computer Fraud and Abuse Act (CFAA) penalizes unauthorized access to systems. In Europe, the GDPR and the Directive on attacks against information systems establish sanctions. In Paraguay and most Latin American countries there are computer crime laws that criminalize improper access, sabotage, and data interception.

The practical lesson is simple: never assume you have permission. Authorization must be explicit, in writing, and specific. A verbal agreement or an informal invitation does not protect you legally. Before you touch a single packet, you need a document signed by someone with real authority over the systems in question.

You must also comply with privacy and data-handling legislation. During a test you might encounter sensitive personal information; how you store, transmit, and destroy it can carry its own legal implications, separate from the permission to test.

Written Authorization and Rules of Engagement

The document that authorizes your work is usually called the Rules of Engagement (ROE) or testing authorization. It must specify who authorizes, which systems are included, during what dates and hours you may operate, which techniques are permitted or prohibited, and whom to contact in case of emergency. This document is your legal shield and your operational map.

Typical rules of engagement exclude actions that could cause real harm, such as denial-of-service (DoS) attacks against production or destructive modification of data. They also define "testing windows" to avoid business disruptions. If something is not explicitly permitted, the default rule is not to do it and to ask first.

A good practice is to include a "get-out-of-jail-free letter": a signed letter you carry with you that proves your authorization if someone — a system administrator, physical security, or the authorities — questions your activity during the engagement.

Mini-Scenario: The Engagement Kickoff

Imagine a fictional company, Acme Logistics Inc., hires you to assess its customer portal. The engagement does not begin with tools: it begins with a kickoff meeting where the rules of the game are agreed upon.

In that meeting you define, together with Acme's security lead, the essentials: which assets are in scope (the domain portal.acme-example.com and its public IP range), what is explicitly out of scope (the mail infrastructure and the payroll systems), the testing window (nights and weekends, so operations are not affected), and an emergency contact available around the clock. All of this is put in writing and signed before continuing.

Before confirming that a domain truly belongs to the client, a prudent step is to verify the public ownership of the domain. Never assume the client owns what they say they own; scope mistakes usually start here.

# Public registration lookup for a domain (ownership, registrar, dates).
# Used to corroborate that the declared asset matches the expected owner.
whois acme-example.com

# Check which address the domain resolves to before confirming the in-scope range.
# 'dig' queries DNS; the result should match the range authorized by the client.
dig +short portal.acme-example.com

If the owner or the IP does not match what was declared, you stop and ask. Only when the written authorization, the scope, and the rules of engagement are firm, and you have verified that the assets truly belong to the client, does the technical work begin.

Scope Is Everything

Scope defines the exact boundaries of what you can and cannot test. It includes IP ranges, domains, applications, network segments, and sometimes specific types of tests. Going out of scope, even by mistake, can invalidate the engagement and expose you to legal liability. That is why validating scope before and during the test is a constant discipline.

Scope can be black box (no prior information), grey box (partial information, such as low-privilege credentials), or white box (full access to documentation and code). Each modality simulates a different scenario and has implications for the depth and speed of the test. Defining it well with the client avoids misunderstandings and maximizes the value of the engagement.

Document any ambiguity before you start. If an asset is not clearly inside or outside scope, ask. The difference between a trustworthy professional and a legal problem often comes down to disciplined respect for those boundaries.

Service Modalities

Not every "security test" is the same thing. Choosing the right modality depends on the client's maturity, budget, and the question they want to answer.

Vulnerability assessment: aims for the broadest possible coverage by identifying and cataloging known weaknesses, generally with the help of automated scanners. It does not go deep into exploitation; it answers "what weaknesses do I have?". Ideal for periodic security hygiene and compliance.
Penetration test: goes beyond listing flaws: it exploits vulnerabilities in a controlled way to demonstrate real impact and chain accesses together. It answers "what can an attacker actually achieve?". It requires more manual expertise and a well-defined scope.
Red team: simulates a real, goal-driven adversary over time, also measuring the defending team's (blue team) detection and response capability. It is stealthy and broad; it answers "would we notice if we were attacked?". Appropriate for mature organizations.
Bug bounty: a continuous, open program where external researchers report flaws in exchange for rewards, under public rules. It complements — does not replace — the other modalities, and works best when a baseline level of security already exists.

In practice, many organizations combine several: a vulnerability assessment for continuous hygiene, an annual pentest for depth, and a permanent bug bounty for long-term coverage.

MITRE ATT&CK: Thinking Like the Attacker

MITRE ATT&CK is a public knowledge base that catalogs the observed behavior of real adversaries, organized into tactics (the "why" of an action, such as initial access, persistence, or exfiltration) and techniques (the concrete "how" of each tactic). It is not a list of exploits, but a map of adversary behavior across the entire lifecycle of an attack.

The ethical hacker uses ATT&CK as a reference framework for two reasons. First, it gives a common vocabulary to think and communicate: instead of loose findings, you can map your activity to recognizable tactics and show the client which stages of a real attack your test managed to cover. Second, it helps you structure adversary thinking systematically: rather than improvising, you walk through the tactics and ask how an attacker would approach each phase within your scope.

For the defender, that same map allows verifying detection coverage: if your test exercised certain techniques and the blue team did not see them, there is a concrete gap to close. That is why ATT&CK connects offensive work with defensive improvement, which is the ultimate goal of the engagement.

Closing Checklist: Pre-Engagement

Before executing any technical action, verify — in a disciplined way — that these points are covered:

[ ] Written authorization exists, signed by someone with real authority over the systems.
[ ] The scope is defined without ambiguity: assets included, assets excluded, and permitted test types.
[ ] The rules of engagement are agreed upon: testing windows, prohibited techniques, and impact limits.
[ ] You verified the ownership of the declared domains and IPs (for example, with whois and dig) and they match the client.
[ ] You have an emergency contact available and a clear procedure to pause the test if something goes wrong.
[ ] You agreed on sensitive data handling: how findings are stored, transmitted, and destroyed.
[ ] You have the "get-out-of-jail-free letter" in case anyone questions your activity during the engagement.
[ ] You defined the format and recipient of the final report, and who receives critical findings immediately.

If any of these points is incomplete, do not start. Discipline in the pre-engagement is what separates a trustworthy professional from a legal problem.