cygrunsrv.exe_180210_134420.dmp
[
*
]
Downloaded 4.00 MiB of 4.00 MiB
(
100.0%
)
: cygrunsrv.exe_180210_134420.dmp ->
cygrunsrv.exe_180210_134420.dmp
[
*
]
download : cygrunsrv.exe_180210_134420.dmp -> cygrunsrv.exe_180210_134420.dmp
The process selected had a token handle listed. We can use
either the process name or
the PID to tell
procdump64.exe
which process we want to dump. If you have processes
with the same name,
as was the case with
postgres.exe
because it spawned numerous
child processes to manage the work, you will have to use the PID.
This makes it clear
to
procdump64.exe
which process you mean to extract from memory. We end up with
a
.dmp
file left on the disk of the remote system. If we want to analyze it, we’ll want to
bring it back to our local system to work on it. We can do that using
download
in
Meterpreter. Before we can do that, we need to drop out
of the shell on the remote
system so we just
exit
out. This doesn’t lose the connection to the remote system,
since we still have our Meterpreter session running. We
just spawned a shell out of
our Meterpreter session and needed to drop back to Meterpreter.
Once we are on the remote system, there are a number of things we can do with pro‐
cesses. This could be done using Meterpreter, one of the
other modules that could be
loaded, or any number of programs we could upload to the remote system. One thing
to keep in mind is that you may want to clean up after yourself after you’re done so
any artifacts you created aren’t available for detection later.
