The first panel that I was on dealt with a particularly challenging topic: bringing the fight to the adversary.   For most people in our space, when they hear or read statements that espouse bringing the fight to the adversary their thoughts immediately drift towards offensively driven “hack back” scenarios.  My experiences on this panel however couldn’t have been more to the contrary.  We discussed castle building (explain or include link to a definition) and the failures of current and traditional operational security models.  This discussion also touched on how our inability to effectively see traditional operational security models through to fruition could be indicators of what the performance of the unskilled enterprise might look like should they engage in a truly offensive capacity.  In the end, all of us agreed that the current United States code was clear on what is and what is not deemed legal (never mind the ethical arguments).  We came to the conclusion that unless forcefully compelled by the courts, offensive measures were likely troublesome at best and disastrous at worst.  This panel forced me to rethink the topic of offensive measures and in some ways reposition my own beliefs.

I believe that offensive security measures (when thoughtful and measured) can be effective.  I believe advanced active defensive strategies, when applied in a lean forward manner, can provide organizations a great deal of insight into who their adversaries truly are, what they want and how they are attempting to go about gaining access to the target assets in question.  Surprisingly, while most strongly agreed that attribution was critically important when defending an attack there was notable dissent on the subject.  I believe that active defense begins with the basics and though I am skeptical of the way in which many organizations operate in respect to the basics of information security, I advocate a hard-lined approach to the basics in order to prepare for advanced threats.

So what does this all mean? How does an organization that has its act together with respect to the basics get to the point to where they can effectively lean forward into an advanced active defense?  For starters they can try to understand what they expect from themselves and their adversaries.  Red Teaming is a tried and true test of one’s readiness.  If an organization fails a Red Team engagement than they need to revisit those areas found susceptible, remediate and re-engage.  If the organization in question has conducted Red Team engagements and passed with flying colors than they should begin looking at technology and methodology that will allow them to meet their aggressors head on.

Understanding who your adversaries are (and are not) will make this process smoother.  Understanding what it is about you that makes you a likely target for an adversary also aids in the process of preparedness and when conducted in an intellectually honest manner can save vital resources necessary for other purposes.  Technology such as honeynets & honeypots (regardless of the ethical questions they pose) can be invaluable tools for attack definition and attribution.  One cannot gain an insight into who is banging on their door threatening to break in if one does not have a vantage point that allows them to characterize their adversary.  The application of false flag data or advanced network segmentation can also thwart and confuse potential adversaries.  In the end a lean forward approach sees an organization taking pre-emptive measures against a threat actor prior to his arrival (when possible).

Does your organization utilize an active defense (offensive as a defense) strategy?  Is there any justification for “hacking back”?  How critical is attribution when defending attacks?

• 

A large covert network was revealed and summarily reviewed during the investigation code named “Red October”.  Certain parties have made the claim that the choice of code name is directly tied to the source of origin however, there has thus far been no evidence (beyond the speculative) presented that supports this.  According to Kaspersky Labs the earliest known evidence related to this campaign dates back to May 2007 (verified through domain registration information – used for C2s)  and thus far was still active as of January 15, 2013.

The advent of the Red October cyber espionage campaign comes at an interesting time.   By all appearances it has the look and feel of a state-sponsored APT style attack however there are some key differences that have led most experts to conclude that this is something entirely different.  What makes this campaign interesting isn’t the fact that there was an advanced and elaborate exfiltration network in place, advanced malware kits, importation of exploits or that the information harvested from the infected networks was reused in later attacks.  No.  What makes this campaign intriguing is the question that surrounds the attribution of the threat actor.  The hypothesis is that this is the work of organized criminal entities who have decided to switch gears and jump into the world of espionage vis-a-vis cyber means.  That seems plausible given the risk vs. reward argument that seems to govern these organizations decision making when it comes down to moving from one illicit market in favor of another.

The actor identification seems to be the most intriguing (and clearly news worthy) aspect of this campaign.   Kaspersky Labs asserted in their report that due to the registration of the domains (C2 servers) and the “numerous” artifacts left in the malware executables that the threat actors were most likely from a Russian-speaking region.   Though there are no other examples of work – attacks or executables known, that is the assertion.

