> ## 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 One – Core Concepts & Confidence - URL: https://niklas-heringer.com/penetration-testing/interview-prep-part-one/ - Published: 2025-06-26T15:39:00.000Z - Updated: 2025-11-19T19:14:37.000Z - Description: Kicking off my interview prep journey with key phases of pentests, handling tricky questions, and building confidence under pressure. - Author: Niklas Heringer - Tags: interview-prep, penetration-testing > I know I've been lazy on the digital forensics series and other announced posts - **although i wish it was laziness**. Throughout the whole last week i was sick with a nice sommer flu; now that i am fully recovered (though the first gym session after being sick still hurts), let's come **back to schedule.** This week, i'll take up with the digital forensics series - we've got *some posts* ahead of us.. **BUT** something important rose to some more.. immediate attention: **Next week, i have the second interview with** [**cirosec**](https://cirosec.de/cirosec?ref=niklas-heringer.com) **for a 6-month internship in their pentesting & red teaming crews.. and i've got to prepare for that.** I assume since i am metting higher company officials, it will be a more thorough technical interview and **assessment of my skills.** So, in this series, **we'll do interview prep!** # What i Missed in my First Interview: some base network theory > I ofc knew what a Switch was, but my way of saying it was extremely clumsy haha, i stumbled around the facts: ![](https://storage.ghost.io/c/a1/92/a19235e1-df52-43a1-9f25-1151fdb92c82/content/images/2025/11/image-80.png) Image from our [friends at Cloudflare](https://www.cloudflare.com/de-de/learning/ddos/glossary/open-systems-interconnection-model-osi/?ref=niklas-heringer.com) A switch is a network device operating at **OSI Layer 2 (Data Link Layer)**. It connects devices within a **local area network (LAN)** and forwards **Ethernet frames based on MAC addresses**. Said **frames** are **data packets at Layer 2**, the unit of data that switches work with ## A frame contains... - **Destination** MAC address - **Source** MAC address - **EtherType / Length** - **Payload** (data from Layer 3, like an IP packet) - **Frame Check Sequence (FCS)** for error checking Think of it like this: > 📨 **Frame = Envelope** with sender and receiver MAC addresses, and inside is the **IP packet (letter)**. ## How does a Switch decide where to send traffic? The switch makes its forwarding decisions based on the **destination MAC address** in the Ethernet frame. ### Step-by-Step Decision Logic: **1 - Learning:** When a switch receives a frame, it looks at the **source MAC address** and notes: *“This MAC address is reachable via Port X.”* → This is stored in the **MAC address table** (also called the CAM table). ![](https://storage.ghost.io/c/a1/92/a19235e1-df52-43a1-9f25-1151fdb92c82/content/images/2025/11/image-81.png) Taken from [GeeksForGeeks](https://www.google.com/url?sa=i&url=https%3A%2F%2Fwww.geeksforgeeks.org%2Fwhat-is-mac-address-table%2F&psig=AOvVaw2dRc5IlTZM2Hq%5FH2gN1Sf3&ust=1750876837759000&source=images&cd=vfe&opi=89978449&ved=0CBQQjRxqFwoTCODps9Taio4DFQAAAAAdAAAAABAK) \- we see an ****exemplary MAC address table.** **2 - Forwarding / Filtering:** When the switch processes a frame: - It checks the **destination MAC address**. - **Case A:** If it **knows** the MAC → **Forward to the specific port**. - **Case B:** If it **doesn't know** the MAC → **Flood** the frame to **all ports** except the one it came in on. - **Case C:** If the destination is the **switch's own management MAC** → The frame is processed. - **Case D:** If it’s a **broadcast** address → Flood it to all ports. ## What is Flooding? Flooding = when the switch **doesn't know where to send** a frame (because the destination MAC isn't in the MAC table), so it: > **Sends it to all ports except the incoming one** This is how switches deal with unknown MACs or **broadcast** frames. Related: - **Unknown Unicast Flooding** \= destination MAC is not in table - **Broadcast Flooding** \= destination MAC is `FF:FF:FF:FF:FF:FF` **3 - Aging:** Entries in the MAC address table are removed after a timeout (e.g., 300 seconds) if no traffic is seen from that MAC. ## So, What Influences a Switch’s Decisions? | Factor | Explanation | | -------------------------------- | ---------------------------------------------------------------- | | **Destination MAC Address** | Main factor for forwarding decisions. | | **MAC Address Table** | Stored mappings of Port ↔ MAC. | | **Inbound Port** | Used to learn the **source MAC**. | | **Unknown MAC / Broadcast?** | Then the switch **floods** the frame. | | **VLAN Configuration** | Switch will only forward within the **same VLAN**. | | **Spanning Tree Protocol (STP)** | Prevents loops; may disable ports. | | **Port Security / ACLs** | Can limit which MACs are allowed on a port (depending on model). | ## What Happens If Two Devices Have the Same MAC Address? Imagine two people wearing **the same name tag** at a party. Every time someone wants to talk to “John”, they might accidentally talk to the wrong one. The same happens in a network. ### In technical terms: > A **switch learns** which MAC address is on which port. Let’s say Device `A` with MAC `AA:AA` is on Port 1 → switch *saves that*. Then it sees MAC `AA:AA` again, but now on Port 3 (from Device B). The switch updates its table: *"`AA:AA` is now on Port 3."* But if Device `A` sends traffic again from Port 1, it **updates back** to Port 1. > This **back-and-forth** causes **unstable communication**. ### What problems does this cause? - Devices might not get responses. - Traffic might end up in the wrong place. - **Switch keeps “flipping”** the MAC table entry, confused. ### Real-world causes: - **VM clones** with the same MAC (very common in virtualization). - **MAC spoofing**: An attacker pretends to be another device. - Manufacturing mistakes (rare). ## How Does a Switch Prevent Loops? Let’s say you connect **three switches in a triangle**. Without precautions, that creates a **loop**. ## What’s the problem with loops? - Imagine shouting in a canyon, but the echo **never stops**. - In a loop, **broadcast frames never die** – they just circle endlessly. > This is called a **broadcast storm**. It **kills performance** and crashes the network. ### Solution: **Spanning Tree Protocol (STP)** STP is like a **traffic controller** that says: > “Too many roads! Let’s close one, so there’s only one clear way from `A` to `B`.” ### STP Actions: - Finds loops in the topology. - **Blocks one or more ports** to “cut” the loop logically. - Keeps **one active path** between devices. Modern networks use **RSTP** (Rapid STP) → faster recovery *if something changes*. ## Difference(s): Switch vs Router vs Hub Let’s use a **postal analogy**: | Device | Think of it as... | What it does | Intelligence | | ---------- | ----------------- | -------------------------------------------------- | --------------------------------- | | **Hub** | A megaphone | Repeats every message to everyone | Dumb | | **Switch** | A secretary | Gives each letter to the right desk (MAC-based) | Learns who is where | | **Router** | A postal service | Routes mail between cities (networks) using ZIP/IP | Knows routes, networks, NAT, etc. | ### In short: **Hub** → blasts all traffic to everyone. **Switch** → forwards frames within the LAN using **MAC addresses**. **Router** → connects different networks using **IP addresses**. ## Difference Between Layer 2 and Layer 3 Switches Let’s say you work in a large company with **multiple departments (VLANs)**. ### Layer 2 Switch > “I can send stuff **within your department** (VLAN), but not to other departments.” - Works only with MAC addresses. - Cannot route between VLANs. - Needs a **router** to talk across VLANs. ### Layer 3 Switch > “I’m like a switch AND a router – I can **send between departments** (VLANs) too.” - Has **routing capabilities** → works with IP addresses. - Can do **inter-VLAN routing**. - Speeds up routing because it’s built into hardware (very fast). ### Think of it like this: | Layer | Job | Analogy | | --------- | ---------------------- | ---------------------------------------------- | | L2 Switch | MAC-based forwarding | Office mail clerk | | L3 Switch | MAC + IP-based routing | Office mail clerk with a map of the whole city | ![](https://storage.ghost.io/c/a1/92/a19235e1-df52-43a1-9f25-1151fdb92c82/content/images/2025/11/image-82.png) [Source](https://cdn.shopify.com/s/files/1/0106/6339/5391/files/Layer%5F2%5Fvs%5FLayer%5F3%5FSwitch%5F1024x1024.jpg?v=1722388247&ref=niklas-heringer.com) > Nice! We've covered some basics so they can't come back around to bite me (atleast not in that form). Let's go on, shall we? --- # Typical Interview Questions Let's first go through some typical questions I've read about in [this amazing HackTheBox blog post](https://www.hackthebox.com/blog/cybersecurity-interview-questions-and-answers?ref=niklas-heringer.com). ## What is the difference between vulnerability scanning and penetration testing? > Penetration testing is a **simulated, authorized attack** on systems to evaluate their *security posture*. It has a rather clear goal (other than to "just look around"), it's **scoped**, it has a timeframe, and often includes **manual techniques to exploit vulnerabilities** and assess real-world risks. Vulnerability scanning is different: it is **typically automated** with tools like [Nessus](https://de.tenable.com/products/nessus?ref=niklas-heringer.com) or [OpenVAS](https://www.openvas.org/index-de.html?ref=niklas-heringer.com). It identifies and categorizes **known weaknesses in systems**, but does **not exploit or go beyond detection**. ### I like HTB's analogy for this: Vulnerability scanning is like *checking if your windows and doors are unlocked*. Penetration testing is trying to break in without causing damage - to see *how far an attacker could really get*. > Pentests go deeper: they chain exploits, test defensive controls, and help answer, ‘What if someone actually tried to attack us?’. Vulnerability scans are often used for compliance (e.g., [PCI-DSS](https://cpl.thalesgroup.com/compliance/pci-dss-compliance?ref=niklas-heringer.com#:~:text=PCI%20DSS%204.0%20Requirements,and%20reduce%20credit%20card%20fraud.)), while penetration tests are used to validate security and identify gaps that automated tools might miss. ## What are the different phases of a typical penetration test? A typical penetration test follows structured phases, each with a specific goal, and they often loop or overlap as the test progresses. > Here's a high-level breakdown I use to keep it organized and focused. ### 1\. **Pre-Engagement (Planning & Scope)** > We define **scope**, **rules of engagement**, get all legal approvals, and align expectations. This ensures we're targeting the right assets in a safe, controlled manner. ### 2\. **Information Gathering (Recon)** > I collect **OSINT** and actively enumerate systems, services, domains, and users. Example: finding exposed services, public GitHub secrets, cloud misconfigs, or metadata leaks. ### 3\. **Vulnerability Analysis** > Using what I found, I map services to known vulnerabilities (CVEs) and assess risk. Tools like **Nessus** or **Nmap scripts**, paired with manual analysis, help identify viable attack paths. ### 4\. **Exploitation** > This is where I attempt to **exploit vulnerabilities** to gain access. For external tests: I might pivot from a public app to internal systems. For internal: I’m often dropped inside the network (via VPN or pre-positioned VM). ### 5\. **Post-Exploitation** > Once initial access is gained, I focus on understanding the system, escalating privileges, and gathering valuable data (credentials, tokens, configs, etc.). If possible, I move laterally - compromising other systems using harvested creds, `WinRM`, `RDP`, so much is possible. The goal is to assess the real impact of the compromise. > I ask: *“What can I do now that I’m in?”* *“What does this access mean in a real-world attack?”* ### 6\. **Post-Engagement (Reporting)** > Finally, I document everything: what I did, what I found, what impact it has, and how to fix it. The goal is a **clear, actionable report** and a client debrief that turns findings into improvements. ### Mnemonic: **P.I.V.E.P.P.** > *Plan – Info – Vulns – Exploit – Post – Present* ![](https://storage.ghost.io/c/a1/92/a19235e1-df52-43a1-9f25-1151fdb92c82/content/images/2025/11/image-83.png) > [Astra](https://cdn-blog.getastra.com/2024/08/f564c76f-penetration-testing-phases-2.png?ref=niklas-heringer.com) here presents a slightly different process but the spirit's the same - **remediation afterwards is not always the case, depends on your service for your clients.** ## How would you handle sensitive data or information you come across during a penetration test? > Any client data encountered (credentials, internal documents, PHI, etc.) is treated as **highly sensitive**. My role is to identify exposures, not to explore data out of scope or curiosity. I document only what’s necessary to demonstrate risk, and ensure findings are securely stored (e.g., encrypted storage, secure transmission). If I encounter potentially illegal content, I stop testing immediately and escalate to my supervisor for guidance. ## How do you stay up-to-date on latest vulns, exploits, etc.? Despite some good past months, i am still veery early in my learning journey in off-sec. I am learning new techniques every week using HTB Academy, my uni courses and some excellent online sources: - **HTB Blog (Hack The Box)** – deep-dives, labs, write‑ups, and recon guides [1](https://www.hackthebox.com/blog?ref=niklas-heringer.com) - **0xdf “hacks stuff”** – technical posts on exploit dev and methodology [2](https://0xdf.gitlab.io/?ref=niklas-heringer.com) - **IppSec (blog & YouTube)** – walkthroughs of HTB boxes with clear, methodical style [3](https://ippsec.rocks/?ref=niklas-heringer.com) - **HackTricks** – open-source pentesting repo packed with cheatsheets, attack methods, and methodology [4](https://book.hacktricks.wiki/en/index.html?ref=niklas-heringer.com) - **KrebsOnSecurity** – excellent deep dives into breaches, criminal infrastructure, and cybercrime trends [5](https://krebsonsecurity.com/?ref=niklas-heringer.com) - **SwiftOnSecurity (Twitter/blog)** – witty, insightful commentary on infosec and sysadmin practices [6](https://x.com/SwiftOnSecurity?ref%5Fsrc=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor&ref=niklas-heringer.com) - **Security Now! (podcast)** – long-running show by Steve Gibson and Leo Laporte, mixing news with technical detail [7](https://twit.tv/shows/security-now?ref=niklas-heringer.com) - **Hacker Public Radio** – community-driven tech/hacker podcast with frequent episodes across many topics [8](https://hackerpublicradio.org/?ref=niklas-heringer.com) ## How to handle obscure CVEs or unexpected vuln questions in interviews These types of questions aren’t really about the CVE - they’re about your process, mindset, and honesty. Here’s a quick **playbook-style rundown** to tackle them **like i would**. ### Goal: Demonstrate that you're resourceful, calm, honest, and methodical - even when you're caught off-guard. ## How to Respond to unfamiliar Questions 1. **Stay honest and composed** “I’m not familiar with that CVE right now, but I’d be happy to look into it right now, may i google it?”\* 2. **Talk about your though process** What they want to hear is *how* you approach the problem: > "Okay, first i google the plan cve to get to know the tech stack i'm dealing with" - as you read the basics, mention similar encounters if you've had any: "this reminds me of XY i found in HTB Box Dog!" **Google for**: ` exploit github` and find if there is a useable exploit present, explain (briefly) how it works. 1. **Offer to simulate in a VM** They might want to go deeper - if so, go deeper! Demonstrate what you can do in the terminal, **be honest about what not!** Clone the exploit github, get a bit into how you'd structure an exploit try, how you'd document and so on! > This was a shorter yet effective session - in part 2, we'll go on to talk about more technical questions.