Senior cybersecurity interview questions

No. You can't compare raw key length across different algorithm families. Because of how each one's underlying math hardens, a 256-bit elliptic-curve key gives roughly the same security as a 3072-bit RSA key — about 128-bit strength, per NIST. Bigger isn't simply stronger: ECC reaches equivalent strength with far smaller keys, which is why modern systems prefer it. Within a single algorithm, longer keys do help, up to a point.

Not necessarily. Double-encrypting with the same algorithm doesn't simply double security — the classic result is that 2DES adds only about one bit of effective strength because of meet-in-the-middle attacks, which is why 3DES exists. More importantly, hand-rolled multi-layer schemes tend to introduce implementation bugs that weaken the whole thing. Use one well-vetted authenticated cipher (AES-GCM) with sound key management instead of stacking crypto.

Unbounded autonomy plus tool access is OWASP LLM 'excessive agency': a manipulated or mistaken model can take destructive actions. Constrain it with least-privilege tool scopes, require human confirmation for irreversible operations, and keep permissions narrow and audited. Trusting it or granting admin widens the blast radius, and hiding a UI button does nothing about the model's underlying capability to call the action.

Untrusted content the model ingests can carry instructions — indirect prompt injection. You can't fully prevent the model from being influenced, so isolate fetched content as data, constrain what tools/permissions the agent has, require confirmation for sensitive actions, and avoid giving it secrets it could be coerced into leaking. Assuming the model will simply ignore injected instructions is exactly the failure mode being exploited.

This is OWASP LLM 'improper output handling': model output influenced by user input can become command injection when fed to a shell or eval. Treat it as untrusted — map intents to a small allow-list of parameterized actions, validate strictly, and sandbox execution rather than running raw generated strings. Trusting the output, raising token limits, or only logging does nothing to stop the injection.

If retrieval pulls any indexed document regardless of who's asking, the model will faithfully surface data the user shouldn't see — this is an authorization flaw, not hallucination. Enforce the user's document-level permissions at retrieval time so only authorized chunks enter the context. A bigger system prompt is bypassable and doesn't implement access control, temperature is unrelated, and another model has the same gap.

Training on unvetted user data lets an attacker poison the model — implanting backdoors, triggers, or skewed behavior that surfaces later. Control it with data vetting and filtering, provenance tracking, anomaly detection on the dataset, and evaluation of model behavior after training. 'More data is better' ignores integrity, and the real concern is poisoning, not speed or disk space.

Reliable incident reconstruction comes from correlating independent telemetry into one timeline: auth logs, EDR process/exec data, filesystem MAC timestamps, network flows and SIEM events, so you can order actions and bound the scope. A single log or the latest event alone misses the chain and can be misleading or tampered with. Guessing from one source or asking the attacker are not investigative methods. Correlation across independent sources is what reveals the full attacker activity and survives an attacker who edited one of them.

A gap in local logs during an incident can mean cleared or tampered logs, a common anti-forensics step, so don't treat absence of logs as absence of activity. Cross-check against centralized/forwarded logs, EDR and network data that the attacker likely couldn't alter, and record the integrity gap as a finding. Assuming the server was idle trusts evidence the attacker may control, treating the gap as proof nothing happened is exactly the conclusion they want, and deleting more logs destroys what's left. Corroborate with independent telemetry instead.

Frameworks set a minimum bar and can be fully met while real risk remains, so a passed checklist doesn't mean secure: raise the gap, assess its risk, and drive treatment regardless of the compliance status. Concluding it's secure because compliance passed is a dangerous conflation of two different things. Removing the gap from the report is misrepresentation and potentially fraud. Waiting for the next audit cycle knowingly leaves a real exposure open. The mature stance treats compliance as evidence of a floor, not a ceiling, and acts on risk you can actually see.

PCI DSS scope covers systems that store, process, or transmit cardholder data plus anything connected to or able to affect them, so effective network segmentation isolates the cardholder data environment (CDE) and removes unrelated systems from scope, shrinking cost, effort, and risk. Encrypting every server doesn't define a boundary and connected systems stay in scope; adding untargeted firewalls everywhere isn't segmentation if it doesn't restrict and validate the data flows; and stopping people reading card numbers aloud is hygiene, not a scoping control. The systemic answer is to control where cardholder data lives and what can reach it.

