The SOC Analyst
Glossary

Two teams run the same workload on the same cloud. One adopted the CIS AWS Foundations Benchmark, mapped its controls to a posture tool, and gets a daily score against every line. The other secured things by instinct: encryption where someone remembered, logging where it seemed important, IAM policies written under deadline.

Pull the post-incident reports for cloud breaches and the same two words appear over and over: misconfiguration and identity. An S3 bucket left public. An access key checked into a Git repo.

An incident responder pulls the CloudTrail history on a breached S3 bucket and finds the answer in two minutes: the bucket was created public by a developer, no one owned the account it lived in, and no rule said it could not be. Every step was allowed. Nothing was malicious.

A storage bucket gets set to public during a Friday deploy. No alert fires, no exploit runs, nothing crashes. The bucket simply sits there, world-readable, until a researcher or an attacker finds it with a scanner.

Most cloud incidents you will investigate trace back to a decision nobody made on purpose. A storage bucket left public because the team that created it owned no policy for who classifies data. An identity with administrative rights across three accounts because the operating model never said who grants cross-account access.

In late 2020, the actor tracked as APT29 did not breach its downstream victims by attacking their front doors. It went through their suppliers. By compromising a managed service provider and the cloud identities that provider used to administer customer tenants, the actor inherited legitimate, trusted access into many organizations at once.

The SIEM most analysts learned on lives in a rack. Someone sized it for a peak ingest rate, bought the licenses and the storage, and now every new log source is a negotiation with capacity. Add a cloud workload that bursts to ten times its normal volume during a deploy and the choice is brutal: pay for headroom you almost never use, or drop the events you would have wanted during an incident.

Run a cloud account inventory at the end of a quarter and compare it to the start. The list almost never shrinks. A developer spun up three EC2 instances to test a migration and walked away from them.

A compromised access key does not trip an alarm. It logs in, calls sts:AssumeRole, enumerates a few buckets, and reads data it was technically allowed to read. Every API call is valid.

The cloud breaches that reach an analyst's queue rarely start with a zero-day. They start with an S3 bucket left open, an access key checked into a public repository, an OAuth token granted to a third-party app that nobody reviewed, or an identity provider role that trusts a wildcard. The attacker did not break in.

The breach reports rarely name a CVE. They name a storage bucket that was public, a security group open to the internet, an access key checked into a Git repo, a role that could assume every other role in the account. The exploit was not a buffer overflow.

A scanner finds the open port before you do. Somewhere in a data center, an automated tool is sweeping the entire IPv4 space for a specific vulnerable version string, and when it matches your unpatched vCenter Server or your internet-facing file transfer appliance, it fires an exploit and gets a shell. No spear-phishing email, no insider, no zero-day burned.

A container spins up to handle a traffic spike, runs for ninety seconds, and disappears. In that window an attacker exploits a vulnerable library in the image, spawns a shell, reads an environment variable holding a cloud access key, and uses it to reach a storage bucket. By the time anyone looks, the container is gone.

A cryptominer running inside a Kubernetes pod does not show up in a configuration scan. Neither does a reverse shell spawned from a web server process, or a binary writing to a directory it has no business touching, or an attacker reading a container's environment variables to steal a cloud credential. These are runtime events.

The first time most teams hit this comparison, it is during a tool evaluation. A vendor pitches a CNAPP, a second pitches a CWPP, and someone on the security team is asked to decide which one the company should buy. The framing is wrong before the meeting starts.

Two of the loudest incidents of the last few years started in code, not on a network. Log4Shell was a single logging library, pulled in transitively by thousands of applications that never chose it directly, with a flaw that turned a logged string into remote code execution. The SolarWinds Orion compromise was an attacker who got into the build pipeline and shipped a backdoor inside a signed update.

A runtime sensor fires on a production container: a known-exploitable library, reachable from the internet, running as root. The alert is real. Now answer the next three questions.

