Cyber Security

Case-Study Viva and Core Security Concepts

Published: 2026-08-16

Level: postgraduate

Audience: Postgraduate students in Cyber Security

Prerequisite Knowledge

This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.

Previously Covered in This Subject

Authentication, authorization, and accountability — covered in Lecture 2
Malware families: virus, worm, and trojan — covered in Lecture 2
Port numbers and well-known services — covered in Lecture 7
SaaS, PaaS, and IaaS cloud models — covered in Lecture 3
Physical, administrative, and technical controls — covered in Lecture 3
Preventive, detective, and corrective controls — covered in Lecture 3
Least privilege and need-to-know — covered in Lecture 5
SQL injection — covered in Lecture 11
Social engineering: phishing and spear phishing — covered in Lecture 11
Ransomware — covered in Lecture 11
Defense in depth — covered in Lecture 12
Single sign-on and MFA — covered in Lecture 12
SAST and DAST — covered in Lecture 12
Data loss prevention (DLP) — covered in Lecture 12
Supply chain attacks — covered in Lecture 15

This session is a series of short case-study defenses. Each team walked through a real cyber security incident and then faced pointed questions about the terms, controls, and attack chains behind it. The question-and-answer pattern is where most of the learning lives, so these notes preserve every exchange in full, with the definitions and controls woven around them.

16.1 The xz Utils Backdoor: Backdoors, Malware, and SSH Basics

16.1.1 The Case: Malicious Code in a Trusted Linux Utility

Hook. How would you notice if the compression tool you use every day had quietly become a door for attackers? That is the question this case answers: a handful of inserted lines of code in a trusted utility turned into a high-risk backdoor before anyone expected it.

The session opened with a backdoor-versus-malware question about the xz utils case. xz utils is a compression utility used widely in Linux operating systems — it is the tool behind the .xz and .tar.xz file formats that Linux distributions and package managers rely on daily. A couple of lines of code were maliciously inserted into it, and that code gave attackers access to the operating system. From there the computer could be compromised, leading to remote code execution, data theft, and data exfiltration — so the team rated it a high-risk backdoor.

Why a small change meant a big risk. A compression tool runs with the privileges of whatever process invokes it, and on servers it is often invoked automatically by system services and update flows. Malicious code inside it so runs whenever the utility runs — no special action from the victim required. That is what made the inserted lines dangerous out of proportion to their size: they executed inside a trusted context.

Worked example — the trigger event that exposed the problem. While a user was using the utility to upload a large file for compression, an SSH connection was being executed, and the authentication was interrupted — the data that was sent for authentication was analyzed. A Microsoft employee detected this anomaly, and that is how the issue came to light.

Step by step:

Normal flow: the user invokes the compression utility on a large file, and in parallel an SSH connection carries authentication data.
Anomaly: the SSH authentication is interrupted mid-connection — an abnormal event, because authentication either completes or fails cleanly; it should not stall midway.
Observation: the authentication data sent during that interrupted exchange is analyzed — someone looked closely at the payload that the seemingly innocent compression job was emitting.
Detection: a Microsoft employee spots the anomaly and reports it, and only then is the hidden code inside xz utils found and removed.

Sense-check: every step follows from one root cause — inserted code altering the behavior of a routine compression job. If no one had noticed the interrupted authentication, the backdoor could have stayed hidden for far longer.

Real-world: xz utils is a real, widely deployed open-source tool on Linux, which is exactly why a hidden backdoor inside it mattered — trust in the utility gave the attacker a foothold in many systems at once. The same pattern repeats across the industry: supply-chain poisoning of a trusted component (a library, a build tool, a package) converts ordinary maintenance into an attack vector.

16.1.2 Backdoor versus Malware

Formalize — the two terms side by side. A backdoor (also called a trapdoor in older literature) is a hidden entry point into a system that bypasses the normal security checks — a way in that does not go through the usual authentication or authorization gates. It can be planted deliberately — malicious code slipped into a trusted utility, as in this case — or it can be an unintended flaw that someone finds and uses. Malware (malicious software) is the umbrella term for any software written to harm or compromise a system. The two concepts overlap: here, malware was the vehicle, and the backdoor was the result — hidden code that quietly opened the door.

The relationship is easier to see with the vehicle-versus-result mapping: malware is the code (the vehicle), and the backdoor is the capability it creates (the result — a hidden entrance). In this incident, the planted malware functioned as the backdoor into the operating system: the malicious code carried the hidden entry point as its payload.

Q: What is the difference between a backdoor and malware? A: The first attempt described a backdoor as "a vulnerability in the code that already exists and someone uses it, bypassing the security checks to gain the access." That is closer to a vulnerability than to the backdoor-versus-malware contrast that was asked. The second attempt offered "a backdoor is the fault in the system that exists" and "malware is the infected system that provides the opportunity to an attacker to get into the system." Both answers were hesitant. The useful distinction to carry away: malware is the malicious code itself, while a backdoor is the hidden entry point — and in this incident the planted malware functioned as the backdoor into the operating system.

The correction sequence matters more than the correct answer: the student repeatedly described the weakness (a vulnerability in existing code) instead of the entrance (the backdoor). Keep the three boxes separate — vulnerability is the weakness, backdoor is the secret entrance built on it, malware is the harmful code that may use either.

16.1.3 Private Keys and Certificate Authorities

Asymmetric encryption (also called public-key encryption) uses a pair of keys: a public key that is shared with everyone, and a private key that stays with its owner and is never shared. The private key is what you keep safe, and you use it for authentication or for signing something; the public key lets others verify that the signature or the identity is genuinely yours.

Intuition — the locked mailbox. Think of a mailbox where everyone in the world has the key that locks it (the public key), but only you have the key that opens it (the private key). Anyone can slip a message in by locking with your public key; only you can open it with your private key. For signing it works in reverse: only you can "sign" a message with your private key, and everyone can verify that signature with your public key. The analogy breaks if you imagine the keys as identical — they are mathematically paired but different, and one never reveals the other.

The question that followed asked the student to name and defend the private key half of that pair.

Q: What do you understand by private key? A: In asymmetric encryption there are two keys — public and private. The public key is shared with everyone; the private key is the one we have to keep safe, and we use it for authentication or signing something. The private key always stays with the owner, never with the public side.

Scope — what the private key does and does not protect. The private key protects your side of the identity: it is what proves a message or login genuinely came from you. It does nothing by itself against a stolen public key — the public key is public by design. If a private key leaks, anyone can impersonate its owner, which is exactly why keys must be stored in protected key stores, hardware tokens, or password-encrypted files — and why losing one triggers revocation and re-issuance of certificates.

A certificate authority (CA) is the authority that signs certificates. Say you hold your own public and private key pair; the CA is a trusted third party that vouches for your public key by attaching its signature to a certificate for it. The CA signing key is the private key the CA itself uses to produce those signatures.

Worked example — why a CA is needed. Suppose Alice publishes a public key and claims it is hers. How does Bob know it really belongs to Alice and not to an attacker who posted a key in her name? Without a trusted middleman, anyone can claim any key. The CA solves this:

Alice generates a public/private key pair.
Alice presents her public key to the CA along with proof of identity.
The CA verifies the identity, then signs a certificate — a package containing Alice's identity, her public key, and the CA's own signature.
The CA signs with its signing key: its private key. Anyone can verify the signature with the CA's well-known public key.
Bob receives Alice's certificate, checks the CA's signature, and now trusts that the public key inside really belongs to Alice.

Sense-check: the chain only holds if the CA's private signing key is kept secret — if the CA's signing key leaks, every certificate it ever issued becomes forgeable, which is why CA key compromises are treated as critical incidents.

Q: What does CA stand for, and what does a CA signing key mean? A: CA stands for certificate authority — the authority whose role is to sign certificates. For example, a person has a public key and a private key; the CA is somebody who acts as the authority that signs the certificate so others can trust that the key belongs to the person.

