Full Report
When conducting a red team exercise, we want to blend in as much as possible with the existing systems on the target network. For most large networks, that means looking like a Windows machine when you request a DHCP address. In a lot of cases, though, the machine that we connect to the target network is not going to be running Windows, but more likely, a variant of Linux. By default, Linux DHCP requests don’t look the same as Windows DHCP requests. One way of visualising this would be to take packet captures from Wireshark, copying DHCP requests into a text file and comparing them using Meld.
Analysis Summary
# Tool/Technique: Mimicking Windows DHCP Requests from Linux Clients
## Overview
This technique involves modifying the configuration of a Linux DHCP client (specifically `dhclient` on Kali Linux) to make its DHCP requests functionally and structurally identical to those sent by a Windows 10 machine. The primary goal is to achieve stealth and blend in with existing Windows systems during red team engagements by avoiding detection based on anomalous DHCP option sequences or values in network logs.
## Technical Details
- Type: Technique
- Platform: Linux (specifically Kali distribution using `dhclient`)
- Capabilities: Customizing DHCP option requests, overriding default values, avoiding local lease file correlation.
- First Seen: The technique is described in an article published July 20, 2020, detailing the specific configuration adjustments made.
## MITRE ATT&CK Mapping
- **TA0008** - Lateral Movement
- **T1550** - Use Alternate Authentication Material
- *Note: While this technique is primarily about network reconnaissance/initial access blending, anomalous network activity can be flagged.*
- **TA0007** - Discovery
- **T1046** - Network Service Scanning
- *DHCP interaction is a form of network surveying.*
- **TA0003** - Persistence
- *By blending in during the initial network connection (lease acquisition), an adversary improves long-term stealth.*
## Functionality
### Core Capabilities
- **DHCP Option Customization:** Modifying `/etc/dhcp/dhclient.conf` to request the same set of DHCP options as Windows clients (e.g., options 43, 249, 252, in addition to standard ones).
- **Vendor Class Identifier Spoofing:** Setting the `send vendor-class-identifier` to `"MSFT 5.0"` to explicitly identify as a Microsoft client to the DHCP server.
- **Hostname/FQDN Spoofing:** Setting `send host-name` and `send fqdn.fqdn` to match target naming conventions (e.g., using a standard corporate hostname format).
- **Client Identifier Setting:** Configuring `send dhcp-client-identifier = hardware` to mimic standard Windows behavior.
- **Lease File Control:** Using `dhclient -lf /dev/null` to prevent the client from sending previously known IP addresses associated with different leases/networks, ensuring a cleaner request profile.
### Advanced Features
- **Parameter Request List Normalization:** Manually adjusting the order of options specified in the `request` stanza to match the exact sequence used by Windows 10 clients, thereby achieving an identical `Option 55 Parameter Request List`.
- **OUI Spoofing Preparation:** Suggests monitoring live traffic (`tcpdump`) to extract the Organizationally Unique Identifier (OUI) used by existing legitimate DHCP clients and using tools like `macchanger` to spoof the MAC address to fall within a trusted OUI range.
## Indicators of Compromise
- File Hashes: N/A (Configuration modification)
- File Names: `/etc/dhcp/dhclient.conf` (Configuration file modification)
- Registry Keys: N/A
- Network Indicators:
- DHCP Request Option 60 value: `"MSFT 5.0"` (when observed from a non-Windows OUI).
- Unusual sequence of DHCP Option 55 (Parameter Request List) originating from a Linux Host-ID.
- DHCP Client Identifier Option 61 using hardware address format typical of Windows OS deployment tools or clients if the underlying hardware type is suspicious.
- Behavioral Indicators:
- Linux client requesting an identical set of DHCP options found only on Windows systems.
- Execution of `dhclient` with the `-lf /dev/null` flag.
## Associated Threat Actors
The article frames this as a technique used during **Red Team Exercises**, implying proactive defensive testing or advanced pentesting activities rather than attribution to specific threat groups. However, sophisticated APTs focused on long-term internal network presence would benefit from this blending technique.
## Detection Methods
- **Signature-based detection:** Detecting the exact sequence of DHCP Option 55 values that match Windows profiles being sent from non-Windows operating system identifiers (if the OS is detectable via other means).
- **Behavioral detection:** Flagging DHCP requests where the Vendor Class Identifier (Option 60) explicitly states `"MSFT 5.0"` originating from devices not identified as Windows hosts by network management ingress checks.
- **YARA rules:** N/A (Applies to network traffic analysis, not static files).
- **OUI Analysis:** Monitoring for OUIs associated with non-standard virtual machines or known penetration testing hardware if MAC address spoofing is not performed correctly.
## Mitigation Strategies
- **Network Policy Enforcement:** Implement strict DHCP server policies that only allow known, vetted MAC addresses or hardware identifiers to receive leases.
- **DHCP Logging Analysis:** Actively monitor DHCP logs for anomalous Option 60 values or unusual Option 55 request sequences that deviate from the established environment baseline (e.g., seeing an unexpectedly high number of hosts claiming to be "MSFT 5.0" if the environment is predominantly macOS/Linux).
- **OS Fingerprinting Consistency:** Ensure internal devices adhere closely to manufacturer-standard DHCP request patterns. Deviation, even when subtle, should be observable when analyzed en masse.
## Related Tools/Techniques
- **`macchanger`:** Used in conjunction to randomize the MAC address OUI to blend in with legitimate clients.
- **DHCP Spoofing/Rogue DHCP:** While this is configuration modification for blending, related security practices involve monitoring for unauthorized DHCP traffic.
- **T1189:** Drive-by Compromise (Often involves initial network foothold where DHCP fingerprinting might occur).