D (3:22)

Yeah, it's going to develop the attack path pretty much. So kind of without it. That's all right. So about us, obviously, we're both here red teamers at Black Hills. I was involved with the OWASP Orlando team with Bo doing Tradecraft Security Weekly, and then obviously the Coinsec podcast. So Attack Surface Recon. Bo, this is you?

C (3:44)

Yes, yes, this is me. So like I mentioned, this is. This is. We're going to scratch the surface of the external network at this point. So when we look at targeting, targeting an organization, our first step is first off, what are we going to actually look at attacking? Right? So we got to build a solid target list. We have to really understand what technologies is your organization using. How many hosts do you have? Can we discover things that you might not even really realize is still there? Like things like legacy items? But in reality, there's. There's three main things that I personally try to look for upfront. I want to know, how are your employees remotely accessing your network? How are they accessing email? Because pretty much every workforce on the planet has to have a way of communicating. And then if I can gain an insight into what security products you're using externally, that just adds so much more that I can. I can use to exploit on or when. Whenever I'm going to try to build payloads, I can use that information to craft stuff around Those specific products, like if I see that maybe one of your security engineers is on LinkedIn and he starts talking about I'm an expert with Bluecoat web proxies and expert Symantec AV deployer or something like that. That stuff helps me as an attacker understand what you guys are using. I've actually seen a number of companies lately that actually post up what products they use. They'll be proud of the fact that they're using things like Carbon black or they're proud of the fact they're using more advanced softwares in terms of protecting their networks. All that information is really, really important to us as an attacker. The first thing that we look for this is the baby steps we want to look at understanding what domains you have, what top level domains and what sub domains can we figure out. A lot of this can be done through basic stuff like just Google Dorking basically going to Google, going to Bing, going to the Chinese search engine Baidu and doing things like site domain name and trying to discover what domains you have out there. Throughout this entire presentation, each of the slides has the associated recon ng modules attached at the bottom as well. So that if you want to go run this, we do this all the time in recon ng because the modules are built to basically do all this enumeration already for us and it just makes it a lot easier. So the modules are out there. So the modules for this particular slide are the Bing Domain API which actually utilizes an API key that you can get from Bing to perform web searches as well. So NetBlocks Hurricane Electric is a company that has a great netblock discovery site. So bgp.he.net, you can go there and you can search for ASNs. MX Toolbox is a site that I use all the time whenever I'm looking up a netblock associated to a specific IP address. So if I go and I want like let's say that I look up your domain and I understand that this IP address is associated with your domain. I can take that IP address, go to MX Toolbox, you and then that will hopefully be able to translate it to your associated netblock and give me the rest of your infrastructure. One thing to kind of note here that we run up against a lot is when organizations are using like third party hosting, like so they're using things like, you know, Rackspace or using like some sort of hosting service where they're, they're buying IP space that isn't necessarily associated with them specifically from that sometimes that can be a little Bit harder to kind of attribute to an organization, but we can kind of go through the process of enumerating domains and still kind of tie up IP addresses that way. Then the other thing to note here is that each, each region has its own Internet search registry list as well. So in terms of subdomain discovery, there's like hundreds of tools out there, I think, that do subdomain discovery. It seems like there's one that comes out each week. I mean there's, there's such a, like a plethora of subdomain discovery tools and they range from, from performing different types of lookups to, to brute forcing just domains across the Internet to looking at certs, to all kinds of stuff. But some of the main ones we use are Shodan and Census. So Shodan is a site that they scan the Internet all the time and provide a search engine of sorts for ports that are open for sites. Census does similar thing. DNS Dumpster is a great site for looking up domains. Hacker Target and threatcrowd both, again, great sites that we utilize all the time. And a lot of these are fairly similar sites, but we get back different information from them. So they're, they're doing slightly different stuff, which is, which is interesting. I like to have a kind of a. Go ahead, John.

B (7:52)

So Jeff had a question. He said if a company owns multiple brands, multiple domains, where would you be able to find all the domains or many of the domains associated with the organization?

C (8:01)

So yeah, so we'll get into looking for multiple top level domains in a second. So I think that's what he meant there. Right? Multiple top level domains. Right, yeah. So when it comes to the top level domains, this specific part of it I'm looking at just enumerating subdomains for like one specific tld. Right. And then in a second after, I think it's actually the next slide after this, we're going to talk about trying to look up multiple top level domains. But one thing I do need to note here is that subdomain brute forcing is very important too. So like, you know, we might not be able to get all this, all the subdomains just from these sites. So let's go ahead and just brute force them ourselves. So there's, there's a number of lists out there that you can use to just perform DNS lookups for various subdomains for a specific top level domain and you can learn more about the subdomains through that. Yeah, so yeah, so additional TLD and subdomain discovery. So one of the main Ways that we find additional top level domains is through certificates and that's basically through certificate transparency. So Cert SH is one of the sites that provides a service where you can basically search for a specific domain, find SSL certs attached to that domain, and then a lot of times within those SSL certs, if they have used them for multiple top level domains, you can see that within the search themselves. So there's been a number of tests we've been on where we will pull a single search for a website and it contains other top level domains in that same cert, if that makes sense.

D (9:21)

They're basically taking the certificates and then parsing them and then databasing them in a postgres database. When we were using Cert Sh recently, I stumbled across a forum post where the developers behind it, now they've open sourced all of the tools that they use as well, but they actually made public read access to their PostgreSQL database. So you could just go in there and query it directly. So it's really nice. Yeah.

C (9:46)

And then so once we get those new TLDs, rinse and repeat. Right. Like go back through the entire process again, start looking for more subdomains, looking at the netblock spaces, and just try to gain as large of a host list as we can.

D (9:57)

Yeah, because once you get these domains, you'll start seeing on Cert SH that they may have registered another top level domain and sharing certificates with ones that you already know about. So referencing it when he's saying rinse and repeat and go back through the net blocks is because you kind of want to try to make sure that you can parallel both domains to the same netblocks. That way you could identify whether or not it's at least within scope of your infrastructure.

C (10:22)

All right, so the next thing is looking at cloud services, right? So we've looked at the attck infrastructure that a company's hosting themselves. What other cloud services are they using? Are they using things like O365, SharePoint, Skype? For business, these are very big targets that we look for on every single assessment, because which I'll talk more about later, is that we're looking for portals that have active directory connectivity for the most part, because if we can attack that, we can perform password attacks against your users. One of the ways that we can find out if you're using O365 is just go to outlook.office365.com and try authenticating with testourdomainame.com and if you use O365, it will simply redirect to your own portal. That's just the way O365 is set up. SharePoint. Similarly, you can check for company name.sharepoint.com and a lot of times you'll find that they utilize SharePoint based off just the subdomain there. Skype for business. So link Discover similar to AutoDiscover and the way that OWA works. So linkdiscover.domain.com will point you at the link or Skype for business servers that a company utilizes. Again, all of these are Microsoft services and we heavily target these because they have active directory connectivity.

B (11:30)

So a couple of questions. First one was how does cert Sh. Collect certs?

D (11:34)

Yes, using the certificate transparency projects that are out there. So like Google for instance makes all of them that get registered available. So if you, if you did, if you looked up like a certificate transparency, you'll see a lot of different projects that monitor it. There's been some where they monitor S3 buckets for any. They monitor the certificate transparency project for S3 buckets to try to discover misconfigured ones on the fly. There's a lot of really cool projects that leverage certificate transparency.

B (12:04)

So, and then another question. Whenever we're seeing a lot of organizations moving to things like Office 365 and Google Business, a lot of organizations speak of like zero trust models where there's no trust internally. Everything goes to the end, goes to the endpoints in the cloud. Do you think that that zero trust model is more or less secure? People are moving everything into the cloud getting rid of Active Directory. Is that a more or less secure approach to an overall architecture, especially for new organizations?

C (12:32)

So you know, I, we, we've done assessments against both, right? We've done, you know, hundreds of assessments against both types of infrastructures, some that utilize ad, which I would say is the majority of companies that we, that we attack and a number of them that don't just don't have Active Directory. They're very different obviously. But I would lean more on the side of if you don't have Active Directory, it's harder to manage from an administrative standpoint, which can potentially make your endpoints less secure. But at the same time, without the Active Directory infrastructure in place, you have users who are now basically creating their own security policies of sorts of on their own endpoints. Like they're, they're basically following their own set of restrictions which can be just honestly based off of obscurity alone. That can make it tougher to target. So I think there's definitely benefits to both.

D (13:27)

I was gonna say having a hybrid like the using ADFS for Azure and then ad for on prem and then synchronization. We've seen a lot recently too uptick of kind of compromising the system based on the configuration. So whether it's like using the ADFS syncing connector or just the misconfigurations of how they have it, just because it's a hybrid model, I think it makes it a little bit more difficult to manage.

C (13:55)

All right, so then other cloud services that we see a lot at Google. So honestly like back to your question about non ad infrastructure companies. We go up against Google infrastructures a lot where companies are utilizing Google for the main stuff, right. Like for document syncing, for to email and they, they don't really have like an infrastructure in terms of their endpoints. And a lot of times with those companies we're looking at targeting their Google infrastructure like that is the target. And to find out if a company's using Google, it's similar process to the way we attack with365. We can basically just put in a valid company email and if it's a valid email it will redirect to the authentication portion of that account. So like it'll ask them for a password.

B (14:34)

Martin just asked a question. How would this work on whitelisting of the ADFs since we whitelist on ours meaning not everyone can connect to it? I don't know. I will say whitelisting on hours usually doesn't work that well. I know that some organizations try to establish that that accounts can only be accessed from nine to five and oh, hours.

C (14:52)

Hours like as in time.

D (14:54)

Oh, I think like hours.

C (14:56)

Okay, yeah.

D (14:57)

So like using conditional access rules I'm guessing.

B (14:59)

Yeah, yeah. Time based on that. I just, you know, I remember years ago they used to tell everybody to shut off your computer at night, stop hackers. And that was back in 2000. I kind of see that as the same approach and I don't think it's.

C (15:11)

Only hack at night. Right?

D (15:13)

Yeah.

B (15:13)

Right. Well, seriously, I used to have managers that would say things like that. So I think that those types of whitelists are not nearly as effective as some people would think they would be.

C (15:23)

I agree with that. So go ahead, Mike.

D (15:26)

I was just going to say I've ran up against conditional access rules where we were able to compromise credentials from a target employee at an organization using phishing like Cred Sniper and went to login to authenticate and it turns out that the conditional access rules restricted them from logging in based on location.

B (15:48)

Yeah, Martin just asked that as a follow up location or IP address. I think that that may have a little bit more, that might make a lot more sense. Like if your business only works and runs in Kansas or everybody's in the United States, you might want to restrict access outside of that.

D (16:02)

Yeah, definitely. Some companies that two factor authentication too for when employees are outside of the quote unquote office space.

B (16:11)

Oh wow. We just had new employee Bill come in with an answer too by the way. Everybody say hi to Bill. He's helping us out on the active countermeasure side as Mike and Beau are like, who is? That's Bill. Nice.

