Question 1

Explain the OSI Model

Accepted Answer

The OSI model breaks network communication into seven layers: physical, data link, network, transport, session, presentation, and application. Physical is cabling and signals, data link handles MAC addresses and switches, network is IP addressing and routing, transport is TCP/UDP, and then session, presentation, and application cover things like session handling, encryption and formatting, and the actual protocols like HTTP or DNS that applications use.  For a security analyst, this isn't just something to recite, it's a mental map for figuring out where a problem or an attack actually lives. ARP spoofing happens at layer 2. IP spoofing and routing attacks sit at layer 3. A SYN flood is a layer 4 problem. SQL injection or a malicious HTTP request is layer 7. When you're triaging an alert, knowing the layer tells you which tool to reach for: a switch's ARP table for layer 2 issues, packet captures for layer 3/4 anomalies, a WAF or app logs for layer 7. It also matters when firewalls come up in an interview: a traditional stateless ACL firewall works mostly at layers 3 and 4, filtering on IP and port, while a next-gen firewall or WAF inspects up at layer 7 to catch things a port-based rule would miss entirely.  I'd also bring up that most real incidents span multiple layers at once. A phishing email that leads to a C2 beacon involves layer 7 delivery but layer 3/4 traffic for the actual callback, so the model is a diagnostic ladder, not a strict box for every attack.

Question 2

TCP Three-Way Handshake in a Packet Capture

Accepted Answer

TCP starts every connection with a SYN, SYN-ACK, ACK exchange before any real data moves. The client sends a SYN with an initial sequence number, the server responds with its own SYN plus an ACK of the client's sequence number, and the client finishes with an ACK. Once you know that pattern cold, you can read a lot into a capture just from which parts of it are present or missing.  If I see a flood of SYN packets to a host with no SYN-ACK responses or no completed handshakes, that looks like a SYN scan or a SYN flood, someone probing ports or trying to exhaust connection state rather than actually talking to a service. If I see a completed handshake followed by almost no data and then a quick RST or FIN, that can be a health check, but it can also be a beacon confirming a C2 server is alive before the real payload gets scheduled. Malformed handshakes, like a SYN-ACK with no matching SYN, usually point to spoofed source IPs or asymmetric routing, both worth flagging.  The handshake also tells you which side initiated the connection, which matters for direction of compromise: an internal host reaching out to complete a handshake with an external IP on an unusual port is a very different story than an external host trying to initiate one against your DMZ. The handshake isn't just protocol trivia, it's the baseline pattern I compare against when something in a PCAP looks off.

Question 3

TCP vs UDP

Accepted Answer

TCP is connection-oriented: it sets up a session with the three-way handshake, numbers every segment, acknowledges receipt, and retransmits anything lost, so the application gets a reliable, ordered stream of data. UDP skips all of that. It just fires packets at the destination with no handshake, no guaranteed delivery, and no ordering, which makes it faster and lower overhead but leaves reliability up to whatever application sits on top of it.  That difference has real security consequences. Because UDP has no handshake, it's trivial to spoof the source address, which is exactly why UDP-based protocols like DNS, NTP, and memcached get abused for amplification DDoS attacks: an attacker sends a small spoofed request and the victim gets hit with a much larger response they never asked for. TCP is harder to spoof the same way, since hijacking an established session means guessing sequence numbers, though SYN floods still abuse the handshake itself to exhaust server resources.  On the defense side, this changes what I expect to see in logs. A TCP-based service failing typically shows retransmissions and resets, which is diagnostic. A UDP-based service just silently drops packets, so troubleshooting relies more on application-level logging. It also affects firewall rules: stateful inspection tracks TCP connection state naturally, but for UDP a firewall has to fake state by timing out flows, since there's no FIN or RST to signal the conversation is over.

Question 4

DNS Resolution, Security Angle

Accepted Answer

When you type a domain into a browser, the OS first checks its local cache, then queries a configured DNS resolver, usually your ISP's or a corporate one. If that resolver doesn't have the answer cached, it goes recursive: it asks a root server, which points it to the TLD server for .com or whatever the extension is, which points it to the authoritative name server for that domain, which finally returns the IP address. The resolver caches that answer and hands it back to your machine, and only then does the browser open a TCP connection to that IP and start the TLS handshake if it's HTTPS.  I care about this flow because DNS is one of the richest and most underused sources of evidence in an investigation. Malware families use domain generation algorithms to produce hundreds of pseudo-random domains a day so a hardcoded C2 domain can't just be blocklisted, and seeing a host generate a burst of NXDOMAIN responses for gibberish domains is a strong DGA indicator. DNS tunneling abuses TXT or NULL records to smuggle data out over what looks like ordinary DNS traffic, which is why unusually large or frequent DNS queries to one domain are worth a second look. Fast-flux setups rotate the IP behind a domain rapidly to dodge IP-based blocking. Because DNS almost always happens before the real connection, DNS logs often show the first sign of compromise before anything shows up in proxy or firewall logs.

Question 5

Common Ports Quickfire (445, 3389, and Beyond)

Accepted Answer

Port 445 is SMB, the protocol Windows uses for file and printer sharing, and it's one of the first things I'd flag if I saw it crossing a network segment boundary or reaching the internet, because SMB has been the delivery and lateral movement mechanism for a long list of major incidents, EternalBlue and WannaCry being the obvious examples. Internally, SMB traffic between workstations that don't normally share files with each other is a classic lateral movement signal. Port 3389 is RDP, and unauthenticated or brute-forced RDP exposed to the internet is still one of the most common initial access vectors for ransomware crews, so I'd want to know immediately if that port is reachable from outside.  Beyond those two, the ports I keep in my head without thinking are 80 and 443 for HTTP and HTTPS, 53 for DNS, 22 for SSH, 23 for Telnet, 25 for SMTP, 67 and 68 for DHCP, 389 for LDAP, and 21 for FTP. What matters more than memorizing the list, though, is knowing what's normal for a given environment: SSH on port 22 from an admin jump box is expected, SSH showing up on a random high port from a workstation that's never used it before is not. Port knowledge is only useful as a baseline for spotting deviation, whether that's a service running somewhere it shouldn't, a protocol on a nonstandard port trying to blend in, or a legitimate port being used for something it wasn't meant for.

Question 6

How a VPN Actually Works

Accepted Answer

A VPN creates an encrypted tunnel between your device and a VPN gateway, so traffic that leaves your machine is wrapped in an encrypted layer before it crosses whatever untrusted network sits in between, and it gets unwrapped once it reaches the other end. Protocols like IPsec or SSL/TLS-based VPNs handle the key exchange and encryption, and depending on configuration, the VPN can route all of your traffic through the tunnel or just traffic destined for a specific internal network, which is the split-tunnel versus full-tunnel distinction that comes up a lot in corporate environments.  The core problem it solves is that most of the networks your traffic crosses, coffee shop Wi-Fi, hotel networks, the broader internet, aren't trustworthy, and without encryption anyone positioned on that path can read or tamper with your traffic. A VPN also lets a remote employee's machine behave, from the network's perspective, as if it's sitting inside the corporate LAN, which is how VPNs enable access to internal resources that were never meant to be internet-facing.  From a security standpoint, VPNs are also a common attack surface themselves, since a compromised VPN credential or an unpatched VPN appliance gives an attacker a fully trusted foothold straight into the internal network, bypassing perimeter controls entirely. That's part of why so many ransomware intrusions in recent years started with stolen VPN credentials rather than anything more sophisticated, and why MFA on VPN access matters as much as the encryption itself.

Question 7

Stateful vs Stateless Firewall

Accepted Answer

A stateless firewall evaluates every packet on its own against a fixed set of rules, usually matching on source and destination IP, port, and protocol, with no memory of what came before. That makes it fast and simple, but it also means you have to write rules for both directions of traffic explicitly, since the firewall has no concept of a packet being a reply to a connection it already allowed.  A stateful firewall tracks the state of active connections in a table, so once it sees the initial handshake and decides to allow a connection, it automatically permits the return traffic for that session without needing a separate rule for it. This is both more secure and easier to manage: you write a rule allowing outbound traffic to port 443, and the firewall handles the reply traffic on its own by recognizing it belongs to an established session, rather than requiring an admin to open inbound high ports broadly, which stateless setups often end up doing and which becomes its own vulnerability.  From an analyst's perspective, this matters because stateful firewalls give you connection-level context in their logs, you can see a session as a whole rather than isolated packets, which is far more useful during an investigation. It's also why a stateless ACL is more prone to certain evasion techniques, like crafting packets that look like return traffic when no real connection was ever established, something a stateful table would catch immediately.

Question 8

Explain NAT

Accepted Answer

NAT, network address translation, lets a device with a private IP address, something in the 10.x, 172.16-31.x, or 192.168.x ranges, communicate on the public internet by having a router or firewall swap that private source address for a public one on the way out, and swap it back on the way in. It exists mainly because IPv4 doesn't have enough addresses for every device to have a unique public one, so an entire office can share a handful of public IPs.  The security side effect, and it is a side effect rather than NAT's actual purpose, is that it hides your internal network structure from anything on the outside. An external host can't directly address an internal machine behind NAT unless the router is explicitly configured to forward a port to it, so NAT acts as a rough perimeter that blocks unsolicited inbound connections by default. People sometimes talk about NAT like it's a firewall, and it's not: it doesn't inspect content or enforce policy, it's just address translation that happens to make unsolicited inbound traffic harder because there's no mapping for it to follow.  From an investigation standpoint, NAT also complicates attribution. If you're looking at logs on an external-facing service and see one public IP, that could be dozens of internal hosts behind it, so tying a specific alert back to the right internal endpoint means you need NAT translation logs, not just the firewall or web server logs alone.