But in an age where attribution remains difficult at best does it make sense to presume that the nationality of the threat actors is Russian based off of domain registration records?  I guess they forgot that criminals often fraudulently register domains using falsified information on a regular basis.   It may be premature to assert that the nationality of the threat actor corresponds to the C2 server.  Further, it might be premature to assert that the threat actor is not in fact nation state sponsored but is merely criminal looking to segue away from traditional (or non-traditional depending on their degree of sophistication) criminal activity.  So where does that leave us with the case of Red October?  I think it leaves us in a place where more research is required and additional analysis warranted.  The code is clean and the approach the threat actors employed noteworthy however, clean and sophisticated code and a noteworthy approach are not necessarily enough to determine attribution.

• 

For years risk management types of have been preaching the gospel of establishing CMDBs and promoting asset criticality matrices.  If you’ve done this and maintain it regularly, you’re ahead of the game. If your organization has not endeavored toward doing so you may wish to reconsider that point as we progress through this blog.  Understanding your organizational asset inventory is of paramount importance to all information security professionals especially those tasked with monitoring the enterprise in reactive and proactive scenarios.

Knowing the proverbial lay of the land is key largely due to the fact that first rule of intelligence analysis is being able to ask ourselves what do we know based on the information we have at our disposal?  Not being able to answer that question is akin to flying blind and no one wants to go through that type of experience.  So understanding what we know unequivocally in the absence of speculation or conjecture is a good thing and should be embraced.  How do we get there?  We begin by evaluating every piece of technology we have at our disposal for its value in terms of being an intelligence collection agent.  This may seem like a daunting task but it’s important nonetheless.

Understanding what is occurring on the host foot print for example of every user in your enterprise will aid in narrowing the gaps of your knowledge as you begin to compare that activity to that which is occurring within systems, servers, infrastructure etc.   So understanding what you have to work with as part of your asset inventory becomes increasingly valuable.  Network defenses are also huge fonts of intelligence data.  Firewall logs tell us who is doing what on a transaction-by-transaction basis via rules.  IDS / IPS tell us what if any vulnerabilities are experiencing either anomalous activity on the wire or exploitation.   Web and Mail gateways empower us with knowledge related to HTTP and SMTP communications respectively while SIEMs tie this all together in a cohesive package for the analyst to view in a composite form factor.  But does this give or provide true visibility into what is occurring within (and outside) our enterprise footprints?  The answer may surprise you.

Where we need to begin

No.  We need more insight into transaction-oriented communications at the packet level in order to see what is truly occurring on a host-to-host level and host-to-network level.  We need to be able to reconstruct sessions based on what we are seeing and make decisions (driven by information security policy) with respect to the results.   We also need data to feed platforms powerful enough to collect information security intelligence data to feed these tools and platforms ultimately seeing their value increase and be realized exponentially.

Honeypots for example, are not new but are becoming increasingly viable solutions within network security infrastructure.  Why?  Because they enable the analyst to see who is coming toward them and what their TTPs might be with respect to malicious code promulgation.   Sinkholes are also becoming increasingly viable though there is more complexity involved with them than with traditional honeypots.  The point is that without greater insight that can only be derived from a greater vantage point one will struggle with the application of information security intelligence achieving mixed results at best as they struggle to contend with advanced adversaries ready to strike without warning.

• 

The world has changed.  It’s a fact that can no longer be avoided.  People and enterprise organizations alike are being taught a lot about intelligence in particular the types of intelligence that impact their lives through cyber channels and non-cyber channels alike.   In this blog we’ll introduce the concept of intelligence, its collection and most importantly its application in our daily lives in the environments we work and play in.  People love knowing (or believing they know) something that someone else doesn’t   It can be an intoxicating thing to be privy to information that is shared and known by a select few.

More important than the level of biochemical and emotional response this evokes is what we do with the intelligence we have.  The idea that all intelligence is equal, as we’ll see, is farcical.   We’ll investigate how grading and weighting intelligence can help in its application and how this application of intelligence can ultimately lead to a more stable, secure organization with a keener understanding of its risk posture and the risk posture posed by its constituents.

Collection

