<p dir="ltr">So, this has become its own market segment now, and I think attack/adversary simulation is really important. Yes, I agree that accurately simulating current tactics is important, but this is a hugely valuable capability even if the simulations are older,since the average enterprise is far from effectively defending against more sophisticated adversaries. And let's be honest - the attackers most likely to go after the average organization don't get terribly fancy unless they have to (they usually don't have to).</p>
<p dir="ltr">What is exciting here is the ability to safely simulate attack/breach activities in production as often as you want. Most orgs only have an opportunity to do something like this once a year, during the annual pentest, and most orgs I've seen squander that opportunity by focusing instead on the missing patches of the day,not the fact that domain admin creds were created, and no one noticed. To significantly improve defenses, we need to be able to cycle through improvements weekly, not once a year, and it is impractical to do pentesting activities that frequently. In fact, most orgs I've seen don't have anyone qualified to run active attack tools safely, so they're usually banned from doing so. </p>
<p dir="ltr">I see three key use cases with tools like Innuendo:</p>
<p dir="ltr">1. Functional controls testing - is your stuff powered on and working is it plugged into the right SPAN port? Is it in monitor or blocking mode? Is it configured they way you THINK it is configured? Run functional tests after every major environment change, maintenance work, and on a regular periodic basis - once a week seems reasonable. I think every integrator/professional services team installing enterprise security tech should do some sort of real<br>
2. Efficacy testing - okay, you detected C2 over HTTP. What about HTTPS? Tor? DNS? The next step past functional testing is ensuring that you can detect the attacks you're most likely to get hit by. <br>
3. Response training. Forget annual IRP training. How about testing your SOC team/analysts weekly?</p>
<p dir="ltr">There's are a few other commercial offerings here with varying features and complexity - SafeBreach, Verodin, AttackIQ and vThreat to name a few. </p>
<p dir="ltr">That's my $0.02 on this. </p>
<p dir="ltr">--Adrian</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Nov 30, 2016 08:52, "Christos Kalkanis" <<a href="mailto:chris@immunityinc.com">chris@immunityinc.com</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Paul,<br>
<br>
INNUENDO was created to be a framework, or a superset if you like,<br>
of APT functionality that was common at the time but also visible on the<br>
horizon. The most important design decision we made was to keep<br>
the architecture flexible enough in order to both adapt to and subsume<br>
emerging techniques used by nation states while dealing with uncertainty<br>
and failures on the target end. This led us to fully adopt Python as<br>
the core of INNUENDO [1].<br>
<br>
In the years since, we've watched, with some satisfaction,<br>
the domain shift towards the direction we had envisioned. From<br>
Flame to Project Sauron and beyond, there is a trend towards<br>
more flexibility and runtime dynamism including the use of languages<br>
other than C. In short, the implants are getting more intelligent.<br>
<br>
I think we have done a good job of matching and in many cases<br>
exceeding the rate of change in this arena with features<br>
such as:<br>
<br>
+ An embedded debugger available from the get-go.<br>
<br>
+ Implicit implant-to-implant routing, no configuration needed.<br>
<br>
+ Peer-to-peer network for implant synchronization.<br>
<br>
+ Ephemeral in-memory execution without artifacts.<br>
<br>
+ In-process sniffer also exposed through Python and<br>
optional out-of-process usage.<br>
<br>
+ Bidirectional Outlook exfiltration channel.<br>
<br>
+ Programmable channel-switching behavior.<br>
<br>
+ An executor that can transparently manage and execute 3rd party<br>
Python code + its dependencies at runtime.<br>
<br>
Some of these haven't been widely observed in the wild yet,<br>
I expect to see them out in the open sooner rather than later.<br>
<br>
Finally, I am not aware of any criminal elements using our framework,<br>
but I'd say that the more sophisticated actors are certainly moving<br>
in the same direction.<br>
<br>
[1] <a href="http://infiltratecon.com/downloads/python_deflowered.pdf" rel="noreferrer" target="_blank">http://infiltratecon.com/<wbr>downloads/python_deflowered.<wbr>pdf</a><br>
<br>
Chris<br>
<div class="elided-text"><br>
On Tue, 29 Nov 2016 14:57:37 -0600,<br>
Paul Melson <<a href="mailto:pmelson@gmail.com">pmelson@gmail.com</a>> wrote:<br>
> So are you aware of a criminal actor that uses Immunity's Innuendo in their attacks? If not, then which adversary are you simulating?<br>
><br>
> The point to my obvious straw man is that if you really want to help your<br>
> clients up their game in detecting and responding to real threats, shouldn't<br>
> you study the actors that target their industry verticals and emulate their<br>
> operations using the same tools and tactics they are known to choose?<br>
><br>
><br>
><br>
>> On Nov 29, 2016, at 9:26 AM, dave aitel <<a href="mailto:dave@immunityinc.com">dave@immunityinc.com</a>> wrote:<br>
>><br>
>> So obviously everything a penetration testing company does is at some level<br>
>> "Adversary Simulation". I like to call it "Focused Training" - because<br>
>> penetration testing is more about education than anything else, but the WAY<br>
>> you do to that is by emulating and instrumenting some sort of adversarial<br>
>> process.<br>
>><br>
>> Ok, that said, we have for the past year offered a special service called<br>
>> Adversary Simulation by which we meant something quite specific. We go to<br>
>> some big financial company, usually super under-dressed for the cold because<br>
>> we live in Miami, and we install INNUENDO on a couple machines. Then we<br>
>> exfiltrate a few terabytes of data over whatever protocols are working and<br>
>> we work with the company to do a hardcore analysis of their detection<br>
>> systems for that sort of thing.<br>
>><br>
>> That sounds simple. But in practice, every company at that size range has<br>
>> multiple products trying to detect you, and they provide overlapping<br>
>> coverage. Sometimes the Alerts are useful, and sometimes not. For example,<br>
>> when you're doing DNS exfiltration, FireEye will alert on the weirdness of<br>
>> the DNS packets. But it has no idea who the infected endpoint is, because<br>
>> those DNS packets came from intermediary DNS servers! :)<br>
>><br>
>> With web-based analysis systems I worry more about false positives, and of<br>
>> course, false negatives. Detecting beacons from malware but not from, say,<br>
>> DropBox is a hard problem. In theory, products like StealthWatch work, but<br>
>> in practice, that depends on the team.<br>
>> Likewise, there are gaps in the market itself: Who is looking at all<br>
>> outbound e-mail to find data exfiltration channels? And on the host, when<br>
>> faced with a new product, all the protection systems we've seen have not<br>
>> detected INNUENDO. Some of them detect injection, but you don't really need<br>
>> to do that. What if there is too much chaos on a big company's desktop for<br>
>> reputation-based protection systems to work?<br>
>> -dave<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Dailydave mailing list<br>
>> <a href="mailto:Dailydave@lists.immunityinc.com">Dailydave@lists.immunityinc.<wbr>com</a><br>
>> <a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" rel="noreferrer" target="_blank">https://lists.immunityinc.com/<wbr>mailman/listinfo/dailydave</a><br>
> ______________________________<wbr>_________________<br>
> Dailydave mailing list<br>
> <a href="mailto:Dailydave@lists.immunityinc.com">Dailydave@lists.immunityinc.<wbr>com</a><br>
> <a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" rel="noreferrer" target="_blank">https://lists.immunityinc.com/<wbr>mailman/listinfo/dailydave</a><br>
______________________________<wbr>_________________<br>
Dailydave mailing list<br>
<a href="mailto:Dailydave@lists.immunityinc.com">Dailydave@lists.immunityinc.<wbr>com</a><br>
<a href="https://lists.immunityinc.com/mailman/listinfo/dailydave" rel="noreferrer" target="_blank">https://lists.immunityinc.com/<wbr>mailman/listinfo/dailydave</a><br>
</div></blockquote></div><br></div>