Internal network pentest methodology

Overview

Security objective. The asset you are protecting is an internal corporate network — its file shares, workstations, servers, and above all the Active Directory domain that authenticates every Windows user and computer. The threat is an attacker who already has a small foothold inside (a phished laptop, a rogue device in a meeting room, a compromised contractor VPN account) and wants to expand that into control of the whole domain. As a learner you will detect the misconfigurations and weak credentials that let this expansion happen, and — just as importantly — learn to prevent and detect each step.

This lesson builds directly on your two prerequisites. From The phases of an engagement you already know the overall arc — scoping, rules of engagement, recon, exploitation, reporting. Internal methodology is the engine that runs inside the middle of that arc. From Port, service, and OS scanning you know how to find live hosts and identify what is listening; here you learn where that scanning fits in a repeating loop and how to do it gently on fragile internal networks.

An internal engagement assumes the attacker is already past the perimeter. Instead of asking "can someone break in from the internet?", it asks the more realistic question: "once someone is in — which happens constantly via phishing — how far can they get, and would we notice?" The whole methodology is a disciplined loop that turns one small position into a map of the network's real risk, all while staying inside an authorized scope.

Why it matters

Internal and Active Directory work is the bread and butter of professional penetration testing. Most organisations of any size run Windows domains, and the majority of real engagements involve them.

A repeatable loop matters for three professional reasons:

• Thoroughness. Working the same steps on every host means you do not miss the forgotten file server with everyone's passwords in a spreadsheet.
• Scope safety. A defined loop keeps you inside authorized subnets and stops "just one more host" drift that can breach the contract or knock over production systems.
• Reportable impact. Clients do not pay for a list of open ports. They pay to know the business risk: "a single phished laptop leads to Domain Admin in under a day." The loop is what lets you demonstrate that path, host by host, with evidence.

Recognising that AD ties Windows networks together lets you focus effort on the highest-impact target instead of spreading thin. And the same loop, read backwards, tells a defender exactly where to add logging, tighten segmentation, and rotate credentials — which is the outcome that actually improves security.

Core concepts

1. Assumed breach

Definition. An engagement that starts with the tester already inside the network — given a network drop, a low-privilege domain account, or a standard employee laptop image.

Plain explanation. Instead of spending days trying to break through the firewall, the client hands you a realistic starting position, because real attackers get in through phishing and stolen credentials all the time. The interesting question is what happens next.

How it works. The client provisions a foothold (a VM, a VPN account, or a physical drop) and defines exactly which subnets and systems are in scope. You then demonstrate the impact an attacker could achieve from that spot.

When / when not. Use assumed breach when the goal is to measure internal blast radius and detection. Do not use it when the client specifically wants to test perimeter defences — that is a different objective.

Pitfall. Treating "assumed breach" as permission to go anywhere. The foothold is scoped; the rest of the network may not be.

2. The loop

Definition. The repeating cycle: host discovery → service enumeration → validation → credential gathering → lateral movement → domain escalation, then back to discovery from the new vantage point.

Plain explanation. Every new host or credential you gain gives you a new place to look from, so you run the same steps again with better access. The network unfolds like a series of rooms, each one revealing doors to more rooms.

How it works. You discover live hosts, identify their services, confirm real (not scanner-guessed) misconfigurations, collect any credentials, reuse those credentials to reach new hosts, and try to convert local access into domain-level control — repeating until you have mapped the risk or run out of scope/time.

When / when not. The loop applies to almost any internal test. On very small or non-Windows networks the escalation step may not lead to AD, but the discover-enumerate-validate rhythm still holds.

Pitfall. Skipping validation and reporting raw scanner output as findings. A scanner saying "possible MS17-010" is a lead, not a confirmed vulnerability.

3. AD-centric convergence

Definition. The observation that internal Windows engagements almost always turn into Active Directory engagements.

Plain explanation. In a Windows environment, AD is the single system that authenticates users, joins computers, and stores group memberships. Control AD and you effectively control every domain-joined machine. So the loop naturally flows toward it.

How it works. Credentials and misconfigurations you find on individual hosts are usually domain credentials or domain trust relationships. Following them leads inward to the domain controllers.

When / when not. Applies to Windows/AD networks. A pure-Linux or embedded/OT network has a different centre of gravity — do not force an AD narrative where there is no AD.

Pitfall. Tunnel vision. Chasing AD so hard you ignore a critical finding elsewhere (an unpatched internet-exposed database on the same subnet).