Intelligence collection is as much an art as it is a science.  It requires a great deal of insight into traditional and nontraditional areas of interest that an organization may concern itself with.  There are myriad ways through which one can collect intelligence; organic and inorganic.  For the purpose of this blog (as we’re only touching on collection here as opposed to diving deeply) we’ll assert that intelligence collection is a people, process and technology driven proposition that strives to obtain (through the marriage of disparate intelligence disciplines) a composite perspective that accurately represents an organization’s worldview and itself (and its user population) within the context of that world view as potential targets.

The goal should be the obtainment or achievement of high fidelity intelligence that is salient and actionable.  Anything less is unacceptable.  The real question is how do we apply this intelligence once we have collected it?  And how can we ensure that the intelligence is acted upon in a timely manner thus preventing or narrowing the likelihood of a potential attack?

Application of Intelligence within the Enterprise

For enterprise environments, the application of intelligence – regardless of the intelligence type, begins with verification and classification.  If these steps are forsaken, and one assumes that the intelligence that one has collected is irrefutable without first having vetted it, mistakes can be made and vulnerabilities introduced to the enterprise environment that can lead to compromise.  As a result, the verification process (inspection of what you expect) is key to successful application of intelligence along with appropriate classification of the intelligence itself.

Prioritization will – once verification and classification have been completed, become the focal point of the application of the intelligence as it is brought to the attention of those within the enterprise organization concerned with its analysis.  At this point any number of actions may be taken with respect to the intelligence in question.

Updates in the form of new firewall rules, network and host base signatures or filters, web and mail protection may all come into effect alongside the application of threat feeds  and parsers such as the ones my team, RSA FirstWatch produces for the consumers of technology.  Regardless of how it is applied within your enterprise you’ll need to consider doing so if you have not already begun doing so.  In this blog we discuss very high level scenarios regarding intelligence collection and application.  In subsequent blogs we’ll be exploring these concepts in more detail leaving as few stones unturned as possible.

We hope you’ll keep reading!

• 

One point that should be made which I hope the informed reader can infer for themselves is that the article didn’t specify the difference between host and network analysis.  My good friend Harlan Carvey pointed that out to me — and I agree that it is perilous to ignore one aspect in favor of another as opposed to viewing monitoring of this sort as being ecosystem driven, that the host view was missing in this piece.   Thanks Harlan!  So let’s chat for a minute on the role of the analyst in identifying and analyzing events of interest (pre-categorized events that later map to an attack or campaign).

Sight Beyond Sight

In my opinion, there is no substitute for a well-trained analyst; no tool, no process, no procedure can replace or supplant them. An experienced and well trained analyst knows what to look for and knows what he or she is looking at when they see it.  It’s difficult to say how much of this is nature vs. nurture but make no mistake, there is a balance that is struck and a certain amount of innate capability that cannot be taught.  No tool can ‘instill’ this elementary characteristic that solid analysts share; critical thinking, logic, reasoning and an analytic approach to problem solving.

“No tool can ‘instill’ this elementary characteristic that solid analysts share; critical thinking, logic, reasoning and an analytic approach to problem solving.”

Tools and technology (along with well articulated and vetted process & procedures) cannot always narrow this gap if it exists, though they do help enormously in making the less obvious more obvious to the uninformed viewer.  Technology (robust, ecosystem-aware) can communicate in a clear and concise manner what it knows to be occurring.  Though this is important it should never be treated as the be all, end all in terms of conclusive analysis.  The analyst will still be required (if not lead to) cross-correlate the results derived from one platform against those of another seeking corroboration of results.  If a delta exists, he or she will note that and press on seeking a third technological opinion as they apply their own experience to what they are seeing and experiencing.

Experience is Paramount to Success

So, why should we care about what was written in the Dark Reading article I mentioned above?   Put very simply we should care because these threats are and remain among us.  They have been with us for some time now and their architects demonstrate no signs of slowing their progress due to their levels of success.  In many cases they are far less ‘advanced’ or ‘sophisticated’ in terms of their base technology (the malicious payload for example) than one might be lead to think.

The experienced analyst can tell the difference, noting the nuisances in surveillance and reconnaissance techniques employed by the threat actor and the distribution (and receipt) of the malicious payload.  Having an experienced eye reviewing the data related to these events of interest is critical to success or failure as the devil is in the details.

Let me give you an example.