C (16:28)

Hi Bill.

B (16:29)

Great job. Fng.

C (16:36)

Awesome. All right, so back to cloud services. All right, so box.com, this one is actually I feel has become more and more interesting, especially over the last couple weeks because there was a report done where they were able to find that Google was actually caching a lot of these publicly available files that companies were hosting on box.com yeah, so box.com has a similar problem, right? Like the subdomain company name.account.box.com to locate the company you want to attack, you can search for that on Google site with that URL. And so that's one problem, right? Like the Google caching part of this problem. But Google has to be able to find those to do that. The second problem is that with Box.com, you can create your own customized names for files that would be just be tagged onto the end of that.

C (17:24)

Creates a brute forcing problem.

C (17:27)

What was released not, I mean I guess a week or two ago now was a tool to basically brute forces file names on the end of the URL there. So now you can basically just brute force potential files like somebody called a file like secret documents or tax files or something. You can brute force all that now, which is kind of interesting. Amazon AWS looking to see if people are using S3 buckets. Basically just look to see if web resources when you load a web page are pointing at that stuff. Anything to add there, Mike?

D (17:56)

Yeah, there's just. So whenever you're, I guess if you're using AWS for S3 as a CDN, right. So the images, the JavaScript, the CSS files, sometimes they load directly from a CDN when they're in use. And so when you kind of are viewing the page you can kind of get an idea. I think there's some plugins too for burp if, if you're browsing like pages and you see some stuff, you could kind of identify where those, those S3 buckets may be. And then I mean there's also, there's projects out there where they brute force. I'm using like domain name or subdomain names. And then you can kind of just enumerate looking for misconfigured buckets. Amazon has made a pretty big push on streamlining configurations for S3 buckets now. So the policies aren't as lax as they used to be. So you have to kind of go to like these other alternative AWS services in order to find misconfigurations nowadays. But S3 buckets are still a huge, huge deal.

C (18:49)

All right, next slide. Okay, so after we've kind of collected all of that information, right, about the external attack structure, right. So we're looking at like all the hosts at that point now let's, let's figure out where can we log in. So let's look for interesting files and let's look for login portals. Now that we've kind of done this passive discovery of where the portals are, we can go into more of an active mode which all of you are familiar with. Port scanning, I would assume basically your basic NMAP scan for just web services is typically what I run right up front. Something like 80443. I threw 2381 in there because that's HTTP System Management homepage, which has historically a number of vulnerabilities. 888443. Just typical web portals. And then we could go and manually navigate each of these results with a browser. Or let's go to the next slide. We can use an amazing tool from Chris Truncer called Eyewitness which does screenshotting of. Of these portals. Hey, there's a poll.

C (19:52)

Hey everyone. Sorry to interrupt your. Your presentation.

C (20:00)

I suppose you should answer a question at this point.

B (20:06)

A lot closer than I thought it was going to be. This is the way they say that this is the way to increase engagement with your, with your audience. So there we go. I wasn't expecting it to completely hijack the entire webcast, but I think we have enough votes to say definitively that Bo should not shave. So I'm going to close this poll now and give you back access to the screen. That didn't go well at all. So his legs are fine. No need to shave his face or something else.

C (20:41)

Nice. Oh my gosh.

D (20:44)

Okay.

B (20:45)

Should he shave himself or Mike.

C (20:47)

Whoa.

D (20:48)

Whoa.

C (20:50)

That's weird.

C (20:52)

There's a lot of times we come up against companies that have thousands of web portals. We could literally open up a web browser and go to each one and navigate them, or we can just screenshot them, have it put in a nice HTML format where we can just scroll through and look at pictures essentially of each portal. What I typically do is I create a secondary list of interesting web servers from that list. That way I can use it for this next portion which I'm about to talk about. Because when you're looking through these results, a lot of times you're going to get a ton of iis, just your standard pages. You're going to get a ton of just blanket Apache pages. There's a ton of things that just are the same across organizations, if that makes sense.

C (21:33)

Should I create a list of interesting stuff? And then we go into this process of looking at brute forcing files. All right, so this is, this is something that was actually written by Steve Borish for internal pen tests. This is a script that he wrote called Find Fruit that essentially you pass it in netblock list and on an internal network it will go and just look for a specific set of like certain interesting files. So things like your typical Tomcats, your Cold Fusions, that kind of stuff on an internal network. I took that and I modified it. Because what I wanted is I wanted a script similar to that that I could pass a URL list and a file list. That way I can now brute force these directories and files at scale across thousands of web servers. We have a short demo for this one. Let's play this. Basically, it's PowerShell script. You feed it a list of URLs. We've got this list that we've gathered. This would be the interesting list that I gathered from eyewitnesses.

B (22:32)

This.

C (22:32)

And you can feed it a ton of these. This is basically the list of files that I want to brute force. This particular list has 6,000 files on it. We're going to give it a timeout of about 3000 milliseconds, a number of 10 threads. So it's going to spin up 10 different sessions essentially to brute force these files. And we're only going to print out anything that was found.

B (22:58)

And people are asking already, where can they get this tool?

C (23:02)

It's on GitHub. Hold on.

B (23:04)

It's on GitHub. Right.

B (23:08)

Questions are coming so fast, I can't keep up with it. Go ahead.

C (23:14)

