Skip to content
Intermediate Estimated time: "16 min" Category: Cybersecurity Published

Pentesting Básico (auditoría propia)

Summary

This guide explains the methodology of a penetration test (pentest) from the perspective of a DevOps team wanting to audit its own infrastructure. It's not an exploit cookbook: it's the method by which an attacker looks at your systems, so you do it first and defend yourself better. It covers the pentest phases, passive and active reconnaissance, and the legitimate use of Nmap, Burp Suite and Metasploit against your own labs, ending in what really gets delivered: the report.

This is the offensive complement to the defensive documentation in this section. Vulnerability scanning automates the search for CVEs in your images; a pentest goes further and validates whether those weaknesses are exploitable in your real context. The threat model predicts where you'll be attacked; the pentest checks it. And everything you do here generates exactly the events answered by the incident response playbook.

This is the most important section of the document and it comes first for a reason: a pentest without written authorization is a crime, not a grey area. In Spain it falls under articles 197 bis and 264 of the Criminal Code (unauthorized system access and computer damage); other countries have equivalents (the Computer Fraud and Abuse Act in the US, the Computer Misuse Act in the UK). Port-scanning a third party "just to look" can already constitute unlawful access. The difference between a security professional and a criminal isn't the tool: it's the permission.

No written authorization, hands off

There's no good-intentions exception. "I was going to tell them about the flaw" is not a legal defence. Before launching a single tool against a system, you need in writing: who authorizes it (with the power to do so), which systems are in scope, which techniques are allowed and in which time window. If you don't have that, the only legitimate target is your own infrastructure or a lab built for it.

The document that captures all of this is called the Rules of Engagement (RoE) and scope. The scope defines what's in and what's out: specific IP ranges and domains, explicitly excluded systems (often the most fragile: SCADA, medical systems, critical production), and time windows. The Rules of Engagement set the rules of the game: which techniques are allowed (social engineering yes or no?, denial of service never?), whom to notify if you find an existing compromise from another attacker, and an emergency contact to stop if something breaks.

That's why you practise in environments designed for it, never against third parties:

  • Your own labs: virtual machines you spin up yourself, isolated on an internal network, to reproduce your infrastructure or a specific service you want to audit.
  • Legal practice platforms: Hack The Box, TryHackMe and similar give you vulnerable targets you are welcome to attack because that's what they exist for.
  • Deliberately vulnerable applications to run in your lab: DVWA (Damn Vulnerable Web Application) for web, and Metasploitable as a full network target.

Your own infrastructure has rules too

Auditing your systems doesn't exempt you from coordinating. An aggressive scan in production can bring a service down; a brute-force can lock out real accounts. Warn your team, do it in an agreed window and have a rollback plan. Authority to attack is not the same as permission to cause an unplanned outage.

Methodology: the five phases

A pentest is an orderly process, not a string of tricks. The phases chain together and often feed back: what you discover while exploiting sends you back to enumerate.

graph LR
    A[Reconnaissance] --> B[Enumeration]
    B --> C[Exploitation]
    C --> D[Post-exploitation]
    D --> E[Report]
    C -.new target.-> B
    D -.pivot.-> A
    style A fill:#264653,color:#fff
    style E fill:#7f5539,color:#fff
  • Reconnaissance: gathering information about the target. The better this phase, the easier everything else becomes.
  • Enumeration: going from "this host exists" to "this specific version of this service runs on this port". It's active, detailed reconnaissance.
  • Exploitation: using a weakness to gain access or demonstrate impact. In an honest audit it often stops at "this is exploitable" without causing harm.
  • Post-exploitation: once inside, how far can you go? Privilege escalation, reach of the accessible data, ability to pivot to other systems. This is where real impact is measured.
  • Report: the deliverable. None of the above is worth anything unless it translates into something actionable. We give it its own section because it's what almost nobody does well.

Reconnaissance

Reconnaissance splits into passive and active, and the difference matters both legally and technically.

