Looking for The Last Domain—A Practical Approach to Combating Modern Phishing: Detect ‘19 Series

CHRIS MONTGOMERY: All right.

You're here, Looking for The Last Domain-- A Practical Approach to Combating Modern Credential Phishing.

So full disclosure.

This is going to be a discussion about credential phishing and we're really going to get into tactical IOCs.

So if you're looking more strategic, APT group level, dark web kind of stuff, this is really for people that use a tool like Anomali and like geeking out on IPT domains.

I've been told it gets a little technical.

I don't really think it does too much, but that is what it is.

We're going to talk about phishing today.

We're going to talk about why phishing is so prominent on the threat landscape, where attacker innovation is going, and why.

I'll get into some of the details that we see the modern credential phishing evolving towards.

And then we're going to get into the mitigation methods.

And really it's about looking at a complex chain of events that is the modern phish.

And if you're using feeds and things that you would put into a tool like the Anomali platform, what's the best part of that chain of events to put in, look for it, and you'll get the most efficacy, and you'll be able to leverage that.

My name is Chris Montgomery.

I am from Proofpoint, which, if you're not familiar with Proofpoint, we do primarily email security.

But we do a lot of other things and it is just-- if you're a data geek and you're into threat intelligence, having the Proofpoint data set is just incredible because it used to be about hygiene and spam.

And now, where the threat actors have moved, it's really about advanced threats.

I mean, if you pull 9 out of 10 attackers, how am I going to get into an organization?

What's your preferred method?

probably to tell you, I'm going to start with an email.

There are other ways, but email is just kind of like the shortest distance between two points.

And in cyber security that's a straight line from the attacker to an inbox.

And if you look across all of the customers and look at enrichment of an email with an identity and get to see kind of attacker intent when you look at, OK, energy industry, and they're going after maintenance technicians or for instance, pharmaceutical.

They were going after this one individual and we're trying to figure out why.

Ask the pharmaceutical company who is that.

And turned out that this guy named Phil was the one who sent the drug trial data to the FDA upon drug trial completion-- which, if you're an Eastern European crime gang, it's really kind of interesting to be able to do some insider trading on that.

But that kind of data set, everybody's first attempt at getting into an organization, gives you an extremely robust and high contrast view of what's happening on the threat landscape.

So we're going to talk about that.

The genesis for this talk is really something that I trace sort of with my career was I joined Proofpoint from Emerging Threats.

And if you're not familiar with Emerging Threats, they're the organization that produces the ET Open and ET Pro, Suricata, and Snort Rules, and Intelligence feeds-- purchased by Proofpoint in 2015.

And what really put Emerging Threats on the map was the data that they had and the mitigation strategies that we could give you from a IDS perspective when exploit kits came onto the scene.

And instead of just saying, hey, I think that that's Blackhole or Angler or RIG, we had a research team that put together snort detections or a kind of detection rules that would tell you that is the landing page, that is the plugin attack, here's the encrypted binary, and give you this really cool chain of events of what would happen if you got owned via the exploit kit.

Well, we get to purchase Bullet Proofpoint and the threat landscape starts to evolve.

And what we've seen over the last, I'd say three to four years, is that exploit kit peaking with kind of the fall of Blackhole, the rise of Angler.

It really kind of left the scene like the exploit kit-- for those that aren't familiar, this was the Angler, Blackhole where you purchase a service that would keep up-to-date with CVEs and exploit code, and then you'd essentially put together an attack that was based upon some sort of CVE vulnerability.

They're not completely gone from the scene, but the activity, when you look at the last two to three years, is just a trend down.

Well, the reason we're talking phishing today is that the economy of traffic direction of maintaining the CVEs and vulnerabilities that would go into these exploit packs has completely shifted into phishing kits.

And the reason they're doing that is because it's just an easier way.

CVE vulns have a shorter shelf life these days.

And like I said before, it's just a shorter distance between two points.

