Is SIEM Rocket Science? Extraordinary SIEM Use Cases

Although it’s not rocket science, try experimenting with the SIEM you use and see how many of the following scenarios you can accomplish:

✅ Starting from 23–10–2022, can you retrieve the list of failed sessions on the firewall within 3–5 minutes, going back 180 days?

✅ Real-life scenario: In July 2021, the personnel requested to the management that some files were missing in the Shared Area.

The IT team, using their SIEM, discovered within 2 hours that the person had deleted the files from their own computer with their own user account back in January 2021. They generated the necessary reports and presented them to the management, revealing an incident that occurred 6 months ago.

If they hadn’t kept this data live for at least 6 months, they might not have been able to find it even after days of searching through the archives!

✅ Another real-life scenario from a university: In their SIEM solution, they have an average of 10000 EPS traffic. They wanted the access list for 2 IP addresses within the last year. With their SIEM, they could generate this report within 1 month.

✅ Can you retrieve the list of all failed firewall sessions in the last 180 days within a few minutes?

✅ List of devices that accessed the target IP address X within the last 12 months.

✅ List of target IP addresses using UDP protocol that were blocked by the firewall and were not in the threat intelligence list within the last 12 months for your user.

✅ List of user access reports within the last 12 months for your user, which were not blocked by the firewall but were in the threat intelligence list, including the original log from the firewall.

✅ Which databases did SA log in to and what queries did they execute in the last year?

✅ All activities performed by service account X in the last 6 months, including the firewall.

✅ List of machines that have not generated any traffic in the last month.

✅ List of users who accessed tables X or Y (containing personal data) or files A or B on the file server (containing personal data), followed by the list of all URLs and IP addresses accessed by these users in the last 12 months, including port information. Finally, provide a list of other users who accessed these listed IPs or URLs in the last 12 months.

✅ Example of a site that was discovered/revealed to be used for an attack long after: deftsecurity[.]com (similar to the SolarWinds incident). Provide a list of users from your system who accessed this site in the last 6 months.

✅ List of unused firewall rules in the last 6 months.

✅ For example, it is critical to know if anyone from your company accessed the avsvmcloud.com site associated with the SolarWinds hack in the last 6, 12, or 18 months. Today it’s SolarWinds, tomorrow it could be something else.

✅ List of users who made DNS queries to SolarWinds servers in the last 6 months.

✅ List of users who have requested exception in AV or Endpoint Security in the last 6 months, if the same users requested it consistently.

✅ List of users who encountered problems while receiving updates consistently in the last 6 months.

✅ List of activities for a suspected user in the last 6 months.

✅ How many times did any user download mov files in the last 6 months?

✅ List of users who have not accessed the file server in the last 6 months.

✅ List of servers that have been shut down in the last 6 months.

✅ Number of occurrences of hitting the monthly threat intelligence list in the last 6 months.

✅ List of users who hit the monthly threat intelligence list the most in the last 6 months.

✅ Users who were blocked by the firewall while accessing the same target domain simultaneously.

✅ List of devices, along with source port and username, that accessed the sample IP address avsvmcloud[.]com in the last 12 months.

CORRELATION USE CASES

1. If there are more than 350,000 events from over 1,500 unique IPs and a maximum of 10 unique taxonomies within 15 minutes, raise an alert

2. Detect if the hourly login fail/login success authentication rate exceeds 3%.

3. Generate an alert if a file containing personal data is copied to a shared path that is accessible to everyone, or if personal data is added to an existing file in the shared path that is being edited.

4. Identify if the hourly HTTP/DNS ratio is less than 1.

5. If the total number of login events during business hours is at least 3% higher than the total number of users, and more than 5% of these events are generated by the same repeating users, notify.

6. If the data row added to the monitored table in the last hour is anomalous compared to history, then alert

7. Raise an alert if a machine is detected with a virus by the AV, and within 5 minutes, another machine is logged into, followed by the blocking of the logged-in machine within 5 minutes.

8. Alert if the same user logs in to multiple machines simultaneously, except for admin users or those in the whitelist.

9. If a user triggers a failed session event and repeats it between the 5th and 10th minute, with a 5–10 minute interval, raise an alert. (Operator support is needed for the condition where Event A does not occur within the first 5 minutes but occurs between the 5th and 10th minute.)

10. Raise an alert if the same user establishes a VPN connection to one machine and simultaneously performs a local login to another system.

11. Raise an alert if a user attempts three login failures within 30 minutes without any successful logins, especially if they are not an administrator or in the whitelist.

12. If a machine is flagged by the threat intelligence list, report the last logged-in user. (Operator first)

13. Raise an alert if a user downloads more than 50 MB in one minute or uploads more than 250 MB to the same target IP/Domain within 10 minutes, especially if the URL ends with zip, exe, or dat.

