<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">To be fair we currently use Python 2,
but we want to switch to Python 3 for the better Unicode support.
<br>
<br>
It's true that AV companies can trigger on "Python somewhere it
isn't normally". . . but Python is fairly common in enterprise
environments. <br>
<br>
Trojans, like steganography are essentially about the game of
knowing more accurately where entropy is in a system than your
opponent. This is why the kernel is often a bad place to place
functionality - the entropy of your basic system call is low.<br>
<br>
For sure, the risk of all technology is that someone will steal it
and use it against you, but this is more for testing than for
actual hacking in the sense that FLAME's C&C design is already
out of the bag, but modern tools model that threat very poorly. So
INNUENDO will be sold to customers who want to model that threat
properly. <br>
<br>
It sounds somewhat silly, but I don't believe you can really write
trojans for Windows without fully using COM. With INNUENDO you get
the COM Python bindings so throwing events on new processes with
WMI is 3 lines away instead of 100 lines of insanely hard to read
C++. I don't know how to explain why this makes such a big
difference, except that we're releasing a new version of El Jefe
soon, and when things like Meterpreter do registry backups they
use Reg.exe to do it, which gets caught instantly by El Jefe and
flagged as hacker activity. It really doesn't matter WHAT process
you hide in if your trojan does dumb stuff like that all the time.<br>
<br>
-dave<br>
<br>
On 11/21/2013 5:25 PM, Mohammad Hosein wrote:<br>
</div>
<blockquote
cite="mid:CAM4cd6ApbZnXd8AtyLMX_Egd=wH0OE_iSPGWOu+r=AwtSv9RLQ@mail.gmail.com"
type="cite">
<meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>are you using the civilian off the shelf Python ?
if i was into typical enterprise pentest or offense
biz two questions would be raised immediately<br>
</div>
- so the AV people need a tiny addition to their engines
to particularly act out when something smells like
python particularly when the calls are going down like
..the same route , well , since its always the standard
python ?<br>
</div>
- isnt this a risk if our adversary finds out a node is
active on her system and grab the thing and use the
"forward-thinking technology" against us or their own
favor whatever that is ?<br>
<br>
</div>
obviously i am asking such "selling-session" standard
questions like most .org/.gov typical customers to hear your
technical counter argument ( presuming i am going to learn
something , not get iced by a move like mad men's don draper
in the scene where he talks about the candy in the brothel
and what it meant to him -- a ceremony :> )<br>
<br>
</div>
meanwhile i am going to put this out for folks@dd to hear back
: LLVM is one the wonders of the world . although Duqu
developers preferred to develop code based on their own
framework ground up and flame used the typical lua embed ,
developing a middleware-style LLVM-based transformer to
produce native code from some .py or .rb for almost any
platform - x86 ..to ..say.. TI's rarely used DSPs - is easy
work -- why using this technique isn't popular in "our circle"
?<br>
<br>
</div>
-mh<br>
<br>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Nov 21, 2013 at 1:53 PM, Dave
Aitel <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dave@immunityinc.com" target="_blank">dave@immunityinc.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote">
<div> So as much as Chris tries to drive all of the
complexity for INNUENDO to the server, I find there's a
sort of feature-gravity that makes you want to put it onto
the client. Even the simplest of modules has a big enough
state table and complexity that I'm tempted to call it a
"Behavior" and not a module at all. INNUENDO's client is
of course running Python, and I wanted to explore WHY for
a second.<br>
<br>
Obviously one reason is that Immunity has a ton of Python
experience. But in trojans, Python is hardly most people's
first pick for a language. You're hauling 40Mb of code and
data with you when you want to run somewhere. This isn't
ideal for a lot of scenarios. <br>
<br>
But you're getting one, *very* important thing when you
use Python:<br>
<br>
1. Your most complex code will be a lot less buggy. <br>
<br>
For advanced remote access trojans, you are operating in a
completely unknown environment and frankly, you may NEVER
be able to update it or reach it again. Any detection or
failure could be globally catastrophic. This means your
code has to be forward thinking in a way that is not
typical. So it simply has to be much more correct than
code usually is. People tend to write complex things more
CORRECTLY in Python than in Ruby or Lua or (Naudhubillah!)
C. That reason alone is why the future of remote access
trojans is embedded Python engines. If you're trying to
build trojans that have emergent behavior, then you need a
language that makes that behavior as clear and easy to
understand as possible. <br>
<br>
I mean, deep down, I refuse to give any ground whatsoever
to the new industry of incident response people who just
realized how useful instrumentation and anomaly detection
is. It's time to tool up for the challenges ahead! :><br>
<br>
-dave<br>
(P.S. You can mess with INNUENDO at<a
moz-do-not-send="true"
href="http://www.infiltratecon.com/" target="_blank">
INFILTRATE 2014 in Miami</a>!)<br>
<br>
</div>
<br>
_______________________________________________<br>
Dailydave mailing list<br>
<a moz-do-not-send="true"
href="mailto:Dailydave@lists.immunityinc.com">Dailydave@lists.immunityinc.com</a><br>
<a moz-do-not-send="true"
href="https://lists.immunityinc.com/mailman/listinfo/dailydave"
target="_blank">https://lists.immunityinc.com/mailman/listinfo/dailydave</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>