It's actually part of Steve Borish's Find Fruit module. It's actually in his repo, which I can copy the link to that in A second and I'll paste it in. But essentially what you just saw there was a very quick version of the way this would work. Right. So it had a total of 30,000 requests that were sent. I sped this video for the sake of not waiting for seven minutes, but that only took seven minutes to do that. So essentially I fed it a list of targets, fed it a list of URLs. IT brute forced 30,000 files across them in seven minutes. And you can kind of see, you can play it now. We got some results back. So like that's some typical cold fusion stuff. You know, there's an EWS out there. What's that?

B (23:54)

Secret?

C (23:56)

Yep, yep, secret. OA, some WebDAV stuff, WordPress. But essentially, like, you get the idea, right? Like this is, this is something like instead of just taking each specific URL and running something like Derby or Dirbuster against those specific URLs, we're not doing this threaded across multiple sites.

B (24:13)

So it's faster, multi threaded. You can hit it across multiple systems. That's kind of the advantage over like Durbuster.

C (24:20)

Exactly, exactly.

B (24:20)

Yep.

C (24:21)

Yeah, because I didn't want to just say, okay, run dirbuster. Next server, run Durbuster. Next server, run durbuster.

B (24:29)

Have you used something called amass? I haven't heard of this, but James was asking.

B (24:35)

I haven't heard of that.

C (24:36)

Yeah, I'll check that one out.

C (24:40)

Now that we've learned what portals we want to attack, the next part of this entire attack process is figuring out what information can we now utilize from the internal network. Can we. Can we actually remotely gather internal domain information remotely? Next slide. Okay, so on pretty much any vulnerability scan you ever run, it will tell you that information disclosures are either low or informational, which I totally disagree with. I think that information disclosures can be critical, especially to an attacker. So think about this. If I'm an attacker, if I don't know what your internal domain name is, and if I don't know what your username schema is, how am I supposed to perform password attacks externally?

C (25:24)

Potentially, if there's an email portal, sure, I could use an email address for that. But in a lot of cases what we're looking for are active directory login portals, things that are accepting NTLM based authentication that utilizes domain username. I think that the process of just identifying those names alone is critical information to an attacker. It might not be a critical in terms of a vulnerability because nobody's going to exploit that. Right. To you as an organization. But to Me, as an attacker, I have to have that information. If I don't have it, how am I going to attack?

D (25:58)

I think a lot of times, real quick, is the reason why we see it's low too, is because it's a vulnerability scan that finds some sort of information disclosure, and it within itself tends to be a low finding because it's not exploitable. But when you are an attacker, those definitely are elevated.

C (26:14)

Yeah. So in order to perform a successful password attack, we need the valid username format, Right. And then we need a portal that has a high probability that the users can authenticate to. Because a lot of times externally we're attacking very large organizations that have multiple different types of email portals and VPN portals. I've seen Companies that have 50 different VPN portals and it's hard to really understand which one of those is the one that every employee can actually authenticate to.

C (26:44)

Which one's the good one, which one's the one that has the high probability. Those are two very important things we need to look at. This is a vulnerability that we disclosed to Microsoft two years ago now, and it's something that they don't want to fix. It's a problem in the way that they handle authentication attempts and it allows for username enumeration. This is part of the process for us identifying what your username schema is with OWA Outlook Web Access. When I perform an authentication attempt to that portal, if I utilize a username that is wrong, it will take a significant amount of time differently than a username that is right. It might take 600 milliseconds more for the application to respond to me. If a username is correct, I can identify which ones are incorrect and which ones are correct. I can go through the process of single initial, last name, last name, dot, first name, all these different types of formats and try to identify which one is the correct one purely based off of response time from the application. You can use Mail Sniper to perform that attack. It has a module for it. The other thing we look at a lot is metadata. Jason will like this one because I gave marketers some crap in the last time we talked about this, but basically the idea here is that publicly available files that are hosted and things that are hosted on your web application, if I can pull those down and I can extract metadata from them, I can a lot of times gain information in terms of what your usernames are and the applications that they're utilizing. So to give you an example, a lot of times marketers, Jason, I don't know if he's still on. I hope he is. A lot of times marketers will create documentation like the shiny new PDF that details all the cool services that your company does. And they'll just post it on the website. And then that way people come by and they say, oh, look at all these sweet services this company does. But a lot of times, if that person that created that PDF did not go and actually extract metadata out of them, their username is attached to that metadata externally. Me as an attacker, if I can just go find those files, pull them down, pull the metadata out, I now have your username and I can use that to basically build a list off of.

B (28:48)

Martin just asked a question. He said, what would happen if we just use a sequence of letters and numbers? How would this work then? And I think honestly it would depend on the length of the numbers and letters. I mean, whenever you're creating user IDs, I can remember at Northrop we would have a number, it would be like E and then a series of numbers. And that would be my logon, Right. That would be my account. But it wasn't long enough that it wasn't brute forceable. I think that the length matters quite a bit because we can actually still brute force it. Correct?

C (29:16)

Yeah. So I actually had a company similar to that and they had. It was three letters, three numbers. That's a very short list of brute forceable possibilities. Right. What I did is I actually was able to figure that out through this exact attack right here. I used Power Meta, which is a PowerShell tool that I wrote, which is basically. It's a very similar set of tools to Foca or if you've heard of goka, which is a newer version that's written in Go, it basically does Google Searches, does Bing Searches, finds these files that are cached on those sites, goes and downloads them, pulls the metadata from them. I did this for an organization. I figured out the username schema was three characters, three numbers, and then I just did exactly what John said, brute force the entire space just to figure out what that list is and then use that username enumeration vulnerability on OWA to figure out which ones of those are correct.

D (30:07)

Bo, how much does a company's policy to lock out accounts with bad password attempts impede your progress?

C (30:17)

