Connecting the Dots with Anomali MHN and the Cyber Kill Chain: Detect ‘18 Presentation Series

My name's Dave Empringham.

I'm a principal sales engineer out of Canada.

I work with a lot of customers in the FSI industry, as well as energy.

And I built this presentation with the help of a customer who is in the energy sector.

And so we're going to be talking about how they've employed a few tools to help them detect APTs.

And some of those tools are modeling with the cyber kill chain, the Modern Honey Network, and Anomali solutions.

I don't want to belabor some of these slides, but I want to make sure that we-- depending on who the audience is.

We have some technical people.

We have managers.

Is everyone technical?

I just want to get a feel for who's here.

Technical, technical, technical.

OK, some management.

Not very much.

APTs, obviously.

So advanced techniques, motivated users, sophisticated TTPs targeting organizations-- for something.

Could be code, could be monetary value, could be disruption.

And so the trick here is being able to understand what they're targeting, why they're targeting it, and the attacks that they're using, and that methodology that they go through, OK?

Obviously, the cyber kill chain was developed by Lockheed Martin.

The thing that-- when I was making this presentation with our customer, I always knew it was about the identification of the phases of particular attacks, but I had never flipped the coin over and said, well, how do we use it to prevent attacks?

And so we're only talking a lot about that today.

I've mapped it out here to what the particular characteristics at each layer.

What's interesting is when we were going through the exercise and looking at actual production data with this customer, most of our detection was happening at the C2 layer, rarely at the installation layer.

So we were actually having to work backwards from all this.

But as we go through, we talk about reconnaissance and weaponization, some of the examples are, hey, we're looking at IP scanning as the type of scanning behavior, the types of scans, SMB, remote desktop, things of that nature.

Weaponization-- what are they doing?

They're trying to exploit vulnerabilities on particular hosts.

Well, how do we determine where those exploits lie?

Some of the tools, obviously, are vulnerability scanners, patch management, things of that nature.

But delivery, what are those avenues of delivery?

Can be emails, can be email attachments.

Phishing's a big thing, as we heard in this morning's talks.

The URLs, that's part of it.

But also thumb drives or USB drives.

And some of the customers that we work with have very strict policies about using thumb drives, and even going as far as shutting down those USB drives on particular servers or corporate assets.

Exploitation-- this is the point where we're seeing attackers actually gaining access to systems.

We also see a lot of failed attempts.

And this is where IPs and other security controls come into play.

So as they attempt to work through their arsenal of exploits that they're targeting particular servers, IPs is going to trip.

We're also going to see as part of the phase before the emails and URLs where we're going to utilize sandboxing technologies to look at the attachments, to look at the different URLs, the files that are dropped, things of that nature, because that's going to help us in our discovery.

And then, of course, installation, where we start seeing the malware or the payload on systems, all right?

Attacker delivers the malware as part of an attachment or link, but they're looking to exploit specific vulnerabilities on systems.

CVE-2017-8758 is one of them, or 59.

And so we start looking at controls like EDR, or Endpoint Technologies.

We can start to utilize threat intelligence hashes, file names, things of that nature.

But getting our hands on those type of things, again, we're going to start using sandboxing and existing indicators already in the platform.

But again, it's at the C2 level and on the action on objectives where we start to see the actual behavior.

Beaconing traffic-- we see C2 communications where the attackers are actually executing commands on those systems.

And we want to see what they're doing.

And also, you may see lateral movement when we get down to action on objectives.

So traditional incident response-- so some of these screenshots are going to look a little offset.

It's because I had to obfuscate a lot of the data.

This is customer.

This is production.

They're using Splunk in the backend.

They're using Anomali products, and they're using Modern Honey Network.

So Splunk with enterprise security-- they've got a customized rule.

C2 possible domain beaconing.

We're way down the kill chain at this point, and he's seeing an internal asset beacon out to that particular domain.

Right away, that raises a ticket.

So he's got an automated process that's going to create an incident to block the mentioned URLs, OK?

Very simple, very straightforward.

But the rest of the attack, how it got in, we'll kind of stop there.

We actually want to work through the entire remediation so we learn what this particular source is doing and all their particular attack TTPs so we can start preventing more.

