mailing list archives
From: Dave Aitel <dave () immunityinc com>
Date: Thu, 21 Nov 2013 14:53:04 -0500
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.
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.
But you're getting one, *very* important thing when you use Python:
1. Your most complex code will be a lot less buggy.
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.
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! :>
(P.S. You can mess with INNUENDO atINFILTRATE 2014 in Miami
Description: OpenPGP digital signature
Dailydave mailing list
Dailydave () lists immunityinc com