Analyzing Indicators of Potential Malicious Activity

For example, suppose a finance workstation's CPU jumps to full load in the middle of the night and stays there, and soon after the same host sends a large volume of data to an address outside the company: each observation is an indicator, which the US National Institute of Standards and Technology (NIST) defines as a technical artifact or observable that suggests an attack is imminent or is currently underway, or that a compromise may have already occurred^[1]. The key word is suggests: the CPU spike could be mining malware or a legitimate batch job, and the upload could be data theft or the nightly backup. Reading indicators means turning that suggestion into a conclusion you can defend, and it rests on knowing what normal looks like. The joint guidance on living off the land attacks led by the Cybersecurity and Infrastructure Security Agency (CISA) tells defenders to establish and continuously maintain a baseline of installed tools and software, account behavior, and network traffic^[2] so that potential outliers stand out, and to use behavior analytics that analyze and correlate activities across multiple data sources^[2].

1. The expected-state check compares the observation with what should be there: the asset or software inventory, a baseline of normal resource use, traffic, and account behavior, and the records of approved changes and deployments. A match is context, not proof of authorization. A match to a specific approved change still needs its actor, scope, purpose, and approval confirmed; a match to the behavioral baseline only lowers suspicion, because living off the land (abusing tools already on the system) lets threat actors camouflage activity with typical system and network behavior^[2], so the corroboration check still applies. A deviation keeps the question open.
2. The corroboration check correlates the observation with its cause: the process that produced it, the parent process that launched that process, the identity that made a change, and what happened immediately before and after. A trusted name, port, or login shows what was used, never that this particular use was authorized.
3. The extent check states the strongest conclusion the evidence supports, whatever the cause, because a cause that is not malicious can still have security impact: ATT&CK records numerous incidents where cloud storage has been improperly secured, typically by unintentionally allowing public access to unauthenticated users^[3]. An attempt is an action shown to have been tried, refused or with its outcome unknown; an exposure opens an opportunity without observed use; and a confirmed compromise may involve unauthorized disclosure, modification, or loss. An attempt whose outcome is unknown stays an attempt with that outcome marked unresolved, never raised to a higher level, because an indicator only suggests that a compromise may have already occurred^[1].