Exam note: whenever an abbreviation such as CA appears, be clear on what it stands for, what its role is, and what its signing key does — loose abbreviation use was the weak spot in the write-up. In the exam, define the abbreviation, state the role (a trusted third party vouching for public keys), and state what the signing key is (the CA's private key used to sign certificates).

16.1.4 SSH and Standard Port Numbers

SSH (Secure Shell) is the protocol used for secure remote connections, and its standard port is 22. During the lab work the team had tried different port settings while testing SSL-related issues — they mentioned 501 and 614 — which caused confusion about which port was really in use. The instructor settled it: SSH is 22.

Intuition — port numbers as apartment numbers. A server's IP address is the building; the port number is the apartment. SSH lives in apartment 22, HTTP in apartment 80, HTTPS in 443, RDP in 3389. Two parties can only talk if they knock on the same door — which is why knowing standard port numbers matters both for setting services up correctly and for spotting scanners probing them.

The lab mix-up made the port question a natural follow-up.

Q: Which port number does SSH use? A: Port 22. Earlier, while trying different configurations and SSL-related checks, ports like 501 and 614 had been used for testing, which is what caused the confusion.

Pitfalls. (1) Confusing SSH's port with SSL-related test ports: during lab work the team used ports 501 and 614 for SSL testing and then reported them as SSH's port — testing configuration is not the same as the standard port. (2) Assuming the port number changes the protocol: running SSH on a non-standard port is a configuration choice, not a protocol change — the service is still SSH, just on a different door. (3) Skipping the check: in the exam, state the standard port confidently (SSH = 22); a wrong port number loses marks even when the rest of the answer is right.

16.1.5 Exam Notes

Exam note: the examination is a combination of theoretical and practical knowledge — prepare both. Be ready to explain every abbreviation you use (such as CA), the role of a certificate authority, the standard port numbers (SSH is 22), and the main challenge in establishing an SSH connection — in this incident, the authentication being interrupted mid-connection. Practical follow-ups may probe how the anomaly was detected, so rehearse the trigger sequence: interrupted authentication → analysis of the authentication data → detection by a Microsoft employee.

16.2 Slack Security Breach: Incidents, Tokens, and Brute Force

16.2.1 The Case: Employee Tokens and GitHub Access

Hook. What if one stolen piece of login data let an attacker become you — on every repository-hosting site your company uses? That is the Slack case: not a hack of Slack's servers, but the theft of employee security tokens that opened employee accounts from outside.

The Slack security breach case focused on how attackers gained real access. The attackers targeted employee security tokens — specifically the single sign-on token issued during the authentication flow when employees signed in to access their GitHub repositories as part of their official accounts. With those tokens, the attackers could log into GitHub and other repository-hosting websites as the employees.

Real-world: this is the classic token-theft pattern — steal one login credential (the token), and everything the employee can reach becomes reachable. It is why tokens are stored in protected browser stores, expire quickly, and are often bound to a specific device: the token is the key to the kingdom while it is valid.

16.2.2 Security Incident versus Breach

A security incident is any suspicious or harmful event — something went wrong. A breach is the serious subset of incidents: data was actually modified, exposed, or stolen, which violates the confidentiality contract with the client.

Q: Give me a one-point difference between a security incident and a breach. Which turns into which? A: First answer: an incident is any kind of security vulnerability or misuse — stealing data, or even a DDoS attack — while a breach is mainly focused on data leaking from a data source. Asked which comes first, that student said "the breach will turn into a security incident" — that is backward. The corrected view: all breaches are security incidents, but not all incidents are breaches. Minor things like DDoS, timestamp problems, or NTP overflow get reported as incidents; a breach means data was modified or the confidentiality contract with the client was violated.

Formalize — the set relationship. Think of incidents as a big circle and breaches as a smaller circle inside it:

Incident = any event that is out of the ordinary and potentially harmful: a DDoS attack, a timestamp problem, an NTP (network time protocol) overflow, a phishing email reported by a user.
Breach = an incident in which data was actually touched — modified, exposed, or stolen. A breach always violates the confidentiality contract with the client.

The one-line rule that settles every follow-up question: all breaches are security incidents, but not all incidents are breaches — so an incident happens first, and a breach is the escalation of an incident into actual data compromise.

That hierarchy matters for incident response: you log every incident, but you escalate and declare a breach only when data is actually touched or leaked. Minor incidents are recorded and monitored; a breach triggers disclosure obligations, forensics, and client communication.

Pitfall — the direction of the arrow. The student's first attempt said "the breach will turn into a security incident" — that inverts the hierarchy. A breach does not become an incident; an incident becomes a breach when data is actually compromised. Draw the two circles on paper if needed: incident (big) contains breach (small). When asked "which comes first", the answer is incident.

16.2.3 Tokens: Authentication versus Authorization

A token is a piece of data that proves a login already happened. Tokens are mainly used for authentication — proving who you are. They can also carry authorization information when they are JWTs (JSON web tokens): a JWT can hold the role and other claims that the server then uses to decide what you may do.

Q: The attackers targeted employee security tokens. Are tokens used for authentication or authorization? A: Tokens are mainly used for authentication. They are not a single sign-on token by themselves — wait, they can also be used for authorization if they are a JWT, because a JWT contains the role and other information. But in this case the token referred to in the case study is the single sign-on token from the authentication flow of the employees when they try to access their GitHub repositories as part of the official account — so here it is for authentication.

The exchange itself was a good demonstration of thinking out loud: the student first over-narrowed tokens to authentication, then caught the JWT exception, then applied the case facts to settle on authentication. That thought process is the model answer for a viva.

Q&A — the correction that kept both halves. The professor's answer shows the two-layer mental model: a token's primary job is authentication (proving the login happened), and only a JWT specifically can carry authorization as well, because its payload includes claims such as the user's role that the server reads to decide what the user may do. In the Slack case the stolen token was the single sign-on token from the authentication flow — so the theft defeated authentication, and authorization followed automatically because the employee's identity was accepted everywhere the token was accepted.

16.2.4 The Failed Control: Brute Force without Rate Limiting

Brute force means trying many password guesses over and over until one works. Rate limiting means capping how many login attempts are allowed in a given time window — the direct defense against brute force. A security code audit means reviewing the application code for weaknesses before it ships.

Q: What technical control failed and caused this breach? A: This was carried out by a brute force attack. The organization did not implement rate limiting on their login pages, and the security code was not audited properly, so the attacker could guess the password multiple times. The basic authentication control itself was not implemented properly. It was at the application level — they targeted a specific employee-facing application to gain access, took the tokens from there, and then logged into GitHub and other repository-hosting websites.

Worked example — the brute-force attack chain. Put the pieces in order:

Target selection: the attacker picks a specific employee-facing application — the application-level target.
Reconnaissance on the login page: the attacker notices there is no rate limiting, so guesses are not capped and no lockout triggers.
Guessing: the attacker submits many username/password guesses over time; because the security code was not audited and no attempt cap exists, the guesses keep flowing until one succeeds.
Token theft: once logged in, the attacker captures the single sign-on token issued during the authentication flow.
Lateral movement: the attacker uses that token to log into GitHub and other repository-hosting websites as the employee.

Sense-check: every step depended on the previous one — no rate limit made the guessing possible, guessing produced the login, and the login produced the token. Block any one step (rate limiting, code audit, token expiry) and the chain breaks.

16.2.5 Password Exposure and the No-Index Problem

Two further weaknesses were named in the technical analysis. First, security updates (password changes) were hidden from search engines because the site used the no-index concept — search engines were told not to record the pages. Second, although the plaintext passwords were not exposed, hash versions of the passwords were exposed.

Q: What were the two issues that made the breach possible? A: Two major issues: the security updates were hidden from the search engines because of the no-index concept they used at that time, and the password exposure — the passwords themselves were not exposed, but the hash versions were. So password security needed to be raised, and the no-index concept should be dropped so password updates are known to everyone.

The follow-up asked how to undo the first weakness, since the second one (exposed hashes) is fixed by stronger password practice.

Q: What technical control do you implement to overcome the no-index issue? A: Remove the no-index concept, so that password changes are visible and everyone is aware of the updates going on. With visibility, password-exposure attacks and even brute force stop working as easily.

Pitfalls. (1) Treating no-index as a security feature: no-index is meant to keep pages out of search results for SEO reasons, but here it hid security update pages — the exact pages users need to see. Hiding the change notices meant users never learned their passwords were compromised or changed. (2) Underestimating exposed hashes: the plaintext passwords were not exposed, but hash versions were — hashes are still dangerous because weak passwords can be recovered by dictionary and rainbow-table attacks. (3) Fixing only one of the two issues: removing no-index without raising password security (e.g., forcing changes, hashing with salts) leaves the exposure half-fixed.

16.2.6 Security Testing: SAST and DAST

Normal testing teams in the SDLC focus on functionality — does the feature work. Security testing asks a different question: does the application contain exploitable weaknesses? Two standard approaches were laid out: SAST (static application security testing) and DAST (dynamic application security testing).

Q: How do you test an application for security vulnerabilities? A: From the security side you use static application testing and dynamic application testing — SAST and DAST. You take the OWASP Top 10 vulnerabilities and check whether those are present in your application: either manually going line by line through each piece of code, or giving the application as input to a security tool that does a thorough scan and reports the vulnerabilities it finds.

Real-world: SAST reads the code without running it; DAST attacks the running application from the outside. Companies use both, with the OWASP Top 10 as the checklist of what to look for.

Dimension	SAST (static)	DAST (dynamic)
What it examines	Source code, line by line	The running application, from outside
When it runs	Early — during development, before deployment	Late — against a running build, even in production
How it finds bugs	Pattern-matches against known bad code patterns	Sends real attack inputs and watches the responses
Analogy	Proofreading a manuscript before printing	Hiring a critic to read the printed book and poke at it
Blind spot	Cannot see runtime behavior, config, or wiring	Cannot see code paths the running app never exercises

When to pick which: use SAST early and continuously in the pipeline to catch flaws cheaply, and DAST before release (and after) to catch runtime vulnerabilities — the two complement each other.

16.2.7 Need-to-Know Basis versus Least Privilege

Both principles limit access, but they start from different questions. Need-to-know basis: grant only the functions the user's job description requires, nothing more. Least privilege: everyone begins with the minimal set of privileges by default, and more access is given only on request when a real need exists.

Q: What is the difference between need-to-know basis and least privilege? A: Need-to-know basis: the functionalities required for the particular user — their job description — are provided, and no extra privileges are given. Principle of least privilege: by default only the minimal set of privileges is given to the user, and only on a request basis — if they need a higher level of access, that is granted.

The two principles are close cousins, so the professor drilled them side by side to keep the starting point of each one distinct.

Intuition — two ways of deciding the size of the door. Need-to-know asks: "What does this job title require?" and cuts access to match the job description. Least privilege asks: "What is the minimum anyone could start with?" and starts everyone at zero, granting more only on request. The first is scoped to the role; the second is scoped to the baseline — both exist so that an employee's stolen token (as in Slack) can reach only a small slice of the company's data.

16.2.8 Exam Notes

Exam note: expect basic questions, but with follow-ups that probe the logic — for example "which comes first, the incident or the breach?" Be able to name SAST and DAST, and know that the OWASP Top 10 is the reference list for web application vulnerabilities. Rehearse the incident-versus-breach hierarchy (all breaches are incidents, not vice versa), the failed-control story (brute force succeeded because rate limiting was missing and code was not audited), and the two terminology pairs introduced here: authentication versus authorization, and need-to-know versus least privilege.

16.3 Okta Incident (October 2023): Cloud Models, IAM, and SSO Risks

16.3.1 The Case: Tokens Compromised at the Service Level

Hook. You lock your front door, but the building's main door was left open. The Okta incident is that second kind of failure: not a client's application being hacked, but the identity service itself being compromised at the product level.

The Okta security incident happened in October 2023. Okta is a cloud-based SaaS solution — software as a service — that provides identity and access management. In the incident, a person was working from home and forgot to log off; that is how some of the cookies and session tokens were compromised. The compromise was at the service product level — Okta's own systems, not the client's application.

Why position matters. Because Okta is the service that other companies rely on to verify their own users, a compromise at Okta's product level has a multiplier effect: one broken token inside the identity provider can echo into every application that trusts Okta. The same "forgot to log off" mistake that a user might make on any site becomes a systemic risk when the session belongs to the identity service itself.

16.3.2 Cloud Service Models and Shared Responsibility

Q: Okta is a SaaS solution in the cloud. What are the other service types a cloud provider offers? A: The types are SaaS, PaaS, and IaaS — software as a service, platform as a service, and infrastructure as a service.

That first question settled the names; the second question moved from naming the models to responsibility within them.

Q: With SaaS, whose responsibility is security? A: Cloud security is discussed in two ways: security in the cloud and security on the cloud. The infrastructure part is taken care of by the cloud provider, but the software part — access and identity — is the client's responsibility.

Formalize — the three service models. The cloud offers computing at three levels of abstraction, each handing a different layer to the customer:

IaaS — infrastructure as a service. The provider delivers raw computing resources: processing, storage, networks, virtual machines. The customer installs and manages operating systems and applications on top. Example: Amazon EC2, where you rent a virtual server and run your own software on it.
PaaS — platform as a service. The provider adds a ready-made platform — runtime environments, databases, development tools — on which the customer deploys applications. The customer writes and runs code but does not manage the platform underneath. Example: Heroku or AppEngine, where you push code and the platform handles servers and scaling.
SaaS — software as a service. The provider runs the complete application in the cloud; the customer just uses it through a browser or app. Examples: Gmail, Microsoft 365 — and Okta itself, which delivers identity and access management as a finished service.

Each level moves a different set of responsibilities from the customer to the provider: in IaaS the customer manages almost everything above the hardware; in SaaS the provider manages almost everything, and the customer manages its own accounts, access, and data handling.

Intuition — security in the cloud versus security on the cloud. "Security in the cloud" means what the provider secures — the infrastructure underneath the service: data centers, servers, networking, hypervisors. "Security on the cloud" means what the customer must secure — everything placed on top: accounts, identity, access, configurations, and how data is handled. In SaaS, the provider takes care of the infrastructure part, but the client still owns the access-and-identity part — which is precisely where the Okta incident bit: the failing component was access and session handling.

The shared responsibility model: the provider secures the infrastructure under the service; the customer secures what it puts on top — accounts, access, and data handling. Position matters too: Okta itself runs on a cloud provider's infrastructure and has its own clients, so Okta is both a customer (of the cloud provider) and a service provider (to its clients). This double position means Okta must satisfy the customer-side responsibilities of its own cloud provider while simultaneously being judged as a provider by its clients.

16.3.3 IAM, Auth0, and Active Directory

IAM (identity and access management) is the family of services that handle who people are and what they can do. Auth0 is a platform that helps developers add authentication and authorization flows to their applications — it belongs in the IAM space. A common confusion: is Auth0 part of Okta, or a separate product? The answer settled on: a separate platform.

Q: You mentioned Auth0. What is it, and is it part of Okta? A: Auth0 is a platform which helps developers add authorization and authentication flows to their application; it is part of the IAM — identity and access management — space. The first answer said it is part of Okta only because Okta itself gives the IAM solution. That was corrected: Auth0 is a different platform — an access management platform that provides authentication, just like Okta, offering SSO and MFA — and it can integrate with your Active Directory.

The reasoning that sounded plausible but was wrong — "both are IAM, so one must contain the other" — is a good warning for the viva: being in the same product space does not make one product part of another. Same space, different vendor, same feature family.

16.3.4 Single Sign-On and Its Weakness

SSO (single sign-on) lets a user log in once and get into many applications without logging in again. The convenience comes with a single point of failure.

Q: What is the full form of SSO, and what is its main disadvantage? A: SSO is single sign-on. The main disadvantage: in SSO we rely upon tokens. If the tokens get saved somewhere unsafe or if the tokens get breached, the attacker gets access to the whole application — everything the user could reach.

Scope — the trade-off is structural, not accidental. SSO concentrates the login into one token, and that concentration is the whole point (one login, many apps) and the whole risk (one stolen token, many apps). The risk cannot be designed away while keeping SSO; it is managed by shrinking the blast radius — short token lifetimes, token binding to devices, revocation, and MFA at the login point. The lesson of the case: the compromised session tokens were SSO tokens, so one stolen token equaled access across the employee's connected services.

That is exactly the lesson of this case: the compromised session tokens were SSO tokens, so one stolen token equaled access across the employee's connected services.

16.3.5 APIs and the Backdoor User Account

An API (application programming interface) is a means of communication between applications — a defined way for one program to request functionality from another. RESTful APIs are the common kind today. Want geolocation inside your app? You call an API that provides it.

Q: What is an API, and why do we need it? A: API is application programming interface. There are multiple kinds of APIs; the ones that come to mind are the RESTful APIs. If you want a certain functionality in an application — for example geolocation — you can use an API for that. Developers use APIs on a regular basis; it is just a means of communication with another application.

The menu picture helps explain why the next question — about the backdoor user account — was a design question, not a code question.

Intuition — the restaurant menu. An API is the menu a restaurant hands you: it lists what you can order (the endpoints) and how to ask for it (the request format), without letting you into the kitchen to cook it yourself. You call the API with a request, the restaurant's kitchen does the work, and the response arrives plated. The analogy breaks where menus are public by design: some APIs are meant to be public, others must be locked behind authentication and authorization — and the Okta incident showed what happens when the API that administers accounts (the admin API) can be used to create a backdoor user account: an identity that exists in the system but was never sanctioned by the organization.

The team's technical analysis noted that the attacker used the Okta admin API to create a backdoor user account. The question that followed separates a designed feature from an unintended hole.

Q: What is the difference between creating a traditional user account and a backdoor user account? A: There is definitely a difference. The backdoor functionality should not have been there — it should have been tested beforehand, and the backdoor should not have been possible. In this case it was, because there was not enough testing in the first phase, and it should not have been a problem if they had multi-factor authentication in the first phase either.

Worked example — how the backdoor account was created. Put the Okta admin API abuse in order:

Access the admin API: the attacker reaches the endpoint that administers identities — the Okta admin API.
Call the account-creation function: the API offers a create-user operation; because testing was not enough and MFA was missing on the session, the call is not blocked.
Backdoor account created: the new identity exists in the directory — indistinguishable from a normal account from the outside.
Persistent access: the attacker can now log in with the backdoor account at any time, even after the original token expires.

Sense-check: every step is a legitimate API operation — the problem is that the system allowed an unintended capability. A normal user account is a designed feature gated by policy and MFA; the backdoor account is the same operation running without those gates. MFA on the session and regular security audits of admin-API calls close the loop.

Q: How do you check for API vulnerabilities? A: By security scanning tools.

Q: How do you overcome backdoor user accounts being created? A: Strong authentication mechanisms — multi-factor authentication — plus regular security audits.

The two short answers together form the prevention story: scanning tools find the hole, MFA and audits stop the backdoor from being created in the first place.

Pitfalls. (1) Treating every API endpoint as equally sensitive: the admin API is a crown-jewel endpoint and needs stronger protection (MFA, audit logging, restricted callers) than read-only public APIs. (2) Relying on testing "in the first phase" only: testing must cover the abuse paths — what happens when an authenticated caller invokes admin endpoints — not just the happy path. (3) Confusing detection with prevention: security scanning tools find API vulnerabilities, but the backdoor account case is prevented by MFA and audits, which stop the creation and catch it when it slips through.

16.3.6 Exam Notes

Exam note: be ready to explain SaaS, PaaS, IaaS; the shared responsibility split (security in the cloud versus on the cloud); what SSO is and its main weakness; and the difference between a normal user account and a backdoor user account. Rehearse the position argument — Okta is simultaneously a customer of its own cloud provider and a service provider to its clients — and the Auth0 correction: separate access management platform, same IAM space, offers SSO and MFA, integrates with Active Directory.

16.4 MOVEit Ransomware against a Government Body: Exfiltration and Double Extortion

16.4.1 The Case: Encrypted and Exfiltrated

Hook. A robber can either lock you out of your own house or steal your belongings — what if they did both and then demanded money to unlock the house while threatening to sell what they stole? That double threat is exactly what a ransomware group did to a government body.

The case study covered a ransomware attack on a government organization (NCSC) that runs on MOVEit. Ransomware groups had encrypted the files on the servers and also exfiltrated data. Because the organization is a government body, it holds very sensitive data related to national security — including army and military matters — and some citizens' personal data was on the systems as well. The main risk was data exposure.

Why this case is special. The victim's type changes the impact: a government body holds national-security data (army and military matters) and citizens' personal data. That combination means the incident is simultaneously a security problem (confidentiality broken) and a privacy problem (citizens' personal data handled improperly) — and it raises compliance duties toward regulators and citizens.

16.4.2 Exfiltration and the Controls against It

Exfiltration is the act of moving data out of a protected boundary.

Q: What do you understand by exfiltration? A: Exfiltration means moving the data out. In the context of ransomware, it means moving the data from the organization into a server or a machine that is controlled by the attacker.

Formalize — the exfiltration journey. Exfiltration has a destination problem, not just a source problem: the data leaves the organization's protected boundary and lands on a server or machine controlled by the attacker. Once the copy exists outside the boundary, the organization loses control over it forever — even if the original files are recovered by backup, the attacker still holds the stolen copy. That permanence is what makes exfiltration the more dangerous half of the attack.

The controls discussion went through several layers, and the classification of each one is the real lesson.

Q: What technical control do companies implement to avoid exfiltration? A: (First attempts) Proper network segmentation, plus endpoint monitoring — when so much data moves outside a network, a proper monitoring setup raises an alert that we can act on; without endpoint detection, attackers can move data out easily. Also encryption of the classified information, and limiting access so not everybody can reach all the data — confidentiality — only what they need.

Q: Is monitoring a preventive control or a detective control? So what is the preventive control for exfiltration? A: Detective. Monitoring detects the data leaving; it does not stop it, so monitoring does not prevent exfiltration. The primary preventive control is DLP — data loss prevention — which watches outbound data movement and blocks unauthorized transfers before they leave the network, together with firewalls that block access out.

DLP (data loss prevention) systems watch outbound data movement and block unauthorized transfers before they leave the network. The takeaway sequence: network segmentation and access control shrink the paths; encryption blurs what leaves; monitoring (detective) raises the alarm; DLP and outbound firewalls are the preventive controls that actually stop the data from going out.

Formalize — the control classification table. Every control the class proposed has a place on the preventive–detective axis:

Control	Class	What it actually does
Network segmentation	Preventive (shrinks paths)	Splits the network into zones so not every system can reach every other system; data must cross fewer, controlled chokepoints
Access control / least access	Preventive	Only people who need the data can reach it (confidentiality), shrinking who can exfiltrate it
Encryption of classified data	Preventive-ish, but incomplete	Blurs what leaves — an encrypted file is unreadable outside — but does NOT stop data moving out, so alone it is not a real exfiltration control
Endpoint / network monitoring	Detective	Detects data leaving and raises an alert; does not stop it
Firewalls blocking outbound	Preventive	Stop connections and transfers at the network boundary
DLP	Preventive (primary)	Watches outbound data movement and blocks unauthorized transfers before they leave the network

The exam-critical line: DLP is the primary preventive control for exfiltration; monitoring is detective; encryption alone does not stop data from moving out.

16.4.3 Double Extortion

Double extortion is a ransomware strategy where the attacker applies two threats at once.

Q: What do you understand by double extortion? A: The ransomware group extorted NCSC in two ways. First, they encrypted the files on the servers; second, they exfiltrated the data. So they were threatening in both ways: either we will expose the data, or we will not let you decrypt the data. Since they do it twice, it is called double extortion.

Worked example — two levers, two threats. Work through the victim's options to see why double extortion is so hard to beat:

Threat 1 — encryption: files on the servers are encrypted. If the victim refuses to pay, the data stays locked.
Victim's countermove 1: restore from backup. This defeats the encryption lever — the data comes back without paying.
Threat 2 — exfiltration: the attacker already copied the data out. Even with restored backups, the attacker still holds the copy.
Victim's countermove 2: there is none — the copy cannot be un-copied. The attacker now threatens: pay, or we publish the national-security and citizens' data.

Sense-check: because the two threats are independent, defeating one (backup defeats encryption) leaves the other (exposure) fully armed. That is why even a perfect backup strategy does not defeat double extortion.

16.4.4 Security Incident and Privacy Incident at Once

Q: What is the main risk to the organization? A: Data exposure. It is a government organization, so it holds very sensitive data related to national security — army and military matters — and some citizens' personal data was also there.

Q: Is that exposure a security incident or a privacy incident? A: Both. Government data includes data related to national security — the army, the military — and also citizens' private data, so it is a privacy incident as well as a security incident.

Q: Any compliance failure involved? A: Security audits for the partners and service providers should have been performed. If those are not done and the partners' security level or controls are not up to the mark of the organization, they can act as a channel through which data could exfiltrate.

That last point is third-party risk: vendors and partners become an extension of your attack surface, so their security must be audited to your standard.

Pitfall — the "one label only" instinct. When asked "security incident or privacy incident?", the wrong mental model treats the two labels as alternatives. They are not: the same event can be both. The rule from the case: if the exposed data contains national-security material, it is a security incident; if it also contains citizens' personal data, it is simultaneously a privacy incident. The second label does not cancel the first — a government body's exposure is almost always both, plus a compliance matter (auditing partners and service providers to the organization's standard, so vendors cannot become an exfiltration channel).

16.4.5 Exam Notes

Exam note: know the control classification for exfiltration — DLP is the primary preventive control, monitoring and endpoint detection are detective, and encryption alone does not stop data from moving out. Be ready to explain double extortion (encryption threat plus exfiltration threat, which is why backups alone do not solve it) and to argue why a government-body exposure is simultaneously a security incident and a privacy incident with third-party audit duties.

16.5.1 The Case: An Account Takeover

Hook. No server was hacked, no code was broken — a handful of convincing messages was enough. The Twitter case shows that the most effective attack is often aimed at the person holding the password, not the machine that stores it.

The Twitter data breach case: through phishing and spear phishing, attackers got the authentication details of accounts and were able to access them — in this case, to post messages and tweets as the account owners.

16.5.2 Security Breach, Privacy Breach, or Both

Q: Is the Twitter data breach a security incident or a privacy incident? A: Security. Whenever a security breach or a data breach happens, automatically the privacy angle also comes into play — without crossing the privacy angle, the security breach cannot happen. Once spear phishing or phishing happens, the passwords and the authentication that a person has for his own account go to the hacker. So it is a privacy breach as well.

Formalize — why the two labels travel together. A security breach is a confidentiality failure: data that should stay private was accessed. The moment the data in question is a person's own authentication details — password and the ability to act as them — the breach has also crossed into the privacy domain, because the individual's private credential was compromised. The professor's framing: without crossing the privacy angle, the security breach cannot happen — the attacker had to get the person's private authentication to perform the breach at all. The mental model: a breach of credentials is simultaneously a confidentiality failure (security) and a violation of the individual's private data (privacy). The two labels are not alternatives; a data breach usually triggers both.

Social engineering is a hacking technique that targets people instead of machines — manipulating individuals into giving up access or authentication.

Q: What is social engineering? A: It is a hacking technique in which phishing and spear phishing are used. In spear phishing, a particular study is done on a particular individual, and the attack is tailored according to that person's behavior — it is more individual oriented. Phishing is more broadly oriented: mails and spurious messages containing links; when the person clicks, the authentication is transferred to the hacker. These techniques were used to get access to the accounts — in the Twitter case they could access the account and post messages and tweets.

Q: Is social engineering done using technology? A: Yes, it is done via technology itself — sending emails and messages to the individuals.

Formalize — phishing versus spear phishing.

Dimension	Phishing	Spear phishing
Target	Broad — mass messages to many people	Narrow — one specific individual
Preparation	Generic template reused everywhere	Research on the person's behavior, role, and habits first
Message	Spurious mails/messages with links	Tailored content designed to look credible to that person
Mechanism	Clicking the link hands the authentication to the attacker	Same click mechanism, but engineered for that target
Analogy	A net cast wide over the ocean	A hook made for one specific fish

The one-line contrast: phishing is a net cast wide; spear phishing is a hook made for one specific person. Both are forms of social engineering, and both rely on the human clicking.

Pitfalls. (1) Treating social engineering as non-technical: the professor was explicit — social engineering is done via technology itself (emails, messages, links); the human is the target, the technology is the delivery vehicle. (2) Thinking phishing and spear phishing are different attack families: they are the same family (deception via messages), differing only in scope and tailoring. (3) Underestimating the privacy label: because the attacker receives the victim's own authentication, the incident is automatically both a security and a privacy breach — one never arrives without the other here.

Recap. Social engineering = hacking people instead of machines. Phishing = wide net; spear phishing = tailored hook for one person. Both end the same way: the victim's authentication goes to the attacker, and the breach is simultaneously a security and a privacy incident.

16.6 WannaCry: Ransomware at Global Scale

16.6.1 The Case: Global Scale

Hook. A fire needs fuel to spread — WannaCry found its fuel in every Windows machine that had not been patched. The case is not about one clever exploit; it is about what happens when an attack meets an ocean of unpatched systems.

The WannaCry ransomware case is about scale. WannaCry targeted around 200,000 to 300,000 computers all over the world, in some 150 countries. It was not aimed at any particular victim — it attacked every Windows desktop that was not updated, and that is why it exploded to a global scale.

Worked example — the scale, in numbers. Put the WannaCry numbers side by side with a normal ransomware attack:

Dimension	Normal ransomware	WannaCry
Victims	One person or one company — sometimes a single PC	About 200,000 to 300,000 computers
Countries	One location	Some 150 countries
Targeting	Chosen victim	Every unpatched Windows desktop

Sense-check: the scale difference is not a difference in cleverness — it is a difference in spread. WannaCry did not pick its victims; it propagated through every system that had the sharing channel open and the patch missing, which is why the count reached the hundreds of thousands.

Why it spread the way it did. WannaCry rode the SMB file-sharing protocol across networks and propagated like a worm — once one machine in a network was infected, it scanned for other reachable machines and spread to them without user action. The patch for the underlying flaw existed before the attack; the victims were the systems that had not installed it.

16.6.2 Normal Ransomware versus WannaCry

Q: What do you understand by a normal ransomware and WannaCry? A: The main difference is the extent. WannaCry targeted around 200,000 to 300,000 computers all over the world in some 150 countries. Ransomware can be as simple as malicious software which can affect one or two single PCs as well — a hacker can target one particular person or one particular company and ask for money for the data. WannaCry was not targeted: it was done to every Windows desktop which is not updated, and that is why it affected on a global scale.

Formalize — the targeted-versus-untargeted axis.

Dimension	Normal ransomware	WannaCry
Targeting	Targeted — a specific person, company, or organization	Untargeted — every unpatched Windows desktop it could reach
Scale	One or a few machines	About 200,000–300,000 computers in some 150 countries
Method	Often delivered via email or exploit aimed at the chosen victim	Worm-like spread over the SMB sharing protocol, no per-victim effort
Income model	Ransom from the chosen victim	Mass ransom demands from thousands of victims at once

The key axis: targeted versus un-targeted. Normal ransomware is often a one-to-one crime; WannaCry was a fire that spread through whatever was unpatched.

16.6.3 Non-Technical Controls: The Administrative Family

Controls come in three families: physical, administrative, and technical. Patching and updates are technical controls. A non-technical control is, in practice, an administrative control — policy, process, and people.

Q: What is the non-technical control that can be implemented to prevent this? A: (First try: patch updates and regular system updates.) That is a technical control. The non-technical side: data backup — we can take care of our data and back it up. The controls are of three types — physical, administrative, and technical — and non-technical means the administrative control: training and awareness, telling people not to download random things, plus backup and recovery practice.

Q: So what is the administrative control you propose? A: For these kinds of things, we can give training and awareness and do backup recovery.

Formalize — the three control families. Security controls divide into three families:

Physical controls — tangible protections: locks, badges, guards, server-room doors.
Technical controls — implemented in software and hardware: patching, firewalls, encryption, MFA, antivirus.
Administrative controls — policy, process, and people: training and awareness programs, acceptable-use policies, backup-and-recovery procedures, incident response plans.

The professor's correction: a non-technical control means, in practice, an administrative control. Patching is technical; telling people not to download random things, running awareness training, and practicing backup-and-recovery are administrative. Training and awareness was the expected answer: a human who knows not to click and not to install unknown software is a control that no patch schedule can replace.

16.6.4 SMB, Patch Frequency, and Legacy Systems

SMB (Server Message Block) is the protocol Windows uses for file and printer sharing across a network — the sharing channel that malicious code can ride on.

Q: What does SMB stand for in Windows? A: Server Message Block — the protocol which helps Windows with sharing files over the network.

Intuition — the shared hallway. SMB is the shared hallway Windows uses to pass files and printers between computers on a network. It is meant to be convenient — you can open a document stored on another machine as if it were local. But a shared hallway is also a spreading path: malicious code that learns to walk it (scan for other machines, connect to them via the same file-sharing channel) moves from room to room without knocking — which is exactly the mechanism WannaCry exploited to propagate at global scale.

Patch cadence was probed as a follow-up, because patching failure was the root cause here.

Q: Patching failure is the main issue. What is the best frequency to update Windows — weekly, monthly, quarterly, or annually? When does Microsoft release those patches? A: The answer given was quarterly. The prompt had framed it as weekly, bi-weekly, or monthly in general. In practice, Microsoft ships security patches on a monthly cadence; the quarterly answer was left unconfirmed when the session moved on.

Scope — patch cadence in practice. The student's quarterly answer was not confirmed. In practice, Microsoft ships security updates on a monthly cadence (the second Tuesday of each month, "Patch Tuesday"), with out-of-band emergency patches when a vulnerability is being actively exploited. The broader lesson: patch cadence is a risk-management decision — monthly routine patching plus emergency patches for critical flaws — and delaying patches is what allowed WannaCry to spread through systems that had the fix available but uninstalled.

Legacy systems are the reason patch-failure keeps recurring.

Q: What do you understand by legacy systems? A: These are the old systems which are still relevant and still in use, but their patches are not available to them anymore. That is why they are called legacy systems.

Pitfall — the legacy trap. A legacy system is old, still relevant, still in use — but no longer receives patches, because the vendor has stopped supporting it. The danger is not that the system is old; it is that its vulnerabilities are permanent: fixes no longer exist, so any flaw found in it stays unfixed forever. That keeps the WannaCry failure pattern alive — unpatched systems sitting on the network, waiting for an attack that targets exactly that gap. The mitigation is not "patch the legacy system" (impossible) but isolation, removal, or compensation with other controls.

16.6.5 Defense in Depth and Recovery Controls

Defense in depth is the strategy of stacking many independent controls so that no single failure leaves you exposed.

Q: What does defense in depth mean? A: Defense in depth includes all the preventive as well as proactive measures for cyber security.

Intuition — multiple locks on multiple doors. Defense in depth is a castle with walls, a moat, gates, guards, and an inner keep: no single breach point ends the defense. Each control covers the gaps of the others — patching covers the machine, the firewall covers the network edge, training covers the human, backup covers recovery. If the attacker defeats any one layer, the next one still stands. The professor's compact definition: all the preventive as well as proactive measures for cyber security, working as stacked layers rather than one silver bullet.

The control-classification drill was repeated: preventive stops it, detective finds it, recovery restores after it.

Q: If you take backups regularly, is it a preventive, detective, or recovery control? A: (No spoken answer was captured; the expected classification is recovery — backup is what you use after an incident to restore the data.)

Formalize — the three control classes. Every control can be classified by when it acts on the incident:

Preventive — stops the incident before it happens: patching, firewalls, DLP, access control, training that stops clicks.
Detective — finds the incident while or after it happens: monitoring, endpoint detection, IDS, audit logs.
Recovery — restores the system after the incident: backup and restore, disaster-recovery plans, incident response.

The drill: preventive stops it, detective finds it, recovery restores after it. Backup is a recovery control — it does not stop the ransomware (preventive) and it does not alert you (detective); it is what you use after the incident to bring the data back. Backups belong to the administrative family when the practice is policy and procedure, though backup software itself is technical — the family question and the class question are two separate axes.

16.6.6 Exam Notes

Exam note: know the three control families — physical, administrative, and technical — and be able to classify a control as preventive, detective, or recovery. Expect the targeted-versus-untargeted contrast between normal ransomware and WannaCry, and be ready to name SMB (Server Message Block) and the meaning of legacy systems (old, still used, but no longer patched). Rehearse the correction: patching is a technical control; the non-technical/administrative answer is training and awareness plus backup-recovery practice.

16.7 Credential Stuffing: Nintendo Checker, Reverse Engineering, Remote Kill Switches

16.7.1 The Case: Credential Stuffing

Hook. One leaked password list can become an attack on a thousand other services — because people reuse passwords. Credential stuffing industrializes that bet with automation.

Credential stuffing is the attack where attackers take username and password pairs that were leaked from one service and try them on other services, betting that users reused their passwords. The case study documented a credential-stuffing attack, and with it the attacker-side tools described in the analysis.

Formalize — the economics of credential stuffing. The attack only makes sense because of password reuse: if users had a unique password per service, a leak at one service would be useless elsewhere. The attacker acquires bulk username/password pairs (from a data breach of one service), then replays them across other services, automated, at scale. Even a modest success rate pays: millions of attempts, a few percent of hits, thousands of compromised accounts. The defense mirrors the economics: unique passwords per service, MFA (a password alone is not enough), and monitoring for login anomalies.

16.7.2 The Nintendo Checker

Q: What does the term "Nintendo checker" mean, which has been referred to in your document? A: When a credential stuffing attack happens, the attackers usually check whether the existing credentials match the user or not. The Nintendo checker is a kind of automation created by attackers: at one time they can check multiple accounts and see whether their passwords match.

Worked example — what the checker automates. Suppose a breach leaked 10 million username/password pairs from a gaming service. Doing that check by hand is impossible; the Nintendo checker is the automation that replaces the human:

Input: the leaked list of username/password pairs.
Fan-out: the checker tries each pair against many target services at once (multiple checks at the same time), rather than one-by-one.
Test: for each pair, it submits a login attempt and reads the response — success or failure.
Output: a filtered list of working credentials — pairs that actually matched an account on the target service.

Sense-check: the point behind the name is that an automation, not a human, runs the try-and-check across thousands of accounts at once — the checker is the scale engine that turns a leaked list into usable accounts.

16.7.3 Reverse Engineering

Q: What do you understand by reverse engineering? A: You take a piece of software, you try to execute it, and you get the idea behind what is happening; then you deduce the logic going on behind it. Based on that logic you can try to find the vulnerabilities and what edge cases could have been missed. You do not have the code — you have the application — so you check the logic by executing it.

Intuition — the black box you are allowed to poke. Normal development builds software from source. Reverse engineering goes the other way: you hold a finished application (a black box), you run it, you watch what it does with different inputs, and you deduce the logic inside — then you use that deduced logic to hunt for vulnerabilities and edge cases the developers missed. You never see the source; the executable behavior is your only window. The professor's sequence: execute → deduce the logic → find the missed edge cases.

Pitfalls. (1) Assuming reverse engineering requires the source code — it explicitly works without it, by executing the application and inferring behavior. (2) Confusing reverse engineering with reading code — the point is behavioral analysis of a black box. (3) Forgetting the attacker use case: in this case the technique is used to understand an app's logic to attack it; the same skill set is also used legitimately by malware analysts on the defensive side.

16.7.4 Remote Kill Switch and Endpoint Controls

Q: What do you understand by a remote kill switch? A: The remote kill switch is a facility provided in the software that allows the attacker to remotely end the procedure without actually being at the site of the attack. It remotely ends the program so that no traces are left on the compromised machine.

Pitfall — the kill switch leaves no traces. The remote kill switch is a facility built into the attacker's software that lets the attacker remotely end the running procedure — without being at the site — so that no traces are left on the compromised machine. The dangerous property: it is not just "stop the attack"; it is "stop the attack and erase the evidence of it." Forensics then finds an empty machine, which is why detecting the incident while it runs matters more than after it ends.

Q: To prevent this incident, what technical control do you recommend? A: A firewall, and endpoint protection — an application-based firewall running on the end client system, so that non-recognized network behavior can be stopped at the source.

Q: An application-based firewall works at which layer of the OS? A: The application layer.

Formalize — two firewalls, two positions. A network firewall sits at the network boundary and filters traffic between networks. An application-based firewall runs on the end client system itself (endpoint protection) and filters at the application layer — the layer where applications interact with the network. Its advantage for this case: non-recognized network behavior (an app making unexpected connections, the checker dialing out, the kill switch phoning home) can be stopped at the source, on the very machine where it happens, rather than only at the perimeter. OSI model: the application layer is layer 7, the top layer, where the firewall sees what application is trying to communicate, not just which ports.

Recap. Credential stuffing = replaying leaked username/password pairs at scale, betting on password reuse. Nintendo checker = the automation that checks many accounts at once. Reverse engineering = deducing logic by executing a black box. Remote kill switch = remotely ending the attack with no traces left on the compromised machine — stop it with an application-based firewall working at the application layer.

16.8 MOVEit Breach: Ransomware Gangs, CVE Numbers, and Asset Inventory

16.8.1 The Case: MOVEit and the Ransomware Gang

Hook. One vulnerability number, one tool, one group of attackers — and data from thousands of organizations became a bargaining chip. The MOVEit case shows how a file-transfer product becomes a single point of failure for everyone who uses it.

This team studied the MOVEit data breach — the same MOVEit file-transfer tool that appeared in the government ransomware case, approached from a different angle. The document cited the vulnerability number 2023-34362 (CVE-2023-34362). MOVEit is used for transferring files from one organization to another and from one application to another. A ransomware gang exploited the vulnerability, and the team's recommendations — asset inventory, vulnerability assessments, network monitoring — were discussed in turn.

Why file-transfer tools are prime targets. A file-transfer product sits exactly where data is most concentrated and most mobile: it holds copies of whatever organizations pass to each other, and it is connected to both internal systems and external partners. Exploiting one flaw in such a tool exposes data from every organization using it — the MOVEit vulnerability did precisely that at scale.

16.8.2 Ransomware Gangs

Q: What is a ransomware gang? A: A ransomware gang is a group of hackers that sends out and deploys ransomware into people's computers, and blackmails them in different ways. One way: they breach the data and ask for some ransom — like some bitcoins — in return for not breaching or exposing the data. Another type of ransomware encrypts your data and demands money for the decryption.

Formalize — two blackmail models. A ransomware gang is a group of hackers that deploys ransomware and blackmails victims. The answer names the two revenue models:

Exposure threat: they breach the data and demand payment (for example, in bitcoins) in exchange for not publishing or further exposing it.
Encryption threat: they encrypt the data and demand payment for the decryption key.

These map onto the double-extortion pattern from the government case: the most dangerous gangs run both models at once — encrypt (deny access) and exfiltrate (threaten exposure).

16.8.3 CVE Numbers and Central Vulnerability Databases

A CVE identifier is a public, standardized identifier for a known vulnerability.

Q: In CVE-2023-34362, what does CVE stand for? A: In the session it was described as a collection of vulnerabilities stored together in a database that is accessible through the internet, so people can know which vulnerabilities exist in the world and protect their systems accordingly. (The standard expansion of the acronym is Common Vulnerabilities and Exposures.)

Q: Can you name one website where these vulnerabilities are centrally available? A: No answer came back in the session. The canonical central repository is the NVD — the National Vulnerability Database — along with vendor advisory pages.

Formalize — reading a CVE identifier. CVE stands for Common Vulnerabilities and Exposures. The identifier format carries information: CVE-2023-34362 breaks down as the fixed prefix "CVE", the year of assignment (2023), and a sequential identifier (34362) for that year. A CVE entry describes a known vulnerability — what it is, what software it affects, how severe it is — and is published so the whole community can patch. The central repository where these are available over the internet is the NVD (National Vulnerability Database), maintained by NIST, along with vendor advisory pages.

Worked example — the disclosure-to-patch workflow. Trace how a CVE saves systems:

Discovery: a researcher or vendor finds a flaw in a product — here, the MOVEit file-transfer vulnerability.
Assignment: the flaw receives a CVE identifier (CVE-2023-34362), giving the vulnerability a canonical, searchable name.
Publication: the advisory lands in the NVD and on the vendor's advisory page — a central, internet-accessible record of what exists in the world.
Community action: organizations read the advisory and patch before attackers weaponize it.

Sense-check: the value chain is only as fast as its slowest step — a vulnerability is public knowledge before every organization patches, which is exactly the window attackers exploit. This is why the professor emphasized that the community patching is the point of publishing a CVE.

16.8.4 Authentication versus Authorization

Authentication is proving who you are — username and password, OTP. Authorization is what you are allowed to do once you are identified — the permissions granted to that identity.

Q: What do you understand by authorization versus authentication? A: The answer given mixed the two up: it said the OTP you enter during a transaction is an authentication — correct — but then called username and password the authorization — that is backward. In standard terminology, username and password (and OTP) are authentication; authorization is the set of actions the system allows after you are identified.

Q&A — the correction that kept both halves. The answer contained one correct half and one backward half: correctly, the OTP entered during a transaction is authentication — but then username and password were called authorization, which reverses the standard terminology. The corrected picture: authentication answers "who are you?" (username and password, OTP, tokens, biometrics) and authorization answers "what are you allowed to do?" (the permissions granted to the now-identified identity — which files, which functions, which APIs). Username and password and OTP are all authentication; authorization decides the allowed actions.

16.8.5 Asset Inventory and Legitimate Applications

Q: Your recommendation mentioned maintaining an asset inventory. What does that mean, and at what level do you maintain it? A: An asset inventory is used to identify the authorized and unauthorized software present. In this case it was maintained at the server level, to overcome the listed vulnerability. You keep track of what is installed, what is authorized, and what should not be there.

The follow-up drilled the standard by which inventory entries are judged.

Q: What do you mean by legitimate applications? A: Legitimate means whether the application is aligned to the standard or not — that is, approved and compliant with the organization's policy.

Formalize — inventory as a detection foundation. An asset inventory is a record of the software present in the environment, kept to identify which applications are authorized and which are unauthorized. In this case it was maintained at the server level: each server's installed software is compared against the authorized list, and anything present that should not be there stands out. A legitimate application is one aligned to the standard — approved and compliant with the organization's policy. The reason it matters for this case: you cannot assess the vulnerability of software you do not know exists — inventory is the prerequisite for vulnerability assessment and for spotting the unauthorized tool that attackers plant.

16.8.6 Vulnerability Assessment and Network Monitoring

Q: How do you perform vulnerability assessment? A: You conduct regular assessments to identify the vulnerable components — by using a scanning tool.

Two tool questions followed: what to use, and what to watch.

Q: What tools do you use for network monitoring? A: Network monitoring is done by monitoring the network ports, protocols, and services. Tools like nmap and Zabbix are typical — nmap is a port scanning tool.

Having named the tools, the professor probed which parameter of the traffic matters most for detection.

Q: When monitoring network traffic, what parameters do you consider? A: Network monitoring is about the traffic coming into and going out of the network: how much exposure there is, in terms of bandwidth or traffic patterns, or network-wise the speed. Of all these parameters, traffic patterns are what would help identify and detect MOVEit-style attacks.

Worked example — the two tools doing two jobs. The monitoring answer names two tools with different roles:

nmap — the port scanner. nmap is used to enumerate what is exposed: which ports are open on a machine, which services listen on them, sometimes even which operating system is behind them. It maps the attack surface.
Zabbix — the network monitoring platform. Zabbix continuously tracks live network traffic: bandwidth usage, traffic patterns, and speed — the ongoing flow of data in and out of the network.

The parameter question is the exam trick: bandwidth tells you how much flows, speed tells you how fast, but traffic patterns tell you what kind of flow is happening — bulk transfers out of a server that never used to send bulk data is the pattern a MOVEit exploitation leaves behind as data flows out to attacker servers.

Sense-check: volume monitoring would catch "a lot of data went out", but pattern monitoring catches "the kind of traffic changed" — and the change in pattern is the earlier, more reliable signal. That is why watching patterns rather than just volumes is the detection lever for MOVEit-style attacks.

The connection to the case: a MOVEit exploitation creates a recognizable traffic pattern as data flows out to attacker servers, so watching patterns rather than just volumes is the detection lever.

16.8.7 SQL Injection

Q: What is SQL injection? A: A website takes some input; the attacker manipulates the query built from that input in a way that it is always true, or allows inputting more than one query. That way they can manipulate the database in the background.

Worked example — login bypass with an always-true condition. SQL injection happens when a program builds a database query by concatenating user input directly into the SQL text. Consider a login that checks username and password against a users table:

Normal query built from clean input:

SELECT * FROM tblUsers WHERE USERNAME = 'jdoe' AND PASSWORD = 'letmein'

The attacker enters ' OR '1'='1 into the username field (and password field). The program pastes it in and the query becomes:

SELECT * FROM tblUsers WHERE USERNAME = '' OR '1'='1' AND PASSWORD = '' OR '1'='1'

The condition '1'='1' is always true, so the WHERE clause matches every row — the query is satisfied regardless of the real credentials. The login is bypassed, and the attacker can manipulate the database in the background: the same trick can be extended to read other tables, inject more than one query, or modify data.

Sense-check: the attack succeeds only because the program trusted the input and pasted it into the SQL command; the fix is to stop trusting input — parameterized queries (prepared statements) that send values separately from the command, strict input validation (filtering characters like quotes), and database accounts with minimal privileges so that even a successful injection can do little.

Prevention was left open in the session. Standard defenses: parameterized queries (prepared statements), strict input validation, and database accounts with minimal privileges.

Recap. Ransomware gangs blackmail by encryption and/or exposure. CVE = Common Vulnerabilities and Exposures, the standardized identifier (year + sequence) for a known vulnerability, centrally available in the NVD. Authentication proves who you are; authorization decides what you may do. Asset inventory at the server level finds unauthorized software. Traffic patterns — not just volume — detect MOVEit-style exfiltration. SQL injection makes queries always true by pasting unfiltered input into SQL.

16.9 BlueKeep: RDP, Threat versus Threat Actor, Virus versus Malware

16.9.1 The Case: BlueKeep and Port 3389

Hook. You can sometimes spot a sickness before you know what it is — by watching the symptom. The BlueKeep case is a real-world example: rising traffic on a port revealed a vulnerability before anyone had named it.

The BlueKeep case combined a Windows vulnerability with the remote desktop access vector. The detection story is instructive: scanning tools run by cyber security institutions observed that traffic on the RDP port — 3389 — was increasing. No vulnerability was known at that point, but the rising traffic was reported to Microsoft, and that was when the vulnerability was first detected.

Real-world: this is anomaly-driven discovery — you notice the symptom (port traffic climbing) before you know the disease (the vulnerability behind it).

Worked example — the symptom-first detection chain. Put the BlueKeep discovery in order:

Baseline: security institutions run scanning tools that continuously observe network traffic, including the RDP port 3389.
Anomaly: the traffic on port 3389 is observed to be increasing — more connection activity than normal, though nothing is known to be wrong yet.
Report: the institutions report the rising traffic to Microsoft — the symptom, not a diagnosis.
Diagnosis: investigating the anomaly leads to the discovery of the vulnerability behind it: BlueKeep.

Sense-check: the report carried no vulnerability claim — it carried an observation. The detection worked because someone was watching the port before there was a known disease to look for; anomaly observation turned a symptom into a discovered vulnerability.

16.9.2 RDP

RDP (remote desktop protocol) is what lets you access a desktop remotely.

Q: What does RDP stand for, and what is its main functionality? A: RDP stands for remote desktop protocol. Its main functionality: you can access a desktop remotely. It runs on port 3389.

Intuition — the remote-control screen. RDP is the protocol that lets you see and control another machine's desktop as if you were sitting in front of it — the mouse moves, the screen updates, files can be copied. The convenience is also the danger: any machine that exposes RDP is a machine that offers a remote-controller to the internet, which is why RDP on port 3389 is one of the most-scanned services on the internet and a favorite target for brute-force and exploit-based attacks — exactly the vector BlueKeep rode.

16.9.3 Threat versus Threat Actor

Q: What is the difference between a threat and a threat actor? A: A threat is something — a potential danger or a harmful event — that may exploit the system or organization. A threat actor is the one who attacks: a hacker, or an organization or group of organizations that actually attacks the system or carries out malicious activity.

Formalize — the danger versus the one carrying it. A threat is the potential danger itself — a harmful event or condition that may exploit the system or organization (a vulnerability being exploited, malware, a destructive event). A threat actor is the entity that carries out the attack — a hacker, or an organization or group of organizations performing malicious activity. One is the danger; the other is the one carrying the danger. In the case: BlueKeep is the threat (the potential danger in Windows RDP); the cybercriminal groups exploiting it are the threat actors.

16.9.4 Virus versus Malware

The virus-versus-malware question drew three answers before it settled, which makes it a good confusion-repair example.

Q: Is a virus the same as malware? A: First answer: malware is a kind of security software or script running in the background which takes control of the whole system; a virus is something that comes externally — when you download software and a bug gets installed at the back of it — and it also takes control of the system. Second answer: a virus is also a type of malware which performs malicious actions like corrupting, and it can spread to other files or systems, while malware is the broader term covering unauthorized access and damage, which includes viruses. The final, precise version: a virus is a kind of malware, but it needs user interaction to spread — it has to be attached to a file someone opens. Malware in general can be wormable: it scans the systems and spreads across the network, with no user interaction needed. That is why the technical analysis called BlueKeep wormable — malware exploiting one system could propagate to other systems on its own.

Formalize — the differentiator is the spreading mechanism. The three answers climbed toward the precise rule:

First attempt (rejected): malware as "security software taking control of the system" and virus as "something external installed with downloaded software" — both describe effects (taking control) rather than the defining distinction.
Second attempt (closer): a virus is a type of malware — a category inside the umbrella term.
Final, precise version (accepted): a virus is a kind of malware that needs user interaction to spread — it has to be attached to a file someone opens (email attachment, downloaded document). Malware is the broad umbrella. Some malware is wormable: it scans systems and spreads across the network with no user interaction at all.

The clean rule of thumb: all viruses are malware, but not all malware is a virus; and the spreading mechanism — attached to a file (virus) versus self-propagating across the network (wormable) — is the differentiator. That is why the technical analysis called BlueKeep wormable: malware exploiting one system could propagate to other systems on its own, no clicks needed.

16.9.5 Collaboration through CVE and Incident Reports

Q: How do organizations collaborate and share information across different organizations? A: Security incidents — like BlueKeep — are published as a CVE, which publishes the vulnerability to the entire community, so people can do the patching or updates and mitigate the issue. In addition, security researchers or organizations share a security incident report with all the organizations.

Intuition — the shared wanted poster. Publishing a CVE is like nailing a wanted poster up in every town: one announcement informs the entire community, and everyone who patches fast denies the attacker the window of opportunity. Incident reports add the operational layer — organizations share what happened, how it happened, and what worked, so the next defender does not have to learn the same lesson from the same mistake. CVE publication = vulnerability awareness; incident report sharing = lessons from real attacks.

Recap. BlueKeep: a Windows RDP vulnerability on port 3389, discovered when institutions reported rising port traffic to Microsoft — anomaly-driven discovery. RDP = remote desktop protocol, port 3389. Threat is the danger; threat actor is the one carrying it. Virus is a kind of malware needing user interaction to spread; wormable malware spreads across the network on its own. Collaboration = CVE publication plus shared incident reports.

16.10 Kaseya Ransomware: Supply Chain Attacks

16.10.1 The Case: A Supply Chain Attack

Hook. Break into the water company's main pipe instead of each house — one door, thousands of homes. That is the economics of a supply chain attack, and the Kaseya case is a textbook example.

The Kaseya ransomware attacks case: Kaseya is a software services provider offering network and system monitoring to its customers, through the VSA (virtual system administrator) product. The vulnerability lived in the VSA, and through it the attackers reached Kaseya's customers.

Why "virtual system administrator" matters. The VSA product is what Kaseya's customers (managed service providers and their clients) use to administer their own fleets of machines. A tool designed to reach many systems is the perfect single point of failure: attackers who control the tool's backend control every system it manages.

16.10.2 Supply Chain Attacks versus Direct Attacks

Q: What is the difference between Kaseya and WannaCry? A: Kaseya is a supply chain attack. In a supply chain attack they need not attack the end systems directly; they attack at different levels — the service provider's software, like Kaseya's VSA. In the case of WannaCry, they attacked straight onto the systems.

Q: What does a supply chain attack mean? A: Kaseya was a software services provider — it provided network and system monitoring for all its customers, and the customers form a part of the supply chain to which Kaseya is indirectly linked. By a supply chain attack, they are trying to attack the end users through the vulnerability that exists in the provider's software — here, Kaseya's VSA.

Formalize — direct versus supply chain.

Dimension	Direct attack (WannaCry)	Supply chain attack (Kaseya)
Target	The end systems themselves	The provider's software, to reach the end users through it
Path	Attack straight onto the systems	Attack at a different level — the service provider's product (Kaseya VSA)
Reach per attack	One system at a time	Every customer of the provider at once
Relationship	Attacker-to-victim direct	Attacker → provider → end users (indirect)

The economic logic: attack one provider, and every customer of the provider becomes a victim without being individually targeted. The customers are part of the supply chain to which the provider is indirectly linked — so the vulnerability in the provider's software is the attack on the customers.

16.10.3 What Went Wrong and How to Fix It

Q: What is your recommendation to overcome a supply chain attack like this? A: The main problem was the vulnerability in the VSA, and the first mistake was with the backend, not the database: they had developed one single API for all the CRUD operations. So first, develop more APIs for different things and add a stronger access matrix based on need-to-know privileges. Also, the passwords stored in the SQL should have been hashed and salted. What actually happened: the attacker could modify the query, perform an SQL injection, get all the data, then use SSH or RDP to attack each and every system as and when they wanted, and inject the ransomware software. So add multi-factor authentication so that once you get the data, you cannot get in again; store the passwords better; and the backend should take more accountability — develop specific APIs for specific operations, even though they seem arbitrary.

Worked example — the full attack chain. The professor's answer reconstructs how the supply chain attack worked end to end:

Backend flaw: one single API handles all CRUD operations (create, read, update, delete) — one broad door to the whole backend.
SQL injection: the attacker modifies a query built from input, performing an SQL injection and retrieving all the data — including stored passwords.
Credential reuse: the stolen passwords (stored unsalted — hashed and salted storage would have blunted this step) unlock systems; MFA is the control that would have stopped the attacker from "getting in again".
Pivot: using SSH or RDP, the attacker reaches each and every system as and when wanted.
Ransomware deployment: the attacker injects the ransomware software into the systems — and because the entry was through the VSA, every customer of Kaseya is affected.

Sense-check: each step depends on the previous one — the single CRUD API enabled SQL injection, injection yielded credentials, credentials (without MFA) enabled SSH/RDP pivoting, pivoting delivered ransomware. Fix the first steps and the chain breaks.

The instructor's closing comment was praise with a lesson: that one answer covered multiple technical controls — salting, password hashing — and these are the best practices most companies use nowadays.

Salting means adding a random string to each password before hashing it, so identical passwords produce different hashes and rainbow tables fail.

Pitfalls. (1) One API for all CRUD operations: a single all-purpose backend API is a single point of failure — develop specific APIs for specific operations, even when they seem arbitrary, so an injection in one endpoint does not expose everything. (2) Storing passwords without salting: identical passwords then produce identical hashes, and precomputed rainbow tables crack them in bulk — salting gives every password a unique hash. (3) Stopping at the data breach: getting the data should not mean getting the systems — MFA must sit between stolen credentials and login. (4) Forgetting the accountability layer: the backend should be built with a stronger access matrix based on need-to-know privileges, so no single query or role can reach everything.

Recap. Kaseya = supply chain attack: the vulnerability lived in the VSA provider software, and end users were attacked through it. Direct attacks (WannaCry) hit the systems themselves; supply chain attacks hit the provider and inherit its customers. Fixes: specific APIs per operation, need-to-know access matrix, hashed and salted passwords, and MFA so stolen data does not become stolen systems.

16.11 Heartbleed and OpenSSL

16.11.1 The Case: A Flaw in the Heartbeat

Hook. A library that encrypts the world's most sensitive traffic asked "are you still there?" — and attackers discovered that the answer could leak the secrets it was supposed to protect.

The case covered Heartbleed, the vulnerability in OpenSSL — transcribed in the session as the "heartbleed flow in OpenSSL" case. OpenSSL is the open-source library that implements SSL/TLS: it encrypts and decrypts the data exchanged between two parties communicating. The flaw lived in the heartbeat feature — an echo message — which was modified to read memory outside the requested bounds.

Why a small library flaw was catastrophic. OpenSSL is embedded in web servers, mail servers, and VPNs across the internet; the heartbeat feature runs on every connection. A flaw in that feature meant any server running the vulnerable version could be drained of memory contents — including session keys, cookies, and passwords — without leaving obvious signs of break-in.

16.11.2 OpenSSL and the Move to TLS

Q: What do you understand by OpenSSL — what is its main function? A: OpenSSL is a communication protocol: it encrypts and decrypts the data between the two communicating parties.

That first answer described the function; the second pinned the generation of the protocol in use today.

Q: What is the current-generation protocol for end-to-end encryption? A: TLS — transport layer security. It is the successor to SSL, and the version in current use is TLS 1.2.

Formalize — the naming line. The professor's answer separates three things that students often collapse into one:

SSL (Secure Sockets Layer) — the old generation of the protocol that encrypts communication between two parties.
TLS (Transport Layer Security) — the current-generation protocol, the successor to SSL; the version in current use at the time was TLS 1.2 (later replaced by TLS 1.3).
OpenSSL — the open-source library that implements SSL/TLS: it is the software that does the encrypting and decrypting of the data exchanged between the two communicating parties.

The naming line: SSL was the old generation, TLS is the current one, and OpenSSL is the library that implements them.

16.11.3 Heartbleed: Out-of-Bounds Memory

Q: What is Heartbleed? A: It is a memory out-of-bounds access. In OpenSSL there is a feature called heartbeat — it is like an echo message. That feature was modified to gain information which is outside the memory bounds, so the server would answer back with memory contents it should never have shared.

Worked example — the echo that lied about its size. The heartbeat feature is a keep-alive: one party sends an echo message, the other party echoes it back to prove the connection is alive. The flaw: the responder trusted the claimed size of the echo instead of its actual content.

Normal heartbeat: the client sends a short echo, say the 4-character word "ping", and announces "I sent 4 bytes." The server stores the 4 bytes and sends back 4 bytes. Connection confirmed.
Malicious heartbeat: the client sends "ping" again — but claims it sent 5000 bytes. The server, trusting the claimed length, allocates room for 5000 bytes and echoes back the stored message plus whatever else sits in the next 4996 bytes of memory — because it never checked the real length.
Outcome: the server answers back with memory contents it should never have shared — session keys, cookies, passwords, other users' data — and the attacker can repeat the trick to drain memory over time.

Sense-check: the vulnerability is an out-of-bounds memory read: the code read and returned data beyond the requested bounds, because the length was never verified against the actual payload. A boundary check that ignores any message asking beyond the memory boundary would have stopped it cold.

Q: Is this an application-level vulnerability? A: Yes — since it sits in the TLS protocol, it is an application-layer concern.

A follow-up tested whether the fix could be OS-limited, or whether the vulnerability was broader.

Q: Is OpenSSL only a concern on Linux? A: OpenSSL is most common in Linux, because there the memory interacts directly with the library; but since it is an application-level issue related to the transport layer, it is not really tied to one operating system — in practice it matters most on the Linux systems that run it.

Scope — where the vulnerability lives. The professor's answers pin down the boundary: Heartbleed is an application-level concern because it sits inside the TLS protocol implementation, which operates at the application layer of the network stack. And it is not an operating-system-specific flaw: it is not really tied to one OS, even though in practice it mattered most on the Linux systems that run OpenSSL and interact with the library's memory directly. The lesson: classifying a vulnerability correctly (which layer, which library, which OS exposure) determines where you look for it and where the fix goes.

16.11.4 Controls: Boundary Checks and Library Updates

Q: What technical control do you suggest so that out-of-memory reads cannot happen? A: Boundary checks: as soon as they are put in place, if any message asks for something beyond the memory boundary, it should be ignored. In addition, the open-source library was updated with all the latest fixes, and memory checks are in place.

Formalize — two layers of defense. The professor's answer names two controls with different jobs:

Bounds checking (technical, in-code): validate every length claim before trusting it — any message that asks for something beyond the memory boundary is ignored rather than answered. This is the fix that closes the specific flaw.
Library updates (supply-chain hygiene): the open-source library was updated with all the latest fixes, and memory checks are in place. Because OpenSSL is a shared library, every system running the vulnerable version needed the update — one library patch, applied everywhere it is embedded.

The two layers of defense: fix the library (patch the flaw), and enforce bounds-checking behavior so malformed requests are dropped instead of answered.

Recap. OpenSSL = the open-source library that implements SSL/TLS encryption between parties. SSL is old generation; TLS (currently 1.2, later 1.3) is the current protocol. Heartbleed = an out-of-bounds memory read in the heartbeat echo: a modified echo message made the server answer with memory outside the requested bounds. Controls: boundary checks that ignore out-of-bounds requests, plus library updates with memory checks.

16.12 T-Mobile Breach: API Security

16.12.1 The Case: A Misconfigured API

Hook. A door left ajar for two months — not because someone broke the lock, but because the lock was never configured. The T-Mobile case is about what happens when an API is exposed before anyone secures it.

The T-Mobile data breach case: due to a misconfigured API, lots of customer information leaked. The breach occurred about two months before it was detected — a detection gap, not just a vulnerability gap.

Q: Can you give a crisp one-sentence summary of the case? A: Due to a misconfigured API, lots of customer information were leaked.

Q: What technical controls do you recommend? A: Proper authorization for the API, and proper detection — intrusion detection systems — to detect early, because the breach occurred two months prior to its detection.

Worked example — the two-month timeline. Map the T-Mobile exposure onto a timeline:

Month 0 — the misconfiguration: an API is deployed (or reconfigured) with the wrong settings, and customer information becomes reachable without proper authorization.
Months 0–2 — the silent window: the misconfigured API keeps leaking customer information. Nothing tests the runtime API, so nothing raises an alarm; the vulnerability gap is open.
Month ~2 — detection: the breach is finally detected — about two months after it began.
After detection: proper authorization is applied to the API, and detection controls (intrusion detection systems) are put in place so the next misconfiguration is caught early.

Sense-check: the damage was not done by the misconfiguration alone — it was done by the two-month detection gap. The fix is so two-sided: proper authorization closes the vulnerability, and IDS plus runtime testing closes the detection timeline.

Scope — the two gaps in the T-Mobile case. There are two distinct failures and they need two distinct fixes: (1) the vulnerability gap — the API was misconfigured, so customer information was reachable without proper authorization; the fix is proper authorization for the API. (2) The detection gap — the exposure ran about two months before it was detected; the fix is proper detection (intrusion detection systems) so the breach is caught early. A vulnerability that nobody notices is just as dangerous as a vulnerability that nobody fixes — the detection timeline decides how much damage is done.

16.12.2 API Governance and Visibility

Q: How exactly can you restrict the communication between APIs? A: The most important thing is visibility and governance of the API: know what APIs we are producing and who we are giving them to consume. It is an asset-management type of sequence — API asset management: how many we have created, who the consumers are, what is the frequency of consumption, what is the bandwidth of consumption, and what authentication mechanisms protect the consumption. This helps us control it and avoid misuse.

Formalize — the API asset management register. The professor's answer is a checklist that turns vague "API security" into concrete records. For every API, the organization must know:

Record	What it answers
Inventory count	How many APIs have we created? (no shadow APIs)
Consumers	Who is allowed to consume each API?
Call frequency	How often is it consumed? (unusual frequency = anomaly signal)
Bandwidth	How much data flows through it?
Authentication mechanisms	How is consumption protected? (what auth guards the calls)

The principle: you cannot protect what you cannot see. An API inventory with consumers, call frequency, bandwidth, and auth attached to each entry is the prerequisite for API security — and it is exactly the kind of record that would have shown the misconfigured T-Mobile API early.

16.12.3 API Testing Mechanisms

Q: What two security testing mechanisms do you recommend for API security? A: One is security auditing — a proper VA (vulnerability assessment) scan, so API vulnerabilities are detected. The other is runtime API testing: this vulnerability was open for about two months, so if they had run a runtime API check every now and then, it would have been detected much earlier.

Formalize — two mechanisms, two timescales.

VA scan (vulnerability assessment / security auditing): a scheduled scan of the API to detect vulnerabilities — a periodic audit that finds misconfigurations and known weaknesses.
Runtime API testing: testing the API as it runs, repeatedly — exercising live endpoints and monitoring behavior. Because this vulnerability was open for about two months, running a runtime API check periodically would have detected it much earlier.

The pair is complementary: the VA scan finds the flaw when you look for it; runtime testing finds the flaw because it keeps looking. Both would have caught the two-month exposure earlier — which is why the professor recommended both, not either.

16.12.4 Common API Vulnerabilities

Q: Can you list one or two API vulnerabilities you are aware of? A: Broken object level authorization, broken function level authorization, broken sensitive data exposure, and broken authentication. Just as web applications have the OWASP Top 10, API security has its own reference list — the OWASP API Top 10.

Pitfall — assuming authorization happens by default. The pattern across these vulnerabilities: most API failures are authorization failures — an API endpoint does not verify whether the caller is allowed to touch the object or the function it requests.

Broken object level authorization — the caller can read or modify an object (a record, a file) they have no right to, because the endpoint never checks ownership.
Broken function level authorization — the caller can invoke an administrative function (create a user, delete data) they have no right to.
Broken sensitive data exposure — the API returns sensitive data (personal information) without adequate protection — the exact T-Mobile pattern.
Broken authentication — the API's authentication can be bypassed or does not exist.

Remember: the OWASP API Top 10 is the reference list for APIs, just as the OWASP Top 10 is the reference list for web applications — an API endpoint that does not verify the caller's permission is the vulnerability.

Recap. T-Mobile: a misconfigured API leaked customer information for about two months — a vulnerability gap (fix: proper authorization) plus a detection gap (fix: intrusion detection systems and runtime testing). API security starts with visibility and governance: know your APIs, consumers, frequency, bandwidth, and auth. Test with VA scans plus runtime API testing; watch the OWASP API Top 10, where broken object and function level authorization dominate.

16.13 Microsoft AI Data Incident (2023): A 38-Terabyte Exposure

16.13.1 The Case: 38 Terabytes on GitHub

Hook. One ticked box, two months, 38 terabytes. The Microsoft AI case shows the smallest configuration error producing one of the largest silent exposures on record.

The Microsoft AI data incident of 2023: a leak of Microsoft's AI research team's entire source and training data on GitHub. Around 38 terabytes of private data were exposed. It was a configuration error that made the data publicly exposed; the exposure was exploited for a period of about two months, after which it was identified, reconfigured, and the error was mitigated.

Q: What was the incident? A: It was a leak of Microsoft's AI research team's entire source and training data on GitHub — about 38 terabytes of private data exposed. It was a configuration error which made it publicly exposed, and it was exploited for a period of around two months, after which it was identified, reconfigured, and the error was mitigated.

Worked example — the silent-breach timeline. Map the two-month exposure onto the incident-response timeline:

Configuration error: a repository's access setting is wrong — private data is made publicly exposed on GitHub. At this instant the breach begins, silently.
Exposure window (about two months): the data sits public. Nothing monitors the setting, so nothing alerts — the error is exploited during this period (anyone could download the source and training data).
Identification: after about two months, the exposure is identified.
Mitigation: the repository is reconfigured, the error is mitigated, and the data is secured.

Sense-check: the damage did not happen at step 1 — it compounded across step 2, the silent window. This is the same timeline pattern as T-Mobile (about two months between breach and detection): the detection gap, not the error itself, is what made the incident costly.

Real-world: one misconfiguration, one repository set public, and 38 terabytes of training data and source code sat exposed for two months — the silent-breach timeline pattern again.

16.13.2 Administrative Controls

Q: What is your recommendation to overcome this kind of vulnerability? A: This breach happened mainly because of missing administrative controls. There are various methods at the administrative or policy level: access controls, deauthorization, and timely auditing. Regular training of the people who handle different kinds of classified data should also be done — this was an oversight on the part of the employees of the organization.

Formalize — the administrative control package. The professor's answer names four administrative measures that would have prevented or shortened the exposure:

Control	What it does for this case
Access controls (policy level)	Define who may set repository visibility and who may view the data — so a single employee's action cannot make 38 TB public
Deauthorization	Actively remove access that is no longer justified — revoke stale permissions that let exposures persist
Timely auditing	Review configurations and permissions on a schedule — the audit that would have caught the public repository long before two months
Regular training	Train the people who handle classified data so that misconfiguration is recognized and avoided — the professor called it an oversight on the part of the employees

The classification lesson: not every failure is technical; this one was a governance and human-process failure that technical controls alone could not have fully prevented.

16.13.3 Technical Controls

Q: What technical controls can you implement? A: Multi-factor authentication, so data leakage becomes more controlled; regular monitoring, so an exposure is not exploited for over two months; and security training, so this does not happen further down the line.

Formalize — administrative and technical controls pair up. Compare the two answers from the case:

Layer	Controls	Role in this case
Administrative	Access controls, deauthorization, timely auditing, training	Set the policy: who may access, who may be deauthorized, when audits happen
Technical	MFA, regular monitoring	Enforce the policy: MFA makes data leakage more controlled (one stolen identity is not enough), monitoring detects the exposure instead of letting it run two months

Training closes the human gap in both. The pairing with the previous case: administrative controls set the policy, technical controls enforce it — and the two-month detection timeline is shortened by the monitoring (technical) that the auditing policy (administrative) requires.

Pitfall — the "all failures are technical" reflex. The first instinct is to recommend a technical fix, but the professor is explicit: this breach happened mainly because of missing administrative controls — a governance and human-process failure. A student who answers only "add MFA and monitoring" has named half the solution; the exam answer pairs the administrative package (access controls, deauthorization, timely auditing, training) with the technical package (MFA, monitoring), and identifies the root as employee oversight rather than a technical flaw.

Recap. Microsoft AI 2023: a configuration error publicly exposed about 38 terabytes of AI research source and training data on GitHub for about two months. Administrative controls (access controls, deauthorization, timely auditing, training) set the policy; technical controls (MFA, regular monitoring) enforce it. The lesson shared with T-Mobile: the detection timeline is what turns an error into an incident.

Exam Guidance Summary

The examination combines theoretical and practical knowledge — prepare both sides. This summary collects the recurring drill points from all thirteen cases.

Question style: viva-style questions stay at the basic level and stay within what each team documented, but the follow-ups probe reasoning: "which comes first, the incident or the breach?", "is that preventive or detective?" Prepare to defend the logic behind each definition, not just the definition.
Abbreviations to master: be clear about every abbreviation you use — CA (certificate authority) and the role of its signing key; CVE; SAST and DAST; RDP; SMB; SSO; JWT; DLP; IAM; MFA. For each: state the full form, the role, and where it appeared in the cases.
Port numbers: know the standard port numbers — SSH is 22, RDP is 3389. Know the main challenge in establishing an SSH connection (in this case, authentication interrupted mid-connection).
Control families and classes: know the three control families — physical, administrative, and technical — and be able to classify a control: preventive (DLP for exfiltration, firewalls), detective (monitoring, endpoint detection), recovery (backup). The classification drill ("preventive stops it, detective finds it, recovery restores after it") recurs across cases.
Security testing: SAST (static) and DAST (dynamic), the OWASP Top 10 for web applications, the OWASP API Top 10 for APIs, VA scans, and runtime API testing.
Terminology pairs: these recur and were drilled explicitly — incident versus breach, threat versus threat actor, virus versus malware, authentication versus authorization, need-to-know basis versus least privilege, backdoor versus malware, security incident versus privacy incident. For each pair, be ready to state the one-line difference and, where asked, the direction of the relationship.
Detection timelines: know the detection timelines in the cases — two months between breach and detection (T-Mobile, Microsoft AI), rising traffic on port 3389 before the BlueKeep vulnerability was known.
Attack chains: understand the attack chains — brute force plus token theft (Slack), one CRUD API plus SQL injection plus SSH or RDP pivot (Kaseya), misconfigured API (T-Mobile, Microsoft AI). Be ready to walk each chain step by step and name the control that breaks it.

Key Industry Applications

xz utils: a widely used Linux compression utility that carried inserted malicious code — a high-risk backdoor flagged by a Microsoft employee when SSH authentication misbehaved during a large file upload. Lesson: trust in widely deployed open-source tools converts supply-chain insertion into widespread access.
Slack security breach: employee single sign-on tokens stolen via brute force (missing rate limiting), then used against GitHub and other repository-hosting sites; JWT used for authorization in other contexts. Lesson: the token is the key — protect login endpoints with rate limiting and code audits.
Okta (October 2023): cloud IAM vendor; employee session tokens compromised; Auth0 and Active Directory integration; SSO's token weakness on display. Lesson: identity services are systemic — a service-level token compromise echoes into every client.
MOVEit Transfer: file transfer between organizations and applications; vulnerability CVE-2023-34362 exploited by a ransomware gang against a government body (NCSC); encryption plus exfiltration equals double extortion. Lesson: file-transfer tools concentrate data and are prime single points of failure.
Twitter breach: account takeover through phishing and spear phishing — social engineering in action. Lesson: the human is the attack surface; one click transfers authentication to the attacker.
WannaCry: untargeted ransomware that hit about 200,000–300,000 computers in about 150 countries through unpatched Windows systems; SMB as the sharing protocol involved. Lesson: patching discipline and defense in depth are what contain global-scale spread.
BlueKeep: Windows remote desktop vulnerability; RDP on port 3389; wormable malware propagation; discovered after security institutions saw port traffic rising and reported it to Microsoft. Lesson: anomaly observation on ports detects threats before they are named.
Kaseya VSA: supply-chain ransomware — one provider's vulnerability (single CRUD API, SQL injection, then SSH or RDP access) reached every customer; password salting and hashing named as current best practice. Lesson: backend design and credential storage decide how far one flaw spreads.
Heartbleed: OpenSSL heartbeat out-of-bounds memory read; TLS 1.2 as the current generation protocol. Lesson: a flaw in a shared encryption library is a flaw in everything that trusts it.
T-Mobile: customer data leaked through a misconfigured API; runtime API testing and API asset management as the fixes. Lesson: API governance and runtime testing shrink the detection gap.
Microsoft AI research: 38 terabytes of source and training data exposed on GitHub for about two months by a configuration error. Lesson: administrative controls and auditing are what catch configuration errors before they become incidents.
Tools and references: nmap (port scanning), Zabbix (network monitoring), DLP, intrusion detection systems, SAST and DAST tools, the NVD for CVE lookups, OWASP Top 10, OWASP API Top 10.

CS Lecture 16 notes · Case-Study Viva and Core Security Concepts

Cyber Security· postgraduate· 2026-08-16

Sections Breakdown

116.1 The xz Utils Backdoor: Backdoors, Malware, and SSH Basics

The xz utils case study: inserted malicious code acted as a hidden backdoor into Linux systems, exposed when SSH authentication was interrupted during a file upload. Distinguishes backdoor (hidden entry point) from malware (malicious code), explains private keys and certificate authorities, and pins SSH to port 22.

216.2 Slack Security Breach: Incidents, Tokens, and Brute Force

The Slack breach: employee single sign-on tokens stolen by brute force (missing rate limiting and code audit) and used against GitHub. Defines the incident-versus-breach hierarchy (all breaches are incidents, not vice versa), tokens as authentication with JWT authorization, the no-index and password-hash exposure weaknesses, SAST/DAST and the OWASP Top 10, and need-to-know versus least privilege.

316.3 Okta Incident (October 2023): Cloud Models, IAM, and SSO Risks

The Okta October 2023 incident: session tokens compromised at the identity service product level when an employee forgot to log off. Covers SaaS/PaaS/IaaS, the shared responsibility model (security in the cloud versus on the cloud), IAM, the Auth0 correction (separate platform offering SSO and MFA, integrates with Active Directory), SSO's token-based single point of failure, and the normal-account versus backdoor-account distinction via the admin API.

416.4 MOVEit Ransomware against a Government Body: Exfiltration and Double Extortion

Ransomware attack on a government body (NCSC) running MOVEit: files encrypted and data exfiltrated. Defines exfiltration (moving data out to attacker-controlled machines), classifies the controls against it (DLP primary preventive, monitoring detective, encryption incomplete), explains double extortion (two independent threats: deny decryption and expose data), and the dual security-plus-privacy nature of the exposure with third-party audit duties.

516.5 Twitter Breach: Social Engineering

The Twitter account-takeover breach via phishing and spear phishing. A credential breach is automatically both a security incident (confidentiality failure) and a privacy incident (victim's private authentication compromised). Social engineering targets people, not machines; phishing is a wide net, spear phishing is tailored to one individual.

616.6 WannaCry: Ransomware at Global Scale

WannaCry: untargeted ransomware that hit about 200,000-300,000 computers in some 150 countries by attacking every unpatched Windows desktop, spreading over the SMB protocol. Contrasts targeted normal ransomware with WannaCry, teaches the three control families (physical, administrative, technical), the preventive-detective-recovery classes (backup = recovery), SMB, patch cadence, and legacy systems.

716.7 Credential Stuffing: Nintendo Checker, Reverse Engineering, Remote Kill Switches

Credential stuffing replays leaked username/password pairs across other services, betting on password reuse. The Nintendo checker is attacker automation that checks many accounts at once. Reverse engineering deduces software logic by executing the application. A remote kill switch lets the attacker end the attack remotely leaving no traces; an application-based firewall at the application layer stops non-recognized behavior at the source.

816.8 MOVEit Breach: Ransomware Gangs, CVE Numbers, and Asset Inventory

The MOVEit breach viewed through the ransomware gang that exploited CVE-2023-34362. Defines ransomware gangs (encryption and/or exposure blackmail), CVE identifiers (Common Vulnerabilities and Exposures; year + sequence; NVD is the central repository), the authentication-versus-authorization distinction, server-level asset inventories with legitimate applications, vulnerability assessment and network monitoring (nmap port scanner, Zabbix monitoring, traffic patterns as the MOVEit detection lever), and SQL injection with an always-true query bypass.

916.9 BlueKeep: RDP, Threat versus Threat Actor, Virus versus Malware

BlueKeep: a Windows RDP vulnerability discovered when security institutions observed rising traffic on port 3389 and reported it to Microsoft (anomaly-driven detection). RDP = remote desktop protocol on port 3389. Threat is the potential danger; threat actor is the one carrying it out. Virus = malware needing user interaction to spread; wormable malware self-propagates across the network. Organizations collaborate via CVE publication and shared incident reports.

1016.10 Kaseya Ransomware: Supply Chain Attacks

Kaseya ransomware as a supply chain attack: the vulnerability lived in the provider's VSA (virtual system administrator) software, reaching every customer without targeting them individually, versus WannaCry's direct attack on systems. The chain: single CRUD API -> SQL injection -> data theft -> SSH/RDP pivot -> ransomware. Fixes: specific APIs, need-to-know access matrix, hashed and salted passwords, MFA.

1116.11 Heartbleed and OpenSSL

Heartbleed: an out-of-bounds memory read in OpenSSL's heartbeat echo feature — the echo message was modified to make the server answer with memory contents outside the requested bounds. OpenSSL is the library implementing SSL/TLS; SSL is the old generation and TLS (1.2 at the time, 1.3 later) is the current protocol. Controls: boundary checks ignoring out-of-bounds requests plus library updates.

1216.12 T-Mobile Breach: API Security

T-Mobile breach: a misconfigured API leaked customer information for about two months — a vulnerability gap (proper authorization) plus a detection gap (intrusion detection systems). API security starts with visibility and governance (API asset management: count, consumers, frequency, bandwidth, auth). Testing: VA scans plus runtime API testing. Vulnerabilities: broken object/function level authorization, sensitive data exposure, broken authentication — the OWASP API Top 10.

1316.13 Microsoft AI Data Incident (2023): A 38-Terabyte Exposure

Microsoft AI incident 2023: a configuration error publicly exposed about 38 terabytes of AI research source and training data on GitHub for about two months. Administrative controls (access controls, deauthorization, timely auditing, training) failed; recommendations pair the administrative package with technical controls (MFA, regular monitoring). The two-month detection timeline mirrors T-Mobile.

14Exam Guidance Summary

Viva-style exam guidance: theoretical and practical preparation, abbreviations (CA, CVE, SAST, DAST, RDP, SMB, SSO, JWT, DLP, IAM, MFA), standard port numbers (SSH 22, RDP 3389), the three control families and preventive-detective-recovery classes, SAST/DAST plus OWASP Top 10 references, terminology pairs, detection timelines, and attack chains from the cases.

15Key Industry Applications

Real-world applications of all thirteen cases: xz utils, Slack, Okta, MOVEit (government and gang angles), Twitter, WannaCry, BlueKeep, Kaseya VSA, Heartbleed, T-Mobile, and Microsoft AI research, plus tools and references (nmap, Zabbix, DLP, IDS, SAST/DAST, NVD, OWASP lists).

Postgraduate students in Cyber Security

Exam Revision Notes

Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.

16.1 The xz Utils Backdoor: Backdoors, Malware, and SSH Basics

Must-know: A backdoor is a hidden entry point bypassing security checks; malware is the malicious code itself. CA = certificate authority, the trusted third party whose signing key (its private key) signs certificates vouching for public keys. SSH uses port 22.

⚠️ Top pitfall: Calling a backdoor 'a vulnerability in existing code' mixes it up with vulnerability; a backdoor is the hidden entrance, not the weakness.

Self-check: Which port does SSH use, and what is the main challenge noted in establishing an SSH connection?

Connects to: 16.3, 16.9

16.2 Slack Security Breach: Incidents, Tokens, and Brute Force

Must-know: All breaches are security incidents but not all incidents are breaches; incident comes first. Brute force succeeded because rate limiting was missing and security code was not audited. SAST = static, DAST = dynamic application security testing; OWASP Top 10 is the web vulnerability reference list.

⚠️ Top pitfall: Saying 'the breach will turn into a security incident' reverses the hierarchy — an incident escalates into a breach, never the reverse.

Self-check: Which comes first, the incident or the breach, and why?

Connects to: 16.1, 16.8

16.3 Okta Incident (October 2023): Cloud Models, IAM, and SSO Risks

Must-know: Cloud models: SaaS, PaaS, IaaS. Shared responsibility: provider secures infrastructure (security in the cloud), client secures accounts/access/data (security on the cloud). SSO's main disadvantage: reliance on tokens — a breached token reaches the whole application. Backdoor account = unintended capability, possible due to insufficient testing and missing MFA.

⚠️ Top pitfall: Assuming Auth0 is part of Okta because both are IAM; they are separate platforms offering the same feature family (SSO, MFA).

Self-check: What is the shared responsibility split for SaaS, and why is SSO's reliance on tokens its main disadvantage?

Connects to: 16.1, 16.2

16.4 MOVEit Ransomware against a Government Body: Exfiltration and Double Extortion

Must-know: Exfiltration = moving data out to attacker-controlled machines. DLP is the primary preventive control; monitoring is detective; encryption alone does not stop data moving out. Double extortion = encryption threat plus exfiltration threat, so backups defeat only the first lever.

⚠️ Top pitfall: Classifying monitoring as preventive — it detects data leaving but does not stop it; the preventive control is DLP.

Self-check: Why does a perfect backup strategy fail against double extortion?

Connects to: 16.2, 16.6, 16.8

16.5 Twitter Breach: Social Engineering

Must-know: Social engineering is a hacking technique targeting people; phishing is broad and untargeted, spear phishing is tailored to one individual after studying their behavior. A breach involving the victim's own authentication is both a security incident and a privacy incident.

⚠️ Top pitfall: Treating social engineering as non-technical — it is carried out through technology (emails, messages, links); the human is the target.

Self-check: Why is a credential breach automatically a privacy breach as well as a security breach?

Connects to: 16.2, 16.4

16.6 WannaCry: Ransomware at Global Scale

Must-know: Three control families: physical, administrative, technical. Non-technical control = administrative (training and awareness, backup-recovery practice). Classes: preventive stops it, detective finds it, recovery restores after it (backup = recovery). WannaCry was untargeted at global scale; normal ransomware is one-to-one.

⚠️ Top pitfall: Calling patch updates the non-technical control — patching is technical; the administrative/non-technical answer is training and awareness.

Self-check: Is regular backup a preventive, detective, or recovery control, and which control family does training and awareness belong to?

Connects to: 16.4, 16.8, 16.9

16.7 Credential Stuffing: Nintendo Checker, Reverse Engineering, Remote Kill Switches

Must-know: Credential stuffing = trying leaked username/password pairs on other services, betting on reuse. Nintendo checker = automation checking multiple accounts at once. Reverse engineering = deduce logic by executing the software. Remote kill switch = remotely end the procedure leaving no traces; application-based firewall operates at the application layer.

⚠️ Top pitfall: Forgetting the kill switch's signature property: it remotely ends the attack so that no traces remain on the compromised machine.

Self-check: At which OSI layer does an application-based firewall work, and why does that help stop non-recognized network behavior?

Connects to: 16.2, 16.6

16.8 MOVEit Breach: Ransomware Gangs, CVE Numbers, and Asset Inventory

Must-know: CVE = Common Vulnerabilities and Exposures, a public standardized identifier (year + sequence, e.g., CVE-2023-34362); NVD is the central repository. Authentication = proving who you are (username/password/OTP); authorization = what you are allowed to do. Asset inventory at the server level identifies authorized and unauthorized software. Traffic patterns detect MOVEit-style attacks; nmap scans ports, Zabbix monitors traffic.

⚠️ Top pitfall: Calling username and password the 'authorization' — they are authentication; authorization is the set of allowed actions after identification.

Self-check: In CVE-2023-34362, what do CVE and the number parts mean, and where are these centrally available?

Connects to: 16.2, 16.4, 16.9, 16.10

16.9 BlueKeep: RDP, Threat versus Threat Actor, Virus versus Malware

Must-know: RDP = remote desktop protocol, runs on port 3389. Threat = potential danger/harmful event; threat actor = the hacker or organization carrying out the attack. Virus = a kind of malware needing user interaction (attached file); wormable malware spreads across the network with no user interaction.

⚠️ Top pitfall: Equating virus and malware: all viruses are malware but not all malware is a virus — the spreading mechanism (user interaction vs network self-propagation) is the differentiator.

Self-check: What is the difference between a threat and a threat actor, and why was BlueKeep called wormable?

Connects to: 16.1, 16.6, 16.8

16.10 Kaseya Ransomware: Supply Chain Attacks

Must-know: Supply chain attack = attacking end users through a vulnerability in the provider's software (Kaseya VSA), versus WannaCry's direct attack on systems. Root flaw: one API for all CRUD operations enabled SQL injection, data theft, then SSH/RDP pivot and ransomware. Recommendations: specific APIs per operation, need-to-know access matrix, hashed and salted passwords, MFA.

⚠️ Top pitfall: Calling a supply chain attack a direct attack: the difference is the level attacked — provider software versus end systems.

Self-check: What was the root backend flaw in the Kaseya case and how did the attack chain proceed from it?

Connects to: 16.6, 16.8, 16.9

16.11 Heartbleed and OpenSSL

Must-know: OpenSSL = the open-source library implementing SSL/TLS; SSL is the old generation, TLS (in use on version 1.2, later 1.3) is current. Heartbleed = out-of-bounds memory access where the heartbeat echo message was modified to gain information beyond the memory bounds. Controls: boundary checks that ignore out-of-bounds requests and library updates.

⚠️ Top pitfall: Calling Heartbleed an OS-specific flaw or a network-layer issue — it is an application-level vulnerability in the TLS protocol implementation, not tied to one OS.

Self-check: How did the modified heartbeat echo cause an out-of-bounds memory read, and what control prevents it?

Connects to: 16.1, 16.9

16.12 T-Mobile Breach: API Security

Must-know: T-Mobile: misconfigured API leaked customer information for about two months. Two gaps: vulnerability (fix: proper API authorization) and detection (fix: IDS, runtime testing). Restrict APIs via visibility and governance (API asset management). Testing: VA scan plus runtime API testing. Know the OWASP API Top 10 vulnerabilities.

⚠️ Top pitfall: Fixing only the misconfiguration and skipping detection: the two-month detection gap shows a vulnerability unnoticed is as dangerous as one unfixed.

Self-check: What two security testing mechanisms were recommended for the T-Mobile API, and what would each have caught?

Connects to: 16.3, 16.8

16.13 Microsoft AI Data Incident (2023): A 38-Terabyte Exposure

Must-know: Microsoft AI 2023: configuration error exposed ~38 TB of source and training data on GitHub for ~two months. Root cause: missing administrative controls (access controls, deauthorization, timely auditing, training). Technical controls: MFA and regular monitoring. Administrative sets policy, technical enforces it.

⚠️ Top pitfall: Answering with technical controls only: the professor classified the root cause as an administrative/governance failure (employee oversight), with technical controls as the enforcement layer.

Self-check: Why did the professor classify this as mainly a failure of administrative controls, and what technical controls pair with them?

Connects to: 16.6, 16.12

Exam Guidance Summary

Must-know: Know abbreviations with full forms and roles; port numbers (SSH 22, RDP 3389); three control families (physical, administrative, technical) and three classes (preventive, detective, recovery); terminology pairs; detection timelines (two months for T-Mobile and Microsoft AI; port 3389 traffic before BlueKeep); attack chains (Slack, Kaseya, T-Mobile/Microsoft AI).

⚠️ Top pitfall: Using abbreviations without knowing what they stand for and what the role of each is.

Self-check: What is the classification of DLP, monitoring, and backup with respect to preventive, detective, and recovery?

Connects to: 16.1, 16.2, 16.3, 16.4, 16.6, 16.9, 16.12, 16.13

Key Industry Applications

Must-know: For each case: the tool/vendor, the vulnerability or attack type, the failure chain, and the lesson (patching, DLP, MFA, API governance, administrative controls).

⚠️ Top pitfall: Memorizing case names without the underlying control lesson each case demonstrates.

Self-check: Which cases share the two-month detection timeline, and what control shortens it?

Connects to: 16.1, 16.2, 16.3, 16.4, 16.5, 16.6, 16.7, 16.8, 16.9, 16.10, 16.11, 16.12, 16.13

Previous LectureLecture 15 · Cybersecurity Incident Case Studies

Next LectureLecture 01 · Data Management for Machine Learning: Foundations and Data Representation

Was this lecture useful?

Loading comments…

🤖

BitsNotes AI Assistant

Subject Notes Assistant

Configure AI Chat

Choose how to access the chatbot

Have your own API key?

Switch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.

AI Provider Preset

API Endpoint URL (OpenAI-Compatible)

API Key

Model Name

🔑 Enter API key above to fetch live models from provider, or enter model name manually.

Remember key for this session (until tab closes)

OpenAI-Compatible API Support

Choose any provider preset (Gemini, DeepSeek, Kimi, GLM, MiniMax, Qwen, OpenAI, Groq, Ollama, etc.) or enter a custom endpoint URL.

Security & Privacy First

Your API key is sent directly from your browser to your specified provider. BitsNotes servers never store or see your key.

Prerequisite Knowledge

Previously Covered in This Subject

16.1 The xz Utils Backdoor: Backdoors, Malware, and SSH Basics

16.1.1 The Case: Malicious Code in a Trusted Linux Utility

16.1.2 Backdoor versus Malware

16.1.3 Private Keys and Certificate Authorities

16.1.4 SSH and Standard Port Numbers

16.1.5 Exam Notes

16.2 Slack Security Breach: Incidents, Tokens, and Brute Force

16.2.1 The Case: Employee Tokens and GitHub Access

16.2.2 Security Incident versus Breach

16.2.3 Tokens: Authentication versus Authorization

16.2.4 The Failed Control: Brute Force without Rate Limiting

16.2.5 Password Exposure and the No-Index Problem

16.2.6 Security Testing: SAST and DAST

16.2.7 Need-to-Know Basis versus Least Privilege

16.2.8 Exam Notes

16.3 Okta Incident (October 2023): Cloud Models, IAM, and SSO Risks

16.3.1 The Case: Tokens Compromised at the Service Level

16.3.2 Cloud Service Models and Shared Responsibility

16.3.3 IAM, Auth0, and Active Directory

16.3.4 Single Sign-On and Its Weakness

16.3.5 APIs and the Backdoor User Account

16.3.6 Exam Notes

16.4 MOVEit Ransomware against a Government Body: Exfiltration and Double Extortion

16.4.1 The Case: Encrypted and Exfiltrated

16.4.2 Exfiltration and the Controls against It

16.4.3 Double Extortion

16.4.4 Security Incident and Privacy Incident at Once

16.4.5 Exam Notes

16.5 Twitter Breach: Social Engineering

16.5.1 The Case: An Account Takeover

16.5.2 Security Breach, Privacy Breach, or Both

16.5.3 Social Engineering: Phishing versus Spear Phishing

16.6 WannaCry: Ransomware at Global Scale

16.6.1 The Case: Global Scale

16.6.2 Normal Ransomware versus WannaCry

16.6.3 Non-Technical Controls: The Administrative Family

16.6.4 SMB, Patch Frequency, and Legacy Systems

16.6.5 Defense in Depth and Recovery Controls

16.6.6 Exam Notes

16.7 Credential Stuffing: Nintendo Checker, Reverse Engineering, Remote Kill Switches

16.7.1 The Case: Credential Stuffing

16.7.2 The Nintendo Checker

16.7.3 Reverse Engineering

16.7.4 Remote Kill Switch and Endpoint Controls

16.8 MOVEit Breach: Ransomware Gangs, CVE Numbers, and Asset Inventory

16.8.1 The Case: MOVEit and the Ransomware Gang

16.8.2 Ransomware Gangs

16.8.3 CVE Numbers and Central Vulnerability Databases

16.8.4 Authentication versus Authorization

16.8.5 Asset Inventory and Legitimate Applications

16.8.6 Vulnerability Assessment and Network Monitoring

16.8.7 SQL Injection

16.9 BlueKeep: RDP, Threat versus Threat Actor, Virus versus Malware

16.9.1 The Case: BlueKeep and Port 3389

16.9.2 RDP

16.9.3 Threat versus Threat Actor

16.9.4 Virus versus Malware

16.9.5 Collaboration through CVE and Incident Reports

16.10 Kaseya Ransomware: Supply Chain Attacks

16.10.1 The Case: A Supply Chain Attack

16.10.2 Supply Chain Attacks versus Direct Attacks

16.10.3 What Went Wrong and How to Fix It

16.11 Heartbleed and OpenSSL

16.11.1 The Case: A Flaw in the Heartbeat

16.11.2 OpenSSL and the Move to TLS

16.11.3 Heartbleed: Out-of-Bounds Memory

16.11.4 Controls: Boundary Checks and Library Updates

16.12 T-Mobile Breach: API Security

16.12.1 The Case: A Misconfigured API

16.12.2 API Governance and Visibility

16.12.3 API Testing Mechanisms

16.12.4 Common API Vulnerabilities

16.13 Microsoft AI Data Incident (2023): A 38-Terabyte Exposure

16.13.1 The Case: 38 Terabytes on GitHub

16.13.2 Administrative Controls

16.13.3 Technical Controls

Exam Guidance Summary

Key Industry Applications