Malware & Credential Threats.

From deceptive requests to real systems and accounts.

Lesson 03 introduced deceptive messages and safe reporting. Here we study what may happen after an initial lure—or after an exposed service or stolen password is used. You will learn to distinguish an attempted action from a successful session and from demonstrated business harm.

We will not download malware, run exploits, generate password attacks, collect live credentials, or alter real endpoints. Every telemetry example is fictional and designed for defensive reasoning. Prior knowledge of SIEM queries, PowerShell or operating-system event IDs is not required.

Malware is software used for harmful purposes.

Start with observable behavior, not a dramatic label.

Malware is software intentionally used to cause unauthorized, unwanted or harmful outcomes. The word describes the purpose and behavior of the code, not a single file extension or a special kind of computer. Malware may steal data, encrypt files, open remote access or interfere with a service. An infection can be initiated through a lure, a vulnerable service, a compromised update or stolen administrative access.

Defenders should avoid claiming 'the machine is infected' solely because an antivirus product displayed a detection name. A detection can represent a blocked download, a quarantined file, a running process or even a false positive. Ask exactly what happened, at what time, and what evidence proves the next stage occurred.

Different malware families describe capabilities and goals.

Understand the categories without assuming they are mutually exclusive.

A computer worm can spread through susceptible systems with limited user involvement; a Trojan presents itself as useful or legitimate; a remote-access Trojan (RAT) enables unauthorized remote control; spyware collects information; ransomware denies access, often through encryption, to coerce payment. These descriptions concern behavior. A single campaign may combine multiple capabilities.

No category tells you the complete incident story. A legitimate remote-management tool can also be abused by an attacker; you need context and authorization to classify its use. The type of file or the appearance of a program window does not establish what the process actually did.

A lure, file download, execution and impact are separate events.

Reconstruct only the stages supported by evidence.

An attacker might deliver a file through phishing, persuade someone to run it, establish persistence, access additional resources and eventually steal or encrypt data. That is one plausible chain, not a mandatory sequence. Some attacks begin with exposed services or compromised credentials without a phishing email at all.

If a web proxy shows a download but endpoint telemetry shows no process launch, the evidence supports a download, not confirmed execution. If a suspicious process launches but no sensitive file access is observed, avoid asserting exfiltration. Write down each observed event and the gaps between them.

Behavioral evidence matters more than an alarming filename.

Correlate process, file, network and identity events.

Endpoint telemetry can report a process launch, parent process, file modification, security-product action or network connection. A process is a running instance of a program; its parent is the process that started it. A suspicious chain may involve a document reader unexpectedly launching a command interpreter, but legitimate automation can look similar. Explain why the context is unexpected rather than assuming a single process name proves maliciousness.

Network logs can show a destination and time without revealing everything that was transferred. DNS resolution shows a hostname was looked up, not necessarily that a harmful download succeeded. File-event spikes can indicate automated changes but also legitimate backups or updates. Multiple sources improve confidence; none should be treated as perfect.

Persistence and privilege change what an attacker could reach.

Be precise about what the telemetry demonstrates.

Persistence means a mechanism for maintaining access after a restart, sign-out or similar interruption. It might involve an autorun setting, scheduled task, service or cloud application grant. Privilege escalation involves gaining broader authority than initially held. Neither can be concluded solely from an unusual login or an isolated suspicious file.

Look for validated system changes, account role assignments and activity that follows those changes. In a real environment, investigating persistence safely may require endpoint or cloud security tooling and a documented escalation path. A beginner should not delete scheduled tasks or revoke high-value accounts just because a list looks unfamiliar.

Ransomware response starts with evidence and containment authority.

Know the difference between a ransom demand, encryption and recoverability.

Ransomware may encrypt files, exfiltrate data, disrupt backups or threaten public disclosure. A ransom note is concerning, but it is only one artifact. File change events, inaccessible records, endpoint detections, shared-storage activity and backup status help establish which systems were affected. Do not assume that a ransom note proves every backup was destroyed or that all data was stolen.

Containment may involve isolating systems, blocking an account or halting a process, but these are operationally consequential actions. Follow an authorized incident procedure; isolation may interrupt critical services and may affect evidence collection. Restore only from evaluated recovery points and validate the recovery before declaring resolution.

Password spraying, stuffing and brute force describe different login patterns.

Distinguish techniques using the shape of observed authentication failures.

