47 Cybersecurity Engineer Interview Questions Candidates Actually Get Asked

Cross-site scripting injects attacker-controlled script that runs in a victim's browser under your site's origin, stealing cookies, session tokens, or defacing the page. Cross-site request forgery tricks a victim's browser into submitting a request to your site using their existing session, without the attacker ever seeing the response.

Because the failure modes are different, the fixes don't overlap much. XSS gets fixed with output encoding and a strict Content Security Policy. CSRF gets fixed with anti-CSRF tokens or the SameSite cookie attribute, which stops the browser from attaching cookies to cross-site requests in the first place. A candidate who proposes CSRF tokens as an XSS fix, or the reverse, hasn't fully understood either vulnerability.

It's an API that doesn't limit how much a single client can request, in volume, size, or computational cost, so a legitimate-looking authenticated user can exhaust server resources without ever tripping a DDoS-style volumetric alert. A search endpoint with no page-size limit, or a report-generation endpoint with no timeout, are both textbook cases.

The fix is rate limiting, request size caps, and timeouts enforced server-side, not just documented in an API spec that nothing actually validates against. It's a quieter failure mode than a DDoS because the traffic pattern looks like one busy user, not a flood.

A network firewall filters at layers 3 and 4, deciding what's allowed based on IP addresses, ports, and protocols. It has no visibility into what's actually inside an HTTP request body. A WAF operates at layer 7, inspecting request bodies and headers to catch injection and cross-site scripting patterns before they reach the application.

Neither one is sufficient alone. A network firewall can't see application-layer content at all, and a WAF still misses API abuse patterns and business-logic vulnerabilities that don't look like an attack signature. Both need secure coding practices underneath them regardless.

Brute force tries many passwords against one account. Credential stuffing tries pairs of usernames and passwords, harvested from an unrelated breach, against your login endpoint, betting that some fraction of users reused the same password elsewhere. It works because password reuse is common, not because your rate limiting failed.

Rate limiting per account doesn't help much here since each stuffed credential pair typically only gets tried once or twice per account, spread across a huge list of accounts using a botnet with thousands of source IPs. Detection needs to look at request patterns across accounts (many distinct accounts, low attempts each, from a wide IP range) and layer in device fingerprinting or a challenge triggered by that pattern, not just a per-account attempt counter.

Volumetric attacks flood bandwidth with raw traffic volume, UDP floods and amplification attacks are the classic examples. Protocol attacks, like the SYN flood covered earlier, exhaust server or network device resources rather than bandwidth. Application-layer attacks target a specific expensive operation, a search endpoint or a login form, with traffic that looks legitimate at the network layer but is deliberately expensive to process.

Volumetric attacks get mitigated upstream, at a CDN or scrubbing provider with far more bandwidth than the attack. Protocol attacks get mitigated at the network and OS level, SYN cookies being one example. Application-layer attacks need application-aware defenses, rate limiting and behavioral analysis, since the traffic looks normal to anything that isn't inspecting what the requests are actually asking the application to do.

Authentication answers "who are you." A real authentication bug: an API that accepts an expired JWT because signature validation gets skipped on certain code paths, letting a token that should have been rejected authenticate a request anyway. Authorization answers "what can you do now that we know who you are." A real authorization bug: checking that a user is logged in but never checking whether they own the specific resource being requested, which is the broken object-level authorization problem covered earlier.

Interviewers ask this because candidates who can define both terms correctly still sometimes describe an authorization bug and call it an authentication problem, or the reverse, which tells the interviewer the distinction hasn't actually landed yet.

Common factors beyond a password: SMS or voice one-time codes, authenticator app codes (TOTP), push notifications to a registered device, and hardware security keys using FIDO2/WebAuthn. They're not equally strong.

SMS OTP is weakest because it depends on the mobile carrier's own authentication for a SIM swap, an attacker who convinces a carrier's support line to port a victim's number gets the OTP with no further effort. Push notifications fix the SIM-swap problem but introduce "MFA fatigue," repeatedly sending approval prompts until a tired user taps approve. Hardware keys are the strongest widely deployed option because they're phishing-resistant by design, the key checks the actual domain requesting authentication, not just whatever the user was shown.

Symmetric encryption uses the same key to encrypt and decrypt, it's fast and used for bulk data, AES is the standard choice. The hard problem it doesn't solve is getting that shared key to both parties securely in the first place.

Asymmetric encryption uses a key pair, a public key anyone can have, and a private key only the owner holds, and solves exactly that key-distribution problem, at a real performance cost, it's much slower than symmetric encryption for large amounts of data. In practice, TLS uses both together: an asymmetric handshake to safely agree on a shared secret, then fast symmetric encryption (AES) for the actual data transfer using that negotiated secret.

Vulnerability scans are automated and continuous, finding known CVEs and misconfigurations quickly and cheaply, but they miss logic flaws and chained vulnerabilities that only show up when a human strings multiple small weaknesses together into a real exploit path.

Penetration tests are manual, time-boxed, and simulate an actual attacker's reasoning, catching exactly what scans miss, but they only reflect the system's state at the moment of testing. A vulnerability introduced the week after a pentest wraps up won't be caught until the next one, which might be a year away. Running both, scans continuously and pentests periodically, covers the gap either one leaves on its own.

Translate the technical finding into business language: a realistic exploit scenario, what data or functionality is actually affected, and concrete consequences, regulatory fines, incident response costs, reputational damage. "This SSRF could expose AWS credentials and let someone read customer data from S3" lands with a room full of product managers in a way "high-severity SSRF, CVSS 8.6" never will.

When a team pushes back on prioritizing a fix, escalate through their engineering manager rather than repeating the same technical argument louder. Most pushback isn't disagreement about the risk, it's a genuine competing priority that needs a manager's context to resolve, and treating it as a security-versus-engineering fight instead of a prioritization conversation rarely gets the fix shipped faster.

A useful tabletop presents a specific, realistic scenario, not a generic "there's been a breach," and forces the actual decision-makers (not just the security team) to work through their real roles: who talks to legal, who decides on customer notification, who has the authority to take a production system offline. The exercise is only worth running if it surfaces a gap in the plan, an unclear owner, a contact list that's out of date, a decision nobody had actually made in advance.

Run it without warning the exact scenario details ahead of time, and time-box decisions the way a real incident would force them. A tabletop where everyone has read the scenario beforehand and calmly discusses the "right" answer tests nothing that a real incident, arriving at 2 a.m. with incomplete information, will actually demand.

IDS (intrusion detection system) is passive. It monitors traffic or host activity and raises alerts when it matches known-bad signatures or anomalous patterns, but it doesn't sit inline with the traffic itself. A copy gets mirrored to it via a SPAN port or network tap, and if it flags something, a human or a separate system has to act on it. An IPS (intrusion prevention system) sits directly in the path of the traffic, so it can drop or reset a connection the moment it matches a bad signature.

That placement difference has real consequences. An IPS false positive can take down legitimate traffic instantly, so teams often run new IPS signatures in detect-only mode for a while before flipping them to block, essentially running it as an IDS until they trust it. An IDS false negative or slow triage means an attacker has more time to act before anyone notices, since detection alone buys visibility, not containment.

Most shops run both. A NIDS like Suricata or Zeek tapped off the core switch gives visibility and forensic data, while IPS functionality baked into the perimeter firewall or a dedicated appliance handles the traffic they're confident enough to auto-block, things like known malware C2 signatures or exploit attempts against unpatched CVEs. Host-based versions (HIDS/HIPS) matter more once the concern shifts from perimeter traffic to lateral movement inside the network.

Confidentiality means only authorized parties can read the data. Integrity means the data hasn't been altered without authorization. Availability means the data and systems are actually accessible when needed. The trick with the CIA triad isn't memorizing the three words, it's noticing that they trade off against each other, and most security decisions are really about deciding which one matters most for a given asset.

Encryption at rest is a straightforward confidentiality control. It stops someone who steals a disk or a backup from reading the contents without the key. Integrity gets enforced with things like TLS message authentication codes, code signing, or database write-ahead logs and checksums that let you detect if a file or transaction was tampered with in transit or storage. Availability shows up as redundancy: load balancers, multi-AZ database failover, DDoS mitigation, and backups that have actually been tested by restoring from them, not just backups that exist.

The trade-off is real. A system locked down so hard for confidentiality that on-call engineers can't get emergency access during an incident is failing on availability. A highly available system replicated everywhere without encryption is failing on confidentiality. Good security design is explicit about which leg of the triad matters most for a given piece of data. A public marketing site cares mostly about availability and integrity, a database of social security numbers cares overwhelmingly about confidentiality.

