Learning from the breaches that happens to others

Published: 2014-01-22
Last Updated: 2014-01-22 09:51:23 UTC
by Chris Mohan (Version: 1)
4 comment(s)
Initially when major breaches or incidents announced via the media, everyone and their pet dog has a theory about how it happened.  As an Incident handler, I love a good explanation of what really happened when systems get breached, rather that the wide ranging, speculative theories. Most of us completely understand that during a breach information has to be limited to a need to know basis while the incident is being worked on and have to run their course before the investigators can even think about publically publishing their findings. That means the armchair security experts can pontificate endlessly of what they think happened. When an official report does get published of the breach, I tend to feel big chunks are missing, with some excellent notable exceptions.  When discovering a public, well written, comprehensive report, that dives in to the nitty-gritty of an attack it cries out to be shared and should be cherished, voraciously dissected, pillaged for any tactical or strategic indicators and then carved up for lessons learned  whenever they surface.
 
So when an IR report was published today and I read it, I got rather excited*. There have been a number of stories on ColdFusion attacks over the last year. Brian Krebs had reported on a particular interesting case [1] of attacks against ColdFusion, but despite Brian’s excellent pieces, I hadn’t found the real technical meat of what happened and how.
  
RSA's Incident Response Team today published [2] their findings dealing with a particular adversary that took advantage of a known vulnerability in ColdFusion and used as a bridgehead to gain access to the internal network then fully compromise it and exfiltrate data across multiple forms and companies. I won’t spoil the read, (the full PDF is here [3]) but they provide plenty of exacting details, the tools techniques and procedures used , their own suggested lessons learned and a stack of indicators of compromise [4] for you to run against your own networks. 
 
To me, reports like these should be compulsory reading if you're in a security role. Following the twists and turns an attacker took to get that initial compromise then how they pivoted inside a network and pillaged the data. We as security people need to understand what and how these other firms were compromised, then flip the attack on your own systems and see how we can detect or protect against becoming the next breach story in the spotlight.
 
If you know of any other papers you believe IR teams should have to read on the details of a breach , add them in the comments or send them in to us [5]
 
[1] http://krebsonsecurity.com/2013/10/adobe-to-announce-source-code-customer-data-breach/ 
[2] https://blogs.rsa.com/dissecting-tactics-techniques-advanced-adversary/
[3] http://www.emc.com/collateral/white-papers/h12756-wp-shell-crew.pdf
[4] http://www.emc.com/collateral/white-papers/h12756-rsa-incident-response-emerging-threat-profile.zip
[5] https://isc.sans.edu/contact.html#contact-form
 
* In a proper Internet Storm Center Handler manner, of course. Lots of nodding and the like.

 

Chris Mohan --- Internet Storm Center Handler on Duty

4 comment(s)

Comments

Nice gotta love coldfusion.
My question is; Is enough information being published about even the publically known breaches to help anyone? The public news articles about the recent Target Department store breach did mention the type of malware that was used and the numbers of customer's who data was stolen, precious little of use to others. The reporting on the Target breach seemed typical to me. And many companys do not publicize their security issues at all leavingt everyone in the dark. Are the hosting companies reporting anything?
Thanks for posting this. It is indeed difficult to find in depth, reliable information about real world breeches and how they were investigated, so that we all can learn from them.

It is unfortunate that we has a profession are not very good at sharing information for the sake of improving security overall.

A big thank you to RSA for making the information available.
This shows why you don't allow your servers to make outbound connections at will. Block them by default and allow outbound connections as needed to specific destinations. If possible, you should use a VPN to force encrypt traffic that needs it and lock down destinations for traffic.

As far as the "Target" breach goes, I still haven't read if the POS system was implemented in a secure manner. Did Target and the other retailers use the same POS, the same consultants, or ?.

Diary Archives