In the previous lesson you laid out the map: the domains of the discipline, the frameworks that organise it and — above all — the life cycle of an attack. Now we are going to fill that skeleton with content. This lesson works through the technical attacks executed against systems like Nimbus Reservas', ordered by the phase of the chain in which they appear: how the adversary gathers information, how it attacks the network, how it obtains credentials, how it exploits a web application, how it deploys ransomware or compromises a supply chain, and how it abuses an API. For each one you will see what it is, a minimal, conceptual example on the Nimbus architecture, how it is detected and where its defence points. The approach is defensive throughout: the examples are illustrative, minimal and always accompanied by their fix. Knowing the attack is not an end in itself, it is the prerequisite for designing the defence.

1. How this catalogue is organised, and a warning first
2. Phase 1 — Reconnaissance: OSINT and scanning
3. Network attacks: eavesdropping, spoofing and interception
4. Denial of service: volumetric and application-layer
5. Credential and session attacks
6. Web application attacks: the OWASP Top 10 as a framework
7. Malware in action: modern ransomware and double extortion
8. Supply chain attacks
9. API-specific attacks
10. A chained attack on Nimbus, step by step
11. Summary table: attack, property affected, detection and defence

A catalogue of attacks without structure is a list nobody can remember. That is why we use the axis you already know — the Kill Chain phases — and add a second reading key: which property of the CIA triad each attack breaks, the one you established in 01-01.

A necessary warning. Everything that follows is written in order to defend. You will not find ready-to-use attack tooling here, nor working malware code, nor instructions applicable to third-party systems. The examples are minimal fragments on the fictitious Nimbus environment, always with their fix alongside. Running any of these techniques against systems that are not yours, without express written authorisation, is a crime; the legal and ethical framework for authorised testing is covered in 06-06, and the methodology of penetration testing in 05-03.

Reconnaissance is the phase organisations ignore because it leaves no trace in their systems: a good part of it happens without touching them.

What it is. Gathering publicly available information about the target. Nothing is exploited; what the organisation has published without realising it is simply read.

What an attacker finds about Nimbus without touching a single server:

How to defend against it. You cannot stop somebody reading what is public, but you can reduce what gets published unintentionally:

• Periodically review the subdomains that appear in certificate transparency and withdraw those that no longer exist (this is the finding from exercise 3 of the previous lesson).
• Scan the history of the repositories for secrets — deleting the file is not enough: in Git it is still in the history — and rotate any exposed credential.
• Strip metadata from published documents.
• Assume the team's list of e-mail addresses is public. The defence is not to hide it, it is MFA and training (02-03, 02-05).

What it is. Actively contacting the target's systems to discover what is there: which IPs answer, which ports are open, which services and versions run, which routes exist in the web application.

Unlike OSINT, scanning does leave a trace. And here is the asymmetry that matters for an SME: Nimbus is already being scanned continuously by bots that have no idea what it is. Telling targeted scanning apart from the background noise is hard; what is feasible is to look out for slow, methodical scans from a single source, which suggest real interest.

How to read this extract:

• Six requests in six seconds from the same IP, all to routes that do not exist at Nimbus. It is an automated scanner working through the usual catalogue.
• /wp-login.php and /phpmyadmin/ give away that the bot has no idea what technology Nimbus uses: it tries everything. This is the opportunistic attack from 01-04 in its purest form.
• The most valuable defensive signal is not in the 404s, but in the day one of them returns a 200. That is why the useful alert is not "we are being scanned" (you always are), but "a sensitive route has returned something other than a 404".

Discovery and scanning tools are covered in 05-01 and 05-03. What matters here is the concept and its defensive counterpart: every service you do not expose is a service that appears in no scan at all.

These attacks go after the channel, not the endpoints. They share one premise: if the attacker manages to get in the middle or to listen in, the security of the endpoints stops being enough.

That is the right question. Properly implemented TLS makes passive eavesdropping useless: the attacker sees encrypted traffic. But three real gaps remain at Nimbus:

1. Internal traffic that is not encrypted. In the 01-04 DFD, flow F3 (load balancer → API) was internal HTTP. Anyone who reaches that network reads it in the clear. This is the reason for the Zero Trust principle: the internal network is not trusted.
2. Metadata is still visible. Even with encrypted content, an observer sees which domains you connect to, when and at what volume. The DNS lookup beforehand usually travels in the clear.
3. Downgrade and user error. If a Nimbus laptop accepts an invalid certificate with one click, TLS stops protecting. That is why HSTS exists (we will see it in 02-04) and why clients must refuse, not ask.

Minimal example of the classic mistake in the Nimbus code:

Why verify=False is so serious and so common: it turns off the check that the certificate presented really does correspond to the domain and is signed by a recognised authority. The traffic is still encrypted, which gives a false sense of security, but encrypted against the attacker if the attacker has interposed themselves. It almost always appears as a temporary patch in a test environment and ends up in production. Practical rule: verify=False must not exist in any repository; if an internal certificate causes trouble, the answer is to add the internal authority to the trust store, not to disable verification. Static analysis in CI (02-04) picks it up automatically.

The objective is availability: stopping Nimbus's customers from using the service. For a SaaS that clinics' live diaries depend on, an hour of downtime has an immediate and visible cost.

The most dangerous for Nimbus is the third, and it is the most underestimated. Remember the unpaginated reports endpoint that broke availability in 01-01: 20 well-chosen requests can bring the API down, whereas a volumetric DDoS requires a botnet. Defence against the volumetric kind is bought (the provider's anti-DDoS service); defence against the application-layer kind is programmed.

The four defences that appear here, explained:

1. Type validation (date_from: date instead of str): rejects malformed input before it reaches the database.
2. Business limit (92 days): a ten-year occupancy report is not a legitimate use case. Business limits are more effective than technical ones because they can be defended to the customer.
3. Pagination with LIMIT: bounds the memory and the time of each request, whatever happens.
4. Rate limit (5/minute): bounds how many times that cost can be paid. Without it, the other three limits only force the attacker to repeat more often.

Detection: average API latency shooting up with little inbound traffic, slow PostgreSQL queries concentrated on one endpoint, and a single user_id or token accounting for most of the consumption. In a volumetric DDoS these signals would be different: lots of traffic and network saturation.

Identity is today the dominant way in, because a valid credential sets off no alarm: no exploit, no malware, no protocol anomaly. Just somebody logging in.

It deserves special attention because it is designed to get around account lockout. If Nimbus locks out after 5 failed attempts per account, the attacker tries a single very common password against the team's 38 accounts, waits an hour and tries the next one. No account ever reaches 5 failures.

How to read it: four failures and one success, one attempt per account, the same IP, four seconds between each, at two in the morning. No account has reached the lockout threshold, and yet the attack has succeeded. Correct detection does not count failures per account but distinct failures per origin and the ratio between accounts attacked and accounts that exist. This is exactly the kind of rule built in 05-02.

The defence that neutralises it almost completely is phishing-resistant MFA, together with checking passwords against leaked lists. Both are developed in 02-05.

In the inventory you discovered a token for the nimbus-deploy-bot account with no expiry and with write permissions on every repository. A token like that has three properties that make it the perfect target:

• It does not expire: stealing it once is enough forever.
• It has no second factor: a token is the complete credential.
• It is in many places: in the CI configuration, on the laptop of whoever created it, perhaps in a .env file, perhaps in a chat history.

Its fix — short expiry, minimal scope, short-lived credentials from the CI itself and rotation — is detailed in 02-05.

The OWASP Top 10 is the list of the ten most widespread risk categories in web applications. It is not an exhaustive catalogue of vulnerabilities: it is a list of categories by frequency and impact, and that is why it works well as a review guide. We work through the ones most relevant to the Nimbus API.

It is the first category in the Top 10 by prevalence, and you already came across it in 01-01.

What it is. The system authenticates correctly ("I know who you are") but does not authorise correctly ("I am not checking that this is yours").

Variants of the same family worth recognising:

• Horizontal escalation: reaching the data of another user at the same level (the classic IDOR).
• Vertical escalation: a reception user obtains administrator functions because the control lives only in the interface and not on the server.
• Parameter tampering: sending {"role": "admin"} in the body of a profile update and having the server accept it because it does a mass assignment of fields.

Detection. It is hard from outside and easy from the audit trail: if the log records user, tenant and resource, a query looking for accesses where the resource's tenant does not match the user's finds the attempts. Without that log, it is invisible. This is why the auditing of 01-01 and 01-03 was not bureaucracy.

What it is. The user's data is concatenated into a query and the engine interprets it as an instruction rather than as data.

If text contains a quotation mark, the structure of the query changes. This conceptual example is enough: a value such as ' OR '1'='1 turns the search condition into an always-true condition, and the query returns all the rows the database role has access to. More advanced variants make it possible to read other tables or to infer data character by character from the response time (blind injection).

Why parameterisation really works and "manual escaping" does not: with parameters, the engine receives the structure of the query first and then the values, already as data. There is no content of text that can change the structure, because the structure is already fixed. Manual escaping, by contrast, depends on getting every combination of quotation marks, encodings and engine modes right: sooner or later it fails.

Second layer (the one that saves you when the first fails): the nimbus_api role from 01-03 has no DELETE, no DDL and cannot read payroll or gateway_keys. An injection with that role is serious, but bounded. And PostgreSQL's RLS additionally prevents it from returning another tenant's rows. Defence in depth in its purest form.

Detection: SQL errors in the application logs (a syntax error at or near is an unmistakable signal that somebody is probing), spikes of anomalously slow queries, and requests with quotation marks or SQL keywords in parameters that should never contain them. A WAF catches many attempts, but it does not replace parameterisation.

What it is. The attacker gets another victim's browser to execute code in the context of the Nimbus site. The victim is not the server: it is the user.

Minimal, conceptual example. The "notes" field of a booking accepts free text. If the SPA inserts it into the page without escaping, a text containing a <script> tag will execute in the browser of the clinic receptionist who opens that appointment. The impact is not "a pop-up window": it is that this code acts with the receptionist's session, and it can read the whole diary or perform actions in her name.

The three layers of defence against XSS, in order of importance:

1. Context-aware output encoding. The same data is escaped differently in HTML, in an attribute, in JavaScript or in a URL. Modern template engines and SPA frameworks do it by default; the problem appears when somebody deliberately turns it off (innerHTML, dangerouslySetInnerHTML, |safe).
2. Content-Security-Policy: a header telling the browser which origins it may load and execute code from. It turns many exploitable XSS flaws into failed attempts. Detailed in 02-04.
3. HttpOnly cookies: they stop JavaScript reading the session cookie, limiting direct theft. They do not stop the code acting on behalf of the user. Detailed in 02-05.

What it is. A malicious site makes the victim's browser, already authenticated at Nimbus, send an unwanted request. The browser attaches the session cookie automatically, so the request looks legitimate.

Example at Nimbus: a clinic administrator is authenticated in the panel and visits another page which, without her noticing, submits a form to POST /api/v1/usuarios/invitar to create a new user with permissions.

Defences, and why they have to be combined:

What it is. The attacker gets the Nimbus server to make a request to a URL of their choosing. It is especially dangerous in the cloud, because the server is inside the private network and can reach places nobody reaches from outside.

Example at Nimbus: a feature lets a clinic supply the URL of its logo for invoices, and the server downloads it. If it is not validated, the attacker can supply an internal address — the cloud provider's metadata service, an internal administration panel, localhost — and have the server fetch it on their behalf. The most serious case is access to the instance metadata service, which in older configurations can return temporary credentials for the cloud account (A-05).

The four decisions in the fixed code: HTTPS only (rules out file://, gopher:// and other schemes); resolving the name beforehand and checking that the IP does not fall in an internal range; not following redirects, because a redirect is the classic way of getting around the check; and a size limit so that the download does not turn into a denial of service. Even so, the definitive defence is architectural: have these requests go out through an egress proxy with an allowlist, and require the version of the metadata service that demands a token (covered in 05-07).

What it is. The application reconstructs objects from data that comes from outside. Some formats allow the reconstruction process to execute code.

The rule: pickle, yaml.load without SafeLoader and their equivalents in other languages must never be applied to data coming from outside. Use JSON and validate the schema. Validating with an explicit model additionally provides a defence against mass assignment of fields: only the three declared keys are accepted.

Less spectacular and very frequent. Common forms in an API like the Nimbus one:

• Returning more than necessary: a SELECT * that includes dni, internal_notes or hash_password, trusting the interface not to display them. The data travels to the client and is sitting in the browser.
• Verbose error messages: a full stack trace with the library version, the file path and even the SQL query.
• Logging what should not be logged: tokens, passwords or health data in the logs. Covered in 02-04.
• Objects accessible without authorisation: the attachments bucket (A-02) with no restrictive policy. You already solved this with the 120 s signed URLs in 01-03.

The Nimbus API drags along around 180 transitive Python dependencies. Iván has written a tiny fraction of the code that runs in production.

How to read it and what to do: each line is a known vulnerability with the version that fixes it. What matters is not the list, it is the process: that this command runs on every build, that it breaks the pipeline when something of high severity appears, and that there is an explicit commitment to a remediation deadline. An analysis nobody reads is worse than none at all, because it creates the feeling of being covered. The full CI yaml is in 02-04.

In 01-02 you saw the taxonomy of nine malware families. What matters here is how the one that does most damage to companies the size of Nimbus operates today.

What changed with respect to classic ransomware: it is no longer a file that encrypts a computer. It is a human-operated campaign, with several specialist groups involved, that lasts weeks and in which the encryption is the last step.

The three defensive conclusions that follow from this timeline:

1. There is a three-week window. Ransomware is not instantaneous: it is the visible conclusion of a long compromise. Every day of that window is a detection opportunity that Nimbus is currently wasting because nobody looks at the logs.
2. The backups are the objective, not collateral damage. The attacker actively looks for the backups and deletes them. That is why a backup accessible with the same credentials as production is not a backup: it is one more file that is going to be encrypted. The answer is immutability and separation of accounts (02-04, 04-06).
3. Paying does not solve the leak. Even if the ransom is paid and the data decrypted, the data has already left. For Nimbus, holding clinic appointment data, that means a breach notification regardless of whether service is restored. The concrete implications are covered in 06-03, and the payment decision is analysed in the Colonial Pipeline case in 02-06.

Legal note: paying ransoms has legal, tax and sanctions implications that vary with the jurisdiction and with the identity of the attacking group. Any decision in a real case must be taken with legal advice and with the competent authorities.

What it is. Instead of attacking Nimbus directly, the adversary compromises something Nimbus trusts and waits for Nimbus to install or run it. It is an attack of extreme efficiency: compromise one, reach thousands.

Why it is so hard to detect: all of the above looks legitimate. A dependency installed by pip from the official index, a CI action with a familiar name, a connection from the consultancy during working hours. There is no protocol anomaly to detect; only subsequent behaviour.

Defences applicable at Nimbus today:

• Pin exact versions and a lock file with checksums, so that the build is reproducible.
• Pin CI actions by commit hash, not by tag:

• Least privilege in CI: the build workflow should not have access to production secrets, and the secrets should be short-lived.
• Generate a component inventory (SBOM) so that "are we using the library that has just been in the news?" can be answered in minutes. It is the 01-04 inventory applied to software.

Treating the supplier as a manageable risk — assessment, contract, review — belongs to 04-04.

The Nimbus API (A-04) is its main surface: ~120 endpoints used by the SPA and the mobile app. API attacks are not always "vulnerabilities" in the classic sense; very often they are legitimate uses taken to the extreme.

The most underestimated point: business logic abuse. There is no technical vulnerability in booking and cancelling 200 appointments; the system does exactly what it was asked to do. No WAF, no static analysis and no scanner detects it, because nothing is malformed. It is only caught by business limits thought up by somebody who knows the domain, and by alerts on business metrics (an anomalous cancellation rate in one tenant). This is why security cannot be delegated entirely to tools.

Real attacks are not one technique: they are a chain in which each link takes advantage of the previous one. Let us reconstruct a complete one, connecting everything seen in this lesson.

Where this chain breaks, link by link:

The decisive observation: of the eight links, five break with measures that cost little or nothing — token expiry, minimal scope, tenant filtering, rate limiting and a volume alert. None requires buying a product. And link 6 was already broken in advance thanks to a design decision taken in 01-03: short-lived signed URLs. That is exactly what "defence in depth" means when it works.

Common mistakes:

• Studying attacks as a list of names. What has to be retained about each one is three things: which property it breaks, what signal it leaves and which control neutralises it. The name is the least of it.
• Believing HTTPS solves network attacks. It solves eavesdropping on external content. It does not cover internal traffic in the clear, nor metadata, nor the user who accepts an invalid certificate.
• Trusting input filtering to a blocklist. Trying to forbid ', <script> or UNION can always be evaded with encodings. The correct defence is structural: parameterise queries and encode on output.
• Thinking a WAF replaces correct code. A WAF is a useful layer that buys time; it does not fix an injection or a broken access control.
• Ignoring application-layer DDoS. Money goes into volumetric protection while a single unpaginated endpoint lets someone bring the service down from a laptop.
• Treating ransomware as an antivirus problem. It is a weeks-long operation whose outcome is decided by immutable backups, MFA and segmentation, not by the signature of the final file.
• Assuming dependencies are somebody else's problem. 95 % of the code running in production was not written by Iván, and the vulnerabilities in that 95 % are just as exploitable.
• Forgetting business logic. No tool detects the abuse of a feature that works exactly as it was designed to.

Tips:

• When you review an endpoint, ask yourself four questions in this order: who are you? (authentication), is it yours? (authorisation), is what you are sending valid? (validation) and how much does this cost? (limits).
• Search the Nimbus repository for these five patterns: verify=False, SELECT *, string concatenation in SQL, innerHTML and pickle.loads. You will find most of the application risk in under an hour.
• For every new attack you learn, write the log query that would detect it. If you cannot write it, you will not detect it.
• Practise the chain exercise: take any incident and ask yourself at which link it would have been cheapest to break it. Almost always it is one of the first.
• Remember that most successful attacks do not use exploits: they use valid credentials and forgotten configurations.

For each of these extracts or facts observed at Nimbus, state: which attack it suggests, which CIA property is at stake, what you would check next and which defence applies.

The following fragments are in the Nimbus code. For each one: identify the vulnerability, explain how it would conceptually be exploited, rewrite the fixed code and add a second layer of defence independent of the code.

Nimbus suffers the following incident:

1. Rubén receives an e-mail with an attachment claiming to be an issue report from a customer clinic. He opens it.
2. His laptop runs a component that establishes an outbound channel to the attacker.
3. The attacker extracts from Rubén's browser the session cookie for the internal support panel, which does not expire for 30 days.
4. With that cookie they enter the support panel without going through the log-in or the MFA.
5. From the support panel, which offers a "view as customer" feature, they reach the data of 40 clinics.
6. They export a CSV with 120,000 appointment records using the panel's export feature.
7. Three days later, the export appears published on a forum.

Required: (a) assign each step to its Kill Chain phase and to the technique from this lesson's catalogue; (b) give two controls per step that would have broken it; (c) explain why MFA did not protect at step 4 and which concrete measure would have done; (d) say at which step detection would have been easiest and what exact signal you would have looked for.

Solution 1

Solution 2

(a) Customer search box. Vulnerabilities: SQL injection through concatenation and excessive exposure through SELECT *. Conceptual exploitation: a value of q containing a quotation mark closes the string and allows conditions to be added, turning the filter into an always-true condition and returning the full contents of the table accessible to the role.

Second layer, independent of the code: the nimbus_api role with no DELETE and no DDL (01-03) and the RLS by tenant_id, which prevents other tenants' rows being returned even if the query is manipulated. The LIMIT 50 additionally adds protection against mass extraction, and the three-character minimum avoids the empty search that returns the whole database.

(b) Attachment download. Vulnerability: broken access control — any key in the bucket is downloaded without checking that the booking belongs to the user's tenant. It can also allow path traversal if the key contains ../. Conceptual exploitation: with a key known or guessed, any authenticated user downloads another clinic's attachment: a scanned medical report.

Key changes: the client no longer chooses the object key but the identifier of their booking; the real key is obtained from the database after ownership has been verified; a 120 s signed URL is handed over instead of serving the object; and the access is logged. Second layer: the bucket is private, the policy prevents anonymous access, and the API has no delete permission over it (01-03).

(c) Payment webhook. Vulnerabilities: spoofing (there is no check that the message comes from the gateway) and integrity tampering (anyone can mark invoices as paid). Conceptual exploitation: an HTTP request to that endpoint with a suitable JSON body turns an unpaid invoice into a paid one. It is the S threat of flow F8 in the 01-04 DFD.

Second layer: confirm the status against the gateway's API before accepting a financial operation as valid, and restrict the origin to the IPs published by the provider. HMAC is explained in detail in 03-04.

Solution 3

(a) and (b) Chain, techniques and controls:

(c) Why MFA did not protect. MFA is verified at the moment of log-in and produces a session. If the attacker steals the session already issued, they never go through authentication again: they walk straight in with a valid artefact. That is the essence of pass-the-cookie and the reason why "we have MFA" is not a complete answer.

What would have worked, in order of effectiveness:

1. Binding the session to a context (device, IP or client certificate), so that a cookie used from another machine is invalidated.
2. Short sessions with silent renewal: a 30-day cookie is a permanent credential in disguise. Hours, not weeks.
3. Reauthentication for sensitive operations: impersonating a customer or exporting data requires presenting the second factor again, even if the session is valid.
4. Cryptographically binding the token to the client (token binding / device-bound keys), which is the direction passkeys point in (02-05).

(d) Where to detect and what signal to look for. The easiest point is step 6: an export of 120,000 records spanning 40 different tenants is a quantitatively unique event in Nimbus's normal operation. The detection query is straightforward on the append-only audit table from 01-01:

What matters about this query is not its SQL but its premise: it only works if the audit trail records session_id, tenant_id and record_count. Detection is not improvised when the incident happens; it is designed when the log is written. A second useful signal, and an earlier one, is step 4: an active session with no preceding authentication event in the log is an anomaly with no legitimate explanation.

You now know the adversary in action. You have worked through the attacks ordered by the phases of the chain: the reconnaissance that happens without touching your systems — OSINT in certificates, repositories and job adverts — and the scanning that does leave a trace, with the practical lesson that the useful alert is not "we are being scanned" but "a sensitive route has stopped returning 404". You have seen the network attacks — eavesdropping, ARP and DNS spoofing, interception — and why they still matter in a world with HTTPS: because of internal traffic in the clear, because of metadata, and because of the verify=False somebody left in production. You have distinguished volumetric denial of service, whose defence is bought, from application-layer denial of service, whose defence is programmed, and you have seen that twenty well-chosen requests do more damage than a botnet when pagination is missing.

In credentials you have learned to tell apart brute force, dictionary attacks, password spraying — designed precisely to get around per-account lockout — credential stuffing and session theft, with the uncomfortable idea that a valid credential sets off no alarm. In web applications you have worked through the OWASP Top 10 on the Nimbus API: broken access control and IDOR, SQL injection and why parameterisation works where manual escaping fails, XSS with its three layers of defence, CSRF, SSRF and its route towards the cloud account's credentials, insecure deserialisation, data exposure and vulnerable dependencies. You have understood modern ransomware as a three-week operation whose outcome is decided by immutable backups, not by the antivirus; supply chain attacks, where everything looks legitimate; and API attacks, with the business logic abuse that no tool detects. And you have reconstructed a complete chain on Nimbus, confirming that five of its eight links break with measures that cost no money at all.

What is still missing is the vector that heads almost every set of statistics and that appears in none of the previous techniques: the person. In the next lesson, Social Engineering and Phishing (02-03), we will see why the human factor is the dominant way in, which principles of influence attackers exploit, the complete catalogue of techniques — from mass phishing to CEO fraud aimed at Sara, vishing, quishing and consent phishing —, how to take a malicious e-mail apart indicator by indicator by reading its headers, and the technical and process defences that counter it, starting with SPF, DKIM and DMARC.