4. Discipline, safety, and scope

Definition. The professional constraints that keep internal testing from causing outages or leaving scope.

Plain explanation. Internal networks contain fragile things — printers, badge readers, medical or industrial (ICS/OT) devices — that can crash from aggressive scanning. Being careful is part of the job, not a nicety.

How it works. You throttle scans, avoid known-fragile ranges unless explicitly authorized, record timestamps of noisy actions, and continually check that the current target is in scope.

When / when not. Always. There is no phase where scope and safety stop applying.

Pitfall. A default "fast/aggressive" scan across a /16 that knocks printers or an ICS device offline — a real, contract-ending mistake.

Threat-model diagram

            AUTHORIZED INTERNAL LAB (scope: 10.10.0.0/24 only)
  ============================= TRUST BOUNDARY (perimeter) =============================
  Internet  |                                                                          |
            |   [Foothold VM]  <-- entry point (assumed breach, given by client)       |
            |     10.10.0.50                                                            |
            |        |  discover / enumerate (gentle)                                   |
            |        v                                                                  |
   TRUST    |   [Workstations] --- [File Server] --- [App/DB Server]                    |
  BOUNDARY  |     shares 445      creds in shares      service accounts                 |
  (user ->  |        |                 |                    |                            |
   domain)  |        +--------- credentials / trust relationships ---------+            |
            |                          |                                                |
  ========================== TRUST BOUNDARY (domain tier) ==============================
            |                   [Domain Controller]  <-- highest-value asset            |
            |                    AD: users, groups, Kerberos, LDAP 389/636, KDC 88      |
  =====================================================================================
  Assets protected: user data, file shares, service accounts, and the AD domain itself.
  Entry point: the single foothold. Escalation crosses each trust boundary inward.

Knowledge check.

1. In the diagram, what asset sits behind the innermost trust boundary, and why is it the highest-value target?
2. The foothold VM can read a file share and finds a password in a script. Which insecure assumption made that a serious problem — and which log would let a defender detect the tester reading that share?
3. Why must every step in this loop happen only on a network you own or are explicitly authorized to test, even though the techniques are "just enumeration"?

Syntax notes

Internal methodology is a process, but a few concrete, lab-safe commands anchor the loop. The key structure is: discover → enumerate one host → validate by hand, always throttled.

# 1) GENTLE host discovery on an authorized lab subnet (ARP/ping sweep, no port flood)
nmap -sn -T2 10.10.0.0/24
#   -sn : host discovery only (no port scan) -> quiet, low-impact
#   -T2 : slow timing template -> gentle on fragile devices

# 2) Targeted service enumeration of ONE live host (only common internal ports)
nmap -sV -T2 -p 88,389,445,636,3389 10.10.0.10
#   88=Kerberos 389/636=LDAP/LDAPS 445=SMB 3389=RDP  -> AD service fingerprint

# 3) VALIDATE a finding by hand (list SMB shares as an authenticated user)
#    Placeholder creds only; never real secrets in commands or notes.
smbclient -L //10.10.0.10 -U 'LAB\\student%<lab-placeholder-password>'

Key internal ports to recognise (an AD service fingerprint):

Note the -T2 timing and single-host targeting: on internal networks, gentle and specific beats fast and broad.

Lesson

An internal engagement assumes the attacker is already inside the perimeter. The starting point may be a foothold, a rogue device, or an "assumed breach" position.

The goal is to show how far that access can be pushed — ideally all the way to domain compromise.

The loop from a foothold

1. Host discovery — find live hosts on the local subnets (ping sweep, ARP, careful scanning).
2. Service enumeration — for each host, identify running services such as SMB (port 445), RDP (3389), LDAP (389), Kerberos (88), and databases.
3. Vulnerability and misconfiguration validation — confirm issues by hand (open shares, default credentials, missing patches). Do not rely on scanner output alone.
4. Credential gathering — collect credentials from shares, config files, memory, and the attacks covered in this track.
5. Lateral movement — reuse credentials to reach new hosts.
6. Escalation to the domain — convert local access into Domain Admin.

Repeat the loop. Each new host or credential opens up more of the network.

Internal vs external

Internally you will see far more than from the outside: file shares, printers, legacy protocols, and Active Directory, which ties every Windows host together.

Most internal engagements become AD engagements.

Discipline