Question 9

Explain Subnetting

Accepted Answer

Subnetting is splitting a larger network into smaller ones by borrowing bits from the host portion of an IP address for the network portion, which you write in CIDR notation like /24 for a network with 256 addresses, /26 for 64, and so on. The subnet mask tells devices which part of an address identifies the network and which part identifies the specific host, and that's how a router decides whether traffic needs to be routed elsewhere or can stay local.  I won't pretend subnetting math is something I do with the same speed as a network engineer, but I know enough to read a CIDR block and immediately know the size of that network and roughly what it's used for, and that's the skill that actually matters day to day. What matters more for security is what subnetting enables: network segmentation. Putting servers, workstations, IoT devices, and guest Wi-Fi on separate subnets, often mapped to separate VLANs, means that if one segment gets compromised, the blast radius is contained by the routing and firewall rules between subnets rather than the attacker being able to freely reach every device on a flat network.  When I'm looking at an alert, knowing the subnet layout tells me immediately whether a connection is expected. Traffic from the guest subnet trying to reach the finance servers' subnet is a much bigger red flag than the same traffic between two workstations on the same corporate subnet, and that context comes straight from understanding how the network is segmented.

Question 10

What Is ARP? (and ARP Spoofing)

Accepted Answer

ARP, Address Resolution Protocol, maps IP addresses to MAC addresses on a local network segment. When a device wants to talk to another device on the same subnet, it knows the destination's IP but needs the physical MAC address to actually deliver the frame at layer 2, so it broadcasts an ARP request asking who has that IP, and the device that owns it replies with its MAC address. That mapping gets cached in an ARP table for a while so the device doesn't have to ask again for every packet.  The reason this matters for security is that ARP was designed with zero authentication. Any device on the local segment can send out an ARP reply claiming to own an IP address it doesn't, and most systems will just update their ARP table with whatever they hear last. That's ARP spoofing, and it's the basis for classic man-in-the-middle attacks on a LAN: an attacker poisons the ARP tables of a victim and the default gateway so that traffic between them routes through the attacker's machine first, letting them intercept, inspect, or modify traffic that's supposed to stay between those two endpoints.  Because ARP only works on the local segment, this is specifically a threat when an attacker already has a foothold inside the network, it doesn't work across routers. That's part of why an unusual number of ARP replies for the same IP, or a gateway's MAC address suddenly changing in logs, is one of the signs I'd look for when trying to detect an internal MITM attempt.

Question 11

CIA Triad, With a Real Incident

Accepted Answer

Confidentiality, integrity, and availability are the three properties you're protecting, and the useful way to talk about them in an interview is through an incident where you can point at which leg broke.  Take a ransomware attack on a hospital network. The attacker encrypts the systems holding patient charts and medication histories, so clinicians can't access data they need during a shift. That's an availability failure: the data still exists, it's just locked away from the people who need it right now, and in a hospital that has real physical consequences. If the same crew also exfiltrated the records before encrypting anything, which is standard double-extortion practice now, you've added a confidentiality breach, because that data can show up on a leak site regardless of whether the ransom gets paid. And if they went further and quietly altered a few fields, say a dosage or an allergy flag, before locking the rest, that's an integrity failure, and it's the one that does the most damage because nobody notices until something goes wrong downstream.  Most serious incidents don't cleanly hit just one leg. A single ransomware event can degrade all three at once. Recognizing that these are independent properties of the same data, not three separate categories of attack, is what separates someone who's applied the model from someone who memorized it.  Which leg matters most also depends on the system. A hospital cares most about availability. A bank cares more about integrity than a short outage.

Question 12

CIA Triad Tension: the MFA Example

Accepted Answer

The classic tension is between confidentiality and availability, and MFA is the easiest example to reach for because almost everyone has lived it.  Rolling out mandatory MFA on a VPN or an email login raises confidentiality and, arguably, integrity too, because it makes account takeover much harder even if a password leaks. But it comes at a real cost to availability in the practical sense: a user without their phone, an expired TOTP app, a hardware token left at home, or an SMS that doesn't arrive in a low-signal area all turn into someone locked out of a system they need right now. Security teams see this constantly in helpdesk ticket volume right after an MFA rollout.  The same trade-off shows up with account lockout policies. Lock an account after three failed attempts and you've made brute-forcing harder, but you've also handed an attacker a cheap denial-of-service lever: repeatedly fail login attempts on someone else's account and they're locked out of their own system.  The point of this question isn't to pick a side, security usually wins over convenience in principle, it's to show you understand that every control has a cost, and that a mature security posture means choosing where on that trade-off curve you want to sit rather than pretending the trade-off doesn't exist. Good implementations soften the cost with backup codes, grace periods, or step-up authentication instead of blanket lockouts.

Question 13

AAA: Authentication, Authorization, Accounting

Accepted Answer

Authentication answers who you are, authorization answers what you're allowed to do, and accounting answers what you actually did. They run in that order and they're enforced by different mechanisms, which is where people get tripped up.  A concrete example: you log into a company VPN with your username, password, and an MFA push. That's authentication, the system just confirmed you are who you claim to be. Once you're on the network, whether you can reach the finance server or just the general file share depends on your group membership or role, that's authorization, and it's a completely separate check that happens on every resource request, not just at login. Then every action you take while connected, files you opened, servers you touched, commands you ran, gets logged somewhere, that's accounting, and it's what an incident responder pulls up six months later when something goes wrong.  The mix-up I see most often is candidates treating authentication and authorization as one step, saying something like 'the user was authenticated to access the file,' when really those are two separate control points that can fail independently. You can be authenticated and still get denied by authorization. You can also have solid authentication and authorization and still get burned because accounting wasn't turned on, so when there's a breach there's no log trail to reconstruct what happened.  RADIUS and TACACS+ are the protocols usually cited for implementing all three together.

Question 14

Defense in Depth, In Practice

Accepted Answer

Defense in depth means that if one control fails, there's another one behind it that doesn't depend on the first one working. The test for whether you actually understand it is whether you can list layers that are independent of each other, not just a pile of tools.  Picture an employee getting a phishing email with a malicious attachment. Layer one is email filtering that should catch it before it lands in the inbox. Say it slips through anyway. Layer two is user awareness, ideally the employee doesn't open the attachment, but assume they do. Layer three is endpoint protection, EDR should flag the malicious process the attachment tries to spawn. If that's evaded too, layer four is network segmentation, the compromised workstation shouldn't have a clear path to the domain controller or the finance servers. And if the attacker somehow gets that far, layer five is monitoring and detection, someone's SOC should notice unusual authentication patterns or lateral movement and respond before real damage happens.  The failure mode I watch for in this question is a candidate who just names a list of products, firewall, antivirus, IDS, without explaining that the value is in each layer covering for the others' blind spots. A firewall and an IDS sitting on the same network segment aren't defense in depth if they both fail to the same bypass technique. Real depth means diversity of control type, preventive, detective, and administrative controls stacked together, not five versions of the same idea.

Question 15

Zero Trust vs Perimeter Security

Accepted Answer

Perimeter security is built on the idea that there's a hard outside and a soft inside: once you're through the firewall or connected to the VPN, you're mostly trusted to move around. Zero Trust starts from the opposite assumption, that no user, device, or network location gets automatic trust just because it's already inside, and every request has to be verified on its own terms.  The practical difference shows up in how access decisions get made. In a perimeter model, once an employee's laptop is on the corporate network, it can usually reach a wide range of internal systems with minimal extra checks, because 'inside the firewall' was treated as proof enough. In a Zero Trust model, that same laptop reaching the same internal file server triggers a fresh check every time: is this the right user, is the device compliant and patched, is this access pattern normal for this person, does this specific request match a defined policy. Access is scoped tightly per resource instead of broadly per network segment, which is why microsegmentation and per-session verification are core pieces of most Zero Trust implementations.  The scenario that sells this in an interview is lateral movement. Under a perimeter model, one compromised laptop can often reach a lot of the network because internal traffic isn't scrutinized. Under Zero Trust, that same compromised device gets stopped at the next resource boundary because its access to that specific system was never granted in the first place, regardless of network location.  It's worth being clear that Zero Trust is an architecture and a set of principles, not a single product you buy.

Question 16

Least Privilege Failing in Cloud IAM

Accepted Answer