It's about moving from the tactical to more of a strategic.

Again, action on objectives-- after C2, we're starting to see domain admin queries.

So in order-- going to walk right through this.

Even the team in the SOC, they get an alert from the SIEM, hey, this command was executed.

OK, fine.

But we still need to do some digging to see if this was a valid command run by our admin group or this was something that's attributed to that initial communication that we saw at C2 level.

I'm just going to rip right through this.

OK, the key here is that attacker has to have either physical access to that system or remote.

In the case of a remote attack, it needs that command and control channel.

So the SIEM is doing a lot of investigating of the network traffic.

And these are some of the rules that were triggered, not just the domain beaconing, but also the command and control from some of the firewall set of rules that he had configured, OK?

So again, we want to identify the sources, the communication channels, the exploits or the commands that they're executing.

But now we're at installation, OK?

So another rule within the Splunk, we had coined it "hacker tools." So it saw, hey, the PowerShell is executing on this particular host.

It triggered this alert.

We're going to start looking at particular services on that asset at the installation level.

This is way harder than it sounds.

So if you're looking at a server or a group of servers, service or application whitelisting can go a long way.

But the reality is most of it's happening on laptops and user laptops.

So to pause and park this, we're now talking about policy, what's allowed, what's not allowed, what are you allowing your users to do, installing their laptops, other remote teleworkers, things of that nature.

This is not as simple as finding an executable or a service payload [INAUDIBLE] or tor.exe.

It's not that simple.

I grossly over-simplified that.

It's going to be a lot of other things.

So this means that for the next stage, you're going to have to start digging through all kinds of logs to find where the delivery actually happened, OK?

How did it get there?

A lot of times-- a lot of times it's easier to come back to this once we've identified what the actual payload was.

So how was it delivered?

We don't know.

Again, it's that avenue of was it emails or was the website that they visited?

Was it internal, meaning a user clicked on a link or executed the code themselves?

Was it a drive by pollution, so to speak?

Because again, how it got in is part of the whole puzzle that we want to prevent the next time.

Once we discover that payload, and that entails going through all the emails, all the other log files using your SIEM or using your centralized log database or tool to rip through all of the logs what you can find around that, we're going to use some of those files, some of those URLs, and we're going to heavily leverage our sandbox to determine what was involved with all of that.

So part of the URL, we drop that.

We see that the actual code exploited a couple things here, started some processes.

And we can start to glean that information out of the sandbox and put it into ThreatStream.

So I'm going to go through.

You can see, this is just some examples that we took.

They weren't related to the actual exploit that we were investigating, but you can see here, it could be an email attachment.

And you can see here that, as we detonate this in the sandbox, the top one, certain files, it's going to create a process.

And you see that the weird WMIC.exe under that directory.

If you're not going through the whole process, if you were to look at a particular system that was polluted, that wouldn't catch my eye, right?

But I've walked through backwards to find a URL or to find an attachment that's related to that.

And when I use the sandboxing technology, that's what it's dropping and that's the process that's creating.

Some of these were just-- I mean, it depends on the AV tool that you have.

They will categorize the detonation, where it's being seen.

And there's some other good useful information there.

But really, we want the detonation in the sandbox to create those indicators.

And I'll go through some of these.

There's a couple of things on these screenshots that I wanted to point out.

You're seeing a lot of command and control domains, the pretty funky Fowler hashes, IPs, but there's also the tagging structure on the side.

So if we were to pull out that one particular IP, tags were incredibly useful as part of this whole exercise of tying this together, not just with phase of the kill chain, but also the port, the services, the actual attacks that these particular sources, after they were done scanning, had escalated into exploit.

So it goes from recon to exploit.

And we're using tagging to get very explicit and be able to categorize or profile the nature of that IP and what we've seen it do.

I'm going to park all of that, because that was just kind of the run through of what we used SIM and some of the other pieces of information to get to that point.

We're going to stop and talk about honeypots.

I don't know how many people are familiar with honeypots, how many people are utilizing honeypots, or the value that comes from employing honeypots.

But they're really designed to bait or lure hackers, or, frankly, misbehaving users as well.

But they're there to mimic servers that are vulnerable, that have exploits on them that are not patched.

They're designed specifically.

