The SOC Analyst
Glossary

A storage bucket gets created for a quick test, set to public so a teammate can grab a file, and never locked back down. Eighteen months later it holds a copy of production data, and a researcher finds it by guessing the bucket name. Nothing was hacked.

A pod in your AKS cluster gets compromised through a vulnerable image. The attacker reads a Kubernetes Secret mounted into the pod, finds a service account token, and calls the Kubernetes API. From there they enumerate the cluster, find a second namespace with weaker controls, and pivot.

On December 13, 2020, FireEye disclosed that an update to the SolarWinds Orion network monitoring platform had been shipping a backdoor. The malicious code, called SUNBURST, rode into roughly 18,000 of SolarWinds' 300,000 customers inside a plugin that SolarWinds itself digitally signed. It sat dormant for up to two weeks, then beaconed out to attacker infrastructure that looked like normal Orion telemetry.

Your scanner reports a critical finding: the web server is running OpenSSL 3.0.13, and the banner on a neighboring host shows Apache httpd 2.4.6, both flagged as vulnerable to CVEs that were patched upstream months ago. You open a ticket, the system owner pushes back, and they are right. The boxes are fully patched.

A signature catches what someone has already seen. A stolen credential used by an attacker who logs in during business hours, from a normal-looking endpoint, with valid Kerberos tickets, trips none of them. There is no malware to hash, no exploit to fingerprint, no known-bad domain to block.

A red team engagement is underway, though the defenders do not know it yet. The testers phish a credential and log in. Minutes later, an analyst sees it: a correlation rule fires on a login from an unusual location followed by an unusual process on the same host.

In early 2023, ESET published the dissection of BlackLotus: the first bootkit seen in the wild that defeats UEFI Secure Boot on a fully patched Windows 11 machine. It does it by carrying its own copy of a legitimate, validly signed but vulnerable Windows boot manager, then exploiting CVE-2022-21894, a flaw nicknamed "Baton Drop." Microsoft had already patched the bug in January 2022. It did not matter.

In October 2016 a DNS provider called Dyn fell over, and with it went Twitter, Reddit, Netflix, Spotify, GitHub, and PayPal for much of the United States east coast. The traffic that took it down did not come from a server farm. It came from home routers, IP cameras, and DVRs, hundreds of thousands of them, devices whose owners never knew they were part of the attack.

The phone in the breach timeline is rarely a company phone. It is a personal Android two major versions behind on patches, joined to a sales rep's home Wi-Fi, holding a cached copy of a CRM export and the same password the rep reuses on three other sites. Nobody provisioned it.

A grammar checker your sales team installed two years ago is reading every page they open. Not the marketing copy, every page: the CRM, the cloud console, the webmail, the internal wiki behind SSO. It declared one permission at install, "Read and change all your data on websites you visit," the user clicked through, and nobody looked again.

Brute Force Attack Definition: A brute force attack is a method of gaining unauthorized access to an account, system, or encrypted file by systematically trying every possible password or credential combination until the correct one is found. Rather than exploiting a software vulnerability, brute force attacks rely entirely on trial and error backed by automated tools and computing power. The name reflects the approach: overwhelming a target through sheer force of attempts rather than through skill or deception.

The email came from the CFO. Same display name, same signature block, same clipped tone he always used. It told the accounts-payable clerk that the Henderson acquisition had closed early and the final $480,000 needed to go out today, to a new escrow account, before the wire window shut at 3 PM.

A leaked access key turns into a billing alert three days later: someone spun up forty GPU instances in a region you never use. By then the attacker has already enumerated your IAM, assumed two roles, and copied a storage bucket to an account you do not own. None of it tripped an endpoint alert, because none of it touched an endpoint.

An attacker steals a developer's access key, assumes an over-permissioned IAM role, and starts enumerating S3 buckets from the control plane. A different attacker sends a crafted request to your public API, triggers a deserialization flaw in the running application, and gets remote code execution inside the process. Both end in a breach.

A public S3 bucket gets flagged by a posture scan at 9 a.m. The same afternoon, a leaked access key is used from an unfamiliar IP to enumerate IAM roles, assume a more privileged one, and spin up compute in a region the account has never used. Two different tools see those two events, and they are not the same tool.

