So let's go back into our environment,
and we'll check for open ports and devices.
What we'll do first is create what's called an echo server using PowerShell.
Effectively, this means we open a port using PowerShell,
and then we can test that port or any number of ports.
It just means we don't have to install software that
is actively using those ports.
We can kind of pseudo create this.
Then we'll use the .NET API to check for open ports.
We'll then use Nmap in PowerShell to check for an open port.
And then we'll look at using a third‑party module,
which will use PowerSploit to check for an open port.
So the first thing we have to do here is to create a listener.
So this is going to be what's called the echo server,
which effectively you create a port, you tell it to open it,
it doesn't really exist necessarily because we've told it to open,
and then it just returns a response back in the screen that we're in.
Now to create this initial listener.
We can do this by creating a listener variable,
and we're going to utilize the .NET API.
So we can use new object, or we could just put it in square brackets.
But either way, we're going to be using System.Net.Sockets.TcpListener.
And then we have a variable called or a property called ArgumentList here,
and we can say what the port is going to actually be.
Now, we could use anything.
But of course, remember,
the communication between the two devices that you're testing,
you'll probably need to make sure the firewall on the
machine allows that specific port to be open.
So I'm going to use something on the high end here, so let's say 16,000, and I'm
going to press Enter. Now, when I go into the listener to check, you can see
it's now been bound to the IP address. Now, of course, if I try to initiate a
connection to that, it's probably going to fail because 16,000 probably not a
port that you would normally open.
So while we're here on the server, we can say Windows Defender
Firewall. I can go into Inbound Rules, and I already created one, but
I wanted to show you here that I have a rule,
a port rule, and basically, it's allowing every single port to come in in
my test environment. Now you may not have to do that because it might be
a standard port like port 80 or port 443.
So I have that running. Now, the difficulty is here
that when we make the connection,
nothing really gets returned. Or when a connection is created,
so if I say Listener.Pending and do this,
it comes back and says,
well hold on a minute. You can't check the status of it because it's not
actually running. So we have to come first here and say Start.
So I'm going to start the listener. Then I can check the pending phase.
But the pending phase isn't anything to do with the service starting.
Pending is was there a pending connection made to the specific port?
Which in this instance, there isn't because we haven't actually tried
connecting to that port. So now that we have that, we need to adjust a
couple of settings here.
The first thing we want to do is allow the connection to be made.
So I'm going to create a new variable on here, and I'm going to
use the listener, and there's a option here called Accept, if
we just loop through, TcpClient.
So what that means is that when the connection is made,
my listener is going to say oh, I accept you, instead of
just allowing it connect and do nothing.
So I'm going to say client listener AcceptTcpClient.
So now we have this ability for it to say accept
the connection that's coming in.
And then from here, we can specify other properties to kind of go
in and say I want this message to be written back to me, etc. So,
let's go over to the Windows machine.
Now that I have this running that says
client=listener.AcceptTcpClient, it's not going to return
anything because no one's made a connection.
So let's flick to the Windows 10 machine and create that connection.
So this is our Windows 10 machine.
And so what we're going to do this time is we're going to create that
connection, so connect to it. And we do that by simply creating what is
going to be a variable for the endpoint.
So I'm going to call it client, and I'm going to say instead of a TcpListener,
I want to create a TcpClient. And then, for my client properties, I
can go in and say connect to a specific IP or port. I'm going to set
my IP address. Now I can go back and say connect to that specific
IP. So, now I've connected. Let's see what happened back on the
Windows Server itself.
So let's change to that.
So what happened is my client or my accepting TCP client
stopped. It received a connection.
So if I now loop back and say listener is pending,
it will say well no, no there's no listener pending,
because now I have a specific connection.
So now we need to get information about the client that's connecting.
So let me create a variable called connection, and I'll
populate that with the value from client.
And what I can then do is I want to retrieve the data
stream that's coming from that client.
So let's create a variable called stream, and I can say stream, and I'm going
to say client.GetStream. So that will return any value.
So let's look what stream looks like.
So right now, you can see that there's a connection that was
created, and we're allowed to read, and we're allowed to write, and
there's a timeout. So we're starting to grab values. I'm going to
clear that so we have more space.
What I can then do is say write a message, so Write‑Verbose. And from here, I
can tell it to write a specific message into the console here.
So from here, I'm going to say New Connection, let me just change that to
quotes, New Connection from, and then, of course, we'll just use standard
PowerShell here to just write a message out using the properties that are
part of the client object itself.
Now you'll notice when we do client.Client, we then have access to things
like remote endpoint, the address, . I can then say same thing again,
client.Client.Remote, and I want to use the port this time. And then, maybe I
just want to write that out as Verbose. And you'll see the message gets
returned with those values saying a connection was made from a different IP
address using a different port, which was the remote connection that came
out, but it was retrieved and accepted on the port that was targeted when it
came across.
Now, of course, you may see that the remote endpoint port is different, and
that's because it's an outgoing port that's making a connection coming in. So
our echo server allows us to initiate that connection.
So at any point, we can just rerun this as we need to. So
that's how we create an echo server or piece of PowerShell that
will return specific values for us.