This past April (4/19 to 4/21) I had the great pleasure and experience of joining the Red Team at 9^th NCCDC competition.   It was actually my 2^nd year on the Red Team and 4^th year to attend in total (I judged in 2010 and 2011).  McAfee is actually a perpetual sponsor of this event.  That being said, I have my own selfish agenda when I attend.

Joining in as part of the Red Team is, by far, on of the most educational experiences I could possibly put myself in.   Not only are you tossed into a room w/ folks like Mubix, Vyrus, Raphael Mudge, and others – but also you are on a limited schedule and from the time that the competition starts it’s heated and non-stop.

The general strategy this year was to lay down all our toys and persistence (backdoors, beacons, RATs and other tools) on Day 1.   We made very little noise, hoping that the competing teams would gain a false sense of confidence and not notice our presence on their systems.   This way on Day 2 when the chaos commences, and the teams choose to just ‘restore from backup’ or ‘revert snapshots’ and the like, they end up restoring all our persistent tools and we retain access and ownership.

DarkComet Client Console

And . . . .. . It worked!

Different individuals on the Red Team had their unique tools and methods to gain and retain access and unset the teams’ activities.   As the McAfee guy, I choose to rely on some old, tried and true (and very accessible RATs).  Most of my activities centered on the use of DarkComet and, to a far lesser degree, DNA.

RAT Remote Process View

My philosophy was driven by two primacy goals.   First, I know these things work realllllllllly well.  And with these RATs on the box, I can control and own everything.  Second, and possibly more interesting, is that if these tools work, I know that the teams are not putting any effort into installing/deploying even the most basic endpoint/host-based AV solutions.   This is especially intriguing because, as a sponsor, McAfee provided the competition with our software.   I purposely did NOT do any crypting/packing/obfuscation on the RATs I generated.   I know that McAfee (and just about all other) vendors DID detect these things.  Yet, I still managed to install and persist on most of the hosts that I deployed to (deployed via Cobalt Strike btw).

When the competition was over, I chatted with a few competitors, and mentioned this fact.  I immediately saw the gears start turning.  I could tell they had a real “Ahhhh we should have done that” moment.  Not to mention, that McAfee (and others) detect meterpreter/MSF listeners and Trojans as malware/PUPs.  Those could have been curtailed as well.

Each year, the teams have to setup, maintain, and safeguard an environment for a faux company/entity.  This year the teams were tasked with tasked with the environment of a Correctional Institute.   This includes databases for tracking the whereabouts of prisoners, an e-commerce site for a prisoner commissary, and more.  From the Red Team perspective, this gives us some of our big bets for getting points deducted from the teams.   For example if you kill/mangle/destroy the database for tracking prisoner and personnel, that’s one of the high point items.   After all, they don’t want an IT issue to allow prisoners to go unaccounted for or escape, etc.   Other hot items include public web site defacement and acquisition of PII (personally identifiable information).  For added fun, many of us defaced the web sites by posting the company’s PII for all to see.

Defaced with PII

All and all it was a fantastic experience.   I look forward to future activities with this competition.

UTSA shot a documentary this year.  I’ll post details on that once it’s released.    However, if you’d like to get some really detailed info, Hak5 released a documentary filmed at the 2012 event.   It features great interviews and ‘behind the scenes’ Red Team action.   I’m not interviewed, but you can see the top of my head in a couple shots!!

Hak5 Doc – Jim’s Head

2012 Hak5 Documentary

Additional Blogs on NCCDC 2013

• David Cowen - http://mcaf.ee/wid10
• Raphael Mudge - http://mcaf.ee/ageor
• Alex Levinson - http://mcaf.ee/limh1

NCCDC 2013 Red Team Brief - http://mcaf.ee/uodvk

Bonus:   We recently did our 2^nd AudioParasitics episode with the great Raphael Mudge.   This time we have a full and glorious video demo of Cobalt Strike in action.  We actually walk though scenarios and give you details on how some of these Red Team activities actually occur.