Passive reconnaissance doesn't touch the target: you query third-party sources. Since you send no traffic to their systems, it's the least intrusive part and where any serious audit begins.

  • OSINT (Open Source Intelligence): public information. WHOIS records, known credential leaks, metadata in published documents, code repositories with forgotten secrets, job postings revealing which technology you use.
  • DNS: a domain's DNS records reveal subdomains, mail servers (MX), and sometimes internal infrastructure badly exposed. dig and host query public DNS servers, not your target.
  • Certificate Transparency: every issued TLS certificate is logged in public, auditable logs. Searching crt.sh for your domain reveals subdomains you didn't even remember existed, because each one needed a certificate at some point.
# Passive reconnaissance — ONLY queries public sources, doesn't touch the target
# DNS records of a domain you own
dig +short frikiteam.example ANY
dig +short frikiteam.example MX
dig +short frikiteam.example TXT

# Zone transfer (almost always denied; if it works, it's a finding)
dig AXFR frikiteam.example @ns1.frikiteam.example

# Certificate Transparency: subdomains via issued certificates
# crt.sh returns JSON; filter for unique names
curl -s 'https://crt.sh/?q=%25.frikiteam.example&output=json' | jq -r '.[].name_value' | sort -u

Active reconnaissance does send traffic to the target: port scanning, service probing, requests to the web application. It's noisier, leaves traces in logs and requires being in scope. This is where Nmap comes in.

Passive reconnaissance is defence too

Do to yourself what an attacker would do. Searching your own exposed surface in Certificate Transparency and in device search engines usually reveals services you didn't know were public. It's among the cheapest and most effective things a DevOps team can do.

Nmap: network enumeration

Nmap is the standard tool for discovering hosts, open ports and what services run behind them. What matters isn't memorizing flags, but understanding what each type of scan does and why you pick one over another.

The most-used scan types:

  • -sS (SYN scan): sends the initial SYN but doesn't complete the TCP handshake. It's the default scan when you have privileges (requires root/CAP_NET_RAW). Fast and relatively discreet.
  • -sT (TCP connect): completes the handshake using the operating system stack. It's the one used without privileges; it leaves more traces in the target's logs.
  • -sU (UDP scan): scans UDP ports (DNS, SNMP, NTP). It's slow by nature because UDP doesn't confirm like TCP, but critical services live there.
  • -sn (ping scan): discovers which hosts are alive without scanning ports. Useful for mapping a range before drilling in.

Service and version detection is where Nmap adds the most value for an audit:

  • -sV: probes open ports to identify the service and its exact version. Knowing you run "OpenSSH 8.9" instead of "something on 22" is the difference between being able to cross-reference known CVEs or not.
  • -O: attempts to identify the operating system from its TCP/IP stack fingerprint.
  • -sC: runs the default NSE script set (safe, common checks). -A combines -sV -O -sC and traceroute in a single aggressive flag.

Timing (-T0 to -T5) controls aggressiveness. -T3 is the default. -T4 speeds things up and is reasonable on fast networks; -T5 is so aggressive it can miss results. The slow ones (-T0, -T1) reduce impact and noise.

# Host discovery on your own lab subnet
nmap -sn 192.168.56.0/24

# SYN scan + version detection of a host in your lab (Metasploitable)
sudo nmap -sS -sV -T4 192.168.56.101

# Full scan with default scripts and OS detection
sudo nmap -sS -sV -sC -O -T4 -p- 192.168.56.101

# Save in all formats for the report (normal, greppable, XML)
sudo nmap -sS -sV -T4 -oA recon-lab-101 192.168.56.101

An aggressive scan brings down fragile services

-T5, -A or -p- (all 65535 ports) against a delicate service —a network printer, an IoT device, a SCADA, an old database— can saturate it until it falls over. It's not theoretical: some devices hang on a simple version scan. That's why the scope excludes fragile systems and why, against your own production, you start with -T2 and ramp up carefully. A pentest that takes down the service it was auditing has failed.