14. Raise an alert if a process is started on one machine and within 5 minutes, the same process starts on another machine with the same path as the first machine, and if one of these machines is blocked by the firewall within the next 5 minutes, and the users are different.

15. Raise an alert if a user creates a new user, and within 5 minutes, the created user performs a login failure, followed by the creation of another user by the user who created the initial user.

16. Do not generate an alarm if a user is created but deleted within 10 minutes without being used. However, raise an alert if the user is used before being deleted.

17. Raise an alert if the same IP first logs into a Linux server, then logs into a Windows server, and subsequently starts/stops a service on either of these servers.

18. Raise an alert if the same user attempts unsuccessful logins on two different machines within 15 minutes, and if within 5 minutes after the second unsuccessful login, there is an access request to an IP in the threat intelligence list from one of these machines.

19. Raise an alert if the same user attempts at least 3 unsuccessful logins within 10 minutes without any successful logins in between.

20. Banu establishes an external VPN connection and obtains the IP 172.16.23.21. Then, she SSHs into another system using this IP, and the IP on this system becomes 172.16.99.99. Finally, when she tries to access the internet from 172.16.99.99, it gets blocked.

21. If multiple usernames are subjected to brute force attacks or if, within 15 minutes of a brute force attack, one of the machines that was subjected to the attack successfully logs in (excluding machines where brute force was not attempted to avoid false positives), raise an alert. The expected outcome of this rule in the PoC is as follows:

✔️ Notify about users conducting brute force attacks

✔️ Create a list of source IPs from machines where brute force was attempted

✔️ Report machines where successful logins occurred

✔️ Report the usernames used during successful logins

The reason for including this rule here is:

🔔 It can perform these four tasks simultaneously without using lists.

🔔 It can detect multiple usernames in a single step.

🔔 In large networks with thousands of devices, only the 100 devices that are subjected to brute force need to be monitored, reducing false positives.

🔔 It can identify the username that successfully cracks the password as a result of brute force.

🔔 It can achieve the above four points in a single rule, written within 3–5 minutes using the GUI.

22. If a domain is created within the last 24 hours and it is listed in both Alexa’s top 1 million and Cisco Umbrella’s top 1 million lists, but not in our whitelist, raise an alert.

23. DGA detection (ML)

24. Hunting malware and viruses by detecting random strings

25. If critical processes that should be secure in your network (winlogon.exe, svchost.exe, explorer.exe, lsm.exe, lsass.exe, csrss.exe, taskhost.exe, wininit.exe, smss.exe, smsvchost.exe) start processes that may be deceptive in terms of their names (could be perceived as the same by human eyes) and these processes are not among the allowed processes, raise an alert.

26. Raise an alert if there are users who have not logged in for more than 3 months.

27. Raise an alert if a user has been created and hasn’t been used for 72 hours.

28. Identify machines or users that have been idle for more than 30 days (40 days, 60 days, 90 days, … 365 days) and then appear on the network, and shut down the machine and disable the user.

29. If a user has not used VPN for at least 2 weeks (20 days, 30 days, 40 days, … 365 days) and within a short period of time, they perform remote interactive logon on more than one workstation, raise an alert.

30. If a port, other than standard proxy target ports, which has not been used for at least 30 days or more (40 days, 60 days, 90 days, … 365 days), starts to be used again and this port is greater than port 1024, and within 5 minutes, multiple requests are made to different destination IP addresses with requestMethod=POST, raise an alert. (Threshold, but not all SIEMs support it, so it is included here.)

31. If the same user performs two or more unsuccessful logins to the same machine within a day without any successful logins, identify and raise an alert.

32. If a locked user remains unlocked for more than 72 hours, raise an alert.

33. Raise an alert if an email is received from email addresses similar to the original email address. For example, if an email is received from errtugrula@anetsoft.com instead of ertugrula@anetsoft.com.tr, raise an alert. (Phishing technique)

34. If an authentication error occurs simultaneously from the Oracle database user interface (Oracle Management Studio) and the console (SQL*Plus), raise an alert.

35. If an email is received from a domain that was created within the last 24 hours and is listed in both Alexa’s top 1 million and Cisco Umbrella’s top 1 million lists, but not in our whitelist.

36. Learn the user agent information of each user, then warn if any other user agent information is detected.

37. Learn users’ campus (University or distributed locations) information, then warn if any other campus location information is detected.

38. Learn users’ flat number or building location information, then warn if any other location information is detected.

39. Alert if user session on server more than 8 hours.

40. Detects when a user is still logged on but someone else logs on with a different IP using the same username to any machine

41. After the Antivirus system detects the Virus on a machine, notify if a process starts on that machine before it is deleted, and also alert if this process occurs more than two times in 15 days.