A vulnerability is a flaw, a weakness in code, configuration, or design that could be abused to do something the system wasn't supposed to allow, like a buffer overflow in a library or a misconfigured storage bucket left public. It's a static fact about the system. An exploit is the actual code or technique that takes advantage of that vulnerability to produce a concrete outcome: arbitrary code execution, privilege escalation, data exfiltration. Not every vulnerability has a public exploit, and having a vulnerability doesn't mean you've been attacked, it means you're exposed if someone builds or buys the exploit.

A patch is the vendor or maintainer's fix for the vulnerability, usually a code change that closes the specific flaw. The gap between vulnerability disclosure and patch application is where most real damage happens. A CVE getting published with a proof-of-concept exploit attached, which happens constantly within days of disclosure, turns a theoretical risk into an active one immediately, well before most organizations have scheduled the patch window.

This is also why patch management isn't just "apply everything as fast as possible." A vulnerability with no known exploit, low exploitability score, and no internet-facing exposure is a very different priority than one with a public working exploit hitting a service exposed to the internet, which is basically what CVSS combined with EPSS is trying to formalize.

The same-origin policy is the browser rule that a script running on one origin, defined by scheme, host, and port together, can't read data from a different origin unless that origin explicitly allows it. If someone is logged into their bank in one tab and a malicious site is open in another, JavaScript on the malicious page can't just reach over and read the bank's page content or make an authenticated fetch call and read the response, even though the browser still sends the session cookie along with any request it does make.

It's strict because without it, the web wouldn't be safe to use at all. Every site would be able to script-read the DOM, cookies, and local storage of every other site open in the browser, turning any malicious tab into a data thief for the entire browsing session. The policy specifically blocks reading the response, not sending the request, which is exactly the gap that CSRF exploits and why CSRF tokens exist as a separate defense.

CORS is the deliberate, opt-in relaxation of this rule. A server sends back headers like Access-Control-Allow-Origin to say scripts from this other origin are allowed to read its responses. Misconfiguring CORS, reflecting the request's Origin header back with Access-Control-Allow-Origin set to that reflected value and Access-Control-Allow-Credentials set to true, is one of the more common ways teams accidentally undo the same-origin policy's protection entirely.

Confirm exploitability first: can the payload actually read data, modify it, or execute commands, or does the scanner just suspect a pattern in the query string? Reproduce it with a controlled proof of concept against a non-production copy if one exists, and document exactly what the payload returned. Only after that do you loop in the engineering owner with severity, reproduction steps, and the likely blast radius.

# vulnerable: string concatenation lets input become part of the SQL
query = f"SELECT * FROM users WHERE email = '{user_input}'"
cursor.execute(query)

# fixed: parameterized query, the driver escapes user_input for you
query = "SELECT * FROM users WHERE email = %s"
cursor.execute(query, (user_input,))

The fix itself is almost always parameterized queries or prepared statements, with input sanitization treated as a secondary layer rather than the primary defense. Verify the fix by retesting the actual payload, not by reading the diff and assuming it's correct. Candidates who describe remediation before discovery and communication steps are the ones interviewers push back on hardest.

Mass assignment happens when an API automatically binds every field in a request body to a model's attributes, including fields the client shouldn't be able to set directly, like isAdmin or accountBalance. A user updating their display name can slip an extra field into the same request and quietly grant themselves admin rights.

It keeps shipping because frameworks make automatic binding the convenient default. The fix is an explicit allow-list of bindable fields per endpoint, not a deny-list, since a deny-list has to anticipate every dangerous field in advance and new ones get added to models constantly.

BOLA happens when an API checks that a request is authenticated but not that the authenticated user actually owns the specific object being requested. Change /api/invoices/1042 to /api/invoices/1043 and, if the backend only checks "is this a logged-in user" instead of "does this user own invoice 1043," you're reading someone else's data.

OWASP's 2023 API Security Top 10 puts BOLA at number one because it's structurally easy to introduce (a missing ownership check reads exactly like working code) and hard for automated scanners to catch, since they don't know what "ownership" means for your specific data model. The fix is enforcing an ownership or scope check on every object-level operation, not just at the authentication layer.

Draw a data flow diagram first: where data enters the system, how it transforms, where it exits, and where trust boundaries sit between components. Then apply the six STRIDE categories, spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege, at each trust boundary rather than to the system as a whole.

The value is in doing this during design review, not after the code is written. A threat model applied to a finished feature mostly catches things a code review would have caught anyway. Applied during design, it catches architectural decisions that are expensive to unwind later, like a service that trusts an internal network boundary a little too much.