Password spraying attempts a small set of common passwords against many accounts, often to avoid per-account lockouts. Credential stuffing tries known or stolen username-and-password combinations across services. Brute-force attempts many guesses for a single secret or account. Observations can overlap, and sign-in logs do not automatically reveal exactly where the attacker obtained candidate credentials.

An authentication log contains a timestamp, account, source context and outcome where available. A broad wave of failures across users can suggest spraying; repeated guesses against one account may suggest brute force. A successful login after failures is a reason to investigate, not automatically proof the login was malicious.

MFA reduces risk but does not end the credential investigation.

Examine both the authentication result and the session.

A password can be stolen while an MFA challenge blocks account access. An attacker may still seek an unsolicited prompt approval, reuse a stolen session token or exploit an application with weak access controls. These are different problems with different indicators. Phishing-resistant authentication can reduce some impersonation and relay risks, but it is not a promise that endpoint or token compromise is impossible.

When evaluating a suspicious sign-in, note whether it failed, required MFA, completed MFA, issued a usable session or accessed a sensitive resource. These are distinct states. A user report of unexpected prompts should be escalated, but the prompts themselves do not establish that an attacker reached the mailbox.

Read sign-in evidence without inventing an attacker.

Time, account, source and outcome form a defensible starting record.

A sign-in event may include the account name, timestamp, application, source IP address, location estimate, result, authentication requirement and device signals. IP-based location is approximate and may reflect proxies or VPN services; two different locations minutes apart are a useful anomaly but not conclusive proof of account takeover.

Compare suspicious events with user reports, managed-device inventory, approved remote work, previous sign-in patterns and downstream application actions. A successful sign-in from an unfamiliar source raises the need for verification. A failed sign-in is not the same thing as a completed session, and a successful session is not automatically proof of data access.

Triage separates an alert, a suspected incident and demonstrated harm.

Match response urgency to the evidence and potential consequence.

Start with the observable signal and the asset at risk, then ask what more can be established: was a file blocked or executed, was a sign-in rejected or completed, did any resource access occur, did important data change? Record both confirmed observations and unresolved questions. Multiple independent observations can justify stronger concern even before every uncertainty is resolved.

Some actions are safe to recommend at a service desk level—reporting, preserving logs, contacting the responsible security team, and avoiding suspicious content. Others are high-impact, such as disconnecting a server, revoking many sessions, changing firewall policy or restoring production databases. An authorized responder must evaluate business impact, scope and evidence before acting.

Preventive, detective and recovery controls address different parts of an attack.

Explain what each control can and cannot establish.

Patching, application allowlisting, least-privilege accounts and appropriate network boundaries can reduce opportunities for harmful execution or spread. Phishing-resistant authentication and scoped permissions reduce certain identity abuse paths. Endpoint detection and response (EDR), sign-in monitoring and audit logs help discover and investigate activity; they do not make every dangerous action impossible.

Protecting offline or immutable recovery copies and regularly testing restores reduces some disruption consequences but does not undo data disclosure. The control lesson is the same as Lesson 01: choose a safeguard for the specific path to harm, verify its operation, and document residual uncertainty instead of claiming risk has reached zero.

Build the evidence timeline before choosing a response.

Try six investigations where an observed alert may mean very different things.

The Threat Chain Explorer below contains only synthetic endpoint and sign-in events. Inspect the timeline carefully. Then decide whether the evidence shows an attempted action, a suspected compromise needing correlation, or confirmed harmful activity; finally select a proportionate next step. In these scenarios, 'confirmed' refers only to a demonstrated event or impact described in the supplied evidence—not proof of every possible attacker action.

The explorer does not execute malware, run commands or interact with a directory. The goal is defensive reasoning: connect the time of delivery, authentication, process creation and impact without filling gaps with assumptions. After this guided workbench, independent Practice will give you different incidents and no preselected answers.

Describe the incident stage you can actually prove.

A download is not a process launch. A process launch is not proof of exfiltration. A failed login is not a session, and a completed session is not automatically proof of an attacker. Conversely, actual inaccessible files and corroborating unauthorized rewrites may justify urgent response without identifying the initial entry point.

These habits connect directly to Security Evidence & Logs, Detection & Alert Triage, and Incident Response Fundamentals, where incomplete records and operational consequences demand careful decisions.

Reference guidance from security organizations.

The lesson and its Practice are self-contained. These official resources expand on malware, credential threats, and evidence-led incident response.