Cloud IAM makes least privilege violations easier to create and harder to notice than on-prem AD, because granting access is a policy attached to a role instead of a domain group someone has to remember exists. The classic failure: a CI/CD pipeline's service role gets attached the AWS managed policy AdministratorAccess, or an Azure Owner role assignment, because the deploy kept failing on a permissions error and granting broad access was the fastest way to get the build green under deadline pressure. Nobody circles back to scope it down once the pipeline is working, because it's working, and "working" rarely gets revisited.  That pipeline role is now one of the most attractive targets in the environment. A leaked CI/CD credential with admin-equivalent cloud access can spin up resources, exfiltrate data from every service in the account, or pivot into production, and it often has no MFA on it at all, because service identities can't answer an MFA prompt. The blast radius of one leaked API key becomes the blast radius of the entire cloud account.  Done right, that same pipeline gets a role scoped to exactly the actions it needs, deploy to this specific set of resources, read from this specific artifact bucket, nothing else, ideally defined through infrastructure-as-code so the permission boundary gets reviewed the same way application code does. Cloud providers also give you tools on-prem AD doesn't have for finding these gaps after the fact: AWS IAM Access Analyzer and Azure's Access Reviews both flag permissions that were granted but never actually used, which is usually the fastest way to find every over-provisioned role in an account without auditing each one by hand.

Question 17

Threat vs Vulnerability vs Risk

Accepted Answer

A vulnerability is a weakness, a threat is something that could exploit that weakness, and risk is what you get when you combine the two with the actual impact if it happens. None of them mean the same thing, and treating them as interchangeable is one of the fastest ways to sound like you're just repeating security vocabulary without understanding it.  The example I like is an unpatched, internet-facing server with a known remote code execution flaw. The unpatched flaw itself is the vulnerability, it's just a fact about the system, it exists whether or not anyone ever tries to use it. A threat is an actor or event capable of exploiting that flaw, which could be a specific ransomware group known to scan for that exact vulnerability, or more generically just opportunistic internet scanning. Risk is the product of likelihood and impact: how likely is exploitation given that this server is exposed and that flaw is actively being scanned for in the wild, and how bad would it be if it happened, meaning what data or systems that server touches.  This matters practically because it changes what you do about each one. You reduce vulnerability by patching. You reduce threat exposure by things like taking the server off the public internet or adding a WAF in front of it. You reduce risk overall by doing either of those, or by reducing impact, say by isolating that server so a compromise doesn't cascade into the rest of the network. A patch fixes the vulnerability but doesn't remove the threat actor from the internet.

Question 18

What Is Non-Repudiation?

Accepted Answer

Non-repudiation means having strong enough evidence that someone performed an action that they can't credibly deny doing it afterward. It's the property that turns 'we think it was them' into 'we can prove it was them,' and it matters most when accountability has legal, financial, or HR consequences.  A good example is a digitally signed contract or a financial transaction signed with a private key tied to one person. If that signature is valid, the signer can't later claim someone else submitted it, because the cryptographic signature is mathematically tied to a key only they should have had. Compare that to a shared login: if an entire team logs into one admin account, and something gets deleted or changed, there's no way to prove which specific person did it, because the account itself doesn't carry that granularity. That's a non-repudiation failure, and it's a genuinely common one in poorly run environments.  This shows up constantly in incident response and audit contexts. If a SOC investigates an insider threat case and the suspect's defense is 'that wasn't me, someone else must have used my session,' the strength of your non-repudiation controls, unique accounts, MFA, session logging, digital signatures where it counts, determines whether you can actually close that case or whether it stays ambiguous forever.  Individual, non-shared accounts combined with logging and, where the stakes justify it, digital signatures are the practical building blocks. It's less a single control and more an outcome you get from combining several.

Question 19

Security by Design vs Security by Obscurity

Accepted Answer

Security by obscurity means your protection depends on an attacker not knowing something, how a system works internally, an undocumented port, a custom encryption scheme nobody's published. Security by design means the system holds up even when an attacker knows exactly how it works, because the protection comes from the mechanism itself, not from secrecy about the mechanism.  Kerckhoffs's principle from cryptography captures this well: a cryptographic system should be secure even if everything about it except the key is public knowledge. That's why modern encryption standards like AES are published in full detail and still considered secure, the security lives in the secrecy of the key, not the secrecy of the algorithm. Compare that to a company running SSH on port 2222 instead of 22 and calling that their security control. It might cut down noise from dumb automated scanners for a while, but a real attacker doing reconnaissance finds it in a basic port scan in seconds, and once they know, there was never a second layer behind it.  Obscurity isn't worthless, moving SSH off the default port genuinely does reduce log noise and opportunistic scanning traffic. The mistake is treating it as a security control on its own instead of a minor operational nuisance for attackers. Security by design means building in access controls, encryption, and least privilege that hold up under full disclosure of how the system works, and using obscurity, if at all, only as a thin extra layer on top of controls that would already hold without it.

Question 20

False Positive vs False Negative

Accepted Answer

A false positive is an alert that fires when nothing bad actually happened, the detection said 'attack' and there wasn't one. A false negative is the opposite and far more dangerous in most cases: an actual attack happened and the detection stayed silent.  A concrete example: an EDR rule flags a PowerShell script as malicious because it uses obfuscation techniques, but it turns out to be a legitimate IT automation script that a sysadmin wrote and just happens to look suspicious. That's a false positive, annoying, it burns analyst time, but nothing was missed. Now flip it: an attacker uses a living-off-the-land technique, say abusing a legitimate admin tool like PsExec to move laterally, and because that tool is used constantly for benign administration, the detection rule doesn't fire at all. That's a false negative, and the attacker is now inside the network with nobody looking.  I worry more about false negatives, because a missed detection means an active compromise runs unchecked, and you only find out later, usually from something worse. But false positives aren't harmless either, a high false positive rate causes alert fatigue, and alert fatigue is exactly what causes analysts to start dismissing alerts quickly, including real ones, which eventually produces more false negatives downstream. The two aren't independent problems, tuning too aggressively toward catching everything drives up false positives and burns out the team that needs to catch the one real alert buried in the noise.  Good detection engineering is a constant balancing act between the two, not a one-time fix.

Question 21

Symmetric vs Asymmetric Encryption

Accepted Answer

Symmetric encryption uses one key to lock and unlock the data, so whoever has the key can both encrypt and decrypt. It's fast and computationally cheap, which is why AES is what actually encrypts your disk, your database fields, and the bulk of a TLS session once the connection is set up. The catch is key distribution: both sides need the same secret, and if you send that key over an insecure channel, you've handed an attacker everything they need.  Asymmetric encryption uses a key pair, a public key anyone can have and a private key only the owner holds. Data encrypted with the public key can only be decrypted with the matching private key. This solves the distribution problem because you never have to transmit a shared secret, but the math behind RSA or elliptic curve crypto is expensive, so it doesn't scale well for encrypting large amounts of data.  In practice you rarely see one used alone. TLS is the textbook example: asymmetric crypto or a Diffie-Hellman exchange is used briefly to agree on a shared session key, then that session key drives fast symmetric encryption for the rest of the conversation. If a candidate says 'use asymmetric because it's more secure' without mentioning performance or this hybrid approach, that tells me they've memorized a definition rather than understood why the split exists.

Question 22

Hashing vs Encryption

Accepted Answer

Encryption is reversible by design, you encrypt something so the right person can decrypt it later with a key. Hashing is a one-way function: you feed data in, you get a fixed-length digest out, and there's no key and no reverse operation that gets you back to the original input. That's not a limitation, it's the entire point. A hash is meant to prove integrity or represent data without ever needing to recover the original.  That's why 'decrypting a hash' isn't a real operation. What people actually mean when they say that is running a dictionary or brute-force attack: hash a huge list of candidate passwords and see which output matches the stored hash. If it matches, you've found the input, but you didn't invert the function, you guessed until you got lucky. That distinction matters because it changes what defenses actually work. Rate-limiting login attempts protects against online guessing. Salting and using a slow, memory-hard algorithm like Argon2id protects against offline guessing once a database leaks.  If someone tells me they 'encrypted' a password before storing it, that's a red flag on its own, because it implies the system can recover the plaintext password, which it should never be able to do. Passwords should be hashed, not encrypted, precisely because you never need the original back.

Question 23

Why Password Salting Matters

Accepted Answer

No. Hashing alone stops someone from reading passwords directly out of a leaked database, but it doesn't stop precomputed attacks. If two users pick the same password, an unsalted hash produces the same digest for both, which immediately leaks that fact and lets an attacker recognize common passwords across the whole table. Worse, attackers keep rainbow tables, huge precomputed lookups of hash-to-plaintext pairs for common password lists. Without a salt, cracking one password is the same cost as cracking all of them, because the attacker just checks the table.  A salt is a random value generated per user and stored alongside the hash. It gets combined with the password before hashing, so two identical passwords produce completely different digests, and a precomputed rainbow table becomes useless because the attacker would need a separate table for every possible salt. It doesn't make an individual guess any slower, that's the job of the hashing algorithm's cost factor, it makes attacking many accounts at once as expensive as attacking one.  A strong answer also mentions that salting isn't the finish line. You still want a slow, memory-hard algorithm like bcrypt or Argon2id rather than a single fast round of SHA-256, because a fast hash lets an attacker with GPUs try billions of guesses per second even with a salt in place.

Question 24

What a Digital Signature Proves

Accepted Answer