Burp Suite: auditing your own web app

Burp Suite is the reference tool for auditing web applications. Its central idea is to act as an intercepting proxy: it sits between your browser and the application, and sees (and lets you modify) every HTTP request and response. There's a free Community edition, enough to learn and to audit your own app; the Professional one adds the automated scanner.

The conceptual workflow, against your own DVWA or your app in a test environment:

  1. Configure the proxy: point the browser at Burp's proxy (default 127.0.0.1:8080) and install its CA certificate so you can see HTTPS traffic. From then on, everything the browser does goes through Burp.
  2. Browse to populate the site tree: use the application normally. Burp builds a map of endpoints, parameters and flows in its Target tab.
  3. Intercept (Proxy → Intercept): pause a request before it goes out, see its headers, cookies and body, and decide whether to let it through or edit it. Here you truly understand what your app sends.
  4. Repeater: send a request to Repeater to modify and resend it as many times as you want, watching how the response changes. It's the manual tool par excellence to test, for example, whether a parameter that should be yours accepts another user's ID (a broken access control, from the threat model).
  5. Intruder: automates sending many variants of a request, useful for systematically testing a set of inputs against a single parameter. In the Community edition it's speed-limited, but it works for your own lab.

Repeater and Intruder only against your own

These tools send real, potentially damaging traffic. A misaimed Intruder is indistinguishable from an attack. Use them exclusively against applications you control or that are within an authorized scope. Confirm the exact path of each feature in your version of Burp: the interface changes between editions.

Metasploit: validating a CVE in your lab

Metasploit is an exploitation framework. Its legitimate value for a DevOps team isn't "hacking": it's to validate that a specific vulnerability actually affects you. Vulnerability scanning tells you "this image has CVE-X"; Metasploit, against a copy in your lab, confirms whether that CVE is really exploitable in your configuration or whether a mitigation makes it harmless. That turns a list of hundreds of theoretical CVEs into a short list of real risks to prioritize.

Its structure:

  • Modules: the catalogue of capabilities, organized by type. exploit modules leverage a vulnerability; auxiliary do support tasks (scanners, fuzzers, brute-force); post act after gaining access.
  • Payloads: the code that runs if the exploit succeeds. A payload can be as simple as opening a port, or a full interactive session like Meterpreter, Metasploit's advanced shell.
  • Handlers: the component that waits for and receives the connection back from a payload. An exploit launches the payload; the handler catches the resulting session.

The typical flow in the msfconsole console, against Metasploitable on your isolated network:

# Inside msfconsole — target: a vulnerable copy IN YOUR LAB
# Search for modules related to a specific service
search type:exploit name:vsftpd

# Select a module and see what options it needs
use exploit/unix/ftp/vsftpd_234_backdoor
show options

# Set the target (RHOSTS is your lab VM, never a third party)
set RHOSTS 192.168.56.101

# Check without exploiting when the module supports it
check

# Run against your own lab and confirm whether the CVE applies
run

Confirm module names in your version

Module names, their options and their availability change between Metasploit versions. The module in the example (vsftpd_234_backdoor) is a historical, well-known case, used here only for illustration against a lab target built to be vulnerable. Always verify with search and show options what exists in your installation; don't trust names from memory.

Scanning for weak credentials in your infrastructure

This is the most directly useful use case for a DevOps team, because weak and default credentials remain one of the most common entry points (it fits Identification and Authentication Failures from the threat model). Auditing your own fleet for trivial passwords, unchanged default accounts and reused keys finds real problems before an attacker does.

The idea isn't to crack other people's passwords, but to check your posture: is there still an admin/admin on some internal panel?, any database with the example password?, any service that would accept a basic dictionary?

# Weak-credential audit — ONLY against your own, authorized services
# hydra: tests a short list of credentials against an SSH in your lab
# Do it in an agreed window: a mass failure can lock real accounts
hydra -L usuarios.txt -P passwords-comunes.txt ssh://192.168.56.101 -t 4