During the VOHO campaign an organization we spoke to noted lateral movement occurring within its environments.  Their analysts highlighted a file that is ubiquitous to all modern Microsoft Windows operating systems as being malicious and wanted an opinion of it.  The RSA FirstWatch team reviewed the file and noted it was benign.  After which we suggested that the file on the machines in question be left alone as its state is indicative of normalcy and tampering with it could have negative ramifications on the health of the hosts in question.  In this example the analysts of one organization thought they had narrowed activity of the threat actors down to a specific file that in actuality it was a normally functioning file that the victim organization was not aware of.

The experienced eye of the analyst, in this case, saved quite a bit of time, energy and additional work that could have come as the result of the victim organization making an erroneous change to the file in question rendering the host inoperable.

http://blogs.rsa.com/?p=7141

• 

In the second installment of this blog series we built off of the first installment by discussing in greater detail many key principles and concepts for the comprehension of indicators of compromise (IOC) by security analysts.  We continued our conversation related to how IOCs relate to observables and how observables relate to measurable events and / or stateful properties on a given host.

We also reiterated the importance of being able to identify, collect, record and note in a detailed manner IOCs as they are encountered in a host and network-based forensic investigations.  In fact, I can’t stress too often or strongly how important this truly is!  We also introduced another framework or taxonomic model that is making waves in the industry related to the establishment of a formal approach to IOC creation and communication, the OpenIOC initiative.   We found that the OpenIOC standard is intriguing due to its highly extensible, well vetted for IOC development and customization of IOCs for organizations of varying size and industry vertical.  Potential downside being that it is  vendor-sponsored and largely driven though it endorses a “community” driven look and feel.  For some organizations, this will be the ‘Achilles heel’ in the selection process.

What is the IODEF (RFC 5070)

The IODEF is a standing IETF RFC (RFC 5070) that is designed to address and define a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents.  The basic premise is that organizations need help from third parties to mitigate malicious or nefarious activity targeting their hosts and networks.  They need to gain additional (presumably absent) insight into these new and exotic threats.  The coordination element of this communication seems to be less obvious and natural than one might think hence, the need for a standards-driven framework for coordinating this process.  The RFC suggests that such coordination may include (but is not limited to) working with ISPs to filter traffic deemed malicious and unwanted, to contact a remote site to take down botnet hosts or for the sharing of reputation-based intelligence.

The architects of the Incident Object Description Exchange Format (IODEF) are a format that offers the users a means by which to represent computer security information as described above.  It is communicated via an XML schema that conveys incident information across administrative domains amongst parties that have an operational responsibility for both remediation and notification of their user population.

The data model itself encodes information about hosts, networks, and services running on various systems, along with attack methodology and associated forensic evidence (artifacts), and impacts.  Furthermore, the standard offers an approach (albeit a limited one) for documenting the workflow necessary for triaging and communicating the aforementioned data.

Details

Overall, the IODEF (which came out in 2007 and was sponsored by some folks at the University of Amsterdam) strives to enhance the operational capabilities of CSIRTs and threat intelligence analysts.  It’s community driven which makes it highly extensible and affords the standard refinement and improvement driven by an ‘open source’ community independent of a vendor sponsor.  The architects of the standard designed it with the goal of improving the ability to resolve incidents while being able to more artfully express situational awareness via simplified collaboration and data sharing.  A beautiful thing however, it may not meet your organization’s needs and requires more research as we’ll see.  The format that the standard espouses sees its architects advocating automation for the following:

• Processing incidents
• Decreased efforts in normalization of incident data
• Common format / schema for the purpose of building tools for incident handling and analysis

Net Effect

A very well defined standard driven (vendor independent) approach to the creation and articulation of IOC related information and intelligence.  For some organizations this will be a much more natural and easily adopted format than for others given its vendor neutrality and heavily documented nature.  For others, it may not be as readily adopted due to the very same reasons.  I would recommend organizations investigate this standard and become familiar with it in comparison to the two other standards we have described and discussed in this series to date.   I believe that an open standard designed with increasing situational awareness and ability to react is what most organizations require and that this is a great example of what can be done and how it can be architected for an enterprise and a community.

Conclusion

