In the previous lesson we built TechNova's file without touching its systems: whois, public DNS, crt.sh, dorks, archive.org, and metadata gave us a list of candidates -subdomains like dev., staging-tienda., intranet., and vpn., the store's IP, the name servers NS1/NS2-. But all of that is a hypothesis: it tells us what could exist, not what is alive and responding. To go from "exists in a certificate" to "this host answers", we have to talk directly to the target's infrastructure. That is active reconnaissance.

Active reconnaissance means interacting directly with the target's systems by sending them packets and analyzing their responses. Unlike passive work, here we do leave a trace: our requests can appear in TechNova's logs and trigger its detection systems. That is why it is doubly important to stay within scope and the RoE, and to tread carefully. In this lesson we cover the first band of active techniques -DNS queries and zone transfer, live host discovery, basic banner grabbing, traceroute, active subdomain enumeration, and light web crawling- and we clearly mark where reconnaissance ends and scanning begins (which is Module 3).

1. What changes relative to passive (and the boundary with Module 3)
2. Active DNS: queries to the authoritative server and zone transfer
3. Live host discovery (ping sweep)
4. Traceroute: the path to the target
5. Basic banner grabbing
6. Active subdomain enumeration
7. Light web crawling
8. Ethical and scope framing
9. Common mistakes and tips
10. Exercises
11. Conclusion

The essential change is that now the traffic reaches the target. With it we gain certainty (we confirm what is alive) in exchange for visibility (we can be detected). Let's place this lesson between what we already saw and what comes next:

The boundary we will not cross in this lesson: deep port scanning (sweeping all 65535 ports, fine-grained version detection, service enumeration scripts) belongs to Module 3. Here we do "surface" active reconnaissance: confirm live hosts, grab the occasional banner, and map names and paths. Think of it as taking attendance ("are you there?") before the detailed interrogation that comes later.

In passive work we asked a public resolver. Now we ask TechNova's authoritative server directly (ns1.technova.lab), which is already direct interaction.

The star technique here is the zone transfer (AXFR). A misconfigured DNS zone can allow anyone to download all of its records at once: a complete map of the infrastructure served on a platter.

If the server is misconfigured, the output is a gift:

Reading the finding:

• We confirm the IPs of the subdomains that in 02-01 were only candidates.
• Internal records (10.10.10.x) appear that did not show up in public sources: dev, intranet, and a revealing db-interno.technova.lab → 10.10.10.40. This connects directly to the internal network 10.10.10.0/24 in scope.
• A successful zone transfer is itself a reportable finding (DNS misconfiguration).

If the zone is properly configured, we will see something like Transfer failed or REFUSED, which is the correct behavior.

Defensive counterpart: TechNova should restrict zone transfers to the authorized secondary servers (allow-transfer in BIND). Allowing AXFR to anyone leaks the complete map of the network.

Within the internal scope we have the network 10.10.10.0/24 (254 usable addresses). Before anything else we want to know which addresses have a live machine. A ping sweep sends probes (ICMP echo, or ARP on a local network) to the whole range and records who responds.

With nmap in "discovery only" mode (-sn, no port scanning):

Notice the flag: -sn does host discovery without scanning ports. That is the exact boundary of this lesson. The result is an inventory of live hosts: 10.10.10.1 (likely gateway/network controller), .15 (dev), .20 (intranet), .40 (db-interno), and .55 (a workstation not seen before). These five hosts will be the targets of Module 3's deep scanning.

A lightweight alternative with fping:

-a shows only the alive ones and -g generates the range.

Defensive counterpart: filtering ICMP at the perimeter and segmenting the network reduces the ping sweep's success; an IDS can detect the pattern of "one IP probing an entire /24 in seconds".

traceroute (or tracert on Windows) reveals the network hops between us and the target, showing the intermediate topology (routers, firewalls).

Reading: we see that the store sits behind the gateway 203.0.113.1. The intermediate hops help us understand where the perimeter is and whether there is a firewall filtering (hops with * * * often appear when a device does not respond to the expired TTL). This is topology information, not service information.

When we connect to an open port, many services "introduce themselves" with a banner that can reveal the software and its version. In active reconnaissance we do banner grabbing spot-by-spot and manually on a specific service we already know exists; the systematic sweep of versions across many ports is Module 3's job.

With netcat against port 80 of the store:

Response:

Reading: the banner confirms the Apache 2.4.29 on Ubuntu with PHP 7.2.24 stack, consistent with the "PHP/MySQL store" in scope. We note down specific versions: they are key for looking up known vulnerabilities later. PHP 7.2 is end-of-life, an early hint of exposure.

You can also read the banner of an SSH service:

Again: a specific OpenSSH version from the dev host. Here we only read it; exploiting or enumerating it in depth belongs to later modules.

In 02-01 we obtained subdomains from passive sources (crt.sh). Now we verify them actively and try to discover more through name brute forcing: we test a list of common names (www, dev, api, correo, vpn, git...) resolving them against DNS to see which exist.

