5.3 Core Network Services: DHCP, NTP & TFTP

CREST Practitioner Security Analyst CPSA

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Soft Skills, Legal Framework & Assessment Management

1.1 The Penetration Testing Engagement Lifecycle & Scoping 1.2 Legal Framework: Computer Misuse Act & Compliance 1.3 Understanding, Explaining & Managing Technical Risk 1.4 Record Keeping, Interim Escalation & Reporting Standards

2 Chapter 2: Core Networking: IP Protocols & Network Architectures

2.1 IPv4 and IPv6 Addressing, Subnetting & Header Architecture 2.2 TCP and UDP Transport Protocols & Handshake Mechanics 2.3 ICMP Protocol, Network Diagnostics & Error Messages 2.4 Network Topologies, Switched Media & VLAN Segmentation 2.5 Network Media, Ethernet Standards & Physical Topologies

3 Chapter 3: Cryptography & Secure Communication Protocols

3.1 Symmetric & Asymmetric Cryptographic Algorithms 3.2 Cryptographic Hash Functions, MACs & Digital Signatures 3.3 Secure Protocols: SSL/TLS, IPsec & SSH

4 Chapter 4: Background Information Gathering & OSINT Reconnaissance

4.1 WHOIS Records, Domain Registrars & Autonomous Systems 4.2 DNS Infrastructure, Record Types & Zone Transfers 4.3 Search Engine Reconnaissance, Google Dorking & Information Leakage 4.4 Newsgroups, Mailing Lists & Public Archive Reconnaissance

5 Chapter 5: Networking Equipment & Infrastructure Protocols

5.1 Router & Switch Management: SNMP, SSH & Authentication 5.2 Layer 2 Protocols: ARP, CDP, STP, VTP & Redundancy 5.3 Core Network Services: DHCP, NTP & TFTP 5.4 Wireless Security (802.11) & VoIP Assessment 5.5 Out-of-Band Management, Console Access & Cisco Reverse Telnet

6 Chapter 6: Network Mapping, Nmap Techniques & Target Identification

6.1 Host Discovery Techniques & Ping Sweep Methodologies 6.2 Port Scanning Mechanics: TCP, UDP & Stealth Scans 6.3 OS Fingerprinting, Service Detection & Timing Templates 6.4 Firewall and IDS/IPS Evasion Techniques 6.5 Passive OS & Service Fingerprinting 6.6 Network Access Control Analysis & Firewall Rule Base Review

7 Chapter 7: Vulnerability Identification & Tool Output Analysis

7.1 Vulnerability Scanning Principles & Methodology 7.2 CVE Referencing, CVSS Scoring & Risk Prioritisation 7.3 Banner Grabbing, Service Verification & Manual Triage 7.4 Host Audit Techniques: Processes, Sockets, Patch Levels & Interesting Files

8 Chapter 8: Microsoft Windows Security Assessment & Active Directory

8.1 Active Directory Architecture & Domain Reconnaissance 8.2 Windows User & Group Enumeration via SMB & RPC 8.3 Windows Authentication: NTLM, Kerberos & Password Security 8.4 Windows Patch Management, Local Security & Common Services 8.5 Windows File System, Share & Registry Permissions 8.6 Desktop Lockdown, Citrix Breakout & Common Windows Applications

9 Chapter 9: Unix & Linux Security Assessment & Legacy Services

9.1 Linux/Unix Security Architecture, Permissions & Filesystem 9.2 Unix User Enumeration & Service Discovery 9.3 Network File System (NFS) & RPC Services Assessment 9.4 Legacy Unix Services: R-Services, X11, FTP & Modern SSH 9.5 Unix Remote Information Services: rusers, rwho, finger & systat 9.6 Unix Vulnerability Exploitation & Post-Exploitation Workflow

10 Chapter 10: Web Architectures, Technologies & Testing Methodologies

10.1 Web Server Architecture & the HTTP/HTTPS Protocol 10.2 Web Application Components, Frameworks & State Management 10.3 Web Reconnaissance, Content Discovery & Threat Modelling 10.4 Testing Authentication, Authorization & Session Management 10.5 Web Service Protocols: SOAP, REST & XML Messaging 10.6 Web APIs, Server Extensions & Client-Side Sub-Components

11 Chapter 11: Web Testing Techniques & OWASP Top Vulnerabilities

11.1 Input Validation Vulnerabilities & Parameter Manipulation 11.2 Cross-Site Scripting (XSS): Types, Impact & Defenses 11.3 Cross-Site Request Forgery (CSRF) & Client-Side Attacks 11.4 Command Injection, File Upload Vulnerabilities & API Flaws 11.5 Information Disclosure: Error Messages & Mark-up Leakage 11.6 Injection Beyond SQL: LDAP, XPath, Code & Template Injection 11.7 Source Code Review & Encoded/Cryptographic Value Analysis

