 Before I get started I want to say thank you to the Reconvillage for having me and today I want to talk about the future of asset management and I really want to ask if we're really dairy it and if that industry has completely grown. Before we get started I'm going to talk about our agenda, like I said I'm going to talk about asset management, different ways you can actually look for these assets, some of my personal benchmarking I've done, some research I've done myself and we're going to kind of live example and then we're going to wrap this up and hopefully I can do some do's and don'ts and give you a overview of what I think should be done in order to accomplish this. But before all that I want to introduce myself, my name is Ben Sadegapur and most people online know me as Nahamsek. I have been hacking for as long as I can remember as a young teenager but I've been professionally doing bug bounties since 2014-15 and I've been really focusing on recon with even a bigger focus on discovering assets and extending my tax surface when it comes down to looking at an organization from an external point of view. So let's dive into it, bear with me it's kind of weird doing these live presentations I'm trying to make sure I have my notes, the recording is going fine so bear with me as I look around and we'll jump right into it. So if you're not familiar with tax surface management it is a thing a lot of companies are getting into the space but it is kind of a fancy term for knowing what your organization has on the internet. So do you know what every domain that you own, every subdomain and that sort of stuff and having an inventory of it and there are big companies out there like Risk IQ, I think I would say it's Balbix, Randery, Coalfire, those are the big ones that I've heard of and I think Risk IQ is in the process of getting acquired by Microsoft or was already acquired by Microsoft whatever it is. There's also census and showdown, those two aren't really doing asset management but they could be used for that kind of stuff if you want to do it internally they're kind of expensive but they do have that data for you to use and get a list of your assets that may be out there depending on how they are scanning the entire internet. So before I get started and dive into all this I want to ask everybody in the audience in the chat, you can drop this in Discord but let us know in the chat if you know what your company has on the internet, do you know everything, just web assets that you have a good inventory and you know 100% of everything your developers have launched and it's currently on the internet. So that includes the root domains, that includes your subdomains, your IP addresses, your EC2 instances, your S3 or your storages that you're using, if you're running stuff on Heroku app, GitHub pages and that sort of stuff that also includes acquisition. So if you are a big company and you require some other companies or some other startup, do you know what you have on there? So if you said yes, this meme is for you, I don't buy it and I'm talking about this based on personal experience. All right. So the reason why I asked this is because having these assets externally being visible to the entire internet comes with a lot of possible vulnerabilities that include subdomain and dangling DNS records, it could be expired domains. So for example, if you've purchased company xyz.com for a site project, did you renew that domain? Did you use it ever again or is it still being used in production? If you're using dev staging environments meant to be internal, are they exposed to the internet? Your continuous integration and development are those tooling internal and exposed. You have your back end applications with a bunch of outdated software probably because you think it's supposed to be internal. You have your admin panels with guessable passwords or maybe in some cases there's no even authentication involved. So a lot of these could be things that are happening. Again, these are things that I have seen based on my own personal experience as a bug bounty hunter and a pen tester. So I'm talking about a lot of experience here, the things that I've seen again, there's a lot of times when I approach a company and I showed them the things that I found and they come back and they tell me that they didn't even know that that belonged to them or that domain belonged to them or this asset was externally exposed. And I'm not saying this, you know, oh, we didn't know this belonged to us to make fun of the engineers or the security teams, but it's just mostly it's a reality of a big organization or a security or organization of its own with a security team that hasn't done any inventory of all the assets they own. And again, like I said, it's not really your fault because this whole thing is incredibly messy. It's it's not easy to do. It's not easy to track inventory. And the bigger the organization gets, the harder it gets. I think about big organizations that you see out there, like Google, Oracle, Apple, we'll talk about a little bit. But I think that it's really, really messy. First of all, it requires a lot of skills to operate and track assets. If you're doing this in-house, you might have a dedicated team that's working on some sort of a project to keep these things, to track these things and keep an inventory on it. There is no way of providing 100 percent coverage. If you're doing a vendor, for example, there's no way to give you 100 percent of coverage. That's not really going to be realistic because you're deploying things every day, if you're not scanning every hour, they might miss something that you deployed for an hour ago and it's been up for 12 hours and it's gone down. Those are things that they can't track. And again, like I said, it's incredibly hard to scale these things for a large organization like Google, Apple, Oracle. Think about like Yahoo and Amazon, for example. Yahoo is not as big as it used to be anymore. They've been divided into different companies. But think about Amazon's case. Amazon itself has a ton of different regional sites. So if you're working with Amazon.com itself within the United States, that alone has its own application, own microservices versus the original stuff that could come with the portion of Amazon for India or Amazon.de for other countries. Each have different back ends that each have different requirements, dependencies, things that support it. And each of these different assets could be in a different cloud account. It could just be hosted on a completely different Amazon account than Amazon.com itself because another team, another sub org owns it. And that just gets bigger and bigger. That list goes on forever and it just makes that entire scope of tracking assets a lot larger and a lot bigger. Obviously, I'm not saying like Amazon or Yahoo Google have these issues. But if you don't get ahead of it very early on, it's going to be very hard to track later. And you have to make sure you implement things properly. So things that are supposed to be internally visible only as they stay internal. So you don't have to worry about so much of tracking and keeping them locked out. So I said this again, not your fault. If you're a security engineer, you're watching this, you're on a security team, you're a CISO, whoever you are, this is not your fault. You just have to figure that, especially if you're new to this company. So just think about the scenario. You are the new head of security. You are a security engineer. You just got this job at this new brand new startup. You learn the end and outs of your organization. You learn all your policies. You learn how to improve a few things. You see all your pitfalls, things that need to be improved and built on. Four years goes by. How does it look like now? Did you face any reorgs? Did you have to move from an in-house space or an environment to the cloud? Did you have to switch providers from Azure to AWS because you had a better deal or your budget was cut in half? Whatever that reasoning could be. How did you track everything? How are you tracking everything as you go? How are you tracking everything that needs to be moved from one provider to another? There's a lot of things that could happen in a few years. And if you don't have the right processes in place, that is going to be extremely hard to keep track of. That's just an example of it, why it's messy, why it's hard. And obviously more teams and more people in charge, people come and go, they leave, things will get messy again, even more messy. And vendors are also a big part of this. They need to step it up to talk about why the vendors aren't doing a proper job of doing it. And yet I'm not here to bash up any vendors. Anybody that I mentioned throughout this talk isn't a part of the problem. It's just this is a very young and new industry. But the only thing is I've realized is they're either really get out focusing on being a get out one aspect of this asset management game, or they offer a large variety of what I call unfinished products. So either they're really, really good at scanning the entire internet, but they don't give you good data. They don't have a good way of allowing you to ingest that data or look at that data or the reporting for it. Or they do a bunch of different things like they scan ports, they pull certificates and they look for loans based on CVEs, whatever it is, outdated software. They do all this stuff, but it's unfinished. It's not fully done yet. And the ones that do actually do this, they're very, very expensive. They cost a lot of money. One of the vendors that I know, a friend of mine works with. I think they pay about $20,000 a year and that's just to get an access to an API, just an API that gives you data for $20,000, no real reporting, nothing like that. It's just very expensive. It's also hard to get real time data. So by that, I mean the scan times are either too long. It takes a few days to scan it and it's not their fault again because there's a lot of IPFs. There's a lot of data out there to be brought in. And they also rely on organizations knowing what they own. So if an organization itself doesn't know what main domains they own or what subdomains they own, what environments they have, it makes it harder for them. In a lot of cases from what I hear is the CISO head of security, the CTO who is in charge goes into this vendor meeting and says, I don't know what I have figured it out. That's not how it should be. There's got to be that bridge that's built between the two vendors and the consumer to make sure everything and everyone's getting the full coverage of some sort of getting close as we can to providing full coverage. So what do we do now? Well, before I jump into this, I'm going to go back before I answer this question. I wanted to actually show you what it looks like from an attacker's point of view and how you approach a company and kind of walk through that process. And this is going to also touch on a limited number of tools, techniques and methods that are out there. And I'm going to try and keep as high level as I can without diving into too much details, but I think it's something that we need to talk about first. So the first thing is we're going to look at the organization's structure. So again, if I mentioned Evil Corp, I'm not calling any corporations evil. It's just the easiest name to come up with. But let's say Evil Corp owns Evil Corp.com. This is a large corporation. They already have thousands of subdomains and internal domains. They could have Evil Corp internal or they could have Evil Corp.net and some people could calm for their internal or corporate websites. Evil Corp takes off. They have a ton of money. Investors are happy. They want to take more of the market share. So what do they do? They acquire Evil Startup. Evil Startup happens to be a big infrastructure of its own. They have a lot of stuff on their own. They have a lot of domains, have a lot of subdomains. And let's not even talk about the ASNs and the IP blocks that they may own because that itself is another part of this whole entire thing. That we have to take a look and repeat the cycle. They buy more and more and more and more startups or other companies and that scale gets larger and larger and larger and larger. And it's very common in tech companies, especially to see these mergers or acquisitions to happen. So we have to think about how big this thing could become. As an example, we can see that Uber has six acquisitions. As far as I could find, this is in the past 12 years. The biggest and most recent one was their acquired postmates and postmates. I'm talking about experience here. They have a large infrastructure of their own and I don't know what Kareem is, but that's another entire organization of its own to worry about. And Uber itself is huge. You have Uber.com, Uber internals. They have a bunch of different IP addresses. So that itself is huge. That's only with six acquisitions, right? Apple. I don't know what these two companies are, but Apple's infrastructure alone, I think it's somewhere between last I pulled a number one, and I think it comes down in a few slides is they have about 70,000 domains or subdomains that has a keyword Apple in it. And that's just Apple.com alone. And it doesn't include anything like iCloud or anything like that either. So they have a hundred fortune acquisitions. Their ASN is giant. It's one point something million IP address as far as I remember. It's huge. Just think about it. Like this is a giant company like Apple itself. And they're not even the biggest one yet. There's also Google. Google has two hundred and twenty five acquisitions. They have companies like Pointy and AppSheet and more recent ones or more bigger ones that I know of the ways. Looker Google itself, Google Doc, Google Drive, Google Sheets, Scholar, Gmail, all these micro apps they have. They're also huge. I have a ton of back ends. They probably have a huge infrastructure also as well. So you just can imagine how much work to have done to keep an inventory to make sure things are not being exposed. I'm not saying Google, Apple, these companies actually know every subdomain or domain they own. They may or they may not. But they have done the right things, the right approaches to make sure things are gated enough so the outside world doesn't see some of these domain or subdomains, internal services or their corporate dev site, whatever it is, they're not being visible by the outside world. So we're going to talk about OSIN. And this is I want to talk about acquisitions first. Just to paint that picture of how big an organization gets. And then how do I, as a hacker, can identify all of these domains if I'm lucky or if I have the right tools? So OSIN is a big part of it. Now, we're going to talk about a company that I like to work with a lot. I've hacked them a few times, but they also have a great blackbody program, great team. They have a great infrastructure. It's a huge infrastructure. There's a ton of acquisitions, PayPal. So we have PayPal, obviously they own PayPal.com. But what are some of the other domains they own? What are their acquisitions? What are their internal domains? What are their corporate domains? And what are some of the methods that we can use easily using OSIN or some toolings that are open source and find more and more of these assets? Well, let's take a look at the who is data for PayPal.com. And this is really important. They have the organization for the registrar for the administrative contact. It's PayPal Inc. And the email address right here, our starting point is going to be hostmasteratpaypal.com. That is great information to have. And again, I'm not saying that every time we go and do a who is on a domain, they're going to have this data for us. But in a lot of cases, some companies have this email for the registrar. And again, it could be masked sometimes, it could be protected. But in this case, it's not great. What we're going to do is we're going to find a website like VUDNS Info. This one costs a little bit of money. I'm sure there's better tools out there for it. But this is one that I found that was very, very helpful. So you go to this, you can do a reverse who is lookup, right? So cool, we can do the registrant name. We're going to skip that one for now. Too much work, but just for the sake of this conversation, for the sake of this presentation, I'm going to look at the email address of the registrar. So I'm going to go in there, I'm going to type in hostmasteratpaypal.com. We're going to push go and it's going to come back with 3962 domains that this company has collected through the reverse who is lookup that belongs to paypal.com. Me as a bug bounty hunter, adversary, whatever you want to call it, 500 of these are free and accessible to me. And I can just spend 50 bucks and get a whole list of almost 4,000 domains that belongs to this company. And that just starts, it's the start of my day, it's the start of my work. But you can see there is accept Venmo, which hints that they own Venmo. They have some PayPal stuff, they have some funding domains. You can go through the list and find a lot of different information. Personally for me, the notable ones was paypal.com. Done, that's a obvious one. That's one that we know they own. I also saw something like paypal.corp. PayPal is actually very well known for having domains that either end in dash paypal or start with paypal.dash. So it could be paypal.marketing.com, paypal.corp. As you can see on the screen, they're also on paypal.corp.com. Braintree is one of their other acquisitions or domains. They have Bell Me Later and obviously Venmo being another big one. Well, we know that this is not the entire list based on Braintree alone. We can see there's Braintree.com, Braintree API. There's the tools and they also have the gateway. So there's a lot of domains that probably has the keyword Braintree within it that we can find later on as we do more research. And excuse me. And they all probably have a ton of sub-domains too. I know PayPal itself is huge, but Braintree Tools is an internal one that's huge. But this is just to paint a picture of how big and how messy this could get. Well, lucky for us, there's a certificate of transparency, search transparency, which is an open framework for monitoring SSL certificates. So as soon as the certificate is issued to a domain, it gets indexed through one of these different frameworks. Showdown does that, they allow you to do it through Showdown. They're not specifically doing this, but Showdown allows you to search for it. Census allows you to do the same thing for a limited number of queries, but I think you can pay them like a thousand or something dollars a month. I'm not sure how much, but you can pay them some money that will give you access to it. Search data stage is free, but they don't give you a lot of data. It's still useful to me personally as a hacker, search spotter, and also Google and Facebook have also gone into the search transparency game. So you can use it actually with Facebook, the cool thing is on my phone, I get push notifications of some of these companies that I have set up an alarm. So it tells me when a new certificate was identified, which is great because I can monitor it now on my phone. Well, when you come down to looking at a certificate, there's a few things that are very, very important, at least for my perspective and things that I look at when it comes down to identifying assets. The first one is the subject organization. This is the organization that owns the certificate based on the public key. The subject common name, which represents the server name that's being protected by the certificate, which is the host name in a lot of cases. And also there's the subject organizational unit. This is the department or the acquisition. So in the example right here, as you can see the organization itself is PayPal. The organization unit is Venmo production and this was issued to common name ops.venmo.com. And actually if you pull this up and scroll all the way down, there's a ton of different domains that's also listed at the same time. So, but it's a good information to have. It helps you identify and narrow down more of your search. So I mentioned Census, one of my favorite tools to use. It's nothing new, but it allows you to look based on the organization name. So all you do is part subject organization. You type in PayPal Inc brings you about 8,000 domains. Great, or 8,000 assets. And you can see PayPal Inc and Braintree down there. And also right here QA.Zoom or XOOM, however you say that. That's a domain that I didn't know about in my previous slides that also came up. Great, that's awesome. We found even more assets that belongs to PayPal. We can also do the organizational unit. So PayPal itself is PayPal production. I typed in PayPal. It gave me SecOps, PayPal Corp. Roka or ROCA, PayPal.com, excuse me. PayPal Inc.com and another additional 3,000 domains. Some of it may be the same as the previous one, but it's just to show there are different ways you can actually identify these just going through the certificates that are on Census itself. All right, there's also the common name. The common name is a really weird head or miss one depending on the organization, but you can always look for the common name. You can type in PayPal.com, PayPal, whatever you want to look for. That's a great way to look for it. Not really as helpful as the previous two, but it still gives you some data and it shows you which ones have expired, which ones have been issued by the dessert versus various side and that sort of stuff. And the good thing about this is if you go back, you can actually do the tag or you can actually sort them by the issuer, which is great because if you see the pattern that is being used in a particular asset, it helps you narrow it down even more. So this is also the search that I said is one that I use religiously. It actually has, I think has a better functionality for searching than most other ones like Census have, which allows you to actually search by any of these fields through the certificate, the common name, email address, the unit name, organization name, the DNS name, anything that you want to search where it's awesome. It also gives you some more data and the search can also add output equals to JSON, I believe. And that gives you a JSON blob of the same exact data and it tells you when it was logged. It was the first time they've seen it. It was the last time you can see it. You can sort by it and all that good stuff. It's a great tool to use, but it also gives you some decent data. It doesn't give you the IP address. I think Shodan is one of the only ones that does it. That's the tool that I use also and does a similar thing. It's just, it's good to have the IP address, but it's not required because sometimes these are probably more than likely internal. Like I hope these IQA sites on PayPal itself, contenttransform.qa.paypal.com, more than likely internal, but you never know. Well, there's also recon tools you can use. Amass is one of the best ones, I think, personally. Big shout outs to the OWASP Foundation and the team to support this. Adapting it also, Jeff Foley and everyone that works with him is an amazing job. I'm not here to sell you an Amass, but there's a bunch of different tools you can use. Subfinder, I think the guys at this project discovered that some of the good work. There's a ton of them you can use, but Amass is a good one because it actually allows you to do a bunch of things. So these are the three things that I think are very, very useful when it comes down to using tooling like Amass. The first one is Intel, which it collects Intel for enumeration. So if you type in collect Intel on organization PayPal, it looks for all the domains it has in its tool set with all the different sources it has, and then you can feed it into Enum later on, and it will perform enumeration on these different network mappings or subdomains and domains that you have found through the Intel. And then next, you can visualize it. So it actually gives you a really nice looking graph that shows you how things are connected. There's also some DNS stuff you can do with it to see if it resolves. There is a tracker. There's a DB thing in there. There's a bunch of different other things you can do with it, but these are the top three things that I found was really, really helpful using Amass. The way they collect their data with Enum itself, it's through DNS. So they do some brute forcing, they do some reverse DNS thing, they do some walking, there's zone transfer, there's a bunch of different things. You can go on their GitHub page and actually see a lot of this functionality. And there's also the scraping. They look at ask.com, but do all these different search sites, doc.go, DNS, dumpster, and so on. They look at certificates. We covered this already, but you can connect it to Facebook API, Google, search spotter, search.sh. They actually have a bunch of APIs. So if you use some sort of an API, you have a key for Alien Vault, search spotter, I mentioned that earlier, but any of these different APIs that a vendor you may have a key to, you can feed it into this through the conflict file, I think, and it will pull from it. And also it goes after web archives. If you're not familiar with Wayback or archive.org, it actually goes to it. You can see the websites from 10 years ago, 2006, maybe even further, like 20 years ago, and it collects data based on that as well. Amazing stuff you can do with it and just goes beyond just a regular searching. There is a lot of good weaknesses and strengths for this. The biggest strength is it gathers a ton of information that gives you domains, it looks for ASNs, they look for a bunch of different things with different methods that include your certificates, brute forcing APIs, there's multiple sources, they allow you to do a scripting engine of its own. We can write some additional tooling and do other stuff with it, but it has its downfall, it has its weaknesses. You can't rely on a single tool. First of all, as an organization, even as a hacker personally, I don't just rely on a mask. It's a great tool, don't get me wrong, but it's not 100% giving you 100% coverage. It's really slow against large organizations just because it's not so much that they're slow and they've dealt with it to be slow, but the more data you have, the more time it's gonna take for this to digest, run Intel or get that Intel, run an immigration on it, and then finish that thing up. If you're doing 20 domains and each have 1,000, 2,000 domains, it's gonna take a very long time. It's not on a mask, but it's just one of that weaknesses because it's a single tool, especially if you rely on it. And again, it might miss some of the newly developed or deployed apps or domains. They may not show up. I did a benchmark on the domains you could find based on the who is, and it was missing a ton. And again, it's still a new tool. I think it's only been around for a few years, but it's getting there. And also let's be honest, does every domain and every subdomain have a certificate? I think it's becoming a best practice to do it on default, but I've seen a lot of domains, a lot of subdomains at least, that may still not be protected by an SSL cert. So that's another one. It's not so much an amass weakness, but it's a part of the game. Especially when it comes down to certificates. So this is at a high level, what it looks like when you want to enumerate. What I'm doing here is I'm just saying, hey, I don't want you to get any intel. I have a domain that I want to specifically go after. I want you to enumerate, give me the source and IP address. We'll talk about the IP address in a sec, but this gives me where it's coming from. So I know, Ops.Venmo is coming from search barter versus scope.qa.Venmo came from hacker target, for example. And it suggests vanilla amass. I don't have any keys or any of my data imported into it, but it's just to show it gives you this beautiful data and it's very, very helpful when it comes down to it. But before I go further, I want to quickly do a recap. I know I threw a lot of stuff at you, but the things that we talked about, I can get it out. The first thing that we talked about was the reverse lookup based on the registrar's email. That's very helpful. If you're lucky, if it's not protected, you can get some really good data. It's not that expensive. You can also use some tools. I'm sure the one that I showed isn't the only one, but that's a really good starting point. Then you can post up the names based on certificate transparency. Great. You can use tools like amass to gather more info, automate, visualize, et cetera. Then we can use what IP addresses are coming out. I mentioned ASNs a bunch of times. And the cool thing about ASN is if you have the block of ASN, so if you see that amass comes back and says like, hey, they own this autonomous number that they have, this ASN number that they have, you can actually have amass enumerate more data and gather more intel on that ASN number. And you can find more domains and subdomains and internal tools based on that. We'll talk about the ASN thing a little bit. I actually scanned the entire IP before that I really want to talk about in a little bit, but that's a really good place to start and see what's being deployed every day or every week within those IP blocks that you own. And you just repeat this process and use other tools. That's what we talked about so far. There are other options. I just brought this up, scanning the IPv4 space, which is one of my favorite things to talk about. And this is one of the things I've been obsessed with for years. But before I jump into this, actually I want to say a big thank you to a few people, one of them being Ziet, Brett Brewerhouse, going by Ziet, an amazing hacker who's been a good friend of mine. We experimented with this a little bit on a very small scale. Then I met Tanner, aka StaticFlow. He actually helped me with a lot of this data. We did a talk on scanning the entire IPv4 and finding some bugs for fun, which led to hacking Apple and a few other big orgs. You can check that out later. It's on YouTube, but it's a very cool thing when it comes down to scanning the IPv4. There's some pros and cons. The pro is you're in control. How frequent you want to scan data for it. You can control that. You want to do it every day. You want to scan it every, we text us three hours so I can literally scan three hours and then reset that scan immediately to see if there's more changes. You can actually store and access the data. Searching is very important and I will talk about that a little bit. But you are in control of how you ingest that data and how you can access it and how you can search through it. And also what and where you collect the data is really important. A lot of organizations are scanning for 443. A lot of companies focus on 443, but we also went as far as scanning for 8443, 8888, 10,4443 and some other ports. And that even gave us more data because some of these IP addresses have nothing on them on 443 versus that 8443. There was a lot of good data that we could come up with. The cons of it, it's messy. I've been saying everything is messy today, but it requires a lot of engineering effort. It's time consuming. It takes a lot of time to get a good build going. It took us over a year to figure out how to bring down the cost and how to do it fast. We made a really big mistake at some point and we sent the wrong request and we got a ton of nasty grams and a ton of pissed off people that didn't understand we're doing this for research. We're not trying to hack into your company. We're just collecting data on your certificates, but that could be a part of it. And it's also very expensive. I mentioned how you ingest that data could be very hard if you don't have the right people to do it. But also there's always this question that I ask. Even when you work with a vendor, you have the data, now what? What are you specifically looking for? How are you going to organize it? How are you going to prioritize what you're going after? But this is my personal use case. For me personally, it gave me more access and accurate data from the sources that I've scanned. The first thing was I can search for any keyword in any domain or any subdomain. So I could just type in, give me everything that has PayPal in it. And I could also say give me everything that has Jenkins and for example, which I'll show those in a little bit. I can also search based on the organization. So I can say, hey, show me every certificate that's been issued by the organization PayPal. We should give me more domains. In our case, we scan daily almost in most cases and we choose what ports to scan. Sometimes we do eight, four, four, three. Sometimes we do four, four, three just because we want to see what data we get. I also like to do, I want to access the IP. I want to know where did I get this certificate? What IP does it belong to? That's very important, especially if it's a corporate domain or an internal asset, then I know where to stop there. We're not going to get into that a lot. I just want to highlight why it's so important. And obviously this also doesn't give me 100% coverage but it's still the closest that's come because I can also look at the different results. So if I scan today or this morning and I re-scan again at nights and it takes me three hours to do each scan, what are the differences we need to? What change for PayPal.com from this scan versus the other scan that I just did? Was it a new asset that came up? Was it a new domain that came up? Those are very, very interesting to look at and I think that also gets missed by a lot of vendors because they're scanning every few days. And I actually did a little bit of research on this last year. We found some really cool stuff that were coming up on a Tuesday and by Friday it was gone. We could no longer see it. It was no longer accessible. It was either put behind some firewall or it was completely taken down. There's some cool stuff to think about, especially when it comes to looking at what assets you own. So one of the things that I was talking about is in this case, I'm just looking for everything that has the root domain. So the brain tree domain, the root domain. So whatever.com.net doesn't matter what it ends with but I want to make sure the domain itself has the word brain tree. So you can see in that tool it's one of the domains is brain tree payment. Brain tree.tools also came up a few times. But I'm also saying look at the sub domain data before the root domain and look at everything that has dev. So it's came up with developers, dev.brain tree.api and blue front door QA dev something. Sorry, blue front door QA dev.brain tree whatever that domain is. So it's giving me some really good data based on brain tree and the keyword dev. I could just switch out Dave for API. I could switch out dev for internal corp whatever that is. So I have the freedom of searching however I want for whatever I want. And it shows me the IP address. Next thing is looking at something with PayPal. I want to see the APIs is what is on paypal.com that has a keyword API. So there is cores on API. Again, think about the domains, the text in there. It's multiple domains on everything. It's not showing the entire row for us in the screenshot, but there are multiple domains in there in some cases. But there's API dash S API dash AA API, API dash AA dash 3 T and it shows me the IP address we're collected from. I did a count. I just want to kind of show how messy it is just for Apple. When you look at the RDN for Apple right here, it shows almost 60,000 domains that match Apple. That's a lot of domains if you are a big organization like Apple itself. So that's another option of things you can do. I'll talk about it in a little bit, but this is the last thing I want to show is Jenkins. This is nothing to do with this talk, but I want to show how scary it is that so many people's Jenkins instances are being shown publicly, almost 11,000, 13,000 or 12,000 of them. But I wanted to show you how messy it gets for some of these organizations, but also having good data. What I was demonstrating there, you don't have to go to the extreme of scanning all of IPv4. You can scan your ASN. You can ingest the data from somebody else, but having the freedom of knowing what you're doing with this data. How are you going to utilize this data? What are you going to search for? How are you going to search for this data? These companies are going to give you a report, but it doesn't necessarily mean it's complete or it's what your team is in need of. So you want to also know different ways and things that you can do with this data to find things that may be useful to you. Imagine if your Dev sites are being publicly accessible and they're publicly accessible and that's not something you need because you don't want it to be exposed. That's a good way of realizing that it is being accessible by a third party or an outsider than your organization. So some of the options of things you can do here is you can pay thousands of dollars a month and have a big or give a list of your assets. There's a ton of those. We talked about them. Again, like I was mentioning earlier, this is not a best way to ingest data or monitor them. Sometimes it's incomplete. Things change day by day. You can also work with those or else you get those open ports, asset names. They'll give you the possible CVEs that your assets are vulnerable to, but it's not a complete inventory or everything you have. You can also go with the smaller ones. Intrigue and asset notes are also really good alternatives. Big shots to Jay Kran and Shabam Shaw, the two people that are behind these two companies. But they have downfalls and this is nothing against them. They're good friends of mine, not here to bash on anybody, but they're still in early stages. They're still trying to figure out how to scale, how to get really good data for each other customers and make sure it's complete. Their product isn't complete yet. They're still controlling or they're still collecting data. It's getting there. Don't get me wrong, but I just want to say there are different options. You don't have to go with the big guys like Risk IQ and all the other ones that I mentioned, there are some bigger startups that are coming out and doing this a little bit different and better than the older ways of doing this. The options that I showed of using tools and chaining them together, a mass up, finders help this or find domain, enter whatever tool name you have here. Like I mentioned, you can also scan the IPv4 or scan ASNs depending on how large your organization is. If you have the resources to do it, good for you. If not, you got to find a way of getting better data or pay for the data that you have. My favorite option personally, and you know it's not going to be a talk by me if I don't mention bug bounty programs. If you have a bug bounty program, work with your hackers. Ask them, how did you find this asset? How did you know this thing was being hosted on port 3000 and you found the IP address but couldn't access it? We can't access this domain, but obviously you have found a way to access by IP. What tools did you use? Was it a source that you specifically paid to get this, collect data from your reports and analyze that? So the hackers are willing to share with you on how they have done these. Understand it, like take some time and work with your teams internally and see why this happened the way it did. Why was this thing exposed? Why was this thing online? What was this thing? Who owns this domain or infrastructure, whatever it is internally and really, really analyze it. It may be hosted recon challenge and if you don't believe me, big shots of security trials actually, they just put it with a mass and they did a competition where they were actually paying or I think it's actually still going on for another few weeks. They're paying hackers to submit data to the platform, which is a great way for them to collect data. I don't get me wrong, but you can do that on your own too. Like, hey, there was a list of everything you can find on our company and wanna know how you did it. People may do it if you have a bug bounty program. If you have the funding for it, you have a bug bounty program, successful program that you work with hackers on regularly, this is also another way of doing it. So I talked about all of this stuff. I wanted to talk about my solution. And I don't think I have a really, you know, one model fits all solution, but I have some stuff that I wanna talk about. So far, we know all the tools, the vendors you can use, the most efficient way of discovering assets, everything's there. We've talked about that it's not 100% coverage, but it gives you a good starting point to discover and track some of your assets. Some of the things that you can do is kind of a do's and don'ts is actually create a dedicated environment for testing sites and make sure it's always protected. So if you're doing dev.site.com, make sure no one can access that. Because if they can access it, you don't have to worry about what's out there because no one can actually see it. It's good to have the list, don't get me wrong, you wanna have a list of those. You might wanna create a process to deploy and track those assets internally, but if it's protected, you don't have to worry about somebody owning that environment and getting in. You wanna also find a way of a process where you can actually take these assets down that I mentioned early on in my slides that once you have these assets coming down, what happens to the DNS record is it's still pointing to the thing that I was pointing to a month ago since the box is down. Or the other way, if you took down the DNS record is the IP address is still up and accessible. You wanna think about those things. Again, make sure you keep track, make sure you have some way of collecting data from your teams and also help vendors. It doesn't help when you go to a vendor and say, well, I don't know what I own. Figure it out. They're gonna figure it out, but at the end of the day, you know your infrastructure better, your engineers know what to look for, what they own, so work with them as well. And that's obviously the opposite. Almost the same thing, but the opposite, don't expose your assets. Don't just take down your assets by deleting the record or just deleting the box and saying, you'll be fine. Don't just rely on vendors for everything. Really find a way how are you gonna take down that data? How are you gonna collect data from them? And what are you gonna do next with that data that you're getting from the vendors? Have a really good process of actually have a process of going through that data and how you want to manage it and what are the things that you look for? And don't wait until later. If you're in a security team at a startup, start thinking ahead. Your company's gonna even grow and grow more every year. So don't wait three years from today to do this. Start thinking about how am I gonna start tracking all these things? So my thoughts on this, again, as I've mentioned, there is, this is still a very immature and young industry. It's still growing. We're getting there. It's not 100% there, but a lot of companies are doing some really good research. Again, improve and create your processes. Really work with your teams. You really want to, I want to make sure this is something that you guys take away. If you folks take away from this talk is to really work with your teams, to create a process to track all of these different data. You work with your vendors. You create your own tools on top of these different vendors you work with. It doesn't hurt to run a mask. If you really know how to use these tools, it doesn't have to be a mask, but running a tool here and there to see what kind of data you have. Work with your red teams, your blue teams to see if they can do it. And obviously really analyze your data that you get from your bug-binding program and other security teams. If you think I've missed anything so far, I would love to hear your thoughts. I'll be in the chat obviously, but I also would love to hear from you. So if you want to tweet at me and let me know, I would really appreciate it. Again, this is something very, very new. I think the asset management, attack surface management industry is going to be the next big thing, but it's also up to us to make sure we work with the entire industry whether it's with your hackers, whether you're working with your vendor, and also doing some additional research and work together really to get this entire thing to push forward. Other than that, I just want to say thank you again for listening to me. I appreciate you all for having me and a big thank you to the Recon Village for hosting this year at DEF CON again. Thanks.