They capture that data.

You can keep it locally in your own database.

We'll talk about MHN in a minute.

But you can really use it when you start to dig in and analyze that information, run the forensics, the threat intelligence.

And over time, you can start to trend what you're seeing those sources do against your network.

You can really use it as an early warning system.

Are those attacks targeted?

Are they attacking others too?

And you say, well, how do I know if they're attacking others too if they're my honeypots?

That's where MHN comes into play.

What is it?

It's the framework.

It was designed and developed by Anomali Labs.

It is designed to take the heavy lifting out of deploying honeypots.

And what it does is it's all about deployment, management, and it's designed to get the data flowing, meaning, what are they detecting?

Where is that data going?

Is it locally for me to use?

Do I want to hook it into the global database?

It is a community of servers, meaning it's not just you, if you're setting it up.

It's thousands of corporations or organizations or users out there in the wild that, again, they can keep some of their data private to them.

They can share it into a global database.

But again, sharing is optional.

Our Anomali Labs actually uses MHN data as part of our feeds, as part of the curation process.

So it's-- the value is immense.

And it gives you a lot of aggregated data on the attackers.

Now, how do we use that?

You can see some of the screenshots here.

These were from the honeypots that were set up.

We started to build very specific attacks reports.

And we were starting to see some trends, and we would pull that data out and start to look at those IPs and what they were doing.

Well, what did we do next?

We started to tag and map those indicators with kill chain phase, recon, to start with.

Because what they would do is they would come in and they would just blank scan the honeypots that we would set up.

But as soon as they found a honeypot of something they were looking for, they would escalate their targeting.

So it's not just a blank scan-- oh, I found a web server.

I'm going to start using particular exploits against that web server till something hits.

So again, if we're feeding all of this honeypot data into the SIEM, some of these rules are going to trigger for you.

This is going to give me-- this is triggering that this particular IP, their activity just escalated from just a recon to an exploitation.

They've stopped scanning.

They're now targeting a particular asset.

In this case, a honeypot.

And what they're doing is now very specific attacks.

So if I cycle through this-- oops.

I don't know if you can see the dates very well.

I screwed up the panning in.

So this one was the actual first one.

So we took the data out of the Modern Honey Network.

It is 5/25.

So 2018, 5/25.

Scanning IP.

We added two tags.

Reconnaissance-- but their activity escalated to a specific exploit.

So that was 6/06.

So the next time we saw them, they went directly to that particular honeypot, and they were using Oracle WebLogic security component remote code exploitation.

So they'd stopped doing the scanning.

They found something that they were interested in and they started doing explicit attacks.

So now, what we do-- or what we had done in this instance is another IP similar to it.

You can see exploitation.

First it was reconnaissance.

That it was exploitation.

Then it was an explicit attack.

So RDP server services, SMB.

And then an explicit attack against a web server, MS Windows.

The life cycle of the deployment or automation is we then sent that out to be blocked at the security controls, firewall and some other tools.

And we retagged it as ta-blocked.

So we know the particular status of that indicator if we see a TLP:RED tag on that indicator.

It's in flight.

It's out there in the security controls and we're actively blocking it to try and stop similar attacks from happening.

Now, to spend some time in ThreatStream, we use the Explore function.

So we have been putting a lot of IPs into the indicators, into the ThreatStream, along with the tagging.

And in the Explore feature, we can look for specific tags.

Reconnaissance-- they're doing SSH server sweeps.

Or exploitation, where we're doing word press attacks.

And we start to see this cross-correlation of these particular IP addresses all coming from the same ASN and they're on the same subnet.

So again, this is building up to what we ultimately uncover is this.

So it turned out, as we started doing more digging on the far side, those are the group of IPS that they are actually tagged with exploitation.

And they were doing a particular brute force.

And those were all the IPs that were attempting to log into this particular customer's Office 365 infrastructure.

Now, on the other side, we were also looking for the same tags.

But when we do this, the listing that it gives us are there's a small little grouping there of IPs that other organizations have seen, and they've chosen to share it out to the greater community.

So if you were to look in ThreatStream, you're going to see the source that reports the IP.

That's what it's giving you.

There is yet another group of IPs as we continue to look for RDP server sweeps, web server sweeps, SMB, yet seen by other organizations that have also chosen to share it out.

But they're all consistent with the ones that we've seen as well.

So this was everything that was happening at the same time.

And we were using ThreatStream to get a handle on, is this particular-- are we targeted by these ones?

Are other organizations seeing it as well?

Now, I had mentioned before that we were sending all the honeypot data into Splunk.

It's just data.

We were just slicing and dicing and julienne frying.

And we were able to go by the honeypots that we set up.

And you can see there's five here.

There was a lot of other ones that we set up.

But then we were categorizing the source traffic of where the scans and the attacks were coming from, and we were breaking it down by country.

So you can see Brazil, China, Ecuador, France, Germany, Japan.

And this is all real data.

This isn't mocked up.

So this is where these attacks were originating from.

And the counts.

Again, I screwed up my fade in.

Now, we were also tracking the brute forcing of the accounts against these honeypots, the user, and the password.

Now, even if on these honeypots, or even on servers, if you're not set up a whole lot of OS logging, you're able to at least log the attempt, the password, and the command that they had run.

So this is all now in Splunk.

And we were able to attribute the actual command and start to put in additional tagging in some of these indicators.

Now, what's happening behind the scenes?

The previous slide, you saw that kind of Death Star looking things.

The real life scenario was there was 1,500 users, or 1,500 IPs all executing one username and password.

It was a very eloquent attack.

That made sure that they didn't trip off any alarms of someone trying to brute force.

So we picked up a scanning IP that did a broad scan, found something.

Then it said, I can do this.

Started using very explicit exploits.

We escalated.

They're now in a new phase or a new phase of the kill chain.

And it turned out that as we peeled back the layers of the onion, there was even more IPs doing this one username and password per IP to try and attempt to get into things.

Now, we then sent everything to Anomali Enterprise.

All of the log data from SIEM, all of the indicators that we put in ThreatStream.

We were building customized threat balloons, making sure that we could drill down on things and seeing how far we could go back in time.

So all of that is now culmination of where-- yes, you've got real time correlation.

Yes, you're seeing things trip today.

You're using a honeypot to detect certain TTPs.

But what about back in time?

If you see something today, how long has it really been going on?

So what we'd like to do is we always like to start in the multi-dimensional dashboard.

And not necessarily we're looking at attacks or the categorization of the attacks or the indicator itself, but my-- say my colleague-- my customer would start at the ports, because he was setting up-- because they're in the energy sector, they were setting up honeypots to mimic SCADA devices, because they're Grid Control, oil and gas, all kinds of things.

port for SCADA controllers.

And so right away, when he clicked on port 502, we found a particular hacker, an IP on port 502.

We had brought in all the logs from Splunk.

It's five days old, this particular match, and there's been five matches.

And you can see the different tags here-- exploitation, ADFS, brute force campaign, right?

So trying to get in through a SCADA controller to get to the bigger jewels, which is Active Directory.

And start to escalate their privileges within the organization, all through a SCADA controller.

Because they're pretty loose, right?

So not only that, when we're bringing down vulnerabilities and other threat bulletins, we were making matches on that as well.

So eight matches across the 350 million events, eight different data sources.

And when we go back through a year's worth of data, we actually found 13 matches.

And because we had spent the time and all the indicators to map kill chain and use tagging explicitly, we were able to then build out at the timeline.

And you can see all the different sources, all the different victims within the organization, and start to utilize these group of IPs and start to block them at the perimeter.

So again, utilizing a honeypot, getting rid of the wheat from the chaff, just the scanning IPs to ones that are escalating their techniques into something more, targeting and exploit.

And start to block them, start to utilize them in ThreatStream, and get them out into the other security controls.

And we could build out the timeline for that.

So again, there's a whole process of using multiple tools, not just SIEM, not just real time correlation, not just ThreatStream, but moving to that more strategic, I need to find out who is looking, who is probing, who is touching based on the honeypot and the Modern Honey Network.

And then leveraging that information, again, not just in the SIEM, but also back into ThreatStream and pushing that out into AE so we could go hunting and do some deep diving.

And ultimately, uncovering something that had got through.

So I know that was really quick and short, but it is the end of the day.

