07/30/14

Tor Traffic Confirmation Attack

Tor Traffic Confirmation Attack -Roger Dingledine Report
SUMMARY:
  On July 4 2014 we found a group of relays that we assume were trying
  to deanonymize users. They appear to have been targeting people who
  operate or access Tor hidden services. The attack involved modifying
  Tor protocol headers to do traffic confirmation attacks.gato_signal_02

  The attacking relays joined the network on January 30 2014, and we
  removed them from the network on July 4. While we don't know when they
  started doing the attack, users who operated or accessed hidden services
  from early February through July 4 should assume they were affected.

  Unfortunately, it's still unclear what "affected" includes. We know
  the attack looked for users who fetched hidden service descriptors,
  but the attackers likely were not able to see any application-level
  traffic (e.g. what pages were loaded or even whether users visited
  the hidden service they looked up). The attack probably also tried to
  learn who published hidden service descriptors, which would allow the
  attackers to learn the location of that hidden service. In theory the
  attack could also be used to link users to their destinations on normal
  Tor circuits too, but we found no evidence that the attackers operated
  any exit relays, making this attack less likely. And finally, we don't
  know how much data the attackers kept, and due to the way the attack
  was deployed (more details below), their protocol header modifications
  might have aided other attackers in deanonymizing users too.

  Relays should upgrade to a recent Tor release (0.2.4.23 or
  0.2.5.6-alpha), to close the particular protocol vulnerability the
  attackers used -- but remember that preventing traffic confirmation in
  general remains an open research problem. Clients that upgrade (once
  new Tor Browser releases are ready) will take another step towards
  limiting the number of entry guards that are in a position to see
  their traffic, thus reducing the damage from future attacks like this
  one. Hidden service operators should consider changing the location of
  their hidden service.

