Detect the Next Sunburst Attack

TERI ROBINSON: Hello, all.

My name is Teri Robinson, and I'm the executive editor for SC media.

Welcome to our democast, detect the next sunburst attack, sponsored by Anomali.

The Sunburst SolarWinds attack illustrates the dwell time problem we continue to see in advanced cyber attacks.

Starts with an undetected breach, with adversaries in the network trying to find the crown jewels.

And eventually, often months later, the breach is discovered and attack details are released.

At this point, security teams from other organizations that may have been targeted need to look back and search their event log data, 6 or if they have been breached.

Unfortunately, they often find out that they can't because they don't have the data online or the data is just not searchable.

In this democast, you're going to learn security analytics that can complement your SIEM to immediately answer the most fundamental question, have we been impacted?

Continuous retrospective search can speed threat detection, investigation, and response particularly, for critical events like the recent Sunburst SolarWinds malware attack.

And you can optimize interplay between analyst research tool, security analytics systems, threat intelligence platforms, SIEM and SOAR.

Before we get started, I want to just tell you that Anomali has provided additional resources that can be found under the handouts tab.

Our speaker today is, Joe Gehrke, solutions architect at Anomali.

He works with companies to build and operationalize threat intelligence programs and help solve some of their most complex challenges.

Joe's 20-year career in cybersecurity spans from security strategy to solution implementation.

His current areas of focus include systems interoperability, intelligence operationalization, and platform software development kit.

He is well qualified to lead this discussion, and I would like to welcome him here today.

Hi Joe.

Take it away.

JOE GEHRKE: Thank you, Terry, and Thanks, everyone.

I think most of what I'm going to speak to today is not a new challenge.

And some of the recent events with SolarWinds and Sunburst have just really brought this to the forefront, the challenge that teams encounter when they're asked to just answer what might be a very simple question.

And I think everybody that's on the webcast today is at some level familiar with Sunburst and then there's probably several of you that were actually tasked with determining whether or not your organization was impacted by that or maybe one of the variations.

And so on the surface, it's a really simple question, were we impacted by Sunburst?

But as we know, that's not really that simple an answer.

There's of course, the use cases where, yes, we were impacted.

If you were, well then all of a sudden we have to understand a complete history of maybe, when we were first impacted, what were the assets that were impacted?

Was there lateral movement?

What was the collateral damage?

All of those things are going to be important in framing the actual impact and the risk to your business.

And then there's also just the idea that, if we just look at this from the standpoint of, do I own the vulnerable product?

We're missing a lot of things.

And we'd all like to go to an application inventory and say, I don't own this product that was just breached or I don't own this thing that has been subject to a vulnerability for the past six months.

There's all sorts of reasons why these things may exist in our environment despite us not actually owning the product.

A big thing is always an issue, shadow IT.

A particularly in tech companies we have developers all over the place, there's a lot of freedom for them to install, to try on new software.

In fact, one of my clients that I work with quite frequently had just this case where a developer actually had access to a developer instance in SolarWinds.

Luckily for them, it was not one of the vulnerable versions but it is not a fringe use case, it happens quite frequently.

Another thing with long dwell times like Sunburst is you might be in the scenario where you once owned a vulnerable product you no longer do, and so even though you've moved on from that solution or that environment, that doesn't mean that you didn't have a breach or an impact based on how you looked six months ago, eight months ago.

And then of course, just the proliferation of this.

This is very sophisticated unique attack.

In Sunburst it was a supply chain attack.

We now know that every week it seems like there's a new vendor that's reported something.

So the number of impacted companies keeps growing and growing as does the intelligence that must be used to hunt for those impacts.

So it's a very challenging situation to not only answer that initial question, have I been impacted?

But also answer ongoing, am impacted by any of these other collaterally impacted organizations?

Last note here is, detection versus prevention.

We're really focusing on detection here.

Prevention of course is great.

And we'll have all sorts of time I think, in the coming weeks and months to understand how could we have prevented this attack.

But as a very, very sophisticated attack, I think, there's going to be a lot of challenge in identifying how we could have done that.

And these sophisticated attacks are going to occur time and time again.

And so rather than flat out preventing them, quick detection becomes critical as you'll see.

The earlier on we can catch these things, the more likely we are to prevent any damage.

So with that, just a little bit on why this question's so challenging.

Have we been impacted?

The first thing is data overload and we see this all the time even in what our quote, unquote, "big data solutions" there is just too much event data.

And so we're doing a few things there.

One is, we might not be aggregating all of the telemetry that would be helpful in identifying a breach perhaps or not sending in our network logs, our flow logs, or DNS logs just because it's too much or it's cost prohibitive.

And then at the same time, we have access to millions and millions of pieces of threat intelligence.

