<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Incident on Insinuator.net - Bold Statements</title>
    <link>https://insinuator.net/tags/incident/</link>
    <description>Recent content in Incident on Insinuator.net - Bold Statements</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 20 Aug 2024 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://insinuator.net/tags/incident/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CrowdStrike: What is the worldwide BSOD all about?</title>
      <link>https://insinuator.net/2024/08/crowdstrike-what-is-the-worldwide-bsod-all-about/</link>
      <pubDate>Tue, 20 Aug 2024 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2024/08/crowdstrike-what-is-the-worldwide-bsod-all-about/</guid>
      <description>&lt;p&gt;&lt;em&gt;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.&lt;/em&gt;&lt;/p&gt;&#xA;&lt;p&gt;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)&lt;sup id=&#34;fnref:1&#34;&gt;&lt;a href=&#34;#fn:1&#34; class=&#34;footnote-ref&#34; role=&#34;doc-noteref&#34;&gt;1&lt;/a&gt;&lt;/sup&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Dissection of an Incident – Part 2</title>
      <link>https://insinuator.net/2019/10/dissection-of-an-incident-part-2/</link>
      <pubDate>Wed, 30 Oct 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/10/dissection-of-an-incident-part-2/</guid>
      <description>&lt;p&gt;After our &lt;a href=&#34;https://insinuator.net/2019/07/emotet-at-heise-emotet-there-emotet-everywhere-dissection-of-an-incident/&#34;&gt;last blogpost&lt;/a&gt; regarding Emotet and several other Emotet and Ransomware samples that we encountered, we recently stumbled across a variant belonging to the &lt;em&gt;Gozi&lt;/em&gt;, &lt;em&gt;ISFB&lt;/em&gt;, &lt;em&gt;Dreambot&lt;/em&gt; respectively &lt;em&gt;Ursnif&lt;/em&gt; 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Follow-Up on the Heisec Webinar on Emotet &amp;amp; Some Active Directory Security Sources</title>
      <link>https://insinuator.net/2019/08/a-follow-up-on-the-heisec-webinar-on-emotet-amp-some-active-directory-security-sources/</link>
      <pubDate>Fri, 09 Aug 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/08/a-follow-up-on-the-heisec-webinar-on-emotet-amp-some-active-directory-security-sources/</guid>
      <description>&lt;p&gt;Some weeks ago, Heinrich and I had the pleasure to participate in the heisec-Webinar &lt;a href=&#34;https://www.heise.de/security/meldung/heisec-Webinar-Emotet-bei-Heise-Lernen-aus-unseren-Fehlern-4439874.html&#34;&gt;“Emotet bei Heise – Lernen aus unseren Fehlern”&lt;/a&gt;. 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.&lt;/p&gt;&#xA;&lt;p&gt;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 &lt;a href=&#34;https://www.heise-events.de/webinare/emotet_cybercrime&#34;&gt;“Emotet bei Heise – Online-Fachgespräch zum Schutz vor Cybercrime”&lt;/a&gt;. Seats are still available 😉&lt;/p&gt;</description>
    </item>
    <item>
      <title>Emotet at Heise, Emotet there, Emotet everywhere – Dissection of an Incident</title>
      <link>https://insinuator.net/2019/07/emotet-at-heise-emotet-there-emotet-everywhere-dissection-of-an-incident/</link>
      <pubDate>Thu, 18 Jul 2019 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2019/07/emotet-at-heise-emotet-there-emotet-everywhere-dissection-of-an-incident/</guid>
      <description>&lt;p&gt;After the &lt;a href=&#34;https://www.heise.de/ct/artikel/Emotet-bei-Heise-4437807.html&#34;&gt;Emotet Incident at Heise&lt;/a&gt;, where &lt;a href=&#34;https://www.heise.de/security/meldung/heisec-Webinar-Emotet-bei-Heise-Lernen-aus-unseren-Fehlern-4439874.html&#34;&gt;ERNW has been consulted for Incident Response&lt;/a&gt;, 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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cloudflare Incident #Cloudbleed</title>
      <link>https://insinuator.net/2017/02/cloudflare-incident-%23cloudbleed/</link>
      <pubDate>Fri, 24 Feb 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/02/cloudflare-incident-%23cloudbleed/</guid>
      <description>&lt;p&gt;Exactly one week ago I noticed an “urgent” tweet from Tavis Ormandy to get in contact with the Cloudflare team.&lt;br&gt;&#xA;Normally when a tweet like this appears from Tavis, something is horribly broken. Well, today we know the background of this tweet as the &lt;a href=&#34;https://bugs.chromium.org/p/project-zero/issues/detail?id=1139&#34;&gt;bug tracker&lt;/a&gt; issue went public and it exposed quite a bug from Cloudflare.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
    <item>
      <title>White Paper on Incident Handling First Steps, Preparation Plans, and Process Models</title>
      <link>https://insinuator.net/2017/02/white-paper-on-incident-handling-first-steps-preparation-plans-and-process-models/</link>
      <pubDate>Wed, 01 Feb 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/02/white-paper-on-incident-handling-first-steps-preparation-plans-and-process-models/</guid>
      <description>&lt;p&gt;We just published my &lt;a href=&#34;https://www.ernw.de/download/newsletter/ERNW_Whitepaper58_IncidentHandlingFirstSteps_signed.pdf&#34;&gt;Whitepaper about First Steps, Preparation Plans, and Process Models for Incident Handling&lt;/a&gt;, that I wrote to pass the time between Christmas and New Year. The whitepaper sums up information that I consider to be useful to prepare for IT security incidents as a conclusion from the incidents in which we supported over the past year.&lt;/p&gt;&#xA;&lt;p&gt;&lt;a href=&#34;https://www.ernw.de/download/newsletter/ERNW_Whitepaper58_IncidentHandlingFirstSteps_signed.pdf&#34;&gt;&lt;img src=&#34;teaser.jpg&#34; alt=&#34;&#34;&gt;&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;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?&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