THE TECHNICAL DETAILS:
  We believe they used a combination of two classes of attacks: a traffic
  confirmation attack and a Sybil attack.

  A traffic confirmation attack is possible when the attacker controls
  or observes the relays on both ends of a Tor circuit and then compares
  traffic timing, volume, or other characteristics to conclude that the
  two relays are indeed on the same circuit. If the first relay in the
  circuit (called the "entry guard") knows the IP address of the user,
  and the last relay in the circuit knows the resource or destination
  she is accessing, then together they can deanonymize her. You can read
  more about traffic confirmation attacks, including pointers to many
  research papers, at this blog post from 2009:
  https://blog.torproject.org/blog/one-cell-enough

  The particular confirmation attack they used was an active attack where
  the relay on one end injects a signal into the Tor protocol headers,
  and then the relay on the other end reads the signal. These attacking
  relays were stable enough to get the HSDir ("suitable for hidden
  service directory") and Guard ("suitable for being an entry guard")
  consensus flags:
  https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1775
  Then they injected the signal whenever they were used as a hidden
  service directory, and looked for an injected signal whenever they
  were used as an entry guard.

  The way they injected the signal was by sending sequences of "relay"
  vs "relay early" commands down the circuit, to encode the message they
  want to send. For background, Tor has two types of cells: link cells,
  which are intended for the adjacent relay in the circuit, and relay
  cells, which are passed to the other end of the circuit.
  https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt#l364
  In 2008 we added a new kind of relay cell, called a "relay early"
  cell, which is used to prevent people from building very long paths
  in the Tor network (very long paths can be used to induce congestion
  and aid in breaking anonymity):
  http://freehaven.net/anonbib/#congestion-longpaths
  https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/110-avoid-infinite-circuits.txt
  But the fix for infinite-length paths introduced a problem with
  accessing hidden services:
  https://trac.torproject.org/projects/tor/ticket/1038
  and one of the side effects of our fix for bug 1038 was that while
  we limit the number of outbound (away from the client) "relay early"
  cells on a circuit, we don't limit the number of inbound (towards the
  client) relay early cells:
  https://lists.torproject.org/pipermail/tor-commits/2009-July/014679.html

  So in summary, when Tor clients contacted an attacking
  relay in its role as a Hidden Service Directory to publish
  or retrieve a hidden service descriptor (steps 2 and 3 on
  https://www.torproject.org/docs/hidden-services), that relay would
  send the hidden service name (encoded as a pattern of relay and
  relay-early cells) back down the circuit. Other attacking relays,
  when they get chosen for the first hop of a circuit, would look for
  inbound relay-early cells (since nobody else sends them) and would
  thus learn which clients requested information about a hidden service.

  There are three important points about this attack:

  A) The attacker encoded the name of the hidden service in the injected
  signal (as opposed to, say, sending a random number and keeping a local
  list mapping random number to hidden service name). The encoded signal
  is encrypted as it is sent over the TLS channel between relays. However,
  this signal would be easy to read and interpret by anybody who runs
  a relay and receives the encoded traffic. And we might also worry
  about a global adversary (e.g. a large intelligence agency) that
  records Internet traffic at the entry guards and then tries to break
  Tor's link encryption. The way this attack was performed weakens Tor's
  anonymity against these other potential attackers too -- either while
  it was happening or after the fact if they have traffic logs. So if
  the attack was a research project (i.e. not intentionally malicious),
  it was deployed in an irresponsible way because it puts users at risk
  indefinitely into the future.

  (This concern is in addition to the general issue that it's probably
  unwise from a legal perspective for researchers to attack real users
  by modifying their traffic on one end and wiretapping it on the
  other. Tools like Shadow are great for testing Tor research ideas out
  in the lab: http://shadow.github.io/ )

  B) This protocol header signal injection attack is actually pretty neat
  from a research perspective, in that it's a bit different from previous
  tagging attacks which targeted the application-level payload. Previous
  tagging attacks modified the payload at the entry guard, and then
  looked for a modified payload at the exit relay (which can see the
  decrypted payload). Those attacks don't work in the other direction
  (from the exit relay back towards the client), because the payload
  is still encrypted at the entry guard. But because this new approach
  modifies ("tags") the cell headers rather than the payload, every
  relay in the path can see the tag.

  C) We should remind readers that while this particular variant of
  the traffic confirmation attack allows high-confidence and efficient
  correlation, the general class of passive (statistical) traffic
  confirmation attacks remains unsolved and would likely have worked
  just fine here. So the good news is traffic confirmation attacks
  aren't new or surprising, but the bad news is that they still work. See
  https://blog.torproject.org/blog/one-cell-enough for more discussion.

  Then the second class of attack they used, in conjunction with their
  traffic confirmation attack, was a standard Sybil attack -- they
  signed up around 115 fast non-exit relays, all running on 50.7.0.0/16
  or 204.45.0.0/16. Together these relays summed to about 6.4% of the
  Guard capacity in the network. Then, in part because of our current
  guard rotation parameters:
  https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters
  these relays became entry guards for a significant chunk of users over
  their five months of operation.

  We actually noticed these relays when they joined the network, since
  the DocTor scanner reported them:
  https://lists.torproject.org/pipermail/tor-consensus-health/2014-January/004134.html
  https://gitweb.torproject.org/doctor.git
  We considered the set of new relays at the time, and made a decision
  that it wasn't that large a fraction of the network. It's clear there's
  room for improvement in terms of how to let the Tor network grow while
  also ensuring we maintain social connections with the operators of all
  large groups of relays. (In general having a widely diverse set of relay
  locations and relay operators, yet not allowing any bad relays in,
  seems like a hard problem; on the other hand our detection scripts did
  notice them in this case, so there's hope for a better solution here.)

  In response, we've taken the following short-term steps:

  1) Removed the attacking relays from the network.
  2) Put out a software update for relays to prevent "relay early" cells
     from being used this way.
  3) Put out a software update that will (once enough clients have
     upgraded) let us tell clients to move to using one entry guard
     rather than three, to reduce exposure to relays over time.
  4) Clients can tell whether they've received a relay or relay-cell.
     For expert users, the new Tor version warns you in your logs if
     a relay on your path injects any relay-early cells: look for the
     phrase "Received an inbound RELAY_EARLY cell".

  The following longer-term research areas remain:

  5) Further growing the Tor network and diversity of relay operators,
     which will reduce the impact from an adversary of a given size.
  6) Exploring better mechanisms, e.g. social connections, to limit the
     impact from a malicious set of relays. We've also formed a group to
     pay more attention to suspicious relays in the network:
     https://blog.torproject.org/blog/how-report-bad-relays
  7) Further reducing exposure to guards over time, perhaps by extending
     the guard rotation lifetime:
     https://blog.torproject.org/blog/lifecycle-of-a-new-relay
     https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters
  8) Better understanding statistical traffic correlation attacks and
     whether padding or other approaches can mitigate them.
  9) Improving the hidden service design, including making it harder
     for relays serving as hidden service directory points to learn what
     hidden service address they're handling:
     https://blog.torproject.org/blog/hidden-services-need-some-love

