I've given a few presentations this past year regarding security visualization where I have implied for all intents and purposes that Zeus (or Zbot) can be considered part of the advanced persistent threat (APT) picture.
As I prepared for the most recent presentation to the ISSA Puget Sound chapter meeting I contemplated the premise of Zeus-as-APT a bit further, and also found myself amused by the implication that there was now a Zeus v3.
Let me first debunk the v3 claims.
The Zeus hype over the last few weeks has been off the charts given a brilliant marketing campaign from M86 who, in their latest white paper, have gone so far as to refer to certain Zeus variants as Zeus v3.
Quite simply, I disagree.
The M86 white paper states that "Zbot/Zeus v3 version is an evolved mutation of Zbot 2. Unlike the older version, this one focused specifically on online banking."
If this is the basis for declaring the samples analyzed for this white paper as v3 I must cry foul.
As an example, Figure 1 includes content from a Zeus v1 (yes v1, not even v2) config file that clearly targets online banking, specifically Wells Fargo. The MD5 hash for this sample is 3cfc97f88e7b24d3ceecd4ba7054e138 if you wish to confirm for yourself.
Figure 1
The Zeus version transition from v1 to v2 was born of the inclusion of code signing, advanced encryption methods, and licensing (one install per registered user, please). Either way Zeus has long targeted online banking and does not warrant new version nomenclature on this premise alone. I'll grant that mutations and variations are rapid amongst Zeus samples, with particular goal of avoiding detection, but in my opinion it's still the same v2 code-base.
While a bit more difficult to de-obfuscate, a recent Zeus v2 sample showed clear signs of classic Zeus behavior and targeted a mass of online banking offerings.
Figure 2 offers a small subset of targeted institutions pulled directly from the config file.
The MD5 hash for this sample is d86ba734b30c650b091dd39e7707872c and you can pull the sample for your own analysis from ZeuS Tracker.
Figure 2
As per the "Is Zeus an APT?" question, I have mixed feelings here.
I've recently read two excellent discussions on the matter that offer slightly different perspectives.
In Dr. Eric Cole's Advanced Persistent Threat: The Insider Threat, posted to Dark Reading on Aug 16th, he is very precise in his definition of APT:
"The entry point with many attacks is focusing on convincing a user to click on a link. However, once the APT breaks into a system, it is very sophisticated in what it does and how it works. Signature analysis will be ineffective in protecting against it. Advanced attacks are always changing, recompiling on the fly, and utilizing encryption to avoid detection."
Gary Hoglund's The shadowy world of the advanced persistent threat and botnets, posted to SC Magazine on July 15 offers a slightly different take:
"…botnets traditionally were not associated with state-sponsored attacks (sometimes called advanced persistent threats, or APT). While that characterization may have worked five years ago, it is completely outmoded for today's threat landscape. Botnets have evolved to become generic remote-access frameworks."
Dr. Cole further states that "stealth and being covert are the main goals of today's attacks. APT's goal is to look as close {if not identical} to legitimate traffic. The difference is so minor that many security devices cannot differentiate between them."
Zeus clearly communicates via "legitimate traffic", isn't noisy, and goes to great lengths to disguise itself.
Hoglund also points out that Zeus "has a plugin architecture, so any capability is possible. The base source code of Zeus readily is available, and attackers can easily customize the system for any purpose. There are hundreds of custom variations of Zeus in operation today.”
Following the sound logic from both of these gentlemen, Zeus is a bot used for APT-like attacks. While it may not often be used in very narrow, highly specific attacks (not to say that it isn't), it is certainly used in a very targeted fashion.
Attackers simply drop the C&C mechanism on hacked web server (see Figure 3), target a specific victim set, and collect data until shutdown, where after the move on.
This morning's RSS headlines included a most troubling reference from TrendMicro detailing Zeus being utilized for a deeply nefarious and specific purpose: targeting US military personnel bank accounts.
While this may be a broad victim audience, it's still targeted specifically to Bank of America Military banking users.
So is Zeus an APT? If not, it certainly partially qualifies; call it pseudo-APT.
Let me know what you think, of both the Zeus-as-APT debate as well as the M86-driven Zeus v3 ambiguity. Comments welcome.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Sunday, August 22, 2010
Tuesday, August 03, 2010
Suricata in toolsmith: meet the meerkat
Rather than fan the Suricata versus Snort flames (you're both great kids and I love you equally) I'm opting for Swiss-like neutrality and simply invite you to explore Suricata at length.
See Victor Julien's post on the matter as he sums it up succinctly.
While I've always been a Snort user, I've also long been an ardent supporter of Matt Jonkman's Emerging Threats. Given his logical progression towards the Open Information Security Foundation (OISF), a "non-profit foundation organized to build a next generation IDS/IPS engine", I felt deeply obligated to cover Suricata in toolsmith.
Suricata: An Introduction is my effort to oblige.
While this article is painfully introductory, it should whet your appetite.
Suricata, as the "product" of OISF, is compelling on different fronts.
1) Intent: "OISF’s primary goal is to remain on the leading edge of open source IDS/IPS development, community needs and objectives."
As such, Suricata "is not intended to just replace or emulate the existing tools in the industry, but will bring new ideas and technologies to the field."
Committing to community needs and objectives, much as Emerging Threats has, is noble and valuable.
2) Scale: My testing on a dual core box matches Victor's assessment.
"Is Suricata faster than Snort on a single core cycle for cycle, tick for tick? No. But we scale. We’ve had reports of running on a 32 core box and scaling to use all cores. There Suricata is much faster."
I believe performance at scale is essential/vital/critical to IDS/IPS success in this burgeoning age of all things cloud and virtual (think complexity, and mondo network traffic). Groundbreaking thinking on my part, I know. ;-)
Consider that an unnamed military body has tested Suricata versus Snort on a large scale platform (24 processors and 128GB of RAM) and saw a very clear 6-fold speed increase over a tuned Snort implementation on the same platform.
3) HTP Library: In a context similar to all things cloud (online services), effective HTTP normalization and parsing is mighty important. Ivan Ristic's HTP Library endeavors to provide "very advanced processing of HTTP streams for Suricata."
4) Features: I'll let the comparison chart speak for itself.
Performance geeks will definitely want to explore the use of PF_RING and leveraging CUDA-capable hardware. The article clarifies these a bit more.
5) Same rules (Snort-based): Need I say more?
These should be ample reasons for you to give Suricata a really close look.
Deploy it.
Give it every opportunity to prove itself side by side with your current IDS/IPS solution.
Keep an eye on the project site, and get involved.
Start by downloading 1.0.1 here.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Subscribe to:
Posts (Atom)
Moving blog to HolisticInfoSec.io
toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ...
-
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
When, in October and November 's toolsmith posts, I redefined DFIR under the premise of D eeper F unctionality for I nvestigators in R ...