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?