An attacker sends a flood of spoofed TCP SYN packets. The server allocates connection state for each one and replies with a SYN-ACK, then waits for an ACK that never comes from a spoofed source. Enough half-open connections exhaust the connection table, and legitimate traffic starts getting dropped.

SYN cookies mitigate this by encoding the connection information into the sequence number of the SYN-ACK itself instead of allocating state up front. Only when the real ACK comes back does the server reconstruct the connection state from that sequence number, so a spoofed source that never completes the handshake never costs the server anything beyond one reply packet. Most cloud providers handle this automatically at the network edge, but on-prem environments still need it configured explicitly.

TLS 1.3 cuts the handshake from two round trips to one (zero for a resumed session), drops legacy cipher suites that had known weaknesses, makes forward secrecy mandatory instead of optional, and encrypts more of the handshake itself so less metadata leaks to anyone watching the wire.

Teams still running TLS 1.2 aren't automatically broken, but they're carrying downgrade-attack risk and slower handshakes for no real benefit at this point. Disable TLS 1.0 and 1.1 outright, prefer 1.3 where client support allows it, and test the actual negotiated versions quarterly with a tool like testssl.sh rather than assuming the server config matches what you think you deployed.

Start with RBAC that reflects actual least privilege rather than copy-pasted cluster-admin bindings, default-deny network policies so pods can't talk to anything they weren't explicitly allowed to, image scanning wired into the CI pipeline before anything reaches a registry, and API server audit logging turned on from day one.

Secrets management, runtime threat detection, and service mesh mTLS matter too, but they're reasonable to add as the team's familiarity with the platform grows, rather than blocking the first production deployment on all of it at once. The four items above catch most of the damage a misconfiguration can do; the rest reduces blast radius further.

The failure modes to avoid: plain-text environment variables in a pipeline config file, secrets accidentally committed to git, and long-lived credentials baked into a container image. Instead, pull credentials at runtime from a secrets manager, AWS Secrets Manager, HashiCorp Vault, or GitHub's OIDC-based secrets, and scope each pipeline job to only the permissions that specific job actually needs.

Rotate credentials automatically rather than on an annual audit cycle, and run a pre-commit scanner like truffleHog or git-secrets so a leaked key never makes it into history in the first place. A key that's already in git history is compromised the moment it's pushed, rotating it later doesn't undo that exposure window.

SSRF tricks a server into making an HTTP request on the attacker's behalf, usually by feeding a URL parameter a target the application never expected to fetch from. In a cloud environment, the interesting target is almost always the instance metadata service at 169.254.169.254, which can hand back temporary IAM credentials to anything that can reach it from inside the instance.

That's essentially the mechanism behind the 2019 Capital One breach: an SSRF vulnerability against a misconfigured web application firewall let an attacker retrieve IAM role credentials from the metadata service, then use those credentials to pull data from S3 buckets the role had access to. The fix is requiring IMDSv2 (which needs a session token, defeating simple SSRF payloads), validating and allow-listing any URL an application fetches on a user's behalf, and keeping IAM roles scoped tightly enough that a stolen credential doesn't hand over everything else too.

Initial access (phishing, credential stuffing against exposed logins), persistence (service accounts, scheduled tasks, OAuth grants that quietly survive a password reset), privilege escalation, and exfiltration deserve the most attention for most SaaS companies. Defense evasion is consistently under-monitored relative to how often it shows up in real incidents.

The surprising part for candidates who prepared assuming a network-perimeter model: for most SaaS companies, MITRE's ATT&CK framework and real incident data both point to credential compromise or a supply-chain dependency as the far more common starting point than a firewall or network breach. There usually isn't much of a network perimeter left to breach once everything's in the cloud.

BEC doesn't rely on a malicious link or attachment that a spam filter or a trained employee might catch. It's a well-researched email, often impersonating a real executive or vendor, asking for a wire transfer or a change to payment details, sent at a moment (end of quarter, right before a holiday, during a real acquisition) chosen to make urgency plausible and verification inconvenient.

The defense that actually works is procedural, not technical: a mandatory out-of-band verification (a phone call to a known number, not one in the email) for any payment or account-detail change above a threshold. Training helps people recognize obvious phishing. It does less against a targeted, well-written request from someone who's done their homework on your org chart.

On Linux, common paths include SUID binaries that run with elevated permissions and can be tricked into executing attacker-controlled code, misconfigured sudo rules that allow more than intended, writable cron jobs owned by root, and exploiting an unpatched kernel vulnerability directly.