OPEN QUESTIONS:
  Q1) Was this the Black Hat 2014 talk that got canceled recently?
  Q2) Did we find all the malicious relays?
  Q3) Did the malicious relays inject the signal at any points besides
      the HSDir position?
  Q4) What data did the attackers keep, and are they going to destroy it?
      How have they protected the data (if any) while storing it?

  Great questions. We spent several months trying to extract information
  from the researchers who were going to give the Black Hat talk, and
  eventually we did get some hints from them about how "relay early"
  cells could be used for traffic confirmation attacks, which is how
  we started looking for the attacks in the wild. They haven't answered
  our emails lately, so we don't know for sure, but it seems likely that
  the answer to Q1 is "yes". In fact, we hope they *were* the ones doing
  the attacks, since otherwise it means somebody else was. We don't yet
  know the answers to Q2, Q3, or Q4.
06/22/13

China Hackers found in Tor

China Hackers found in Tor

gAtO bEeN crawling - Tor and found China — China, Fujian IP found in Tor but is it really the Chinese or someone else. As I work on the Tor-Directory-Project to map out every URL in Tor. I came to these site

Anonetchina-computer-hac_1963116c

http://yaiaqf3te6khr3nd.onion/ – This sites has 3 different sites in one – 3 index front pages-DOORS - fUnNy nO?

http://lw7b7t7n7koyi6tb.onion

Now what’s so weird about these 2 sites 4 IP address on the site for proxies and Tor in CHINA.  This ain’t right, China does it’s best to block Tor and keep it’s citizens away from Tor so why would a website in Tor place these explicit IP address and telling you to use them.  In Tor you try to hide not give IP out that can be traced, so why is this different???

So I back trace these 4 sites 3 in China 1 is Soul,Korea, then you google “Fujian Providence hacking”

Yeah there are a lot of things happening in that part of China but is it really the Chinese or others. Russians maybe??

These 2 sites are linked to “Anonet” the funny (ha ha) thing is this one person that keeps popping up – (Anonymous Coward ) on both these sites-  and he/she leads back to China too mAyBe -Si-nO. The Chinese use the Anonymous Coward to mock Anonymous which are very dangerous in China but this does not look good folks.

We talk about China hacking us and when people like myself find these sites and try to report them  – no way- I’m just a nobody that has one of the largest Tor search engines around. Just from these 2 sites I have 56 URL’s – Maybe one of these cyber Professional should check these 2 sites out – I have a subscription service for Tor Search engine any governments or law enforcement out there that need this — talk to gAtO—

They may find one source of China Hacking the US and other places – gAtO oUt

Chinanet Fujian Province Network

http://1.1.7.10/  IP Address:

Chinanet Fujian Province Network

http://1.1.7.7/  IP Address:

Chinanet Fujian Province Network

http://1.234.56.4/  IP Address:

1.234.56.4  ISP: SK Broadband Co Ltd Region:

Seoul (KR)

http://1.56.75.16/  IP Address:

China Unicom Heilongjiang Province Network

1.56.75.16  ISP: Region: Harbin (CN)