12 Chapter 12: Database Security Assessment & SQL Injection

12.1 Database Architectures, Default Ports & Authentication 12.2 SQL Injection (SQLi) Foundations & In-Band Techniques 12.3 Blind SQL Injection & Database Enumeration 12.4 Database Attack Vectors, Stored Procedures & Hardening

5.3 Core Network Services: DHCP, NTP & TFTP

Key Takeaways Explain This Topic AI

Dynamic Host Configuration Protocol (DHCP) operates over UDP ports 67 (server) and 68 (client) through the four-step DORA exchange (Discover, Offer, Request, Acknowledge); unauthenticated access ports are vulnerable to address starvation and rogue server gateway spoofing.

DHCP Snooping mitigates rogue DHCP servers and address pool starvation by filtering untrusted access ports, dropping unauthorized server responses, and building a dynamic binding database that underpins DAI and IP Source Guard.

Network Time Protocol (NTP, UDP 123) operates across a hierarchical Stratum architecture; legacy ntpd implementations supporting the 'monlist' command (CVE-2013-5211) can be exploited to generate distributed denial-of-service (DDoS) reflection attacks with amplification factors exceeding 500x.

Clock desynchronization beyond five minutes breaks Kerberos authentication in Active Directory environments, invalidates X.509 TLS certificate chains, and undermines the evidentiary integrity of forensic timeline reconstruction across security logs.

Last updated: September 2026

5.3 Core Network Services: DHCP, NTP & TFTP

Enterprise local area networks rely on core infrastructure services to provision network addresses, synchronize cryptographic clocks, and deliver device firmware and configuration baselines. Because these foundational protocols were designed during the formative years of internetworking, they emphasize operational simplicity over cryptographic assurance. When compromised, an attacker can hijack client network routing, execute high-magnitude denial-of-service attacks, break identity authentication systems, or extract cleartext administrative credentials. This section explores the operational mechanics, attack vectors, and hardening protocols for DHCP, NTP, and TFTP.

1. Dynamic Host Configuration Protocol (DHCP)

Dynamic Host Configuration Protocol (DHCP) , defined in RFC 2131, automates the assignment of IPv4 addresses, subnet masks, default gateway routers, DNS nameservers, and domain search suffixes. It operates over the User Datagram Protocol (UDP):

UDP Port 67: Destination port for DHCP Servers and Relay Agents.

UDP Port 68: Destination port for DHCP Clients. +-----------------------------------------------------------------------------------+

• | DHCP DORA TRANSACTION SEQUENCE |
• +-----------------------------------------------------------------------------------+
• | |
• | DHCP Client (Port 68) DHCP Server (Port 67) |
• | | | |
• | | ---- 1. DHCP DISCOVER (Broadcast: 255.255.255.255) -------> | |
• | | Src IP: 0.0.0.0, Dst IP: 255.255.255.255 | |
• | | Client Hardware MAC: AA:BB:CC:DD:EE:FF | |
• | | | |
• | | <--- 2. DHCP OFFER (Unicast or Broadcast) ----------------- | |
• | | Offered IP: 192.168.1.50, Subnet: 255.255.255.0 | |
• | | Gateway: 192.168.1.1, DNS: 192.168.1.10, Lease: 86400s | |
• | | | |
• | | ---- 3. DHCP REQUEST (Broadcast: 255.255.255.255) --------> | |
• | | Selects Server IP, Confirms Lease Terms | |
• | | | |
• | | <--- 4. DHCP ACKNOWLEDGE (Unicast or Broadcast) ----------- | |
• | | Finalizes IP Lease; Client Binds Network Parameters | |
• +-----------------------------------------------------------------------------------+
• The DORA Exchange Sequence

DHCP Discover: The unconfigured client broadcasts a datagram searching for active DHCP servers. Because the client has no assigned IP, the source IPv4 address is set to 0.0.0.0 and the destination is the limited broadcast address 255.255.255.255 .

DHCP Offer: A listening DHCP server reserves an available IP from its defined address scope and transmits an offer containing the proposed IP address, subnet mask, default gateway, DNS servers, and lease duration.

DHCP Request: The client broadcasts its acceptance of the selected server's offer. Broadcasting this request notifies all other DHCP servers that offered leases so they can release their reserved addresses back into their pools.

DHCP Acknowledge (ACK): The server commits the lease to its database and transmits an acknowledgment datagram, finalizing the assignment.

• Attack Vectors Against DHCP
• 1. DHCP Starvation Attack

The DHCP address pool (scope) contains a finite number of assignable IP addresses (e.g., 254 addresses in a /24 subnet):

