Argus detecting historical APT1 activity #3

[Carter Bullard]

Gentle people,
To continue on the Argus and APT1 discussion, I had written that the Mandiant
APT1 document described two basic nodes in the APT1 attack infrastructure,
the Hop Point and the Target Attack Nodes.  I'm going to continue to write about
Hop Points for a few more emails, because, having one of your machines acting
as an APT1 Hop Point, is possible the worst thing that can happen in the APT1
attack life cycle.

So far, I've presented that Mandiant's report gives us a lot of detail, trends and
methods, that allow us to detect overt APT1 behavior using the argus data.  Trends
such as APT1's establishment and use of well defined attack infrastructure and
the tendancy to access that infrastructure directly, from well defined IP address
blocks, using specific access methods, and a good description of the attackers
intent, exfiltration of large amounts of data.  These trends lead to a set of very
simple tests for APT1 activity, that can be tested against argus data archives
to help you realize if you've been had, or not. 

The APT1 strategies that Mandiant describes are conventional, and the attack
infrastructure itself is simple, direct, almost optimal (minimal reliable methods,
2-3 hops from attacker to target), suggesting that the infrastructure has
predictable utility, i.e. it may actually work to scale, and work well enough to
be worth the effort.  The ultimate simplicity of the realized APT1 infrastructure,
may be the result of a limit in Mandiant's detection capability ( you can only
see what you are looking for ), but there is no question that what they describe
is real.

While Mandiant is very detailed in what it does talk about, there are huge
gaps in what it doesn't talk about.  I'd like to dive deeper into APT1 Hop Point
identification, but we're lacking key information.  What kind of systems does
APT1 use for Hop Points? Linux workstations ? Windows XP machines ? 
Web Servers ?  Android devices ?  Routers ?  While we have some really
great patterns to look for, like specific SSH certificates, there are so many
things we don't have; initial penetration techniques, command and control
methods, beaconing patterns, persistent vs dynamic access.

In the absence of real detail, we'll have to develop general strategies for
detection, and if we want to have any success, we'll need to avoid 
awareness / detection system pitfalls, such as sampling, and sampling bias
(looking only at one protocol or one type of OS), and matching complexity.

One of the simple characteristics that I will try to leverage in my discussions, is
the intent of the APT1 attack, and the goal of the APT1 Hop Point; to move
a lot of data, from a remote site to another remote site.  If that really is the
singular attack goal for APT1, then with good argus data generation and
analytics, we should be able to find any node that is acting as an APT1
Hop Point, as well as any the other APTx Hop Points that may exist.

The approach that I will try to describe in the next set of emails, is one based
on a Bell-LaPadula style of analysis, to find nodes that have been transformed
from being one type of network based node, to another type of network node, 
in the case of APT1, one that is supporting a demanding network based transport
service.

I'm going to use Time Series Analysis methods, specifically Transfer Function
Models, and Intervention Analysis to realize that a node is doing something
different.  The Transfer Function Models, are perfect for this, as they are
generally used to describe input / output dynamic system response,
and Intervention Analysis is all about the notion that there is an event that
motivates a dynamic change in system input / output.  So I'm going to try to use
this strategy to identify a change in input / output, and then to try to find the
event that correlates with the change.

If you can imagine that there is an argus running on every node in an
infrastructure, establishing a generalize network activity audit, that goes
back quite a ways, then we should have a very rich set of data to perform
this type of analysis, either automated, or by hand.   The goal will be to
realize that a node went from being a specific type of producer / consumer,
to a different kind of producer / consumer, over some period of time.

OK, that is going to be my strategy, any other approaches that seem to be
appropriate?    More to come.

Hope all is most excellent,

Carter




On Mar 23, 2013, at 2:06 PM, Carter Bullard <carter at qosient.com> wrote:

