[Dailydave] Ants in your pants

[Kyle Creyts]

I think commodity malware have come much further than legitimate tools in
some regards, and are much further behind in others.

Notably, almost all commodity criminal implants have an specificity of
mission not commonly found in the group of attack frameworks you highlight.

The typical level of specificity is "I want to make money off this implant"
and one typical outcome of this ambiguity is having N ways to make money:
through credential theft, CC scraping, clickfraud, participation in DDoS,
etc.

Very rarely will these objectives require the implant to make decisions
about how to attempt to accomplish the objective, and almost never any sort
of "privileged" peer interaction.

Some focus has been given to improving the robustness and survivability of
the infrastructure and control channel, mostly in distribution of
command/config, and shipping "home" the money-making data.

Notably, these are areas where attack frameworks like those you listed have
made some progress. Not as much progress as some malware out there,
perhaps, but still progress; every category has stand-outs.

I think that one reason so much focus is given to the "lesser" algorithms
in designing capabilities and control protocols for remote agents is
ambiguity and flexibility of application. Ambiguity and flexibility of
application cause some people to think about simplifications to
interactivity; the first intuitive  solution appears to be building a tool
that provides some abstractions for local resources and runs whatever code
the control channel pushes it, and the easier you can make it to deliver
instructions to interact with or loot resources of the implanted hosts, the
better.

And so, most implants are designed with two control flows: a
preconceived/scripted mission, and a capability to loop, wait for
interactivity with a control channel, and process updates or extensions to
that mission or script. The notion of peering is just beginning to take
shape as distributed implant puppeteering improves, and having many
co-operating implants is becoming more commonplace.

But I think most of our tools are still pretty bad at describing different
kinds of mission in a decomposable way, where individual nodes can
understand their role in the mission and interact directly with peers to
execute complex missions.

We're getting better, certainly. Tools like Bloodhound that leverage
frameworks like Empire are a good example of encoding and communicating and
executing a mission... still very wheel-and-spoke, though. They could use
more hive-mind.

I'm not sure we have yet developed the semantics to have Siri help us here.
 "hey siri, tell implants at the target to work amongst themselves to exfil
the Crown Jewels that customer has requested" for arbitrary Crown Jewels.

It sounds quite challenging to encode.

The difficulty of sufficiently describing said jewels, writing code to
enumerate all possible paths to them, the resource complexity of reaching
them in execution... each seems very significant.

Doing it quietly, so that defenders never notice seems even harder.

Maybe I'm just out of the loop. It sounds like you're doing pretty cool
work over there.


On Wed, Nov 29, 2017 at 10:07 AM Dave Aitel <dave.aitel at gmail.com> wrote:

> Recently at RPISEC and on Twitter people have asked me what the design
> differences are between INNUENDO and something like Meterpreter. I think
> these are quite large really, and worth trying to explain. Really it boils
> down to a fundamentally different algorithmic approach to distributed
> computation.
>
> So the following chart talks about various types of algorithms and how
> they might apply to our world. An Emergent algorithm is one where lots of
> tiny bits of state and different pieces of code are all sent out on your
> framework, where the end goal is achieved without any one piece of it
> really understanding how it all works. Realistically INNUENDO is not all
> there yet: We're still worker-slave with initiated actions for the most
> part. But the design is built to enable it, and we spent a lot of time
> future-proofing our underlying assumptions from the lessons learned from
> twenty years of implant construction.
>
> [image: pasted3]
> "There are multiple different interesting classes of algorithms," is how I
> would start any conversation at an RPI party. It was pretty much just play
> with CORBA in the lab, read all of USENET and blearily eat morning donuts
> at 4am with the truckers at the local Dunkin Donuts as far as my university
> time went. This hasn't really changed, based on Immunity's recruitment
> mission to RPISEC last week. :)
> Frankly, I still open up with that line at most parties, because these
> days BITCOIN is so popular that even the local PTA moms are in on the
> bubble.
>
> In infosec we often talk about "command and control" as if hierarchical
> instruction was the only way to do distributed computing.  And Immunity is
> just as guilty as anyone else: MOSDEF was designed from the beginning to be
> a theoretical minimalist extensible remote computing loop.
>
> MOSDEF is a loop that executes shellcode, essentially
> while(1){eval(input)} in machine code. To do this, you also have to store
> and send a minimum amount of state (aka, the file descriptor for the socket
> you are using), and you have to have some small conventions about
> protecting certain registers and the stack location, not blocking, error
> handling and returning, a few minor things like that.
>
> At the same time, CORE was also doing quite a lot with syscall proxying,
> which has similar requirements except you send data instead of code.
>
> Meterpreter and MOSDEF and CORE and EMPIRE and almost all simple implants
> have the same basic form. Command to control with maybe a wheel and spoke
> routing model. The same real model the IP network runs on - with addresses
> and destinations and a path between A and B.
>
> In almost all cases, publicly available implants don't even have full
> routing modules built in, they're just simple tree formations where if you
> lose one node you lose all the nodes under it.
>
> As you can annoy people at RPI with, this model is just one kind of really
> boring algorithm, and the interesting class of distributed algorithm is
> what ants and other social insects use:
> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2915909/
>
> One thing you learn about ants is that initial colony sizes were quite
> small, and all the ants looked the same, even if they had different roles.
> But you can't be a self respecting colony of kitchen sugar ants without
> five major body types these days and a colony size of tens of thousands.
> And yet, when we look at implants we tend to look at them fairly separately
> as if they were not built to all work together. . .
>
> In any case, the simple operational difference between current Meterpreter
> and INNUENDO is you can send your request for a screenshot down in INNUENDO
> over a HTTPS connection, and get the response two days later over ICMP or
> DNS as the implant itself sees fit. These things are independent actors for
> the most part, when done right, much as an ant is.
>
> It's like, once you've used the internet for a while, you understand that
> what you really wanted was MESH NETWORKING. But these days, people think
> Mesh networks are niche applications.
>
> In other words: The implants of the future are autonomous agents, and
> probably operate using a class of algorithms which is poorly studied. ;)
>
>
>
> _______________________________________________
> Dailydave mailing list
> Dailydave at lists.immunityinc.com
> https://lists.immunityinc.com/mailman/listinfo/dailydave
>
-- 
Kyle Creyts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.immunityinc.com/pipermail/dailydave/attachments/20171130/a61ba796/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pasted3
Type: image/png
Size: 80719 bytes
Desc: not available
URL: <http://lists.immunityinc.com/pipermail/dailydave/attachments/20171130/a61ba796/attachment-0001.png>