This article is about the massive BSOD triggered by CrowdStrike worldwide on July 19. Analysis and information from CrowdStrike or other sources are regularly published, completing what is expressed here. Updates may also be provided in the future.
Friday, July 19, is a day to be remembered in computing history as the day of one of the biggest BSODs (Blue Screens of Death). We have seen air traffic come to a standstill over the USA and people climbing ladders with USB sticks to update giant screens. The impact was still measurable over many days. The question on everyone’s lips is how that all happened. CrowdStrike provided, on a regular basis, an explanation for people to understand what happened. But explanations can be hard to understand, especially for one who would like to read directly within CrowdStrike’s internal wording in their publications and regarding technical driver implementation details. Also, the analysis misses some points we consider relevant for secure software development. This article discusses conclusions from this massive crash, especially the necessity to change our mindset about software. This means we should understand, document, and evaluate independently software provided by vendors to know exactly what we install on our systems and to figure out the risk that may be taken by using the software. The time of naive belief in software magic must end with a third party’s independent review of the software, analysing its reliability, security, and stability. This is an activity we have been doing at ERNW for years, especially for e.g. the German Federal Office for Information Security (BSI)1.
After our last blogpost regarding Emotet and several other Emotet and Ransomware samples that we encountered, we recently stumbled across a variant belonging to the Gozi, ISFB, Dreambot respectively Ursnif family. In this blogpost, we want to share our insights from the analysis of this malware, whose malware family is mainly known for being a banking trojan that typically tries to infect browser sessions and sniff/redirect data. In particular, we are going to provide details about the first stage Word Document, the embedded JavaScript/XSL document, an in-depth runtime analysis of the downloaded executable, and some details regarding detection.
Some weeks ago, Heinrich and I had the pleasure to participate in the heisec-Webinar “Emotet bei Heise – Lernen aus unseren Fehlern”. We really enjoyed the webinar and the (alas, due to the format: too short) discussions and we hope we could contribute to understand how to make Active Directory implementations out there a bit safer in the future.
Now, I have the pleasure to announce a continuation of our talk about Active Directory security next week, Wednesday, 14^(th) of August @heisec in the format of a technical talk “Emotet bei Heise – Online-Fachgespräch zum Schutz vor Cybercrime”. Seats are still available 😉
After the Emotet Incident at Heise, where ERNW has been consulted for Incident Response, we decided to start a blogpost series, in which we want to regularly report on current attacks that we observe. In particular we want to provide details about the utilized pieces of malware, different stages, and techniques used for the initial infection and lateral movement. We hope that this information might help you to detect ongoing incidents, apply countermeasures, and in the best case to figure out proactive countermeasures and security controls beforehand.
Exactly one week ago I noticed an “urgent” tweet from Tavis Ormandy to get in contact with the Cloudflare team.
Normally when a tweet like this appears from Tavis, something is horribly broken. Well, today we know the background of this tweet as the bug tracker issue went public and it exposed quite a bug from Cloudflare.
While there is some background story how Tavis found the bug, because he wasn´t actively looking into the Cloudflare infrastructure and it was rather discovered by accident when odd data appeared in his fuzzing corpus. When he looked closely he found data that was not in any mean related to the expected data from various websites.
Have you for example thought about classes of incidents that are most likely to affect you and formulated Incident Handling Preparation Plans for those incidents?