All of the standards we looked at require scrutiny and investigation in order that organizations make the correct decision in terms of which to adopt and for what reason.  It’s completely plausible that an organization may decide that certain aspects of one standard and certain aspects of another make for a winning combination.  Whatever your decision take the time to review and assess your organizational readiness in preparation of adopting one of these standards.  In doing so, you will save both time and trouble!

• 

In the first installment of this blog series we discussed several principle ideas and concepts necessary for security analysts as they seek to master an understanding of indicators of compromise (IOC).  We discussed how IOCs relate to observables and how observables tie or relate to measurable events or stateful properties on a host.  We also discussed the importance of being able to identify, collect, record and note in a detailed manner IOCs as they are encountered in host and network based forensic investigations.  We also began discussing standards or taxonomic models that are making waves in the industry (rightly so) and left off preparing to discuss the three leading contenders in detail: CyBox, the OpenIOC initiative and IODEF (RFC5070) respectively.  We concluded the first installment in the series with a dialogue on CyBox and today we’ll discuss the OpenIOC initiative.

What is the OpenIOC Inititiative?

Like the CyBox program sponsored by MITRE, the OpenIOC initiative is a program designed to bring a degree of maturity, repeatability and order in a taxonomic fashion to the world of the security analyst and incident responder.  Its architects designed it in such a way so as to guarantee expeditious communication of information germane to quickly detecting, responding and containing targeted attacks.  Additionally, it ought to be noted that this is a vendor sponsored emerging standard.   The goal of which is to address current holes existing within enterprise organizations’ operational and threat mitigation models; specifically where threat intelligence sharing (in a machine readable format) is nonexistent.  This is not necessarily a bad thing.  This is neither the first nor will it be the last time that a standard has emerged from a vendor rather than a collective standards body such as the IETF for example.  For some organizations, vendor standards such as this one will be looked at with a quizzical eye.  For others, adoption will occur rapidly.  In many cases adoption or the lack thereof, will be dependent upon whether or not the organization in question has already made an investment in the underlying architecture that the standard was designed to compliment.  Either way, if one is investigation standards that address IOCs one must investigate the OpenIOC initiative.

Details

The OpenIOC is an extensible XML schema that empowers analysts with the capability to achieve the following:

1. Definition of the descriptive elements of a given threat – technical; non-technical, methodology or evidence of compromise

The standard was originally developed by a vendor to enhance and enable their products platform from a intelligence codification perspective during breach investigations.  This ‘standardization’ led to requests of the vendor through its user community to make the schema open and available to all who use the vendor’s platform and technology.  The vendor’s assertion is that traditional methods and means of identifying security breaches (and by proxy IOCs) is no longer effective and thus requires a new approach.  So far, I agree there are things that need to change and change for the better but let’s continue and see what else they say prior to commenting more on the merits or shortcomings of the proposed standard. They further assert that simple signatures are too easy for aggressors to evade and circumvent (something I agree with and that most of more savvy anti-malware / intrusion prevention organizations agree with as well).  Furthermore, they go on to assert that through the use of the framework described in the standard an organization will have the most advanced threat detection capability available.  A bold claim if I may so myself.   Not surprising given that this is a vendor sponsored standard (I can’t blame them in all honesty).

In order to gain access to the tools and schema written in XML as we described above, an potentially interested organization must download them from the vendor site.  At which point, providing the schema and the standard meet the needs of the organization, they are free to use them at their discretion.  The schema will enable the user to describe in detail, approximately 500 attributes that can be used to sleuth out attackers that have been vetted through the vendor’s experiences in incident response.

Net Effect

The OpenIOC is intriguing due to its highly extensible, well vetted for IOC development and customization of IOCs for organizations of varying size and industry vertical.  Potential downside being that it is a vendor sponsored and largely driven though it endorses a “community” driven look and feel.  For some organizations, this will be the ‘achilles heal’ in the selection process.

Coming Soon!

In the next installment we’ll discuss the IETF IODEF (aka RFC 5070) standard and what it offers in comparison to CyBox and the OpenIOC initiative.

• 

Introduction

