SOC. SIEM. Threat Hunting. What goes into keeping users safe without disrupting their daily work?

Central to all of this is log ingest. Our agent when installed on an endpoint transmits an array of information back to us including: Syslog/Eventlog, file system activity, process information, network activity and a whole host of other information.

Armed with data collected by various world-class threat intelligence resources this data is analysed to find “indicators of compromise” – that is, events or sequences of events which fit a set of criteria and tell the AI or human operator that an attack could be unfolding in real-time; typically, before site staff are aware.

These indicators are constructed by numerous small contributing factors, each of which is assigned an arbitrary “threat score” which is compounded in each event until either a particular threshold is reached or enough of the small events, when held together, are representative of a known attack vector – at this point an alert is fired by the AI and a human steps in to analyse the chain of events.

Take a look at the graphic below for a working example:

Here is the process chain for what was ultimately a blocked attempt at sending malicious code to a user - allow me to elaborate.

The user logs on, via the winlogon process. This launches userinit.exe which in turn does a lot of launching, but we are only interested in one particular process chain. Explorer is opened. Then Outlook. As you can see from the chain, nothing “interesting” happened in Outlook for some 39 minutes, (though a great deal of telemetry would have been recorded regardless) until the user opened a malicious email. This email contained code which activated rundll32.exe, a common attack vector for malicious code – which then spawned msdt.exe. Typically, msdt is used for troubleshooting, however at the time of this incident, there existed a known CVE (Common Vulnerability and Exposure) which allowed attackers to run specially crafted code via this vector, as detailed at https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/  --

When viewed in sequence like this, the AI can determine that this was likely an attempt to exploit this and of course the AI notified a human to come and check on things, via an alert into our SOC. In this case, an operative contacted the site admin who in turn contacted the user and delivered some well-needed information security training. Without our agent on hand, this could have quickly and easily escalated into a business-crippling ransomware attack or worse.

Of course, this is just one example of a fairly simple to trace attempt. Unfortunately, as with all things, it’s not always as simple as that. As I’m sure you can imagine, there are a great many things that go on day-to-day which could be viewed as attacks when you don your cynical cap. Even something as “simple” as updating a driver can raise an alarm, if the driver is not packaged and provided according to best practice. That’s where the human element earns its paycheque.

Time for another example. It’s for a niche dongle used in a factory. There are 100 users, each wielding such a dongle, attached to their PCs. The manufacturer issues a driver update. The site admin pushes this driver out to the 100 machines requiring it. Unfortunately, the manufacturer couldn’t afford to get their driver approved by Microsoft, or needed to ship it urgently to overcome this CVE before it was exploited. Suddenly, 100 machines have got an unsigned driver installed!

The AI of course notices this and very quickly issues a bunch of alarms:

This alerts a human who then has to begin the process of threat hunting. What does that entail? Of course, it varies somewhat from incident to incident but in this case… What are these DLLs? Where did they come from? Why so many, so suddenly? Whodunnit?

It’s all in the logs: First step – does the filename or path give anything away? It may do, but it’s unlikely to be enough to have much confidence – renaming your malicious DLL to at least look like something real is probably in “Hacking 101” – we’ll need to dig deeper than this. Who put it here? Well in our working example here, it was an admin user, the logs would confirm this, but again, it’s only of limited value. What if the admin’s credentials have been exposed? Perhaps we’d dig into the other recent activities of the admin user to see if there are any IOCs there. Assuming there aren’t, we are now left with the question “Why has this admin pushed out an alarming DLL to 100 workstations?”

“Why does the DLL trigger alarms?”

We need to take a closer look at the DLL. What else can we see about it? File hashes are handy here, again, the hash of the DLL will be in the logs. Not just one either, we’ve got SHA1 MD5 and SHA256. By submitting the DLL (or its hash) to a service like VirusTotal, it will compare the intel from 60+ well known security vendors and offer you their standpoints. Moreover, if you don’t have the DLL on hand, you can gather additional details from here which may be of use.

Having submitted our file hash to the checker, and finding it’s come back clean we’re no closer to understanding the why of the alert, but we’re starting to get a good sense that it’s not actually  malicious – it seems to have been deliberately deployed to a bunch of workstations by an admin account in apparently good standing and has not been flagged by any of the main security vendors as being suspicious. It does appear safe, it is looking likely that this is a false positive. We don’t need false positives clogging up the alerts dash, so let’s dig deeper still to try and understand what’s raising the alarm. Back to the SIEM logs, there’s plenty more here to pick through.

Is the DLL signed? Yes. Was it signed using a trusted certificate? Yes. From a trusted Vendor? Again, yes. Ah, but what’s this?

 

 

There’s the why – the signing certificate has expired! We have most of the pieces we need now to make a reasonable diagnosis-

The site admin, whose account is in good standing has made an absolutely typical admin-change, and pushed out an entirely legitimate update to a group of machines. Unbeknownst to them, the update is not signed according to best practice and has hallmarks of an attack. This has triggered the AI to bring it to the attention of a human, who has conducted “soft” analysis and reached the conclusion that this is likely safe. We can now close the loop by contacting the site admin directly to enquire as to the nature of this event and sure enough, they confirm our hypothesis. These would then be marked as safe, based on a combination of the criteria we’ve talked about here – we can take the file path, the file hash and a couple of other bits and create an exception to prevent this alarm firing the next time this particular update is installed.

Of course, these are just two examples of the myriad ways in which our SIEM service helps to transparently protect your users from cyber threats. In most cases, the analysis is deeper and the conclusions less clear cut, but this serves our purposes for a demonstration. We haven’t even discussed log aggregation from network devices, Cloud services such as AWS or Azure – the more data we ingest, the better we can protect you – and it’s not just the desktop which is protected, the same powerful AI can of course be aimed at the logs from your servers, firewalls etc. There are currently just shy of 700 different “rules” in place to analyse logs and this list grows frequently as new vectors are uncovered.

Do come and visit Factory Internet at International Cyber Expo (stand G25), we’d love to show you a demo and have a chat!

To register for the event, visit: https://ice-2022.reg.buzz/e1

​​​​​​