Malicious activity in applications and cloud services

Why this matters

CS0-004 added cloud emphasis for a reason: a growing share of intrusions never touch a corporate endpoint or cross a corporate network. They happen against a web application, through an API, or inside a cloud control plane using stolen credentials.

The analytical habits from the previous two lessons still apply, but the evidence lives somewhere new and the vocabulary changes. This lesson is about reading application and cloud logs with the same suspicion you would bring to a process tree.

The lesson

Web application attack signatures in logs

A web server log is a record of requests, and attacks against web applications have recognisable shapes in that record.

SQL injection appears as SQL syntax inside parameters: quotes, OR 1=1, UNION SELECT, comment markers, SLEEP or WAITFOR DELAY for blind timing attacks. The timing variants are worth special attention because they produce slow responses rather than errors, and error-based detection misses them entirely.

Cross-site scripting shows as script tags, event handlers such as onerror=, or javascript: URIs in parameters — usually URL-encoded, often several times over, which is itself a signal.

Path traversal shows as ../ sequences, their encoded forms, or absolute paths to sensitive files.

Command injection shows as shell metacharacters — semicolons, pipes, backticks, $( ) — followed by recognisable commands.

File upload abuse shows as a POST to an upload endpoint followed by a request to the uploaded file. That second request is the important one: the upload alone may be benign, but fetching it executes it. A subsequent web shell produces the ancestry signature from the previous lesson — the web server process spawning a shell.

What to read in the log beyond the payload:

• Status codes in sequence. A run of 404s and 500s followed by a 200 is someone finding what works.
• Response sizes. A 200 with an unusual size on an endpoint that normally returns a fixed page suggests it returned something it should not.
• User agents. Scanner defaults are obvious; absent or malformed agents are suspicious.
• Request rate and ordering. Humans browse; tools enumerate alphabetically or by wordlist.

A caution worth carrying: a request in the log is an attempt, not a success. The exam distinguishes these, and so should you — attempted injection blocked by a WAF is a very different finding from injection that returned data.

API abuse, enumeration and credential stuffing

APIs are now the dominant interface, and they fail differently from web pages.

Enumeration walks identifiers to discover what exists: sequential IDs, username checks, or endpoints that respond differently for valid and invalid values. The signature is many similar requests with one changing parameter, and a mixture of success and not-found responses.

Broken object-level authorisation — requesting another user's object by changing an identifier — is the most common serious API flaw. In logs it looks like an authenticated user accessing a range of object IDs, most of which are not theirs. Crucially the requests are authenticated and successful, which means nothing fails and nothing errors. Only the pattern gives it away.

Credential stuffing replays username and password pairs from other breaches. Its shape:

• High volume of authentication attempts across many different accounts, each tried once or twice — the opposite of brute force against one account.
• A low but non-zero success rate, because reused passwords do work.
• Distributed source addresses, often residential proxies, defeating simple rate limits.
• Consistent client fingerprints across supposedly unrelated users.

Password spraying is the sibling: one common password against many accounts, staying under per-account lockout thresholds. Detect it by counting distinct accounts attempted per source rather than failures per account, which is the counting mistake most lockout-based thinking makes.

Also worth watching: rate-limit responses (429s) in bulk, tokens used from many addresses simultaneously, and sudden use of an API version or endpoint that had been dormant.

Cloud control-plane events: who changed what

This is the heart of cloud detection, and the idea that matters most in this lesson: the control plane is a separate attack surface from the network.

An attacker with a valid cloud credential can enumerate the environment, grant themselves permissions, copy data and create infrastructure — all through API calls that generate no interesting network traffic whatsoever. Flow logs will show nothing. The audit log is the entire story.

Events that deserve attention:

• Identity and permission changes: new users, new access keys, new roles, policy attachments, trust relationship changes. Privilege escalation in cloud is usually a permissions change rather than an exploit.
• New access keys created for an existing user, especially a privileged one — the cloud equivalent of adding your own MFA method.
• Security control changes: audit logging disabled, a trail stopped, alerts deleted, guard services turned off. An attacker turning off logging is both a strong signal and a race against your retention.
• Storage access changes: a bucket or container made public, policies loosened, encryption removed.
• Snapshot and image activity. Taking a snapshot of a disk and sharing it to an external account is data theft that never looks like a download.
• Resource creation in unused regions, a classic cryptomining and staging pattern.
• Enumeration bursts: many List* and Describe* calls in quick succession, which is what tooling does on arrival.

Two details make cloud analysis harder and are worth knowing. First, actions taken by an assumed role appear under the role, so tracing back to the human requires following the assumption chain. Second, an action performed by an automation pipeline looks identical to the same action performed by an attacker who stole the pipeline's identity — which is why unusual source address and unusual time matter so much when the actor is a service.

Container and workload indicators

Containers add their own vocabulary, and a few indicators recur:

• A container running as root when it does not need to, or with privileged flags and host mounts. Mounting the host file system or the container runtime socket is effectively a request for host access.
• A shell inside a running container. Containers are usually built to run one process; an interactive shell is either a human debugging or an intruder.
• Unexpected outbound connections from a workload, particularly to mining pools or unfamiliar registries.
• An image pulled from an unapproved registry, or an image tag that changed without a deployment.
• Package installation at runtime. Containers should be immutable; a running container installing tools is a strong signal.
• Access to the cloud metadata service from a workload that has no reason to need credentials — a very common path from a compromised application to a cloud identity.

Orchestration adds more: service account token use from outside the cluster, role bindings granted broadly, and workloads scheduled into namespaces they do not belong in.

SaaS audit logs and the blind spots in them

SaaS applications hold a great deal of the organisation's data and give you whatever logging the vendor chose to provide.

Events worth collecting where available:

• Sharing and permission changes, especially links made public or shared externally.
• Mass download or export, the SaaS form of exfiltration.
• Mailbox rules, particularly ones that forward externally or delete messages — the signature of business email compromise, quietly hiding the replies.
• OAuth application consent grants, which give durable, password-independent access.
• Administrative changes: new admins, disabled security policies, altered retention.
• Data loss prevention triggers, which are findings in their own right.

The blind spots are real and you should know them for the exam:

• Logging is often a premium feature. The tier the organisation bought may simply not produce the events you need.
• Retention is frequently short — sometimes 30 days or less — and cannot be extended retrospectively.
• Granularity varies wildly. Some vendors log a file access; others log only a session.
• Export may be manual, meaning the data is not in your SIEM when you need to correlate at speed.
• Latency. Some SaaS audit events appear hours after the fact, which breaks real-time detection and confuses timelines.

The practical response is to find out before an incident which of your SaaS platforms can answer questions and which cannot, and to say so plainly in the risk conversation. A platform holding critical data with 30-day logs is a constraint on every future investigation, and that is a finding worth reporting in exactly the terms of the reporting lessons at the end of this course.

Topics this lesson owns

• [x] Web application attack signatures in logs
• [x] API abuse, enumeration and credential stuffing
• [x] Cloud control-plane events: who changed what
• [x] Container and workload indicators
• [x] SaaS audit logs and the blind spots in them