With a tool like dnsx fed by a wordlist:

api.technova.lab and git.technova.lab show up, which were not in crt.sh: active brute forcing complements the passive work. An exposed git. is especially interesting (possible source code leak). This is active because each attempt generates a real DNS query; with a large wordlist, the volume of queries is noticeable.

A crawler walks a site's links to map its paths and resources. In reconnaissance we do a light and respectful crawl (low depth, low concurrency) to draw the site's structure, not an aggressive vulnerability scan (that is Module 3/4).

Reading: we discover paths on the store -login.php, producto.php?id=1 (a parameter that is a candidate for injection, to be studied in Module 4), an /admin/ directory-. It is always worth checking robots.txt and sitemap.xml, which often list paths the owner did not want indexed but that exist:

Ironically, robots.txt reveals sensitive directories to us (/admin/, /backup/). It is a classic. Crawl carefully: keep the load low so as not to degrade TechNova's service.

Active reconnaissance already leaves a trace and touches the client's systems, so the RoE weigh more than ever:

• Do not step outside the authorized range. The ping sweep must be limited to 10.10.10.0/24 and to the public IPs in scope. Sweeping a neighboring network or the hosting provider's range is going out of scope.
• No third parties. If the traceroute crosses an ISP's or a CDN's network, that is transit, not a target: do not probe it.
• Control the intensity. An aggressive crawl or a massive ping sweep can degrade production services. Adjust pace and concurrency; coordinate windows with the client if there is risk.
• Document with timestamps. Since you now leave a trace, log what you launched and when. If TechNova's SOC detects activity, they must be able to correlate it with your authorized work (hence the usefulness of a known, communicated source IP).

• Crossing Module 3's boundary without realizing. Launching nmap -sV -p- "while I'm at it" is deep scanning, not reconnaissance. Keep active work to -sn and spot banners; leave scanning for its module.
• Going out of range. A mistyped /24 (10.10.0.0/16) can sweep networks outside the scope. Always double-check the CIDR before running.
• Ignoring robots.txt and sitemap.xml. They are among the most rewarding active sources and are often overlooked.
• Going too hard against production. An aggressive ping sweep or crawler can cause an outage; that is an incident, not a finding.
• Tip: always start from what you discovered passively. Active work confirms and completes; using the candidate list from 02-01 makes your active reconnaissance far more targeted and quiet.

Exercise 1. Explain why nmap -sn 10.10.10.0/24 is active reconnaissance appropriate for this lesson, whereas nmap -sV -p- 10.10.10.15 is not. Which module does the second one belong to?

Exercise 2. A zone transfer (dig @ns1.technova.lab technova.lab AXFR) succeeds and returns internal 10.10.10.x records. State two things: (a) what value this has for reconnaissance and (b) why it is in itself a reportable finding, with its defensive counterpart.

Exercise 3. After a light crawl of the store you find robots.txt with Disallow: /admin/ and Disallow: /backup/. Why is this information, meant for search engines, useful to the pentester? What intensity precaution must you keep when crawling production?

Solution 1. nmap -sn performs host discovery without scanning ports: it only confirms which IPs in the range are alive, which is exactly the goal of this lesson's active reconnaissance. By contrast, nmap -sV -p- sweeps all 65535 ports and performs version detection on each service: that is deep scanning and enumeration, proper to Module 3. The difference is depth: taking attendance vs. the detailed interrogation.

Solution 2. (a) It gives us a complete, confirmed map of the infrastructure, including internal hosts (db-interno → 10.10.10.40) that did not appear in public sources, saving us much of the discovery work. (b) It is reportable because a zone that allows AXFR to anyone is a misconfiguration: it leaks the entire DNS topology to an attacker. Defensive counterpart: restrict allow-transfer solely to the authorized secondary servers.

Solution 3. Because robots.txt asks search engines not to index those paths, but by listing them it reveals their existence: /admin/ (administration panel) and /backup/ (possible copies with sensitive data) are direct targets we might not have found linked anywhere. Precaution: crawl with low depth and concurrency so as not to degrade the store in production; an aggressive crawler can cause an outage, which would be an incident and a violation of TechNova's RoE not to interrupt the service.

With active reconnaissance we have moved from hypotheses to certainties: we confirmed the subdomains' IPs, discovered internal hosts via zone transfer (db-interno → 10.10.10.40), inventoried the live hosts of 10.10.10.0/24 with a ping sweep, mapped the route to the store, read banners revealing Apache 2.4.29 / PHP 7.2.24 / OpenSSH 7.6, expanded the subdomain list (api, git), and drew the store's structure with a light crawl. All of it leaving a trace in a controlled way and without going out of scope.

We have already touched many tools -whois, dig, nmap -sn, nc, dnsx, wget- in a scattered way, as we needed them. In the next lesson, 02-03 Information Gathering Tools, we step back to see these and other tools as a comparative catalog and, above all, to learn to orchestrate them into a coherent recon flow for TechNova, instead of using them in isolation. Neither passive nor active in the abstract: which tool, for what, in which order.