A misconfigured S3 bucket and an attacker already inside your account are two different problems, and they need two different tools. The bucket is a posture problem: it was public before anyone touched it, and the fix is to change the configuration. The attacker is a runtime problem: a valid set of keys is making API calls right now, enumerating roles and reading data, and no configuration scan will tell you it is happening.

An attacker steals a developer's access key from a leaked CI log, assumes a role in your AWS account, and starts enumerating S3 buckets. No malware lands. No process spawns on a laptop.

An attacker lands on a web server, pivots to a database host, dumps credentials, and exfiltrates to an external IP. That single intrusion touches four machines, and each one wrote the evidence to its own local log file. If you have to SSH into every box one at a time, grep four different formats, and line up the timestamps by hand, the attacker is long gone before you have a timeline.

In December 2020 the malicious code that shipped to roughly 18,000 SolarWinds Orion customers was not slipped past code review or signed with a stolen key. It was compiled in. Attackers planted an implant on the build server that injected the SUNBURST backdoor during compilation, so the finished artifact was signed with SolarWinds' own legitimate certificate and pushed through the normal update channel.

A fresh Ubuntu server boots with SSH allowing root login, password authentication on, no firewall rules, and verbose service banners advertising versions to anyone who scans it. None of that is a vulnerability in the CVE sense. The software is patched and current.

A finance team starts paying for a file-sharing app on a corporate card. Nobody tells security. Six months later an analyst pulls the egress proxy logs during an incident and finds 40 distinct cloud services in use, half of which IT never sanctioned, one of which holds a copy of the customer database.

A security team needs to answer one question: did the credential that was phished last Tuesday touch any production system this month. The data exists. It is spread across thirty days of API audit logs, VPC flow records, authentication events, and load-balancer logs, sitting in object storage across two cloud accounts and a region nobody checks.

An attacker exploits a deserialization flaw in a payment service running in a Kubernetes pod. The application monitoring sees a latency spike and an odd error rate. The cloud logs see the pod's service account assume a role and start reading an S3 bucket it never touched before.

A public S3 bucket exposes a customer database. An API with no authentication returns records to anyone who asks. A container runs as root with a known-exploitable library, reachable from the internet.

A single Terraform module sets one S3 bucket to public. It is reused across forty deployments. Now there are forty public buckets, all created in the time it takes a pipeline to run, none of them clicked by a human who might have hesitated.

An auditor asks one question that ends most compliance programs: show me. Show me that the S3 bucket holding cardholder data was never public. Show me the access logs for the database under HIPAA scope, for the full retention window, unbroken.

A cloud security assessment asks whether your S3 bucket is set to public. A cloud compromise assessment asks whether someone already walked through it. The difference is the whole job.

A startup with no servers ships a product to a million users in a weekend. A data scientist spins up forty GPUs for an afternoon, runs a model, and tears them down before dinner. A company closes its last data center and runs entirely on infrastructure it has never seen.

The data that leaves an organization rarely leaves through the front door. It leaves in a Google Drive link set to "anyone with the link." It leaves in a customer export attached to a personal Gmail. It leaves in an S3 bucket that someone made public to debug a deploy and forgot to lock back down.

Most cloud data breaches are not break-ins. They are doors left open. An S3 bucket set to public, an access key checked into a public repository, a role policy that grants s3:GetObject to *.

The first sign of most cloud intrusions is not malware on a disk. It is an API call. A set of long-lived access keys that show up calling GetCallerIdentity from an IP in a country the account has never operated in, then enumerating S3 buckets, then creating a new IAM user with administrator policy attached.

A CSPM dashboard tells you an S3 bucket is public and an IAM role is over-permissioned. It does not tell you that, twenty minutes ago, an attacker assumed that role from a residential IP in another country, called the instance metadata API on a running EC2 host, and is now enumerating every bucket the role can reach. Posture tools see the open door.

Pull the storage logs after a cloud incident and you will usually find the bucket was encrypted the whole time. AES-256, server-side, enabled by default, exactly as the compliance report claimed. The attacker did not break the cipher.

Open one security group rule to 0.0.0.0/0 on port 22 and you have published an SSH endpoint to every scanner on the internet. It is the single most common finding in a cloud security review, and it is a firewall rule. The firewall that allowed it was not a box in a rack.