A SOC 2 report only assures you if you actually read it: confirm it's the right type (Type II tests operating effectiveness over time, Type I only design at a point), check the scope and which Trust Services Criteria it covers, that the period is current and has no gap, what opinion the auditor gave (unqualified vs qualified), and review the noted exceptions plus the complementary user-entity controls (CUECs) you're responsible for. Merely confirming the report exists — or judging it by its cover logo or page count — tells you nothing about the vendor's actual control effectiveness or your residual obligations.

An open redirect on an auth flow lets an attacker craft a trusted-looking login link that, after authentication, sends the user — and potentially an auth code or token — to an attacker-controlled domain, enabling account takeover and convincing phishing. Fix it by strictly allow-listing exact redirect URIs server-side and rejecting anything else. It is not cosmetic and not a performance issue, and HTTPS doesn't help because the attacker's destination can be a valid HTTPS site too.

Fileless malware lives in process memory (injection, reflective loading, LOLBins), so acquire and analyze a memory image to find the injected code, suspicious modules, and process relationships. A disk AV scan and a clean disk tell you nothing about an in-memory implant. The recycle bin is irrelevant. Memory forensics is the right tool when there's no file to triage, and you should capture before the host is rebooted.

Use simulated network services or a tightly monitored, attributable-safe egress so you can study C2 behavior without revealing your real IP to the attacker or letting the host be tasked with harmful commands. Interacting from the corporate IP tips off the operator and risks real harm. Bridging the sandbox to the LAN invites spread. Disabling logging throws away the analysis data. Control the network so you observe without exposing or being weaponized.

Packing hides the real code, so high entropy plus stripped imports is a sign to unpack — detect the packer and dump the unpacked image from memory once the loader has executed, then analyze the real payload. Unreadable strings are evidence of evasion, not of being benign. Calling it a false positive or renaming the extension ignores an actively obfuscated sample. The obfuscation itself is a strong malicious indicator worth investigating.

Malware commonly checks for VM/sandbox artifacts, short run times, or user interaction and stays dormant when it sees them. Disguise and harden the analysis VM, lengthen execution, or move to bare metal, and pull behavior from a memory image of the live host. Assuming it's broken or that the host was wrong ignores a sample proven malicious in the wild. A reboot changes nothing because the evasion logic still fires every run.

Server-side fetching of attacker-controlled URLs is server-side request forgery (SSRF): it lets an attacker reach internal-only services or the cloud metadata endpoint to steal credentials. Mitigate by allow-listing permitted hosts and schemes, blocking private and link-local ranges (re-checking after every redirect), and hardening metadata access with IMDSv2. Saying there's no risk ignores the access the fetch grants, and a loading spinner or response caching does nothing about where the server is allowed to connect.

`alg: none` lets anyone craft a valid-looking unsigned token and impersonate any user — a full authentication bypass, not a minor finding. Fix it by allow-listing the expected algorithms server-side and always verifying the signature with the right key; never trust the token's own alg header to pick the verification method. Longer expiry or moving where the token is stored does nothing about forged, unsigned tokens. This is critical and exploitable, so document is not a fix.

Prompt injection can't be fully solved with more prompt text; assume the model can be subverted and constrain what it's allowed to DO. Give tools least privilege, gate high-impact actions behind human confirmation, and validate or sandbox tool calls before acting (OWASP LLM 'excessive agency' and 'improper output handling'). System-prompt pleading is bypassable. Higher temperature only adds randomness, and logging alone records the damage without preventing the injected action.

Balance usability and risk: enforce conditional access tied to device posture and isolate corporate data in a managed container (MAM/MDM) so it can be controlled and selectively wiped without taking over a personal device. Unrestricted access risks leakage on unmanaged, possibly compromised endpoints. An outright ban pushes people to insecure workarounds like forwarding data to personal email. And emailing attachments scatters sensitive data uncontrollably across devices you can never reclaim.

No single product stops every attack, so mature security layers independent controls — defense-in-depth — so the failure of one does not mean compromise. Map the proposed spend to the actual gaps across identity, network, endpoint, data and detection, and keep the complementary controls already working. Betting everything on one tool creates a single point of failure, and ripping out existing controls to replace them reduces coverage. Declining to spend at all ignores real gaps.

Encryption at rest defends exactly one threat — physical or disk theft — and does nothing against a compromised application, stolen credentials, or sniffed traffic, because the database decrypts transparently for any authorized query. A sound design also requires TLS in transit, strong authentication and authorization, and proper key management with separation of duties. Doubling the at-rest encryption adds cost without changing the threat model, and encrypting only the backups leaves the live data and its access paths exposed.