04/5/13

Tor Tells It’s Secrets

gAtO pLaYiNg with words in Tor- We just simply counted the number of times a word appeared in our search engine by pages- this is something every search engine does but what it gave us was a picture of what Tor really is. It’s not all crime and ugly but information is number one in Tor. Exactly what it’s supposed to be. Tor was created to share information from the table below we see lot’s of stuff inside Tor.output

Tor word data points: We put this report together to see what our word count occurrence was, in our crawled data so far. The chart below gives an interesting picture of the Tor data points that it generates.

We are finding that these are the best categories to put our websites into. The words by site occurrence speaks volumes to understand trends in Tor.  For example it shows i2p network in Tor 2 notices above drugs in Tor. Because i2p is fast being intwined with Tor to get better anonymity.

  • These are real data point based on 3/27/2013-4/3/2013 – this is a live report from our crawls.
  • As we crawl and add more data our picture will change as to the landscape of Tor. 
  • Bitcoins is the fourth most popular word – currency in the Dark Web is number 1  

Word Num. Occurrences
blog 1014
wiki 985
anonymous 966
bitcoin 837
sex 530
gun 492
market 458
I2P 400
software 372
drugs 365
child 353
pedo 321
hacking 314
weapon 221
politic 209
books 157
exploit 118
anarchism 105
porno 88
baby 87
CP 83
fraud 76
piracy 69

 

  • Bitcoins are above SEX tell us volumes in that bit coins are the normal exchange currency in Tor.
  • Fraud and piracy are the lowest were we would except it to be much higher, People trust more in Tor.

This map does tell us that crime is everywhere in Tor at a more alarming rate than we though.

We are doing the same in the e-mail we found in Tor. In the email table is a place where we can get a better picture of emails in the Tor network. Not all of them go to tormail.org as we thought. As mentioned more i2p and connections with other anonymous networks seems to be a trend, as the growth rate of Tor users increase so is the technical base and more sophisticated users will come on board.

Hope this gives you a better picture of Tor. -gAtO oUt

03/10/13

Finding the Bad Guy’s in Tor -triangulated irregular network

gAtO ThInKiNg - a car GPS works very simple, It takes the delay time from one geo-positioned satellite and compares is to another geo-positional satellite and estimates the position of the GPS in my CAR – I think they call it satellite triangulation or something cool, it’s been done with radios to guide pilots navigate ever since they developed radios. We do it with satellite and we can use networks too.

triangulated irregular network  -So now apply this to the Tor bad guy’s websites- a hidden service!math_clouadTag

With a simple command you can get the time it takes to crawl a website, so you have one server in the U.S one is South America, one in Europe and one in Asia and we run the same command getting the delays from each location. I bet with a little math and some basic network tools we could figure out the geo-location of any given website in Tor. One of my good mentors told me that in my crawls I was capturing timing information, we all see timing information with a simple ping command in the clear web but in Tor – UDP is unsupported so it does not work -//- we must take into account the Tor network thru-put and utilization bit that’s easy to get from a number of Tor tools.

Reverse triangulation of a network server should be easy to find with a little math, just take a good sample and the longer you wait the more data you collect and the better the chance you can find a geo-location of a website. We do this in the clear web all the time we can see bad areas of the world that are bad spammers, and other like mail from Africa Prince Scams offering you millions if you send them some money to cover the transfer, or Russian and Chinese phishing attacks. So we know geo-location and some IP are more prime to bad actors and we can draw a profile, a geo-location of a place and/or  country or an ISP so not having the IP of a Tor server may not be neededto find them we could use network triangulation. “triangulated irregular network  ” So the same thing can be done with networks and timing delays of data back and forth from a // client <–> Tor OR <–>server.

I got a crazy Idea that may or may-not work, but it sounds good—//  so— Now if I can only find a government grant and a good math major to help out and we have a big business model to find the bad guy’s geo-location even in Tor - gAtO oUt…

02/3/13

Offensive Cyber Capabilities

Companies Need Offensive Cyber Capabilities