Internal scanning can disrupt fragile devices such as printers and industrial control systems (ICS). Scan gently and stay within scope.

Note the time of noisy actions so the client's blue team (defenders) can correlate them.

Segmentation testing — checking whether subnet A can reach subnet B — is often an explicit objective.

Code examples

The "code" for a methodology lesson is a repeatable, auditable runbook. Below is the insecure habit, the secure practice, and a verification you actually ran the loop safely — all lab-only.

(1) WARNING: intentionally vulnerable — use only in a local, isolated, authorized lab. Do not deploy.

This is the insecure tester habit that causes outages and scope breaches — shown so you can recognise and avoid it:

# ANTI-PATTERN: aggressive, unbounded, unlogged. Never do this on a real network.
nmap -T5 -A -p- 10.0.0.0/8        # fast+aggressive across a HUGE range
# - -T5  : maximum speed -> can crash printers, badge readers, ICS/OT devices
# - -A   : OS+script+traceroute -> noisy, sends probes fragile devices choke on
# - -p-  : all 65535 ports        -> massive traffic
# - 10.0.0.0/8 : millions of hosts -> almost certainly OUTSIDE authorized scope
# No timestamp, no scope check, no output file -> nothing the blue team can correlate.

(2) SECURE fix — a scoped, gentle, logged loop

#!/usr/bin/env bash
# Lab-only internal recon runbook. Runs ONLY against an authorized subnet.
set -euo pipefail

SCOPE="10.10.0.0/24"                 # <-- exactly what the client authorized
OUT="engagement_$(date +%Y%m%d)"    # evidence folder
mkdir -p "$OUT"

# Refuse to run if the operator has not confirmed authorization for this scope.
read -r -p "Confirm you are AUTHORIZED to test ${SCOPE}? (yes/no) " ok
[ "$ok" = "yes" ] || { echo "Aborting: not authorized."; exit 1; }

log() { echo "$(date -u +%FT%TZ) | $*" | tee -a "$OUT/actions.log"; }

# STEP 1: gentle host discovery (no port flood)
log "host-discovery start scope=${SCOPE}"
nmap -sn -T2 "$SCOPE" -oG "$OUT/hosts.gnmap"
log "host-discovery done -> $OUT/hosts.gnmap"

# STEP 2: enumerate ONLY common internal ports on discovered live hosts, gently
grep "Status: Up" "$OUT/hosts.gnmap" | awk '{print $2}' > "$OUT/live.txt"
while read -r host; do
  log "enumerate host=${host} ports=88,389,445,636,3389"
  nmap -sV -T2 -p 88,389,445,636,3389 "$host" -oN "$OUT/host_${host}.txt"
done < "$OUT/live.txt"

log "loop complete. VALIDATE findings by hand before reporting."

(3) VERIFY — prove the safety controls REJECT bad input and ACCEPT good input

# ACCEPT: authorized scope + "yes" -> the loop runs and writes an audit log.
$ ./recon.sh
Confirm you are AUTHORIZED to test 10.10.0.0/24? (yes/no) yes
2026-07-07T09:00:01Z | host-discovery start scope=10.10.0.0/24
...

# REJECT: operator cannot confirm authorization -> the script refuses to scan.
$ ./recon.sh
Confirm you are AUTHORIZED to test 10.10.0.0/24? (yes/no) no
Aborting: not authorized.
$ echo $?
1

# REJECT (scope drift): to test a different subnet you must EDIT $SCOPE deliberately
# and re-confirm. There is no way to "accidentally" scan 10.0.0.0/8.

What this shows. The secure runbook is scoped (one /24, not a /8), gentle (-sn/-T2, five ports), and auditable (UTC-timestamped actions.log the blue team can correlate). The verification proves the authorization gate blocks a run when the operator cannot confirm authorization (exit code 1) and permits it when they can. Nothing here is an exploit — it is disciplined enumeration plus an audit trail.

Line by line

Walking the secure runbook from part (2):

How values change across the loop. hosts.gnmap (all responses) narrows to live.txt (only "Up" hosts), which drives one host_<ip>.txt per live host. Each of those files is a starting point for the validate → credentials → move steps you cover later in the track. After you gain a credential or a new host, SCOPE may legitimately expand — but only by a deliberate edit and a fresh authorization confirmation.

Common mistakes

Debugging tips

Common ways the loop "fails" internally, and how to work through them:

• Host discovery returns nothing, but you know hosts exist. Ping/ICMP is often blocked internally. Try ARP-based discovery on the local segment (nmap -sn -PR on the same L2), or a light TCP-SYN discovery on a common port (-PS445). Ask: am I even on the right VLAN/subnet?
• A host shows all ports filtered. A host firewall or network ACL may be dropping probes — which is itself a segmentation data point worth noting. Ask: is this a firewall, or am I hitting a boundary I am not authorized to cross?
• smbclient/enumeration returns ACCESS_DENIED. Expected without valid creds. That is a validation result, not a bug — note "share exists, requires auth" and move on. Ask: do I have a lab credential that legitimately applies here?
• A device drops off the network after you scan it. You may have been too aggressive. Stop, lower timing to -T1/-T2, restrict ports, and note the incident. Ask: is this device fragile (printer/ICS)? Should it be excluded?
• Results are inconsistent between runs. Timing templates, host firewalls, and transient devices cause this. Re-run gently, and record timestamps so you can correlate. Ask: did the environment change, or did my scan behave differently?

Questions to ask when the loop stalls: Am I in scope? Am I on the expected subnet? Is this a real block or a fragile device? Did I validate the finding or just read a tool's guess? Is every noisy action logged with a UTC timestamp?

Memory safety

Security & safety: detection, logging, and remediation

Because this is a methodology lesson, the defensive payoff is huge: the same loop, read from the defender's chair, tells you exactly what to log, what to watch for, and what to fix.

What to log (so the loop is detectable):

• Timestamp (UTC) of every network event.
• Source host/account performing discovery or authentication.
• Resource touched (host, share path, service, LDAP query).
• Result / security decision (allow, deny, ACCESS_DENIED, logon success/failure).
• Correlation id (engagement id, ticket, or session) so events chain together.

Concretely on Windows/AD: enable and forward Security event logs — logon events (4624/4625), Kerberos service-ticket requests (4769, spikes hint at Kerberoasting), object-access on sensitive shares (4663 with SACLs), and network/firewall connection logs. Central collection (a SIEM) is what turns scattered events into a detected attack path.

What to NEVER log: passwords, password hashes, Kerberos tickets or session cookies, private keys, full API tokens, or unnecessary PII. If the tester found a credential in a share, the finding is logged — the credential itself is redacted to a placeholder like <redacted>.

Events that signal abuse (the loop, seen defensively):

• A single host suddenly touching many other hosts on 445/389/88 → discovery/enumeration sweep.
• A burst of Kerberos ticket requests for many service accounts → possible Kerberoasting.
• The same credential authenticating to many machines in a short window → lateral movement.
• Unusual access to a domain controller from a workstation → escalation attempt.

How false positives arise: legitimate vulnerability scanners, backup agents, patch-management sweeps, and monitoring tools all generate host-to-host traffic that looks like discovery. This is precisely why an authorized test's timestamped actions.log matters — defenders can subtract the known test from the alerts and see what (if anything) remains. Tuning detections to the environment's normal baseline is what reduces these false positives.

Remediation the loop points to: network segmentation (limit which subnets can reach the DC), least privilege (no shared local-admin passwords — use LAPS), credential hygiene (no passwords in scripts/shares, rotate service accounts), patching the validated findings, and turning on the logging above. Verify each fix (see practice tasks): after segmentation, re-run discovery and confirm subnet A can no longer reach subnet B.

Real-world uses

Authorized real-world use case. A mid-size company hires a firm for an assumed-breach internal assessment. The client provisions a standard employee laptop image on an isolated test VLAN and authorizes the 10.10.0.0/24 range. The tester runs the loop — gentle discovery, targeted enumeration, hand-validation of an open file share containing a deployment script with a service-account password, careful reuse of that credential, and a path toward the domain — all timestamped. The deliverable is not "here are open ports" but "a single phished laptop reaches Domain Admin via one exposed script; here is each step, the evidence, and the fix." The client uses it to add share ACLs, remove the embedded password, deploy LAPS, and turn on the missing logging.

Professional best-practice habits.

The through-line: an internal test is only valuable if it is safe, in scope, validated, logged, and remediation-focused — that is what separates a professional from a scanner-runner.

Practice tasks

All tasks are lab-only. Run them on a network you own or an intentionally-vulnerable lab (a local VM range you control, a container network, or a sanctioned CTF/AD lab). Authorization checklist: (1) you own or have written permission for the target, (2) it is isolated from production/the internet, (3) you have defined the exact scope, (4) you know how to reset it. Each security task ends by remediating and verifying.