So when we do password attacks these days, we're doing password spraying, for the most part, we're not doing brute forcing. Right. So if we're not doing brute forcing attacks, then the password policies don't matter. Right. I mean, because we're trying, like one or two attempts in the span of a day. We. I mean, there's a lot of organizations that, like, actually, I think the largest policy I've ever seen is a day, a window of an observation window where, like, they'll lock. They'll. They'll. They'll create a threshold of lockout attempts you can perform in a given amount of time. I think the largest I've seen is a day. So, you know, as long as we're doing like one or two attempts a day, there's not a whole lot of risk there. All of these attacks.

B (30:56)

Right.

C (30:56)

The one problem we have is IP address for the most part.

D (31:00)

Right.

C (31:00)

Like, as attackers, that's the one thing that you, as the blue team are going to typically alert on is, all right, so this guy is scanning my site. You know, he's doing password spraying from this ip. Let's just block that ip. Well, there's been a few different types of tools out there that can help with pivoting your IP space, but some of them don't really work that great. They do Maybe up to 12 IPs at a time. We had Proxy Cannon, which was cool at the time, but you can only spin up a few at a time. That still doesn't give you real evasion, if that makes sense. So, Mike, what's the fix for this?

D (31:39)

Spin up a bunch of Russian VPS servers and chain them all together and. Kidding.

B (31:45)

Kidding.

D (31:46)

He's kidding, everyone.

D (31:50)

No. So it used to be back in the day, if you're from any time before SOX was a really big thing, they used to have these things called Wingates, Wingate proxies, where you could scan the Internet for Wingate proxies, and then you'd have a million of them, and you could just use those, which were basically SOC proxies anyway, I think. But before socks got really big, and I liked Proxycan, and Proxycan is actually a really good tool. It spins up EC2 instances and then routes all the traffic through it. And then Cred King, what you were saying was the 12 IP limits. That's because Cred King is built using the AWS Lambda, which is really cool. And what it does serverless compute, but you're still limited. And so what we did was we came up with this tool called FireProps. We released it a couple weeks ago now Bsides Orlando. Then the idea behind fireprox was I was informed from Ralph May, a friend of ours, that if you used AWS API Gateway, that it would actually rotate the IP with every request. After some dialogue after the tool came out, I learned that this actually was old. In 2016, some people came out with a tool and released it at Black Hat Arsenal as a portion of their tool set. It just didn't get any headlines. But it's a really fascinating technique. So it's using the AWS API gateway and what you're doing is you're basically setting up an HTTP pass through proxy.

D (33:19)

If you're familiar with the HTTP protocol, the GETs, and you have posts and you have heads and you have options and all these different methods, this does basically any of them. You can set up any to any. What you do is you spin up this API gateway proxy, you point it at a URL destination. It just doesn't have to have the full URI. It could just be www.companydomain.com, the entire URI on the end of that. So all the file names or the directories, all the post parameters, all the headers, they get sent directly to that destination. When it makes the web request, it's actually using another IP address with every request. Let's say that you sent 1,000 different web requests. It's going to rotate them. Now, depending on the region, there is a finite number of IP addresses somewhere. But if you use us east1 or us east2, I rarely run into a duplicate. And if I do, it's like minutes or hours later. And it just so happened to be like coincidental. But it's really cool technique. And so Fireprox basically spins up a URL.

D (34:31)

And it provides you with the proxy URL for the API gateway. And then you could scrape, or you could do password sprays, or you could crawl and use some of those tools. The other cool thing is if they're using captchas or wafs or any sort of detection capability on the ip, a lot of times you'll see some of these more sophisticated infrastructure where their security teams are basically looking across all of their IP space and then correlating them back to the IP request. If you make a web request and then you also try to authenticate and then you also hit some mobile app endpoint or some MDM endpoint, then they're able to say, hey, why, this is weird. This IP address is touching multiple different IP addresses. Let's just blacklist it. Or they get smarter and they say they might be using a proxy. So let's monitor for the exported foreheader. This. Originally, when we released it, we had this problem. We put out a $100 bounty for the first person that could find the bypass for it. Fred Reamer actually came out with it within a couple hours. What he did was he overwrote the X forwarded 4 in the API gateway. You could basically spoof the x forwarded 4 by passing in your own custom x my x forwarded 4 header and it would automatically reroute it. It was super fascinating. So with that, I have a little demo here.

B (35:49)

You're already just in case. Okay, we do not need the poll, by the way. By the way, I like the fact that you're using Phish. That's awesome.

D (35:56)

Yes. Fish is amazing. In the top screen, I have FHIR products. In the bottom screen, I spun up a web server. It's basically just a custom domain. It's BHIS webcast, Ezra Report.com or something. What we're going to do here before we start it, because it goes quick, I'm going to launch a custom web server written in Python on the bottom screen. All it's going to be doing is listening for web requests. It's going to be printing the request as it comes in and I also print the exported 4 below it. So you can see get an idea for it. Then in the top screen, Firefox is going to run and we're going to walk through a few of the different techniques that Firefox does on creating new ones, deleting them and listing them out. And so I'm launching Python hacks py. I'll show you a copy of what that code really is. It's super lightweight, but basically all it really does is it spins up a listener on it binds to 0.0.0.0, which is on the external interface on port 80. And then it makes the web request, it prints it out, and then it prints the X forwarded forward is basically all it does. And then Fireprops, we run FHIR PY and just by itself. And you'll see it can take access key, secret access key. You can use sessions. We had another pull request for profiles. So you could use AWS profiles. And then there's a number of different commands list, create, delete and update. So the first thing we're going to do is we're going to spin up a Create URL and point it at the bhis webcast.esrareport.com URL, which is the one running on the bottom. And AWS API gateway is going to give us back this long URL that has some custom.