Every day security analysts are faced with piecing together disparate parts of complex events of interest related to emerging and sophisticated threats.  These pieces can be simple metadata elements or much more complex malicious code and content samples that require advanced reverse engineering and analysis.  When pulled together, the cumulative result equates to what we refer to as Indicators of Compromise (IOC).  For many, IOCs are foreign in nature and concept.  For security analysts, they should be familiar if not well known as a concept.  In this blog series we’ll explore IOCs and their importance to the successful assessment of threat conditions facing security analysts and enterprises every day.

One Size Doesn’t Fit All

To begin with, let’s define the term Indicator of Compromise.  Simply put, an IOC is a forensic artifact or remnant of an intrusion that can be identified on a host or network.  Pretty straight forward right? Let’s keep reading.  IOCs tie to observables and observables tie to measurable events or stateful properties which can represent anything from the creation of a registry key on a host (measurable event) to the presence of a mutex (stateful property).  Though not present in all incident response or event of interest scenarios, IOCs are present more often than not should the security analyst devote enough time, energy and resources in learning where and how to identify them.  The ability for a security analyst, incident responder or threat researcher to collect, record and notate IOCs in a detailed manner cannot be stressed enough.  To be able demonstrate the Who, What, Where, When, How and (assuming one has enough data the ‘Why’) is invaluable!  Today there are several emerging, would be standards for what has previously been an individualistic at worst and organizational at best approach to demonstrating IOCs.

My Way, Your Way Any IOC Standard Tonight

Though there are many would be standards related to IOCs making waves in the industry today we’ll spend some time looking at what promise to be the three leading contenders.  The first, CyBox which according to its website provides “…a standardized schema for the specification, capture, characterization and communication of events or stateful properties that are observable in the operational domain. A wide variety of high-level cyber security use cases rely on such information including: event management/logging, malware characterization, intrusion detection, incident response/management, attack pattern characterization, etc. CybOX provides a common mechanism (structure and content) for addressing cyber observables across and among this full range of use cases improving consistency, efficiency, interoperability and overall situational awareness.”  The fine folks at Mitre are responsible for CyBox and it happens to be a personal favorite of mine.  Is it perfect? That depends on your needs and wants.  I like a lot about the way in which CyBox approaches observables and properties additionally and perhaps more important than those two fundamental aspects of their approach is their integrated approach to disparate domains of interest such as:

• Threat assessment and characterization (detailed attack patterns)
• Malware characterization
• Operational event management Logging
• Cyber situational awareness
• Incident response
• Forensics
• ETC.

In the second installment we’ll discuss the OpenIOC initiative, the IODEF (RFC5070) initiative sponsored by the IETF and the best way to select a framework that suits your needs.

• 

One of my favorite Latin sayings was one that was considered common during the height of the Roman Empire.   In pace, ut sapiens, aptarit idonea bello or for those of you who do not speak Latin: In peace, like a wise man, he appropriately prepares for war.  Many information security professionals laugh and roll their eyes at comparisons made to ancient military texts (Western or Eastern alike) yet, there is something that strikes me as being invaluable in adopting these concepts and applying them to all scenarios where in conflict may result.  Tell me where in life you can find a scenario that may not result in some form of conflict?

Ok, good we are on the same sheet of music.  It is an act of wisdom to be prepared during peace so that when the time comes and duty calls, you and your compatriots are prepared mentally, physically and emotionally.  This is an idea that is as old as time and yet we somehow dismiss it as being an inappropriate one relegated solely for the armed forces and in no way applicable to the day to day walk that the average security analyst takes in his or her life.  How much more wrong could we be?  Leaders lead from the front; not the rear.   As such, we have an obligation to prepare ourselves and our ranks for the conflict during times of peace because we know it will come.  And when it comes (and yes, it will come) we will want to know that our peers and ourselves are prepared having taken the time to understand our strengths, weaknesses, affiliations, population behaviors and much more.  We will want to know that our active defense is an intense defense. That the mere mention of a campaign sees us scramble into position not out of fear, but out of obligation and duty to protect that which we have been chartered to protect (whatever that may be to your individual enterprise).

Deeds, Not Words

