13.安全调查员 - 欣赏案例

13.安全调查员 - 欣赏案例
Security Investigator -Explore a Case
Let’s use the Dynatrace Security Investigator to explore a case the security team has brought to our attention.
To begin our review, let’s start by looking at the data available. This query has provided the count for each of the AWS log sources.
This next level query chooses just one of these options to focus on. The query tree is interactive, so we can filter for this log source.
Now, let’s look at these EKS logs. In this content stream, we can see that we should focus on unauthorized application access or request activity.
In this path, a filter was added for the audit logs because the audit logs have the unauthorized access information. The response status and code can be parsed out. To do that, let’s extract the fields using the DPL Architect.
With a sample log as a guide, the DPL Architect uses Dynatrace Parsing Language to parse the JSON and extract attributes we want, specifically, the response status. When the DPL Architect is displaying the parsed content you want, simply insert it.
And that is what the case shows happened in this step. The workflow of this hunt wasn’t interrupted to use other tools to extract data.
There is still a lot of data displayed here, so a deeper focus is still needed. Selecting the next step in the query tree, we can see that the data has been summarized by source IP, response status, and user string and focused on the information that we are most interested in. However, this is showing all the response status codes, and we are only interested in 403.
In the next step of the query tree, a filter was added for 403. Now we can see the source IP addresses of the unauthorized requests from anonymous users. The suspicious IP list has already been started here, where they were added as artifacts.
With the query tree, we can easily access the cached searches to explore the data. We can compare with the 200 requests or change the timeframe and rerun queries to gather more data. This allows for horizontal searching throughout different data sources, and the queries are automatically saved as new branches and nodes.
Now that we know there is unauthorized activity, we want to look at database integrity. Along with these suspicious requests, we should also look at the span data. This was created in a new query tree.
The net was cast wide to view all of the span data, then narrowed down to the span data not found in our other log data. Again, to focus on the important data, the fields were limited to the databases involved, the system, name, operation, and the statement. The nulls are filtered out, and now we can focus on data that relates to a database system.
There are MongoDB, MySQL, Oracle, and Redis queries. Let’s look through these and see if we can identify any issues. There are “finds” for Mongo, but those look benign. Here are some statements that are making inserts into permissions, which could be a concern. Is it internal work being done or is it nefarious? This is something we should follow up on. Let’s get the database service and add a note to check into it later.
These events can be filtered by the Dynatrace entity to take a closer look at the service. This shows that several events made the same insert statement. This observability data has narrowed our focus to something that could be an indicator of an attack.
Moving within the query tree, we can expand beyond database activity and broaden the scope to include the http POSTS and GETS. Now we can start to look for specific objects, such as the http methods, and target them.
If we pull out a trace ID, we can see a correlation across full transactions because the spans align based on the trace id or entity service. Filter by that entity service we noted and clean up nulls from the http targets. Looking at specific entity data for that service using the same trace ID, we see that most of it looks benign.
However, this one is accessing jsp reports. If we search online, we find “reports dot jsp” isn’t something an external user should be posting or getting. A Godzilla web shell is associated with the attack, which is an incredibly destructive attack.
Using all this observability data together with traced attributes across logs and events, we’re able to drill down through the service and host levels to pinpoint the problem which is a Godzilla web shell present in our environment.

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。