Now let's talk about the handler.
It is going to be running on the attacker's machine.
Its job is to listen for incoming connections from the stager.
When a connection occurs, it will send back the payload,
which is then bootstrapped by the stager using the ret instruction we just saw.
Once the payload has been initialized,
the handler is used to interact with the Meterpreter shell.
We can configure the handler manually or by using a .rc file
containing all the options we want to set.
We can specify the IP address and port,
which we want our payload to connect back to,
as was the type of payload we want to send to the stager.
This command will start the handler,
which will be listening on the IP address and port we specified in the .rc file.
There are additional options we can set,
which we will be looking at later on in the course.
When a connection is received by the handler,
it reads the payload, also known as metsrv,
from disk.
metsrv is a DLL containing the actual Meterpreter code. Before sending
the payload back to the stager, the handler will patch a small stub of
shell code into the payload's DOS header.
We can find the code responsible for this in the meterpreter_loader_x64.rb file.
Let's take a look at the code. In the asm_invoke_metsrv method, we
will find the shell code stub written in assembly.
When this code is executed by the stager,
it needs to figure out where it is in memory in order to calculate offsets.
It does this by using a call instruction, which automatically pushes the
address of the next instruction on the stack.
It then pops the address off the stack into the rbx register.
The offset to the ReflectiveLoader function is calculated by the
handler and patched into the assembly code, similar to how the
ROT13 hashes were patched into the assembly code by msfvenom
when generating the stager.
Once the ReflectiveLoader function call returns, the
stub of shell code calls DllMain, which kicks off the initialization.