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. 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 126.96.36.199/16 or 188.8.131.52/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.
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
http://yaiaqf3te6khr3nd.onion/ – This sites has 3 different sites in one – 3 index front pages-DOORS - fUnNy nO?
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
http://184.108.40.206/ IP Address:
http://220.127.116.11/ IP Address:
http://18.104.22.168/ IP Address:
http://22.214.171.124/ IP Address:
126.96.36.199 ISP: Region: Harbin (CN)
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.
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
- 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
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.
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…
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)
- fe0-0.bbr1.bahar.kimianet.irIran (Karaj)
- gi0-1.thr-001-core-1.ctel.ir Iran (Tehran)
- router1.iust.ac.irIran (Tehran)
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
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’s 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.
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.
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
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
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.
Internet Crime Complaint Center
2600: The Hacker Quarterly
US-Cert Technical Alert & Bulletins
US-Cert National Cyber Alert System
US-Cert National Cyber Alert System
US-Cert Cyber Security Tips
The Dark Visitor -inside the World of Chinese Hackers
Security Global – http://global-security.blogspot.com/