42. Alert when a user is still logged on but someone else logs on with a different IP using the same username to any machine

43. Warn if the same user tries more than 3 unsuccessful sessions on the same machine for three days without any successful login

44. Detect when multiple logins are occurring with the same username but from different IP addresses.

45. First Access to Critical Assets

46. User Access at Unusual Times

47. If the user whose last login event is Authentication-Fail, and this user fails again after at least 5 minutes without any successful login.

48. Create rules around logins that hop to different points of the network after a failure occurs or use the same credentials across multiple assets. (Automated login attempts)

49. Alert, while a user’s VPN connection is in progress, a new VPN connection request is received with the same username.

50. Detect if a disabled user account is attempted to be used without enabling it.

51. Warn if a logged-off user evet detected without a logon event.

52. If a user tries to log in to another machine while logged in on one another machine, alert.

53. Notify if the mac address of the server changes.

54. Monitor each users VPN connections from unauthorized locations. (While sales personnel can travel to certain countries in the world, the locations where the developers and accounting personnel work are fixed)

55. Detecting login attempts to a database server from an unauthorized IP address or users.

56. If the mail gateway discovers an infected email, add the sender’s IP address to the list of suspect IPs, add the email’s attachment file name to the list of suspected files, and alert any access from this IP (directly blocking is risky on the firewall), additionally, alert if there are any file accesses with the same filename until mail gateway categories this IP clean.

57. Report all access to an external IP categorized as suspicious by the URL proxy until it is again removed from the suspicious category by the URL proxy. Do not report after leaving the suspect category.

58. If an Antivirus System detects a virus on a machine, add the IP of that machine to the infected machines list, and add the current user to the suspicious users’ list and notify that IP and user activities until the Antivirus send the information that it has been cleaned for that machine.

59. When multiple failed login attempts from a single IP address occur within a short time frame, add the IP to a list of suspicious IPs’ and users to the suspicious users’ list. Then alert all the events of that IP address or users until a successful login event comes from that IP or one of the users. After a successful login event does not create an alert for that IP or user (successful event IP or user).

60. When a VPN connection is detected from a high-risk area, alert all events of this user until a VPN connection from a low-risk location with the same user. Do not alert after this VPN connection.

61. if multiple users accessing sensitive information (Monitoring Cloud Environments or File Servers) at the same time, alert. If someone accessed a file, then 5 minutes later, another user accessed the same file, this event flow will not generate an alert.

62. If multiple devices on the network are infected at the same time (At least 3–5 seconds)

63. If multiple users are accessing sensitive information at the same time, alert

64. If multiple users modifying system settings at the same time, alert

65. If a new device is being added while (at the same time) the firewall rules are being changed, alert.

66. Detect, if multiple users are accessing suspicious websites at the same time.

67. A user account is created, followed by a password change for that same account within 30 seconds.

68. A user accesses a database, followed immediately by a user uploading a large file to a cloud storage service.

69. A user accesses a sensitive document, followed immediately by a user connecting to a VPN

70. Alert if more than half of the queries in the last hour to a selected table from the database belong to the same user.

71. If there are more than 15,000 events from at least 50 unique IPs within 3 minutes, and these events belong to a maximum of 10 different categories, notify “So, these 15,000 events are being grouped into a maximum of 10 categories”.

72. Alert if the ratio of unsuccessful sessions to successful sessions in the last hour exceeds 5%.

73. Alert if more than half of the data added in the last hour to a selected table from the database belongs to the same user.

74. If the data row added to the monitored table in the last hour is 10% more than the previous hour, then alert

75. Detect anomalies between the number of inserts in the logs and the number of rows added to the monitored critical table.

76. Detecting data loss: Monitor the logs of a database table for any anomalies between the number of inserts in the logs and the number of rows added to the table. If the number of inserts in the logs is significantly lower than the number of rows added to the table, this could indicate potential data loss or deletion.

77. Detecting database performance issues: Monitor the logs of a database table for any discrepancies between the number of inserts in the logs and the number of rows added to the table. If the number of inserts in the logs is significantly higher than the number of rows added to the table, this could indicate database performance issues, such as slow or failing queries.

78. Detecting unauthorized data access: Use logs to track access to a sensitive database table and compare the number of inserts in the logs to the number of rows added to the table. If there is a significant difference between the two, generate an alert to indicate potential unauthorized access to the data.

79. Detecting data tampering: Monitor the logs of a database table for any anomalies between the number of inserts in the logs and the number of rows added to the table. If there is a discrepancy between the two numbers, generate an alert to notify security teams of potential data tampering.

80. Generate an alert if a file containing personal data is copied to a shared path that is accessible to everyone, or if personal data is added to an existing file in the shared path that is being edited.