A fun question to ask is, *"why wasn't that Cisco ASA remote patched?"*
Because EQGRP didn't tell Cisco about it, duh. But, wait, if you're EQ and suddenly a bunch of your vulns are in the wind, you're bloody well going to rethink the equities there, right? Especially knowing that an adversary was suddenly in possession of a bunch of your unpatched vulnerabilities... Unless, of course, you didn't know. pty (Alternative explanations: 1. the vuln just got lost in the bureaucracy; 2. meh, it's just a persistence bug, and notifying the vendor would be a tell; 3. some bugs get disclosed, some bugs don't, and, say, an inquiring mind might discern a thing or two about the equities process by reviewing which ones got patched, and when, and which ones didn't.) On Wed, Aug 17, 2016 at 8:01 AM, dave aitel <[email protected]> wrote: > > > So every remote access trojan framework has a high level interpreter built > into it these days. It brings you back to something from that Zero Day > movie (which we all watched drunk to make it bearable, admit it) where a > Kaspersky analyst talked about Stuxnet being "Big but amazingly BUG FREE". > Not having subtle bugs is something you can do much more easily in > Python/Lua/Ruby/etc than in C/C++. There are other good reasons to have a > high level language in your RAT system, but that is a major one. > > One of the other major reasons is that you can push complex logic to the > endpoint that only lives there temporally. By complex logic, we mean > full-on exploits. You can drive CANVAS's entire MSRPC libraries inside > INNUENDO <https://immunityinc.com/products/innuendo/>, without ever > touching disk. And we often do (MSRPC is still important in the world even > though the last good public bug was MS08-026). > > And this is a good reason to choose Python instead of Lua in your RAT. > You're going to want to write your exploits in Python. You're going to want > to run your exploits on the remote side - because of Latency. > > Latency is a funny thing. Inside all networking code is a hellish mishmash > of timeouts, MTUs, retries, and buffers. That mishmash does > Murphy-law-level chaotic things in the face of what you might consider very > reasonable network conditions. Sat hops are one second latency bombs. Add a > couple of those, and a bit of packet loss, and TCP breaks down in some hard > to debug ways that will drive your exploits from "Working \o/" to "Not > worky worky sadface". This is hard to emulate on VMWare or other software > stacks for some reason. > > In any case, there are bad things about putting Python in your RAT, but > one GOOD thing is that no soon-to-be-fired-for-extreme-idiocy operator > will ever upload an entire package to some random redirector box on the > Internet to avoid latency issues. > > That said, I still lean towards HUMINT being a source for the EQGRP leak. > It's kinda a happy battle between colossal stupidity and insane malice at > this point? > > -dave > > TL;DR: https://twitter.com/itsDanielSuarez/status/764898078663012356 > > > > > > _______________________________________________ > Dailydave mailing list > [email protected] > https://lists.immunityinc.com/mailman/listinfo/dailydave > >
_______________________________________________ Dailydave mailing list [email protected] https://lists.immunityinc.com/mailman/listinfo/dailydave
