The SOC Analyst
Glossary

A ransomware operator lands on a workstation at 2:14 a.m. on a Saturday. The endpoint agent fires an alert. With an MSSP, that alert is validated, wrapped in a ticket, and emailed to your on-call inbox.

A mid-size company gets hit with ransomware at 2 a.m. on a Saturday. Whether anyone is watching the alerts at that hour, and whether someone is authorized to pull the infected host off the network, comes down to one earlier decision: did the company build a security operations center, or did it buy managed detection and response? MDR and SOC both answer the same question, who watches the environment and acts when something is wrong, but they answer it with different ownership models, cost structures, and staffing.

A ransomware operator lands on a finance workstation at 02:14. The SOC's sensor fires the same minute, but the alert sits in a queue until an analyst opens it at 02:51. Triage and escalation eat another 40 minutes.

A monolithic application is one deployable. One codebase compiles into one process, and a checkout function calling an inventory function is an in-memory call that never touches the network. A microservices application is the opposite: checkout and inventory are separate services, deployed on their own, talking to each other over HTTP.

A monolith has one front door. A microservices application has hundreds. Every service that was once a function call inside a single process is now a network call across a service mesh, authenticated or not, encrypted or not, logged or not.

In 2020, Microsoft's red team ran an attack against an internal machine-learning model that auto-provisioned cloud resources. They never touched the code. They queried the model's API enough to rebuild a working copy, found inputs the copy mishandled, and used those to make the production model approve resources it should have denied.

An alert fires: a process just read the memory of lsass.exe. On its own, that is a line in a log. Look it up in MITRE ATT&CK and it has a name, an ID, and a paper trail: T1003.001, OS Credential Dumping: LSASS Memory, sitting under the Credential Access tactic.

A banking app stores the user's session token in a plaintext file inside the app's sandbox. Nothing on the server is wrong. The API is fine.

A bank fraud team sees a cluster of account takeovers that make no sense. The logins come from the customers' own phones, the right devices, the right locations, and they sail through the SMS one-time-password check. No stolen passwords show up on any breach dump.

A managed iPhone passes every check your mobile device management console runs. It is enrolled, encrypted, patched, and compliant. The same phone is also connected to a rogue Wi-Fi access point in an airport lounge that is decrypting its TLS traffic, and it is running a banking app sideloaded from a fake store that reads the screen on every tap.

In April 2025, Trail of Bits showed that a malicious MCP server could attack a user before that user ever called a single tool. The server only had to answer the question every client asks on connect, "what tools do you offer," and hide instructions inside the tool descriptions it returned. The model read those descriptions straight into its context and obeyed them.

A ransomware note lands on every screen in the building at 3 a.m. You call your provider. Whether the person who answers can do anything about it depends on one letter.

A retailer runs its storefront on AWS because that is where it started, trains its recommendation models on Google Cloud because the tooling is better, and keeps a copy of its checkout service on Azure because its largest enterprise customer demands a contract on Microsoft. None of this was a master plan. Three teams made three reasonable calls over four years, and the company now runs on three public clouds at once.

A single workload sprawls across three providers. The web tier runs on AWS, the analytics pipeline on Google Cloud, and the identity stack on Azure. Each provider hands you its own console, its own billing export, its own log format, and its own permission model.

A SOC analyst gets an alert: an IAM role in an AWS account assumed credentials it had never used, then called s3:GetObject on a bucket of customer data. Routine triage. Except the same identity, federated through the company's single sign-on provider, also holds a Contributor role in three Azure subscriptions and an Editor binding on two Google Cloud projects.

Three clouds, three scanners, three severity scales, three alert queues. That is the starting position for most teams running workloads across AWS, Azure, and Google Cloud. AWS Inspector flags a finding as "Critical." Microsoft Defender for Cloud calls a similar issue "High." Google Security Command Center ranks its own version on a separate scale.

A stolen password buys an attacker nothing if the login still demands a hardware key the attacker does not hold. That is the entire premise of multi-factor authentication, and it holds up under pressure: Microsoft reported in 2019 that enabling MFA blocks more than 99.9% of automated account-compromise attacks. The number has aged, but the conclusion has not.