A confirmed match to an approved change closes as authorized activity (legitimate administrative use^[2], in CISA's words); a deviation with an affirmatively verified benign cause can be classified as an inventory update (an authorized tool nobody recorded), a policy violation (an unapproved tool whose origin and use are confirmed benign), or an operational fault (a CPU spike traced to a performance fault); none of these is an attack, but each still has its security impact assessed; when the evidence shows neither a benign nor a malicious cause, keep the cause unresolved; assess security impact with the extent check regardless of intent, because even unintentional unauthorized disclosure, modification, or loss can be a compromise. The figure below illustrates the checks from raw observation to these outcomes; a baseline match alone cannot close the investigation.

For example, suppose a switch reports a device nobody recognizes and one address then starts touching many internal hosts: MITRE ATT&CK (ATT&CK from here on), a public knowledge base of adversary techniques, notes that adversaries may introduce devices that can be used as a vector to gain access^[4], yet an approved device missing from the inventory and your own authorized scanner leave the same traces. Network-related indicators come from traffic and from what is attached to the network, and the network's inventory and the host's role help interpret them.

Rogue devices

A rogue device is hardware attached to the network without approval. ATT&CK describes adversaries physically introducing networking hardware or other computing devices^[4], including adding new wireless access points to an existing network. The expected-state record is the asset inventory: Control 1 of the Center for Internet Security (CIS) Critical Security Controls calls for actively managing every enterprise asset connected physically, virtually, remotely, or in the cloud, which supports identifying unauthorized and unmanaged assets to remove or remediate^[5]. A new IP address on its own does not show a new device, because addresses are reassigned. Check the device's identity, where it attached, and whether onboarding records exist before declaring it rogue; an approved device that nobody added to the inventory fails the same check and ends as an inventory update.

Enumeration

Enumeration is systematic probing to list what is reachable: hosts, open ports, and running services. ATT&CK's network service discovery technique describes adversaries trying to get a listing of services running on remote hosts and network infrastructure devices^[6], commonly with port, vulnerability, or wordlist scans. In flow or firewall logs it looks like one source touching many ports or many hosts in a short period. Your own vulnerability scanner produces the same pattern, so compare the source address and timing with the authorized scanner and its schedule before calling the activity hostile. A scan is evidence of discovery; calling it denial of service needs evidence of an attack on availability, and showing that the attack actually affected a service needs evidence that the service was degraded or blocked^[7], whether by exhausted resources or a crash condition, as the application-related indicators section below explains.

Anomalous activity: DNS as a hidden channel

Domain Name System (DNS) traffic may be common and permitted, and attackers can hide inside it. ATT&CK notes that adversaries use DNS to avoid detection by blending in with existing traffic, embedding commands and often their results in the protocol^[8], a method known as DNS tunneling. Its detection guidance points at high query volume, long subdomains, encoded-looking payload patterns, and queries issued by processes that are neither browsers nor system services, such as a scripting engine. Treat these as a candidate channel and correlate the queries with the requesting process and the destination domain before concluding that tunneling is taking place.

Activity on unexpected ports

Ports work as an indicator in both directions. A protocol on a port it does not normally use is suspicious: ATT&CK's non-standard port technique gives the example of HTTPS over port 8088 instead of the traditional port 443^[9], a change made to bypass filtering or confuse analysis. Port 443 is only HTTPS's conventional port, not a requirement, which is exactly what the technique relies on. The reverse holds too: a connection on a commonly allowed port is not cleared by its port number, because the blending that hides DNS tunneling works for any allowed protocol. Judge the connection by the host's role, the process that opened it, its destination, and its duration: a database server opening an outbound HTTPS session to an unknown address is unexpected even though port 443 is allowed.

On the network, ownership and role turn raw traffic into an indicator: an unknown device, a burst of probing, unusual DNS queries, or an odd port is a lead until inventory, scanner schedules, and the initiating process have been checked.

Process execution indicators can come from host process telemetry, records an appropriately configured EDR (endpoint detection and response) tool or host logger may collect about a process, its parent, executable path, arguments, and account. They answer one question: should this program have run here, launched by that parent, with these arguments?

Suspicious processes

An unknown executable in a user's temporary folder or a legitimate program behaving unexpectedly needs investigation before its authorization or purpose is settled. The name proves little in either direction, because attackers rename utilities to avoid monitoring. CISA recommends checking the original file name that most Microsoft utilities carry in their file header, since a utility renamed from net.exe to net2.exe may indicate malicious activity^[2].

Parent-child chains

The relationship between two processes is often a stronger indicator than either process alone. CISA calls it a red flag when Office applications such as Word or Excel spawn cmd.exe, PowerShell, wscript.exe, or cscript.exe^[2], because those applications rarely launch scripting processes, and it recommends establishing baselines of normal parent-child process activity so deviations stand out. Both programs in that chain, the document viewer (Word) and the command interpreter (PowerShell), are legitimate products; the indicator is that a document was able to make one launch the other. Examine the command line the child process received, the document or request that triggered it, and the resulting activity. Public-facing servers deserve the same scrutiny: the same guidance notes that attackers who gain a foothold by exploiting internet-facing services frequently rely on built-in binaries for initial execution and reconnaissance. The figure below traces one such chain from the parent process to the resulting activity.

Living off the land binaries and scripts

Living off the land (LOTL) is the abuse of tools and processes that are already on the system. CISA's joint guidance describes it as abusing native tools and processes, especially living off the land binaries, often referred to as LOLBins, to blend in with normal system activities^[2], because those tools are already deployed and trusted. Its examples include wmic.exe, ntdsutil.exe, netsh, cmd.exe, and PowerShell on Windows and curl, systemctl, and python on Linux, among others, and the technique extends to native scripting environments running attacker-supplied scripts. LOLBins therefore name a way of misusing what is installed, not a malware family.

The trap is the trust these files carry. CISA warns that LOLBins have trusted attributes such as file hashes or digital signatures, which can mislead network defenders into thinking they are safe for all users^[2]. The word signature means two different things here: a malware signature is, in NIST's malware incident guide, a set of characteristics of known malware instances^[10], so a clean signature-only scan means only that no known pattern matched and does not establish a file's provenance, while a digital signature is one of the trusted attributes the file itself carries. Neither establishes that this use is authorized. Ask who invoked the tool, what it targeted, and whether the sequence matches approved administrative work. Example: curl fetching a script from an unfamiliar host and handing it to an interpreter on a web server where administrators never do that is a potential living off the land indicator even though no new executable was installed.

On a host, judge execution by lineage and use: the parent that launched a process, the arguments it received, and what it did next outweigh whether its name or signature looks familiar.

For example, suppose a server's CPU stays pinned, an unapproved program appears, and many files are suddenly renamed: CISA's LOTL guidance has defenders establish and continuously maintain a baseline of installed tools and software^[2] to identify potential outliers such as these. Host-related indicators also include deviations in what a host consumes, installs, and writes to disk.

Resource consumption

Unexplained, sustained load can mean someone else is using the machine. ATT&CK calls this resource hijacking: adversaries leverage the resources of co-opted systems to complete resource-intensive tasks such as mining cryptocurrency^[11], which may also hurt system and service availability. Its detection guidance pairs persistent high CPU utilization with suspicious command-line execution and outbound connections to mining or proxy networks, and that pairing is the point: a CPU figure alone cannot separate an unauthorized miner from a legitimate heavy workload or a performance fault. Correlate the increase with the processes consuming it, recent deployments, and the host's network activity.

Unauthorized software

Software missing from the approved inventory is a policy and investigation finding before it is a malware conclusion. CISA recommends reviewing existing host configurations against a known baseline of installed software and expected behavior^[2], and a mismatch can be user-installed, unwanted, or malicious. Decide which from three pieces of evidence: its origin (where the installer came from), its installation history (which account installed it and when), and its behavior. Possible findings include an authorized inventory update, a policy violation, or evidence of compromise, sometimes together; if the evidence is insufficient, keep the cause unresolved. Approval status alone does not establish maliciousness or compromise.

File system changes

File system changes the host's role does not explain deserve attention, but changes that fit that role may also be malicious. Ransomware is the loudest case: ATT&CK notes that common user files such as documents and images are encrypted and often renamed and/or tagged with specific file markers^[12], so many files rewritten and renamed in a short period on one host is a strong indicator. Quieter changes accompany data theft: in one compromise CISA observed potential exfiltration activity that included the creation of temporary directories and the mounting of the ntds.dit database^[2], the main Active Directory database file holding password hashes for every user in the domain. New autostart entries and scheduled tasks are file and registry changes too, but they are taught in the unauthorized configuration section below, where persistence is explained.

Across all three, the expected-state record decides whether the change is even unusual, and the processes and accounts behind it decide what it means.

Data exfiltration is the unauthorized removal of data from an environment (the data theft step of an attack), and this section explains why a transfer is judged by what it carried and where it went rather than by how large it was.

Attackers can use ordinary protocols to transfer stolen data. ATT&CK's exfiltration over alternative protocol technique describes stealing data over a different protocol than the existing command and control channel^[13], where command and control (C2) is the channel an attacker uses to send instructions to a compromised host. The technique names FTP, SMTP, HTTP/S, DNS, and SMB among others, and its detection guidance looks for unusual outbound file transfers by non-standard processes, at off-hours, or at uncommonly high volume. Before sending, adversaries often gather what they want in one place: ATT&CK describes how they stage collected data in a central location or directory prior to exfiltration^[14], sometimes combined into a single archive file. That gathering step is called staging.

Volume alone does not establish exfiltration. ATT&CK's analytics for this technique also weigh whether a transfer happens outside baseline user behavior^[13], so check purpose and authorization regardless of size:

• Expected state: is the destination an approved backup or partner endpoint, and is the transfer on its usual schedule?
• Corroboration: did the same account or process read sensitive files or create an archive shortly before, and is the sending process one that normally transfers data?
• Extent: evidence of an unauthorized transfer of information is a confirmed compromise (here, data loss) and supports an exfiltration finding; if the content or authorization is unclear, the transfer remains a lead.

The figure below traces an illustrative sequence to investigate: sensitive-file access, then staging, then the outbound transfer. A large transfer becomes a confirmed compromise when evidence shows an unauthorized transfer of information, not merely because of its size or the access and staging before it.

Unauthorized configuration is a change to a system's settings made without actual authorization; such a change can explain why other evidence went quiet or help keep an attacker in after the obvious cleanup, and a change missing from approved records needs investigation before you conclude it was unauthorized.

Changes that impair defenses

Attackers switch off what would catch them. ATT&CK describes adversaries who disable, degrade, or tamper with security tools such as EDR, intrusion detection systems, antivirus, and logging agents^[15], by stopping services, killing processes, or modifying the tools' configuration, and who also redirect event logs or interfere with forwarding into the SIEM (security information and event management system). Adding an exclusion to an antivirus policy is one such configuration change. The consequence for triage is direct: a drop in alert volume right after protection was changed may reflect reduced visibility and does not by itself demonstrate remediation. Correlate the change with the identity that made it and with the activity on that host just before it.

Changes that maintain access

Persistence is the attacker's ability to keep access after a restart, a logoff, or a password reset. ATT&CK's boot or logon autostart execution technique describes adversaries who configure system settings to automatically execute a program during system boot or logon to maintain persistence^[16], for example through specially designated directories or registry locations. CISA's LOTL guidance lists where to look: cron jobs and systemd timers on Linux, Run and RunOnce registry keys on Windows, and scheduled tasks that run at unusual times, execute uncommon scripts or binaries, or were recently modified without authorization^[2]. Compare each new or modified entry with software deployment and maintenance records, then connect it to the executable it runs and the identity that created it.

Public access, forwarding rules, and added credentials

Opening storage to public access to unauthenticated users^[3], setting up email forwarding rules to collect sensitive information^[17], and modifying credentials or permission groups^[18] are configuration changes as well; compare each with approved change records and the identity that made it.

Treat an unauthorized configuration change as an active indicator rather than background noise, and confirm its actual effect from evidence.

Application-related indicators appear in an application's availability and in its own logs, and the recurring mistake is naming the cause from the symptom.

Service disruption

An application outage has many possible causes: overload from real demand, a failed dependency such as a database or third-party API, a faulty deployment, or an attack. A denial of service (DoS) attack is the deliberate case; ATT&CK's endpoint denial of service technique describes adversaries who degrade or block the availability of services by exhausting the system resources those services run on, or by exploiting the system to cause a persistent crash condition^[7]. An availability alarm alone cannot tell these apart. The logging guidance of the Open Worldwide Application Security Project (OWASP) recommends that applications always log application errors and system events such as runtime errors, connectivity problems, performance issues, third-party service error messages, and configuration changes^[19], and those are exactly the records that separate a dependency failure or a bad deployment from attack traffic. Correlate the outage time with request patterns (sources, rates, targeted endpoints) and with change records before naming a cause.

Anomalous activity in application logs

The same OWASP guidance lists events that point at abuse rather than faults: input validation failures, authentication and authorization failures, and suspicious business logic such as actions that do not make sense in the business context. A pattern worth recognizing is one authenticated caller requesting many objects outside its own scope, for example GET /api/invoices/1001, then 1002, 1003, and so on. OWASP describes broken object level authorization (BOLA) as a vulnerability attackers may exploit by manipulating the ID of an object sent in the request^[20] to reach other users' objects; inspect the response to see whether access succeeded, since denied probes alone do not establish BOLA.

That last point is the extent check in action. A run of denied responses shows attempted access, an attempt. A response that returned another user's protected record supports the stronger conclusion of unauthorized disclosure, a confirmed compromise. Read the response codes and returned data before writing either word in a report.

For applications, the symptom (an outage, a burst of errors) starts the investigation, and the request and change records help establish the cause.

For example, suppose new virtual machines appear in a region your team never uses and a private storage bucket is suddenly public: ATT&CK's cloud instance detection guidance watches for creation events from unusual geolocations^[21]. Cloud-related indicators can be recorded in the control-plane audit log, the cloud provider's record of management application programming interface (API) calls that create resources and change identities and permissions, and in the access logs of individual services such as object storage. Workload and network telemetry can also show activity.

Unexpected resource creation

New instances in an unusual region or in unusual numbers can mean someone is using the account's credentials. ATT&CK describes adversaries who create a new instance or virtual machine within the compute service of a cloud account to evade defenses^[21], for example to bypass firewall rules and permissions that apply to the existing instances, and its mitigation is to routinely check which users can create instances. Link each creation event to the identity that requested it and to approved deployment activity before attributing it either to legitimate scaling or to a compromised account; assuming automatic scaling without checking who made the request skips the corroboration check.

Resource compromise

Compromised cloud resources are often put to work. ATT&CK's resource hijacking guidance^[11], which also covers host-related indicators such as persistent high CPU utilization, includes sudden spikes in cloud virtual machine CPU usage combined with outbound traffic to mining pools and unauthorized instance creation. The same evidence pairing applies as on a single host: the load figure starts the question, and the process, the network destination, and the identity that created the resource answer it.

New public access

A change that makes restricted data or services publicly reachable is a security-relevant event. ATT&CK notes numerous incidents where cloud storage was improperly secured, typically by unintentionally allowing public access to unauthenticated users^[3], and that adversaries may also use leaked credentials to reach storage objects. Investigate two things separately: the permission change (who made it, when, and whether it was approved) and the subsequent access records. A public setting with no access by unknown parties is an exposure: it opened an opportunity but does not by itself prove that anything was downloaded. Access records showing retrieval of protected objects by unauthorized parties turn the exposure into a confirmed compromise (data loss) once the objects and authorization are verified.

In the cloud, correlate relevant control-plane changes with identity, storage access, and workload telemetry before reaching a verdict.

For example, suppose an account signs in successfully from an unfamiliar device, then registers a new authentication method and receives a new role: no login failed, yet each step is an indicator, because ATT&CK describes adversaries who manipulate accounts to maintain and/or elevate access to victim systems^[18]. Identity-based indicators cover account compromise, unauthorized access, and impossible travel: who is using an account and what the account is doing, and they matter because an attacker with valid credentials can produce activity that looks entirely normal at the login stage.

A successful login can still be a compromise

ATT&CK's valid accounts technique describes adversaries who obtain and abuse credentials of existing accounts^[22] and who may avoid malware altogether, relying on the legitimate access those credentials provide to make detection harder. A successful authentication therefore verifies the credential that was presented, not the person presenting it. Look past the login: an unfamiliar device, an unusual access pattern, privileged actions soon after sign-in, or what CISA's LOTL guidance lists as rapid succession or high volume of access attempts followed by a successful login^[2].

Impossible travel

Impossible travel is one account signing in from two geographically distant places within less time than travel between them would take. It can prompt investigation of account use, but location anomalies alone do not establish that a different person used the credentials. ATT&CK's valid accounts guidance lists impossible travel among identity provider sign-in anomalies. Part of the caution is that an IP address's geolocation is an estimate of where the network egress point sits, not the user's verified physical position. Validate the timestamps, any VPN or proxy egress, and the device evidence before concluding two different people used the account.

Added credentials and role grants

An attacker who controls an account often changes it. ATT&CK's account manipulation technique covers actions that preserve or modify adversary access to a compromised account, such as modifying credentials or permission groups^[18], and its sub-techniques name the common forms, including additional cloud credentials, SSH (Secure Shell) authorized keys, device registration, additional cloud roles, and additional local or domain groups. The technique notes the attacker must already hold sufficient permissions, and that the modifications can grant additional roles, which is privilege escalation. After an account alert, review every credential and authentication method added to the account, not only password changes, because a new access key or registered device may survive a password reset and may need separate revocation. For a role grant, compare permissions before and after and identify who granted them: an administrator's account performing the grant does not make it benign if that administrator identity is itself compromised.

Unauthorized access without a location anomaly

An account that suddenly reads data outside its normal duties, or touches unusually many sensitive resources, needs investigation even when every sign-in comes from the usual office. CISA's LOTL guidance recommends baselining account behavior and comparing activity with normal user behavior, flagging odd login hours and access that conflicts with expected work schedules. A familiar location explains where the session came from, not why the account used its permissions this way.

The figure below traces how these indicators could line up in an illustrative account takeover; finding one is the cue to look for the others.

Social engineering indicators in links are tricks that make a reader trust a destination they have not actually seen; this section covers two examples, lookalike domains and shortened URLs, and a habit that helps investigate both: checking the real destination hostname rather than what the link text, branding, or shortener name suggests.

Typosquatting

Typosquatting is registering a domain whose spelling closely resembles a trusted one so that users mistake it for the real site. CISA's phishing guidance warns that a malicious website may look identical to a legitimate one while the URL uses a variation in spelling or a different domain (for example, .com vs. .net)^[23], and that hovering over a link can reveal that the displayed text does not match the real destination. Branding, logos, and a familiar sender display name can be copied and do not establish legitimacy, so inspect the actual destination hostname, character by character, when assessing a suspicious link.

URL shorteners

A shortened URL shows the shortening service's domain, not the destination. CISA notes that attackers may use a URL shortening service to hide the true destination of the link^[23]. A shortener with a good reputation vouches only for its own redirect service; it does not vouch for the site reached after the redirect, which may be attacker-controlled. Avoid opening a suspicious shortened link from a workstation; verify its real destination with an approved analysis method before trusting it, and evaluate that destination as you would any other link.

For both tricks, inspecting the real hostname after redirects helps detect a deceptive destination; do not rely on link text, page branding, or the shortener name alone.

Email-related indicators center on business email compromise (BEC), fraud that uses email from an impersonated or compromised sender to get someone to move money or hand over information, and on the mailbox rules that support it. BEC is social engineering too: ATT&CK lists impersonation as a sub-technique of its Social Engineering technique (T1684)^[24], but the evidence of BEC sits in the email request and the mailbox rather than in a link.

Business email compromise

ATT&CK's impersonation technique describes adversaries who impersonate a trusted person or organization^[24] such as an executive, colleague, or third-party vendor, noting that in many BEC campaigns impersonation is used to deceive victims into sending money or divulging information, often with pressure words such as payment, request, or urgent. The message may come from a lookalike address or from a genuinely compromised mailbox inside a real conversation, and it may carry no attachment or link at all. That is why a clean attachment scan proves nothing about it: the attack is the business request, not a file. The indicators are in the request itself, for example a change of payment instructions, unusual urgency, or a request that bypasses the normal approval path. The recommended counter is to confirm the request through an independent platform like a phone call or in person^[24], which in practice means a channel established before the message arrived, never contact details supplied in the message.

Mailbox forwarding and deletion rules

A compromised mailbox can be configured to keep working for the attacker. ATT&CK describes adversaries who set up email forwarding rules to collect sensitive information^[17], noting that such rules can preserve access to the victim's email even after compromised credentials are reset and can be hidden from common email tools. Its email hiding rules technique describes rules that delete or move emails to less noticeable folders to hide security alerts, C2 communication, or responses^[25], often filtering on words such as malware, suspicious, phish, and hack. Investigating only the visible suspicious message misses these settings. Correlate any new rule with the mailbox's sign-in records and with complaints from partners or colleagues to decide whether it supports surveillance, theft, or concealment.

In email cases the request and the mailbox configuration carry the evidence; malware scanning of attachments covers neither.

In these practice scenarios, start with a piece of evidence (an alert, a log line, a short scenario) and consider conclusions of different strength. Two tempting mistakes are a verdict the evidence does not support yet and a clearance based on a trusted name.

Indicator (category)	Conclusion the indicator does not yet support	Why the evidence falls short	Investigation step
A new IP address on the network (network)	Declare a rogue device	Addresses are reassigned; an approved device may be missing from inventory	Validate identity, attachment point, and onboarding records
One source probing many ports or hosts (network)	Call it denial of service	Probing shows discovery, not degraded or blocked service	Compare with the authorized scanner and schedule
A connection on a commonly allowed port (network)	Approve it because the port is allowed	Attackers blend into allowed protocols	Check the initiating process, destination, and the host's role
Long, encoded-looking DNS subdomains (network)	Ignore it as routine DNS	Data can travel inside the queries	Correlate with the requesting process and domain
A document viewer starts PowerShell (host)	Allow it because both programs are legitimate	The indicator is the chain, not either name	Examine the command line, source document, and resulting activity
A signed system utility in an alert (host)	Clear it after a clean malware scan	LOLBins are legitimate utilities; the use is the question	Ask who ran it, against what, and whether it matches approved work
CPU pinned on a server (host)	Diagnose malware	Load alone cannot separate misuse from real work or a fault	Correlate with processes, deployments, and network activity
The largest outbound flow of the night (host)	Label it exfiltration	Backups and exports are large too	Check destination approval and sensitive-file access before it
Alerts drop after protection was disabled (unauthorized configuration)	Treat it as successful remediation	Reduced visibility can lower alerts without demonstrating remediation	Identify who changed it and what happened just before
Many denied requests for other users' objects (application)	Report a data breach	Denials show an attempt, not disclosure	Look for responses that returned protected data
A bucket made public (cloud)	Report confirmed exfiltration	Exposure is not proof of download	Review the permission change and access records separately
New instances in an unusual region (cloud)	Assume automatic scaling	Scaling does not explain who requested creation	Link creation to the requesting identity and approved workloads
Successful login after an alert (identity)	Close the alert	Success verifies the credential, not the person	Review device, post-login actions, and added credentials
Sign-ins from two distant countries (identity)	Treat geolocation as the user's position	VPNs, proxies, and estimation errors move apparent location	Validate timestamps, egress, and device evidence
An administrator granted a role (identity)	Treat it as benign maintenance	The administrator identity may be compromised	Compare permissions before and after and confirm approval
Link text names the expected company (social engineering in links)	Trust the link	Display text and branding can be copied and do not establish the destination	Inspect the real destination hostname
A link from a reputable shortener (social engineering in links)	Allow it	The shortener does not vouch for the destination	Resolve the redirect chain with an approved method
Urgent payment change, clean attachment scan (email)	Clear the message	BEC needs no malware	Verify through an independently established channel

When two conclusions both seem plausible, check whether the evidence validates the indicator against the expected state or corroborates its cause before choosing a verdict.