A really common misconfiguration is having SMB shares with
sensitive information open to the public.
So,
let's take a look on how to use PowerShell to find SMB shares in the
network using both WMI queries and Net List queries.
In this way,
we can try to find sensitive information that could
help us in our red team engagement.
So, let's go to our lab environment.
Welcome back to our lab environment.
The idea of this demo is finding servers on the
network that have open SMB shares.
We can accomplish that by using two different techniques.
The first one, which is my favorite,
is using the Windows native feature called net view.
We just have to provide an address to it and release
all the shares on that server.
As long as the shares are open to the public,
we don't need any specific permissions.
The other technique that we could use is WMI.
For example, I could type Get‑WMIObject,
and then this class here, and then the computer name that I want to check.
Once I run this,
PowerShell will use WMI to connect to the machine
and list out the network shares.
However, if you don't have WMI permissions on the target server,
you get an error like this one here.
So personally,
I would only recommend using this WMI technique if you already
have a high privilege user in the environment.
In case you have a low‑level user,
you're better off using the net view technique.
So, in this demo,
we'll be focusing on the net view technique since we don't need
any special privileges to get what we want.
As you might have noted, running net view does take a few seconds.
So,
simply trying to run net view to every single IP on
the network would be too slow.
A better approach is first in finding live servers in the network and then
using net view against only the live servers that we found.
The good news here is that we've already created a
script for finding live servers.
Do you remember our first demo in this module?
So yeah, we have here the code that we created.
We will reuse this tool to create an SMB scanner tool.
As you might remember, when we run this code,
we get a list of servers that are live.
In my code here, I'll put only a small range of IPs to save us time.
But, in your case, you can put a whole network to be scanned.
So okay, let's start to modify the script here.
Since we'll be manipulating the results of this ping command,
I will attribute the results of the ping to a variable called results.
And we can easily access the contents of this variable
by just typing the variable name.
So, let me run this so you can see that we have the exact same output as before.
But now, I have the results in a variable,
and I can start to manipulate the data.
In here, we are mainly interested in the live hosts.
We don't care too much about the hosts that are offline, so we can filter the
results to only show live hosts by adding this pipe and then Where‑Object and
then where the current status equals to success.
And simple like that, when we run this script,
we only get a list of successful pings.
So let me put this into a variable, which I will call live_hosts.
And a quick pause here.
I know I could put everything into one big command line; however,
here I am doing everything in separate lines,
so it's easier for you to understand.
Once you understand the concept,
feel free to optimize this code as much as you want.
So okay, we have the variable live_hosts,
which contains a list of the successful pings.
Now,
we need to interact through this list of live_hosts and
check if there's any open shares.
And the easiest way of doing that is creating a ForEach loop that
reads each target from the live_hosts list.
And then, for each item on the list,
we should execute the net view command for each target.
And remember,
the IP address is containing the field address of the target object.
Perfect, now let's try to run this.
Oh no, take a look.
We've got an error here saying that the network path was not found.
And that's a common issue if you try to use net view with an IP address,
sometimes you might get errors like this one here.
To avoid those errors,
the best thing you can do is translate the IP address into a
hostname and then try to connect to the hostname.
The good news here is that PowerShell has an out‑of‑the‑box
feature that converts IP addresses to hostnames.
This is a function called Resolve‑DnsName.
And all we have to do is provide an IP address to this function.
And when you run this, we get the hostname.
Take a look, we have here the hostname under the NameHost field.
So okay, let's go back to our code and use that there.
Inside of my loop, I'll create a variable called dns_name,
which will receive the result of the command Resolve‑DnsName.
And don't forget, we need to provide here the IP address of my target.
Perfect.
Now on my net view command, I'll replace the IP
address by the dns_name. And that's it.
All we have to do now is cross our fingers and run the script.
Then it works.
Take a look.
We mapped the network shares for the server MSSQL‑01 and we got a few
errors here, but those are because the other IPs didn't have any shares.
To ignore the errors from both DNS resolution and net view, we can just
add the 2>$null in both lines.
And this will redirect any errors to nowhere.
Perfect.
So let's run this again just to make sure it works.
Done, take a look.
We don't have any errors anymore.
We only see the mapped network shares.
Pretty cool, right? And if I want, I can transform this into a standalone
script by adding the param declaration on the beginning of the code. And then,
we should not forget to comment the hardcoded values.
Done. Now, let me save this, and I will call this as smb‑scanner.ps1.
Perfect.
Now we can go to the PowerShell terminal and then run this script with the
flag's IP network, and then IP range. Done, let's run this.
Perfect.
Take a look, it works.
We now have a standalone script that is able to find SMB shares in the network.
So now that we know which servers have open shares,
we can open the Windows Explorer and mentally go through the shareholders.
In theory, you could mentally open each file and try to
find sensitive information; however, if the share has tons of documents,
it will take a lot of time to check each individual
document. But I have good news.
We can use PowerShell to scan this network folder for sensitive
information. In here, we can use the command dir to list all the
documents in the network folder. And in my case, to minimize the noise
I'll filter to only XML documents. Also, I'll add the Recurse flag, so
we can check all the subfolders in this network share. Once we have the
dir command defined,
we can then use this into a PowerShell feature called Select‑String, which
basically parses each individual file looking for a pattern.
All we have to do here is use the flag Pattern to tell what we're looking for.
For example,
we can search for the word PASS. Once we run this,
PowerShell will connect to the network folder and scan
every single file for the word PASS.
And take a look, it seems that I have one XML file
that contains the word PASSWORD.
Let's check it out.
Let's go to this folder, and then open this file here.
Perfect, take a look. We have here a configuration file that has the
user name and password for the database of the server.
Interesting, right? If this was a red team engagement, we
could try to use this password to log into the database or
even log into the domain.
But going back to the script, as you might have noticed, this
script that we created is only scanning for one specific file
type and one specific pattern.
We need to expand this to search for more sensitive files. For that, I'll start
by creating a list of extensions that I'm interested in, like xml, txt, conf,
and so on. And then, I will also create a list of patterns that I'm interested
in, like PASS, USER, SECRET, and so on.
Now we need to interact through those two lists and try every single
combination of extension and patterns. For that, I can simply create two
for loops, one for extensions and one for patterns.
So, let's do this. ForEach extension in the extensions list. And inside of this
for, I'll add another ForEach pattern in the patterns list.
Okay,
so now I have to replace the hardcoded values by the
variables of my for loop. First extensions and then
patterns. Done. And that's about it.
Let me just close both loops, and we are ready to run this.
And remember, in here, we have just a small list of extensions and patterns,
you can add more items to this list as you wish.
So, let's run this.
Perfect, take a look.
We found one new sensitive file here and it seems to have an SSH PrivateKey.
Let's go to the folder and see what we can find. Here, this is the
file, and inside of it, we seem to have an SSH key.
Pretty cool, right?
In just a few minutes, we created two scripts that are able to
find SMB shares and find sensitive data inside of those shares.
If you want, you can even merge both scripts to save your time in
the red team engagement.
Amazing.
We just saw how enumerating SMB shares can be useful for us in a red
team engagement. With our custom script, we found one SMB share, and
inside of the share, we found a configuration file containing the
credentials for the database server.
Pretty cool, right? By using Windows native features and
exploiting really common misconfigurations, we now own a
few machines on the network.
So, before we close this module,
let's have a quick look on what you learned in here. First, we discussed
about the main techniques for network and port enumeration,
including ping scans and TCP connect probes.
Then, we created a ping scan tool that finds live hosts on the network.
After that,
we created a port scanner, which helps us to find open ports on the
network and to find our next target. And last, we saw how to use
PowerShell to enumerate SMB shares. And remember, those shares are a
really good source of sensitive information.
It is really common that we find sensitive files in such shares. Amazing. Now
that we know how to gather information about hosts and servers in the
networks, we're just missing one really important topic,
which is Active Directory reconnaissance.
And the reason I say this is important is because Active Directory can
provide us a lot of useful information about the domain,
like who are the domain administrators,
which service accounts are running, and much more.
I hope you're excited.
I'll see you in the next module.