A digital signature proves two things: that the message came from whoever holds a specific private key, and that the message hasn't been altered since it was signed. It doesn't provide confidentiality by itself, a signed message can still be read by anyone, it's about authenticity and integrity, not secrecy.  The process is essentially asymmetric encryption run in reverse. The sender hashes the message to get a fixed-size digest, then encrypts that digest with their own private key. That encrypted digest is the signature, attached alongside the original message. Anyone with the sender's public key can decrypt the signature to recover the digest, independently hash the message they received, and compare the two. If they match, the message wasn't tampered with in transit and it was signed by whoever controls that private key. If even one character in the message changed, the hash comparison fails.  This encrypt-then-decrypt framing describes RSA signatures specifically. Most TLS certificates issued today actually use ECDSA or EdDSA, where verification checks a mathematical relationship between the signature, the message hash, and the public key, with no decryption step at all. The end result is identical, proof that whoever holds the private key produced that signature, but the mechanics differ enough that it's worth not overgeneralizing the RSA description to every signature scheme.  What trips people up is thinking a signature encrypts the message itself, it doesn't, it operates on a hash of the message for efficiency, and encrypting the whole thing with a private key would be slow and pointless for this purpose. The other common gap is not connecting signatures to identity: the signature only proves possession of the private key, which is why certificate authorities and PKI exist, to bind that key to an actual verified identity in the first place.

Question 25

How HTTPS/TLS Establishes a Connection

Accepted Answer

At a high level, HTTPS is HTTP running over TLS, and TLS's job is to get both sides to a shared secret key they can use for fast symmetric encryption for the rest of the session, while also proving the server is who it claims to be.  In TLS 1.3, the client opens with a ClientHello that lists the protocol version and supported cipher suites, and it already includes its half of a Diffie-Hellman key exchange. The server responds with a ServerHello containing its own key share, which lets both sides independently compute the same shared secret without ever sending it over the wire. Alongside that, the server sends its certificate and proves it holds the private key matching that certificate. The client checks that certificate against a trusted certificate authority, checks it hasn't expired or been revoked, and checks the domain name matches. Once both sides confirm the handshake integrity, they switch to symmetric encryption, typically AES, using the key they just derived.  The key thing to get right in an answer is that TLS is a hybrid system: asymmetric crypto and key exchange are used briefly to establish trust and agree on a secret, and the actual data of the session is protected with symmetric encryption because it's far faster. Saying HTTPS 'encrypts everything with the server's public key' is a common mistake, that's not how the bulk of the session is protected.

Question 26

What a Certificate Authority Does

Accepted Answer

A certificate authority is a trusted third party that verifies a domain or organization actually controls what it claims to control, then issues a certificate binding that identity to a public key, signed with the CA's own private key. Your browser ships with a list of root CAs it trusts by default, and it trusts any certificate that chains back up to one of them.  Certificate validation is what turns 'here's a public key' into 'here's a public key that actually belongs to the domain I typed.' Without it, encryption on its own proves nothing about identity. An attacker running a man-in-the-middle attack can generate their own key pair and present their own certificate, and if the client doesn't check that certificate against a trusted CA, the connection gets encrypted, just to the wrong party. That's the entire premise behind attacks that intercept traffic on public Wi-Fi using a self-signed cert.  This is why browsers throw hard warnings on invalid certificates rather than quietly allowing the connection: expired certs, hostname mismatches, or certs signed by an untrusted or revoked CA all mean the identity claim can't be verified, even if the underlying encryption math is fine. Clicking through those warnings in production is one of the more common ways people accidentally defeat TLS entirely, because they're choosing to trust an identity nobody actually verified.

Question 27

Encoding vs Encryption vs Hashing

Accepted Answer

Encoding transforms data into a different format for compatibility reasons, like Base64 turning binary data into ASCII text so it can travel safely through systems that only handle text. It uses no key or secret, and reversing it is trivial, anyone can decode Base64 with a one-line command. It provides zero security. If I ever see credentials Base64-encoded and someone calls that 'encrypted,' that's an immediate red flag.  Encryption transforms data to make it unreadable to anyone without the right key, and it's reversible on purpose for whoever holds that key. It's meant to protect confidentiality of data you need to get back later, like a file at rest or traffic in transit.  Hashing transforms data into a fixed-length digest and is one-way by design, there's no key involved and no legitimate way to reverse it. It's used to verify integrity or to store something like a password where you never need the original value back.  The gotcha in this question is usually encoding getting confused for security. I've seen real cases where sensitive data was Base64-encoded in a URL parameter or a config file and treated as protected, when anyone who saw that string could decode it instantly. The test for a candidate is whether they can articulate that only one of the three, encryption, is meant to keep data secret from someone without a key.

Question 28

What Is PKI?

Accepted Answer

PKI, public key infrastructure, is the whole system of policies, roles, and technology that makes public key cryptography usable at scale. Asymmetric encryption on its own solves how to exchange a secret without prior contact, but it doesn't solve a harder problem: how do you know a given public key actually belongs to the entity you think it does? PKI answers that.  It's built around certificate authorities that verify identity and issue digital certificates binding a public key to a name, a chain of trust from root CAs down through intermediate CAs to the certificate your browser sees, and infrastructure for checking whether a certificate has been revoked, through CRLs or OCSP, before it would naturally expire. It also covers the processes around issuing, renewing, and revoking certificates.  Without PKI, public key cryptography doesn't scale past people who've exchanged keys in person or through some other trusted channel. With it, a browser can connect to a server it's never seen before and still establish that the server's public key genuinely belongs to that domain, because a chain of signatures traces back to a root the browser already trusts.  A strong answer connects PKI to the trust problem specifically, rather than just listing components like CAs and certificates. The whole system exists because a public key by itself carries no proof of ownership.

Question 29

Why Hash Collisions Matter

Accepted Answer

A collision is when two different inputs produce the same hash output. Mathematically, collisions are guaranteed to exist for any hash function because the input space is infinite and the output space is fixed, so it's not about whether collisions exist, it's about how hard they are to find on purpose.  That matters because a lot of what hashing is used for depends on collisions being effectively impossible to engineer. If an attacker can craft two different files that produce the same hash, they can get a malicious file to carry the same digest as a legitimate one, defeating integrity checks, code-signing verification, or digital signatures that rely on the assumption that a given hash uniquely represents a given piece of data. That's exactly what happened with MD5 and later SHA-1: researchers demonstrated practical collision attacks, and both algorithms were deprecated for security-sensitive uses like certificates and signatures because you could no longer trust that a matching hash meant matching content.  It's fine, even expected, that collisions exist in theory. What isn't fine is a hash function where finding one is computationally feasible with modern hardware. That's why SHA-256 or SHA-3 are the standard now, not because they eliminate collisions, but because finding one is still far beyond realistic attacker resources. A candidate who says 'collisions are bad because they shouldn't happen at all' hasn't quite understood the actual failure mode.

Question 30

Public Key vs Private Key: When to Use Which

Accepted Answer

It depends on what you're trying to achieve, confidentiality or authenticity, and that's the part people get backwards. For confidentiality, encrypt with the recipient's public key. Anyone can encrypt a message that way, but only the person holding the matching private key can decrypt it, which is exactly what you want when you're sending something secret to a specific person.  For authenticity, the roles flip: you 'encrypt,' really sign, with your own private key. Since only you hold that private key, anyone can use your public key to verify that the signature came from you, because successfully decrypting it with your public key proves it was created with the matching private key. This is how digital signatures work: you're not trying to hide anything, you're proving origin.  So the direction depends on the goal. Public key encrypts when you want secrecy, because only the private key holder can undo it. Private key signs when you want proof of identity, because only the public key can verify it came from that specific private key. Mixing these up is a common interview trap: someone will say 'you always encrypt with the private key' or the reverse, without specifying which property they're trying to achieve. The strongest answers state the goal first, confidentiality or authenticity, then explain which key does which job and why.  One caveat worth naming: this whole encrypt-with-one-key-decrypt-with-the-other framing describes RSA specifically. ECDSA, the more common signing algorithm behind most TLS certificates today, never performs an encrypt or decrypt operation at all, verification checks a mathematical relationship instead. The property achieved, proof of private key possession, is identical, but don't extend the RSA mental model to every asymmetric scheme.

Question 31

Process vs Thread

Accepted Answer

A process is a running instance of a program with its own memory space, its own set of handles, and its own security context. A thread is a unit of execution inside that process, and a process can have multiple threads that share the same memory and resources.  The security angle matters because isolation happens at the process level, not the thread level. When you're looking at process injection techniques, like DLL injection or reflective loading, the attacker's goal is usually to get code running inside the memory space of a legitimate, trusted process instead of spawning a new one. A new process shows up in your process tree with a clear parent-child relationship and a command line you can inspect. Code running as a thread inside an existing process, say inside explorer.exe or svchost.exe, is much harder to spot because the process itself looks completely normal.  This is also why process trees matter so much in EDR telemetry. If you see winword.exe spawning a thread that later shows outbound network activity, or a process with no matching parent in its normal lineage, that's worth flagging. Understanding that threads inherit the parent process's token and permissions also explains why injecting into a high-privilege process is a common escalation and evasion trick: the injected code effectively runs with whatever access that process already had.

Question 32

Linux vs Windows File Permissions

Accepted Answer

