Outbound Denies

Many organizations don't allow a default route out of the enterprise.  In other words, they force systems on the internal network to go through some sort of a proxy in order to reach the Internet.  In general, this is a good thing, as it provides both auditing and egress control/filtering.

Monitoring this type of traffic creates two types of extremely interesting data from a network traffic analysis perspective, both involving denied outbound traffic:

1) Traffic that is proxy aware, but attempting to connect out to controlled/filtered/denied sites.
2) Traffic that is not proxy aware, and is thus dropped (no default route out allowed).

Both #1 and #2 can be caused by misconfigurations, and #1 can be caused by attempted drive-by re-directs that fail/are blocked (and thus do not result in successful compromise).  In both those cases, the denied traffic is not caused by malicious code being successfully installed and executed.  In other cases, however, #1 and #2 may indeed be caused by malicious code or some other type of rogue process.

It's another jumping off point that can be used to provide valuable insight into what may be occurring on the network.  With the speed at which attackers maneuver, every little bit helps.

Giving Credit Where Credit is Due

Giving credit where credit is due is a powerful and widely respected rule among analysts.  Sometimes, certain types of opportunists (non-analyst types) will try to leverage the work of an analyst without giving credit where credit is due.  Similarly, some of the opportunist types are inclined to use the connections/experience/reputation of an analyst without properly respecting those connections/experience/reputation, some of which may have taken years to earn.  Needless to say, this doesn't go over very well with the exploited/leveraged analyst, nor the larger analytical community.  Giving both respect and credit where they are due is important.  People take notice of these things.

Talk is Cheap

It used to surprise me when a client would tell me something like: "Wow, it's so unusual that we get a consultant in here who actually knows what he's talking about!".  This is a powerful statement, but unfortunately, it no longer surprises me when I hear it.  In the words of a colleague whom I respect tremendously: "There are an awful lot of hacks out there."  Sadly, this appears to be the case.  The phrase "easier said than done" is a fitting one.  "Talk is cheap" is an even better one.  It seems that in general, there are people who talk about the need to make progress, and then there are people (perhaps like myself) who actually do something and move the state of the art forward.

I hear an awful lot of cyber security rhetoric.  It seems to increase in volume almost daily.  Oddly enough, despite all the talk, I see very little progress week to week, month to month, or year to year.  Talk is cheap.  My challenge to the talking heads out there is to spend less time talking and more time doing.  Give your mouths a break and get your hands dirty making some real changes.  That is the only way to progress.

Passive DNS

Collecting passive DNS data on your network can produce a data source of extremely high analytical value.  Because the data collection is passive, it has little (or no) impact to operations.  What is so interesting and valuable about passive DNS data you ask?  Well, for starters, it records what domain names were assigned to what IP addresses at the time those domain names were requested.  This makes all sorts of interesting analysis possible.  For example, which domain names were requested that point to IANA reserved (e.g., 192.168.0.0/16) or downright silly (e.g., 111.111.111.111) IP addresses?  This can be an indicator of compromise, as malware authors will often park their callback or second stage domains at these types of IP addresses.  Additionally, all the standard analysis that one would do on DNS logs can be done on passive DNS data as well.  For example, which domain names have been changing IP addresses frequently or have extremely short TTLs (i.e., fast flux)?  Or, as another example, which domain names have been requested periodically, or in a pattern more typical of a machine than a human-being?

Passive DNS data is a lot of fun to experiment with and analyze, and it provides a good deal of value.  Check it out!