Home page logo
/

dailydave logo Dailydave mailing list archives

Re: Trojan Languages
From: Dave Aitel <dave () immunityinc com>
Date: Fri, 29 Nov 2013 14:19:17 -0500

To be fair we currently use Python 2, but we want to switch to Python 3
for the better Unicode support.

It's true that AV companies can trigger on "Python somewhere it isn't
normally". . . but Python is fairly common in enterprise environments.

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.

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.

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.

-dave

On 11/21/2013 5:25 PM, Mohammad Hosein wrote:
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
- 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 ?
- 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 ?

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 :> )

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" ?

-mh



On Thu, Nov 21, 2013 at 1:53 PM, Dave Aitel <dave () immunityinc com
<mailto:dave () immunityinc com>> wrote:

    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! :>

    -dave
    (P.S. You can mess with INNUENDO atINFILTRATE 2014 in Miami
    <http://www.infiltratecon.com/>!)


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



Attachment: signature.asc
Description: OpenPGP digital signature

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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault