Re: INNUENDO OPSEC THOUGHTS - Windows is Pythonic

[Andre Gironda <andreg () gmail com>]

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?
>
> -dave
>
>
>
> 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".
>
> -dave
>
>
>
>
>
>
> _______________________________________________
> Dailydave mailing listDailydave@lists.immunityinc.comhttps://lists.immunityinc.com/mailman/listinfo/dailydave
>
>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunityinc com
> https://lists.immunityinc.com/mailman/listinfo/dailydave

_______________________________________________
Dailydave mailing list
Dailydave () lists immunityinc com
https://lists.immunityinc.com/mailman/listinfo/dailydave