I have been working on learning how Veeam SysLog can be utilized with the Azure SEIM tool Sentinel. This entry focuses on what I learned about KQL and an idea of how that can be useful when examining these events. I hope you find it useful, and if anyone wants to know more about the setup, just let me know.
What is KQL?
Kusto Query Language (KQL) is a powerful, read-only language designed to query structured, semi-structured, and unstructured data. It is primarily used with Azure Data Explorer for swift and interactive analysis of vast data sets.
Why Use KQL?
KQL is optimized for efficiently handling massive volumes of data, making it suitable for tasks like log analysis, telemetry data crunching, and monitoring applications and infrastructure. And is deeply integrated with various Microsoft services like Azure Monitor, Azure Log Analytics, and Application Insights. KQL's syntax is easy to pick up, especially for those familiar with SQL. It includes familiar clauses such as where, summarize, project, and join, making it relatively straightforward to learn.
KQL with Veeam SysLog
As mentioned above, KQL is used in conjunction with Azure Data Explorer, or to create queries that trigger incident response. In this example I will simply demonstrate the use of KQL under Analytics in my Sentinel Workspace.
Utilizing the Event codes listed in Veeam Help Center to create a specific query, which find events documenting the removal of restore points. An event that doesn't necessarily mean anything malicious as this happens daily as retention limits are met. But an event of interest nonetheless.
But these logs don't yet tell us much. Let's sort them a little further, and parse these logs a bit further and see if we can't sort them in a way to make them more actionable. The 'SyslogMessage' field contains specific data that can help locate potentially malicious events. Avoiding manually opening every log to find non-system generated events I sorted the logs to those that might contain potential malicious events.
In order to extract information from the Syslog Message, I will parse out the DateTime, VmName (or job name), and the Description. This will provide per-tenant information on each event. The results display a clearer view of the time of the event, the backup job name, and a brief description of the action. However, manually going through the list still poses the risk of missing events of real interest.
I need to sort out those logs that are not relevant, specifically, events not associated with a particular user account. Focusing on identifying any authorized or compromised account that has deleted a restore point manually. Using an additional WHERE statement of 'by user' I can now track manual deletion of restore points. Focusing on those logs that can help in identifying unauthorized or compromised actions within the system.
Now, I can see all Restore Point Removed events that were done manually, and by what account. There may be a valid reason for this removal, but I still want to know about it. And there should be a documented reason for this action. Perhaps, if a specific user, such as 'zallyn' above, removes a point, it is a normal event. And I can follow up or look for a change notification.
But it might be cause for alarm if an administrator account, which has no business logging into a VBR server, is involved. I can further use this for more in depth threat hunting. Correlating with other security events from VBR or other collectors in my environment.
I plan next to explore Azure Data Explorer to simulate long-term log events. Then move into some more advanced features in Sentinel. I hope to have an update in the near future around this journey.