> Gentle people,
> To continue on the Argus and APT1 discussion, I had written that the Mandiant
> APT1 document described two basic nodes in the APT1 attack infrastructure,
> the Hop Point and the Target Attack Nodes.  I'm going to continue to write about
> Hop Points for a few more emails, because, having one of your machines acting
> as an APT1 Hop Point, is possible the worst thing that can happen in the APT1
> attack life cycle.
> 
> The Hop Point is the primary attack node, from the perspective of the site
> being attacked.  If APT1 were to obtain US Classified Information through one
> of your corporate machines, regardless of who is driving the attack, your
> corporation is the attacking entity, and you have will have to assume the
> complete liability for the incident, including cost and reputation impacts, unless
> you can support attribution to the actual attacker.
> 
> I had mentioned last time, that there were behaviors that could be leveraged
> to assess if you had been compromised by APT1 and that nodes in your
> organization were being used as Hop Points.
> 
>> Based on Mandiant's experience, there are some common trends that
>> the APT1 report suggests for Hop Points.
>>    1) virtually all accesses to APT1 Hop Points are from a
>>         select set of IP addresses in China
>>    2) inital penetration and subsequent direct accesses to
>>         Hop Points use Remote Desktop Application
>>    3) many late stage accesses use SSH tunneling, with
>>         specific credentials.
>>    4) Hop points are used to move large volumes of data.
> 
> 
> The #1 trend was that most, if not all, accesses to Hop Points were from Chinese
> IP addresses, and in the previous email, I describe how you can use argus data
> and argus client programs to determine if nodes in your organization are
> communicating with machines in China.  Of course, interaction with Chinese
> machines is not proof of APT1 activity, as I indicated, so care must be taken
> when using general indicators, to strengthen the evidence before you start
> dismantling your organization, looking for APT1 nodes.
> 
> Mandiant suggested that there would be retribution against it for the disclosure of its
> discoveries.  However, based on my experience investigating large scale (global)
> intrusions at the CMU-CERT in the 1990's, this is very unlikely.  Active retribution
> will strengthen the report, and reveal that the investigation has had a negative
> impact on the attackers overall strategy.  What will most likely happen, is that
> the adversary will change its methods, rather than stop its activity.   "Was", the
> past tense of "is",  is now the correct tense to use, when referring to Mandiant's
> description of APT1's methods.  
> 
> In this email, I'd like to talk about how to detect APT1 Hop Point activity, when the
> accesses are not from China, and work our way to a point where you can use argus
> data to detect the activity.  I'll try to do this, without this email growing to 100 pages.
> 
> The key is to try to understand what does a Hop Point do in its role in the APT1
> infrastructure, and then to try to confidently detect that behavior.  The Mandiant
> report indicated 3 other trends for Hop Points.  1) Access was done through Microsoft's
> Remote Desktop Protocol.  Detecting that RDP was used at any time to access
> nodes within your infrastructure, will be a telling point.  2) Many accesses are
> tunneled through SSH, so detection of SSH tunnels to nodes outside your normal
> Community of Interest (COI) will help to strengthen a case for APT1 activity, and
> 3) Hop Points are used to move large volumes of data.  Detecting that nodes
> are using any method to move lots of data out of your infrastructure, will be our
> primary key.
> 
> This last trend, that APT1 Hop Points move lots of data out, is very important, and
> deserves a great deal of discussion, which we can't do today.  Hopefully, it will
> suffice to say that Hop Point data movement should not be called Exfiltration,
> but simple Transport.  The data the Hop Point is moving, doesn't originate from
> the Hop Point's enterprise, but from someone else's enterprise.  So the data has
> to come into the enterprise, and then leave.  This is critical to establishing a simple
> detection criteria.  An APT1 Hop Point is really a transport node, either store and
> forward, or real time transit.  If its a real time transit node, then its a single hop
> Stepping Stone, which can be detected pretty easily.
> 
> Single hop Stepping Stones can be easy to find.  A single transport thread that
> is going from X -> A and A -> Y, at the same time with multiple similar characteristics,
> such as instantaneous load, application bytes transferred, packet dynamics.
> You would like to think that content patterns would be a reliable method for matching,
> like it is for tracking NAT processes, but it is may not be as good as you think.
> If the two threads are using TCP, as an example, the two different connections
> can have wildly different network experiences, such as variations in MTU, widow size,
> loss rates etc... causing the data patterns to be more variable than expected.
> But that doesn't make the effort impossible, just slightly complicated.
> 
> If you like to think of abstract objects and then find examples of them, a single
> hop stepping stone is a proxyed connect that is terminated and re-originated.
> In some cases, it is very similar to a NAT process, but because the connects are
> terminated, the two threads of transport will have different sequence numbers,
> TCP options, TTLs, framing points, and possibly different MTUs, all of which
> can change the number of packets, and the packet sizes, but eventually they
> are two TCP connections that are moving the same application payload, so
> there will be somethings in common.
> 
> Argus clients can identify NAT'd traffic, where the IP addresses, and the ports
> have been changed (to protect the innocent ?), because argus data collects
> additional attributes that are not modified, like base sequence numbers, and
> payload patterns.  The attributes of interest in stepping stone detection is
> coincidental presence, with similar application loads.  And because Hop Points
> move very large amounts of data, you should look for flows that stand out,
> not ones that are hiding in the weeds.
> 
> As an example, taking your argus data collected from your enterprise border,
> the goal is to find pairs of flows, that occur at the same time, with similar
> appbytes transferred over that period.  rabins() can help a great deal here.
> rabins() processes flow data, aggregating and sorting, within single time bins.
> By aggregating records within specific time periods, using the default mode
> of aggregation, and sorting based on appbytes, you will consolidate like flows
> together in the output.
> 
>    rabins -F rabins.rarc -r argus.data.file -M time 1m -w -  - tcp
> 
> In the rabins.rarc, the RA_SORT_ALGORITHM would be set to "dappbytes sappbytes".
> Of course, your argus sensors must be configured to provide this appbyte data.
> 
> For single hop Stepping Stones, you're looking for flows that are similar in app
> byte demand where  X -> A and A -> Y.     In multi-hop stepping stones, the
> similarity will be there, but it will be X -> A and B -> Y.  There is no indication
> in the Mandiant report that APT1 was that cleaver, but you should not exclude
> that.
> 
> When the Hop Point is a bit more sophisticated, the transport will not be real-time,
> it will be store and forward.  What that means is that the Hop Point will collect the
> data, wait for some period of time, such as an hour or a day, and then it will transfer
> the collected data and send it to the mother ship.  If the transfer is limited to a
> one-to-one transfer model, then completely aggregated argus data is needed to
> find the transfer of the same file.  This is easy.
> 
>    racluster -r argus.data -w /tmp/argus.transaction.data
> 
> This will consolidate all the status records for a given TCP connection, into
> a single record.  For 2 TCP connections that move the same file, the resulting
> two TCP argus records will have identical SrcAppByte or DstAppByte values,
> depending on whether the two TCP connections are push or pull.  So, take
> the output of the general aggregation, and look for completed TCP connections
>  that have equal sappbytes or dappbytes metrics.  These should represent
> transport of the same files.
> 
> Not to ignore trends #1 and #2 from above....  Detection of RDP and SSH is really
> pretty trivial with argus data and argus client programs.  You can filter for the well
> known protocol port numbers, and you can inspect the user data captured in argus
> data to detect these protocols on other ports.  Because RDP puts a bit of a network
> demand to do its thing, its easy to find long lived high packet count sessions that
> span an enterprise border, even in the presence of encryption. The average rate
> and load needed to export displays, and to propagate mouse events is pretty
> unique, so finding these is pretty easy.
> 
> RDP based connection attempts either from or to external nodes is trivial.
> 
>    ra -R /your/entire/argus/archive - \
>          tcp and port 3389 and not src net ( .. the list of local network addresses...)
> 
> This should pick up scans for open RDP server ports, both failed and successful,
> and transactions that are actually transferring data.   Variants of this filter may be
> needed to test all the possibilities, but hopefully you can see how trivial this is.
> 
> OK, enough for a Saturday, please send comments / opinions / flames whatever
> to the list.  If you think we should write clients that automate some of this discovery,
> then do send your request to the list !!!!
> 
> Hope all is most excellent,
> 
> Carter
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130327/abc6e6dd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2589 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130327/abc6e6dd/attachment.bin>