An attacker connects an automated tool (such as yersinia or dhcpstarv ) to an access port.

The tool generates thousands of spoofed DHCP Discover packets, each advertising a uniquely randomized client hardware MAC address in the Ethernet and BOOTP headers.

The legitimate DHCP server responds to each request, exhausting its entire pool of available addresses within seconds.

Result: Legitimate endpoints connecting to the network fail to receive an IP lease, self-assigning a non-routable APIPA address ( 169.254.0.0/16 ) and experiencing a total Denial of Service (DoS).

2. Rogue DHCP Server Attack (Man-in-the-Middle)

Once the legitimate DHCP server is starved (or simply by racing to respond faster than the legitimate server over the local switch backplane):

The attacker deploys an unauthorized Rogue DHCP Server on the local subnet.

When a new victim host broadcasts a DHCP Discover , the rogue server responds first with a crafted DHCP Offer :

Assigned IP: Valid local IP address.

Default Gateway: Set to the Attacker's IP Address .

Primary DNS Server: Set to the Attacker's IP Address (or an attacker-controlled resolver).

When the client accepts this lease, all external traffic and DNS resolution queries are forwarded directly through the attacker's system, establishing a transparent, full Man-in-the-Middle (MitM) position.

Defensive Countermeasure: DHCP Snooping

To prevent rogue DHCP servers and starvation attacks, enterprise switches implement DHCP Snooping : +-----------------------------------------------------------------------------------+

• | DHCP SNOOPING ARCHITECTURE |
• +-----------------------------------------------------------------------------------+
• | |
• | [ Legitimate DHCP Server ] |
• | | |
• | (Trusted Switch Port) <--- Permits DHCP Offers & ACKs |
• | v |
• | [ Layer 2 Switch ] |
• | ^ |
• | (Untrusted Switch Port) <--- Drops DHCP Offers/ACKs; Rate-Limits Discovers |
• | | |
• | [ Rogue Server / Attacker ] |
• +-----------------------------------------------------------------------------------+

Trusted Ports: Uplink interfaces connected directly to authorized DHCP servers or trunk links. All DHCP traffic (including Offers and ACKs) is permitted.

Untrusted Ports: Standard access ports connecting to end-user devices. The switch inspects all incoming DHCP packets on these ports:

Any DHCP Offer , DHCP ACK , or DHCP NAK originating from an untrusted port is immediately dropped , blocking rogue DHCP servers.

DHCP Discover packet transmission rates are throttled (rate-limited) to prevent starvation flooding.

DHCP Snooping Binding Database: The switch dynamically builds an internal table tracking MAC Address , Assigned IP , Lease Time , VLAN ID , and Switch Port . This database serves as the authoritative verification engine for Dynamic ARP Inspection (DAI) and IP Source Guard (IPSG) .

2. Network Time Protocol (NTP)

Network Time Protocol (NTP) , defined in RFC 5905, operates over UDP port 123 to synchronize system clocks across distributed computers, routers, and infrastructure appliances.

The Stratum Hierarchy

NTP organizes time providers into a hierarchical structure called Stratums to prevent synchronization loops and maintain timing precision: +-----------------------------------------------------------------------------------+

• | NTP STRATUM HIERARCHY |
• +-----------------------------------------------------------------------------------+
• | Stratum 0: Reference Clocks (Atomic Cesium Clocks, GPS Satellites, CDMA) |
• | (Not connected to networks; connected directly to Stratum 1 servers) |
• +-----------------------------------------------------------------------------------+
• | Stratum 1: Primary Time Servers directly attached to Stratum 0 physical clocks. |
• | Act as network time servers for national/global backbones. |
• +-----------------------------------------------------------------------------------+
• | Stratum 2: Secondary Servers that synchronize over network paths with Stratum 1. |
• | Enterprise boundary NTP servers typically operate at Stratum 2 or 3. |
• +-----------------------------------------------------------------------------------+
• | Stratum N: Synchronize with Stratum (N-1) servers across internetworks. |
• | Maximum valid stratum level is 15. |
• +-----------------------------------------------------------------------------------+
• | Stratum 16: Indicates an unsynchronized, invalid, or unreachable time source. |
• +-----------------------------------------------------------------------------------+
• NTP Amplification DDoS Attacks (CVE-2013-5211)

Because NTP runs over connectionless UDP, the source IP address in request packets can be forged. Attackers weaponized this architectural characteristic by targeting an administrative query function in older versions of the ntpd daemon known as monlist :

The monlist Command: A diagnostic feature intended for administrators. When queried via ntpdc -c monlist <target> , the NTP server returns a list of the last 600 IP addresses that communicated with that NTP server.

