> ## Content Index > Fetch the complete content index at: https://niklas-heringer.com/llms.txt > Use this file to discover other available public pages before exploring further. # Interview Prep Series: Part Two – Technical Deep Dive & Groundwork - URL: https://niklas-heringer.com/penetration-testing/interview-prep-part-two/ - Published: 2025-06-30T18:54:00.000Z - Updated: 2025-11-19T19:19:33.000Z - Description: Digging into technical fundamentals and real interview questions to sharpen my baseline as a pentester. Inspired by Steflan Security’s interview cheat sheet & my 2nd Cirosec Interview - Author: Niklas Heringer - Tags: interview-prep, penetration-testing > In this part, we'll go down the technical question side using a [very nice cheat sheet](https://steflan-security.com/penetration-testing-interview-questions-cheat-sheet/?ref=niklas-heringer.com) i found. # Core Malware Categories | **Category** | **Self-Replicating** | **Needs User Action** | **Spreads How** | **Main Function** | | -------------- | -------------------- | --------------------- | -------------------------------------------- | ------------------------------------------- | | **Virus** | Yes | Yes | Via infected files (opened/executed by user) | Infect files and spread via them | | **Worm** | Yes | No | Exploits across networks, no user needed | Autonomous spread across systems | | **Trojan** | No | Yes | Disguised as legit software, user installs | Deliver malicious payloads deceptively | | **Spyware** | No | Both variants exist | Hidden in software or browser | Steal sensitive data (creds, usage, input) | | **Adware** | No | Yes | Software bundles, often with user consent | Show ads, track behavior | | **Rootkit** | No | No (covert) | Installed via trojans or exploits | Hidden persistent access | | **Logic Bomb** | No | Yes (initially) | Embedded code, activates on condition | Triggered damage or action at specific time | ## Examples of Malware Payloads / Famous Hybrids | **Malware Name** | **Type/Category** | **Delivered Via** | **Purpose / Impact** | | ---------------- | ------------------------------- | ---------------------------- | ------------------------------------------- | | **WannaCry** | Ransomware | Worm (SMB exploit) | Encrypts files, demands ransom | | **NotPetya** | Wiper (disguised as ransomware) | Trojan / Worm combo | Data destruction, disguised as ransom | | **Emotet** | Trojan loader | Email (macro virus) | Drops additional malware (ransomware, etc.) | | **Zeus** | Trojan + Spyware | Phishing / Drive-by download | Steals banking credentials | | **BlackLotus** | Rootkit | Bootkit / UEFI exploit | Bypasses Secure Boot, persistence | | **ILOVEYOU** | Virus | Email attachment | Mass file infection & propagation | | **Stuxnet** | Worm + Logic Bomb | USB / PLC targeting worm | Attacked industrial systems (Iran nukes) | --- # Spontaneous Questions Here, i will do a section where i'll freely answer and then check my answers accordingly. ## "What is the OSI model and what are its layers?" The OSI models serves to illustrate and break down data flow in computers - it encompasses 7 layers, i'll try to come up with the different ones. 1. **Physical Layer:** diret Ethernet connections, MAC addresses are important here 2. Is this Data Link? i think so - i'll have to look up what's going on on this layer 3. I know 3 and 4 are "Network" and "Transport".. Network shouuld come first? and then the Transport Layer is all about TCP and UDP. 4. as stated in 3 5. no clue 6. no clue 7. **Application Layer** \- here is the connection to human users, the interaction layer with applications. > That wasn't great haha. Let's rework. ### The OSI model explained #### Layer 1: Physical Layer This layer is responsible for the **actual, physical connections** between devices - it contains information in the form of bits. > Here, our devices transmit *individual bits* from one node to the next, converting signals into 0s and 1s and sending them to the **Data Link Layer**. **Common Devices:** Hub, Repeater, Modem, Cables, ... #### Layer 2: Data Link Layer This layer is responsible for **node-to-node message delivery**, transferring data error-free from one node to another over layer 1. > In this layer, the MAC address is utilized to get a packet (here called a **frame**) to it's right destination. Layer 2 combines **Logical Link Control (LLC) and Media Access Control (MAC)**, responsible for data transmission is the **NIC (Network Interface Card).** **Common Devices:** Switches, Bridges, ... Addressing, error control, flow (& rate) control, access control - all done here. #### Layer 3: Network Layer In This layer, packets can be transmitted from one host to another in **different** networks, aswell as packet routing (selecting the **shortest path** to the data destination.) > I remember algorithms for such pathing, such as the **dijkstra algorithm**, from my beginning year of uni, awesome stuff. Layer 3 routes and cares for logical adressing through IP addresses (unique and universal addresses). #### Layer 4: Transport Layer Layer 4 **transports** (who would've thought) data, here-called **Segments**, end-to-end. It provides the acknowledgement of successful transmission and re-transmits if an error occurs. > In this layer, TCP, UDP, PPTP and alike protocols are used. Messages are broken down coming from the 5th layer/ put together going to the 5th layer. #### Layer 5: Session Layer This layer is responsible for **establishment, usage and termination** of connections - it adds checkpoints, acting as syncrhonization points in the data, helps identifies errors. > Connections can be in half-duplex or full-duplex (one-way or both-ways). #### Layer 6: Presentation Layer/ Translation Layer Here, the data from the application layer are extracted and **manipulated** as per **required format** necessary for successful transmission over the network. > Protocols handling this are e.g. TLS/SSL - standards or formats for encoding data here are e.g. JPEG, MPEG, GIF, ... #### Layer 7: Application Layer This is the real interaction layer, where we request and are returned **content** \- this can happen via SMTP, FTP, DNS, or other such protocols and services. > The presentation of the 7 layers this way is rather simple and excludes a lot of detail, but in interviews, it is unlikely they want to go in such depths. Just remember [this](https://www.geeksforgeeks.org/open-systems-interconnection-model-osi/?ref=niklas-heringer.com): **Application Layer:** Applications create the data. **Presentation Layer:** Data is formatted and encrypted. **Session Layer:** Connections are established and managed. **Transport Layer:** Data is broken into segments for reliable delivery. **Network Layer:** Segments are packaged into packets and routed. **Data Link Layer:** Packets are framed and sent to the next device. **Physical Layer:** Frames are converted into bits and transmitted physically. --- ## What is the difference between TCP and UDP? I know that TCP is fast but sloppy, while UDP is slow but very accurate - that being due to the way their handshakes work i thinkk.. **Let's see!** ### The difference between TCP and UDP Interesting.. not only did i **remember it wrong**, the outcome is a whole different one again.. Let's **break it down.** | Feature | **TCP** | **UDP** | | --------------- | ---------------------------------------- | -------------------------------------- | | **Type** | Connection-oriented | Connectionless | | **Handshake** | Yes – 3-way (SYN → SYN-ACK → ACK) | No handshake | | **Reliability** | Guaranteed delivery (retransmits, order) | Best effort – no guarantee of delivery | | **Speed (Raw)** | Slower, more overhead due to reliability | Faster, minimal overhead | | **Use Cases** | Web, SSH, FTP, Email | DNS, VoIP, video streaming, SNMP | > UDP is technically faster because it skips the handshake and **all reliability mechanisms** \- yet in practice, if you've ever done it, i'm sure you've noticed: UDP scanning & communication take **forever**, even small nmap scans take several minutes even with only a few ports involved. ### Why Do UDP Scans Seem SLOWER Than TCP Scans? - No handshake → no instant way to **confirm** an open port. - Firewalls often drop UDP packets silently → scanner has to **wait for timeouts**. - Many services don’t respond on closed UDP ports → scanner can't distinguish "filtered" from "open|filtered" easily. - Tools like Nmap must retry and wait longer to detect anything reliably. 💡 Bottom line: UDP isn’t slow, but scanning it is because it ****lacks clear response behavior**. So my answer should've been: > "TCP is reliable but slower due to its overhead; UDP is faster but unreliable. However, UDP scanning is slower in practice because it lacks predictable responses and often runs into firewall issues." ## What is DNS? For this we don't need to check the right answer: > The **Domain Name System** translates *domain names* to *ip adresses* (and vice versa if you do a **Reverse DNS Lookup**). So if you search: `google.com` → `142.250.184.206` (or similar) | Action | DNS Used? | Direction | Notes | | ---------------------------- | --------- | -------------- | -------------------------- | | Typing a URL in browser | Yes | Forward lookup | Domain → IP | | ping google.com | Yes | Forward lookup | Required to resolve the IP | | Looking up IP owner manually | (maybe) | Reverse lookup | If PTR record is available | --- > At this point, my second interview mit cirosec was due. Some of the questions were.. unexpected, i'll dedicate the rest of this article towards them. # Real Interview Questions ## Question 1: SSH key-based authentication ### The Problem > You have **multiple VMs** in a network, and you’re getting tired of typing your password every time you SSH from one to another. ### The Goal > You want to **authenticate securely without typing your password each time** you connect to another VM. ### The Solution The solution is **SSH Keys** \- they use **asymmetric cryptography**: - The **private key** stays on the VM you are SSHing *from* - The **public key** is placed on the VM you are SSHing *to* > Let's illustrate and say you'd like to SSH from `VM_1` to `VM_2`, `VM_3` and `VM_4` **without typing a password**. **Step 1**: Generate an SSH Key Pair **once** on your **source VM** (`VM_1`). ```bash ssh-keygen -t rsa -b 4096 ``` This creates: - your private key `~/.ssh/id_rsa` - your public key `~/.ssh/id_rsa.pub` > If you set a **passphrase** when generating the key (recommended), you’ll be asked to enter it every time unless you use an **SSH Agent** to manage the key securely in memory. To avoid typing your key's passphrase every time: ```bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa ``` > This caches your **decrypted private key** in memory for the session, so you won’t be prompted again **until the session ends**. **Step 2**: Copy the Public Key to each Target VM ```bash ssh-copy-id -i ~/.ssh/id_rsa.pub user@vm2 ssh-copy-id -i ~/.ssh/id_rsa.pub user@vm3 ssh-copy-id -i ~/.ssh/id_rsa.pub user@vm4 ``` > `-i ~/.ssh/id_rsa.pub` is only necessary if you have multiple key pairs in place, if not, `-i ~/.ssh/id_rsa.pub` is the default. These commands append your selected public key to the file `~/.ssh/authorized_keys` on each respective VM. > **Now each of these machines trusts your private key holder, `VM_1`**. **Step 3**: Test SSH Access Now, from `VM_1`, you can just: ```bash ssh user@vm2 ssh user@vm3 ssh user@vm4 ``` --- ## Question 2: SSH Certificates vs Public/Private Key Authentication ### The Problem > You’ve learned how public/private keys allow passwordless SSH access. But in environments with **many users and systems**, managing and rotating keys can become **tedious and insecure**. ### The Goal > You want to understand how **SSH certificates** improve over plain public key authentication, and what roles **Certificate Authorities (CAs)** play in that model. ### The Comparison Both **public/private keys** and **certificates** use **asymmetric cryptography**, but certificates introduce a **trusted third party (CA)** to help with **trust management**. Let’s break down the difference. ### Traditional SSH Key-Based Authentication (What You Already Know) - You generate a key pair: `id_rsa` and `id_rsa.pub` - You copy the **public key** to the target machine (`~/.ssh/authorized_keys`) - That machine directly **trusts your public key** > The trust is **manually managed** \- each machine must individually have your public key. **Problems**: - Hard to scale in big environments - Revoking access is manual - No identity verification - any key works if it’s in `authorized_keys` ### SSH Certificates and Certificate Authorities (CAs) **SSH Certificates** are **signed public keys**. The key idea: > Instead of trusting every user key directly, the server trusts a **Certificate Authority (CA)** that signs user keys. #### How it works: 1. You generate your key pair as usual. 2. An **SSH CA** (trusted entity) **signs your public key**, creating a **certificate**. 3. The server is configured to **trust the CA’s public key**. 4. When you connect, the server checks: - Is the certificate signed by the trusted CA? - Is the certificate valid (time-limited, role-limited)? - Is the principal (username) authorized? > The server does **not** need to store individual user public keys anymore - just the CA's public key. ### Core Differences | Feature | Public/Private Keys | SSH Certificates | | ---------------- | ------------------------------------- | -------------------------------------- | | Trust Model | Manual trust of each key | Central trust in CA | | Scalability | Poor in large networks | Excellent | | Revocation | Manual (remove key from every server) | Easier (update CA, expire certs) | | Identity Binding | None | Certificate binds identity/role to key | | Expiration | Not built-in | Built-in expiration and constraints | ### What is a Certificate Authority (CA)? A **CA** is a **trusted signer** that issues SSH certificates. It has: - A **CA private key** (used to sign) - A **CA public key** (installed on servers to verify signatures) In SSH terms: - Users present **certificates** signed by the CA - Servers trust the **CA**, not each individual user key ### Real-World Use Cases - Large-scale infrastructure (e.g., cloud services, enterprise networks) - Temporary access (e.g., expiring certs for contractors) - Role-based access control (cert contains user roles) - Centralized revocation and rotation ### Example: Creating and Using SSH Certificates #### 1\. Create a CA Key Pair (done once by the administrator) ```bash ssh-keygen -f /etc/ssh/ca_key ``` This generates: - `/etc/ssh/ca_key` – the CA private key (used to sign) - `/etc/ssh/ca_key.pub` – the CA public key (distributed to servers) #### 2\. Sign a User’s Public Key with the CA Assuming the user has a key `id_rsa.pub`, sign it like this: ```bash ssh-keygen -s /etc/ssh/ca_key -I user_cert -n username -V +52w ~/.ssh/id_rsa.pub ``` - `-s` specifies the CA private key - `-I` sets a certificate ID - `-n` sets the principal (e.g. username) - `-V` sets the validity period (here: 52 weeks) This produces a certificate file: `id_rsa-cert.pub` #### 3\. Configure the Server to Trust the CA On each SSH server, edit `/etc/ssh/sshd_config`: ``` TrustedUserCAKeys /etc/ssh/ca_key.pub ``` Then restart the SSH service: ```bash sudo systemctl restart ssh ``` Now the server will trust any user presenting a certificate signed by that CA. #### 4\. Connect Using the Certificate On the client: ```bash ssh -i ~/.ssh/id_rsa -i ~/.ssh/id_rsa-cert.pub user@host ``` Or configure both in `~/.ssh/config` for convenience. > The client presents the certificate, and the server checks its validity and CA signature - no need for the server to know the user’s key in advance. --- ## Question 3: Private Key Management in Linux and Windows ### The Problem > SSH and certificate-based authentication rely heavily on **private keys**. If the private key is leaked, stolen, or misused, **your access is compromised** \- possibly even full root access. So understanding **where and how private keys are stored and protected** is crucial. ### The Goal > You want to understand how **private keys are managed**, stored, and protected in both **Linux** and **Windows** environments, and how to avoid common pitfalls in key handling. ### Private Key Management in Linux In Linux, private keys are typically managed by the user via OpenSSH and are stored in the user’s home directory. #### Where: ``` ~/.ssh/id_rsa # Default private key ~/.ssh/id_ecdsa # Alternative key types (ECDSA, ED25519, etc.) ``` #### How: **Permissions** are critical. The `.ssh` directory and private key file must be **restricted**: ```bash chmod 700 ~/.ssh chmod 600 ~/.ssh/id_rsa ``` **SSH Agent** is used to securely load passphrase-protected keys into memory for session-based use: ```bash eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_rsa ``` #### What: - The private key is a plain text file unless encrypted with a **passphrase**. - The format is PEM (base64) or the newer OpenSSH format. #### When: - Created during `ssh-keygen`, used during each SSH authentication attempt. - Loaded into memory only when needed (or at login, if configured). #### Why: - Ensures secure, passwordless access without exposing credentials. - Avoids repeated password entry while maintaining a strong crypto-based identity. ### Private Key Management in Windows On Windows, there are a few contexts depending on the tools in use: **PuTTY**, **OpenSSH**, or **WSL**. #### Where: **Windows OpenSSH (native since Windows 10):** ``` C:\Users\\.ssh\id_rsa ``` **PuTTY (with Pageant):** - Uses `.ppk` (PuTTY Private Key) format - Keys are stored manually by the user, often outside `.ssh` **Windows Subsystem for Linux (WSL):** - Follows Linux conventions: `~/.ssh/id_rsa` inside WSL filesystem #### How: **Windows OpenSSH** works similarly to Linux: - Use `ssh-agent` and `ssh-add` - Keys must have correct permissions **PuTTY/Pageant**: - Keys are loaded into **Pageant**, a background agent - GUI-based management of keys - Converts `.pem` → `.ppk` with `puttygen` #### What: - OpenSSH format (same as Linux) or `.ppk` (PuTTY) - Optional passphrase for encryption - Can be stored in plain text if no passphrase is used (risk!) #### When: - Used during remote SSH logins (via PowerShell, CMD, PuTTY, or WSL) - Loaded into memory via agent or command line #### Why: - Enables passwordless, secure authentication to servers - Centralized, portable identity (e.g., shared with Git clients or remote admins) ### Best Practices (Linux and Windows) - Always use a **strong passphrase** when generating keys - Use **ssh-agent** (or **Pageant**) to avoid typing passphrase repeatedly - Protect key files with strict **permissions** - Never store keys on shared drives or send over insecure channels - Use **hardware-backed storage** (e.g., YubiKeys) for high-security environments - Use **different key pairs** for different roles or environments --- ## Question 4: Routing Tables in Routers ### The Problem > You know that routers are responsible for directing traffic in a network, but you want to understand **how** they decide **where** to send packets. What do **routing tables** look like, and how do they **work internally**? ### The Goal > You want to understand how routers use **routing tables** to determine packet paths, what information these tables contain, and how this affects traffic flow and redirection in real-world networks. ### What Is a Routing Table? A **routing table** is a data structure used by routers (and hosts) to determine the **next hop** for a packet based on its **destination IP address**. > Each entry tells the router: "If the destination IP is in this range, forward the packet to this gateway via this interface." Routing decisions are made by **matching the destination IP** of a packet against entries in the routing table - the most specific match (longest prefix) wins. ### What Does a Routing Table Contain? Each entry (route) in the table typically includes: - **Destination**: The network or IP address range (e.g., `192.168.1.0/24`) - **Netmask or Prefix**: Defines the size of the destination network - **Gateway (Next Hop)**: The IP of the next router on the path - **Interface**: The local network interface used to reach the next hop - **Metric**: Cost or preference value (used in dynamic routing) ### Example Routing Table (Linux `ip route` output) ```bash default via 192.168.1.1 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100 10.10.0.0/16 via 192.168.1.254 dev eth0 ``` Explanation: 1. `default via 192.168.1.1 dev eth0` - All unknown traffic (default route) is forwarded to `192.168.1.1` via `eth0` 2. `192.168.1.0/24 dev eth0` - Traffic for the local LAN is sent directly via `eth0` (no gateway needed) 3. `10.10.0.0/16 via 192.168.1.254 dev eth0` - For packets to the `10.10.*.*` network, use `192.168.1.254` as next hop ### How Routing Decisions Are Made When a packet arrives at a router: 1. The router examines the **destination IP**. 2. It looks for the **best matching route** in the routing table (most specific match). 3. It forwards the packet to the **next hop** or **directly** to the destination. > If no matching route is found, and no default route is defined, the packet is dropped. ### Static vs Dynamic Routing **Static routing**: Routes are manually configured by the admin. - Simple, predictable - Not adaptive to network changes **Dynamic routing**: Routes are learned via protocols like **OSPF**, **BGP**, **RIP** - Automatically update routes - Scalable and fault-tolerant ### Why It Matters in Pentesting - Routing tables reveal **network segmentation** and **reachable subnets** - You can manipulate routes in pivoting scenarios (e.g., add static routes) - Routing misconfigurations can expose internal systems - Route hijacking or injection (e.g., via BGP attacks) can reroute traffic --- ## Question 5: DHCP – Requesting and Assigning IP Addresses ### The Problem > You join a network and your machine gets an IP address automatically - but how? What if you want to request a new IP? What’s happening behind the scenes? ### The Goal > You want to understand how **DHCP** works, what happens during an IP request, and how to manually request a new IP on systems like **Windows**. ### What is DHCP? **DHCP** stands for **Dynamic Host Configuration Protocol**. It is a **network management protocol** used to automatically assign IP addresses and other network configuration (e.g., gateway, DNS) to clients joining a network. > Instead of manually setting an IP address, the client **asks**, and the **DHCP server responds** with an available address and config. ### How DHCP Works (4-Step Process) When a client (e.g., your laptop) connects to a network and has no IP yet, the DHCP process kicks in - often called **DORA**: 1. **Discover**: The client broadcasts a DHCPDISCOVER message to find available DHCP servers. 2. **Offer**: A DHCP server replies with a DHCPOFFER - an available IP address and other config options. 3. **Request**: The client responds with a DHCPREQUEST - "Yes, I want that IP". 4. **Acknowledge**: The server finalizes the process with a DHCPACK - confirming the lease of that IP. > The IP is usually leased for a set period. When the lease is about to expire, the client can **renew** it. ### What Info Does DHCP Provide? - **IP address** - **Subnet mask** - **Default gateway** - **DNS server(s)** - **Lease duration** ### How to Request a New IP in Windows To manually release and renew your IP via DHCP in Windows: #### 1\. Open Command Prompt as Administrator #### 2\. Release current IP address: ```cmd ipconfig /release ``` This tells the system to give up its current IP and stop using it. #### 3\. Request a new IP address: ```cmd ipconfig /renew ``` This triggers a fresh DHCP discovery → offer → request → acknowledge cycle. > Note: You might get the same IP again, depending on the DHCP server and lease history. ### Why This Matters in Pentesting - Knowing how DHCP works helps identify **network boundaries** - DHCP can be **abused or spoofed** (e.g., rogue DHCP servers handing out malicious configs) - You can trigger DHCP manually to **change your IP** or reinitialize your network stack - Understanding DORA helps when analyzing traffic with **Wireshark** or performing **network-based attacks** --- ## Question 6: CSRF vs SSRF ### The Problem > You often hear about CSRF and SSRF vulnerabilities in web applications. They sound similar, but what exactly do they mean, how do they differ, and what are the technical details behind each? ### The Goal > You want to clearly understand what CSRF and SSRF are, how they work at the HTTP level, and what makes them fundamentally different in purpose, origin, and impact. ### CSRF: Cross-Site Request Forgery **CSRF** is an attack where a malicious site tricks a user's browser into sending unintended requests to a target site where the user is already authenticated. The core idea: the **attacker leverages the victim's browser** and **existing session cookies** to perform unauthorized actions on a web application where the victim is logged in. #### How it works 1. The victim is logged in to a web application (e.g. banking site) with a valid session cookie. 2. The attacker hosts a malicious page that contains a hidden HTTP request (e.g. auto-submitting form or `` tag). 3. The victim visits the malicious page, and the browser **automatically includes session cookies** in the forged request. 4. The server receives the request, sees the valid session, and processes it as if it came from the user. #### Example (forged POST request) ```html
``` > If the user is logged into `bank.com`, this request executes silently with their session. #### Key points - The **victim is the authenticated user** - The **attacker controls the request origin** - The **target server trusts the user**, not realizing the request is forged ### SSRF: Server-Side Request Forgery **SSRF** is an attack where the attacker tricks a vulnerable server into sending HTTP requests to arbitrary destinations, often to internal services not directly exposed. The core idea: the **attacker controls the request destination**, but the **request is sent by the vulnerable server itself**. #### How it works 1. The application accepts a user-supplied URL or hostname (e.g. to fetch metadata, preview a link, etc.). 2. The attacker supplies a crafted URL pointing to an internal resource, such as `http://localhost:8000/admin`. 3. The server makes the HTTP request on behalf of the attacker and returns the result or uses it internally. #### Example (URL input field) User input: ``` http://169.254.169.254/latest/meta-data/ ``` If the server blindly fetches the content, it might leak AWS instance metadata or allow lateral movement in cloud environments. #### Key points - The **victim is the vulnerable server** - The **attacker controls the target of the request** - The **request is initiated server-side**, bypassing client-side access controls ### Technical Differences | Aspect | CSRF | SSRF | | ---------------- | ------------------------------------- | -------------------------------------- | | Origin | Victim's browser | Vulnerable server | | Victim | Authenticated user | Internal services or the server itself | | Attacker control | Controls request content | Controls request destination | | Prerequisites | Victim must be authenticated | Application must accept remote URLs | | Main abuse | Unauthorized actions via user session | Access to internal services or files | | Mitigations | CSRF tokens, SameSite cookies | Input validation, URL allowlists | ### Summary CSRF abuses **user trust and session context** to forge actions. SSRF abuses **server trust and network topology** to reach targets it should not be able to access. Both are serious, but they target different components and require different protections. --- ## Question 7: What is ARP and How Does It Work ### The Problem > You see devices communicating using IP addresses, but switches and NICs operate with MAC addresses. How does a device find out the MAC address of an IP it's trying to reach? How is this assignment made and what’s actually happening on the network? ### The Goal > You want to understand how the Address Resolution Protocol (ARP) maps IP addresses to MAC addresses, how ARP requests and replies work, and how this is handled on both local devices and networks. ### What is ARP **ARP (Address Resolution Protocol)** is a Layer 2 protocol used to resolve an IP address to a MAC address on a local network segment. > It's the mechanism that allows a device to say: "I know the IP address I want to talk to, but what's the MAC address to reach it?" ### How ARP Works When a device (Host A) wants to send a packet to another IP (e.g., Host B), it needs the MAC address for that IP to form an Ethernet frame. #### 1\. ARP Request (Broadcast) Host A sends a broadcast message on the local network: ``` Who has 192.168.1.10? Tell 192.168.1.1 ``` - Destination MAC: ff\\:ff\\:ff\\:ff\\:ff\\:ff (broadcast) - Sender IP and MAC: Host A’s info - Target IP: 192.168.1.10 - Target MAC: unknown #### 2\. ARP Reply (Unicast) Host B sees that the ARP request is asking for its IP and replies directly to Host A: ``` 192.168.1.10 is at 00:11:22:33:44:55 ``` This is a unicast response containing the target’s MAC address. #### 3\. Caching the Result Host A stores the mapping in its **ARP cache** to avoid asking again: ```bash arp -a # Windows or Linux command to view cache ``` Entries are time-limited and will expire unless used again. ### Assignment and Control ARP does not “assign” IPs or MACs - it maps them. IPs are assigned via DHCP or manually. MACs are fixed (or spoofed). ARP simply **resolves** the relationship on a local link. > If the destination is **not in the same subnet**, ARP resolves the **MAC address of the default gateway**, not the final target. ### Why This Matters in Pentesting - ARP spoofing (or ARP poisoning) allows intercepting traffic (Man-in-the-Middle) - Tools like `arpspoof` or `ettercap` can fake ARP replies and redirect traffic - Understanding ARP is key for sniffing, pivoting, and lateral movement on local networks > That's it for today! Read carefully and remember the basics!