Everybody welcome to next video so we're really going over banner grabbing in this video it's going
to be pretty short but nice and sweet.
So what I want you guys to understand about banner grabbing is it's a common technique used by for example
and map when we used and map to scan a host when it provide when we use the dash a it's actually going
and making a socket connection to the hop to the port on that host and then waiting for some sort of
data response back that doesn't get one right away it goes ahead and send some data and see if it gets
a response and then it tries to base the service off of that response which is normally called the banner.
So arms are a banner is normally when you try to connect when you connect to a port and it provides
you some sort of prompt.
So when we try to assess H to a machine you will get a prompt presenting you for saying oh this machine
is private it is set up by and or by whoever or it might give you a date but that's still a banner or
it might give you the version.
However there are some cases where if we look here if we try to connect with net Cat 2 2 1 6 8 to a
thousand we get nothing.
And if we enter it just go it just go ahead and closes the socket.
However if we put some random stuff in there we get a response and it's saying this is a bad message
unsupported but we can tell by the output that it's HDMI which tells us that this is a web page.
We can confirm this by sending it a web request
and we can see we get two listings we get let's say a link to admin knowing to log in both different
directories so this might not be as easy as what you're seeing here.
There might be some ports that when you send some useful statement doesn't do anything.
If that's the case you might want to send.
You might want to hit enter just a few more times or you may want to send a larger string of data such
as you know a good chunk whatever or whatever you might want to do.
Right.
So there's other options that you could do as well.
You can send in things like help info log in all.
So stuff like that are common things that you might find on a service.
So it's always good to try a few of these options out and sometimes a mix.
So you might do off and render as an example.
So it's good to double check and what I want you to know is you don't have to spend forever on this.
If you've looked it's a weird port number you connect to it you can send data to it and it never gives
you a response no matter what you provide it whether you gave it a thousand characters or gave it some
help info log on some other different stuff you might have researched online you try to send in a web
request it doesn't work either.
But by that time your best bet is to just move on to a different port and then come back to it when
you have more time during an engagement with a client or the local company that you might be working
for.
It's always important to note that you have a timeframe to keep to.
Now there's more specifically true with contractors.
So contractors that do penetration testing for companies you have a very strict timeline and there's
no going back and checking it later once the assignment or engagement ends.
But when you're in an internal red team you can go back and refine re finalized those things with certain
approvals and just double check everything and go back to it maybe even take an extra step and go ahead
and log into the box and find out what was actually running on that machine after the engagement so
you can get a better idea of what service it might actually was because there's there's an there's an
interesting standpoint of the red team it's not just attacking a machine or seeing what's a taxable
what's exploitable.
How do you gain access.
But it's also if you notice something weird.
So for example if you're running into a log in prompt.
Right.
It's a you know a basic log and prompt it's behind some sort of service and it's protecting an admin
page.
Maybe you're checking this particular service in the development environment.
It might be good to double check.
Go on log on to the machine after the assessment and find out where it's keeping its passwords and then
make sure that it's not storing the same passwords and prod or endeavors as it isn't broad.
That right there is a finding on its own.
You can't be sharing credentials between Debian pride or Corp and prod or you don't want to be sharing
anything.
So there's times where logging or the boss in double checking after an engagement is complete is extremely
important as well.
It's it's your job as a red team or as a red team or maybe not as a consultant in this particular case.
But I'm speaking to the people that's aiming for a red team position specifically when when you're a
red team or it's more than just attacking you have to be vigilant when you see something stupid or something
weird or something that shouldn't be there.
You need to take that extra step and just double check to make sure you're seeing what you're what you
think you're saying or you have a hunch that something's being configured a certain way.
Go ahead and double check it.
In most cases this isn't a problem for you to log into a box and check out a configuration file unless
there's some sort of detection mechanisms on it which you might want to alert the search team or the
blue team to let you know that or to let them know that you're going to be testing out and looking at
this config file outside of that.
It doesn't hurt to check it in product depth.
You never know when something's going to be duplicated or maybe they're using chef animal or puppet
for configuration management and they go ahead and use that that same files provision and Dev as it
is.
Prod and that becomes now an issue.
So it's always good to just double check but when working with banners don't spend a thousand hours
on a single port because you can never know what's on the other end of that.
It might be looking for a tell us connection and you would have never known that.
So just take a second.
Play around with banners get familiar with writing that banner that that are the requests that I sent
the web request by default.
This right here block of that into your brain somewhere you're going to want that.
That is a quick way to determine if it's a web app.
And sometimes web apps might not respond saying I don't recognize this.
This is an unrecognized bad request as an example.
It might not give you a bad request but it still might be a web app.
It never hurts to double check.
Try a few things.
Remember when you used a web request to enter enter so a carriage return line feed twice so or just
enter on the keyboard twice for it to actually send the request.
Don't hit it once and expect a response.
You'll never get one.
Hit it twice.
So play around with this.
Work with grabbing banners of services whether it's on your route or local machine.
You can make a web request to any Web site you want.
Don't poke around on different ports.
Just port 80 just stick to that for now.
And some Web sites might even not have might not even have 80 up or they might you might get a 3 0 to
redirect.
But anyway I play around with it.
Get familiar with the process of manually checking a port because this is going to come into play later.