Are there questions?

Lots of questions, because again, I spent a lot of time working on this with our customer.

It's really neat to see-- Would you spend a minute saying how zealous our client is [INAUDIBLE]?

Oh, yeah.

So our customer, he is a constant contributor to DEF CON, Black Hat.

He is very savvy.

You give him a little something and he'll take it and run the length of the field.

He's very interested in AE and its connection to Microsoft.

They are a big Office so he wants to be able to pull that information down there, a full window shop on all their assets and their endpoints.

So being able to have that in AE, he's all over it.

So that tie-in and bringing in even more log data, not just from the SIEM, it really resonated with him.

There was a question in the back.

So one of the [INAUDIBLE] do you, as far as [INAUDIBLE] has your customer put [INAUDIBLE] strategic deployments of certain honeypots in [INAUDIBLE]??

Yeah.

Yeah.

So he's got both going on.

The five that I showed you in the Splunk, that's just a few that resonated to this use case that we walked through.

He's got a ton in all the different segments where he's got them strategically placed out there.

And a lot of times, he will say it is early warning system.

Oh, I saw this guy from Korea like two nights ago.

He's back again.

He's looking for something.

He's always on the lookout.

It is an early warning system for him.

And so he will lifecycle that pretty quickly through.

We were slow to say, oh yeah, the SIEM tripped and we raised an escalation.

He will fully admit that process probably takes about 12 hours in his organization because it's multiple teams.

OK.

I was going to say, because wouldn't he [INAUDIBLE] or do mitigation as an action on [INAUDIBLE] on new honeypots [INAUDIBLE].

Yeah, I don't know if he's doing that, per se, but I know what he's doing is he's got some of that set up which will just automatically-- send it automatically to block at the perimeter to shut them down.

Do you have any statistics on the percentage of IPs that appear to be from Korea but that are really not from Korea because some smart hacker uses that as a launchpad?

You know what I mean?

Anybody who's smart enough that the hacker [INAUDIBLE]??

If there was statistics on that, it would make this a whole lot easier.

Is this difficult?

Yeah, it is so-- actor groups will typically-- it could be several hops, right?

It's all about the infrastructure that they own.

And I say that own, they either are controlling.

They've either got a small ISP in their back pocket who turns a blind eye, or a hosting service, or-- and it could be several hops.

Or they've leased from another actor group.

And so they'll hop two or three times across the world, back again, to hide their tracks.

Yeah, I don't have specific statistics.

I don't know if anyone's got statistics.

[INAUDIBLE] really great method of sharing whether or not their primary, that's their primary source, but if it comes off hosting [INAUDIBLE] something secondary, you can bet it's probably the jumping off point.

Yeah.

But to get the true aggregation, you have to take another step into the metadata or like build it on PowerShell.

[INAUDIBLE] just used in [INAUDIBLE],, something metadata will help you-- I'm just wondering, because you mentioned hunting and [INAUDIBLE].

So I was just wondering if the hunt revealed that x percentage of time, it's mostly a hop [INAUDIBLE]..

Over time it might.

The whole reason this came about was because when we first started going down this, the amount of indicators in ThreatStream that are scan IP are millions.

And you just can't shove that out to-- there's no point.

So we came at it from a different perspective.

We used honeypots and MHN to look at things that are only relevant to the organization that are scanning me, and then escalating the privileges.

We'll use those, because that's going to take my-- the amount of indicators I need to push out, either to the perimeter or actually use in my Splunk or SIEM, down greatly.

The same with C2 domains or DGAs.

They're so dynamic and volumous that you can't push them all out.

Again, what I found interesting, and I hadn't really stopped to think about it, was that all of our detection capability, the correlation, generally happened at the C2 level.

It's when we start to see network traffic in the beginning, right?

And most of the time, that's where we end it.

Oh, we've got to block that.

OK, but we still have a problem.

Even if that internal host were blocking it from going outbound to that, it's still installed with something.

We haven't fixed the root cause.

It's all about fixing the root cause and then using that information strategically to-- as preventative medicine.

If we understand more about it, then we can stop it next time.

If there is a next time.

A lot of times it morphs into something else and we're kind of back to square one.

