Welcome to part 2 of building a secure monitoring solution in Splunk!
In this part of the project, I'll be going over the analysis of the reports, alerts and dashboard visualizations before and after the addition of the attack logs.
I'll be using the following formatting to make things more efficient, since this is a lot to dive into:
Results before attack > Results after attack > Conclusion
Let's begin!
We'll start with our Windows Server and then move onto Apache.
-Windows Server Reports-
Severity Report Analysis
Results before attack:
Results after attack:
Conclusion:
Informational count from 11k to 4k, while high severity reports increased from 987 to 1k. Since the drop from informational server requests fell 7k by count, it could indicate that for some reason accounts that should be using the information are unable to, due to lockout or some other reason that should be investigated.
Success and Failure of Windows activities Report Analysis
Results before attack:
Results after attack:
Conclusion:
Successful events decreased from 13,848 to 5,854, while failures decreased from 426 to only 93. The difference seems most jarring for the successful events and may indicate abnormal activity on accounts.
-Windows Server Alerts-
-Alert for Failed Windows Activities-
Results before attack:
Results after attack:
Conclusion:
At 8AM there was a very large number of failed activities, totaling 35 for the hour.
Since the threshold we set was to create an alert for anything > 18, this alert would have picked up on this suspicious activity.
Whether or not this was a false-positive remains to be seen.
-Alert for successful logins-
Results before attack:
Results after attack:
Conclusion:
My Alert was also triggered for suspicious activities taking place at 2AM, 9AM and 10AM. Anything > 26 would trigger an alert, so the successful logins from user_a equaling 91 counts at 2AM would have definitely triggered. The others would have also triggered the alert--70 logins, 67 of which were by user_k at 9AM, followed by 54 logins at 10AM, 52 of which were by user_k.
This tells us that user_k may be compromised, and a security admin may need to step in to temporarily disable access to the account until they can isolate and remove any malicious entity.
-Alert for account deletions-
Results before attack:
Results after attack:
Conclusion:
A large number of accounts appear to have been deleted at the same times we previously saw a suspicious login activity from user_a and user_k.
We can see 45 events of account deletion at 2AM, with 42 of them originating from user_a. We also see 75 events at 9AM, 72 of which were by user_k, followed by 44 events, 43 of which were also by user_k at 10AM.
It would appear that action may need to be taken to temporarily cut off access from user_a and user_k to prevent any potential damage until the cause of this activity can be determined and eradicated.
-Dashboard Analysis-
Full-view before attack:
Full-view after attack:
Conclusion:
As our previous data showed via our alerts and reports, users user_a and user_k had the most hourly activity. The activities specifically outlined via signature monitoring being attempts to reset account passwords and locking out other users.
The hourly activity monitoring dashboards also paint an accurate depiction of the activity that was occurring during 2AM and 8AM.
We can see an attack taking place between 12AM and 2AM locking users out of their accounts. Based on what we already know, this was done by user_a, or someone compromising their account to lock out other users.
We can also see between 8AM and 10AM where user_a and user_k made a combined 761 attempts to reset account passwords.
This data tells us that a brute force attack may have taken place during the hours of 12AM and 2AM that resulted in users being locked out due to security concerns due to failed login attempts, which eventually led to successful login attempts once the passwords were successfully cracked by the attackers.
The password resets may be in response to the mass account lock outs, since all of the affected accounts would require password resets before they could be used again.
-Individual Dashboard panel comparisons-
-User Analysis-
Results before attack:
Results after attack:
Conclusion:
User_a and User_k dominated and may have been compromised.
-Source Domain-
Results before attack:
Results after attack:
Conclusion:
This chart confirms the activity by user_a and user_k during the hours summarized earlier.
-Windows Activities (based on signatures)-
Results before attack:
Results after attack:
Conclusion:
This chart change shows the activities conducted in response to the behaviors of user_a and user_k: user accounts being locked out and attempts made to change account passwords.
As you can see above, there is definitely some abnormal activity originating from user_a and user_k.
Now we will analyze our Apache server log data...
-Reports-
-HTTP Methods Report-
Results before attack:
Results after attack:
Conclusion:
GET requests fell from 30k to around 3k, which is a huge difference. POST requests did the opposite and increased from around 400 to well over 1000.
-Report Analysis for Referrer Domains-
Results before attack:
Results after attack:
Conclusion:
The numbers across all traffic decreased substantially, going from the high thousands to mere hundreds, which could indicate that systems are not working as intended or are being brought down/inaccessible.
-Report Analysis for HTTP Response Codes-
Results before attack:
Results after attack:
Conclusion:
Once again we see numbers falling drastically. This may be indicative of a Denial of Service attack, since these numbers are not within the normal expected range.
-Alerts-
-HTTP POST Alert-
Results before attack:
Results after attack:
Conclusion:
1,296 POST method requests came in at 9AM. Our alert was anything higher than 10, so this was definitely caught, though I do see other alerts with much lower numbers.
Considering the POST method requests outside of 9AM were in the single digits, I may increase from 10 to something a bit higher. I think anything greater than 100 within the span of 1 hour may be a better threshold.
-Dashboard Analysis-
-HTTP Methods per hour-
Results before attack:
Results after attack:
Conclusion:
A high number of POST requests seem to have occurred around 8PM, while GET requests fell tremendously. This maybe be indicative of an attack meaning to deny service but will need to correlate with other data points to confirm.
-Geolocation Cluster Map Analysis-
Results before attack:
Results after attack:
Conclusion:
We can clearly see a noticeable uptick in requests coming from Ukraine and Sweden, as well as within the US, with the majority coming in from the East Coast.
-Dashboard Analysis of URI data-
Results before attack:
Results after attack:
Conclusion:
Malicious actor may be running a script coded in java (php) to automate login attempts, possible indicating a brute force attack. We also see a large number of access to an archive, which may be an effort on someone’s part to exfiltrate log data or other important records.
-HTTP POST Requests-
Results before attack:
Results after attack:
Conclusion:
This POST method increase matches what we saw in our HTTP Method bar graph.
-HTTP GET Requests-
Results before attack:
Results after attack:
Conclusion:
The number of GET requests decreased, which may be indicative of an attack limiting access to resources. Will need to correlate with other data to confirm.
-User Agents Analysis-
Results before attack:
Results after attack:
Conclusion:
A dominant user agent arose as illustrated in our pie chart: Mozilla/4.0 –possibly using a downgraded browser version vulnerability.
If you made it to the end of this report, I appreciate you!
This was a lot of work, but I felt happy at what I was able to create and how I was able to give myself a glimpse of what a day-in-the-life of a SOC Analyst might be like. That said, I know I still have a lot to learn!
Stay tuned~!
Top comments (0)