If the key lives with the ciphertext, anyone who steals the database gets both, so the encryption protects nothing — it is a lock with the key taped to it. Keys must be managed in a dedicated KMS or HSM, separated from the data, with strict access control, rotation, and separation of duties. Hashing the key makes it one-way and useless for decryption, and storing extra copies in the same place just multiplies the exposure rather than reducing it.

Sending PII to a third party extends your trust boundary, so first run a vendor security assessment — data handling, encryption, access controls, certifications like SOC 2 / ISO 27001, sub-processors, breach-notification terms — and put a data-processing agreement (DPA) in place before any PII flows. A pricing contract or a sales rep's verbal word is not due diligence. And a 'polished website' tells you nothing about how the vendor actually protects data; you remain accountable for it.

Network-location trust means a single foothold inside grants broad lateral access — one phished VPN credential and the attacker is 'inside.' Zero trust removes implicit trust: every access is authenticated, authorized, and continuously evaluated on identity and device posture, with least privilege and segmentation (NIST SP 800-207). A second VPN or a wider VPN just extends the same flat-trust problem to more places, and trusting the LAN instead of the VPN repeats the original mistake.

'Secure' is not binary; a CISO communicates in business-risk language: the most material risks, how current controls reduce them relative to the board's risk appetite, planned investments, and the residual risk being accepted. An absolute 'yes' is false assurance that collapses the moment an incident happens. 'No, we'll never be secure' is technically true but unhelpful and signals no command of the problem. A shopping list of firewalls and tools conveys spending, not risk or outcomes the board can actually govern.