A compromised laptop makes a quiet HTTPS request to a domain that looks like a content-delivery network, roughly once a minute, and gets back a few bytes in reply. Most of the time the response is empty. Occasionally it is larger, and right after, the laptop runs a new command, enumerates a file share, or sends a burst of data out.

When a Log4j advisory, a Microsoft patch note, a vulnerability scanner finding, and a threat-intel feed all need to talk about the same flaw, they use one string: CVE-2021-44228. That identifier is why a scanner in Berlin, an analyst in Austin, and a vendor bulletin in Tokyo are provably discussing the same bug and not three that sound alike. Before CVE existed, two tools could report "the Apache buffer overflow" and mean different vulnerabilities, or report it under two names and double-count the same one.

A CVE lands in your scanner with a 9.8. The ticket says critical, the dashboard turns red, and someone wants it patched by Friday. Then you check the host: it is an internal jump box with no inbound path from the internet, the vulnerable service is disabled, and there is no public exploit.

A vulnerability scan asks whether your patch is missing. A compromise assessment asks whether someone already used the missing patch to get in. The difference is the whole job.

At 00:00 a single host on a flat network is compromised. By the time the on-call analyst opens the first ticket, the same exploit has reached every unpatched machine that host could route to, and the count is still climbing on its own. Nobody clicked a second link.

A user who already typed the right password is the most common starting point of the intrusions you will investigate. The credential was phished, or sprayed, or bought, and the sign-in itself looks clean: valid username, valid password, a successful authentication event in the log. What stops the attacker at that moment is not another password.

A container that was hardened at build, scanned clean, and signed before it shipped can still become the incident. It ran for nine months on an old base image nobody rebuilt, accumulated three new critical CVEs that were published after it deployed, and when the service was retired the team deleted the deployment but left the volume, the secret, and a stale firewall rule pointing at an IP that got reassigned. Nothing about that container was insecure on day one.

A developer pulls node:18 from a public registry, layers an app on top, and ships it to production. That base image carries hundreds of OS packages the developer never chose and never audited. Months later one of those packages turns out to carry a critical CVE, and the same vulnerable image is now running in forty pods across three clusters.

A container that runs as root with a writable filesystem and a hardcoded API token in its environment is one compromised process away from owning the node it sits on. The image was pulled from a public registry, never scanned, and rebuilt nightly from a latest tag nobody pinned. None of that is exotic.

Exec into a random pod in most clusters and the same picture comes back. The process runs as UID 0. The root filesystem is writable.

A team ships a microservice as a container image, pushes it to a registry, and writes a short manifest that says run three replicas, autoscale to twenty, expose port 443. They never touch a server. A managed control plane pulls the image, schedules it onto hosts the provider owns and patches, restarts it when it crashes, and bills by the second it runs.

A developer pushes an image to a public registry. It runs a single web service, built six months ago on a base image nobody has updated since. Inside it: an AWS access key baked into a layer, a package manager full of known CVEs, and a process running as root.

An attacker phishes an access token at 09:00. The user reports it at 09:15, IT disables the account at 09:20, and the attacker keeps reading mailbox data until 14:00. Nothing in that timeline is exotic.

An attacker who lands on a host at 2:14 a.m. on a Saturday does not wait for the Monday log review. By the time someone opens a dashboard two days later, the foothold is a domain admin account, the data is staged, and the only question left is how much got out. Periodic checks lose to attackers who operate continuously.

A scanner finds 40,000 vulnerabilities. The patch team can close maybe 400 a month. So the list grows faster than anyone can work it, the highest CVSS scores get patched whether or not an attacker could ever reach them, and the one internet-facing misconfiguration that actually lets someone in sits three pages down because it scored a 6.5.

An attacker who phishes a developer's laptop gets one machine. An attacker who steals that developer's AWS access keys gets the account. From a terminal anywhere on the internet, the same API calls a legitimate engineer makes are now available to them: spin up instances, attach a new policy to their own user, snapshot a database and copy it to an account they own, turn off the trail that would have recorded any of it.