So as some organizations move toward a VDI solution, capturing the packet for traffic to be [INAUDIBLE],, whatever the [INAUDIBLE],, becomes increasingly difficult depending on your response option.

Do you see a way forward to help solve that [INAUDIBLE]??

Off the top of my head, no, other than in our embedded sandboxing technology within ThreatStream, it does do a PCAP.

So while you're detonating and creating indicators for use in the SIEM and your perimeter, as part of that import session, you still have a PCAP file that you can use for analysis.

Is there any way to compare that next time or utilize that in other tools out there in your network?

I'm not sure, to be honest with you.

I see everyone's eyes closing.

It's the end of the day.

It's 5 o'clock.

[LAUGHTER] So [INAUDIBLE]?

I would.

[INAUDIBLE] I always-- we used to think that honeypots and honey nets were for kind of the advanced, the elite.

When I started to really dig into MHN, it's really simple.

You just need to have the infrastructure.

And a lot of times, if you're heavily virtualized, it's pretty quick to stand up a really lightweight Linux machine to play honeypot.

And even if it's only there for a week or two weeks, you're still collecting that data.

Take it down, it's still in your tracking database.

Stand up another one.

And that's the beauty about the MHN, because it's a framework.

It's getting the data flowing.

But that's kind of your database.

And you can leverage that.

Stand it up, take it down.

Stand another one up with different services, take it down.

And see if that scanning host starts to move along with it and find the new-- again, if you're going to re-utilize your IP addressing scheme, he may come back to the same IP address and say, oh, there's something new here.

Yeah, that's something up, right?

Yeah, so it's funny, when we were doing this, we would stand one up.

And you could instantly tell the script kiddies from APTs.

Script kiddies would-- they would bang away on it like it's a real Linux machine.

And nothing returns from a honeypot ever.

It doesn't-- like, it just tells you, oh, I'm running this and I've got these ports open.

OK, awesome.

But an APT will come back and just little hits here and there, find out fingerprint.

And then leave it alone and they'll go away, do some other things, and they'll come back.

And they'll start using, then, explicit-- if I find port 80, do something else.

[INAUDIBLE] what specifically is running.

And depending on the honeypot and the configuration that you've set up, it can say, respond with this specifically.

And he'll use a direct exploit on a particular vulnerability.

And that's what you're looking for.

That's where that [INAUDIBLE] actions, but it depends on your [INAUDIBLE] level of expertise that you're comfortable with.

That's right, yeah.

You can customize it for your answers, but you'd also [INAUDIBLE].

That's right, yeah.

Hi, awesome talk.

Had two questions.

Sure.

First one, what is your-- it sounds like you [INAUDIBLE] customers for a while and [INAUDIBLE].

What is your typical [INAUDIBLE] and scanners active for-- so you find it attacking your honeypot, let's say, and of course, [INAUDIBLE] what is the average date that you see scanners actives that you try to say whether you block alert, et cetera, or for what you detect in your honeypot [INAUDIBLE]?

Depending on the services that we set it up for.

The SCADA ones we would leave for a lot longer, because if you're-- have any experience in Grid Control or energy, oil, and gas, SCADA controllers are pretty standard fare unless-- and they don't go through too many firmware updates very often.

Their longevity is quite long.

Web servers, other things, pretty quick.

Maybe two weeks.

You would consider that IP as a valid indicator for approximately two weeks [INAUDIBLE] web server honeypot.

Is that about what you're-- just a ballpark.

Yeah, again, kind of like what I said before.

If you stand a honeypot up that's going to serve up port it for two weeks, and I have the same IP coming back, there's a pretty good indicator that he's-- I'm targeted.

He's not scanning a bunch of other IPs.

He's targeting that one.

If I take it down and I bring something up with a different port, maybe it's an email server, something like that, and he switches gears and continues to attack that, A, I have to question his sophistication.

He's obviously persistent.

But no one stands up web servers with domains or URLs and takes them down, and up and down, and puts different services on them, right?

Email servers, a little bit different.

If they're really crafty, they're going to look to see how it's configured as part of that fingerprinting.

Each service that you stand up is probably going to have a different time range.

You saw the two-- so one was the first time we put the indicator in.

That was like-- date was 5/25, May 25th.

The second one was June 6.