AudioParasitics Episode 141 (video) - http://mcaf.ee/gep69

There has been a great explosion of chatter in the last day around Anonymous’ “Operation Last Resort” (a.k.a. #OpLastResort).

The entities behind the various “official” communications around this operation have a sense of humor that we must point out (especially because if you don’t catch it, you will end up wiping your disk).

Background

In typical fashion with these events, some data suggests that the whole thing (or at least the leak) is a hoax. Regardless of what data resides in the leaked files, it is apparent that someone is having fun, via the embedded scripts in the USSC site. (See the Update section, below, for details on the Konami scripts.)

Anonymous has infiltrated specific US government systems in response to the “killing” of Aaron Swartz, who committed suicide on January 11. According to various posts and other communication channels, the operation is also tied to Barrett Brown and the law-enforcement actions against him. Ussc.gov (and others) have reportedly been compromised, and various caches of sensitive data have been exfiltrated. The first round is a .rar file (composed of multiple raw downloads). Details on how the compromise or breach took place are not clear or reliable. It is likely (though unconfirmed) that part of the initial intrusion was via SQL injection. Based on phrases in the official videos, RATS or other temporary “leakware” may have existed on compromised systems, and have been subsequently removed by the attackers. Reports suggest that the contents of this leak pertains to various U.S. Supreme Court Justices.

The file set includes an official promo video for the operation, as well as a statement:

"Still there is nothing quite as educational as a well-conducted demonstration...

Through this websites and various others that will remain unnamed, we have been 
conducting our own infiltration. We did not restrict ourselves like the FBI to one 
high-profile compromise. We are far more ambitious, and far more capable. Over the last 
two weeks we have wound down this operation, removed all traces of leakware from the 
compromised systems, and taken down the injection apparatus used to detect and exploit 
vulnerable machines.

We have enough fissile material for multiple warheads. Today we are launching the 
first of these. Operation Last Resort has begun... Warhead-US-DOJ-LEA-2013.AEE256 
is primed and armed. It has been quietly distributed to numerous mirrors 
over the last few days and is available for download from this website now. 
We encourage all Anonymous to syndicate this file as widely as possible.

The contents are various and we won't ruin the speculation by revealing them. Suffice 
it to say, everyone has secrets, and some things are not meant to be public. At a 
regular interval commencing today, we will choose one media outlet and supply them 
with heavily redacted partial contents of the file. Any media outlets wishing to be 
eligible for this program must include within their reporting a means of secure 
communications.

We have not taken this action lightly, nor without consideration of the possible 
consequences. Should we be forced to reveal the trigger-key to this warhead, we 
understand that there will be collateral damage. We appreciate that many who work 
within the justice system believe in those principles that it has lost, corrupted, 
or abandoned, that they do not bear the full responsibility for the damages caused 
by their occupation.

It is our hope that this warhead need never be detonated."

This release is the referred-to “warhead”–specifically “Warhead-US-DOJ-LEA-2013.AEE256.” The “trigger key” referred to in the video is the decryption key for the content. Anonymous also indicated that they will, at some interval, release heavily redacted previews of the decrypted content. As of this writing, these have not emerged. We have, however, seen some fake decryption keys making the rounds.

Now, back to the “humor” that I alluded to earlier in this post. Some of the releases around this operation contain the following handy instructions:

If you did not catch it, at the end that’s an “rm” with force and recursion starting at the root.

What else does this operation entail? It is said that a Twitter-Storm campaign will commence on January 25.

"BEGIN THE MESSAGE OF ATTACK on January 25th at 11:59 PM EST"

Full details on this part of the operation are detailed in some of the groups PADs. This will be an interesting operation to pay attention to during the next few days.

What will the next warheads be? When will we start to see decrypted content from any of the warheads circulating? How will various governments react?

Stay tuned.

Update, January 27

The USSC.gov site is still compromised. A special surprise (via embedded JavaScript) awaits those who  recall some of the old Nintendo/Konami codes. Through a series of keystrokes, a script will let you fly various objects around the page, view fireworks, and more.

Upon execution, the script provides some on-screen controls, and you can even control the various objects (including Nyan Cat) via the arrow keys.

Generic Dropper.p (XtremeRAT)

This is where, from the research side, things begin to get fun.

Automated malware analysis is nothing new to our industry. Most vendors (ourselves included) have tools to handle this internally, and assist our skilled human analysts with proper classification, documentation, and other recurring tasks that must occur with the daily barrage of new and unique malicious binaries. The bar for this threat, however, has been raised. With ValidEdge, we were able to generate enormous amounts of usable and actionable data from the execution of malware samples. We get feedback from basic static analysis, as well as from runtime data. We get all the usual system modification data, and full and complete network/communication data, and samples and memory dumps from second-level threats (dropped, created, downloaded entities). And it’s all done in a safe environment, with extremely robust reporting.

To fully illustrate, let’s focus on the Trojan that affected the Israeli police. In the McAfee universe, we detect this threat as Generic Dropper.p.

To start with, you simply submit your sample(s) to the ValidEdge appliance/host. The ways to do that vary depending on implementation. In my setup, it’s as simple as dropping the file, via FTP, on the appliance, then picking up the results set the same way (different directory on the FTP server). Easy and fast. I immediately had a set of results from my submission of the following sample:

The result sets are organized as a specific directory structure.

Analysis report sample

This is where we typically end with most tools. The exception here, from my experience, is that there is much more data generated by the appliance to start taking action on.  The way in which the information is organized is also very friendly and workable. Some basic examples follow:

Sample Data	Sample Data 2
Sample Data 3	Sample Data 4

From here we can get enough static data to build a picture of the malware and its behavior. We also have network data and full memory dumps and screenshots at our disposal should we need to dig further.

Memory dumps

PCAPs

All the secondary/dropped files are presented as well. As such, these can be easily analyzed in context.

Dropped files

Dropped files, specific to this threat, are detected via McAfee Global Threat Intelligence along with the current DATs.

Example:

Name: word.exe
MD5: 2BFE41D7FDB6F4C1E38DB4A5C3EB1211
Detection: Artemis!2BFE41D7FDB6

At this point you have plenty of information to understand what this threat is doing, how it communicates, and much more. Some would argue that deep malware analysis is an art form. But to embark on that sort of journey you need enough data to make constructive, creative, and accurate decisions. Tools like ValidEdge do exactly that.

If you would like to learn more, you can read the following sources:

• http://www.opswat.com/partners/technology-partners
• http://www.mcafee.com/us/products/network-threat-response.aspx

We see this type of attack over and over. Most recently LinkedIn and eHarmony were in the news with similar issues. This Yahoo breach is just the latest in a series of similar attacks that occur in multiples every day.

The attack was launched by the D33DS Co., whose release included this:

D33DS is probably correct in that latter sentence. But are their methods and motivation ethical or legal? That’s a different story. Regardless, Yahoo’s overlooking basic countermeasures against basic attacks (such as SQL injection) cannot be excused.

This is not the first time that Yahoo has been compromised in this way. During the last five years, Yahoo Local Neighbors, Yahoo Kids, Yahoo Classifieds, and others have been successfully targeted.
Ironically, there is a blog on SQL-injection prevention on Yahoo Voices. It was posted in 2009.

What else is interesting about the latest breach?

More than just @yahoo.com usernames and accounts were exposed. If there was ever a time to heed warnings about password reuse, especially across public and high-traffic social systems, this is it. Yahoo may have been the focus of this attack, but data in the dump could be used to target specific users from AOL, Microsoft, Google, Comcast, SBC Global, and others.

Here is a breakdown of associated domains that appear in the D33Ds release:

Yahoo breach Top 20 domains

I’ll leave you with several McAfee resources for understanding SQL injection:

• WebSec 101 – SQL Injection. http://www.mcafee.com/us/resources/audio/transcripts/websec101-sqlinjection-slides.pdf
• McAfee Security Scanner for Databases. http://www.mcafee.com/us/products/security-scanner-for-databases.aspx
• Threat Brief – LizaMoon. http://www.mcafee.com/us/resources/solution-briefs/sb-lizamoon-sql-injection.pdf
• White paper on Real-time Database Monitoring, Auditing, and Intrusion Prevention.  http://www.mcafee.com/us/resources/white-papers/wp-real-time-database-monitoring.pdf

—————————————————-

The March Security Bulletin release from Microsoft was relatively light in volume. Out of the six bulletins released, only one was rated as Critical.

And for good reason. MS12-020 includes CVE-2012-0002. This flaw is specific to the Remote Desktop Protocol (RDP) present on most current versions of Microsoft Windows. The RDP service, by default, listens on TCP port 3389. And because it’s so darn convenient, lots of people like to open their firewalls/ingress points to the traffic.

This is a bad/dangerous/insecure thing. (Choose your own favorite term.) I hope this issue (and many others before it) will influence anyone’s decision-making process when it comes to network hardening, external access, etc.

This is certainly not the first flaw in RDP. It is quite significant in that it does not require authentication to exploit the flaw–just a firing of some specially crafted packets. From that point the world (or the world that the compromised host lives in) is the attacker’s oyster. This is especially bad because the RDP service runs in kernel mode, under the System account (in most cases).

Keep in mind that it is very easy and takes little time to find targets. You see this type of situation all too often:

It's Open!

This situation very quick leads to an intruder’s trying to login via brute force, or trying something new (like the flaw described in MS12-020) !

It Actually Works!!!!!

So, what can you do to protect your environment?

McAfee, Microsoft, and others firmly recommend that you prioritize the deployment of the MS12-020 update.

Other steps:

• RDP is typically disabled by default. If there is any doubt, investigate and confirm in your environment whether and where it running.
• In Windows Vista or later, enable Network Level Authentication (NLM)
• Even if you have NLM enabled, the flaw can be exploited if the attacker can gain authentication. This means you should verify strong (nondefault, sufficiently complex) user/password combinations.

Resources

• CVE-2012-0002: A closer look at MS12-020′s critical issue
• Microsoft Security Bulletin MS12-020
• McAfee Vulnerability Manager

McAfee Coverage Data

Coverage exists in:

• McAfee Vulnerability Manager (FSL release): 3/13
• McAfee Network Security Platform (Sig release): 3/13
• McAfee Remediation Manager (V-Flash): 3/13
• McAfee DATs (partial coverage, for known PoC code, is provided as “Exploit-CVE2012-0002″ in the 6652 DATs): 3/17

CVSS: (AV:N/AC:M/Au:N/C:C/I:C/A:C)(E:POC/RL:OF/RC:C)

——————- UPDATES ———————————

March 15: McAfee Labs has observed in-the-wild proof-of-concept code targeting this vulnerability. There are a few varied samples that we are both monitoring and analyzing. At this time the coverage/mitigation data already in this post is still valid.

We are continuing to monitor this situation and will provide updates as needed. An updated MTIS Security Advisory has been sent to subscribers.

To stay up to date on these and other critical security events, please subscribe to our McAfee Threat Intelligence Alerts.

March 16: The last 24 hours have been a virtual flood of proof of concept (PoC) and exploit details. Some of these are reliable; some are not.

• This flaw was actually discovered by Luigi Auriemma in May 2011
• There are numerous fake code examples and scripts on Pastebin and similar sites. As is typical, links to these fakes are advertised all over Twitter, etc.
• The code examples/PoCs that are valid can successfully crash the RDP service, but do not move beyond that (to code execution or to allow for the possibility of code execution)

Associated malware samples and events can be traced back several years, and multiple platforms were targeted. To this day many remain affected or infected and are still open to compromise.

The amount of helpful data around this issue is plentiful. Even the FBI has provided a tool to check whether your host/IP is affected.

https://forms.fbi.gov/check-to-see-if-your-computer-is-using-rogue-DNS

So, fast-forward to the present: Within McAfee Labs we have been flooded with queries (forgive the DNS pun) on what will happen on March 8, and what other impacts might ripple through our environments as the FBI takes the next steps toward concluding Operation Ghost Click.

The Good News!

On March 5, a U.S. District Court in New York signed an order to extend the March 8 deadline to July 9.

This extension will allow all affected entities to continue to track down and remediate against hosts that are still compromised. Current data indicates that there are still several million infected or affected hosts worldwide.

Also, as a handy reminder, the offensive Netblocks are well documented:

• 67.210.0.0 through 67.210.15.255
• 93.188.160.0 through 93.188.167.255
• 77.67.83.0 through 77.67.83.255
• 213.109.64.0 through 213.109.79.255
• 64.28.176.0 through 64.28.191.255

To learn more about how to maintain your online connection and to protect against this malware family, read our new Threat Advisory:

https://kc.mcafee.com/corporate/index?page=content&id=PD23652

For McAfee Customers: Detection for associated malware is provided under the DNSChanger Trojan family.

For example: http://www.mcafee.com/threat-intelligence/malware/default.aspx?id=141841

Other Resources:

• McAfee Labs Security Advisory MTIS11-219
• McAfee Labs Threat Advisory on DNSChanger
• McAfee Labs DNSChanger Description Search
• The FBI’s DNSChanger Malware
• United States District Court Southern District of New York Post-Indictment Protective Order extending the March 8 date. (Click on image to expand.)
  

  Court-ordered date extension

There have been a number of reports and studies on the SQLi threat and the extent to which various regions/platforms/verticals/etc. are exposed. The basic takeaway runs along these lines:

• On any given day, it is normal to expect to see around 1,600 SQLi attacks against the most attractive servers (Microsoft IIS/ASP.NET and Apache, for example)
• The most prevalent and attractive (to the attackers) servers or platforms could easily expect to log 40 to 80 SQLi attempts per hour

Those are the current stats. Does this mean we should not be worried about the Urchin.js attacks? Goodness, no. But, my answer would be the same for the other 1,599 attacks going on every day.

As I highlighted in my previous LizaMoon blog:

Before any of us blow our IT budgets on database security goodies, we must all take the basic first steps. Simple and core techniques, such as constraining user input, validating user input, limiting types of input, encrypting sensitive data, and designing accounts with the principle of least privilege will go a long, long way.

The same basic principle holds true for this event.

On a side note, a few other handy stats may help put this into perspective.

• According to Netcraft and a few others, there are around 505,000,000 sites on the web
• Apache is the most popular web server platform, running around 327,000,000 sites
• Microsoft (IIS/ASP.NET) is the second-most popular server platform, running around 79,000,000 sites

The SQLi attacks associated with the urchin.js script inclusion are specific to ASP.NET servers. Current stats indicate that the number of injected/affected hosts is just over 1,000,000.

This particular attack really began to take root at the beginning of this month.

Once the news broke, it was quite easy (via simple Google queries) to see evidence of the injections on affected sites.

Searchin' for Urchin

Technical Meat and Potatoes?

The injected script (urchin.js) forces the browser session to direct traffic to a number of malicious domains. At this point we have observed a variety of secondary malware. They range from the most basic generic Trojan families, to DNS changers, and now to rogue video codecs (bogus Adobe Flash Player, for example), which are backdoor Trojans.

The latest variants (example: MD5: fb4c93935346d2d8605598535528506e) are no different. This sample in particular is a rogue Flash Player install.

This Trojan contacts an number of remote hosts that are known to be “sketchy” and have been associated for years with other malware campaigns. (Remote hosts are registered under GigeNET.)

The LizaMoon Relationship

The original attack domains are:

• nbnjki.com
• jjghui.com

Both of these share the same domain registration details as the original LizaMoon attacks.

Again, both the original attack domains are registered under BIZCN.COM, which has a less than stellar reputation of associations (direct or otherwise) with malicious domains. This reputation can be traced back for several years.

Make Me Feel Safe–Again

I hope this information has put the threats in perspective. Don’t get me wrong; this attack is certainly visible, and deserves the attention of those who are exposed. I would like to stress (as we have done before) that this attack is one of many that occur constantly. Establishing a strong security posture and embracing the most basic and essential steps in web and database security will go a long way. You’ll find yourself much less exposed to Urchin.js as well as to the thousands of other SQLi attacks that are targeting your environments.

As of this writing, here’s your McAfee-specific coverage information:

We will continue to update our content/coverage/countermeasures, as the situation requires.

Like many others, I was raised an Apple faithful. Later I came to embrace and believe in not just the products but also the culture and philosophy behind the products and innovation.

I was in first grade when my father brought home an Apple IIe. Everyone in the house woke up early the next morning, when it was all set up in the den, to take turns typing our names. As my finger movements were translated into green lettering, I was both transformed and enlightened. It’s safe to say from that point I was hooked. We all became proficient in BASIC, ProDOS internals, and all the rest of it. I started attending occasional HAAUG meetings with my dad, and did all the usual fan/enthusiast stuff.

Fast-forward to 1984, with the release of the original Mac. Again, like many I was heavily attracted to the platform, the interface, the “it just works” and “fits like a glove” aesthetic, and more. As I grew more and more familiar with the early Macs, I started to be the “go to” kid for friends and family who needed help and support (foreshadowing, eh). I even spent time assisting my mother’s school district in maintaining their Mac labs, all as a young punk kid.

As a young teenager I took a few years hiatus and devoted myself fully to the world of Amiga. I still to this day maintain an unhealthy enthusiasm for the Amiga platform, but back in 1993-94 the Amiga was doomed. In the wake of the Commodore failure, I (and many of my peers) were faced with a choice. Where do we go now? As Amiga users, the worst and most unimaginable thing to do would be to adopt Windows. Going back to the Mac was the next best thing. To Amiga users, it was not so far off as there were some shared hardware components and other things that made it “okay.” Also, there was much excitement around the Mac’s move to the PowerPC chip.

At this time I made a deal with my mother to go in halves with me on a new PowerMac 6100. As a junior in high school, this took some time. If I recall my half was somewhere around US$1,200. Lots of pizza deliveries went into that machine, but it got me though the rest of high school, as well as college. It just so happened that my next-door neighbor in my first college dorm had a 6100 as well. There was much bonding as we tricked out our machines: maxing out the L2 cache, fooling with RamDoubler and other silly utilities, and lending each other Zip drives to recover from the fatal Netscape disk-corruption issues.

Over the years I’ve continued along the same route. It would be impossible to list all the Apple computers and devices that I have accumulated over the years. For some reason, I still have all of them.

I’m now raising my kids on the Mac platform, just as I was raised on the early Apple systems. I think we have one Windows laptop in the house, but it’s the “use this when no others are available machine.” The point is that I see that same spark in my kids’ eyes that I had; they “get it.” They will not grow up as technophobes or bitter Windows users. They have a choice, but I can already see that they gravitate toward the Mac, and I like it.

It’s safe to say that I would not be doing what I love to do today without the influence of Apple and Steve Jobs (and Woz, too). Even my entry to McAfee (then Network Associates) was Mac-influenced. I came on board in 1998 to assist with support on the newly acquired Dr. Solomon Mac products. At that time it was the Anti-Virus Toolkit, Virex, and the highly underappreciated netOctopus.

Throughout my career with McAfee I have inserted myself into our Mac-related business and dealings, even when my position had nothing to do with it. Why? I’m not sure, other than the fact that I truly love the platform, and I enjoy evangelizing our offerings on it.

I could probably write on this topic for several more hours. The real bummer now is that I’ll be spending a great deal of time over the next 72 hours closely watching for social engineering lures that exploit the death of Steve Jobs with malware and spam campaigns. We’ll be scouring social networks and other channels for the like. It’s the sad state of malware these days, but we’ve seen it time and time again. Any newsworthy event, especially celebrity related, will be exploited to prey upon the masses.

So that’s my story. The Apple legacy, in my opinion, will live on as strong as ever. It’s much larger than one man or one machine. It’s a culture and lifestyle. Even those who do not use or prefer Apple products are still reaping the benefits of their innovative style and technology.

Goodbye Steve Jobs, and “MOOF”

Moof!

In the last few days, a new vulnerability in Microsoft Internet Explorer has made its way through the media. Disclosed at the Hack on the Box conference by the independent researcher Rosario Valotta, this flaw takes advantage of a property of HTML5 to steal the cookies from its victim.

This kind of attack, called cookiejacking by Valotta, bypasses all the security measures in Internet Explorer and works on any version of the application and Windows.

Sounds scary, doesn’t it? Well, this threat is really more noise than anything, and we’ll explain why.

First, unlike other truly dangerous attacks or malware that are completely silent (as PinkSlipbot), this attack requires the victim to visit a malicious site and commit a drag-and-drop action. Also, the attacker must know the victim’s Windows username and where cookies are stored.

Second, although many sites leave their cookies in plain text, the cautious ones (such as banks) keep those values encrypted so that attackers can’t easily gain usernames and passwords.

Third, ask yourself a question: How many times have you been working on a site you’ve logged into and when you refresh a page or move on the site you find you need to log in again? More than once, yes? That’s because almost every website that uses cookies gives them a very short lifespan, so even if someone manages to steal your cookies, the attacker would have to use them within the timeframe.

If this low-likelihood attack is successful, the attacker will have a complete history of your browsing–which sites have you visited and how frequently–so you could start seeing a lot of spam/phishing designed especially for you.

If you’re truly unlucky, the attacker will catch your usernames and passwords of the sites that store them in plain text, so someone could adopt your identity on those specific sites. But remember, sites that manage sensitive information use encrypted cookies.

Could this scenario be dangerous? Sure.

But is it dangerous by itself? Not so much, and you can very easily prevent falling for this kind of attack.

Be careful where you go on the Internet. Do you see a link with a new online game? Search for it first, and read the comments! Has a friend sent you a Facebook invitation that seems strange or out of place? Don’t go! Ask your friend about it.

Keep your cookies clean, delete them regularly, log out of any important website every time you finish your business. These are simple steps, but they will invalidate those cookies. And, finally, never, ever allow a website to remember your sessions! That keeps your cookies valid for future sessions.

Really, all we need is a bit of caution.

M. Francisca Moreno Vilicich and Alfonso A. Kejaya Muñoz of McAfee Labs Chile made major contributions to this blog.

This is notable because normally it would cost quite a bit to purchase the kit and associated services (in excess of of US$10,000). With a release of this sort, the most immediate concern is what will be done with this code, in the wrong hands. Also, how quickly will we start to see examples of those efforts in botnets.

From a vendor point of view, when this sort of thing occurs, we must be ready to respond to customer and public queries about any countermeasures and safeguards that we can offer. Having said that, Zeus is not “new,” and we constantly (and have for years) been dealing with compiled binaries and output from this kit. The current technologies in our tool belt (AV, NIPS, HIPS, app control/whitelisting, firewall, etc.) all provide protection against the output, traffic, and noise from the Zeus toolkit.

Zeus Crimeware Toolkit

We are researching the source packages internally and will enhance our current protection should the need unexpectedly arise.

Stay tuned during the next 72 hours for more updates on this one. It should be interesting as the saga unfolds.