Dailydave mailing list archives
Re: Ants in your pants
From: Kyle Creyts <kyle.creyts () gmail com>
Date: Thu, 30 Nov 2017 17:41:01 +0000
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 () 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 () lists immunityinc com https://lists.immunityinc.com/mailman/listinfo/dailydave
-- Kyle Creyts
_______________________________________________ Dailydave mailing list Dailydave () lists immunityinc com https://lists.immunityinc.com/mailman/listinfo/dailydave
Current thread:
- Ants in your pants Dave Aitel (Dec 01)
- Re: Ants in your pants Kyle Creyts (Dec 01)