Interview Prep Series: Part Two – Technical Deep Dive & Groundwork

In this part, we’ll go down the technical question side using a very nice cheat sheet i found.

Core Malware Categories

Examples of Malware Payloads / Famous Hybrids

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

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.

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)

At this point, my second interview mit cirosec was up. Some of the questions were.. unexpected, i’ll dedicate the rest of this article towards them.

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

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:

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

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:

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

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)

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:

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:

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:

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:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_rsa

SSH Agent is used to securely load passphrase-protected keys into memory for session-based use:

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

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

Certainly - here’s Question 5, continuing in your consistent style:

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:

ipconfig /release

This tells the system to give up its current IP and stop using it.

3. Request a new IP address:

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

<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="1000">
  <input type="hidden" name="to_account" value="attacker">
</form>
<script>document.forms[0].submit();</script>

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

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:

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!