Removing infection modifying Metasploit post modules

The main objective is to remove the persistence of an attack creating a new process. We could do it executing directly a bash command concatenating all in just one line, in order to execute it before it kills itself. But on some cases it will be easier and cleaner (and cause we can 🙂 ) .

  1. 1- How to inject .dll in a process
  2. 2- Modify the module to fit our needs.

We will use the post/windows/manage/reflective_dll_inject module to inject .dll in a process, and as a base of our future modifications.

Here you have the github of the project with all the explanation of the method and a small documentation.

Steps I followed:

  • Clone the project
  • Open the rdi.sln project on Visual Studio
  • You will need C++ dependencies + others. (probably you will need the SDK 8.1)
  • You have to define the route to the dependencies. (Proprieties –> VC++ Directories )

  • Add your code to the ReflectiveDll.c

You have the inject.exe to test it locally, as it triggers the .dll file.

Should be noted that we must inject .dll libraries only to the same architecture process (x86/x64/ARM).

For now, once we build the .dll, we are ready to execute it from Metasploit. We only have to assign the PATH to the .dll file, and the PID of the process to be injected to run the .dll code.

All fine until here, but for our purpose where we have multiple connections and we want to run it in all sessions at once. So we need to modify the module and change the way they reference the process with the PID for the Process Name.

To add new modules the best way is:

cp /opt/metasploit-framework/modules/post/windows/manage/reflective_dll_inject.rb ~/msf4/modules/post/windows/manage/reflective_dll_inject2.rb


As you can see, we will only change the INT option for a PROCESS string, and later client.sys.process function get the PID of the process name. We also hardcoded the option parameters, as we pretend to execute them together.

If we need to change any of this options, we can always define a global parameter before the execution.

Now we use the reload_all to reload all the new or modified modules.

To execute it in all the Metasploit sessions:

sessions -C “run post/windows/manage/reflective_dll_inject2”

Manage metasploit listeners with Tmux

In order to have listeners always ready on the C&C and have access easily through SSH we will use Tmux.
Tmux is a powerful alternative to the Screen command, included in multiple Linux distributions like Kali.

– Detachable from the console.
– Always up.
– Logging all the connection.

Create a script called

As you can see here we create a new detached session, then we check if there is another active session, if there is no we create another loggin file.

Finally execute this script to add the script to the Cron job scheduler

If for any reason it dies, the Cron job will trigger another one automatically and another logging file.

Just with we don’t need to worry about it, as it will always be a listener active.


Listing all the Tmux sessions:

Attaching to a session (“windows” is how we named the session before):

Detach from the session:

Adding new skills to the Metasploit Firefox addon

I have been modifying the firefox_xpi_bootstrapped_addon exploit of Metasploit to add some new skills that were necessary to make it more real (for SE) and successful.

From the beginning:
Firefox uses .xpi extensions, in this case uses the restless method, which is able to install the addon and execute it without rebooting the browser.
Here you have more info about the Mozilla Bootstrap addons.

Signatures not required

The bad news:
The last versions of Firefox have the xpinstall.signatures.required flag enabled, and we have to disable it if we want to execute unsigned ones. So by default it’s only possible to execute addons signed by Mozilla (previous review).

The worst news:
In future versions of Firefox it will not be possible to disable the signatures, and only Mozilla signed addons could be executed.

The good news:
Special versions of Firefox ESR will still have the xpinstall flag in the about:config.
Many companies disable it to execute their own plugins. (In this case Mozilla offers the possibility to sign it and store it in a local repository, not the public market)

Here you have more info about the signatures and versions.

This is the MSF exploit that we are going to use:

Once executed it creates a webserver with the plugin

Downloading and unziping the addon

Now the funny part, what we want to do?
– We want to know when the user executes the addon.
– We want to get all his cookies (all the cookies of the browser, doesn’t matter if they have httponly).

– Because in a phishing attack, it will be very suspicious to execute a plugin that doesn’t do anything. Once the user installs it, we set a cookie that the Javascript code in the client side will read and make some action.
– Because it’s very powerful getting all the cookies in that easy way, and at least we could still have them in the worst case that the RCE exploit fails for any reason.

We are not going to explain all the Metasploit payload, just the code we added.


– In firs place we enumerate all the cookies of the selected domain, and we send them via GET to our external server. It could be also possible to concatenate all of them and send it via POST. (In this case all the user cookies are sent by HTTP so it’s not recommendable at all to use unsecure protocols)
– We create a cookie to be checked by the JavaScript code on client side.
– We also send a request to the server to know that this user executed the plugin.

With this little tricks it’s easy to evade AV as it’s executed on Firefox directly and the stage is encrypted with RC4, it’s easy to fool the users as you can make post execution actions, and easy to get all the cookies as a bonus.

The code works well, but we have not tested it very hard, so we are not responsible for any misuse.