Instead of going after and through and into your web DMZ, all I've got to do is find out via the org chart somebody that has access to the data I want.

And why don't I just get their credentials.

And if they've got access to the data I want, if I can own and be them, I can then get access to the data without having to develop malware or pay for CVE exploits via the exploit kits.

And that's why we see phishing and social engineering, in general, just explode onto the scene.

And so from a high-level threat landscape perspective, we've evolved kind of like this.

If we take a Hollywood view, you've got The Matrix.

And I'm using some sort of really cool tool-- in this case, the ultrasophisticated Nmap.

And this is The Matrix, and they're going to go after systems.

Well, attackers these days-- and maybe because we've done good things as defenders and we've defended systems really well, they're really going after people because people have access to the data they want.

If I can only become them, I am now an insider, and I've done something really interesting and easy by just becoming them and getting access to whatever it is or getting their VPN credentials or what have you, or I own an email account of a supplier and then send an email with no payload and just ask them to, can you send me the M&A docs again.

There's nothing to analyze there.

And it's something that if you look at FBI statistics, talk about BEC, It's like a $12 billion to $13 billion problem.

It's hurting us.

And unfortunately, from a vendor perspective, most vendor marketing is still here.

If you walk through an airport, you're going to see scary pictures of cyber alligators about all these crazy tools that you need to defend against Jason Bourne like malware where what we actually see the actor is doing primarily from our point of view is something like this.

Now we've taken a step down on the movie.

Ocean's 8 is no Matrix, but from a analogy perspective, they just nailed it.

Because they want to get into the Metropolitan Museum, they've got this ultrasophisticated security system.

And instead of going after like getting the Jason Bourne malware and things like that, they do what the modern attacker does first.

They go to Facebook, they do research.

And research is really easy to do these days.

There's a statistic that we have about click rate success on small phishing campaigns.

If you can put the zip code of the victim recipient in the body of the message, you'll have over an 80% click rate.

The lesson is, if you take your time, lower volume, do your research on social media or if you've never had an ex-lover or something like that, I hear you can go to things like ZabaSearch and get that zip code really easily.

And so you've done your research.

You find out this guy that runs a security system at The Met likes dogs and you craft a really interesting lure and you get what you need, which is his access and the plans for the data that they want by using some sort of social engineering.

And right now we have a pretty good footprint into a primary vector like email.

We've got like 80% of the Fortune 100.

We see a lot of juicy attacks.

is user interaction required.

So instead of putting some sort of CVE exploit code, you get the user to do your bidding by either click on a VBA macro or just give me your credentials.

And I'm a big proponent of MFA.

I think it solves most of this problem.

It works most of the time.

Let me give an example.

I had a customer-- have a customer that had MFA and they had Proofpoint.

And they got a phishing link.

And what you'll see in this presentation and what's challenging is that when you get a URL, there's no way to determine whether that URL is malicious or not upon delivery time.

So we send the URL online.

It gets sandbox at click time.

We analyze it.

And then all these alarms go off and we say that it's obviously a phishing link.

Go take it out of their inbox or go change passwords and things like that.

Well, they had an MFA.

So they click on the link, we analyze it.

We say it's bad, send all these alerts on.

The phisher, the attacker, is watching what we call the drop site.

This is the credential harvesting infrastructure somewhere that's going to say, hey, I've got a username and password.

And this was a fake O365 page.

And so they get the link, they click on it.

They see the dummy O365 page.

User puts in their username and password.

The drop site is this is for the dummy O365 page.

So they see a username and password.

The attacker sees their username and password.

Attacker goes to the real O365 page.

Types in username.

Types in password.

Sees a button that says push MFA.

Hits push MFA.

And the user logging in, trying to get into this document that has been shared on O365, sees they're flown and their MFA app blinking now and says, did you authorize this?

And they're clicking on buttons on the screen and they think, well, yeah, I'm trying to log in, click Accept.