Beginner 1 — Draw your lab threat model.

• Objective: produce a text threat-model diagram of your lab subnet.
• Requirements: mark assets, at least two trust boundaries, the single entry point (foothold), and the highest-value target.
• Constraints: no scanning yet — this is on paper.
• Hints: put the domain controller / most valuable host behind the innermost boundary.
• Concepts: assumed breach, trust boundaries, assets.

Beginner 2 — Gentle host discovery with an audit log.

• Objective: list live hosts on your authorized lab subnet without a port flood.
• Requirements: use host-discovery-only, gentle timing; write a UTC-timestamped actions.log line before and after.
• Input/Output: input = your /24 scope; output = a live.txt of responsive hosts + log entries.
• Constraints: no -p-, no -T4/-T5, stay in scope.
• Hints: nmap -sn -T2 <scope>; you can extract "Status: Up" lines.
• Concepts: gentle discovery, logging, scope.

Intermediate 1 — Enumerate and validate one host.

• Objective: fingerprint one live host's AD-relevant services, then validate one finding by hand.
• Requirements: scan only ports 88,389,445,636,3389 gently; then confirm one result manually (e.g. list SMB shares with a lab placeholder credential) and record whether access was allowed or denied.
• Output: a host_<ip>.txt plus a one-line validated finding ("share X exists, requires auth").
• Constraints: placeholder credentials only; no real secrets in commands or notes.
• Hints: distinguish "tool guessed" from "I confirmed."
• Concepts: enumeration, validation vs scanner output.

Intermediate 2 — Detect your own loop.

• Objective: from the defender's seat, find the evidence your discovery run left behind.
• Requirements: on the target host/DC, locate the log events your scan and any auth attempts generated (e.g. logon 4624/4625, service-ticket 4769, or firewall/connection logs); line them up against your actions.log.
• Output: a short mapping of "my action → the log that recorded it," and note any action that left no log (a detection gap).
• Constraints: read-only on logs; do not clear or tamper with them.
• Hints: false positives come from backup/patch agents — your timestamps disambiguate.
• Concepts: detection, logging, correlation, false positives.

Challenge — Segmentation test with remediation and verification.

• Objective: determine whether one lab subnet can reach another it should not, then fix and prove it.
• Requirements: (1) from subnet A, gently test reachability to a service on subnet B and record the result; (2) apply a remediation (a host firewall rule or a network ACL that blocks A→B); (3) verify by re-running the exact reachability test and confirming it is now blocked; (4) write a mini finding with title, affected component, safe reproduction, impact, remediation, and retest result.
• Constraints: lab-only; change firewall/ACL config only on systems you control; keep a rollback/reset step.
• Defensive conclusion: the deliverable is the closed loop — found the gap, fixed it, proved the fix. Include CLEANUP: revert any temporary rules you did not intend to keep and restore the lab to its baseline.
• Concepts: segmentation, mitigation verification, minimal finding template, cleanup/reset.

Summary

Main concepts. Internal testing usually starts from an assumed-breach foothold and runs a repeating loop: discover → enumerate → validate → gather credentials → move → escalate. On Windows networks the loop converges on Active Directory, the highest-impact target, because controlling AD means controlling every domain-joined host.

Key commands/structure. Gentle discovery (nmap -sn -T2 <scope>), targeted AD-service enumeration (ports 88/389/445/636/3389 with -sV -T2), and hand-validation before anything is reported. A scoped, authorization-gated, UTC-logged runbook is the professional shape of the work.

Common mistakes. Aggressive/broad scanning that crashes fragile devices or leaves scope; reporting unvalidated scanner output; assuming decoding a token equals bypassing auth; tunnel-visioning on Domain Admin; and doing noisy work without a timestamped actions log.

What to remember. Every offensive step has a defensive twin: log the timestamp, source, resource, result, and correlation id; never log secrets; watch for host-to-host sweeps, credential reuse, and Kerberos bursts; and reduce false positives with a baseline and your own recorded actions. An internal test only earns its value when it is safe, in scope, validated, logged, and remediation-verified — including cleanup that resets the lab. Testing happens only on systems you own or are explicitly authorized to test, and nothing is ever "completely secure."

Practice with these exercises

• Find open ports on localhost
• Classify an ARP frame