An account logs in from a managed laptop in Chicago at 9 a.m. Forty minutes later the same session is reading mail from a residential IP in another country, on a browser the user has never run, and the identity provider never issued a new sign-in. No failed logons.

An adversary lands on a workstation through a phished credential. Twenty-seven seconds later, they are on a second host. That 27 seconds is the fastest breakout time CrowdStrike has ever recorded, from its 2026 Global Threat Report, which also put the average eCrime breakout time at 29 minutes in 2025, a 65% jump in speed over the year before.

An attacker has administrator rights on one machine. They run a tool that reads the memory of lsass.exe, the Windows process that holds the credentials of everyone currently logged in, and out comes a list: NTLM password hashes, and a Kerberos ticket for a domain administrator who logged in earlier that day. The attacker never cracked a password.

A finance employee gets an email that looks like a Microsoft 365 password-expiry notice. The link goes to a login page that is a pixel-perfect copy of the real one. They type their username and password, the page shows a spinner, then redirects them to the genuine portal.

Definition: Credential stuffing is an automated cyberattack in which threat actors inject stolen username and password pairs into login forms across multiple websites and applications to gain unauthorized access to user accounts. Because many users reuse the same credentials across different platforms, a single data breach can give attackers a working key to dozens of unrelated services. Unlike brute force attacks, which attempt to guess passwords randomly, credential stuffing uses *verified* credentials pairs already confirmed valid somewhere.

A contractor reuses one password across a personal forum and the corporate VPN. The forum gets breached, the password lands in a dump that an attacker buys for a few dollars, and they try it against the company VPN. There is no second factor.

A user opens a product page on a site they have used for years, logged in, trusted. The page renders normally. What they do not see is a line of attacker-controlled JavaScript that a previous visitor planted in a review field, now running inside their browser with the full authority of that trusted site.

Every database-backed application does four things to its data and nothing else. It creates a record, reads a record, changes a record, or removes a record. A user signs up: create.

A user clicks "cancel booking" on a travel site. The browser sends one line over the wire: DELETE /api/bookings/8842. By the time that request lands, it has crossed two different worlds.

A finance team opens a ticket because their cloud bill tripled overnight. No outage, no data loss, no ransom note. Just compute usage climbing in regions they never deploy to, on instances no one remembers launching.

In its November 2021 Cloud Threat Horizons report, Google's security team noted that when an attacker compromised a cloud instance, mining software was downloaded within 22 seconds in 58 percent of cases. Not a backdoor, not a data grab. A miner, running almost before anyone could notice the box was even breached.

A public S3 bucket left readable to the internet and a cryptominer running inside a Kubernetes pod are both cloud security incidents. They are not the same kind of incident, and the tool that catches one is usually blind to the other. The open bucket is a configuration mistake in the cloud control plane, the sort of thing a posture scan flags in minutes.

Ask a SOC team how many assets they defend and you rarely get one number. The CMDB says one thing, the EDR console says another, the vulnerability scanner reports a third count, and the cloud accounts hold a fourth that nobody fully tracks. Each tool is right about the slice it sees and blind to the rest.

A ransomware crew does not spray a hospital network with a mass-mailed payload and hope a receptionist clicks. They buy access to it. They spend days inside, quietly, mapping the domain, stealing the backups offline, and identifying the file servers that run the emergency room.

The intrusions that keep defenders up at night are not the loud ones. They are the ones that were already over before anyone noticed. In the SolarWinds compromise, the operators sat inside victim networks for months before the activity surfaced, and it surfaced because a security vendor caught its own stolen tooling, not because an alert fired in the victims.

An attacker scans the internet for a specific model of VPN appliance running a version with a known flaw. They find a few thousand. One belongs to a mid-sized company that has not patched.

The 40-person company that calls in an incident response firm has the same story almost every time. No dedicated security staff. One IT person who also runs the help desk.