gAtO hEaR - about banks seek U.S Help on Iran Cyberattack’s. We hear about cyber attacks in the financial sector, the oil and energy sectors, then Leon Panetta warned perpetrators to cease hacking the US while we have all kinds of sanctions against Iran -/ this is insanity. Your telling unknown hackers (we suspected Iran) to  just stop, or what. What can we do to prevent them from launching cyber attacks against America.

So Iran has only 3 NAT-access points and 1 submarine cable (Al-Faw, Iraq submarine cable)

 

Then you have all these security people putting up defenses without building a firewall so bad-ass that they cannot do business. If we keep building these defenses it will get to a point where it defeats the purpose of the Internet. So what is the logical next move, offensive cyber weapons and capabilities. We can find these attacks and pinpoint the IP of where they are coming from then all we need is offensive tools to find them and do a seal-team 6 extraction of something like that and get the word out that we will find you and hunt you down.

One little hacker can keep a bank tied up for days in the middle of the desert. They could go after our traffic system, our rail system we know that SCADA is so messed up and in some cases open with defaults passwords. So we beat our chest like some mad gorilla and hope to scare these hackers.

My friends we must take initiative and find ways to counter these attacks no more just defense and I don’t mean a Ddos attack that can be circumvented. We need to plant Bot-nets on these people’s machines and monitor them and if we have to go physical and bring them to justice. Forget about Iran and let’s just talk about Chinese hacker attacks of our intellectual property. They just denied it and go about planning the next attack. We seen Skynet were thousands of computers were given a disk wipe and the blue screen of death. Why don’t we do the same to these hackers going after our infrastructure.

We must change our tactics and be a little more aggressive and become real cyber warriors not just defenders but attacking them and destroying their machines, their servers and routers. How about we just monitor the 1 submarine cable and 3 access points in Iran that should lead us to some of these people. The US monitors our own people then we stand by and allow other hostile countries to go and hack us. This is cyber insanity - gAtO OuT

 

10/21/11

Minimum Essential Security Controls – Is This a Joke?

For example, FISMA [has] over 200 minimum essential security controls. 27001, when linked to [ISO] 17799, [has] over 150 controls. HIPAA itself had 140-odd data and security and privacy requirements.

And the risk assessment is featured in the compliance mechanism for just that reason. An organization really has no choice but [to] attempt to tackle and implement all of the security and data requirements contained in HIPAA; whereas with a risk-based approach and focusing on the assets and what truly is important to the organization and doing that rack and stack, as you referred to it, [the organization] really only had to address the higher-priority risk items and could be in a position to accept the remaining risk or residual risk as it’suscyberlabs - el gatoMalo known, in a defensible way to say that, “We’ve covered our priority risks. Our budget limitations in terms of personnel and funding prevent us perhaps from implementing some of these controls that are contained within the compliance mechanism. But because we have gone through a complete risk assessment process, have captured the results in a defensible form, that’s okay.” That’s the basis of risk mitigation. It’s not risk elimination — get rid of all of them — but consider them in a prioritized fashion against what the constraints and limitations of the organization are.

http://www.cert.org/podcast/mp3/2/clips/20071113wilson1.mp3

01/21/11

CERN The Path from Information Security Risk Assessment to Compliance

The Path from Information Security Risk Assessment to Compliance

Key Message: Information security risk assessment, performed in concert with operational risk management, can contribute to compliance as an outcome.

Executive Summary

Information security risk assessment is a key practice for identifying and prioritizing security risks to critical information assets and key business processes. Determining which security controls mitigate key risks, for both business and compliance purposes, can only be determined through a continuous risk management process. Conducting security risk assessment in concert with operational risk assessment ensures that security risk identification and mitigation are determined based on impact to the business.

In this podcast, Bill Wilson, manager of CERT’s Survivable Enterprise Management team, provides guidelines on how business leaders can use risk assessment as an effective tool for achieving compliance.

PART 1: ASSESSING SECURITY RISK IN A BUSINESS CONTEXT