It's not uncommon for organizations of any size to be consuming new intelligence at those rates of hundreds of thousands per day.

So what are you going to do with that?

We can't take all of that and collide that in all of that data inside of our SIEM, those solutions just weren't built to do that.

And so what ends up happening here is that we do that on a smaller scale.

We say, "Well, this is what we can support.

We can support this level of log data, we can support this level of intelligence, and we can do correlation on that." And then we look for that on an ongoing basis.

New intelligence is reporting today, let's alert passively to see if we have that coming up in future logs.

And then, of course, there's always that concern, where, if I do this and I add more data, I add more intelligence, well, that's just going to generate more alerts.

So we find ourselves in this situation where organizations, number one, don't really have a good solution to do this large scale retrospective searching for past incidents but the reasons are numerous.

It's cost prohibitive in many cases where the current technology, they're afraid of all those alerts and that limited the number of intelligence just, the processing power that will be required to do that.

And to visualize this a little bit better, when we're talking about that data overload problem, SIEMs have billions of event logs per day.

And when we're doing that, we might keep that online for say 90 days.

Of course this is a variable, it might be a year.

Really depends on the industry regulations.

But there's also the distinction between what is hot storage and what is called storage.

And again, back to that original problem, have we been impacted?

It's not a quick answer.

And this is a very good reason why, because even if we are retaining a year's worth of data, chances are some of that's in cold storage.

And so it's not searchable until you go through a process to enable that historic data.

So even if it is available it becomes challenging to search through it.

Then on the intelligence side, they said millions and millions of data points out there, pieces of tactical intelligence that say, "Hey, this is a bad IT.

This is a bad file hash.

Here are my signatures that can help identify some [INAUDIBLE]." The volume of those is growing every day, and when we try to correlate that against our event logs on an ongoing basis, we'll find that there's just not a solution available in most SIEMs where we can collide all of that data together.

And so all that results in that very limited visibility.

We have limited visibility into historic logs and we're comparing that against a limited subset of the intelligence that my organization has available.

And of course, what we really want is all that telemetry.

We don't want to be constrained by the amount of hot storage, cold storage or just the overall duration that we have.

I think Sunburst is a great example of dwell time which I'll speak to you in just a moment.

And then same thing, if we have access to intelligence telling us things are bad, we need to act on that.

It's the easiest thing in the world to say, here's something bad, go do something about it.

And that's really what we need to do.

It's just that traditional environments are not able to act on that volume of intelligence even though we need to be doing that.

So when you combine this together now, all of a sudden, you're looking at all of your telemetry, all of your intelligence and you're doing that matching on an ongoing basis.

So to the dwell time problem.

Again, some us was-- it's a little bit unique in [INAUDIBLE] as a supply chain compromise but even after the impacted versions of that product were deployed, we're still looking at 180 days, Some of the initial code injection back in SolarWinds actually happened in early 2020.

They were registering domains used for command and control back in 2019.

So it's a very long lived problem that is, again it's not new.

I think the average dwell time that Garner and a lot of other folks quote is around 180 days, somewhere in there.

And it's very typical.

We're going to get in, we're going to look around.

So we'll gain that initial access, we'll find out if we're in the right place, we'll do some privilege escalation and then we're going to start to do the data exfiltration.

It always follows this path and by the time you know it, something's actually been released about this attack, or 200 days in.

But sometimes we can catch this in the middle.

So Sunburst again was very advanced and a lot of the intelligence related to that came out towards the end of their dwell time.

But that still was enough time for some folks to catch it in the act and to catch it early enough.

But the challenge with anything, Sunburst or any other type of threat actor or campaign, is that the moment the intelligence is released that says, here's what to look for, you not only need to alert on that going forward but you have to look backwards to understand if you've been impacted.

There's almost zero intelligence that's reported that has not been observed somewhere at some point, that's why it's being reported.

And then you of course, have to watch for that going forward but this thing just becomes the data problem back to the first one I discussed, which is too much data, too much threat and talk.

So thinking in again, a little bit more, if we were to look at this from the kill chain standpoint, we know that a lot of these breaches follow the same path, particularly, some of these sophisticated ones where there's going to be that initial poking around the reconnaissance phase, where nothing is actually being exfiltrated.

And if you overlay this with some of the things that happened with the Sunburst or whatever you want to call it, we saw that code injection back in SolarWinds a year plus ago.

And the actual vulnerable product was probably deployed more like the spring of last year and then they were low and slow.

They did a very, very, very good job of being stealthy in the environment to evade detection.

Once the code was deployed and they knew they were in an environment that could operate in, they waited a couple of weeks.

And then they dropped in some malware, teardrop was one of the earlier ones.

And they remained active for a very long period of time until the intelligence was deployed or they released by FireEye and others in December.

And so again, the whole idea here is if we can detect early in the kill chain, we're preventing a whole lot of damage.

And in order to do that, we need to act on these things very, very quickly.

And so what are the things that must be done in order to do this?

Well, one, you have to have all that telemetry online.

We saw if we can not look back to when the initial injection or the initial attack took place, we're never going to know or be able to build that timeline or fully understand the picture of what was impacted.

We need to do that automatically.

We can't simply have a manual process where we ask an analyst to take 1,000 indicators or 100 signatures and start manually going all over the place to ascend to other products to understand that.

Not only is that time consuming or maybe not even possible depending on the data that's online, but it's very, very error prone.

So we need to do this automatically, we need to do it quickly and we need to have ways to visualize the timelines to get those answers really quickly all with a view to accelerating that meantime to detection.

That is absolutely critical when we're talking about detection minimize the impact.

The other thing that's going to be important to enabling analysts to do this, is to do it in an intuitive way.

Threat intelligence for the longest time has focused and still does it to some degree on tactical indicators.

Tactical being things like a file hash or an IP address or a domain.

And we saw all of those present in the Sunburst attack and we'll see all of those types of indicators present in the next attack.

No secrets there, and that's what we need to effectively do the correlation.

But me as an analyst, I don't want to be in a position where I am manually going through those lists of things and searching on them.

I want to be able to intuitively say, "OK.

Sunburst, it's from an APT.

I'm going to search my environment for Sunburst and get an answer." Not only will that give me the answer if I've been impacted by this specific breach, but then it allows me to pivot to say, "OK.

This particular malware family that I now know exists in my environment has been used by this adversary." And I can pivot and look for other evidence or other impacts that might be related to that same malware family.

So it's the speed to the detection, it's making it more intuitive to detect, and then it's making sure that you're covering all of your bases with that.

So all of this together is where at Anomali we are very, very focused on these questions in the detection side of the house.

It's addressing each of those problems.

Number one, the data that's available online.

We have to be able to cover the dwell time for these threat actors.

That might be a year, that might be two years, it might be three years.

You never know what it's going to be.

We have to be able to take all threat intelligence.

We can't arbitrarily be drawing lines where we say, "This threat intelligence is important, this is not." We know there's always that chance that something that you think may be less important to you actually has had a serious impact to your environment.

So we want to do that on a large scale.

And then of course, threat hunting on demand.

This whole idea that I'm asked, "Have I been impacted by Sunburst?" We need to do that quickly, we need to do that intuitively.

And so with that, I'm just going to show a little bit of how we accomplished this inside our own solution.

So first is the intelligence itself, and this is widely available.

No secret here.

And our threat stream solution aggregates intelligence from all over the place the moment the indicators, the signatures were made available to help hunt for something like Sunburst, they were available inside of our platform.

And so what we're seeing here is simply the visualization of all of that data.

And this is step one.

Having this all in one place normalized searchable, being able to see how those indicators are flowing in from which source, that's very important because it's an organized way to get the intelligence in one spot.

And it's essentially making it machine ready.

If I want to use this to go hunt for something, now it's ready.

If we were in an environment where we don't have the tools or the capability available to aggregate intelligence, we could still get to this data but it would largely involve going to different sources like FireEye or SolarWinds or even GitHub where they publish things and manually compiling these lists of intelligence.

And then the next step is even harder.

That next step is saying, "Now that I've got these 1,000 pieces of tactical intelligence, how do I effectively search historically in my environment for evidence that I have seen these?" And that's where that enormous amount of time comes in if I'm even able to do it.

And if I'm not able to do it, it might be that whole reason where I don't have enough data online.

So with our Match solution what we're doing is we're taking the source of intelligence which Sunburst is one campaign among hundreds and hundreds that will be updating every day as new ones come in.

It contains 1,000, That's among just a small fraction of the hundreds of millions of indicators that some of our customers have access to.

So now we want to ask that question.

Have I been impacted by Sunburst?

And there's two ways that we see our users go about doing that.

One is this ad hoc ability to do it.

And Unit 42 has done a great job over at Palo to summarize a lot of the indicators in the tactical intelligence involved with this, they call it solar storm.

And using our natural language based browser plug-in we're able to identify not only the content that's on a given web page but also instantly tell you, have I seen any of those observables or those indicators inside my environment.

Every one of these that has a red box around them indicates that I've observed that in an event in my environment.

So this is that ad hoc approach where I'm viewing information maybe about a particular campaign, about a particular threat actor or whatever it might be, and I just want that quick answer, have I been impacted?

And the answer here is very clearly, well, yes, I have been impacted by this.

