Google Dorks.
In this video, we're going to be taking
a look at the process of utilizing Google Dorks
or Google Hacking as it's known as by hackers and penetration
testers to essentially identify information
pertinent to a target.
And in this case, we're going to be primarily focusing
on domains as our targets.
So we're essentially going to be taking a look at how
to utilize search filters, Google search filters to find
exactly what we're looking for.
This will include specific subdomains, specific files
associated with a target like maybe we
wanted to find PDF files that are publicly
available for a particular domain, et cetera, et cetera.
You get the idea.
You'll actually see what this looks like when we get started.
So again, I'm going to be utilizing my Kali Linux VM.
And, of course, you can follow along if you want to as well.
Just remember, be very careful with what you actually
engage with.
Because as you'll see, there is quite a lot of content
you can find online that is unsecured and could
be potentially useful as a penetration tester.
So let me just switch over.
All right.
So I am back on my Kali Linux system, and we can get started.
So I'm just going to open up Google, because that's
what we are dealing with.
And then we will actually walk through it.
So there we are, google.com.
So let's say our target is ine.com.
So a standard person who is unenlightened
might just type in ine.com, right?
Fairly simple.
So we type in ine.com.
You can see we have ine.com here, their LinkedIn page,
Twitter.
That's looking OK, but this is really not
giving me information that might be useful to me
with regards to this particular domain.
So let's say I wanted to limit all results
to this particular domain.
To do that, I can utilize the site operator.
And I'm just going to zoom in here.
So this site:ine.com.
Now, you'll see what will happen.
So as you can see, it will now limit all results to specific--
it'll limit all the results to the domain ine.com,
but not just that.
It'll also show you subdomains for this particular domain
here.
So you can see we have my.ine.com.
We have ine.com here.
These are all the pages or categories
for the ine.com website.
So you can see we have blog, careers.
So we are already starting to actually identify
potentially interesting pages and not
just that, but potentially interesting subdomains
like, for example, they have courses.ine.com,
they have community.ine.com, so on, and so forth.
But this is still very wide with regards to the scope.
We can pretty much go through all of these pages
and identify subdomains that might be
interesting like this one here.
Although, I'm not telling you to do that, but let's
say we wanted to look for specific results
and we want to limit it to ine.com.
But let's say within the website title
or within the website URL, let's say
we were looking for an admin panel.
Well, we could say inurl.
So that's the next search filter.
We can say admin.
Will this show us an admin panel?
Well, it shows us a Microsoft 365 Teams Admin page,
which looks like a course.
Nothing to do with admin.
Let's see if we can find anything there.
We have another page here.
But yeah, we pretty much don't have anything there.
So that's a bummer.
So we can see we have the forum.
By the way, we can also change this to forum.
If we are looking for an INE forum,
we can just type inurl forum and then
we go, we get links pertinent to the actual search,
the search queries we have provided.
So you can see that the forum is community.ine.com.
So we've been able to identify that conclusively.
Now, let's say we were looking for things that
are a little bit interesting.
What if we wanted to enumerate subdomains via Google?
Well, we could do that.
And the way we can do that is by saying site
and we then use the wild card symbol or the asterisk.
And we say site:*.ine.com.
This will not show ine.com, but it'll
show subdomains for ine.com.
So I'll hit Enter.
And as you can see now, we're getting somewhere.
So we have my.ine.com, courses.ine.com.
So this is essentially what sublister was doing.
It was essentially utilizing docs for all the search engines
to limit the results to subdomains.
And these are, of course, subdomains that
have been indexed by Google.
Now, you may be thinking to yourself,
well aren't these the subdomains that INE has
exposed by their own choice?
Well, that's true.
That is the case.
But in some cases, companies can become very sloppy,
and they may expose a subdomain to the internet
that they probably don't want to expose.
And in many cases, some companies
don't even know that these subdomains
are accessible via Google.
So let's take a look, and let's see.
Oh, looks like we have the same remote desktop one there.
Let's take a look at some of the other ones.
OK.
We have shop.inecourses.
We've already seen that, but we still
aren't getting anything interesting.
Nothing interesting so far.
So let's try and make this a little bit--
let's try and make our search a little bit more refined.
So I can say inurl, we can say maybe admin.
Let's say we're looking for a subdomain that
has admin in its URL.
In this case, that might not be very useful.
So we can use the entitle operator or filter
that will essentially limit all the results to subdomains
with admin within the actual site title.
So I'll hit Enter.
And we have a sales admin, which looks like the subdomain is
stgacp.ine.
This looks like a CRM.
So you can already see that just by utilizing the Google search
engine and utilizing Google Dorks,
we can start finding subdomains manually
and of course, this is something that sublister would do.
But it's very important that you learn how to do this yourself.
Now, why am I saying that?
Well, let's say we wanted to find--
we can say, let's limit it to subdomains of ine.com.
But we wanted to find files.
So we can say file type and then we specify the type of file.
So let's say PDFs.
So you can start to see that now, it's
going to limit the results to subdomains
that have PDFs or pages or subdomains
with pages that have PDFs.
So in this case, it looks like we have a diagram here,
a network diagram.
Interesting.
And let's try and limit this maybe to sales.
Let's see, oh, nothing there, so nothing useful there.
Can we say CRM may be?
OK.
Nothing there.
Maybe marketing, nothing there.
OK.
So you can see that we probably need
to make our search query a bit more specific
or we pretty much do not have anything--
we didn't get anything returned by Google.
So let's try and limit this to xlsx files
or Excel spreadsheet files, nothing there.
OK.
That's good.
Maybe PDF, we've already done PDF.
So can we say documents?
So doc or docx, nothing there.
Maybe zip, I believe zip still works or .zip but you get
the idea.
So we can limit it to specific files.
So if we say PDF or maybe we can say filetype:xlsx.
And instead of searching for subdomains,
we just search for-- we limit the results to ine.com.
In this case, nothing there.
So maybe docx.
OK.
So Google has, of course, detected
that we are making too many requests, good on them.
We are making too many requests.
Taxis, taxis, I believe that's all the taxis I can see there.
So OK.
That looks like it's working.
So nothing there.
So that is how to essentially limit
or how to perform subdomain enumeration manually.
Now, one other thing that we can do for example, if we're
looking for information regarding employees,
for example, we can say a site ine.com,
and then we can say employee.
So we can enter a standard search query here.
So we can say site ine.com employees.
And you can see we get results based on the actual keyword
that we specified there.
So if we were trying to look for employees or individuals that
work at INE, this would be one of the ways we can do it.
So you can see that you can limit it
to what information you're looking for specifically.
So there we are.
We can also say maybe--
let's see, ine.com maybe instructors.
And this will probably display.
There we are.
So we have the instructor's page.
So you get the idea.
You can pretty much search for whatever you're looking
for by utilizing Google Dorks.
Now, let me take you through a couple of examples that might
not be too good to show you.
But if we were looking maybe for sites
with directory listing enabled, we
can use the intitle search filter
and specify that within the title,
we're looking for index of.
So this is a common vulnerability
within web servers.
So if you're familiar with how web servers work
or if you've ever set one up, there
is a misconfiguration called directory listing.
Now, it's not really a misconfiguration.
But you really rarely want to have this open or running
on a production site.
The reason for that is because it
allows users to view the contents of that directory.
So in this case, it looks like we
have a couple of sites that are hosting probably
pirated movies.
So I wouldn't recommend clicking on that.
And you can see that nothing else there.
It's not displaying anything else there.
So next, we have a couple of other sites.
There we go.
You get the idea.
First, to show you how this works, if I click on maybe--
this looks like a government website.
So index of data, that's probably secured.
But let's click on that.
No, it isn't.
So it looks like they have data that's publicly exposed.
I'm not really sure what this data is.
It looks like-- yeah, I'm not going to click on that.
Anyway, this is publicly accessible information.
But again, I'm just doing this for educational purposes.
There are a couple of other searches
we can perform that I haven't covered here.
But let's say we wanted to try and find
an older version of a website.
This is very important, because companies can modify websites
and are constantly making changes to website.
So if you wanted to see what the website looked maybe five
months ago or maybe one year ago,
you can use the cache operator and then specify the site
itself.
So cache ine.com, and we'll give this a couple of seconds.
And again, it looks like I have the same issues, so boats,
do I see any more boats there?
Verify.
OK.
Google probably allow us to do that.
So there we are.
So that'll display the Google web cache for ine.com.
And in this case, it looks like we don't have any--
this is pretty much the latest version.
We can also utilize the Wayback Machine.
The Wayback Machine is a site that
stores older versions of websites it essentially
takes a snapshot of a website after a fixed period of time,
and it stores those snapshots.
So I can say https://ine.com, and it's
going to take a second.
There we are.
It's taken snapshots all the way from 1999.
So we can see the earliest version of this website.
So I'll click on the snapshot maybe on the 9th of February.
This is very close to when I was born, which is scary, actually.
But there we are.
Let's see how the website looks.
It looks like he's saying Welcome
to the Great Web of China.
I'm guessing that's before INE actually set it up
for its current use case.
Let's see how we looked in 2006.
So let's see how it looked on August the 3rd.
This is really cool.
So the snapshot was taken 2200 hours.
Let's click on that one there.
This is 2006.
So I'm expecting it to be--
well that snapshot doesn't really make any sense.
Let's take a look at a more recent one, maybe 2016.
That's probably where things started
getting really interesting.
So maybe March the 12th, 2016.
So we can start to see how the website looked then.
So you can see, we already have in the title,
we have CCI training.
So I'm just going to give this a couple of seconds to load up.
So if you ever want to know how a site looked
in 2016 like for example ine.com,
this is how it looked like.
So the Wayback Machine is really cool,
because it gives you a historical view
of what a website look like.
Let me show you something even cooler than that.
I'll show you what hackersploit.org look
like during its inception.
So hackersploit.org.
I know that we really had very, very bad theme right
around 2018 when I first set the site up.
So let's take a look at April the 20th, 2018.
I'm not really sure what to expect,
but this had a different title, hackersploit cybersecurity.
Let's see what that looks like, because I think
I've even forgone that myself.
Yeah.
We'll just give this a couple of seconds,
because it needs to fetch that content and then, of course,
render it so that we can view the web page.
So this is our hackersploit.org looked.
Nothing too different but the theme definitely has changed.
But you can get an idea as to how this would be useful.
So a good example of this is I'll
give you a personal example or personal analogies.
When I was performing a pen test for a company
that I can't name, they had information
that was potentially useful for attackers
on one of an older version of their site,
probably four or five years in the past.
And they thought that information was not
accessible by anyone.
And with the Wayback Machine, we could go ahead and view it.
And there was a lot of sensitive information that was leaked.
So you can definitely take a look at the Wayback Machine
to get a historical view of what the website looked like.
And of course, that's not just why you should be doing.
It is because older version of website
might have potentially important information
like email addresses, contact information, et cetera.
So let's head back over to google.com.
And I'll probably explore a few more Google Dorks
that we can use or that you can use
rather if you're ever trying to find interesting stuff.
So another example of this is, let's say,
we wanted to see if some website has inadvertently
listed, or saved, or exposed the directory that has passwords.
A lot of people do that.
So we can, for example, say inurl, and in this case,
we can say auth user file.txt.
And you can already see that a few sites have them.
So for example, this one here, which is just an IP address.
And they probably have this exposed on the internet.
And that means that there's a login form here.
There's probably the password--
the passwords are probably leaked
on this page.
I'm not going to get into that, because again,
that'll be going over what I'm allowed to do.
But looks like we have another one here.
And it looks like the same site.
Interesting.
Very, very interesting.
Let's change this around.
I think there's another one we can use.
So we can say inurl password.txt or maybe intitle password.txt.
So it looks like we have a couple
of sites that have leaked their password.txt
file on the internet.
Let's take a look at this one.
Yeah, that's the etc password file.
And hopefully, these individuals or the owners of this website
here haven't inadvertently leaked this information
to the public.
But there you go.
You can see that there is a password
information or at least usernames for a specific domain
here.
But you get the idea.
You can do a lot with Google Dorks.
Now, I've not covered all of the most important ones,
because I'm really focused on passive enumeration
or passive information gathering.
One of the greatest resources for whenever you're
trying to utilize Google Dorks or perform Google Hacking
is the Google Hacking Database, which
is owned by Offensive Security, the parent company that
owns and develops Kali Linux.
So this is a database of Google Dorks
that can allow you to find specific information.
So for example, in this case, this
will essentially-- this Google Dork
can be used to find files that contain juicy information.
So these are government sites.
So you can see we have site gov dot whatever.
Intitle index of because directory listing is enabled
and the file type is CSV.
So we can actually test this.
Let's see if we actually find some juicy files, which
of course, we will because people don't take the time
to secure their stuff.
So there we are.
A lot of sites here.
These all look like government sites
for different governments.
And as I said, I'm not going to be going through this.
But you can see that they're all being leaked, because directory
listing is enabled.
Most of these are WordPress sites,
which makes a lot of sense, because WordPress
can be quite hard to lock down.
But yeah, you can also limit this to--
you can specify additional keywords
to find what you're looking for.
So maybe you can say passwords.
There we are.
And in this case, that will limit it
to any URL with the gov dot prefix.
So you can utilize the Google Hacking Database
to find specific information.
So let's take a look at a couple of others that might
be potentially interesting.
These are the latest ones here.
Let's run a few filters.
So let's say we're looking for files containing passwords
probably.
There we are, files containing passwords.
We can then utilize these particular docs or search
filters to look for files that contained passwords.
So we can use this one for example here or maybe this one
here.
Let's see whether we are able to find any credentials that
might have been leaked.
There we are.
You can see that we might have a few here.
So this looks like potentially interesting website.
And that is--
I probably won't check them, because I
don't want to do that.
But you can do a lot of stuff with the Google search engine
through the use of Google Dorks.
I've just gone through some of the most interesting ones
that you can do from the perspective of a penetration
tester legally speaking.
So I'm limiting the results to a particular URL
or a particular title or particular domain or subdomain.
So definitely take a look at the Google Hacking Database.
As I said, this is pretty much a one stop shop,
if you ever trying to find potentially interesting files
or potentially incriminating files
that a company might not have secured
with regards to their website.
So definitely take a look at this.
Especially if they have a WordPress site,
then you can limit this, again, by using the filter option
to a particular content management system,
or you can just perform a search maybe like WordPress.
There we are.
And in this case, we can also limit this to maybe WordPress.
There we are.
And these are all the Google Dorks for WordPress.
So you can try and find WordPress config backup files.
This is something that I've used before.
So let me just take a step back here.
So sites that have taken a backup of the WordPress config
file and have not deleted that backup.
If you're not familiar with it, the WordPress config file
pretty much contains credentials to the MySQL database.
So this could be potentially damning
for a particular company.
But that concludes the practical demonstration side
of this video.
In the next video, we're going to be exploring
the process of harvesting email addresses through publicly
available sources or databases with a tool called
The Harvester.
So I'll be seeing you in the next video.