And what that customer found out was that if you have a cached MFA cookie, you cannot revoke said cookie.

And in this case, the time out was seven days.

So they had to go nuclear on that user to actually remove the attacker from being all up in their stuff.

So MFA works most of the time.

This is just such an easy way to get what you want.

And that's why we see it most of the time, most of the attacks that we see on email these days are related to some sort of URL.

We see less and less of the Jason Bourne ultrasophisticated malware.

But don't be fooled.

The innovation and the sophistication isn't gone.

What the innovation looks like-- it's not that they're not doing complex things when they're doing social engineering and putting together these phishing campaigns, it's just moved into the cloud.

What we typically see is something like this.

Starts with an email.

Email has got a PDF.

PDF has a link.

Link goes to SharePoint.

SharePoint then goes to another PDF.

There's a link in that PDF, and that goes to the bad site and you get phished.

So they've moved everything from sophistication on endpoint to sophistication in cloud.

And the point of this whole discussion is that phishing, as dangerous and as damaging as it is, is a complex set of events.

And it produces a whole lot of artifacts that, bear in mind, we want to find the one that is the most actionable and usable.

And that's what's going to be the focus of the rest of the discussion.

The idea is you've got this complex set of events.

There is a spectrum of dynamicness to all of this.

Meaning we put the more disposable stuff up front.

As we move through the chain, things get more static.

So if you can find out what this is or where the credentials actually go to get harvested, which I put in the title, The Last Domain, you've got a more-- you've got better efficacy from your IOC.

This IOC is better than that IOC.

This changes per message or within seconds, days, weeks, months.

Sometimes you can get this drop site sticking around for six months.

If you find the drop site where the credentials go to get harvested, they can come through personal email, corporate email.

It's a block before the credentials become an incident and leave the organization.

So that's what we're going to talk about.

And the challenge to us and why I said that you can't really understand whether a link is good or bad at delivery time is that the attackers can now turn the campaign on or off depending on what part of the infrastructure they're in.

So what they can do is they'll typically send all these stuff, the PDF or the link, and then they'll put something on SharePoint that's benign for three days.

Let everybody analyze it and say, it's good.

And then as other people in the campaign get to their inbox, they turn it and basically make it malicious.

And they load something in there that is now a download or a dropper or leads them to the actual phishing site.

So that ability to turn on and off the campaign to redirect people to a 404, give them something benign to fool or file by sandbox, means that you've got to go look for the thing that's the most static, as well as understand that most of the time your email security provider-- and I think we're a pretty good one-- is going to deliver what they can't determine is malicious at the time of delivery.

So you're going to have to deal with this and come up with some sort of automation that says, I've got race conditions.

We understand now something's bad.

It's in inboxes.

Let's take it out.

So examples of this, and just how the attackers understand how email security is set up and then to go around it, let's talk about reputation systems.

And if anybody here uses passive DNS, well, if we look at this link-- and let me see if I can actually get that there because it's hard to see back there.

Won't zoom for me.

But if you look at that link, that was in the message.

And it is a real website.

So that-- yeah, I mean, like it's a real website.

And if you did the, let's check for anything, I don't want to actually allow anything through that was registered yesterday, that was registered like seven or eight years ago.

And it's got clean reputation and URL categorization.

It's probably going to be religious or health care or something, and they understand this.

Then they find some sort of WordPress vulnerability.

And what they do is they actually add a little bit of office misspelled twice or three times.

And if you go to that actual URL with the officeofficeofficelogin.php, it looks a lot different.

The idea is if you're using the whole let's like make sure the URL categorization is right and it's not risky, this wouldn't be risky, and it was registered eight years ago and it's got clean reputation-- except if you go to that one particular place that actually you arrived, you're going to get something that looks like this.

And if you're looking on your mobile phone, you're probably not looking at email headers, the actual link, and you're going to get phished.

But this completely gives the URL reputation system fits, send the email from something like O365, a compromised O365 account.

