Hunting injected processes by the modules they keep

A relatively recent post showed how Metasploit's Meterpreter module made some noise on endpoints when the migrate command was used to move the agent code into a legitimate process, spoolsv.exe in our example.

One of the things we saw in that post was that when the agent migrates, it uses commonplace injection techniques that result in three dlls being reflectively loaded into the target process. These dlls are not registered with the process and therefore don't show up in the output of something like listdlls, but we were able to find them using gleeda's memtriage in combination with Volatility's malfind plugin. Worth mentioning again, memtriage is really useful because it facilitates some memory analysis without the need for a full memory dump. See the other post for details.

We also noted that these three dlls have dependencies on native Windows dlls and these dozen or so dlls are loaded at the time of agent migration. Depending on how long the target process has been running, these may be "late loaded dlls," which could be a powerful detection. These late loaded dlls are registered in the process, so we can go hunting for them using something like listdlls,  PowerShell's Get-Process cmdlet or a relatively new Kansa module built around the Get-Process cmdlet -- Get-ProcessesUsingModules.ps1.

This new module is one of the few Kansa modules that can take command line arguments, this makes it a bit awkward to use. There's an old post here on what this can look like and we'll dive into the specifics for this new module now.

PS > .\kansa.ps1 -Target $env:computername -ModulePath ".\Modules\Process\Get-ProcessesUsingModules.ps1 wininet.dll,iertutil.dll,winhttp.dll,dhcpcsvc6.dll,dhcpcsvc.dll,webio.dll,psapi.dll,winmm.dll,winmmbase.dll

,ole32.dll,mpr.dll,netapi32.dll" -Credential $cred

Above is an example command-line for running this new collector with a list of dlls. This list of dlls matches what we saw late loaded into our spoolsv.exe process following the migration into that process. Note the double-quotes around the name of the module and its arguments. It's also worth noting that depending on the configuration of the meterpreter agent, there may be different dlls loaded. In our example, I was using a reverse http handler. The example still stands, however. If you're analyzing a piece of malware and can determine what dlls it imports, you may be able to put together a list of modules that you can pass to this collector to see if there are processes that have those dlls loaded. The process may have other dlls loaded too, spoolsv.exe certainly does, but this list of dlls was a result of the agent migration and they are not normally loaded into spoolsv.exe.

Our console output from running this looks like the below, assuming verbose mode:

VERBOSE: Running module:

Get-ProcessesUsingModules

wininet.dll,iertutil.dll,winhttp.dll,dhcpcsvc6.dll,dhcpcsvc.dll,webio.dll,psapi.dll,winmm.dll,winmmbase.dll,ole32.dll,m

pr.dll,netapi32.dll

VERBOSE: Found logging.conf

VERBOSE: Running module on machines 0 to 1 of 1 (0.0 %)

VERBOSE: Waiting for Get-ProcessesUsingModules wininet.dll iertutil.dll winhttp.dll dhcpcsvc6.dll dhcpcsvc.dll

webio.dll psapi.dll winmm.dll winmmbase.dll ole32.dll mpr.dll netapi32.dll to complete.

Id     Name            PSJobTypeName   State         HasMoreData     Location             Command

--     ----            -------------   -----         -----------     --------             -------

7      Job7            RemoteJob       Completed     True            WINS2012R202         <# ...

WARNING: ProcessesUsingModules's output path contains arguments that were passed to it. Those arguments were truncated f

rom wininet.dlliertutil.dllwinhttp.dlldhcpcsvc6.dlldhcpcsvc.dllwebio.dllpsapi.dllwinmm.dllwinmmbase.dllole32.dllmpr.dlln

etapi32.dll to wininet.dlliertutil.dllwinhttp.dlldhcpcsvc6.dlldhcpcsvc.dllwebio.dllpsap to accommodate Window's MAXPATH

limitations of 260 characters.

VERBOSE: ### All Done ###

Note the MAXPATH issue. The way Kansa works, the directory names for the collector output include command line arguments and in this case, those arguments exceed the default limits on my Windows system, so Kansa makes some adjustments and truncates them.

What does the collector output look like, below is a snapshot of the output folder for this collector, note the long folder name.

Inside that folder there's a file, one for each targeted system, in our case there's only one. We ran with the default output type so we have a CSV file and it's contents are as follows:

"ProcessId","ProcessName","PSComputerName"

"1084","spoolsv","WINS2012R202"

This means on our targeted endpoint, we had a single process that had this set of dlls loaded, our injected spoolsv.exe process.

Happy hunting!