D (37:46)

Basically a custom Amazon URL. So anytime we make a web request to that URL. It's actually going to be sent to our web server, which is on bhis web. So I have this brute PY file that I wrote really quickly that does exactly what Bo was talking about earlier. It reads in a word list and. And then it just attempts to concatenate the URL with that file and check for the results. It just loops through. You'll also notice I'm passing in the X my exported 4 and I'm spoofing localhost as who actually made the web request. So if their sim is up there running, it's going to see a bunch of 12.70.01 requests. If you look on the far left on the bottom, this is just going through and enumerating it. And the IP address is changing with every web request. And you'll see the exported port is 127001. And this could technically be anything, right? You could take. I'm going to pause this real quick. You can see on the far right the GET. It's GET 2004 GET 2001. It's enumerating all of these, looking for these files in there and it's making a unique IP address request with each one. If they're blocking on the IP address, then they're just blocking a bunch of AWS API IPs, which technically would be a lot of them. So I don't think they would. It's only making one web request, so they're probably not going to block on one. If they're blocking on exported four, which we've seen before with like fail to ban and some of these other tools that have plugins for. For blocking X44, they're going to block 127001, which is local host. Or we could have set this up for the actual web server.

C (39:11)

We could have.

D (39:12)

We could have did it for Cloudflare IP addresses. We could have made it random. So it's randomized as well. But this is just a simple little demo kind of showing how each of the IP addresses change. So I just canceled the fire approx Brew at top question.

B (39:26)

Oh wait, somebody said how much the API costs, what it costs for the API key to do this.

D (39:32)

So it's super cheap. I did some math. I think it was like 1 million requests with an average. I forget what it exactly was. I think it was like 20k payload size for 1 million requests a month. And it was like dollars. It's very cheap.

C (39:49)

Hey Mike, didn't Dakota just have like a 400 bill or something?

D (39:51)

Or something. Yeah, yeah. So Dakota rolled this into his scraper.

B (39:56)

Which means I'm going to have a 400.

D (40:01)

Dakota rolled it into his scraper and because he's a data connoisseur like me, we collect data.

B (40:07)

You guys would like wine glasses. That's fantastic. That's a vintage 2019 status.

D (40:14)

Feels bad. Not a connoisseur, but his payload sizes were massive because he was downloading these big chunks of JSON and so it spiked it up. And the other thing was he lost. He had control of it, so he just let it ride and he forgot about it and came back. I was like, oh yeah, that's a bad thing. So it's relatively cheap if you keep it down, especially for scraping or web stuff like that. So to continue the demo, I'm just going to list out the ones that are here, passing the command list and you'll see it's right there. You'll notice the H0029ILRDK. That's the API ID that Amazon has. If you want to delete it, you just pass in command, delete API ID and then pass in that and it'll delete it for you. It's weird though. They do rate limit you on how many you can delete.

B (40:59)

Not really sure why they restrict that.

D (41:02)

They restrict that, but you could spin up a bunch of them. That's pretty much the end of the demo. I'm going to go through this quickly because we're getting short for time. So far we found great hosts using both technique portals. We've identified running servers. We get some servers in site that we're going to focus on. We just need some employees and we want to change up our attacks a little bit. That's kind of the nature of what we're going to be focused on here. This next section we called social trust attacks because I haven't found anything that really talks about this stuff yet. So there's no real way to differentiate the type of attack that this would be. So what we're going to do is we're going to focus on breaching the organizations, but we're going to be focusing on personal data of the employee. Most employees are trained not to click links unless they know where they came from or if they came from the company email. But what if you received, I don't know, an email from a friend of yours or a family member? We're also going to look at a couple different, different types of, or a different type of a password attack. So if we could get the personal information of the employees, some of their Relationships and then their personal emails. I think it's going to make for a really different twist on these types of attacks. So with that, we're not doing anything new with regard to discovering employees. I mean this has been done. There's a recon ng model for it. There's been so much about scraping LinkedIn for company people, but how we use that data is interesting. And the thing I want to add here is normally we only care about the first name and last name because we're going to generate an email address for that user or a username. But this time I would suggest grabbing their city and state as well. We'll get to that in a second. But for email forwarding, I know BO has a tool, I put it here, email address mangler on GitHub. So if you're wanting to put together like first name, dot, last name combinations or if you don't know it, you can go to Hunter IO, learn the company email format. I think rocketreach Co has a good one as well. And then, and so take the usernames or the first name, last name, generate the usernames, generate the email. And now we have company email as well. So aside from all the portals, all the running services, we also have the employees email addresses. But we need more data. So what we're going to do is we're going to focus on grabbing pii for the employees we're going to look at. We want to know their personal information, we want to know their personal email addresses, we want to learn about their relationships. In order to do this, I learned about this new. It's relatively new. I guess it's been going on for a really long time, which has gotten really bad lately. The people, data brokers industry, it turns out they buy, sell, trade, they make our data for free and they aggregate it at scale like everything you could possibly imagine. That's public info, public record. They aggregate and then they make it available and they sell it and they trade it.

B (43:43)

Yeah, but it's all secure, right? It's all secure behind, you know, strong authentication, two factor long passwords. It's totally locked down, right?

D (43:52)