Amplification Mechanism: Because 600 IP addresses cannot fit into a single UDP datagram, the server responds with up to 100 individual UDP packets (totaling approximately 48,000 bytes).

An attacker sends a single spoofed request packet of roughly 234 bytes with the Source IP set to the Victim's IP Address .

The vulnerable NTP server floods the victim with 48,000 bytes of response data, achieving an amplification factor exceeding 200x to 500x .

When thousands of open NTP servers are probed simultaneously by a botnet, the aggregate reflection traffic overwhelms enterprise internet pipes, generating multi-hundred-gigabit DDoS volumes.

Mitigation: Disable the monlist functionality by adding disable monitor or restricting queries via restrict default kod nomodify notrap nopeer noquery in ntp.conf , and upgrading ntpd to version 4.2.7p26 or newer. NTP monlist Reflection Attack Flow:

• [ Attacker / Botnet ] ──► Sends 234-Byte monlist Query (Spoofed Src IP: Victim) ──► [ Vulnerable NTP Server ]
• │
• [ Target Victim ] ◄── Overwhelmed by 48,000 Bytes of Amplified Responses (500x) ──────────┘
• Systemic Security Impact of Clock Desynchronization

Accurate network time is a prerequisite for enterprise security controls:

Kerberos Authentication Failure: Active Directory and Kerberos V5 rely on timestamps within Authenticator tickets to prevent replay attacks. The default maximum allowable clock skew between a client workstation and the Key Distribution Center (KDC) is 5 minutes (300 seconds). If system clocks drift beyond this limit, authentication fails completely, preventing user logons and locking domain workstations out of network resources.

Forensic Timeline Invalidation: During incident response, forensic analysts aggregate logs from firewalls, Active Directory domain controllers, web servers, and endpoint detection agents. If clocks are desynchronized, chronological event reconstruction across SIEM tools becomes impossible, masking the true path of an adversary.

PKI & TLS Certificate Verification: Digital certificates (X.509) specify exact Not Before and Not After validity timestamps. A skewed system clock may cause a host to reject perfectly valid TLS certificates (triggering service downtime) or erroneously accept expired or prematurely issued certificates, bypassing security protections.

3. Trivial File Transfer Protocol (TFTP)

Trivial File Transfer Protocol (TFTP) , defined in RFC 1350, is a bare-bones file transfer protocol operating over UDP port 69 .

Inherent Protocol Deficiencies

Unlike FTP or SSH/SFTP, TFTP was engineered to fit within tiny Read-Only Memory (ROM) chips on diskless workstations and network bootstrap environments:

No Authentication: There is no username or password verification; anyone capable of sending a UDP packet can request a file.

No Encryption: All commands, file payloads, and headers are transmitted in cleartext.

No Directory Permissions: TFTP implementations lack access control lists (ACLs) or granular file ownership enforcement; if a file exists within the TFTP root directory, it can be read or overwritten.

Stop-and-Wait Transport: Operates via a simple lock-step transfer model where every 512-byte data block must be individually acknowledged before the next block is transmitted.

Penetration Testing & Infrastructure Risk Profile

Despite its total lack of security, TFTP remains widely deployed in networking environments:

Router & Switch Configuration Harvesting: Network administrators frequently use TFTP to back up and restore Cisco IOS configurations ( copy running-config tftp://... ). In penetration testing, if an attacker discovers an open internal TFTP server or leverages an SNMP read-write community string, they can force network devices to upload their configuration files directly to an attacker-controlled TFTP listener, exposing enable passwords, pre-shared VPN keys, and network ACLs.

VoIP Infrastructure Exploitation: Enterprise IP phones (e.g., Cisco Unified IP Phones, Avaya, Polycom) automatically boot via DHCP Option 150 or 66, which directs the phone to a TFTP server IP. The phone connects to TFTP over UDP 69 to download firmware binaries and XML configuration files (e.g., SEP<MAC_ADDRESS>.cnf.xml ). These XML configuration files frequently contain:

Cleartext SIP authentication usernames and passwords.

PBX controller IP addresses.

Local web interface administrative credentials.

• Extension mappings and softkey configuration profiles. # Extracting an IP phone configuration file via TFTP
• tftp 192.168.1.15
• tftp> get SEP001122334455.cnf.xml

# Inspecting XML payload reveals cleartext credentials:

# <sipPassword>SuperSecretVoipPass!</sipPassword>

Hardening Recommendations: Restrict TFTP services strictly to isolated provisioning VLANs, prohibit TFTP traversal across corporate routed boundaries via firewall rules, and migrate network device backups and VoIP provisioning to secure alternatives, such as Secure Copy Protocol (SCP), SFTP, or HTTPS.