So that's about two weeks, where it took from going to scanning to he's now elevated what he's doing.

He's now gone from recon to exploitation.

I don't know if it's a thumb in the wind, but it's-- Question two, [INAUDIBLE] just curious if you've done any research on [INAUDIBLE] unfortunately, they're a little easier to fingerprint.

And my smaller honeypot might look like [INAUDIBLE].

Have you done any research or any just off-the-cuff estimates on how many scanners you think detected you as a honeypot and left you alone, or did things that were-- attempted to run scripts that were identified to try to identify your own pot immediately, versus which actors did not?

I personally did not, working on this whole exercise, but I am positive my customer has dug into that.

That's part of his whole MO.

The longer he leaves them up the more he's tracking what they do.

And knowing him, he's probably opted for not making it just a standard, easy honeypot that looks and smells like a honeypot.

This is going to look and smell like a real system out there that's got vulnerabilities on it.

That's why we opted for-- not only because it's relevant to his vertical, but the SCADA honeypot.

And he had tweaked a lot of the config files to say, yeah, I want it to do this, this, and this.

Because this is standard interaction when you attempt to log into this particular honeypot that's running this service.

If it's a cyber [INAUDIBLE] supposed servers, server that's [INAUDIBLE] not server?

Would it be suicide?

[INAUDIBLE] for months or years anyway?

Yeah.

Serve some function.

And is there anything [INAUDIBLE] anything that is increasing its vulnerability?

Vulnerability?

That's a good question.

Or it just can be used as just [INAUDIBLE]??

Yeah.

So the MHN is just the framework.

That is going to let you deploy honeypots out within your virtual infrastructure if you're going to use it.

Typically, you want that somewhat protected, and if you want a gold standard image, somewhat hardened.

It's going to keep your data protected.

Opting to share into the global database, that's a standard line of communication.

That's easy enough to set that up.

But I would keep that internal and keep that protected.

That doesn't hang out there with the honeypots.

Did that answer your question?

First part, just not [INAUDIBLE]..

Because if it is not changing the security profile of the server [INAUDIBLE] so it was just an additional function there.

It just protects port probing or whatever it's risen to.

I've never deployed a honeypot on a server that's already running something.

I've always, here's a new system.

Quick Linux box.

I'm going to stand it up, deploy a honeypot so it looks like a system.

[INAUDIBLE] address the issue about how much time we keep this [INAUDIBLE].

Yeah.

Can you install agents on these things as well?

Sorry.

Can you install additional agents, sensors.

Like if you wanted to install the-- I'm not very familiar with the MHN stuff, but could you install additional sensors or agents to detect outside of what the honeypot would be indicating?

Right, so to the best of my understanding, you can customize and configure your honeypot however you want it.

If you want it to run three or four different services on the same system, you totally can do that.

Typically, what we did is we stood up one that is going to do a particular function-- web, email, SCADA-- and left it at that.

I don't see why you couldn't stand up multiple services on the same honeypot.

It gets a little in the weeds to do with the configuration.

But that's just going to attract more flies.

Sometimes the balance between is it a honeypot, does it look and smell like a honeypot?

If you have like five or six services running on the same box and it's Swiss cheese, [INAUDIBLE] like yeah, it's probably a honeypot.

And if you do a particular command and it doesn't respond in the way you expect it to, they probably won't come back.

Although you did get the-- you did get the initial hit, but unless you're seeing followup evidence that it's now a targeted attack, it might be just a one-time passing.

Again, a lot of times that we saw the scan IPs when they're moving from scanning to exploit, their frequency became erratic.

It's not just low and slow.

It's almost hitting this.

Even those Swiss cheese ones, we'll still catch the less sophisticated one.

Right.

But it's-- again, it's wanting to separate the wheat from the chaff.

So they may be attempting-- they may have gotten their hands on a tool and executing a whole bunch of attacks against that particular IP.

It's not going to respond to anything.

That we would consider a script kiddie.

What we want out of it is curated indicators with our tags applied to it that we can then utilize in the other solutions-- ThreatStream, AE, on our perimeter, other security controls.

Because it's now targeted.

It's something we have to be on the lookout for.

Any other questions?

Thank you very much for attending.