[Dailydave] Trojan Languages

[Mohammad Hosein]

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 at 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 at 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 at INFILTRATE 2014 in Miami<http://www.infiltratecon.com/>
> !)
>
>
> _______________________________________________
> 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/20131121/9f3bdf9c/attachment.html>