An investigator responds to a compromised cloud account and goes to do what forensics has always done: image the affected machine. There is no machine. The virtual server the attacker used was terminated an hour ago, deleted by an automated scaling policy, and its disk went with it.

A finance team opens the monthly cloud bill and finds a 4,000 dollar line item for a GPU instance nobody can name. An engineer spun it up for a weekend test, never tagged it, and forgot it. Multiply that by every team with a corporate card and an account, and you have the problem cloud governance exists to solve.

A leaked AWS access key gets committed to a public GitHub repo at 14:02. By 14:09 an automated scanner has it. By 14:20 the attacker has called sts:GetCallerIdentity, enumerated the account, spun up a dozen GPU instances for cryptomining in three regions, and created a second IAM user as a backdoor.

Most cloud incidents you will investigate do not start with an exploit. They start with a setting. An S3 bucket left readable by anyone.

An AWS account has 1,400 IAM roles. Run the numbers and most of them carry permissions nobody has used in 90 days: a role that can read every S3 bucket, a service account that can assume any other role, a developer key with full administrative access left over from a project that shipped a year ago. None of it triggers an alert, because nothing is misconfigured in the usual sense.

The alert fired at 02:14. By the time the on-call analyst opened the console, the EC2 instance that triggered it had already been recycled by the auto-scaling group, the access key behind it had touched three regions, and the CloudTrail events that explained the first move were spread across two accounts and a log group nobody had queried before. The analyst spent the next four hours doing what cloud investigation usually is: logging into consoles, exporting logs by hand, copying volumes through the API one at a time, and trying to assemble a timeline from sources that were never built to be read together.

A developer pushes a commit at 2 a.m. to fix a build. Buried in a config file is a long-term AWS access key, the kind that starts with AKIA. The repo is public for about forty minutes before someone notices and force-pushes it out of history.

The breach you investigate after a cloud migration usually traces back to the migration itself. An S3 bucket that was a locked-down file share on-prem, copied into the cloud with public read still attached. A service account that held local admin in the data center, rehosted with the same standing credentials and now reachable from the internet.

An autoscaling group quietly doubles its instance count overnight. Nothing alerts, because every individual launch is authorized and within policy. By morning the bill is up forty percent, a misconfigured deployment loop is spawning instances it never terminates, and one of those instances is reachable from the internet on a port nobody meant to open.

The intrusion you investigate in a cloud-native shop rarely starts with malware on a host. It starts with a container image that shipped a hardcoded AWS key, or a Kubernetes service account bound to a cluster-admin role, or a public S3 bucket that an infrastructure-as-code template created and nobody reviewed. The compromised workload lives for nine minutes and is gone before an agent finishes its first scan.

The instance you needed for forensics is gone. The auto-scaling group decided the compromised host was unhealthy, terminated it, and spun up a replacement. The volume that held the attacker's tooling, the memory that held their session, the local logs that held their commands, all deleted with the instance.

Cloud Security Definition: Cloud security is the set of policies, technologies, controls, and practices designed to protect cloud-based systems, data, and infrastructure from cyber threats. It covers everything stored, processed, or transmitted through cloud environments, including applications, virtual machines, containers, databases, and the networks that connect them. As organizations move mission-critical workloads to the cloud for greater flexibility and efficiency, cloud security has become one of the highest-priority disciplines in modern cybersecurity.

The breach report lands on your desk and the root cause is the same one you read last quarter: a storage bucket left public, an IAM role nobody scoped, a logging trail that was never turned on. No exploit, no malware, no zero-day. Just a control that should have existed somewhere in the design and did not.

The breach almost never starts with a zero-day. It starts with an S3 bucket someone set to public for a one-time file transfer in 2023 and never closed. A security group that allows 0.0.0.0/0 on port 22 because a contractor needed SSH and nobody revoked it.

Pull the findings from any cloud posture scanner on an environment that has run for a year and you see the same short list every time. A storage bucket readable by anyone who knows the name. An identity with a wildcard policy that can do nearly everything.

A storage bucket goes public. The posture tool fires an alert. Twelve hours later the workload tool flags a crypto-miner on a container in the same account, and the entitlement tool quietly reports that the role attached to that container can read the bucket.