×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Tools, Techniques, Procedures of the RSA Hackers Revealed

timothy posted more than 2 years ago | from the more-links-than-a-sausage-factory dept.

Botnet 54

An anonymous reader writes "Details of the tools, techniques and procedures used by the hackers behind the RSA security breach have been revealed in a research paper (PDF) published by Australian IT security company Command Five. The paper also, for the first time, explains links between the RSA hack and other major targeted attacks. This paper is a vendor-neutral must-read for any network defenders concerned by the hype surrounding 'Advanced Persistent Threats.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

54 comments

First? (-1)

Anonymous Coward | more than 2 years ago | (#39009635)

Seriously first??

PDF eh? (5, Funny)

checkitout (546879) | more than 2 years ago | (#39009687)

I think everyone is afraid to click on that link.

Re:PDF eh? (0)

martin-boundary (547041) | more than 2 years ago | (#39009719)

I think everyone is afraid to click on that link.

Yeah. Personally, if it turns out that it's ROT-13 encoded, I'm gonna freak out!

Re:PDF eh? (0)

Anonymous Coward | more than 2 years ago | (#39024883)

Its double ROT13

Re:PDF eh? (0)

Anonymous Coward | more than 2 years ago | (#39010709)

While I, too, have been around long enough to understand where you're coming from, Google Docs has had PDF import for years.

Re:PDF eh? (0)

Anonymous Coward | more than 2 years ago | (#39015985)

You mean because the PDF somehow becomes corrupted when (and only when) you reject cookies from their webserver?

Re:PDF eh? (0)

Anonymous Coward | more than 2 years ago | (#39016227)

Quick! Fetch the tinfoil hats!

An excellent summation. (5, Interesting)

Anonymous Coward | more than 2 years ago | (#39009699)

It was most interesting to see one antivirus lab take months longer than another to detect one of these rootkits -- and that the rootkit may have been out there for months longer than that.

We might be past the useful span of antivirus software at this point. The attacker has always had the upper hand, being able to train malware against existing antivirus software.

One piece of advice in there was to limit internal networks to using internal DNS. But it's smarter to go one step further. By determining which sites employees should visit and distributing a hosts file to all internal computers, a company can avoid the myriad risks of operating a DNS server. Then any outgoing DNS traffic can be detected by a savvy internalnet admin at the firewall, and the offending computers cleaned.

E-mail attachments also continue to be a problem. The secret of the pros is to set up a script in your favorite language to detect e-mails with attachments, and move the attachments from the e-mail to the IT account. Then, once a trained professional examines each attachment, safe files can be copied into the folders of the relevant employees, and an e-mail sent to them to let them know they're in the clear.

While good computer safety is complex, much of it can be automated or outsourced. But thankfully not all of it, am I right guys?

Re:An excellent summation. (1)

pntkl (2187764) | more than 2 years ago | (#39009741)

Maybe we should take the advice of Rector Mompesson, stop the cleanup, and burn it all! > : ) j/k

That should be done anyway. (4, Informative)

khasim (1285) | more than 2 years ago | (#39009821)

All internal systems should use the internal DNS server.
The firewalls should block any outgoing DNS queries from any systems (except the internal DNS servers).
The firewall logs should be checked each day for violations.
The internal DNS server logs should be checked each day for unusual activity.

Even if you cannot prevent your systems from being compromised you should be looking for the signs that they are compromised.

Re:That should be done anyway. (2)

jgrahn (181062) | more than 2 years ago | (#39009969)

All internal systems should use the internal DNS server. The firewalls should block any outgoing DNS queries from any systems (except the internal DNS servers). The firewall logs should be checked each day for violations. The internal DNS server logs should be checked each day for unusual activity.

Even if you cannot prevent your systems from being compromised you should be looking for the signs that they are compromised.

You mean the "insights" section on page 17 in the report. That part scared me. They also recommend blocking traffic from the network to address X unless it's preceded by a DNS query which resolves to X. Breaking IP in non-obvious ways (impossible to debug unless you have control over the firewalls) has pretty bad consequences too ...

Re:That should be done anyway. (3, Insightful)

Anonymous Coward | more than 2 years ago | (#39010473)

well obviously, they're just proving that research papers are an
excellent attack vector on folks who care about security and
implement security recommendations blindly.

Re:That should be done anyway. (1)

Cramer (69040) | more than 2 years ago | (#39025775)

That would break any cached lookups (which most OSes and applications have done for eons), local host file records (granted, they could be compromised), and access by direct IP address.

It's not a half bad idea for systems in hostile environments. The problem is... no firewall in existance can do this out of the box. (it could be rigged up for a few of them.)

Re:That should be done anyway. (0)

Anonymous Coward | more than 2 years ago | (#39026715)

The cache has to be populated from DNS at some point, meaning that there was a corresponding lookup. The problem is establishing a suitable timeframe within which the lookup can be remembered.

Even if no commercial firewall can currently protect the network in this way it doesn't mean that they shouldn't- it just means that the firewalls aren't capable of defending against modern threats. We can't adapt the threat to suit our defensive capabilities, but we can evolve our capabilities to meet the threat.

Re:That should be done anyway. (1)

Anonymous Coward | more than 2 years ago | (#39010417)

The firewall logs should be checked each day for violations.

I for one support this statement. It must be checked by a Unionized member of the Cisco Guild. We will have job security forever.

And you are an idiot (0)

Anonymous Coward | more than 2 years ago | (#39013061)

>I for one support this statement. It must be checked by a Unionized member of the Cisco Guild. We will have job security forever.

If you were not a first-rate idiot, you would know that regular inspection of firewall logs is indeed a key requirement of any vigilant security strategy. It does not matter whether that firewall is from Cisco, Checkpoint, Linux iptables or any other of probably 100 major systems of that kind.

But you as a super-jerk will surely believe that installing a virus scanner is sufficient and that windows users can safely run as root. Your kind of idiots blend in excellently into large multinational corpos like Lockmart or RSA security. Those which are fscked on a regular basis by anon and the chinese.

Re:That should be done anyway. (0)

Anonymous Coward | more than 2 years ago | (#39016063)

If you wish to check the logs every day, I suggest that you have some script summarize them for you. If you don't want to do all the coding yourself, you can get a tool such as Splunk or (possibly) OSSIM.

According to SANS, you should at least look at the top-x and the bottom-y (where x and y are arbitrary integers, but x=y=10 is good enough for my home network).

Re:An excellent summation. (1)

sociocapitalist (2471722) | more than 2 years ago | (#39010941)

Companies need to have two types of networks, one that connects to everything (ie Internet) with the normal security measures. One that connects to nothing outside the company in any way, and does not connect to the other network that connects to everything.

The internal network should host a minimum set of applications and databases that hold whatever is actually important to secure.

This doesn't do anything about CEOs who will sell company tech to boost their bonuses but it will make it more difficult for everyone else who wants to compromise proprietary information.

Re:An excellent summation. (0)

Anonymous Coward | more than 2 years ago | (#39012715)

Antivirus software is not that useful. Better use a system that is not vulnerable to viruses in the first place. Never used antivirus, never had virus trouble, had the machine on a public IP address since 1998...

There is only one vulnerable system - drop that and you'll be fine.

Re:An excellent summation. (1)

Dogers (446369) | more than 2 years ago | (#39012809)

My question is why do the client machines (heck, even servers) need direct unfettered internet access? Block everything outbound, use a proxy and you have control of it - especially if you have a proxy that can intercept SSL and runs AV.

Also, assuming Windows, you can lock down exactly what software is allowed to run. Don't have admin rights? Can't modify what can run, can't install new software, can't run malware.

Straight away you're far more secure.

Re:An excellent summation. (0)

Anonymous Coward | more than 2 years ago | (#39015049)

Certainly more secure, but absolutely not safe. Some of the malware described in this report is both virtual machine and proxy aware - meaning that it will scoot out through your proxy like it wasn't there. Proxies are only effective with a well maintained whitelist. A silver bullet AV vendor solution can't do this for you without being either too strict or too open for your particular business requirements and threat model.

Limiting admin rights is a good first step but privilege escalation exploits (particularly on Windows) and the ever present threat of a zero day mean that malware can install and run on your system even when it's locked down in this way.

Constant vigilance is required to make sure that infections are contained and controlled - they will never be eliminated.

Re:An excellent summation. (0)

Anonymous Coward | more than 2 years ago | (#39017067)

Also, assuming Windows, you can lock down exactly what software is allowed to run. Don't have admin rights? Can't modify what can run, can't install new software, can't run malware.

And then you end up paying a shit load of money for the IT guys to maintain the systems. If Windows forced programs to behave properly, it wouldn't be that big of an issue. But there is no end to the software which should happily run under user permission space but in practice requires some level of either Admin access or granted admin-level access for a few specific group areas. The end result is that even on a "well-secured" Windows system the actions of one user can adversely affect the others, and malware which normally would have been isolated to a single user gets spread to the others through shared directories.

But regardless of how the clients are setup, a strong network policy should at least mitigate the effects of an attack.

Whitney Houston found dead at age 48 (-1)

Anonymous Coward | more than 2 years ago | (#39009703)

Cause of death not known at this time. /. will always love you, Whitney. RIP.

Re:Whitney Houston found dead at age 48 (-1, Troll)

Anonymous Coward | more than 2 years ago | (#39009929)

who? oh that cokehead loudmouth ho that was popular for a brief few moments surrounding her 1 hit wonders, yea the world will morn another dipshit that offered nothing to the world other than a few radio plays

Not much about RSA (4, Informative)

Sarten-X (1102295) | more than 2 years ago | (#39009745)

The report details malware that connected to a particular control host, named alyac.org. The host was used in an attack on SK Communications. One particular piece of malware (the Murcy malware the paper describes) is indicated to have been used in the RSA attack.

The RSA connection is detailed in the paragraph of the report titled "Link To RSA Breach":

The majority of the known callback domains for Murcy malware were used in the March 2011 RSA breach. This suggests that the attackers responsible for the RSA breach also use the Murcy malware. Given that the malware is reportedly not in widespread use, the Chinese server communicating with ‘path.alyac.org’ may have been compromised by the same attackers responsible for the RSA breach

There's little else that's really information specifically about the RSA breach. Still a nice bit of information about malware, but it'd be nice if the summary mentioned SK Communications, since that's the paper's real focus.

Re:Not much about RSA (4, Insightful)

Anonymous Coward | more than 2 years ago | (#39009815)

The Murcy malware is apparently also linked by the protocol it uses ('IP2B') to the Night Dragon attacks and a family of malware called the 'Destory RAT'. The shared infrastructure and tools indicate that the same attackers responsible for the SK Communications hack were behind both the RSA hack and Sykipot malware; presumably we can conclude that the description of their "Techniques and Procedures" applies equally to all.

Re:Not much about RSA (1)

Sulphur (1548251) | more than 2 years ago | (#39010423)

The majority of the known callback domains for Murcy malware were used in the March 2011 RSA
breach. This suggests that the attackers responsible
for the RSA breach also use the Murcy malware.
Given that the malware is reportedly not in
widespread use, the Chinese server communicating
with ‘path.alyac.org’ may have been compromised by
the same attackers responsible for the RSA breach

A Chinese site hacked, is nothing sacred?

Silly q (1, Interesting)

AHuxley (892839) | more than 2 years ago | (#39009879)

But what is a "Financial IP address" wrt the chart on page 12? Most of the other data is an ip or domain?

Re:Silly q (1)

pntkl (2187764) | more than 2 years ago | (#39009905)

But what is a "Financial IP address" wrt the chart on page 12? Most of the other data is an ip or domain?

From page 16: "... an IP address allocated to a large US financial institution."

Re:Silly q (1)

AHuxley (892839) | more than 2 years ago | (#39010373)

Yes but what was its role?
Based on the lines was it watching, been watched, provided cover, been used to move funds, a drop off point for data on the move?

Re:Silly q (0)

Anonymous Coward | more than 2 years ago | (#39010385)

The domain 'todaygonever.com' pointed to the IP address. See page 16.

Not Necessarily Owned By That Institution (1)

65Galaxie (226184) | more than 2 years ago | (#39015043)

If you look at the whois record (http://whois.arin.net/rest/net/NET-75-100-117-112-1/pft), you'll see that it is indeed listed as owned by a financial institution -- at least, in theory. As they pointed out in the article, the attackers registered DNS names using look-alike credentials, so why not do the same with IP blocks? If you look closer at the above whois, you'll notice that ARIN has been unable to contact the Point of Contact who registered the IPs since 2 weeks after they were registered and the email address is not owned by said financial institution.

Thus, I would conclude that there is a high likelihood the IP registration was spoofed like they did with DNS entries.

What is the compromised computer running? (2)

dgharmon (2564621) | more than 2 years ago | (#39010403)

"the compromised computer communicating with âpath.alyac.orgâ(TM) is running Windows 2003 Server Web Edition, Service Pack 2 .. only computers running Windows XP were observed communicating with âpath.alyac.orgâ(TM)". Command and Control in the Fifth Domain [commandfive.com] , Feb 2012

Re:What is the compromised computer running? (1)

Anonymous Coward | more than 2 years ago | (#39010435)

The second statement appears to refer only to 'XShell' communications, when considered as part of the full sentence: "While XShell supports numerous versions of the Windows OS (including Windows XP, Vista, Windows 7, and Windows 2000, 2003 and 2008 server both 32 and 64 bit versions), only computers running Windows XP were observed communicating with 'path.alyac.org'." (p. 4)

(The 'Windows 2003 Server Web Edition, Service Pack 2' computer was communicating via the 'LURK' protocol - see page 2).

blacked out areas readable (1)

Anonymous Coward | more than 2 years ago | (#39010467)

You can just copy and paste text from the blacked out areas if you want to see it.

Re:blacked out areas readable (2, Funny)

Anonymous Coward | more than 2 years ago | (#39010775)

Oh really? What does it say? I don't speak 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

Re:blacked out areas readable (0)

Anonymous Coward | more than 2 years ago | (#39017295)

Oh really? What does it say? I don't speak 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

So go get a reader that properly renders the forms, and it'll be shown in plaintext.

Yummy. Digitally signed root kits. (5, Insightful)

sgt scrub (869860) | more than 2 years ago | (#39011043)

IMHO the most important thing in the article is that the malware was digitally signed. This exposes the weakness in digital signatures. Not only for applications and modules(drivers) but UEFI and all of the other "secure boot" ideas.

Re:Yummy. Digitally signed root kits. (1)

TemporalBeing (803363) | more than 2 years ago | (#39021287)

IMHO the most important thing in the article is that the malware was digitally signed. This exposes the weakness in digital signatures. Not only for applications and modules(drivers) but UEFI and all of the other "secure boot" ideas.

I'd go a bit further in saying that it exposes the weakness ouf using digital signatures period in all applications of it - legal and otherwise.

For a reveal, it sure blacks out a lot of stuff (1)

sethstorm (512897) | more than 2 years ago | (#39013471)

If this was a real reveal, there'd be no blacked out information.

Re:For a reveal, it sure blacks out a lot of stuff (0)

Anonymous Coward | more than 2 years ago | (#39014223)

As far as I can tell it's only personal information about the victims that has been blacked out...

Re:For a reveal, it sure blacks out a lot of stuff (1)

godel_56 (1287256) | more than 2 years ago | (#39016335)

If this was a real reveal, there'd be no blacked out information.

BTW, amusingly for a security company document, I think the PDF has been improperly redacted. Using Foxit Reader I jumped to the end of the document and then scrolled forward from there. I could briefly read the content of figures 10 and 11 on page 14 with no problem.

When I reversed direction they were blacked out again, and I have been unable to repeat the trick. From what I read, I don't know why they bothered. Both messages were bland and unconvincing phishing invitations to an unnamed conference, with details (and malware) in the attachments. No personal names or organisations were mentioned.

Re:For a reveal, it sure blacks out a lot of stuff (0)

Anonymous Coward | more than 2 years ago | (#39016361)

Some readers don't seem to render the diagrams properly - they're not redacted.

Re:For a reveal, it sure blacks out a lot of stuff (0)

Anonymous Coward | more than 2 years ago | (#39016399)

Wow! OMGZ! Just by using a reader that renders diagrams properly I can see all the redacted information!!!1111!!!ONE!!!

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...