I mean, Office 365 goes through IP ranges like crazy.

They're blacklisted or they're not.

You just can't keep track.

It's totally a game of whack-a-mole.

They understand this.

This kind of stuff is going to get delivered and it's going to get clicked on.

The other thing that they do is-- there's a lot of security providers today, on some level, that would use crawlers.

And they'll say, hey, look I crawled the entire internet over the course of a week or two weeks.

And they're looking for templates or the code that is in the landing page.

And they'll say, all right, look, I might have crawled that entire website and went to the ministry website and they got there and I found code.

Well, there is code.

Again, the innovation is in the cloud that now looks for a particular reverse hostname or IP ranges and it's got to be a user behind a browser.

And if it's not, it's going to get a 404.

And so if you're using the crawler all the time, they understand, OK, I'm only going to serve up the badness to a user behind a browser.

And there's typically a little piece of JavaScript that will tell them yes or no or go to 404.

But the whole idea is there's a lot of code that goes into the phishing kit.

It's not just the old DHL login that looks like a GeoCities website from 1999.

There's a lot of this backend PHP code that's getting really smart.

Well, the thing for the threat intel defender to understand is that just like you reuse code and malware, you reuse code in the phishing kits and you leverage parts of the infrastructure for multiple campaigns.

And there might be an ultrasophisticated APT that wants to use phishing, but that might use certain code from certain kits that's actually good and it's going to save them time.

It's economics.

And so if you can look for code reuse or infrastructure reuse, you can leverage that to stop multiple campaigns or multiple actors or at least detect that.

Another thing that's becoming popular is SSL.

Web sockets are dynamic connections that will actually come up in the browser based upon what is typically a web object that comes down to the host.

So we'll see an example of this here in a little bit.

But the idea is there is a separate connection to go harvest the actual credentials that isn't where the landing page is.

Again, it's a chain in events.

And if you can find where that's going and understand the difference between the types of connections, this is something that you can identify and start going for.

What we found is-- we actually use a credential phishing sandbox that we'll talk about here in a minute.

And as the attackers have moved to SSL, we have a number of detection signatures from that Emerging Threat's team that will actually look for a clear text HTTP form post.

Well, we've got to be able to see it in clear text to put the domains and the IPs on the threat feed and understand that that is the drop domain.

And what we found is that if you ask to get phished in clear text, the actor will happily do so.

So we've got code in our system that actually says, yep, I'm going to submit credentials.

I'm going to give you a backup phone number and phish me, but do it over clear text.

And they're OK with it.

And we're able to actually see what domains in clear text are being used for this credential harvesting, which is the domain that we're looking for.

It's going to give you the most efficacy from a feed perspective.

And this is how it typically works.

So as you're looking at this, this is basically the Proofpoint credential sandbox, credential phishing sandbox, that was built by this guy named Jason Williams.

We call it Orca.

And he came from Emerging Threats and his background was network detection with Snort and Suricata.

And the idea was is there some part of this chain of events where I can find the digital Achilles heel.

We did it with C2 in the malware days back in Emerging Threats.

And what we found here is that it's typically the submission of credentials to the drop site.

That if you can find that, they can change all of this dynamic stuff up, but you've got a static piece that sticks around for a long time.

And if you've got that data, you're going to block multiple campaigns and possibly multiple actors.

So it works like this.

It's going to act like a human.

This Ow.ly link is what is in the message.

That is a phishing link.

We are not going to put Ow.ly on any kind of reputation system.

The bad guys know it.

And this is going to be unique basically per day.

So they'll send about 200 of these across the Proofpoint email base.

And then the next day, it's going to be something else because Ow.ly shuts it down or it gets unsafe browsers or whatever.

What this goes to is the redirector.

The redirector is where all some really interesting stuff happens the reader actor is encrypted.

The attacker set this up basically to do a lot of interesting stuff.

They can turn the campaign on.

They can turn it off.

They can geofence.