# Nmap ships NSE scripts to detect default credentials more gently
sudo nmap --script ssh-auth-methods,ssh-brute -p 22 192.168.56.101

# Verify leaked hashes from YOUR own dump with John the Ripper
# (for example, after rotating and wanting to check the new ones are strong)
john --wordlist=passwords-comunes.txt hashes-propios.txt

Account lockout is a real side effect

A brute-force test, even against yourself, can trigger lockout policies and leave legitimate users without access, or even cause a denial of service. Limit concurrency (-t), use short, targeted dictionaries, and coordinate with whoever operates the service. The goal is to measure your exposure, not to self-inflict an incident.

The report: the real deliverable

Here's the actual work, and it's what almost nobody documents well. A pentest without a report is an anecdote: "I found stuff". The report is what turns hours of terminal into decisions and fixes. A finding that can't be reproduced can't be fixed; a finding without stated impact doesn't get prioritized.

Each finding must carry five elements, always the same:

  1. Finding: what it is, in one clear sentence. "The internal admin panel accepts the default credentials admin/admin."
  2. Reproducible evidence: the exact steps for someone else to confirm it, with the literal command or request and the response obtained. Without this, the development team can neither verify it nor know when they've fixed it.
  3. Impact: what an attacker gains from this in your context. Not "it's an XSS", but "an attacker can steal any administrator's session and take over the panel". Impact is what translates the technical finding into business language.
  4. Remediation: how it's fixed, concrete and actionable. "Force a password change on first login and disable the default account", not "improve security".
  5. Severity: an agreed label (Critical / High / Medium / Low / Informational) combining impact and ease of exploitation, ideally using a common framework like CVSS so it's comparable across reports.
### Finding PT-003 — Default credentials in the admin panel

**Severity:** High (CVSS 8.8) · **Status:** Open

**Description:** The internal panel at `https://admin.lab.local` accepts the
factory credentials `admin/admin`, never changed after deployment.

**Evidence (reproducible):**
1. Navigate to `https://admin.lab.local/login`
2. Enter user `admin`, password `admin`
3. Result: a valid administrator session (screenshot attached ev-003.png)

**Impact:** Anyone with network access to the panel gains full control:
create users, read customer data and modify configuration.

**Remediation:** Rotate the credential immediately, force a change on first
login, disable the default account and add MFA to the panel.

**References:** OWASP A07:2021 — Identification and Authentication Failures.

A good report opens with a one-page executive summary (readable by a non-technical person: what was audited, what the overall risk is, what's urgent), continues with the methodology and the scope actually covered, and then the findings ordered by severity. Urgent at the top; informational at the end.

The defensive side: what your SIEM would see

Closing the loop is what turns a pentest into defensive learning. Every offensive action in this document leaves a trace, and that trace is exactly what your monitoring should detect. If you run the pentest and your SIEM notices nothing, you have a second finding as serious as the first: you're blind.

Contrast each phase with what should fire, and use the result to tune the rules feeding the incident response playbook:

  • Nmap scan: a spike of connections to many ports from a single IP in a short time is the classic signature of a scan. Your IDS/IPS or Falco/Wazuh should alert on it. If the full scan went unnoticed, your reconnaissance detection isn't working.
  • Credential brute-force: dozens of failed logins against the same service should trigger an alert (and a lockout policy). It's among the easiest to detect; if it doesn't fire, review your authentication logging.
  • Exploitation with Metasploit: a successful exploit usually produces an unexpected process or outbound connection (the session back to the handler). Terminal shell in container or an outbound connection to an odd port are exactly the Falco rules that open a case in the incident playbook.
  • Web app activity: anomalous requests, tampered parameters and unusual volumes from Burp should show up in the WAF and application logs.

This exercise —attacking yourself to check you detect yourself— is sometimes called purple teaming, and it's the most honest way to validate that your investment in detection is worth something. The pentest doesn't end when you find the flaw; it ends when you confirm that, the next time someone tries it for real, you'll know.