Managing Alerts and Investigations.

You would enter the Security Operations Centre (SOC) and log onto your desktop. After having read up on your normal sources for Threat Intelligence you login to Samurai XDR and check the current state of Alerts and Investigations to catch up since you were last active.

Accessing Alert Management dashboard:

Here you will take note of the facts that during the set time-period a colleague has initiated an Investigation for 4 of the 94 Alerts triggered during the period and that a total of 85 have been checked at and Dismissed as non-relevant. This leaves you with a total of 5 Alerts in need of actioning.

Selecting the Alerts with the highest Severity and Confidence and opening the Alert details shows that the perimeter has been target for two rather extensive host-scans.

A quick triage further showed that all scanning activities were blocked by the perimeter firewall. You may wish to apply the “Dismiss Alerts” as non-relevant and tag them as handled. This will then hide them from the default view.

Opening the last Alert “Inbound remote management session from rare geoip country” shows that a host located in Belarus has attempted to login to one of our internet facing servers via SSH. This seems like warranting further investigation, for two reasons:

1) Our company does not operate in Belarus, which is why the AI engine has classified it as a “Rare geoip country” as it deviates from the established baseline.

2) Our company security policy strictly prohibits SSH services to be exposed to hosts other than a small pre-defined set. This policy should have been reinforced with Firewall rules, but contrary to this, we are seeing that the Firewall is accepting incoming sessions.

With these two indicators, we decide to undertake a full investigation with this initial Alert. As further information becomes relevant, such as more alerts, these can be added to the same Investigation.

The Investigation has now been created with a direct link in the left panel in Alert Details. Click on this to open the newly created Investigation.

All investigations in SamurAI XDR have a Notes section. It's recommended to document your findings as you go. It may be used as a reminder to follow-up, direct your colleagues to some information, or make important notes for a handover. In this case, we will document our finding relating to SSH.

After the initial analysis has been documented, I want to take a historical look at prior similar behavior. I do this with the Advanced Query feature located in the navigation panel on the left side of SamurAI XDR. I want to perform an initial query to check if the host has been seen in the past; and if any of the “Action” packets sent indicate a session as being successfully established.

• src_ip: Limiting the query to events logged to record activity from the host triggering the initial Alert signature.
• project: defining the fields of interest to make the Results easier to overview, with a positive side-effect of reducing the matching results and in doing so significantly increasing the performance of the query.
  1. timestamp, to be able to graphically visualise the overview result.
  2. action, to see if there were any actions other than those accept during the time-period.
  3. packets_in/out, can be used to indicate a successful session being established.

From these results, I see that the host has been seen at two separate occasions, four connections over five days. The low number of packets transferred during these sessions indicates that while the traffic was accepted by the Firewall, no session where successfully authenticated with the SSH server.

Let's now check if any additional login attempts towards the SSH server from other non-sanctioned networks have occurred.

This is done by running the query events | where src_ip !contains ‘10.30.0.” | where dest_ip “10.3.0.4” | where dest_port == “22” | where action == “A”

• src_ip: Using a !contains operator combined with src_ip has the query looking for an activity that does not originate from the specified network of 10.30.3.*.
• dest_ip: Returning results matching the destination IP address of the initial Alert that the Investigation is based on.
• dest_port: limits the query to only returning results where traffic is initiated towards port 22.
• action: As part of this investigation I am looking for accepted traffic, by defining “A” any other action would not be targeted by the query. 

This would return the below graphical overview and Results,

Revealing many more incoming network sessions have been accepted by the firewall and that the problem may have been more significant than initially thought.

Taking a broader view and creating a query that summarizes all inbound sessions from non-approved networks by “actual_action” to see if any of the incoming sessions were accepted by the SSH server.

Query shows that while all inbound sessions were accepted by the Firewall, most resulted in various types of session terminations (timeout, server-rst, client-rst) being performed by the SSH service, or the attacker client itself. Noteworthy is however that proper session closure (close) also took place between the two hosts, which may indicate an authentication attempt being performed.

Now it's time to see how long this activity has been occuring. Running a query looking for any connections to our SSH server from a non-approved source revealed such activity started on 2023-08-03.

In this example, we identified via IT support that this sudden change in behavior was caused by a change in the firewall policy. The policy includes a host group (“admin_hosts”) unintentionally opened to permit incoming SSH traffic from the Internet. This human error was quickly solved by reverting the change performed and I have validated that no additional attempts have been accepted by the firewall.

As a future second layer of security to reduce the impact of such human errors, the IT team will also be looking into establishing service-based Access Control List (ACL) for external services.

It’s now time to close the investigation, knowing that no assets were affected by this unintentional internet exposure. As a result, we reduce the Investigation severity to Medium.

If the solution has been accepted, it's important to close off the Investigation. Closing the Investigation with a short summarization is recommended.

Going back to the Alert Management Dashboard you now see that there are no Alerts that unassigned.