100%. And if you want to try it for yourself, this is just one of them. Go to truepeople search.com and search for your name or your spouse or your whatever and just look at just that kind of information. It's free, you don't have to log in or anything, you don't have to have an account or anything. But with, with people, like, with search places like true people search now we can grab the pii, the personal emails and the relationships because it's all readily available there. I'm going to leave this screen up just for a second screenshot. This, it'll be in the slide deck. You want to go to each one of these and start opting out. There's a lot more. These are just the most popular and I want to say that most of them all source from peoplefinders.com, which is the reason why I highlighted it, that one. It seems that People finders aggregate a lot of this data and they subscribe it out to these different third party services. I stumbled across on accident, but I found a really unique ID that was coming back from the web request, but it wasn't being displayed. And I noticed that that unique ID was across all these other sites. So when I cross reference the names, it was the same id. And I traced it back and I found out it was People Finders database.

D (44:57)

But there's way more data. They got people data, they got business data, census phone data, work data, marriage data, foreclosure data, evictions. They have so much of it. It's all together. We're in for a rude awakening very shortly with that information. This is where it gets fun. Password attacks. I collect data. I collect breach data. One of my biggest databases is a massive, I think it's almost three terabytes of plaintext credentials that we've sourced from every breach under the sun. Some of that could be like the collection number one through five that came out. Remember, now we have personal email addresses for corporate employees. So what we're going to do is we're going to go to our breach database, we're going to query our search database for the personal email addresses of the employees and grab their personal passwords. Because what's the chance that people reuse passwords? They do. You know, historically we would try to find corporate email addresses in the breach passwords and then hope that they use that password on their corporate account. Didn't always work. We had some luck every once in a while, but doing it from this perspective, it's using their personal email passwords, their corporate accounts, and it becomes a really bad password reuse problem. This is just a little quick tool that I wrote just to in the beginning when I was testing it, which basically I query almost 300 million people for Bob Barker and Ventura, California. I grab all of the personal email addresses that I find for that Bob Barker in Ventura, California, and then I pull all of the passwords for those personal email Addresses. And then we have a really bad day for Bob Barker.

B (46:29)

Martin just posted up. He goes, thank God for gdpr. And I'm sure that there's sarcasm in that as well.

D (46:36)

It's really great. Really. I mean, GDPR for Europe.

B (46:40)

But Joel just brought up a great point and I was thinking about this. He said the local county assessors have websites that you can hook into for free, where you can pull their GIS database and you can see where they live. And that is all public record.

D (46:53)

Yep. So imagine all that being sourced. That's what people finders is pretty much doing. It's hitting all of those.

B (46:58)

Yep.

D (46:59)

So this is just a sweet little tool. So here's our attack path. Almost real quick highlight. So we found the portals, we scraped employee names and locations. We formatted the corporate emails, we scraped the people sites to get their personal information. We got their personal passwords, we reconciled accounts, and now we're using personal passwords with their corporate emails on their portals. And that's how we basically profit. So quit reusing password. That's pretty much the nature of it. I think we all have done that. That'd be a really cool poll. How many people have reused passwords now? I know I have. And John. And we talk about this joking around. So social trust attacks, we're getting short for time. I think we could run over a little bit.

D (47:39)

So another social trust attack. What if we incorporated their personal information into a fish and we leveraged their known relationships and then tried to doppelgang as a contact? So, for instance, let's look at it from this perspective. If I was targeting Beau and I pulled all of Bo's relationships and I seen that Beau had a relationship, some sort of associate with John. And what if I pulled John's associates and I seen that Jason was an associate of John, but Jason was also an associate of Bo. And then I said, hey, Bo, can you believe. Hey, it's John. Can you believe what happened to Jason? Man, I can't believe the news is covering him. Check this link out. Boom.

C (48:25)

Done.

D (48:26)

It's coming from a non corporate domain or Lakeland tax collector. We notice that your address at your old address is delinquent. Please review this document and whatever. Boom. Done. We're highly personalizing phishing for using known data. I have a really hyperbolic version of a phish here coming up. But the amount of data that we have is staggering. And we'll use all of this data in a really cool fish here in a second. But we got names, we got aliases. If you had a previous name that you went by, maiden names and the dates that they were associated, the dates of birth, the age, whether you're alive or whether you're dead. Previous addresses, current addresses, the dates that you had those addresses, the phone numbers, the residencies that you've used and the telco provider. We know the neighborhood information, email addresses, relatives, relative types. There's just so much data that we can retrieve using these people data sites that's free that anybody can do it right now. And so this is just a quick sample. This is fast. People search the same data. Marshall Mather. So if anybody knows Marshall Mathers, would you please stand up?

B (49:29)

Would you please stand up?

D (49:30)

Yes, please stand up. Please stand up. This is really Marshall Mathers information. There's his phone numbers, there's his current address, there's his email addresses. There's his possible relatives. Look, Kimberly Mathers. It's just, it's crazy how accurate this stuff is. I mean I've been watching TV and I like watch some actor or some whatever that's on there on these reality shows and then I'll go straight to fast. People search on my phone and just pull up all their personal information. It's super creepy. Pulling up their passwords is even more creepier. But it's all just readily available. It's just a sample. So here's my exaggerated fish. So hey, first name and you just fill it in the blank. You can automate this whole thing, this whole attack chain. Have you been. It's so and so from previous city and we noticed that, you know, blah blah blah. It's crazy how customized you can get with the details from this information.

B (50:19)

This also gets in when you're talking about the fish. The more points of contact that are relevant to that specific individual that you can put into a fish, the more likely they are to click the link that you actually provide to them every single time.

D (50:30)

