<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
CANVAS added HTTP/S + Proxy support to Java MOSDEF last week <a
href="http://www.immunityinc.com/news-latest.shtml">for the
release.</a> This means that when you attack people with Java
client-sides you get a much higher rate of success against Financial
and Federal Govt networks, which is awesome in its own way. For some
people this is very important, and for others, much less
important...and I've been trying in my head to figure out what the
lines in the sand are here between groups, and where CANVAS and
similar tools fit into these processes.<br>
<br>
As a tool vendor, one thing you realize is that every penetration
tester out there has their own favorite set of tools and
methodologies. But this implicitly ties them to an ecological niche
that is very hard for them to switch out of. In a sense, they often
have to give up their entire toolkit, training, habits, and mindset
to switch ecological niches, like a caterpillar learning how to
drink from flowers instead of eating leaves. The table below comes
from another document, but helps illustrate these issues (and many
of you, of course, will disagree with the table below because you
are cooler than me):<br>
<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top"><b>Sample Test Environment</b><br>
</td>
<td valign="top"><b>Toolkit Characteristics</b><br>
</td>
</tr>
<tr>
<td valign="top">Your local network (or one you have
reasonable physical access to) at a modern large US
corporation (or local/State governments)<br>
</td>
<td valign="top">
<ul>
<li>Shellcode callbacks are optimized in such a way that
it is smaller and simpler by not worrying about
timeouts, dropped packets, or other network
irregularities (i.e. early MSF shellcode always made
this tradeoff - not sure about now). If you see
"recv(size)" rather than "while recvedsize < size:
recv(size-recvedsize)", then this is where you are.<br>
</li>
<li>Sending really large files is commonplace and easy -
network protocols assume low latency and high bandwidth
(c.f. "Syscall Proxying")</li>
<li>C&C done over TCP (or ICMP/UDP perhaps more
rarely) - no covertness levels needed for standard
C&C. You'll see people ignore HTTP Proxy support
here.</li>
<li>It's easy to maintain a concrete connection from your
initial attack point to the very edges of your
penetration - this effects your situational awareness
and operational plan significantly.<br>
</li>
</ul>
<p>Essentially this level is where many commercial tools
really shine today.<br>
</p>
</td>
</tr>
<tr>
<td valign="top">Financial and Federal Government Sector <br>
</td>
<td valign="top">While large, complex, and heterogeneously
managed, these environments often include strict standards
which restrict outbound connectivity to one of two flavors:<br>
1. All outbound connections must be over HTTP/s Proxies,
with NTLM user authentication. This is the most common. <br>
2. WebSense or another proxy is used to ensure that only
reputable sites are reached (i.e. a whitelist approach is
often taken to new websites). This is less common, but when
it is in place it is significantly harder to manage by
commercial toolkits - meaning the threat to these
organizations is poorly modeled at the moment.<br>
3. DNS is logged, analyzed for anomalies, and in many cases
filtered so new domain names don't "exist" - breaking most
standard callbacks. <br>
<br>
In terms of good news for penetration testers (and our APT
friends), you generally have plenty of bandwidth and latency
and storage is rarely a problem in these networks (latency
being something banks tend to hate with a passion), but
connectivity is going to start to force your C&C into a
wheel-spokes configuration, with particular boxes chosen as
exfiltration points. (Some of the more recent talks on APT
were quite good at pointing this style out - generally you
see standard tools being used in custom ways by good
operator teams here).<br>
<br>
AV evasion is a useful (but easy) feature when you get to
this level, on a host and network level.<br>
<br>
At many higher levels here you'll also see application
whitelisting, which has its own restrictions on your
toolset. These can be worked around, but you often end up
special-casing your toolset to deal with them. (e.g. US
Military red teams)<br>
</td>
</tr>
<tr>
<td valign="top">3-Sat-Hops-Deep - for example, a shipboard
computer network on a carrier group<br>
</td>
<td valign="top">Size becomes a premium - writing exploits in
these environments is like sending care packages to
astronauts. You can still maintain C&C and decent
situational awareness in these environments if you do it
carefully. This kind of environment is where operator skill
gets a bit "magical" - did that packet get dropped or did
the exploit fail? <br>
<br>
When dealing with these sorts of networks, you'll see
operators that have habits as strange as those of a cave
dwelling salamander. For example, <a
href="http://www.tunnelbroker.net/forums/index.php?topic=2463.0">ICMP
messages</a> being dropped cause TCP to silently fail, or
managing packet loss on a TCP network manually by
retriggering resends with null packets, etc. Latency becomes
a much bigger issue than bandwidth typically - 3 seconds can
be a long time to wait for a packet to bounce back, so you
won't see people doing things like typing into Cmd.exe here.<br>
<br>
The tools and techniques at this level are weird but almost
understandable. Most penetration testers get culture shock
here, like any normal corporate executive visiting outback
Saudi Arabia. But things at least look similar at a high
level - they still look like <i>hacking</i>.<br>
</td>
</tr>
<tr>
<td valign="top">Protected Nuclear Bunker or SCIF - no
legitimate wired access to outside world.<br>
</td>
<td valign="top">Here is where you need a FLAME-like protocol
where you receive (incompletely in many cases) data that the
worm has decided was interesting enough to exfil. And you
get this data weeks or months after it has been collected.
This has obvious ramifications for your operational cycle.
Your C&C must be resilient to active attack as it's
unlikely you can make modifications to it in time to beat
your opponent's incident response. (<a
href="http://labs.bitdefender.com/2012/06/flame-the-story-of-leaked-data-carried-by-human-vector/">This
BitDefender</a> article is the best resource on how these
types of C&C look in the wild.)<br>
<br>
Things at this level often don't look like hacking so much
as managing information flows within an organization by
injecting pieces of code in the right places. Or rather, as
Immunity's current doctrine would put it, they look like the
near future of hacking.<br>
</td>
</tr>
</tbody>
</table>
<br>
<pre class="moz-signature" cols="72">--
INFILTRATE - the world's best offensive information security conference.
April 2013 in Miami Beach
<a class="moz-txt-link-abbreviated" href="http://www.infiltratecon.com">www.infiltratecon.com</a>
</pre>
</body>
</html>