Interview Prep Series: Part One – Core Concepts & Confidence

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 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:

Image from our friends at Cloudflare

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).

Taken from GeeksForGeeks - 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?

Key Rules/Influences:

Perfect – let’s take this to the next level of clarity and understanding. I’ll rework each section using simple explanations, visual-style metaphors, and clear examples. Let’s turn theory into something you can really picture and explain in your own words.

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: Switch vs Router vs Hub

Let’s use a postal analogy:

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:

Source

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 .

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 or OpenVAS . 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 ), 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

Astra 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
• 0xdf “hacks stuff” – technical posts on exploit dev and methodology 2
• IppSec (blog & YouTube) – walkthroughs of HTB boxes with clear, methodical style 3
• HackTricks – open-source pentesting repo packed with cheatsheets, attack methods, and methodology 4
• KrebsOnSecurity – excellent deep dives into breaches, criminal infrastructure, and cybercrime trends 5
• SwiftOnSecurity (Twitter/blog) – witty, insightful commentary on infosec and sysadmin practices 6
• Security Now! (podcast) – long-running show by Steve Gibson and Leo Laporte, mixing news with technical detail 7
• Hacker Public Radio – community-driven tech/hacker podcast with frequent episodes across many topics 8

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 (Structure):

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: <CVE> exploit github and find if there is a useable exploit present, explain (briefly) how it works.

3. 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.