Why Is Risk Assessment Relevant and Important for Information Security?

Risk assessment allows us to put information security issues in a business context, better understanding the impact to the business in the event of a security breach.

This allows leaders to better answer the “So what?” test, not in technology or security incident terms, but in terms of lost productivity, lost revenue, and potential business interruption – in other words, operational risk.

Leaders can then analyze and prioritize security risks in the context of all other operational risks, using business language and measures of effectiveness.

How Can Risk Assessment Be Used to Prioritize Compliance Requirements?

Current risk-based regulations and standards that call for security controls include:

  • FISMA (Federal Information Security Management Act) for federal and civilian agencies
  • ISO 27001 (in concert with ISO 17799, now ISO 27002)
  • HIPAA (Health Insurance Portability and Accounting Act)
  • ITIL (Information Technology Infrastructure Library)
  • COBIT (Control Objectives for Information and related Technology)
  • COSO (Committee of Sponsoring Organizations of the Treadway Commission)

All of these have many controls and requirements. How does an organization select which ones are most applicable and most important? And which ones can be justifiably eliminated from consideration?

Risk assessment provides an approach for ranking and stacking which security controls to implement, in a business context. It is generally accepted during a compliance review as a defensible basis for control selection and elimination.

An organization can state “We’ve covered our priority risks. Our budget limitations prevent us from implementing some controls. But because we’ve gone through a complete risk assessment process and have captured the results in a defensible form, that’s okay.” What then remains is for a business leader to manage and track any residual risks.

This approach provides a strong basis for making security investment decisions.

PART 2: ZEROING IN ON A RISK ASSESSMENT METHOD

Examples of Common and Widely Accepted Methods for Assessing Information Security Risk

  • NIST SP 800-30 Risk Management Guide for Information Technology Systems
  • BSI 7799-3 (soon to become ISO 27003)
  • CRAMM (CCTA (Central Computer and Telecommunications Agency) Risk Analysis and Method Management) – a qualitative risk analysis and management tool originally developed by the UK government
  • MEHARI (Méthode Harmonisée d’Analyse de Risques Informatiques)
  • FRAP (Facilitated Risk Analysis Process)
  • OCTAVE (Operationally Critical Threat, Asset, and Vulnerability Evaluation)

Selecting a Useful Method

Consider available case studies, experience reports, and comparisons.

Find one that is most compatible with your organization’s operational risk management process, risk criteria, language for assessing risk, and how risk data is typically analyzed and presented.

Make sure to integrate security risk tradeoffs with other organizational risks.

Key Elements of an Effective Security Risk Assessment Approach

Choose a method that recognizes its placement in the risk management and security management life cycles.

  • As a diagnostic, to generate information for decision making and control selection

Follow through – make sure control implementation is managed and tracked over time.

Ensure that risk assessments are part of a continuous risk management process/cycle, and conducted periodically or as events warrant.

Treat security risk assessment as part of operational risk assessment and management.

Recognize that most methods in use today are qualitative but progress is being made in determining quantitative losses and impacts.

Focus more on impact and loss, and less on threat and vulnerability which are constantly shifting and changing. At the core of any risk-based approach is “What’s important, and why do I care?”

PART 3: BUILDING A RISK-BASED COMPLIANCE PROGRAM

The Steps

Select an approach, using the guidelines we’ve covered.

Determine the scope of the assessment (typically a business unit or a selected set of business processes). It is important to bound the information assets and systems of interest, keeping this manageable.

Focus on the most critical assets first.

Select a multi-disciplinary team, including members outside of IT to represent the business/mission perspective and characterize the business impacts.

Perform preliminary analysis and present this to senior decision makers for action.

Make sure there is a well-defined connection to existing operational risk management activities, be it a risk committee or perhaps through internal audit.

Fund and implement risk mitigation controls.

Provide oversight and monitoring to ensure that controls are implemented correctly and are truly reducing risk.

Understand the relationship between risk assessment and compliance: It’s not “I’m doing risk assessment to comply with regulation X” but “I’m doing risk assessment because its effective practice.” Properly performed risk assessment will often result in compliance as an outcome or byproduct.