On Windows, the equivalent playbook leans on unquoted service paths, weak service permissions that let a low-privileged user replace a binary a privileged service will execute, token impersonation once you've compromised a process running as a higher-privileged account, and DLL hijacking, planting a malicious DLL somewhere the loader will find before the legitimate one. Both platforms boil down to the same underlying idea: find something a privileged process trusts that a lower-privileged user can influence.

A man-in-the-middle attacker who can get a client to trust a fraudulent certificate, through a compromised certificate authority, a misissued cert, or a device with a malicious root CA installed, can decrypt and modify traffic that looks properly encrypted to the client. Certificate pinning has the client check the server's certificate (or its public key) against a known, hardcoded value instead of trusting anything a valid CA signed.

The real cost shows up during routine certificate rotation: pin the wrong thing, or forget to update the pin before rotating the actual certificate, and every client with the old pin gets locked out of your own service until they update. That operational risk is why pinning has fallen out of favor for a lot of general web traffic and is used more selectively, mobile apps talking to a single known backend being the common remaining case.

An insider already has legitimate credentials and, often, legitimate business reasons to access sensitive systems, so the usual signals (failed logins, unfamiliar IP addresses, malware signatures) mostly don't apply. Detection shifts toward behavioral baselines: is this person accessing data volumes or systems well outside their normal pattern, right before a resignation date, or right after being denied a promotion.

It's also the area where getting detection wrong costs the most in trust. Overly broad monitoring that treats every employee as a suspect erodes the culture a security team depends on for voluntary cooperation during an actual investigation. Most mature programs scope insider-threat monitoring narrowly, privileged accounts, departing employees, unusual data movement, rather than blanket surveillance of everyone.

A traditional VPN model draws a perimeter and trusts anything inside it, castle-and-moat security, once you're on the network, you're mostly trusted by default. Zero-trust assumes no implicit trust based on network location at all. Every request, whether it originates inside the office network or from a coffee shop, gets authenticated, authorized, and continuously validated against the specific resource being accessed.

The practical difference shows up during a breach: with a VPN model, a compromised laptop on the internal network can often reach far more than it should, because "on the network" was treated as good enough. With zero-trust, that same compromised laptop still has to pass identity-based, per-resource checks for everything, which limits lateral movement even after an initial compromise. Implementation complexity, rewriting access policies resource by resource instead of relying on network topology, is the honest trade-off nobody sells you on during the pitch.

OAuth 2.0 is an authorization framework: it lets a user grant a third-party application limited access to their data on another service, without handing over their password, think "let this app read your calendar." It was never designed to answer "who is this user," even though a lot of early implementations misused it that way.

OpenID Connect is built on top of OAuth 2.0 specifically to solve authentication. It adds a standardized ID token (a JWT) containing identity claims, so an application can reliably know who logged in, not just that they granted some scope of access. If a candidate describes using "OAuth for login," that's usually a sign they mean OIDC, and it's worth a follow-up to confirm they understand the distinction rather than assuming.

A JWT has three base64url-encoded parts separated by dots: a header describing the signing algorithm, a payload of claims (user ID, expiration, scopes), and a signature that lets the server verify the token hasn't been tampered with.

// decoded header
{ "alg": "HS256", "typ": "JWT" }

// decoded payload
{ "sub": "user_10432", "role": "member", "exp": 1770000000 }

// signature: HMACSHA256(base64url(header) + "." + base64url(payload), secret)

The classic implementation bug is trusting the algorithm named in the header itself. If a server naively reads alg from the token and uses it to pick the verification method, an attacker can set alg to "none" and strip the signature entirely, or switch from RS256 to HS256 and sign the token using the server's own public key as an HMAC secret, since public keys are, by definition, not secret. The fix is hardcoding the expected algorithm server-side and rejecting anything else, never trusting the token to tell you how to verify itself.