And if I wanted to get a little bit more detail on one of these, where I could view this inside of Match and it would take me to a view showing the individual events that in this case contain that beacon out to one of the domains that's been associated with the Sunburst breach.

You can see here I've got in the last three months.

So that's one ad hoc entry point to how we would go about doing this.

The other one is if I'm just simply asked to look for evidence of Sunburst.

Well, what I might do here is simply type in the Sunburst campaign.

When I do that, I'm presented with a consolidated view of the indicators associated with Sunburst and I'm executing a search against all indicators associated with Sunburst, against all of my historic data.

And as you can see, if I do that here in my environment I'm presented with So it's very straightforward now to take a operational or strategic piece of intelligence, like Sunburst or like maybe APT 29 and ask the question, have I been impacted by that threat actor or by that campaign?

And the answer might very clearly in this case be, yes.

I have been impacted.

And at the same time, we can start to build visualizations out around the same concept.

Here I've built a simple dashboard that shows in fact, those Sunburst matches in my environment which helps me to paint the picture of the timeline from when I was impacted to some of the activity.

And this might be a very typical view for an impacted entity, where we deployed the vulnerable product back in July, we started to see some activity, it slowed down, it picked up back again.

So again a very intuitive way to ask the question.

And the last part of this is, those were two manual approaches to identifying if I've been impacted by a particular threat and those will always be relevant.

We'll always have that threat hanging use case or having to respond to management to say, yes.

I have been impacted.

Here's the evidence, or no, I haven't.

Here's the evidence.

All of this, though, is being done automatically already.

We are taking those 100 million indicators that we're aggregating at the threat intelligence source and every day we're automatically looking backwards in time at the tactical level to tell you if you've been impacted.

So for our customers using this, they would likely have written a rule that said, any time.

I have a correlation against a tactical piece of intelligence that's known to be associated with a APT threat actor group, I'm going to automatically create an alert.

So that's the way that we at Anomali approach answering what has been a difficult question to answer, which is, have I been impacted?

And with that, I will open it up for questions.

Jane, we've got one coming in here.

So does Anomali also correlate IP addresses for known threats?

And the answer is yes.

So we use available threat intelligence to look for occurrences of that threat intelligence inside of logs and that certainly includes IP addresses.

So our threat intelligence repository is made up of a lot of different types of observables, IP addresses is certainly one of the bigger ones.

And the others might include things like file hashes, domains, URLs, even things like cryptocurrency addresses.

But those are the primary pieces of tactical intelligence that we would use to identify, say, an internal asset making it out to a known malicious IP address.

TERI ROBINSON: Hi, Joe.

I'm back in.

Thanks.

I do have some more questions here, is Sunburst typical of the types of attacks you are able to detect?

JOE GEHRKE: Yeah.

Another good one.

I think it is typical in the standpoint of the timeline and the dwell time basically.

Certainly Sunburst atypical from the sophistication of the attacker but from the footprints, the dwell time, that is very typical and this is the type of content that we have inside of our thrusting platform that's available to do that type of threat hunting on an automated basis.

TERI ROBINSON: How is Match any different from a SIEM?

JOE GEHRKE: Another good one.

So the idea with Match is that we're not replicating the set.

What allows us to keep a lot of data online and hot and searchable and to constantly be colliding that against all intelligence, is number one, it's purpose built to do that, number two, we don't look at the full event as it comes in.

So if we take a firewall event, typically you might see 60, 70, 80 fields.

We only care about a handful of those which would allow us to do the correlation and then we link back to the original event to provide that context.

The result is a footprint that's very, very tiny and would just allow us to laser focus on that retrospective correlation SIEMs will do a whole lot more in terms of assisting with response, getting other types of data in there and so on.

TERI ROBINSON: Thanks.

What's a good way to be proactive or move toward more prevention?

JOE GEHRKE: One of the things that we see with this all the time is that the moment intelligence is reported, you really should be doing two things particularly if it's a campaign of the magnitude, something Sunburst.

One is looking historically understand if you've been impacted and then the second is taking that same intelligence and deploying it to preventative controls.

If somebody is telling me that this domain is being used for the attack, I have, I mean, I should without a doubt take that domain and block it whether that's in my firewall or my proxy or whatever it is.

So even in these cases where we're focusing on detection, it's always a two pronged approach.

Understand my impact and deploy the same intelligence to those controls that can prevent it.

TERI ROBINSON: Well, that's going to have to be it for this session.

Don't forget to grab the additional resources from Anomali found under the handouts tab.

And just a reminder that this webcast will be available on demand beginning tomorrow on scmagazine.com in our events section.

I want to thank you for being with us here today, Joe and of course, thanks to everyone who tuned in.