<div dir="ltr">Rob might be talking about &quot;Living Off the Land: A Minimalist&rsquo;s Guide to Windows Post-Exploitation&quot; from&nbsp;Christopher Campbell &amp; Matthew Graeber<div><br></div><div class="gmail_extra">The idea that you can leverage pinvoke in memory, etc<br>
<br><div class="gmail_quote">On Fri, Jan 31, 2014 at 11:06 PM, Dave Aitel <span dir="ltr">&lt;<a href="mailto:dave@immunityinc.com" target="_blank">dave@immunityinc.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <div><img alt="RobFuller Disagrees" src="cid:part1.00020508.09030009@immunityinc.com" width="1161" height="252"><br>
      <br>
      Rob Fuller says &quot;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&quot;. <br>
      <br>
      So I like where he&#39;s going with this, and I think there&#39;s a subtle
      difference between an Implant and a backdoor (and I&#39;m not sure
      where &quot;Trojan&quot; 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&#39;t offer people Implants that don&#39;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.<br>
      <br>
      INNUENDO, like most implants, runs as a user-mode thread hiding in
      some random process (be it LocalSystem or not).&nbsp; What&#39;s the other
      option that makes sense?<br>
      <br>
      -dave<div><div class="h5"><br>
      <br>
      <br>
      On 1/30/2014 12:13 PM, Dave Aitel wrote:<br>
    </div></div></div>
    <blockquote type="cite"><div><div class="h5">
      <pre>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 &quot;name&quot; or
math behind it.

Windows implants are Pythonic in this way. When writing implants for
Windows, there is really only one &quot;correct&quot; 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 &quot;Desktops&quot;, 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&#39;t do it
directly from a SYSTEM owned process with thread impersonation (which is
what you&#39;d really want). At some point all the APIs become gibbledygook
and you realize to do this simple job right you&#39;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 &quot;correctly&quot;.

-dave



</pre>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>_______________________________________________
Dailydave mailing list
<a href="mailto:Dailydave@lists.immunityinc.com" target="_blank">Dailydave@lists.immunityinc.com</a>
<a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" target="_blank">https://lists.immunityinc.com/mailman/listinfo/dailydave</a>
</pre>
    </blockquote>
    <br>
  </div>

<br>_______________________________________________<br>
Dailydave mailing list<br>
<a href="mailto:Dailydave@lists.immunityinc.com">Dailydave@lists.immunityinc.com</a><br>
<a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" target="_blank">https://lists.immunityinc.com/mailman/listinfo/dailydave</a><br>
<br></blockquote></div><br></div></div>