Welcome to the Splunk for Security Investigation Experience. In this third video, we continue our investigation and use visual drill downs to examine specific activities between targeted hosts and compromised workstations. Watch the video, then try it yourself by following these instructions with this online Splunk instance pre-loaded with security data. Already using Splunk? Download the Getting Started with Splunk Security App, to get demo data and follow along with the scenarios.
[SPLUNK LOGO SOUND]
In the previous exercise, we focused on analyzing workstation 10.1.21.153, and visualized how that workstation carried out attacks across multiple web servers in a database server. For this exercise, we will analyze the scope and the impact of the activities initiated by the workstation and show you how we can pinpoint the nature of activities by the attacker to make an accurate determination on how to remediate the threat activities from this workstation.
In order to make some conclusive mitigation decisions, we will be verifying-- were the access attempts successful? What credentials and privileges were used? What actions were applied to the targeted system, database 001 server? We will be further drilling down into specific source and destination activities between the workstation and the database server. Through the process, we will be demonstrating a continuous investigation workflow from visual analysis results.
From the analysis chart showing activities of workstation 10.1.21.153, mouse over to database -001 in the right side of the chart and click on Database -001. instead of restarting our investigation from the beginning, we can continue our investigation from the previous analysis chart, where we will click on the host database -001 to further drill into detailed activities.
When we click on the destination hostname database -001, we've added another search condition-- destination=database-001. Now we are only looking at activities between 10.1.21.153 and the database that are failed passwords. Focus drill down is a fast way to validate specific incidents, rapidly selecting groups of events to investigate.
What if we went to review not only failed passwords, but all the activities between the 10.1.21.253 workstation and the database server? This would help us to determine the overall impact of the infrastructure. We can do this by simply removing fail*password from our current search, and then clicking on search. By removing fail*password password from our search, we are not limiting our search to just authentication failures, but all other activities between the workstation and the database server.
As you can see, our search result found other events, which can provide more context into the activities between these two hosts. We will determine the searched events as we did in the prior exercise using the Fields Exploration Panel. Select field comment text and SQL text, then view, in the event table format. We are selecting the field comment text, which includes session information on the database server. We are selecting the field SQL text, which includes information on the queries potentially executed against the database. We want to validate if there are any queries coming from this host.
There seem to be four different queries that have run. For easier analysis, we can format the events into tables. Using the Splunk SPL table command, we will format them into table format with aligned columns for each of the selected fields. The Event Formatting Command Table places the database events into an organized table that clearly presents the initial password failure events followed by a number of successful access attempts and queries.
Through this demonstration, we have seen how Splunk can easily drill into detailed analysis and validate specific suspicious activities. Now it is clear that we have been attacked, and the attackers are querying against our database servers. We understand what and how these things have happened.
The activities from the workstation in question have used multiple database credentials to gain access to the database, which includes database privileged user. After three failed logging attempts, the attacker successfully logged into the database as Oracle user, and succeeded in gaining admin privileges to the database to manipulate the user privileges for a third user. Following that, we see clear signs of a transaction that accessed our restricted database table that contains customer information.
This completes the scoping section of the basic security investigation workflow with Splunk. Next, you have an option to further analyze how this workstation has been controlled and communicated by an outside command and control host, exposing the attackers infrastructure.
[SPLUNK LOGO SOUND]