Home page logo

dailydave logo Dailydave mailing list archives

Re: INNUENDO OPSEC THOUGHTS - Windows is Pythonic
From: Andre Gironda <andreg () gmail com>
Date: Sat, 1 Feb 2014 00:21:07 +0300

Rob might be talking about "Living Off the Land: A Minimalist's Guide to
Windows Post-Exploitation" from Christopher Campbell & Matthew Graeber

The idea that you can leverage pinvoke in memory, etc

On Fri, Jan 31, 2014 at 11:06 PM, Dave Aitel <dave () immunityinc com> wrote:

 [image: RobFuller Disagrees]

Rob Fuller says "have strong feelings against your latest post on DD -
there are a ton of ways if you stop thinking of a trojan as a process".

So I like where he's going with this, and I think there's a subtle
difference between an Implant and a backdoor (and I'm not sure where
"Trojan" fits here as he used it). Implants in general tend to have fairly
full featured capability sets (which in the leaked NSA documents are even
standardized). For example, while I can put a backdoor almost anywhere
(say, Outlook.exe), in general you can't offer people Implants that don't
do such amazing things as screengrabs, staged file transfer, camera feed
views, local privesc, WMI access, and covert file storage. The feature list
is fairly large for any base Implant.

INNUENDO, like most implants, runs as a user-mode thread hiding in some
random process (be it LocalSystem or not).  What's the other option that
makes sense?


On 1/30/2014 12:13 PM, Dave Aitel wrote:

So the Python way is that there is really only one correct way to do it
(and that way is easy to read and understand but medium slow and quite
verbose). This is in stark opposition to  the Orcish lineage of horrible
evil that derives from Perl where there are a million ways to do it,
each worthy of an obfuscated code challenge and requiring a PhD in
complexity theory to understand. This is an emergent property that comes
from some of the base design decisions, but which has no real "name" or
math behind it.

Windows implants are Pythonic in this way. When writing implants for
Windows, there is really only one "correct" way to do things, which in
some ways is quite nice but of course scares me a bit as well from an
OPSEC perspective. The interplay of tokens, threading models, APIs, and
kernel objects restricts the way you program for Windows into just a few
channels. You can illustrate this with a simple question: How does your
implant capture screens?

To capture a screen in Windows can be done in many ways, but when you
write trojans for the corporate world you will have to deal with Citrix
(which is used extensively). So if you have chosen say, DirectX, to
capture screens, you may be going the wrong direction. In fact, there
are many screens running on their own "Desktops", and running as local
system you cannot access them easily (as far as *I* know).

So you want to at some point be running in the user context of all the
different users to capture all their screens - and you can start up
processes as them from LSASS to do so if you choose, but you can't do it
directly from a SYSTEM owned process with thread impersonation (which is
what you'd really want). At some point all the APIs become gibbledygook
and you realize to do this simple job right you'll have to inject into
other processes running as those users, one way or the other.

But what exactly do you inject into them and how does this thingy
communicate back to you?

These questions continue, and there really is only one correct answer to
each one, forcing almost all trojans in this space to act very similarly
(or just bail out into kernel-space, which has its own issues). This
bizzare Pythonic emergent property is an interesting thing, since in
Unix, which is in some ways a more simple design, you will feel like
there are a lot more ways to write a trojan "correctly".


Dailydave mailing listDailydave () lists immunityinc comhttps://lists.immunityinc.com/mailman/listinfo/dailydave

Dailydave mailing list
Dailydave () lists immunityinc com

Dailydave mailing list
Dailydave () lists immunityinc com

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]