Back to glossary

Active attack

6 min read

An active attack is one where the adversary acts on the system: writing, modifying, executing or interrupting. It stands against the passive attack, which only observes. The distinction is not academic: it changes how each one is detected, because an active attack leaves a trace and a passive one leaves almost none.

July 30, 2026
Compartir:

Active or passive: whether it touches or only watches

The classification is old and still useful, because it separates two things that are defended in completely different ways. In a passive attack the adversary observes: listening to traffic, gathering information, studying patterns. Nothing changes, so there is nothing broken to look at, which is why it is so hard to detect. The defence against it is preventive, and it is called encryption.

In an active attack the adversary acts on the system. Something is sent that should not be, a value is modified, a command runs, a log is deleted, an account is left behind. It touches, and touching leaves a trace: a connection that does not fit, a new process, a file with an odd timestamp, a failed attempt just before the one that worked.

That asymmetry decides where the money goes. Against passive activity you invest in encryption in transit, because whoever listens to encrypted traffic collects noise. Against active activity you invest in detection and response, because the trace exists and the only question is whether anyone is looking at it.

In practice the same intruder does both, in that order: quiet reconnaissance first, and only then the move that can be seen. Understanding the boundary means understanding the moment you go from having nothing to detect to having an opportunity.

The four traits that define it

Direct interaction. There is back and forth between attacker and system: something is tried, the answer is read, the next attempt is adjusted. That conversation is what separates an active attack from information gathering, and it is also what makes it visible in logs and telemetry.

Intent. It is not a fault or an accident. A full disk takes a service down exactly as a denial of service does, and the two are investigated differently. Having somebody making decisions on the other side changes the whole response, because an adversary reacts to what you do and a failure does not.

Evasion. Anyone acting knows that acting is visible, so effort goes into not being seen: using the system’s own legitimate tools, working during busy hours, clearing logs, blending into the normal. Almost everything we call advanced technique is this.

Persistence. Many active attacks are not after a single hit; they are after staying. Well-placed persistence survives a reboot and a password change, turning one-off access into permanent access. It is the difference between an incident and an advanced persistent threat.

The classic forms, and what breaks in each

Interruption. The service stops being available. That is what a denial of service does, and also what ransomware does when it encrypts whatever was needed to work. It attacks availability, the property the business notices first.

Modification. The data arrives, but changed. An adversary in the middle alters a transfer; an intruder edits an account number on an invoice. It attacks integrity, and it is the hardest to discover late, because the system keeps running and keeps reporting that everything is fine.

Impersonation. The attacker passes for somebody with permission. With credentials taken through phishing or credential dumping nothing needs breaking: they walk in through the door with the key already in it. This is now the most common way to begin.

Fabrication. Something is introduced that did not exist: a new account, a mail forwarding rule, a scheduled task, a certificate. It is usually the step that grants persistence, and it usually outlives the point at which the rest of the incident is declared closed.

An active attack leaves a trace, and that is where it is caught

Because there is interaction, there is evidence. A SIEM collecting the right logs sees the sequence: access from an unusual place, the hop to a second machine, the tool running for the first time on that host. An EDR sees what happens inside the operating system, which is where the things network logs never mention actually occur.

The problem is almost never a lack of signal but an excess of it. That is why knowing what you are looking for matters, and why indicators of compromise and threat hunting exist: going to look rather than waiting for an alarm. It is also why alerts must not be drowning in false positives, because the best sensor is useless if nobody opens what it says.

The framework the industry uses to organise all of this is MITRE ATT&CK: it describes tactics and techniques observed in real intrusions and lets a team move from a list of loose alerts to a story. Once the team can say which tactic the adversary is in, the response stops being reactive.

An example: from one stolen credential to weeks inside

An organisation receives a social engineering campaign aimed at a handful of named people. One of them enters their credentials into a page that looks like the one they use at work. No vulnerability has been exploited: the key was asked for and handed over.

With that account the attacker comes in by the same route its owner would use, so the first access triggers nothing. From there the active part begins: checking what permissions the account has, finding a shared folder holding more than it should, performing lateral movement to a second machine, and creating an account of their own so as not to depend on the stolen one.

For weeks the activity looks like an employee with odd hours. What finally gives it away is not an alarm but a detail that does not fit: an administrative account nobody remembers creating. The investigation leans on digital forensics to reconstruct the order of events, and incident response has to close every route in at once, because closing only the first leaves the adversary inside via the second.

The example is illustrative and describes no client. Its lesson is measurable, though: the expensive part was not the lost password, it was the length of time the activity looked normal.

Why this gets tested with a red team exercise

A penetration test answers whether the path exists. A red team exercise answers the other half: whether somebody actually walks that path, how long your team takes to see it, and what they do once they do. It is the only way to test detection without waiting for somebody else to test it for you.

And what gets measured is not only whether the team reached the objective, but at which step it could have been stopped and why it was not. An exercise that ends with no alert raised is not a pass for the attacker: it is a fail for the detection, and that is precisely the reason it is run.

Want to see how we work at Asperis Security?

Schedule a 30-minute call with one of our experts. We will review your stack, agree on scope, and tell you what is worth pentesting first.