In my world, they can do some really nasty stuff like I'm only going to serve the badness to a particular ASN and I'm going to defeat cloud-based sandboxes.

Think about that.

That's pretty dangerous.

But you're assuming that the user is going to click within a corporate enterprise and sometimes you can get that.

There's some other things that we can do to look at a message and say, they've got to be perfect for that to work.

But you can do that with a redirector.

A redirector, once it qualifies what the user or the victim is the right victim, it's a user behind a browser, it's going to go to the landing page.

That landing page leads to a PHP backend.

And basically, they put it on a public storage site.

So we're not going to block Google.

You're not going to block Google.

And when I was tracking this particular actor-- this is a West African Nigerian confraternity-- these guys stuck out like a sore thumb.

So like what they would do is-- this was-- the date of this particular part of the campaign.

Josh T was the drop site domain.

Then it led to for harvesting.

And this is Monica gone.

So this was either a compromised account that was used to put the template on Google or this was actually like they had one that was like Ghost Rider and Global Pacific and then there was like for the titles LLC, which is if you've bought a house.

That's kind of what their intent was-- to get in the transaction between title, company, broker, buyer, and that kind of thing.

But this leads to a PHP backend.

At this point, you're going to see the login page-- which in this case, I know what you're thinking.

It looks pretty amateurish, right?

But this is designed to be read on a mobile platform.

And usually when you do a Proofpoint presentation, they always want to say, hey, man, I want to see what they saw because I want to play like what I have clicked.

And when I did this one, instead of giving it in 1080p, I just held up the phone and said, would you have clicked on that while you were walking into a meeting during lunch when they sent this?

Absolutely.

This was clicked on within five minutes by three different customers.

And it's very effective.

It's amateurish as it looks.

Now, remember that web object I was talking about.

If you look at the title, we can see that the title bar there where the URL goes, basically what you're going to see is a basic for refresh.

So see how it says data text?

That's actually downloaded, and then it's basically foreign coded.

And then it's AES encrypted after that.

What they're doing there is basically obfuscating the template so that the things that look for template are the two AI based upon how does it visually look.

You can't see that kind of stuff.

And it's something that if you look for that kind of obfuscation, this is where our what we call TAP or the Targeted Attack Protection sandbox would stop.

It knows we're using a known phishing obfuscation.

I don't need to see any more of this.

I don't need to send this email.

If someone's clicked on this, let's tell them it's bad.

We don't need to go any further.

This is where the credential phish sandbox picks up because it knows there's a lot of really cool artifacts that are to follow.

The first one is when you punch in your username, your password-- I think there's a backup phone number and all that stuff to this one.

You get a decoy doc.

And some of you have probably already seen this.

My uncle got this.

It's pretty popular phish kit.

But that particular file is going to get VirusTotal-- completely benign.

It's been around forever.

And if your sandbox uses URLs to just look for files, it's going to think nothing wrong, nothing bad has happened here, let's move on.

And you just got phished.

So you've got 1 domain, 2 domain, 3 domain, 4 domain, but those aren't the pieces that we actually need to find.

If we look at the network trace, sometimes it's the web socket.

In this case, it's the nature to be forum post.

We see what we're trying to find.

So this is Monica gone finish.

And if we look at this, I phished myself, my email was rr@ff.com.

My password was 23241.

And that was posted to josht.pw.

And the whole point of this is, if you look at the stuff where we started, it's more dynamic.

Like you've got days, weeks, maybe more weeks, josht.pw was up and not taken down and accepting harvested credentials for the better part of four months.

And what we had some of our customers do was, hey, look, you've got our targeted attack protection sandbox and we're going to tell you after the fact.

But if you want to prevent the whole patient zero thing, put josht.pw in some sort of reverse DNS, sync calling feature, or outright block, or at least a TAP.

Because if you detect josht.pw, it's not like you're going to block your online learning.

