Okay, let's hop back into the Wazuh manager container.
Let's go back to our rules file.
Now, it's time to focus on our second rule, which is the escalation rule.
For this rule, I'm going to create an escalation group.
As a brief aside,
I'm only going to highlight attributes that haven't already been covered.
The frequency attribute specifies the number of times the rule
needs to be fired within a given timeframe.
So in other words, if this rule is fired twice within 300 seconds,
an alert will be raised.
Now, the 300 seconds is seen within the timeframe attribute.
If_matched_group will trigger this rule when any rule
within the invisible_process group fires.
As you probably remember, we created the invisible_process group above.
Okay, before I forget,
I'm going to remove the noalert attribute to activate this rule.
Okay, I'll go ahead and save the file.
Let's go back into ossec.conf so we can create the active_response entry.
Nice, let's go to our second active_response configuration.
So what does our escalation active_response do?
I created the script for this tutorial, and it will quarantine an
instance by blocking all egress and ingress traffic,
with the exception of one CIDR range.
The CIDR range is defined within the script.
For testing purposes, I set the default to 8.8.8.8,
which is one of Google's DNS servers.
If this was a real‑world environment, we would set it to a bastion host,
or some other host that you can leverage to SSH into
the instance under investigation.
Everything in the command in active_response tag should be familiar to you.
Notice that the rules_id matches the escalation rule that we just defined.
In summary, if the pre‑load file is mutated multiple times,
the quarantine command will be activated.
Okay, let's exit _____.
Similar to before,
we need to restart the Wazuh manager for the escalation rule to take effect.
Alright, let's log in.
Okay, we see the foothold script ran.
I'm going to log out using Ctrl+D. Perfect. Let's log
back into the container one more time.
Okay,
let's check and see if our quarantine script worked. Here I'm going to ping
an IP that shouldn't be allowed, Operation not permitted.
Go into Ctrl+C, perfect.
Let's try an allowed IP. Bingo! Go into Ctrl+C really quick.
It looks like our quarantine script worked.
Now, if you'd like to check out the quarantine script,
please see course notes number 15.
If you recall,
the Merlin agent is able to run for a small amount of time before
being killed by the initial active_response script.
Well,
let's assume that the attacker was able to do some
recon, and through that process,
a database backup file was found on the victim's machine.
At this point,
the attacker is simply waiting for the agent to reconnect so this
command can be executed, but, due to the quarantine,
that day will never come.
Let's try executing this command.
I've waited a few minutes now, and as you can tell, no progress has been made.
Obviously,
this was huge, and Wazuh coupled with the active_response script was able
to quarantine the instance and stop data exfiltration.