I want to show the, pivot listener,
separately because
you manage them in a different way to normal listeners.
So you can't set up a
a pivot listener here.
There's no,
option for it.
So the only way to do this is by right clicking on a beacon,
pivoting and listener.
And this is simply because the pivot listener,
or pivot listeners, are tied to particular beacon sessions.
So you can't create a pivot listener without a beacon.
So when given a pivot listener a name, you probably want to do
something like use some information from the beacon session itself.
I'll just
call it, demo pivot.
And the pivot listener only uses the,
TCP beacon.
And the, the listen host and port,
the listen host is taken from this,
beacon session that we selected.
So ten ten five forty is the IP address of this,
attacking, this machine.
And the port can be whatever we want.
Four four four four is the default,
but we could say one two three one two three four if we wanted.
This host and port is what's baked into the payload that's
generated from this listener.
So in most cases, you would want to
keep the host as it is.
And once we click save,
you'll actually see that,
it sends this,
reverse port forward command.
But if you actually try to type this into the console yourself,
it, it it wouldn't work.
So you can't actually use this to,
start a pivot listener.
Pivot listeners also bind on all interfaces,
so zero zero zero zero,
which is why we then see see a firewall prompt.
For now, just click allow access.
We'll see something else later in the course of how to deal
with that ahead of time.
And now if we look at netstat, not four four four four, one two three
four.
We can see that it's now this beacon that is listening on one two three four.
So in the previous example, it was
the child beacon itself that would
listen, and we would connect to it from another beacon.
And the pivot listener is the other way around.
So an existing beacon is what is gonna bind and listen,
and then the payload that we generate will connect,
to an existing beacon.
So to, generate a payload for that listener, we could go to,
payloads and Windows Stages payload.
And then we can select the, pivot from that,
payload list.
The listener does actually also appear in listeners as well,
even though you can't create it, here,
this is where it appears.
And the listener is now available in
commands that accepts,
listeners.
So example, the spawn command,
we could say spawn demo pivot.
I'm just gonna generate the, payload for it.
And I'll put this into
payloads as well, and I will call it pivot.
And this time when I run
it,
you will see that this time the beacon appears immediately in the UI.
So this is another difference between the normal TCP payload
and the, pivot payload.
In the graph view,
we can see that the arrow is now going the other way like I,
mentioned in the previous video.
So this is the beacon that's listening,
and this is the beacon that's, connecting to it.
Now if we, close both of these beacons,
And go back to the listeners menu.
We might have to, close and reopen. Yeah.
So if I close and reopen it,
you can now see that there's a big old error here.
So because pivot listeners are tied
to b concessions, once that b concession is gone,
Cobalt Strike will,
validate that this,
listener is no longer possible to use because the associated
session with it, has now gone.
To remove it, we can just hit, remove.
And, like this command, when you
remove a listener, or a pivot listener,
though the console prints out this r port forward stop command.
But actually, in my experiences is if you just
if you typed this command into the console without actually
hitting remove on the inside the listener's menu,
that it actually doesn't stop the listener.
So for the most part,
I would say just ignore these commands in the context of the
pivot listeners and just manage them through the UI.