It's typically some DPS placed somewhere that they're using the email service just to email the credentials or they're looking at a screening like that one that had MFA was using or they're just looking at, oh, username and password have just showed up, let me go try that.

Put in some forwarding rules to O365 and things like that so that I can man in the middle some sort of transaction.

But the whole idea was, if you see that resolved-- someone got a phishing email, they opened it.

They clicked.

They fell for the lure, submitted username and password, and now we have an incident.

It's not a false positive.

A whole set of chain of events has just gone and forth.

And this is what we want to block.

But just from a detection perspective, it can tell you that a lot of stuff has happened and it's going to be a very low false positive kind of thing.

Now I came from ET, Emerging Threats.

And what I wanted to at least tell you today is that the rules that come out of that anti-phishing, credential phishing sandbox, are in ETOpen.

And this is free.

So these are Snort, Suricata, Suricata-based rules.

It's pretty easy to run Snort.

A lot of things will import a Snort syntax rule.

But if you look at the subject, the message text of a lot of these rules, you can see this is based upon a phishing template that we pulled out of TAP.

So we've got probably the best email security data around.

There's a lot of people that get more volume.

But like think of Microsoft and Office 365, if we're filtering well, and I think we are, it goes attacker, Proofpoint, O365.

We're robbing the Microsoft Threat team of like some really juicy, good attack data.

But it's showing up here, and you can use it for free.

So what you would do is put this in your IDS and say, OK, I am going to look at outbound internet traffic.

And if I ever see a forum post that matches these conditions, there's a pretty good chance I've got an incident that I need to work.

I need to talk to that user and see if they use that password any other place.

After we change the password for their corporate credentials and things, then of course, we want to move to things like MFA.

But the whole point is, if you go to rules.emergingthreats.net, you can get ETOpen and you can get a lot of really cool threat intel data that is from a pay-for-threat intel provider.

But this part of it is free.

So use this.

Understand what we did on the sandbox, and understand what these-- basically do a download of ETOpen.

And typically, what you want to search for is successful.

That'll take you to the anti-phishing signature set.

And so we've come sort of full evolution on the ET side from understanding the complex chain of events and exploit kits to using that same research team to understanding the complex chain of events in phishing.

That if you do use Suricata or Snort, which would be a good thing to do on some level, you can use it to either feed a list of domains yourself that you can use to track multiple campaigns and actors internally or at least maybe even set the stop up to block just to say, look, you can phish me all day long, but you're never going to see credentials leave the enterprise.

So it's something to look into.

And again, as I mentioned, it's free.

Now what isn't free is the data that we actually send in.

If you go to the app store, I'm going to show you this app in a minute, what it looks like.

But this is basically what we call Emerging Threats Intelligence, and this is the output of-- one of the outputs is the credential phish sandbox.

This will actually go into the threat stream UI and you can search this data.

I'll show you how it looks here in a minute.

But essentially this is our ET Intel portal where we actually give you an indexed Moloch-like PCAP of the actual credential phish sandbox run.

So it's four tabs.

You've got the alerts, the connections that were made, the DNS transactions, the HTTP transactions.

And what you basically see is, if you do a PCAP run of what the automated user is clicking through and watch it with network RDS and the signature set, you see the same kind of chain of events that you would have seen in the exploit kit world.

Where we start down here and we see phishing landing.

Then we see DNS look up and we get phished.

We fall for the lure, and then we see successful generic phish based upon some template that we've pulled out of our email environment.

And of course, we've got a policy saying, which everybody turns off, where we see HTTP client body contains password equal and clear text.

So we've got this whole chain of events, set and rules, and we'll put these IPs right here into the Anomali ThreatStream platform based upon the ET Intel feed.

Now I think this IP is much more useful than the one down here because that's probably going to get found out, get into safe browse, and be gone in a couple of days.

Whereas you'll see an example from one of these, you're talking months.

Because nobody's looking here.

Because it's all about the landing page, where is the actual login, I'm using machine learning.

And they ought to say that that looks like DHL, that looks like Office 365, but the domain is different and they stop there.

If you just follow it all the way through to where the chain of events ends, where it's the most dangerous, that is the most efficacy, the most helpful, the one that you should put on the kind of list when you're trying to decide, hey, look I can't put a gazillion IPs or a gazillion domains, why not just focus on domains.

I like domains these days better than IPs.

Why don't we focus there?

And we've got a shorter list.

But if one of those fires, we take more action.

So this is the HTTP Transactions tab of that same domain chain of events.

You can see we started with Bitly.

We moved to the webhostapp.com whatever domain.

And you see a file structure that is just-- it's a mess.

Like it's a bunch of stuff.

Essentially if you were to browse to everything except this last loginmicrosofton line.com1index.php, everything but that, it would look like this.

Hey, you've got-- this is basically what all the web crawlers are going to see-- is you've got this free web hosting site that leads you to this directory structure.

And when you click on that directory structure, we start doing this.

You get further and further and further and further and further and further down.

And then, at some point, it just starts recycling recursively going back.

You never get to that unless you know exactly where it is.

And browse to it based upon the link that was there.

It completely defeats the web crawler security-based method, and it's the thing that we'll keep it on safe browse for a number of months.

So if you do go here, what you get next, you go to the exact-- you get a nice little O365 login page.

And that's one way these guys hide from and why putting the landing page URL into your feeds is such a whack-a-mole game.

Now HTTP Transactions tab, this was the actual forum post where we now go to the finish and we get the forum post.

So the method is going to be post.

And in this case, you've got a dotted quad which should give you some sort of signature, but that doesn't typically happen in an enterprise.

But the whole idea would be either the dotted quad, the IP address, or the domain where that actual post is.

That's what we want to put in our anti-phishing set of domains that we get from Proofpoint or wherever else.

Because if we can put that into the outbound internet access firewall, we know we can block that because it's typically something that isn't going to be shared infrastructure or Twitter bot kind of thing.

You can block that with a little bit of confidence knowing that it's somewhere between static piece of infrastructure that's been sitting around for months.

They can phish you all day long, but credentials will never leave the enterprise on multiple campaigns based upon that block.

And what I've seen is people that have done that or put that into reverse DNS sinkhole in features is they'll keep sending in phishing emails, they'll keep going, and what they'll realize is whatever it is, I'm not-- it's not happening.

I can see people going to the landing page and what they'll do is they'll do research and they'll find out their personal email and send them the same email, their personal email.

If they're even more aggressive, what they'll do is they'll actually call the individuals and say, I'm trying to send you an email.

What's a better email address for you?

And they've actually done that when they haven't been successful.

Well, block here.

They're probably not going to realize that their infrastructure is the problem and that the last chain of the event, that is their whole intent.

And if you block that, it doesn't matter what they do.

On the dynamic side up front, you're going to block them.

An example, that domain, probably shared infrastructure in Australia, points back to the IP address.

It's just a domain that comes with whoever uses the service.

So this is, again, the ET Intel portal.

And my point here is that we found out-- we first saw this in December of 2018.

And our reputation system, based upon drop, is it's got to have activity.

We've got to be able to see it.

And if you don't have activity, you probably age out in about Well, this thing came on the scene early 2019 and stuck around.

And I pulled the data a couple of days ago, like 11 days ago.

And like I said, that's a pretty good run, and it shows you that not a lot of people are looking for the drop component of that infrastructure.

And the attackers know this.

They're not going to change up that stuff.

They're going to use the Bitly or the Ow.ly links.

So if you can find that kind of thing and those signatures-- the signatures that I showed you, we'll find that type of thing.

That's the thing that actually one of those rules puts that domain in the drop category.

And this particular actor was using this for the better part of half a year.

And if we look at what that same domain does in the ThreatStream UI, Google safe browse not listed, not listed, nothing.