And the worst part here is if I'm doppelganging as your friend, you're not going to expect my email from your corporate email. You're going to expect it from my throwaway Gmail account. As long as it remotely looks familiar using his name or whatever. So, so what can we do? How do we prepare and prevent. We can reduce our digital footprint, right? So watch out for personal emails coming at work or any personal stuff. So whether it's like your tax collector information emailing you at work, that would never happen. But when you start looking at the information, you start seeing how accurate it looks. It gets a little scary and you start wondering, really.

B (51:03)

And when you started pulling this together, it was kind of curiosity. You're just kind of pulling in some data. But after a while it got to the point where it got more and more frightening.

D (51:10)

Right.

B (51:10)

And you have a reference to your blog post a little bit later, talking about just stepping away from Google is just one thing. And then this with the gdpr, I think we all need to become Estonia residents, right?

D (51:21)

Yes. Unless you have a clearance. I heard that you have to go back through the clearance process. Somebody from DODB sides came up to us afterwards and said, I think it does mess with your clearance.

B (51:30)

So those DoD people are just a pain in the ass anyway.

C (51:33)

Don't listen to them.

B (51:33)

You shouldn't party with those people.

D (51:35)

Yeah.

B (51:37)

So according to the JFAN 6:3 and the D skid 63 and the ladies.

D (51:41)

No. No.

D (51:43)

So there was this interesting blog that came out recently. Actually Bronwyn from Sans send us an email with it. It was cool. It's the Vermont Data Broker search. So Vermont made it a requirement that if you're a data broker that you have to register with them in order.

C (51:56)

To do business in Vermont.

B (51:57)

So it's a good place to get a list of data brokers then.

D (51:59)

That's what we're doing. Yeah, we're aggregating and we're finding out how to opt out. Some of them are through like email, some of them are through a form, some of them get the mail or phone calls. So we're trying to concoct like kind of put a big list together and hopefully do something about that. Or like John said, you could become an E resident. The cool thing with becoming a European resident is that you could fall under the gdpr. And the erasure clauses are really good. They make it so that they have to delete the data, but they also make it so that they have to notify third parties that that deleted data has to be there as well. So if they've shared information with a third party or a partner, they have to delete it as well. I may or may not have a German address and email address and phone number. And I may have walked away from Google and hopefully tried to do a GDPR erasure, but I'm still waiting for that to actually come to pass. But with that, we do. I don't know how much time we have for questions. We've answered a bunch of them. I do highlight my. My journey here with regard to leaving Google. One of the big things that I learned is that, you know, putting all of your eggs in one basket makes it really easy for them to track and kind of aggregate and pull together and use against you in some cases. I'm not saying Google was doing that. You'll have to draw your own conclusion on whether or not they're doing that to you. But for me, I have, I mean, in part one, I had a little experience with Google directly, and then part two, I kind of purged Google from my life and I outlined the process and undertaking that it was. So it just kind of gives you a little bit of help.

B (53:27)

Well, and kind of kind of down the path that you've gone down over the past, I would say, six, seven months. A lot of it had to do with your job.

C (53:34)

Right.

B (53:35)

You know, trying to do these types of attacks, doing real red teams, targeting individuals, targeting organizations, setting cloud services against each other. And this gets into a really nasty gray area where you have very, very large organizations. And it's not just Google. Right. I think that your, your journey isn't just like Google is the only thing that's evil. It's like this is how hard it can be to disentangle one.

D (53:57)

Right.

B (53:57)

And, and setting up like we got into the conversation on Twitter about red teaming and what that's supposed to look like versus a penetration test. And I feel when we're looking at pen testing, red teaming as we're moving into the cloud, that many testers are going to have their hands tied because of the difficulty in dealing with these very large data brokers dealing with cloud services. And, and they would much rather us not test anything at Amazon or Microsoft or Google or whatever than actually allow us to test our customers completely. And that goes back to. The game is changing. If you're still looking at active directory and you're finding all those different pathways, those still are valid, but I would argue within the next five to 10 years, maybe even sooner, you're going to see the vast majority of organizations that are in cloud only infrastructures and their quote unquote, zero trust model, and those are not necessarily more secure.

D (54:46)

Yep, completely agree. So here's our Twitters, if you don't already follow us.

B (54:52)

Tweeters.

D (54:53)

Twitter.

B (54:53)

Yes.

D (54:55)

So cool. Any other questions that we had?

B (54:57)

Oh, there's been so many questions we've had. I know Jordan's been on CJ's here. I've been answering questions, Jason's been answering questions. But it's been, it's been a lot of questions. So with that, are we okay if we close it out, gentlemen?

D (55:11)

Yep. All right, good.

B (55:13)

Thank you everybody for attending and we will see you in our next webcast. I think the next webcast is from Jordan, is that correct? Jordan? He's muted right now, but he'll jump on. I don't know what our next one is. Maybe Jason knows, but Jason's got a migraine.

D (55:28)

Yeah, nothing scheduled right now, John, but we'll put out an email as soon as we know.

B (55:32)

Well, hell, then I might take next week. Well, no, let's start with Jordan's. Jordan has a really cool one that's a step by step attack from beginning to end and attack tactics that instead of PowerPoint slides, he's going to do it live from harvesting user IDs, password, spraying, gaining access to the internal network, pivoting, getting a domain administrator account. And then we'll go back and then we'll cover all the defenses and by the way, defenses to detect a lot of things like Bloodhound and things like that are a train wreck. And we'll cover those. So thank you very much, everybody, and we'll see you in the next webcast. And Mike, Bo, thank you so much for putting this together for us.

D (56:07)

Thanks, John.

A (56:09)

Thanks for listening. Remember, if you enjoyed this podcast to leave us a positive review on your streaming service.