Linux uses a fairly simple model: every file has an owner, a group, and a set of permissions for read, write, and execute, applied separately to the owner, the group, and everyone else. You see it as something like rwxr-xr-- when you list a file, and you change it with chmod, either symbolically or with the three-digit numeric shorthand like chmod 755. It's coarse-grained but predictable, and because it's baked into the filesystem itself, it's fast to reason about.  Windows uses Access Control Lists instead. Every object, not just files, has a security descriptor with a list of access control entries, each saying which user or group gets which specific rights, and whether that entry allows or denies access. That gives much finer control, you can grant one user modify rights and another read-only on the exact same folder, but it's also easier to misconfigure because there are more moving parts and permissions can inherit down a folder tree in ways that aren't always obvious.  The security implication is really about attack surface and auditability. On Linux, a world-writable file or a SUID binary that shouldn't be there stands out once you know what to look for. On Windows, an overly permissive ACL, like Everyone with full control on a service binary or a scheduled task folder, is a classic privilege escalation vector because it's easy to introduce by accident and easy to miss in a manual review.

Question 33

Why Active Directory Is Such a Big Attack Surface

Accepted Answer

Active Directory is Microsoft's directory service for Windows domains. It centralizes identity and access: users, computers, groups, and the policies that govern them all live in AD, and domain controllers handle authentication, usually through Kerberos, so a single login gets you access across the whole network instead of authenticating separately to every machine.  That centralization is exactly why it's such a large attack surface. AD grew up in an era when the assumption was that the internal network was trusted. Once an attacker lands on any domain-joined machine, there's a whole toolkit built around abusing legitimate AD features: Kerberoasting to crack service account passwords offline, pass-the-hash to reuse credential material without ever knowing the plaintext password, abusing delegation settings to impersonate other users, or simply enumerating group memberships to find a path from a low-privilege foothold to Domain Admin. None of that requires a traditional exploit, it's abuse of functionality AD is supposed to provide.  The other reason it matters so much is blast radius. Compromising a single workstation is bad, but compromising a domain controller or a Domain Admin account effectively means the attacker owns every machine, account, and resource joined to that domain. That's why so much of enterprise defense, tiered administration, protected groups, monitoring for unusual Kerberos ticket requests, exists specifically to slow down and detect movement toward that outcome.

Question 34

Why Attackers Abuse Windows Services

Accepted Answer

A Windows service is a program that runs in the background, independent of any logged-in user, managed by the Service Control Manager. Services typically start automatically at boot and often run under high-privilege accounts like Local System, which means whatever runs as that service inherits a lot of trust and access without needing a user to click anything.  That combination, auto-start plus elevated privilege plus no user interaction, is exactly what an attacker wants for persistence. If you can create a new service, or worse, hijack an existing one by pointing it at a different binary, your code survives reboots, runs before a user even logs in, and often runs with SYSTEM-level access. It also blends in, because a system with dozens of legitimate services running is normal, and a security team has to know what "normal" looks like on that specific host to spot the odd one out.  The anomalies analysts actually look for are things like a service binary running from an unusual location, say a user's Temp or AppData folder instead of System32 or Program Files, a service name that's slightly off from a known legitimate one, a newly created service around the same time as other suspicious activity, or a service configured to run an unsigned or oddly named executable. Unquoted service paths are another classic one, where a poorly configured path lets an attacker drop a malicious executable earlier in the path string and have it execute instead of the intended binary.

Question 35

Windows Registry Basics, and Why It Matters for IR

Accepted Answer

The registry is a hierarchical database that stores configuration settings for Windows itself, for installed software, and for individual user profiles. It's organized into hives, broadly split between machine-wide settings and per-user settings, and pretty much every setting change made through the GUI ends up written somewhere in the registry.  It matters to security work because the registry is one of the most common places malware touches to survive a reboot or blend into normal operation. Autorun-style keys that launch a program automatically when a user logs in are a textbook persistence mechanism, and they're attractive to attackers precisely because they're easy to set and easy to miss if you're not specifically checking for them. Malware also uses the registry to store configuration data, like a command-and-control address, so it doesn't need to carry that information hardcoded in the binary.  From an investigation standpoint, the registry is also a source of forensic history even after files are deleted. Things like recently run programs, USB device history, or network connections a machine has made can leave traces in the registry long after the activity itself. That's why registry analysis is a standard part of incident response, not just live-system triage: even on a machine that's been cleaned up, the registry often still tells you what happened.

Question 36

Windows Logs to Check First

Accepted Answer

Windows Event Viewer is the starting point, and within it the Security log is usually the most relevant for an intrusion investigation. That log captures authentication activity, things like successful and failed logons, account creation or modification, and privilege use, assuming auditing is configured to actually record those events, which isn't always the default out of the box.  In practice, I'd be looking at logon events to understand who authenticated to the box, when, and how, whether that was an interactive logon at the console, a network logon, or something like RDP. A pattern of failed logons followed by a success is worth flagging immediately. I'd also check the System and Application logs for anything unusual around service creation or crashes that correlate with the timeframe in question, and if process-creation auditing is enabled, that gives you command-line level visibility into what actually ran on the machine, often the single most useful data source you have.  The honest caveat is that these logs are local and finite, they roll over, and a capable attacker with enough access can clear them or disable auditing outright, which is itself a red flag if you notice a suspicious gap. That's the whole argument for forwarding logs to a central SIEM: local Event Viewer is fine for a quick look, but you don't want your only copy of the evidence sitting on the machine the attacker already controls.

Question 37

Linux Logs to Check First

Accepted Answer

Most of what you need lives under /var/log. Authentication activity, SSH logins, sudo usage, failed password attempts, gets written to a dedicated auth log, called auth.log on Debian and Ubuntu-based systems or secure on Red Hat and CentOS-based ones. General system messages, kernel events, and service activity go into syslog or messages depending on the distribution. On systems running systemd, journalctl gives you a unified, queryable view across services and boot sessions, which is often faster than grepping flat files.  What I'm actually looking for depends on the incident, but common starting points are repeated authentication failures against SSH, sudo commands run by an account that doesn't normally use sudo, cron jobs added or modified around the time of suspicious activity, and gaps in the logs themselves, since a log file that's suspiciously short or has a timestamp jump is often a sign someone tried to cover their tracks.  The same caveat applies as on Windows: these logs are local, and syslog in particular is plaintext and easy to tamper with once an attacker has root. That's why forwarding logs off-box to a central syslog server or SIEM as they're generated matters, it turns log tampering from "erase the evidence" into "the evidence already left the building." On a system I actually care about, I'd rather be reading from that central copy than trusting whatever's left locally.

Question 38

What Is Privilege Escalation?

Accepted Answer

Privilege escalation means getting a level of access to a system that you weren't supposed to have, using a vulnerability, a misconfiguration, or a design flaw rather than legitimate credentials for that access level. It's usually split into two directions: vertical escalation, where a low-privilege user gets admin or root, and horizontal escalation, where you move between accounts at roughly the same privilege level to reach one that has access you actually need.  At a systems level, this almost always comes down to a gap between what a process is trusted to do and what it's actually allowed to touch. On Linux, classic examples are SUID binaries that run with the file owner's privileges regardless of who executes them, misconfigured sudoers entries that grant broader command access than intended, or writable files that a privileged cron job or service later reads and executes. On Windows, it's things like a service running as SYSTEM but pointing to a binary a standard user can overwrite, weak ACLs on a directory in the system path, or exploiting a kernel driver vulnerability to jump from user mode straight into kernel mode, about as high a privilege as you can get.  The common thread across all of these is that privilege escalation rarely needs some exotic zero-day. Most real-world escalation paths are boring misconfigurations, a permission that's too loose, a path that's not quoted properly, an account with more rights than its job requires, which is also exactly why least privilege and regular permission audits matter so much as a defense.

Question 39

User Mode vs Kernel Mode

Accepted Answer

Every modern operating system splits execution into two privilege levels. User mode is where regular applications run: your browser, your office suite, most of what's on the machine. Code running there is sandboxed, it can't directly touch hardware or other processes' memory, and if it crashes, it generally only takes itself down. Kernel mode is where the operating system core, along with drivers, runs. Code there has direct access to hardware, memory, and every other process on the system, and there's no safety net if it does something wrong, a bad kernel-mode fault can crash the entire machine.  The security relevance is that kernel mode is the highest value target there is. Malware that manages to get code executing in kernel mode, usually through a vulnerable or malicious driver, can hide processes and files from user-mode security tools, disable or blind antivirus and EDR agents, and generally operate below the layer where most defensive tooling even looks. This is the idea behind BYOVD attacks, bring your own vulnerable driver, where an attacker installs a legitimately signed but flawed driver specifically to get a foothold in kernel mode that a normal exploit wouldn't give them.  It also explains why EDR products themselves often ship kernel-mode drivers, they need that same level of visibility to see what's really happening rather than trusting what user-mode APIs report. And it's why driver signing enforcement gets pushed so hard, since kernel mode is the one place where a single mistake removes essentially every user-mode security boundary at once.

Question 40

Least Privilege, Day to Day

Accepted Answer

