[Dailydave] INNUENDO OPSEC THOUGHTS - Windows is Pythonic

[Dave Aitel]

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 list
> Dailydave at lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20140131/db01e196/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RobFuller.PNG
Type: image/png
Size: 95912 bytes
Desc: not available
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20140131/db01e196/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: OpenPGP digital signature
URL: <https://lists.immunityinc.com/pipermail/dailydave/attachments/20140131/db01e196/attachment-0001.sig>