Challenges to Anticipate and Address

  • Lack of patience – risk assessment takes time to collect information, interact with stakeholders, and conduct analysis.
  • Rushing to solution mode – this will often happen as problems that need immediate attention are discovered along the way. This can cause the team and the organization to lose sight of the larger goal.
  • Insufficient time spent on characterizing true impact – work with your business continuity and disaster recovery staff.
  • The absence of well-defined risk evaluation criteria
  • Failure to involve business line personnel, including the owners of critical information assets and key business processes

http://www.cert.org/podcast/notes/20071113wilson-notes.html

12/1/10

APT-Advanced Persistent Threats- the slow hack is the WORST

………

Advanced Persistent Threats (APT)

What’s an APT? A Brief Definition

Advanced Persistent Threats (APTs) are a cybercrime category directed at business and political targets. APTs require a high degree of stealithiness over a prolonged duration of operation in order to be successful. The attack objectives therefore typically extend beyond immediate financial gain, and compromised systems continue to be of service even after key systems have been breached and initial goals reached.

Definitions of precisely what an APT is can vary widely, but can best be summarized by their named requirements:

Advanced – Criminal operators behind the threat utilize the full spectrum of computer intrusion technologies and techniques. While individual components of the attack may not be classed as particularly “advanced” (e.g. malware components generated from commonly available DIY construction kits, or the use of easily procured exploit materials), their operators can typically access and develop more advanced tools as required. They combine multiple attack methodologies and tools in order to reach and compromise their target.

Persistent – Criminal operators give priority to a specific task, rather than opportunistically seeking immediate financial gain. This distinction implies that the attackers are guided by external entities. The attack is conducted through continuous monitoring and interaction in order to achieve the defined objectives. It does not mean a barrage of constant attacks and malware updates. In fact, a “low-and-slow” approach is usually more successful.

Threat – means that there is a level of coordinated human involvement in the attack, rather than a mindless and automated piece of code. The criminal operators have a specific objective and are skilled, motivated, organized and well funded.

How Advanced Persistent Threats Breach Enterprises:

APTs breach enterprises through a wide variety of vectors, even in the presence of properly designed and maintained defense-in-depth strategies:

  • Internet-based malware infection
  • Physical malware infection
  • External exploitation

Well funded APT adversaries do not necessarily need to breach perimeter security controls from an external perspective. They can, and often do, leverage “insider threat” and “trusted connection” vectors to access and compromise targeted systems. Well-funded APT adversaries do not necessarily need to breach perimeter security controls from an external perspective. They can, and often do, leverage “insider threat” and “trusted connection” vectors to access and compromise targeted systems.

Abuse and compromise of “trusted connections” is a key ingredient for many APTs. While the targeted organization may employ sophisticated technologies in order to prevent infection and compromise of their digital systems, criminal operators often tunnel in to an organization using the hijacked credentials of employees or business partners, or via less-secured remote offices. As such, almost any organization or remote site may fall victim to an APT and be utilized as a soft entry or information harvesting point.

A key requirement for APTs (as opposed to an “every day” botnet) is to remain invisible for as long as possible. As such, the criminal operators of APT technologies tend to focus on “low and slow” attacks – stealthily moving from one compromised host to the next, without generating regular or predictable network traffic – to hunt for their specific data or system objectives. Tremendous effort is invested to ensuresure that malicious actions cannot be observed by legitimate operators of the systems.

Malware is a key ingredient in successful APT operations. Modern “off-the-shelf” and commercial malware includes all of the features and functionality necessary to infect digital systems, hide from host-based detection systems, navigate networks, capture and extricate key data, provide video surveillance, along with silent and covert channels for remote control. If needed, APT operators can and will use custom developed malware tools to achieve specific objectives and harvest information from non-standard systems
.
At the very heart of every APT lies remote control functionality. Criminal operators rely upon this capability in order to navigate to specific hosts within target organizations, exploit and manipulate local systems, and gain continuous access to critical information.