Passwords should be hashed with a slow, salted, purpose-built algorithm, bcrypt or argon2, not encrypted. Encryption is reversible by design if you have the key, which means anyone with database and key access (an attacker who's gotten that far, or a rogue insider) can recover every plaintext password at once. Hashing is one-way; there's no key to steal that reverses it.

import bcrypt

password = b"correct horse battery staple"
hashed = bcrypt.hashpw(password, bcrypt.gensalt())

# later, to verify a login attempt:
bcrypt.checkpw(password, hashed) # True

The salt (built into bcrypt's output automatically) matters because it stops an attacker from precomputing a single rainbow table that cracks every user's password at once, each hash needs its own attack even if two users happen to share a password. Fast general-purpose hashes like plain SHA-256 are the wrong tool here specifically because they're fast, an attacker can brute-force billions of guesses per second on commodity GPUs against a fast hash, which is the opposite of what you want for password storage.

PKI is the system of certificate authorities, certificates, and public keys that lets a client verify a server is who it claims to be without having met it before. A root certificate authority's public key is pre-installed and trusted by your browser or OS. That root signs intermediate certificates, and an intermediate signs the actual server certificate you connect to.

Verifying the chain means checking each signature back up to a trusted root: the server cert is signed by the intermediate, whose signature you verify using the intermediate's own certificate, which is itself signed by the root you already trust. Break any link (an expired cert, a revoked one, a self-signed cert nobody's root trusts) and the whole chain fails, by design, trust doesn't get to skip a broken link just because most of the chain looks fine.

Role-based access control assigns permissions to roles, then assigns users to roles, admin, editor, viewer. It's simple to reason about and audit when the number of distinct access patterns stays small. Attribute-based access control makes decisions from attributes of the user, the resource, and the context at request time, a doctor can view a patient's record only if they're assigned to that patient's care team and it's during their shift, for example.

RBAC stops scaling when the real access rules depend on relationships and context that don't reduce cleanly to a fixed set of roles, you end up creating a new role for every combination of conditions until the role list itself becomes unmanageable. ABAC handles that case naturally, at the cost of policies that are harder to audit at a glance, since the logic lives in attribute rules rather than a readable role name.

Set the Secure flag so the cookie only travels over HTTPS, HttpOnly so client-side JavaScript can't read it (closing off a common XSS-to-session-theft path), and SameSite to Strict or Lax so the browser doesn't attach the cookie to cross-site requests, which helps against CSRF at the same time.

Regenerate the session identifier on privilege changes, specifically on login, since an attacker who fixes a victim's session ID before authentication (session fixation) can hijack the now-authenticated session if the ID never changes. Set a reasonable absolute expiration in addition to an idle timeout, and invalidate sessions server-side on logout, not just by deleting the client-side cookie, since a stolen cookie remains valid until the server actually revokes it.

In practice, it means starting from zero permissions and adding exactly what a role needs to do its job, rather than starting from a broad template and trying to remove what looks unnecessary. Cloud IAM policies with wildcard actions or wildcard resources (Action: "s3:*" on Resource: "*") are the single most common finding in a real access review, because they're the fastest way to get something working during development and the slowest thing anyone goes back to tighten later.

A useful habit: review access logs for what a role actually used over the last 90 days, and scope the policy down to that observed usage plus a documented reason for anything broader. Access granted "just in case" tends to stay granted indefinitely, since removing it feels riskier than leaving it, even though the unused permission is exactly what an attacker benefits from if that account or role is ever compromised.

NIST SP 800-61 frames incident response as four phases: preparation, detection and analysis, containment/eradication/recovery, and post-incident activity. For ransomware specifically, isolate affected machines from the network without shutting them down, volatile memory may still hold encryption keys or artifacts useful for recovery, and powering off destroys that evidence permanently.

Check for lateral movement immediately, attackers typically maintain access for days to weeks before triggering encryption, so the machine you found first is rarely the only compromised host. Notify legal and executive leadership early. Whether to pay a ransom is a business and legal decision, not an engineering one, and the earlier those stakeholders are looped in, the fewer bad options get closed off by the time they're consulted.

Start with whether the behavior is normal for this specific user and system at this specific time, a database admin running a bulk export at 2 a.m. during a scheduled maintenance window looks identical in the logs to the same query run by a compromised account, until you check the context. Correlate the alert with other SIEM events and threat intelligence feeds before deciding it's noise.

Treat genuinely ambiguous alerts as true positives with an investigation scope proportional to potential impact, rather than defaulting to "probably fine." Alert fatigue is a real problem, and pretending it isn't doesn't help. SIEM tuning and detection engineering, writing correlation rules that actually reduce false positives instead of just generating more alerts, matter as much as the investigation work itself.

Event ID 4624 and 4625 (successful and failed logon) establish the basic access timeline. 4688 with command-line logging enabled shows process creation, including the actual command executed, often the single most useful entry in the whole log. 4698 and 4702 flag scheduled task creation and modification, a common persistence mechanism. 1102 (security log cleared) is close to a direct admission that someone was covering tracks. 4104 captures PowerShell script block logging, which matters enormously given how much post-exploitation tooling runs through PowerShell.

Event 4672 (special privileges assigned to a new logon) paired with an account that shouldn't have those privileges is one of the more reliable signals for privilege escalation specifically, worth flagging in any correlation rule rather than treating as routine noise.

Tightening rules to cut false positives always risks raising false negatives, the exact same rule that stops paging someone at 3 a.m. for a benign admin task might also stop catching the rare case where that same activity is genuinely malicious. There's no tuning that eliminates the trade-off, only ways to shift where the line sits based on what a team can actually sustain investigating.

Most detection engineering teams write correlation logic in Python or the SIEM's native query language, and Python's continued dominance as a general scripting language, per the 2024 Stack Overflow Developer Survey, tracks with how much custom tooling security teams end up writing rather than relying purely on vendor-shipped rule packs. A rule pack gets you a baseline. The rules that actually catch what's specific to your environment tend to be the ones your own team wrote.

CVSS scores theoretical severity, how bad a vulnerability could be if exploited, but it says nothing about how likely exploitation actually is in the wild right now. A 9.8 CVSS vulnerability that no one has ever built a working exploit for can reasonably wait behind a 6.5 that's being actively exploited across the internet this week.

EPSS (Exploit Prediction Scoring System) estimates the probability a vulnerability will actually be exploited in the near term, based on real-world exploitation data. Prioritizing patches by CVSS alone routinely gets the ordering wrong; combining CVSS severity with EPSS likelihood gets a patch queue closer to what actually reduces risk fastest, rather than what looks scariest on paper.

Document who collected each piece of evidence, exactly when, using what method, and every subsequent person who accessed or transferred it, with no gaps in that record. Use write-blockers when imaging disks so the collection process itself can't be argued to have altered the evidence, and generate cryptographic hashes of images immediately, so any later claim of tampering can be checked against the original hash.

The standard to hold yourself to is treating every incident as if it will end up in court, even though most won't, because a broken chain of custody can't be fixed retroactively once a case turns out to need it. Deciding "this probably won't go legal" at the start of an investigation is exactly the moment corners get cut that matter six months later.

The review needs to produce specific, assigned, trackable action items, not general statements like "we should communicate better." "We added a weekly sync" is a start. "We added a weekly sync and a shared decision log with the reasoning behind each call, reviewed monthly" is the version that actually survives past the next reorg, because it's specific enough to check whether it happened.

Blameless doesn't mean consequence-free, it means the review focuses on what about the system or process allowed the failure, rather than who to fire, which is what actually gets people to disclose the full sequence of events honestly instead of a sanitized version. A review where people are guarded about what they admit produces a document with gaps exactly where the real lesson was.

Initial access is usually phishing, a purchased set of stolen credentials, or an exposed RDP endpoint, not a sophisticated zero-day. From there, attackers spend time on reconnaissance and lateral movement, often days or weeks, quietly mapping the network and identifying backup systems before touching anything sensitive. Encrypting or deleting backups first, if they can reach them, is standard practice on the attacker's side, since that removes the easy recovery path.

Only after that groundwork does the actual encryption happen, frequently paired with data exfiltration beforehand so the group can threaten a public leak even if the victim restores from backup without paying (double extortion). The ransom note is the last step in a process that, for a well-resourced attacker, may have started weeks earlier.

Check asset inventory first, a surprising amount of "suspicious" DNS traffic turns out to be a legitimate scheduled job or a monitoring agent nobody documented. If it's genuinely unexplained, look at the query content itself: unusually long subdomains, domains registered in the last few days, or high query frequency to a single destination all suggest DNS tunneling being used to exfiltrate data or maintain command-and-control, since DNS is rarely blocked outbound even in locked-down environments.

If the pattern holds up, block the destination, isolate the host, and collect memory and process logs before doing anything that might reset the box. Building a timeline of when the traffic started matters more than the destination domain itself, since that tells you how long the host may have been compromised.

Deserializing untrusted data can let an attacker construct an object graph that triggers arbitrary code execution the moment it's reconstructed, before your application logic even runs. Java's ObjectInputStream and Python's pickle are the classic examples, both will happily instantiate whatever class the serialized bytes describe.

The defense that actually works is avoiding native deserialization of untrusted input entirely, using a data-only format like JSON with a schema validator instead of a format that can carry executable behavior. Allow-listing which classes are permitted to deserialize helps as a second layer, but it's easy to get an allow-list wrong in ways that still leave a gadget chain available.

Attackers compromised SolarWinds' build process directly and inserted the SUNBURST backdoor into signed, legitimate software updates for the Orion platform, distributed to roughly 18,000 customers before FireEye discovered it in December 2020 while investigating its own breach. The update was signed and came from a trusted vendor, which is exactly why every downstream customer's own vulnerability scanning and code review missed it entirely.

It reframed supply chain risk from "a vendor's data breach might expose our information" to "a vendor's build pipeline is now part of your attack surface, and code review alone doesn't get you out of trusting a signed update." Software bills of materials, build provenance attestation, and treating CI/CD pipelines themselves as a high-value target all trace back to lessons from this one incident.

Windows authentication (specifically NTLM) can authenticate a user using their password's hash directly, without ever needing the plaintext password. If an attacker dumps hashes from a compromised machine's memory or SAM database, they can authenticate as that user on other machines using the hash alone, no cracking required.

Changing the account's password invalidates that specific hash, but if the attacker already has a foothold and can dump credentials again, or has moved to a different account's hash, a single password reset doesn't close the door. Real remediation requires isolating affected hosts, rotating credentials across the whole blast radius (not just the one account first noticed), and restricting lateral movement paths with tools like Windows' Credential Guard and tighter local administrator group membership.

Collect the most volatile evidence first: CPU registers and cache, then RAM, then network state and running processes, then disk, then remote logging and archived data, which persists the longest and can wait. RAM specifically can hold encryption keys, malware that never touched disk, and command history that a suspect might otherwise have deleted, and it's gone the moment power is cut.

Getting the order wrong doesn't just lose evidence technically, it can make evidence inadmissible if a defense argues the collection process itself was unreliable or didn't follow accepted forensic standards. Document every action taken on the system, in order, with a timestamp, treating anything that might end up in a legal proceeding with the same rigor from the first minute of response.

Standardize on a common log format (or normalize at ingestion) before anything reaches the SIEM, since cloud-native logs (CloudTrail, Azure Activity Log) and on-prem syslog and Windows Event Log formats don't line up out of the box, and correlation rules written against inconsistent field names silently miss matches. Filter and enrich at the source or at a log-shipping layer rather than sending everything raw and filtering downstream, which just moves the cost, and the noise, into the SIEM itself.

Retention policy needs to match both compliance requirements and realistic investigation timelines, logs retained for 30 days are useless against an attacker who, per the ransomware pattern discussed earlier, may have had access for weeks before doing anything visible. Most mature setups keep 90 to 180 days of searchable logs, with longer-term archival storage for anything that needs to satisfy a specific regulatory retention requirement.

Kerberoasting abuses a normal, legitimate Kerberos feature. Any authenticated domain user can request a service ticket for any service that has a registered Service Principal Name, and that ticket comes back encrypted with the hash of the service account's password. The attacker doesn't need admin rights to request these tickets, just a regular domain account, which is what makes the attack so attractive: it requires no exploit and nothing that looks abnormal at the point of request.

Once the attacker has the ticket, they take it offline and brute-force or dictionary-attack the encrypted blob against the service account's password hash, completely outside the network where there's no lockout policy and no rate limiting to slow them down. Service accounts are the juicy target because they're frequently set up years ago with a long, never-rotated password and often carry high privileges, sometimes domain admin, because someone needed the service to just work and gave it broad rights rather than scoping them.

Detection is genuinely hard because a single TGS request is completely normal Kerberos traffic. What you're actually watching for is the anomaly: Event ID 4769 requests using RC4 encryption instead of AES, since RC4 is what older or misconfigured accounts still support and it's what makes offline cracking faster, plus a spike in TGS requests from one account against multiple different SPNs in a short window, since a real user has no reason to request tickets for a dozen different services back to back. Tools like BloodHound get used by both sides here, attackers to find the highest-privilege Kerberoastable accounts, defenders to find and fix them first.

The actual fix is prevention, not detection, since by the time you're detecting the ticket request the credential is already crackable offline. That means putting service accounts into Managed Service Accounts where the password is a long random value rotated automatically and never known to a human, or if that's not possible, forcing long random passwords on any account with an SPN and enforcing AES-only Kerberos encryption domain-wide so RC4 tickets can't even be requested.