Cyber Incidents & Offender Methods Technical Explainer

Does a security alert prove an attack happened?¶

Not on its own.

An alert proves that activity matched the detection conditions. The underlying events tell you whether the activity was malicious, whether it succeeded, and what effect it had.

That is why a high-severity alert can be important without yet being a confirmed attack.

Test the thing that triggered the alert¶

Suppose an alert says:

Possible credential theft detected.

The useful questions are:

what process or account triggered it;
what exactly happened;
did the action complete;
was anything accessed or changed;
what happened immediately afterwards.

A detection may be based on a real event with a benign explanation.

Attempt, success and impact are different¶

A simple example:

AlertSuspicious login attemptDetection conditions matched.

AuthenticationResult = failedThe service rejected the attempt.

ImpactNo session createdNo account access followed from that event.

That alert still matters, but it does not establish successful compromise.

The reverse can happen too: a low-severity event may become important when joined with later activity.

Triage labels are conclusions too¶

Terms such as:

true positive;
false positive;
benign;
suspicious;
unresolved

describe an assessment of the alert.

They can be very useful when the underlying evidence and reasoning are preserved.

Do not quote “true positive” as though it were a source event. Ask what made the responder reach that conclusion.

Keep the wording accurate¶

If the product says:

possible credential theft

do not silently rewrite it as:

credentials were stolen

until the source evidence supports that stronger statement.

The practical point is: an alert tells you a detection fired. Use the underlying events to establish what actually happened, whether it worked and what consequence followed.