If an APT cannot connect with its criminal operators, then it cannot transmit any intelligence it may have captured. In effect, it has been neutered. This characteristic  makes APTs appear as a sub-category of botnets.

While APT malware can remain stealthy at the host level, the network activity associated with remote control is more easily identified. As such, APT’s are most effectively identified, contained and disrupted at the network level.


11/22/10

Here are a few Security Links and Feeds

Exploits-Database GoogleHacking-DB
http://www.exploit-db.com/
DOD Sitemap
http://www.defense.gov/news/other.html

stuxnet
http://www.cnn.com/2010/TECH/web/11/17/stuxnet.virus/index.html?iref=allsearch

http://en.wikipedia.org/wiki/Stuxnet#cite_note-BBC-5

http://news.bbc.co.uk/2/hi/technology/7004750.stm

simens
http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo?=en&objid=43876783&caller=view

Rhode Island
http://isaca-ri.org/cms/

Internet Crime Complaint Center
http://www.ic3.gov/default.aspx

Anton Chuvakin Blog – “Security Warrior”

BankInfoSecurity.com RSS Syndication

Cyber Risk Reports

CNET News.com

CSOONLINE.com Feed – Articles

CyberCrime & Doing Time

Dancho Danchev’s Blog – Mind Streams of Information Security Knowledge

Secrecy News

FireEye Malware Intelligence Lab

F-Secure Antivirus Research Weblog

GovInfoSecurity.com Articles RSS Syndication

Naked Security – Sophos

Hack In The Box

Help Net Security – Vulnerabilities

honeyblog

Information Warfare Monitor

Security Central – Infoworld

Kaspersky.com / All News

HomeJARTRAN FEED

Krebs on Security

Malware Intelligence Blog

Mcaffe http://feeds.feedburner.com/McafeeAvertLabsBlog

Blog Central » George Kurtz

Metasploit

Microsoft Security Bulletins

Moreover Technologies – Computer security news

Network World on Security

NIST IT Security : News

PandaLabs Blog

PenTestIT

Russian Business Network (RBN)

Rootsecure.net – secnews

SANS Computer Forensic Investigations and Incident Response

SANS Information Security Reading Room

Schneier on Security

SearchSecurity: Network Security Tactics

SearchSecurity: Security Wire Daily News

SearchSecurity: Threat Monitor

Securelist / Blog

Security Database Tools Watch

SecurityTracker Vulnerability Headlines

Sophos latest virus and spyware detection

Sunbelt Blog
http://www.schneier.com/

DOD Media
http://www.dma.mil/dma_solicitations.shtml
2600: The Hacker Quarterly
rss feeds
feed://www.zone-h.org/rss/news
ZD-Net
http://feeds.feedburner.com/zdnetuk/news/security
US-Cert Technical Alert & Bulletins
feed://www.us-cert.gov/channels/techdocs.rdf
US-Cert National Cyber Alert System
feed://www.us-cert.gov/channels/cas.rdf
US-Cert National Cyber Alert System
feed://www.us-cert.gov/channels/cas.rdf
US-Cert Cyber Security Tips
feed://www.us-cert.gov/channels/tips.rdf
Trend Micro
http://feeds.trendmicro.com/Anti-MalwareBlog
The Dark Visitor -inside the World of Chinese Hackers
feed://www.thedarkvisitor.com/feed/

Security Global – http://global-security.blogspot.com/

Tenable Network Security
feed://blog.tenablesecurity.com/atom.xml
Anton Chuvakin Blog – “Security Warrior”
BankInfoSecurity.com RSS Syndication

http://taosecurity.blogspot.com/?http://ha.ckers.org/blog?http://www.gnucitizen.org/?

http://www.darknet.org.uk/?http://spylogic.net/?

http://www.liquidmatrix.org/blog/?

http://jeremiahgrossman.blogspot.com/ (a little light on good content lately imo)?http://www.theregister.co.uk/security/
http://www.planet-websecurity.org/
http://global-security.blogspot.com