The staging function in the post/windows/powershell class was broken
in a previous commit as the definition for env_variable was removed and
env_prefix alone is now used. This caused an error to be thrown when
attempting to stage the payload. This changes the reference from
env_variable to env_prefix.
Additionally, the ps_wmi_exec module created a powershell script to be
run that was intended to be used with the EncodedCommand command line
option; however the script itself was never actually encoded. This
change passes the compressed script to the encode_script function to
resolve that issue.
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.
Brent Cook