Least privilege means giving an account, a service, or a process only the access it needs to do its job, and nothing more, and the "in practice" part is where most organizations actually fall short. It's easy to write the policy, it's harder to enforce it against the convenience of just granting broad access so nothing ever breaks.  On the endpoint side, it looks like day-to-day users working from a standard account instead of local admin, so a phishing click or a malicious download doesn't automatically get install-level access to the machine. On Linux, it looks like sudo access scoped to specific commands a user actually needs rather than blanket root access, configured through sudoers rather than just adding someone to a wheel or admin group. On the service account side, it means a service that only needs to read from a database gets read access to that database, not domain admin rights, because service accounts are a favorite target precisely when they've been over-provisioned and nobody's watching them as closely as human accounts.  In an AD environment specifically, it also shows up as tiered administration, keeping Domain Admin credentials off everyday workstations and away from accounts used for routine tasks, so compromising a helpdesk laptop doesn't hand over the keys to the domain. The practical test I'd apply to any of this is: if this specific account or process were compromised right now, what's the actual blast radius? Least privilege done well keeps that answer small.

Question 41

Residual Risk and Risk Appetite

Accepted Answer

No, and the gap between "no known vulnerabilities" and "no risk" has a name: residual risk, whatever risk remains after you've applied every control you're reasonably going to apply. It never hits zero, because some risk sources don't show up on a vulnerability scan at all: zero-days nobody's found yet, misconfigurations a scanner doesn't check for, insider threats, third-party vendors with standing access into your environment, and plain human error like a reused password or a well-crafted phishing email.  This is where risk appetite comes in, the amount of residual risk an organization is willing to accept rather than spend more money and friction trying to eliminate. No organization has infinite budget or infinite patience for friction, so leadership has to decide, explicitly or by default, how much residual risk is acceptable for a given system. A hospital's risk appetite for a system holding patient records should be much lower than a marketing team's risk appetite for an internal event-planning tool, and treating every system with the same bar either wastes money hardening things that don't need it or leaves the wrong things exposed.  The practical mistake I see is a team treating "we patched the last finding" as the finish line instead of asking two follow-up questions: what residual risk is left that a scanner wouldn't catch, and has anyone with the authority to accept that risk actually signed off on it. Compliance programs formalize this as a risk acceptance or risk register process for exactly this reason, so residual risk becomes a documented decision, not a blind spot nobody chose.

Question 42

Qualitative vs Quantitative Risk Assessment

Accepted Answer

Qualitative risk assessment ranks risks using descriptive categories, things like high, medium, low, or a simple scoring matrix that multiplies a 1-to-5 likelihood score by a 1-to-5 impact score. It's fast, doesn't need much data, and works well when you're trying to prioritize a long list of risks quickly or when the people in the room don't have hard numbers to work with. The tradeoff is that it's subjective. What one person calls 'medium' another might call 'high,' and it doesn't tell leadership much about actual dollar exposure.  Quantitative assessment tries to put a number on it, usually in financial terms. You estimate how often something might happen in a year, the annualized rate of occurrence, and how much a single occurrence would cost, the single loss expectancy, multiply them together, and get an annualized loss expectancy. That number is far more useful when you're trying to justify a security budget to a CFO, because 'this could cost us roughly this much a year if we don't fix it' lands better than 'this is a high risk.'  In practice, most organizations use qualitative assessment for the bulk of day-to-day risk triage because it's cheap and fast, and reserve quantitative analysis for the handful of risks big enough to warrant the extra effort, like a major system outage or a regulatory fine. Knowing when the extra precision is worth the cost is the real skill here, not just knowing the formulas.

Question 43

Risk Treatment: Accept, Mitigate, Transfer, Avoid

Accepted Answer

Once you've identified a risk, you've got four real options, and picking the wrong one usually comes down to not being honest about cost versus exposure.  Mitigate means you reduce the risk, you don't eliminate it. Patching a vulnerability, adding MFA, segmenting a network, these lower the likelihood or the impact but rarely bring the risk to zero. Most day-to-day security work lives here.  Accept means the organization looks at the risk and decides the cost of fixing it outweighs the cost of just living with it. That's a legitimate business decision as long as it's made consciously, with the right person signing off, not just ignored because nobody got around to it. A lot of 'accepted' risk in real companies is actually just neglected risk wearing a nicer label.  Transfer means shifting the financial consequence to someone else, most commonly cyber insurance, or contractually pushing liability onto a vendor. It doesn't reduce the likelihood of the incident happening at all, it just changes who pays when it does.  Avoid means you change what you're doing so the risk no longer applies, shutting down a legacy system nobody uses, or deciding not to build a feature that would require storing sensitive data you don't want to be responsible for.  In an interview, the thing that shows real understanding is recognizing that these aren't mutually exclusive. A single risk often gets mitigated as far as it's practical to, insured against for what's left, and formally accepted beyond that point.

Question 44

Why Compliance Frameworks Matter (GDPR, PCI-DSS, HIPAA)

Accepted Answer

Frameworks like GDPR, PCI-DSS, and HIPAA exist because certain kinds of data cause real harm to real people when they leak, and industries proved repeatedly that they wouldn't protect it adequately without someone requiring it. You don't need to be a lawyer to work in security, but you do need to understand roughly what each one is protecting and why, because it shapes what your job actually looks like day to day.  GDPR is about personal data of people in the EU, and its core idea is that people have rights over their own information, including knowing what's collected and being able to ask for it to be deleted. PCI-DSS exists because payment card data getting stolen has direct financial fallout, so it sets baseline security requirements for anyone that handles card numbers, things like encrypting cardholder data and restricting who can access it. HIPAA covers health information in the US, because medical data is both deeply personal and valuable to attackers, and a breach can affect someone's insurance, employment, or safety.  For an analyst, the practical relevance is that these frameworks often dictate what you're required to log, how fast you're required to report a breach, how long data can be retained, and what counts as an incident that has to be escalated to legal or compliance rather than just closed out. Ignoring that context means you can technically fix a security issue and still leave the organization exposed to a regulatory one.

Question 45

Phishing vs Spear Phishing vs Whaling vs Vishing

Accepted Answer

Phishing at its core is a social engineering attack that uses a message, usually email, to trick someone into handing over credentials, clicking a malicious link, or opening a malicious attachment. It works because it exploits trust and urgency rather than a technical flaw, which is exactly why it's so hard to fully block with technology alone.  The variants differ mainly in how targeted they are. Regular phishing is a mass campaign, the same message sent to thousands of people hoping a small percentage bite. Spear phishing is targeted at a specific person or small group, using details the attacker has researched, their job title, a recent project, a coworker's name, to make the message feel personal and credible. Whaling is spear phishing aimed specifically at senior executives or other high-value targets, often impersonating a CEO or CFO to authorize a wire transfer or request sensitive data, because the payoff for compromising one executive is much higher than compromising a random employee. Vishing is the voice version, a phone call instead of an email, often impersonating IT support, a bank, or a vendor, and it can be more effective than email because a live human voice creates pressure that's harder to pause and think through.  What connects all of them is that the attacker is manipulating a person's judgment, not exploiting a system. That's why the best defenses combine technical controls like email filtering with training people to slow down and verify unusual requests before acting on them.

Question 46

What Is a Man-in-the-Middle Attack?

Accepted Answer

A man-in-the-middle attack is when someone positions themselves between two parties who think they're communicating directly with each other, intercepting, and sometimes altering, the traffic without either side knowing. Classic examples are an attacker on the same unsecured Wi-Fi network as a victim, or someone who's compromised a router or DNS server so traffic gets routed through them before reaching its real destination.  The reason it still works even when a connection 'looks secure' comes down to how trust gets established. HTTPS protects data in transit, but only if the certificate exchange happens correctly and the user actually verifies who they're talking to. Attackers get around this by presenting a fraudulent certificate, downgrading the connection to an unencrypted version, or exploiting a user who ignores a certificate warning and clicks through anyway. Public Wi-Fi is a common setting for this because it's trivial for an attacker to sit on the same network and intercept unencrypted traffic, or run a fake access point that looks identical to the legitimate one.  The reason this matters beyond the technical mechanism is that MITM attacks often aren't about brute-forcing encryption, they're about exploiting the gap between what a system is capable of protecting and what a user actually verifies. Things like HSTS, certificate pinning, and avoiding sensitive transactions on untrusted networks close that gap, but none of them help if the user ignores the warning telling them something's wrong.

Question 47

DoS vs DDoS

Accepted Answer

A denial of service attack is one source overwhelming a system, a server, an application, or a network, with enough traffic or requests that it can't respond to legitimate users anymore. A distributed denial of service attack has the same goal, making a service unavailable, but the traffic comes from many sources at once, often thousands of compromised devices in a botnet, rather than a single attacking machine.  The distributed part matters for two practical reasons. First, it's far harder to defend against, because you can't just block one IP address or a small range and be done with it, the traffic is coming from everywhere, often from real residential devices that got infected without their owners knowing. Second, it's much harder to trace back to the actual attacker, since the botnet operator is hiding behind a layer of compromised machines that did the actual attacking.  Both types can target different layers. Some floods just try to saturate network bandwidth, others target application-layer resources, like repeatedly hitting an expensive search function or login endpoint to exhaust server processing power rather than bandwidth. The defense also differs by layer, bandwidth-based attacks get mitigated with upstream filtering and scrubbing services, while application-layer attacks need smarter rate limiting and behavioral detection because the requests can look legitimate individually.  The interview-relevant point is that scale and origin are what separate the two, not the goal, since both are ultimately trying to make a service unavailable.

Question 48

Explain SQL Injection

Accepted Answer