Walk into most breach reviews and the network looks like a hotel with no front desk. A contractor's laptop with an out-of-date antivirus plugged into a conference-room jack and got a full corporate IP. A personal phone joined the same VLAN as the finance servers.

Every managed endpoint in the environment is clean. The endpoint agents report no malware, no suspicious processes, nothing to investigate. And yet a device on the network is quietly scanning internal hosts and beaconing to an external address every few minutes.

In 2013, attackers stole network credentials from Fazio Mechanical, a refrigeration and HVAC contractor with remote access to Target's network. They logged in with those credentials, then moved across a network that did not separate the vendor portal from the systems that processed payments. They reached the point-of-sale terminals, installed card-scraping malware, and exfiltrated roughly 40 million credit and debit card records, along with personal data on about 70 million more people.

A flat network is one compromise away from a total one. An attacker who phishes a single workstation lands on the same broadcast domain as the domain controller, the backup server, and the finance database, and nothing between those machines stops the next hop. Network segmentation is the work of cutting that flat space into isolated zones so a foothold in one does not become free movement across all of them.

A workstation looks clean. The antivirus is quiet, the endpoint agent shows a normal signed process making web requests, and nothing on the host raises a flag. But on the wire, the same machine is reaching out to one external address every sixty seconds, around the clock, with small, near-identical requests.

Repack a known trojan, change one byte, and its hash changes. To signature antivirus that is a brand-new file with no matching record, so it runs. The malware is identical in behavior, but the tool watching for it was only ever watching for the old hash.

A board asks the security team one question: are we secure? The honest answer is never yes or no, it is "secure against what, and how would we know." That gap, between a technical control list and a business conversation about risk, is the gap the NIST Cybersecurity Framework was built to close. It does not tell you which firewall to buy.

Explain NTLM vs. Kerberos vs. LDAP NTLM (NT LAN Manager): A challenge-response authentication protocol used primarily in Windows environments.

An outage starts as a question nobody planned for. Checkout latency triples at 02:14, but only for users in one region, only on mobile, and only when they pay with a saved card. No dashboard has a panel for that exact combination, because no one predicted it.

A modern application is mostly code nobody on the team wrote. Industry codebase audits routinely find that open source makes up the large majority of the average application, and that nearly every commercial codebase contains open source components. The framework, the JSON parser, the logging library, the cryptography you did not implement yourself, the transitive dependency three layers down that you never chose directly, all of it ships to production under your name and breaches under your name.

Before an attacker sends a single packet, they can already know your org chart, who reports to whom, which employee just posted about deploying a new tool, the email format from a leaked address, and the name of a security product mentioned in a job posting. None of it required hacking. It came from LinkedIn, a conference talk on YouTube, a public code repository, a job board, and a credential dump on a paste site.

When a vulnerability scanner sweeps a corporate laptop, the worst case is a reboot and a help-desk ticket. When the same scan hits a programmable logic controller running a turbine, the worst case is the turbine. OT devices were built to do one thing reliably for twenty years, not to absorb a probe they never expected.

A ransomware alert fires at 2:14 a.m. on a Sunday. Who sees it? For a 40-person company with one IT generalist, the honest answer is usually nobody until Monday.

CVE-2017-0144, the SMB flaw behind EternalBlue, had a patch out on March 14, 2017. WannaCry hit on May 12, 2017, almost two months later, and still tore through hundreds of thousands of machines because the update was sitting in a queue nobody had cleared. The vulnerability was not unknown and the fix was not missing.

A vulnerability scanner reports 4,000 findings on a network and flags 280 as critical. A penetration tester takes one of them, a forgotten Jenkins server with default credentials, chains it to an over-permissioned service account, moves to the file server, and walks out with the HR database in an afternoon. Same network, two very different answers.

An incident response team works through the night and thinks it has won. They found the malware, wiped the infected host, reset the compromised passwords, and closed the entry point. The next morning, the attacker is back, on a different machine, with fresh access.

In September 2023, attackers did not exploit a single vulnerability to take down MGM Resorts. They made a phone call. The group known as Scattered Spider pulled an employee's details from social media, called the IT help desk pretending to be that person, and talked the agent into resetting the account password and its multi-factor authentication.

A development team needs to ship a web app this quarter. They could rent virtual servers, install an operating system, patch it, configure a runtime, wire up a database, and maintain all of it forever. Or they can push their code to a managed platform that already runs the servers, the operating system, and the runtime, and have the app live the same afternoon.

An attacker phishes one employee and lands on their laptop as a standard user. That account cannot read the file server, cannot touch the domain controller, cannot do much of anything interesting. It is a toehold, not a win.

Most intrusions do not end on the machine they start on. They end on a domain controller, a cloud root account, a database holding everything that matters. The thing that carries an attacker from the first phished laptop to that crown-jewel system is privilege: an account with rights ordinary users do not have.

A breach starts with a stolen password and ends somewhere that password should never have reached. The reason is almost always a privileged account: a domain admin, a root login, a service account with rights nobody scoped. One compromised admin credential turns a single foothold into domain-wide control, and in most environments nobody can say how many of those accounts exist, who owns them, or when their passwords last changed.

A domain admin account had not logged in interactively for eight months. Its password was set in 2019 and never rotated. It was a member of three nested groups that, followed to the end, granted control over the domain controller.

A developer spins up an S3 bucket to share a dataset with a contractor, sets it to public for ten minutes to test the link, and forgets to set it back. Six weeks later a researcher finds it indexed, full of customer records. No exploit.

An attacker does not need a working quantum computer today to act on the quantum computing threat today. They need a packet capture, a place to store it, and patience. A nation-state intercepts your TLS sessions, your VPN tunnels, and your encrypted file transfers right now, writes them to disk, and waits.

Ransomware: Ransomware is a type of malware that encrypts files or locks systems on a victim's device, making data inaccessible until the attacker receives a ransom payment, typically in cryptocurrency. It is one of the most damaging and widespread cyber threats facing organizations today, targeting businesses, government agencies, healthcare institutions, and critical infrastructure alike. How Ransomware Works?

A criminal affiliate does not need to write a single line of encryption code to take down a hospital, a pipeline, or a city government. They log into a portal, pick a target, deploy a ready-made payload, and collect the larger share of the ransom. The malware, the leak site, the payment infrastructure, and the negotiation playbook were all built and maintained by someone else, who takes a cut for the rental.

By the time the ransom note appears, the fight is already over. Files are encrypted, backups are wiped, and the data was copied out days earlier. The operator spent that time inside the network on purpose, and that time is the only window a defender ever gets.

A finance clerk gets an invoice email, opens the attachment, and a macro runs. Three days later the file server, the hypervisors, and the backup appliance are encrypted, and the operator is threatening to leak 400GB of exfiltrated data unless the company pays. Walk that incident backwards and you find a chain of missed chances: an email that should have been filtered, an account that should have had phishing-resistant MFA, a flat network that let one foothold reach everything, and backups that sat online where the attacker could reach them too.

Your vulnerability scanner returns a clean report. Your endpoint tool shows no detections. Your SOC dashboard is quiet.

A web server is sitting behind a firewall that blocks every inbound connection except port 443. The attacker has found a command injection flaw in the app but cannot connect back to the box, because the firewall drops anything they send toward it. So they flip the direction.

Every security team works from a finite budget against an infinite list of things that could go wrong. You cannot patch every flaw, monitor every asset, or defend every path at once. So the real job is not eliminating risk.

Two logins arrive with the same valid password. One is the user's enrolled laptop on the corporate network at 9 a.m. The other is a fresh virtual host in a hosting-provider IP range at 3 a.m., an hour after that password surfaced in a breach dump.

A web application firewall sees an HTTP request with ' OR 1=1 -- in a parameter and has to guess whether it is an attack. It does not know if that string ever reaches a database, what query it lands in, or whether the code already parameterized it into harmlessness. It pattern-matches at the perimeter and either blocks legitimate traffic or misses the obfuscated payload it did not have a signature for.