Our system is seen to be on that list, to get in here, and be active in the Emerging Threats piece.

It's got to be something that we've seen in the credit phish sandbox in probably the last five days.

So it's just another example of where these guys want to hide, this is the place to do it.

But if you can actually look for that piece of the static infrastructure and use it or create a group of these you put on the outbound firewall, it can be useful and it can be useful for some amount of time.

It's not a whack-a-mole game where I put that Ow.ly link in that particular group and it was useful for five minutes.

This can last for months.

Now another thing that they're doing is just more obfuscation.

We see that with that signature set.

And in this case, if you look at some of the SIGs, it's just like what we did for the exploit kits.

You see a bunch of JavaScript that escapes ETInfo.

Most people turn that off, but your IDS rule is set.

If you run these signatures, ETInfo, it's free.

ETPro is not going to be free, but there's enough of the anti-phishing stuff in ETInfo that you can probably get a lot of perspective into a threat vector that you didn't consider your IDS, your Snort, your Suricata to be useful in, and it's very effective.

So this is something that I hope you can use the app in the App Store.

Because all of that data that we have in ET Intel, there's multiple categories.

The other problem with it is that when I'm trying to work with the ThreatStream folks or the Anomali folks on this, but everything that comes from Proofpoint Emerging Threats Intelligence shows up as a malware domain.

And I'm trying to get them to understand that, look, we do more than the malware.

This is phishing.

This has nothing to do with malware.

This is credential phishing.

And so if we could actually call that out, you could create groups and maybe say, hey, look, this is a mission specific set of data.

It's all based upon what Proofpoint does really well, which is phishing data.

And if I could get that group of domains and maybe put that into the DNS sinkhole, that I believe is next hours talk.

If I could do that, man, that would be a really effective way to actually use domains.

I'd say use IPs, but anybody that does this IPs-- an IP as a host or a domain as an actor.

So I like the domains much better.

But understand that that app, that is what we've been showing you in the PCAP run and the portal.

So you get it in ThreatStream if you want the portal.

If you've got the app, you get the portal essentially from Proofpoint and you can look at that kind of stuff.

But it's different from Emerging Threats apps that are, yes, it's part of the ETOpen project, but this is not our data.

So ETOpen, CNT server and compromise, that's all shadow server abuse.ch, DShield, things like that we do it as part of the Open Project.

But people will call up and say, hey, my IP address got on with some Emerging Threats list and how do I take it off.

And I say, I have no idea.

You've got to go call Shadowserver or someone else.

We aggregate for ETOpen as part of our service to the community, but that's not our data.

That is a result of our analysis systems that is looking at probably the number one threat factor in the world and is really good at determining what is a phish in a most efficient manner possible, which still includes delivering it to sandbox and in quick time.

And in some cases, we'll preemptively sandbox stuff.

But like I said, it's a complex chain of events that is reflecting attacker-innovation that has ended up in the cloud as opposed to the endpoint, which is really the point of a lot of vendor marketing these days.

So takeaways here.

Social engineering is what dominates the threat landscape and that's most of the time manifested in some sort of phishing.

Why go through the entire DMC if you could just ask somebody for their credentials and get data-- get access to the data that you're actually trying to get to.

It's a lot easier.

It's a lot more efficient, that's why phishing is so popular.

And I don't want to fool you.

There's still a lot of complexity to the attackers.

They're still using code.

It's just up in the cloud.

It's not on the endpoint.

And they understand where all of our defenses and our spend is.

They've moved it outside of the perimeter up in the cloud.

This is a great way to look at the most static piece of the attacker infrastructure that has moved into the cloud and get better detection and feed efficacy from what your pulling in your TIP platform.

If you take a feed in and it's mission specific and it's completely focused, you're going to get better efficacy.

Stick to the domains.

And when they fire, it's not just going to be noise.

It's going to be, hey, look, we've got an incident because if I saw that resolved, would've left the enterprise.

Thank you very much.

Appreciate it.