SQL injection happens when an application takes input from a user and drops it directly into a database query without treating it as pure data first. The database can't tell the difference between the part of the query the developer wrote and the part an attacker snuck in, because to the database, it's all just one string of text it's told to execute. If a login form builds a query by literally concatenating whatever the user typed into the username field, an attacker can type something that closes out the intended query early and adds their own SQL logic, tricking the database into, say, returning every user in the table instead of just checking a password.  The root cause isn't that SQL is inherently insecure, it's that the application trusted user input to behave like data when it was actually being interpreted as code. That's the same underlying failure behind most injection-style vulnerabilities.  What actually prevents it is parameterized queries, also called prepared statements, where the query structure is defined separately from the data being inserted into it, so the database always knows which parts are commands and which parts are values, no matter what a user types. Input validation and sanitization help as an additional layer, but they're not a substitute, because it's very hard to anticipate every way malicious input could be crafted. If a developer tells you they rely only on filtering out quote characters instead of parameterized queries, that's a strong sign the fix is incomplete.

Question 49

Explain Cross-Site Scripting (XSS)

Accepted Answer

Cross-site scripting happens when an application takes user-supplied input and renders it back into a page without properly encoding it, so instead of displaying the text a user typed, the browser executes it as actual code. If a comment field takes whatever someone types and drops it straight into the page's HTML, and someone types a script tag instead of a normal comment, every visitor who loads that page runs the attacker's script inside their own browser session.  It's dangerous specifically because that script runs with the same trust and permissions the legitimate site has in the victim's browser. It can read cookies and session tokens, which lets an attacker hijack a logged-in session without ever knowing the victim's password. It can redirect the page, log keystrokes, or quietly submit forms on the victim's behalf. None of this requires compromising the server at all, the server is just the delivery mechanism for a script that does its damage inside someone else's browser.  There are a few flavors worth knowing: stored XSS, where the malicious script gets saved on the server and served to every future visitor, reflected XSS, where it's bounced back immediately from a single malicious link or request, and DOM-based XSS, where the vulnerability lives entirely in client-side JavaScript rather than anything the server returns.  The real fix is proper output encoding, making sure anything a user submitted gets displayed as literal text rather than interpreted as markup, combined with a strong content security policy that limits what scripts are allowed to run in the first place.

Question 50

Social Engineering: the Weakest Link

Accepted Answer

Social engineering is the practice of manipulating people, rather than systems, into doing something that compromises security, handing over a password, holding a door open for someone without a badge, plugging in a USB drive they found in the parking lot, approving a payment they shouldn't. Phishing, vishing, and pretexting are all specific techniques under that umbrella, but the umbrella itself is broader than any single delivery method.  It gets called the weakest link because no amount of technical control fixes the fact that people are wired to be helpful, to trust authority, and to want to avoid conflict. An attacker doesn't need to find a zero-day if they can just call someone pretending to be from IT and ask them to reset a password over the phone. Every organization can have a fully patched network, strong firewalls, and MFA everywhere, and still get breached because someone trusted a convincing enough story.  What makes social engineering effective is that it exploits normal, reasonable human behavior rather than a flaw or a mistake. Someone holding a door for a person carrying boxes isn't being careless, they're being polite, and that's precisely what tailgating relies on. This is why training alone isn't a complete fix either, since attackers adapt their pretexts constantly. The realistic defense is a mix of awareness training, clear verification procedures for sensitive requests like wire transfers or password resets, and a culture where questioning something unusual isn't seen as rude or as slowing everyone down.

Question 51

A 200+ Alert Queue and a Growing Backlog

Accepted Answer

A 200-alert queue isn't a queue you clear top to bottom, it's a queue you have to sort first. I'd spend the first two or three minutes grouping by severity and by asset criticality, because a critical alert on a domain controller and a critical alert on a kiosk PC are not the same problem even if the SIEM scored them the same. After that I look for patterns: if fifteen of those alerts are the same signature firing against different mailboxes, that's probably one phishing campaign, not fifteen separate investigations. Working the root cause first often closes or downgrades a chunk of the backlog at once.  I also watch for alerts that are noisy because a detection rule is badly tuned rather than because something real is happening. If I can confirm that quickly, I'll suppress or bulk-close with notes and flag the rule for tuning after the shift, so the same flood doesn't hit the next analyst. What I won't do is quietly sit on a growing backlog and hope it clears. If volume is genuinely outpacing what one person can safely triage, that's a conversation with my lead, not something to absorb silently. Alert fatigue causes real misses, and the honest move is to say the queue is unsafe rather than rush through it and let something critical slip past at 2am.

Question 52

Encoded PowerShell Alert, End of Shift

Accepted Answer

Being close to the end of shift doesn't change what I check, it just means I move through the same steps faster and don't skip any of them to save five minutes. First I decode the command line, base64-encoded PowerShell hides the real payload and I want to see what it actually does before I judge it. Then I look at the parent process: if it's spawned from winword.exe or an email client, that's a very different story than if it's launched from a scheduled task an IT admin owns.  Next I check the account and the asset. Is this a standard finance user, or does IT run automation from that box? A lot of encoded PowerShell in real environments is legitimate deployment tooling, and knowing your environment's baseline is what separates a two-minute close from a false escalation. I'd also check EDR for anything downstream, network connections, new processes, credential access attempts, since that tells me whether this was just an odd-looking command or an actual chain.  If I can't reach a confident answer before I need to leave, I don't force a verdict to clear my desk. I'd isolate the host if there's any real doubt and it's a sensitive endpoint, then hand off with a clear timeline of what I checked and what's still open. Closing something as benign just to hit the clock is how real incidents get missed.

Question 53

Three Alerts at Once: Ransomware, VIP Account, Port Scan

Accepted Answer

Severity labels are a starting point, not the answer. The ransomware-behavior alert on a server gets my attention first, because encryption events move in minutes and the damage is often irreversible once it spreads. I'd also check whether EDR already auto-contained the host, since a lot of platforms will isolate on that kind of behavior without waiting for an analyst, which changes how urgently I need to act versus just verify.  The impossible-travel alert on a VIP account is the one I'd watch most carefully even though I'm not working it first. Executive accounts are high-value targets, and if it's a real account takeover, the exposure keeps growing every minute it sits. If the platform supports it, I'd trigger a quick containment step, forcing re-authentication or an MFA challenge, as a stopgap while I finish the higher-urgency item, rather than leaving it completely untouched.  The internal port scan is the one I'd park. Internal scanning is frequently a vulnerability scanner, a misconfigured monitoring tool, or an asset discovery job, and it rarely causes damage in the few minutes it takes to get to it. I'd note the source host and come back to it, or hand it to a teammate if one's free.  The reasoning a hiring manager wants to hear isn't "I did the critical one first," it's why: impact, reversibility, and how fast each situation is moving.

Question 54

First 15 Minutes on a New Alert

Accepted Answer

The first few minutes are about building context, not making a decision. I start by reading the alert exactly as it's written, what triggered it, what the raw log or EDR telemetry actually shows, rather than trusting the alert title alone. Titles get generalized by the detection rule and can undersell or oversell what's really there.  From there I pull up the asset and the account: is this a domain controller or someone's laptop, a service account or a real user, and is there any change ticket or maintenance window that explains the activity. That single check resolves a surprising number of alerts on its own.  Then I look at history. Has this exact alert fired on this host before, and if so, was it closed as benign or as a real finding. I'll also scan for anything else that fired around the same timestamp for the same user or asset, since attacks rarely trip only one detection.  By the ten to fifteen minute mark I want to have a working theory: benign and explainable, needs deeper investigation, or serious enough to escalate or contain now. I don't need full certainty yet, but I should know which of those three buckets I'm in and what specific evidence would move me to the next one.

Question 55

A Severe-Looking Alert You Didn't Escalate

Accepted Answer

I had an EDR alert flag credential access behavior against LSASS on a file server, the kind of alert that reads like Mimikatz on the surface and gets your heart rate up. Before escalating as an active intrusion, I checked the actual process: signed binary, known publisher, and it matched a backup agent that the server team confirmed runs a legitimate credential-read operation as part of its service account handling. I checked whether this happened on other servers running the same backup software on a schedule, and it did, at the same time every night.  I also checked for anything that would tell a different story: unsigned code, a connection out to an unfamiliar external IP, follow-on lateral movement, or any account activity outside that service account's normal pattern. None of that was present, so I documented the finding as a known-benign pattern tied to that backup product, tagged it for allowlisting, and closed it rather than kicking it upstairs.  What would have flipped my decision immediately: an unsigned or unknown binary doing the same thing, any network connection to infrastructure not tied to that backup vendor, or the behavior showing up on a host that had no business running that software. Scary-looking technique names are a starting point for investigation, not a verdict. The call to not escalate has to be backed by something you actually checked, not a gut feeling that it's probably fine.

Question 56

Building a Full Timeline From One Alert

Accepted Answer

