Learning from the breaches that happens to others
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
Keywords: Incident Response report
4 comment(s)
×
Diary Archives
Comments
Anonymous
Jan 22nd 2014
1 decade ago
Anonymous
Jan 22nd 2014
1 decade ago
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.
Anonymous
Jan 23rd 2014
1 decade ago
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 ?.
Anonymous
Jan 23rd 2014
1 decade ago