Last Updated: 2020-10-01 10:40:47 UTC
by Daniel Wesemann (Version: 1)
Remember, back in the days, when the anti-virus vendors looked with derision at some of their competition, exclaiming "But they are using just SIGNATURES. Our tool detects BEHAVIOURS". That was like 15 years ago. Fast forward to today, with many of the same vendors now selling "threat intelligence feeds" for good money, and the most frequent attributes pushed over these feeds are MD5/SHA1 hashes and IP addresses. The main thing that changed is that we now call these items "IOCs" (Indicators of Compromise) instead of "signatures", but they still mostly are what they always were: Binary fingerprints that are very easy for an attacker to change.
There certainly is some value in detecting IPs and SHA1 hashes, but for most of these IOCs, their value rapidly diminishes within hours or days after the artefact was first sighted in the wild. With the bad guys making increased use of Cloud based infrastructure, and correspondingly rapid change and re-use of IP addresses, even the most useful IP address "IOC" can rapidly turn from an indicator of compromise into an "IOOI", an Indicator of outdated Intelligence.
IOOI - that's what I call it when we get a match on an IP that freshly came over a threat intel feed, but after analysis, we end up with the determination that our match is just for some innocent party who "inherited" a cloud based IP address that, hours or days or weeks earlier, had been used by someone else, for malicious purposes.
In 2013, David Bianco published his paper on what he called "The Pyramid of Pain" where he details the different types of "indicators", and the corresponding "pain" inflicted on attackers when these indicators are getting detected or blocked. The little snag about that pyramid though is that it is also a "Pyramid of Effort" for us in the defense to effectively detect the corresponding artefacts.
Matching against IPs and hash IOCs is trivial, once you collect the necessary logs. Reliably detecting TTPs (Tactics Techniques and Procedures) in comparison still requires some skilled and continuous effort for this detection to remain up to date, functional and relevant. But like most things in life, it is the more difficult and harder endeavours that are the ones worth pursuing. So if you haven't done so yet, take a look at MITRE's excellent "ATT&CK" framework, and the detailled real-life attack techniques described therein. Then, for each of the techniques mentioned, assess how good your current tooling and procedures are in catching these individual techniques. Be honest with yourself, and don't be discouraged by the gaps that you'll inevitably discover ... but then prioritize, and start plugging away at shoring them up.
Since you already have the capability to match IPs and hashes from your "threat intel feeds" against your logs, chances are you also already have the logs and capabilities in place that are necessary to go looking for TTPs. But unlike matching on IP and Hash IOCs, spending time on TTP detection will, over time, give you detection capability that is uniquely tuned to YOUR environment. And that's where the value is, much more so than in chasing matches for IOCs that turn out to be IOOIs.
If you have your own experiences with IOOIs, or with TTP detection capabilities that have a longer half-life than simple IOCs, please let us know or share in the comments below.
Last Updated: 2020-10-01 00:02:37 UTC
by Daniel Wesemann (Version: 1)
Chances are, you are quite familiar with the logs of your on-premises Active Directory (AD) domain controller. The corresponding Event IDs have been well documented over the years (though not thanks to Microsoft), and many blog posts have been written about how to use AD logs to detect Pass-the-Hash, brute force attempts, Kerberoasting, and more.
Increasingly though, we all find our Active Directory slowly (or quickly) migrating into the Cloud, and becoming an Azure Active Directory (AAD). Some of the old on-premises AD body of knowledge in detection and defense still applies, but most is obsolete. And - brave new world - AAD is usually exposed to the Internet in some form or fashion, so it is subject to all the noise that all the miscreants on the planet can fire against the IP address that happens to be yours.
As was the case with Active Directory, Microsoft isn't really making huge strides in sharing the knowledge needed to keep Azure AD safe, either. The https://github.com/MicrosoftDocs and https://github.com/Microsoft repositories are sharing some samples, many of which are outdated, but in general, the documentation is still kinda thin.
If you are like many small businesses or institutions who use AAD, but can't afford the full-fledged Microsoft offering with Sentinel, Azure ATP (now called Microsoft Defender for Identity) and other $$$-gadgets, you are kinda on your own.
You still should look at them logs though, because ... as mentioned above ... AAD is usually "internet-facing", and if there is any chink in your armor, the miscreants will find it eventually.
Rather than to stream your AAD logs back to on-premises into your existing ELK or Splunk or what-have-you, I'd suggest you look into connecting your AAD into a LogAnalytics space in Azure. It isn't exactly cheap, but if you don't go overboard with the volume or retention period, you'll find it useful. More info how to set it up, here: https://docs.microsoft.com/en-us/azure/active-directory/reports-monitoring/howto-analyze-activity-logs-log-analytics
Once you have this in place, you can use the Kusto Query Language to run quickfire analysis queries like this one, to look for failed logins that originate from the same IP, and hit several user IDs:
| where ResultType != 0 // failed logins only
| extend TimeBin=bin(TimeGenerated,2h) // in 2h interval buckets
| summarize IDs=make_set(Identity) by IPAddress,TimeBin // attempted usernames per source IP and time bucket
| extend targets=array_length(IDs) // count how many
| render columnchart // paint a pretty picture
which in my case, for the community college where I'm watching the AAD, is resulting in something like this for last week:
which in turn provides ample incentive to drill down further, and to also look into how to deploy some kind of automatic responder that bans this kind of nonsense, by pushing a temporary block rule to zap the offending IPs.
If you know of useful resources on how to monitor Azure AD, please let us know, or share in the comments below.
If you have more information or corrections regarding our diary, please share.