Start with what the alert actually gives you: process name, parent process, full command line, hash, host, user, and timestamp. That's your anchor point, not the alert time itself, since alert time and event time can differ by minutes depending on your EDR's detection latency.  From there I pivot on the process GUID and host. Pull Sysmon or EDR telemetry for that host in a window around the event, maybe thirty minutes before and after to start. I'm looking at process creation, network connections, and file writes tied to that process tree, both parents and children. If the process reached out somewhere, I note the destination IP and port.  Next I take the user account and host and go to the SIEM for authentication events: 4624 for logons, 4648 if explicit credentials were used, 4672 if elevated privileges got assigned. That tells me how the user or the process got there and whether anything unusual happened around access.  Then network logs, proxy, DNS, firewall, to see if the destination from EDR shows up and where else that host or IP talked to. If I find lateral spread, I widen the timeline and repeat the same process on the next host.  The key discipline is anchoring everything to a shared identifier, host, user, or process GUID, and expanding outward in both directions until the story stops generating new leads.

Question 57

PsExec: Admin Work or Lateral Movement?

Accepted Answer

First question: is there a ticket or change record for this? Legitimate patch pushes almost always have a change window, an approved account, and a target list somewhere, even if the sysadmin didn't file it perfectly. I'd check the CMDB or change management system before assuming anything.  Then I look at the account. Was this a dedicated service or admin account with a documented purpose, or a regular user account, especially one that showed signs of compromise earlier in the day? Attackers using PsExec usually ride on credentials they just stole, not a long-standing admin account with normal usage history.  Timing matters too. A 2 AM push during an approved maintenance window reads differently than the same activity at 2 AM on a random Tuesday with no maintenance scheduled.  Scope is a big tell. Twenty servers matching a known patch list is very different from a spray across random hosts that includes workstations with no reason to be touched.  I'd also check the command line itself. A PsExec call running an MSI installer looks nothing like one running whoami, net group, or a credential dumping tool. And I'd check whether the PSEXESVC service got cleaned up afterward, since sloppy attackers sometimes leave it behind.  None of these signals alone is conclusive. Together they usually make the picture obvious.

Question 58

Evidence Handling When It Might Go Legal

Accepted Answer

Everything slows down and gets documented. The moment I think this could go legal, whether it's an insider threat case or something law enforcement might touch, I stop treating it like a routine incident and start treating every action I take as something I might have to explain later.  Practically that means: I stop making live changes to affected systems unless absolutely necessary for containment, and if I have to touch something, I log exactly what I did and why. I follow chain of custody, every piece of evidence gets a record of who collected it, when, how, and everywhere it's been since. I use forensically sound collection methods, imaging with a write blocker rather than just copying files off a live system, and I hash everything at collection time so integrity can be proven later.  I also escalate early, to legal, HR, and whoever owns the formal forensics process in the org, rather than freelancing an investigation that might need to hold up in court. I follow order of volatility, capturing memory and network state before anything that can wait. NIST SP 800-86 is a decent reference framework for the collection and handling steps if the org doesn't have its own documented process.

Question 59

Correlating Logs Across UTC, Local Time, and Clock Drift

Accepted Answer

The first thing I do is figure out what timezone each source is actually in, not what I assume it is. EDR agents usually log in UTC by default, SIEMs often normalize to UTC on ingest but display in local time depending on the analyst's settings, and legacy devices like that firewall might be running on whatever the box's local clock says, which drifts if NTP was never configured.  For the firewall specifically, I don't trust its clock at face value. I look for an event on that device that I can also see, or infer, from a trusted time source, something like a known connection that also shows up in DNS or proxy logs with a reliable timestamp. That gives me a way to calculate the offset, whether it's five minutes fast or twenty minutes slow, and I apply that offset consistently across the dataset from that device.  Everything I present gets normalized to a single timezone, almost always UTC, before I build the actual timeline. And when absolute time can't be trusted, I fall back on relative sequencing, which event happened before which, using consistent identifiers like session IDs or connection tuples rather than trusting the clock alone. I document every offset and assumption I made so the next analyst isn't fooled by the same drift.

Question 60

When the Evidence Contradicts the Ticket

Accepted Answer

I've had this happen. A ticket says a user clicked a phishing link and got a malware download, but three hours into the investigation the process tree shows the actual initial access was a vulnerable browser plugin exploited through a completely different site the user had open in another tab.  At that point, the evidence wins. Always. I don't try to make the data fit the original narrative just because that's what the ticket said or what the user remembered. People misremember timelines, misidentify which email they clicked, or genuinely don't know how they got infected.  What I do next is document the discrepancy clearly, what the original report claimed versus what the evidence actually shows, and why I believe the evidence. Then I go back to whoever filed the original report or ticket, not to blame them, but to understand where the disconnect came from. Sometimes it's a user's honest mistake, sometimes it's a previous analyst who anchored on the first plausible theory and stopped looking.  I update the ticket and the timeline with the corrected story and make sure anyone downstream, whether that's leadership, IR, or a report going to a client, gets the accurate version, not the one that was easier to write first.

Question 61

Isolate Now or Monitor the Intruder First?

Accepted Answer

This is a risk trade-off, not a rule. Isolating immediately kills the threat but also kills your visibility into what the attacker was actually doing, whether they had other footholds, and whether they'd notice the takedown and burn evidence elsewhere. Watching buys intel but extends the window where they can move laterally, escalate, or exfiltrate.  The first thing I check is what the host can reach. If it's a jump box near sensitive data, domain controllers, or has cached privileged credentials, the exposure math changes fast and I lean toward containing now. If it's a low-privilege endpoint with limited network reach and my EDR telemetry is solid enough to track their moves in real time, a short, time-boxed monitoring window makes sense, usually measured in hours, not days.  I also look at what they're doing in the moment. Staging data for exfil, touching credential stores, or trying to move to a domain controller means the clock runs out immediately regardless of what I'd hoped to learn. Quiet recon or dwell with no escalation gives more room to watch.  This isn't a call I make alone. I loop in the IR lead and, depending on the org, legal, since some contracts or cyber insurance policies require containment within a set window regardless of intel value. I'd rather have a documented, defensible decision than a clever one nobody signed off on.

Question 62

How Wide Should a Credential Reset Go?

Accepted Answer

The scope of the reset depends on what level of access the attacker actually had on that box, not just which account they logged in with.  First question: did they ever get local admin or SYSTEM? If so, they had the ability to dump LSASS, read the SAM database, or pull cached credentials for anyone who'd logged in interactively, via RDP, or as a service account on that host. At that point I treat every credential that ever touched that machine as potentially exposed, not just the one account I found evidence for. I pull logon history for that host, cross-reference logon types, and build the list from there.  Second question: is there evidence of a credential dumping tool actually running, whether from EDR alerts, process execution logs, or LSASS access flags? If yes, that confirms the wider reset regardless of privilege level, since the intent was clearly to harvest more than one identity.  If neither of those is true, meaning the attacker stayed within the context of the one compromised user and never escalated, I keep the reset scoped to that account, but I still watch for anomalous logons from it for a while after.  Priority order when the reset does need to be wide: privileged and service accounts first, since those cause the most damage if reused, then everyone else.

Question 63

Removing Persistence Without Tipping Off the Attacker

Accepted Answer

I don't touch it yet. Ripping out one persistence mechanism the moment I find it tells an attacker who's watching their C2 check-ins that they've been discovered, and that can trigger them to accelerate, destroy evidence, or trigger a dead man's switch if they've built one in. The instinct to clean up immediately is usually the wrong one here.  Instead, I treat the find as a lead, not an endpoint. I quietly document it, forensically preserve it if I can, and keep hunting for every other foothold across the environment, since attackers rarely rely on a single persistence mechanism on a single host. That means checking other systems the account or host touched, looking for similar scheduled tasks, services, WMI subscriptions, or startup entries elsewhere, and mapping the full footprint before acting on any of it.  Once I have that full picture, eradication happens as one coordinated sweep rather than piecemeal cleanup. Ideally that's timed for a low-activity window, paired with network containment and credential resets happening at the same moment, so there's no gap where the attacker can notice one action and reposition before the rest lands.  That timing and scope decision goes up to the IR lead, since it usually involves a judgment call about how much longer to tolerate active risk in exchange for a clean, complete takedown.

Question 64

Containing a System That Can't Go Offline

Accepted Answer

Full isolation isn't on the table, so containment has to happen at a narrower layer than the whole host.  If the system has an EDR agent, network containment through the agent is usually the first move, since it cuts off general network traffic while leaving a channel open for the management console, which lets the response team keep visibility and control without pulling the box offline. If there's no agent, and that's common with medical devices running unsupported or embedded OSes, containment has to happen at the network layer instead: firewall rules or ACLs restricting the device to only the specific ports and destinations it needs, VLAN segmentation to cut it off from the rest of the network, or blocking the specific malicious IP or protocol at the switch.  I also look at whether I can kill the malicious process or session without stopping the service itself, which buys time without an outage.  For medical devices specifically, clinical engineering and the vendor need to be in the conversation early, since patient safety constraints and regulatory requirements shape what's actually allowed. For production databases, the system owner and business leadership need to weigh in on acceptable risk if some exposure has to remain temporarily.  Whatever residual risk stays after compensating controls go in gets documented and explicitly accepted by someone with the authority to accept it, not left implicit.

Interview Prep · Q&A

PICK WHERE TO START

Fundamentals of Cybersecurity

SOC Operations

Incident Response

Threat Hunting

Threat Intelligence

Digital Forensics

Red Team

VAPT

Malware Analysis

General & Behavioral

Cloud Security

FILTER & DRILL