Leaders (Managers, Directors, VPs, CISOs/CSOs, and CIOs etc.) you have an obligation to lead.  To instill confidence and ensure that your subordinates — and that which you have been tasked or chartered to protect remains protected is your responsibility.  It is your duty and one you should not take lightly.  Additionally, you cannot hope to defend against or defeat a determined, sophisticated threat actor if you do not know yourself and your environment.  If you do not understand in detail your environment and your user population how can you possibly hope to engage an adversarial opponent?  Enterprises in today’s world simply do not have the luxury of sitting idly by watching the world from behind their NAT’d IP or Proxy’d IP address space hoping that no one takes note of their existence.  Long dead are the days when security via obscurity was an effective model (provided you believed it was effective to begin with).  No. Today’s world is a world where clear and present dangers face our work force populations on a daily, hourly and sub-hourly basis.  It is a world of instant communication and imminent threat.  Your organization must (regardless of its size or prominence) take an active approach to its threat mitigation.  Passivity invites detriment.

There are ample examples that we could cite (but for the sake of time will not) over the last ten years which demonstrate that unequivocally. Your first step in establishing a solid defense is conditioning a sense of involuntary reaction anchored in hard training.  This involuntary reaction must be conditioned beyond the point of reason; it must become as natural as protecting oneself from being struck by a moving object.  It is dependent upon the simulation and study of scenarios that exhibit a comparable model of reality to the one in which you, your peers and your user population exist in on a daily basis; year in and year out.  For information security professionals, this should resonate deeply.  If you find yourself in a position of authority today you must consider the consequence of not acting with vigor.  The cost could be astounding and damage irreparable and the lessons frightening.  It doesn’t have to be that way!

• 

As part of routine security research, the RSA Advanced Threat Intelligence Team identified a new hacking attack this week that uses a technique that we’ve termed “Watering Hole”.

In the new attack we’ve identified, which we are calling “VOHO”, the methodology relies on “trojanizing” legitimate websites specific to a geographic area which the attacker believes will be visited by end users who belong to the organization they wish to penetrate.   This results in a wholesale compromise of multiple hosts inside a corporate network as the end-users go about their daily business, much like a lion will lie in wait to ambush prey at a watering hole.

The details of the attack are still developing, but what we are aware of so far is as follows:

1. The victim visits a compromised “watering hole” website
2. This website, through an injected JavaScript element, redirects the visiting browser to an exploit site.
3. This exploit site checks that the visiting machine is running a Windows operating system and a version of Internet Explorer, and then exploits the Java client on the visiting host, installing a “gh0st RAT” variant.

Gh0st RAT is a commonly observed Remote Access Trojan that historically has been used by APT attacker groups to perform surveillance and intelligence collection inside networks of interest.  This particular type of operation was documented nicely in the Infowar Monitor’s paper, “Tracking GhostNet”.

Among other capabilities, the gh0st RAT malware has the ability to surreptitiously operate the webcams and microphones on compromised PCs.

Emerging Details:

In the VOHO campaign, the attacker compromised, likely through stolen FTP credentials, a number of legitimate websites.  These websites generally served two geographic areas:

• Massachusetts
• Washington, DC

These legitimate websites are geared around commonly accessed services in these industry verticals:

• Financial Services
• Technology Services

Based on our initial analysis of server logs, this attack caused approximately 32,000 individual hosts to visit the attack site, inside over 4,000 unique organizations worldwide and across multiple industry verticals including:

• State and Federal Government
• Educational Institutions
• Defense Industrial Base
• Technology

If successfully compromised the gh0st RAT variant on the infected PC checks into a C2 site at: 58.64.155.59, an IP address located in China.   This IP address has not historically been observed to be involved in malicious activity.

Communication occurs over ports 80, 443, and 53 and initial communication can be recognized via the presence of the string “HTTPS” in the initial payload, although the traffic is not valid HTTPS traffic.

While RSA’s efforts for this investigation are ongoing, individuals and organizations can determine their potential involvement in this attack by looking for traffic to either: 58.64.155.59 (which would originate from a compromised machine) or  Torontocurling.com (which would originate from a machine going through the exploit system).

More information to come!

The RSA Advanced Threat Intelligence Team is a research and analysis organization focused on emerging, sophisticated threats globally.  The RSA team is made up of Principal Researcher Alex Cox; Principal Technologist Jon McNeil; and Consulting Security Engineer Chris Harrington. The team is led by RSA Senior Threat Research and Intelligence Manager Will Gragido.

•