Breach handling is governed by law and contract: work with legal to meet mandatory notification timelines (such as GDPR's 72 hours to the supervisory authority) and inform affected parties accurately. Concealment risks far larger fines, regulatory action, and reputational damage when it surfaces later. Dumping raw, unverified technical details prematurely can mislead customers and aid attackers. Scapegoating an individual employee is neither accurate, lawful, nor effective crisis management — it deflects from the organization's accountability.

Board-level metrics should connect to risk and outcomes: detection and response times (MTTD/MTTR), patching-SLA adherence on critical systems, control coverage, and how residual risk trends against appetite. The number of attacks blocked by the firewall, antivirus signature counts, and total emails received are vanity numbers — they sound impressive but tell leadership nothing about whether risk is going down. The board governs risk, so metrics must let them see the trend and decide.

Security spend should follow risk, not hype: use a risk assessment to direct money where business impact and likelihood are highest and current control coverage is weakest, then measure the reduction you achieve. Buying whatever the popular vendor sells ignores your actual threat profile and often funds shelfware. Spreading the budget evenly underfunds the few areas that matter most. Copying competitors assumes their risk profile equals yours, which it rarely does.

When you can't remediate, you manage the risk: reduce exposure with compensating controls (network segmentation, tightened access, enhanced monitoring), quantify the residual risk, and have the accountable business owner formally accept it with a defined review date. Unilateral shutdown oversteps the CISO's authority and harms the business. Ignoring it because it can't be fixed is negligence. Omitting it from the risk register hides accountability, breaks audit trails, and means no one is on record owning the decision.

A vendor breach is your incident too: invoke incident response to scope which of your data and integrations were exposed, rotate any shared secrets, API keys and SSO trust, evaluate your own regulatory notification duties, and hold the vendor to disclosure. Passively waiting for the vendor cedes control of your own timeline and obligations. A public contract termination is premature theatrics before you even know your exposure. Assuming you're unaffected skips exactly the assessment that regulators and your own customers expect.

An over-privileged instance role turns any application-level flaw — notably an SSRF that reaches the instance metadata service — into full-account takeover, because the attacker inherits the role's credentials. Replace the wildcard with the minimal actions and resource ARNs the workload actually uses, and require IMDSv2 to harden the metadata endpoint. A VPC doesn't constrain IAM at all. A single deny rule is whack-a-mole that leaves everything else permitted. A load balancer is irrelevant to the credential's blast radius.

Containment beats premature recovery: stop the spread by isolating affected segments and killing the propagation path — disable the abused service account, block SMB between segments, pull the staging host — while preserving evidence, then eradicate and recover. Restoring into a network that's still encrypting just re-loses the restored data. Paying the ransom doesn't stop active encryption and carries legal and sanctions risk. Cutting power to every machine destroys volatile evidence and can corrupt files mid-write, making clean recovery harder.

Eradicating before you understand scope lets the attacker persist on systems you haven't found and simply return. Quickly hunt the IOCs and stolen credentials across the estate, identify every affected host and persistence mechanism, then eradicate everywhere at once. Wiping one host is whack-a-mole that tips off the attacker while leaving their other footholds intact. A week-long full internet blackout is disproportionate and harms the business. Deleting just the malware file ignores persistence, lateral movement, and the credentials already stolen.

The point is impact: a reused or over-privileged service credential that unlocks domain admin or critical systems is the finding that matters, so test for reuse and map the privilege and lateral-movement path. Cracking every other hash first is busywork that delays the real story. Changing the service-account password is destructive, breaks production, and tips off defenders. Emailing a live credential in plaintext is itself an exposure and bad operational security.

Discovering an active intrusion is an out-of-band emergency: the rules of engagement should define an escalation path, so invoke it immediately, preserve evidence, and avoid contaminating an active incident. Continuing to test can interfere with the real attacker or destroy the very evidence responders need. Trying to evict the attacker yourself is out of scope, risky, and may tip them off. Waiting until the final report could mean days of ongoing breach and data loss.

An internet-facing, unauthenticated RCE is emergency-grade: shrink the exposure window with a tested, staged or rolling deploy, and add compensating controls (restrict access, WAF rules) in the meantime. Waiting for the quarterly window leaves a wormable hole open for weeks. Blind production patching during business hours with no testing risks an outage and a botched rollback. Trusting the perimeter firewall does nothing — the service is already exposed and the exploit needs no credentials.

Flat networks let one compromised guest device reach crown-jewel systems directly. Segment by trust level and enforce least-privilege traffic between zones so lateral movement is contained and monitored. An edge firewall does nothing for east-west traffic between hosts already inside. Re-IPing the finance servers is security-by-obscurity that any scan defeats. Endpoint AV is one detective layer, not a substitute for the architectural control of isolating sensitive systems.

The LLM supply chain spans base models, fine-tuned variants, datasets, embeddings, plugins, libraries, and the hosting platform — each a place to introduce risk. Threats include downloading tampered or backdoored model weights, malicious fine-tunes, poisoned or license-tainted datasets, vulnerable or over-permissioned plugins, and typosquatted model repos. Defenses: source models from trusted registries, verify integrity and provenance, maintain an AI bill of materials, scan and pin dependencies, vet plugins, and apply least privilege to anything the model integrates with.

The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary, risk-based framework for governing trustworthy AI across its lifecycle. Its core is four functions: Govern (culture, policy, accountability — and it runs through the others), Map (context and risk identification), Measure (assess and track risks), and Manage (prioritize and respond). It also defines trustworthiness characteristics — valid and reliable, safe, secure and resilient, accountable and transparent, explainable, privacy-enhanced, and fair. It complements technical lists like the OWASP LLM Top 10 at the program level.

RAG security means treating every retrieved document as untrusted input. Key risks: indirect prompt injection hidden in retrieved content, poisoning of the knowledge base or embeddings, and missing per-user authorization so the model returns data the user can't access. Defenses include access control enforced at retrieval, content provenance and ingestion vetting, treating retrieved text as data not instructions, output validation, and isolating the vector store per tenant.

An LLM agent turns text into actions via tools and function calls, so a prompt injection becomes a real-world action — the excessive-agency risk. Secure it by giving each tool the least privilege and scope it needs, validating and constraining tool arguments, requiring human confirmation for sensitive or irreversible actions, sandboxing execution, rate-limiting and budgeting calls, and logging every tool invocation. Never let the model's untrusted-data-influenced output directly authorize a high-impact action.

Training-data poisoning is when an attacker tampers with the data used to pre-train, fine-tune, or embed a model so the resulting model behaves maliciously — embedding a backdoor trigger, injecting bias, or degrading accuracy. It exploits the fact that models scrape and trust large, often web-sourced datasets. Defenses include curating and signing data sources, provenance and integrity checks, anomaly detection on training data, dataset versioning, and limiting who can contribute to training and RAG corpora.

DNS exfiltration encodes stolen data into DNS queries (e.g. long subdomain labels sent to an attacker-controlled authoritative server), abusing the fact that DNS is almost always allowed outbound and often unmonitored. Detect it with anomalies: unusually high query volume to one domain, long/high-entropy subdomains, many unique subdomains per parent domain, TXT/NULL record abuse, and queries to newly registered or rare domains.

Process injection runs attacker code inside the memory space of a legitimate process so the activity blends in and inherits that process's trust. Classic techniques include DLL injection (CreateRemoteThread + LoadLibrary), process hollowing (start a benign process suspended, unmap it, write malicious code), and APC injection. Defenders detect it via EDR API hooks, anomalous parent/child or memory regions (RWX, unbacked executable memory), and Sysmon CreateRemoteThread events.

DAC lets the data owner grant access at their discretion; MAC enforces access centrally via labels/clearances and is non-discretionary; RBAC grants access through job roles; ABAC evaluates attributes (user, resource, environment) against policy for fine-grained, context-aware decisions.

Business continuity (BCP) is the broad strategy to keep critical business functions operating during and after a disruption; disaster recovery (DRP) is the IT-focused subset that restores systems and data. RTO is the maximum tolerable time to restore a function; RPO is the maximum tolerable data loss measured in time.

Defense in depth layers multiple, diverse, and independent controls across people, process, and technology so that the failure of any one control does not result in compromise. It assumes every control will eventually fail and uses redundancy and variety to slow, detect, and contain an attacker.

Due diligence is the ongoing investigation and understanding of risks (knowing what should be done), while due care is taking the reasonable actions a prudent person would take to address them (actually doing it). Diligence is research and oversight; care is implementation and maintenance.

Identity lifecycle management governs an account from creation to retirement: provisioning at onboarding (joiner), adjusting entitlements on role change (mover), and timely deprovisioning at exit (leaver), with periodic access reviews throughout. The most common failures are privilege creep on movers and orphaned accounts from missed deprovisioning.

Embed security at every SDLC phase rather than testing at the end: requirements include security and privacy requirements, design includes threat modeling, development follows secure coding standards with SAST, testing adds DAST and reviews, and release requires sign-off — all governed by policy, separation of duties, and change control. Fixing flaws early is dramatically cheaper than after release.

IMDS is a link-local endpoint (169.254.169.254) that gives an instance its metadata, including temporary credentials for its attached IAM role. SSRF can trick the server into fetching that URL and leaking those credentials. IMDSv2 requires a PUT to obtain a short-lived session token, sets a default IP TTL/hop limit of 1, and rejects requests with certain headers — so a simple SSRF GET can no longer reach it.

RBAC controls what identities can do against the Kubernetes API — Roles and ClusterRoles grant verbs on resources, bound to subjects via RoleBindings — and should follow least privilege, avoiding cluster-admin and wildcards. Network policies control pod-to-pod traffic, which is allow-all by default until you apply a default-deny and then explicitly permit required flows. Together they limit blast radius if a pod or token is compromised.

CI/CD is high-value because it holds deploy credentials and runs untrusted code. Risks include compromised dependencies and build actions, leaked or over-broad secrets, mutable third-party actions, and over-privileged runners or OIDC trust. Reduce them with pinned and verified dependencies, short-lived OIDC federation instead of long-lived keys, least-privilege scoped to specific repos/branches, isolated ephemeral runners, and signed, provenance-tracked artifacts (SLSA).

Kerberos relies on a trusted Key Distribution Center (KDC). The client authenticates once to the Authentication Server and gets a Ticket-Granting Ticket (TGT) encrypted with the KDC's key. To reach a service, it presents the TGT to the Ticket-Granting Service and receives a service ticket encrypted with that service's key. The service decrypts and trusts it. Passwords never traverse the network, and tickets are time-limited.

The client builds a chain from the server (leaf) certificate up through one or more intermediate CAs to a root CA in its trust store. It verifies each certificate's signature using the next issuer's public key, checks validity dates, name/hostname match, key usage, and revocation (CRL/OCSP). Trust terminates at a self-signed root that is pre-trusted; the chain is valid only if every link checks out.

Signing cryptographically binds an artifact to its producer so consumers can verify it wasn't tampered with or swapped. Provenance is signed metadata describing how, where, and from what source the artifact was built. Together — via tooling like Sigstore for keyless signing and the SLSA framework for provenance levels — they let a deployer verify an image came from the expected pipeline and source, defeating tampering and dependency-substitution attacks.

Lockfiles pin exact dependency versions and hashes so every build resolves the same, verified bytes — making builds reproducible and blocking silent malicious updates. Pinning by digest, verifying integrity hashes, and scoping internal packages to a private registry also defend against dependency confusion, where an attacker publishes a higher-version public package matching an internal name to hijack resolution. The principle: never let the build silently pull unverified code.

Treat the pipeline as production infrastructure: it holds the credentials to ship code and reach prod, so compromising it bypasses every downstream control. Harden it with isolated, ephemeral runners; least-privilege, short-lived tokens (OIDC federation instead of long-lived secrets); protected branches and reviewed pipeline config; pinned third-party actions by digest; and full audit logging. The pipeline is a top-tier target, not plumbing.

Break the build only on high-confidence, high-severity, newly introduced findings; warn (don't block) on everything else so developers keep trust in the gate. Manage false positives with tuned rules, baselining of pre-existing issues, and documented, time-boxed, reviewed suppressions rather than disabling scanners. A gate that cries wolf gets ignored or bypassed, so signal quality is the whole game.

It confirms XSS. If alert() fired at all, the browser parsed and executed your injected JavaScript in the page context — that is the vulnerability. A blank/empty popup just means the string argument you passed didn't render as expected (quote handling, encoding, or context mangling broke the message), not that the payload is being blocked. The execution sink is live; you refine the payload from here.

No. CORS is not a defense against CSRF — it actually loosens the same-origin policy so a page can read cross-origin responses it otherwise couldn't. CSRF doesn't need to read the response; it just needs the victim's browser to send an authenticated state-changing request. The real defenses are anti-CSRF tokens, the SameSite cookie attribute, and checking Origin/Referer.

Governance is how leadership sets direction, defines accountability, and aligns security with business objectives — the policies, roles, and oversight that say what 'good' looks like. Risk management is the process of identifying, assessing, treating, and monitoring threats to those objectives. Compliance is demonstrating adherence to obligations — laws, regulations, contracts, and internal policy. Governance drives risk decisions; risk informs which controls you need; compliance evidences that those controls meet required standards. Compliance is an outcome of good GRC, not a substitute for security.

ISO/IEC 27001 specifies the requirements for an Information Security Management System (ISMS): a risk-based, top-down framework of policies, processes, roles, and continual improvement (Plan-Do-Check-Act) governing how an organisation manages information security. Annex A is a reference catalogue of controls. You don't apply them all blindly — you run a risk assessment, decide which controls are needed, and document the include/exclude decisions with justification in a Statement of Applicability (SoA).

A KPI (Key Performance Indicator) measures how well a security activity is performing against its objective — for example mean time to detect, patch SLA compliance, or percentage of systems with MFA. A KRI (Key Risk Indicator) is a forward-looking signal that risk exposure is increasing toward an unacceptable level, with a threshold that should trigger action — for example the number of overdue critical patches, count of unmanaged devices, or failed access reviews trending up. KPIs tell you how you're doing; KRIs warn you about where you're heading.

Treat vendor risk as a lifecycle, not a one-off questionnaire. Inventory your third parties and tier them by criticality and data sensitivity. Run due diligence proportional to tier — review SOC 2 / ISO 27001 reports, security questionnaires, pen-test summaries, and the data and access involved. Bake controls into the contract (security requirements, right to audit, breach notification, data handling, subprocessors). Then monitor continuously, not just at onboarding, and have a clean offboarding process to revoke access and recover or destroy data. Fourth-party (subprocessor) risk matters too.

C2 beaconing is the periodic check-in an implant makes to its controller. Hunt for it in network/proxy/DNS telemetry by looking for regularity: connections to a destination at near-fixed intervals (even with jitter), small uniform request sizes, low data-in/data-out ratios, long-lived rare destinations, and suspicious TLS/JA3 fingerprints or odd user-agents. The signal is the rhythm and the rarity of the destination, not the payload — which is usually encrypted.

Detection engineering treats detections as a software product with a lifecycle: identify a threat or technique to cover, research the telemetry and behaviour, develop the rule, test it against true-positive and benign data, deploy it (often staged), validate with adversary emulation, then continuously tune for false positives and retire rules that no longer earn their keep. Each stage is documented and version-controlled, and coverage is tracked against a framework like ATT&CK.

LOLBins (living-off-the-land binaries) are legitimate, signed, pre-installed system tools — like certutil, bitsadmin, mshta, rundll32, regsvr32, wmic, powershell — that attackers abuse to download, execute, or persist while blending in with normal admin activity. Because the binary itself is trusted, you cannot detect on the file; you detect on context: anomalous command-line arguments, unusual parent processes, unexpected network connections from these tools, and execution from odd paths or by odd users.

TTP-based hunting uses MITRE ATT&CK as the map: pick a technique relevant to your threat model (ideally one with weak coverage), form a concrete hypothesis about how it would appear in your telemetry, identify the data sources that reveal it, query for it, and analyze hits. A good hunt is scoped, hypothesis-driven, tied to a real adversary behaviour, repeatable, and produces a durable output — a new detection, a documented coverage gap, or evidence the technique is absent — regardless of whether it finds a compromise.

Just-in-time access grants elevated privileges only when needed, for a limited time, usually with approval — then they expire automatically, so there's no standing privilege to steal. Break-glass accounts are the deliberate exception: highly privileged emergency accounts, normally dormant, locked behind strict controls and heavy alerting, used only when normal access paths fail. JIT shrinks the everyday attack surface; break-glass guarantees you can still get in during a crisis.

Keep access tokens short-lived (minutes) so a stolen one expires fast, and use longer-lived refresh tokens to get new access tokens without re-prompting the user. Rotate refresh tokens on every use and detect reuse of a consumed token as a theft signal, revoking the chain. The goal is to balance limiting the window of a compromised token against not forcing users to re-authenticate constantly.

Zero Trust drops the assumption that being inside the network makes you trusted. Every request to a resource is authenticated and authorized on its own merits — verifying identity, device health, and context — by a policy decision point, granting least-privilege access per session. There is no trusted internal zone; the network location of a request is just one signal, not a free pass.

A disassembler like Ghidra or IDA gives you the full static map: cross-references, decompiled pseudocode, and every code path whether or not it runs. A debugger like x64dbg lets you execute the sample under control — set breakpoints, inspect registers and memory, watch decryption happen, and follow the path the code actually takes with real inputs. You read structure and intent statically, then attach the debugger to resolve what static analysis cannot: runtime-decrypted strings, dynamically resolved APIs, packed payloads, and which branch a condition takes. The two together close each other's gaps.

Process injection runs malicious code inside another process to hide and to inherit trust. Classic remote injection allocates memory in a target with VirtualAllocEx, writes a payload via WriteProcessMemory, and runs it with CreateRemoteThread. Variants include DLL injection via LoadLibrary, process hollowing that unmaps a suspended legitimate process and replaces its image, APC injection that queues code to a thread, and reflective or manual-mapped loading that avoids LoadLibrary entirely. You spot them by the telltale API sequences, RWX memory in a normally-clean process, threads with no backing file on disk, and parent-child anomalies.

Sandbox-aware malware checks whether it is being watched before it misbehaves. It looks for VM and hypervisor artifacts (drivers, MAC prefixes, registry keys, CPUID), analysis tools and debuggers (process names, IsDebuggerPresent, timing of single-stepping), and signs of a real user (few processes, no recent documents, no mouse movement, low uptime, small disk). It may stall with long sleeps or only fire on a specific date, language, or domain. Analysts counter by hardening the VM to look real, patching out the checks, fast-forwarding sleeps, simulating user activity, and confirming behavior with static disassembly.

Unpacking recovers the original code the packer hid. For known packers you use the matching unpacker or an emulator. For custom packers you unpack manually: run the sample in a debugger, let the stub decompress the payload into memory, find the moment it jumps to the original entry point (often by breaking on memory that becomes executable, or on the tail jump), then dump the process image from memory and rebuild the import address table with a tool like Scylla or PE-sieve. The result is a runnable or analyzable PE containing the real payload.

A pentest aims for broad coverage — find as many vulnerabilities as possible in a scoped target. A red team is objective-driven adversary emulation: pick a goal (e.g., reach the crown-jewel data), emulate a specific threat actor's TTPs, stay stealthy to test detection and response, and avoid noisy scanning. Red teaming measures the blue team and the whole org, not just the asset; both need tight rules of engagement and authorization.

A risk assessment identifies assets and their value, the threats and vulnerabilities that could affect them, then estimates risk as a function of likelihood and impact. You can do it qualitatively (high/medium/low, fast and subjective) or quantitatively (SLE × ARO = ALE, data-driven but harder). Frameworks like NIST RMF and ISO 27005 give it structure, and the output feeds risk treatment: mitigate, transfer, avoid, or accept.

Start by understanding the app's threat model and where it handles untrusted input, secrets, authentication, and authorization. Use SAST to scan broadly and DAST against the running app, but treat tool output as leads, not findings — triage out false positives. Then spend human time on the high-value, context-dependent areas tools miss: authz logic, business logic, crypto usage, and trust boundaries. Trace data flow from source to sink.

Threat modeling answers four questions: what are we building, what can go wrong, what do we do about it, and did we do a good job. You diagram the system (often a data flow diagram with trust boundaries), enumerate threats with a framework like STRIDE, prioritize by risk, and assign mitigations. PASTA adds a risk- and attacker-centric flavor; attack trees decompose a single goal. Doing it at design time is far cheaper than patching production.

Use the compromised host as a relay into the unreachable subnet. Set up port forwarding for a single service, or a dynamic SOCKS proxy (SSH -D or chisel) and route your tools through it with proxychains, so your attacker box can reach internal hosts via the pivot.

Enumerate current privileges (whoami /priv), misconfigured services (weak permissions, unquoted service paths), AlwaysInstallElevated, scheduled tasks, stored credentials, and missing patches. WinPEAS or PowerUp automates the sweep; token-privilege abuses like SeImpersonate are common high-value wins.

Any authenticated domain user can request a Kerberos service ticket (TGS) for any account with an SPN. That ticket is encrypted with the service account's NTLM password hash, so you extract it and crack the password offline — no privileged access needed to start, and it's near-silent.

Pivoting turns a compromised host into a relay so you can reach internal segments your machine can't route to. You use port forwarding, a SOCKS proxy over your C2 channel (e.g. Chisel, SSH dynamic forwarding), or agent-based routing, then run tools through that tunnel to attack the next subnet.

A good report serves two audiences: an executive summary that frames business risk for leadership, and detailed, reproducible findings with evidence, accurate risk ratings, and prioritized remediation for the technical team. The report — not the exploit — is the deliverable.

Reduce attack surface (remove unused packages/services), enforce key-only SSH with no root login, keep the system patched, run a default-deny firewall exposing only needed ports, apply least privilege via sudo and file permissions, enable auditd and centralized logging, and add integrity monitoring plus MAC like SELinux or AppArmor.

A secure SDLC bakes security into every phase rather than bolting it on at the end. Requirements include security and abuse cases, design adds threat modeling, development uses secure coding and SAST plus dependency scanning, testing adds DAST and pen testing, and operations adds monitoring, patching, and incident response — shifting security left.

Segmentation divides a network into isolated zones so a breach in one can't freely reach others, limiting lateral movement. Zero trust goes further: it removes implicit trust based on network location entirely, authenticating and authorizing every request regardless of where it originates — microsegmentation is one way to implement it.

Almost everything touches DNS, so DNS logs reveal threats other sources miss: command-and-control beaconing (regular callbacks to a domain), DNS tunneling and exfiltration (high volume of long, encoded subdomains), and algorithmically generated (DGA) domains. You detect these through patterns like query regularity, entropy, record types, and volume rather than single bad lookups.

Lateral movement is an attacker using a foothold to reach other systems. Signs include unexpected network logons (type 3) and RDP (type 10), access to admin shares like C$ and ADMIN$, remote-execution tools such as PsExec, WMI, and WinRM, pass-the-hash patterns, and a normally local account suddenly authenticating to many hosts.

Content-Security-Policy is an HTTP response header that tells the browser which sources of scripts, styles, images, and other content are allowed to load and execute on a page. By disallowing inline script and untrusted origins — ideally via nonces or hashes — it acts as a defense-in-depth backstop that neutralizes injected XSS payloads even when one slips through.

SSRF tricks a server into making HTTP (or other) requests to a destination the attacker chooses, abusing the server's network position to reach internal services behind the firewall. In the cloud it is especially severe because the instance metadata service (e.g. 169.254.169.254) can hand back IAM credentials, turning an SSRF into cloud account compromise.

XXE abuses an XML parser that resolves external entities defined in a document's DTD. An attacker declares an entity pointing at a local file or internal URL, and the parser fetches it — enabling file disclosure, SSRF, and denial of service. The fix is to disable DTD processing and external entity resolution in the parser configuration.