<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Frank Block on Insinuator.net - Bold Statements</title>
    <link>https://insinuator.net/authors/frank-block/</link>
    <description>Recent content in Frank Block on Insinuator.net - Bold Statements</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 06 Sep 2023 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://insinuator.net/authors/frank-block/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Identification of (malicious) modifications in memory-mapped image files</title>
      <link>https://insinuator.net/2023/09/identification-of-malicious-modifications-in-memory-mapped-image-files/</link>
      <pubDate>Wed, 06 Sep 2023 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2023/09/identification-of-malicious-modifications-in-memory-mapped-image-files/</guid>
      <description>&lt;p&gt;I’m happy to announce the publication of the paper&#xA;&lt;a href=&#34;https://dfrws.org/wp-content/uploads/2023/07/block-windowsmemoryforensics.pdf&#34;&gt;Windows memory forensics: Identification of (malicious) modifications in memory-mapped image files&lt;/a&gt;&#xA;at this years DFRWS USA, and the release of the corresponding&#xA;&lt;a href=&#34;https://github.com/f-block/volatility-plugins#imgmalfind&#34;&gt;volatility plugin&lt;/a&gt;.&#xA;With this research came also an update to the Ptenum family (affecting&#xA;especially the &lt;code&gt;ptemalfind&lt;/code&gt; plugin), which makes the plugins reliable in&#xA;identifying modified pages despite memory combining, so make sure to grab the&#xA;newest version from the Github repository.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Some experiments with Process Hollowing</title>
      <link>https://insinuator.net/2022/09/some-experiments-with-process-hollowing/</link>
      <pubDate>Thu, 29 Sep 2022 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2022/09/some-experiments-with-process-hollowing/</guid>
      <description>&lt;p&gt;Process Hollowing is a technique used by various malware families (such as&#xA;FormBook, TrickBot and Agent Tesla) to hide their malicious code within a benign&#xA;appearing process. The typical workflow for setting up such a&#xA;&lt;a href=&#34;https://attack.mitre.org/techniques/T1055/012/&#34;&gt;hollowed process&lt;/a&gt; is as&#xA;follows:&lt;/p&gt;&#xA;&lt;ol&gt;&#xA;&lt;li&gt;Create a new process (victim) using a benign executable, in suspended state.&lt;/li&gt;&#xA;&lt;li&gt;Unmap the executable from that process.&lt;/li&gt;&#xA;&lt;li&gt;Allocate memory for the malicious executable at the address of the&#xA;previously mapped victim executable.&lt;/li&gt;&#xA;&lt;li&gt;Write the malicious executable to the new memory area and potentially apply&#xA;relocations.&lt;/li&gt;&#xA;&lt;li&gt;Adjust the entry point.&lt;/li&gt;&#xA;&lt;li&gt;Resume process.&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;p&gt;We will refer to this as the “normal” Process Hollowing workflow. There are also&#xA;variants of this technique, one being to not unmap the original executable and&#xA;to allocate the new memory somewhere else. We will call this one no-unmap. But&#xA;wait, why does malware not simply overwrite the existing executable but creates&#xA;a new memory area which stands out due to its characteristics? In this blog post&#xA;we will have a closer look at this overwrite approach but also on the no-unmap&#xA;method, their effects on analysis/detection tools and on some tricks to make the&#xA;detection harder. We are also releasing Proof of Concept implementations of all&#xA;mentioned tools/plugins (the links are at the end of this post).&lt;/p&gt;</description>
    </item>
    <item>
      <title>Release of PTE Analysis plugins for Volatility 3</title>
      <link>https://insinuator.net/2021/12/release-of-pte-analysis-plugins-for-volatility-3/</link>
      <pubDate>Fri, 31 Dec 2021 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2021/12/release-of-pte-analysis-plugins-for-volatility-3/</guid>
      <description>&lt;p&gt;I’m happy to announce the&#xA;&lt;a href=&#34;https://github.com/f-block/volatility-plugins&#34;&gt;release&lt;/a&gt; of several plugins for&#xA;Volatility 3 that allow you to dig deeper into the memory analysis. One of those&#xA;plugins is &lt;code&gt;PteMalfind&lt;/code&gt;, which is essentially an improved version of &lt;code&gt;malfind&lt;/code&gt;.&#xA;Another one is &lt;code&gt;PteResolve&lt;/code&gt; which, similarly to the WinDBG command &lt;code&gt;!pte&lt;/code&gt;,&#xA;allows you to inspect Page Table Entry (PTE) information for e.g., a given&#xA;virtual address. In this blog post we will have a closer look at these and more&#xA;plugins, and the &lt;code&gt;PteEnumerator&lt;/code&gt; base class and what you can do with it. The&#xA;memory dump used for this blog post is available&#xA;&lt;a href=&#34;https://ernw.de/download/blogposts/pte_analysis/mem.dump.zip&#34;&gt;here&lt;/a&gt;. Some of&#xA;the injection tools used in this blog post can be gathered from&#xA;&lt;a href=&#34;https://github.com/f-block/DFRWS-USA-2019/tree/master/tools&#34;&gt;here&lt;/a&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>New Release of Glibc Heap Analysis Plugins</title>
      <link>https://insinuator.net/2018/06/new-release-of-glibc-heap-analysis-plugins/</link>
      <pubDate>Wed, 06 Jun 2018 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2018/06/new-release-of-glibc-heap-analysis-plugins/</guid>
      <description>&lt;p&gt;After quite some time and work, I’m happy to announce the new release of the &lt;a href=&#34;https://github.com/google/rekall/blob/master/rekall-core/rekall/plugins/linux/heap_analysis.py&#34;&gt;Linux&lt;/a&gt; &lt;a href=&#34;https://github.com/google/rekall/blob/master/rekall-core/rekall/plugins/linux/keepassx.py&#34;&gt;Heap&lt;/a&gt; &lt;a href=&#34;https://github.com/google/rekall/blob/master/rekall-core/rekall/plugins/linux/zsh.py&#34;&gt;Analysis&lt;/a&gt; Plugins, which are now part of the &lt;a href=&#34;https://github.com/google/rekall&#34;&gt;Rekall&lt;/a&gt; project, but not yet part of an official Rekall release, so you have to grab them manually.&lt;br&gt;&#xA;This release fixes several bugs and adds the following features:&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;Support for Glibc version 2.26 (tcache chunks) and 2.27&lt;/li&gt;&#xA;&lt;li&gt;Heapsearch now includes Rekall’s yara scan functionality&lt;/li&gt;&#xA;&lt;li&gt;x86 Glibc versions with a modified MALLOC_ALIGNMENT value of 16 (as done in arch’s glibc package 2.26) are now supported&lt;/li&gt;&#xA;&lt;li&gt;Improved retrieval of main_arena and new automated retrieval of malloc_par struct; so for the majority of cases, the corresponding cmd line options are not necessary anymore and hence no debug information have to be retrieved.&lt;/li&gt;&#xA;&lt;li&gt;main_arena and malloc_par struct retrieval now also applies for statically linked binaries; there might however be cases, where it is necessary to specify the malloc_par struct offset and the used glibc version number&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;While Glibc version 2.27 does not really change much for the heap from a forensics point of view, version 2.26 introduced a new feature called tcache (per thread cache). Those caches are essentially just a new type of bin, holding freed chunks, but &lt;a href=&#34;https://sourceware.org/ml/libc-alpha/2017-01/msg00452.html&#34;&gt;seem to improve the performance&lt;/a&gt;.&lt;br&gt;&#xA;Sadly, only two days after its &lt;a href=&#34;https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d5c3fafc4307c9b7a4c7d5cb381fcdbfad340bcc&#34;&gt;first commit&lt;/a&gt;, there was already a &lt;a href=&#34;http://tukan.farm/2017/07/08/tcache/&#34;&gt;blog post&lt;/a&gt; explaining the functionality (not so sad 😉 ) and also some discovered vulnerabilities (here we go with the sad part).&lt;br&gt;&#xA;Besides introducing a new landscape for attackers, this feature added two new heap management structs and one additional chunk per thread-heap (each thread has its own heap, up until an upper limit). This chunk is located at the beginning of each heap and hence, part of a raw heap dump (so be aware of that, if you are doing a raw analysis without the plugins).&lt;br&gt;&#xA;The chunk holds the content of the &lt;code&gt;tcache_perthread_struct&lt;/code&gt;, which has to members:&lt;/p&gt;</description>
    </item>
    <item>
      <title>DFRWS USA 2017</title>
      <link>https://insinuator.net/2017/09/dfrws-usa-2017/</link>
      <pubDate>Wed, 06 Sep 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/09/dfrws-usa-2017/</guid>
      <description>&lt;p&gt;As mentioned in my last &lt;a href=&#34;https://insinuator.net/2017/07/release-of-glibc-heap-analysis-plugins-for-rekall/&#34;&gt;blogpost&lt;/a&gt;, I had the pleasure to participate in this years DFRWS USA and present our paper. The paper and presentation can be freely viewed and downloaded &lt;a href=&#34;https://www.dfrws.org/conferences/dfrws-usa-2017/sessions/linux-memory-forensics-dissecting-user-space-process-heap&#34;&gt;here&lt;/a&gt; or &lt;a href=&#34;https://authors.elsevier.com/sd/article/S1742287617301895&#34;&gt;here&lt;/a&gt;. Note that there is also an extended version of the paper, which can be downloaded &lt;a href=&#34;https://opus4.kobv.de/opus4-fau/frontdoor/index/index/docId/8340&#34;&gt;here&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;The keepassx, zsh and heap analysis plugins are now also part of the &lt;a href=&#34;https://github.com/google/rekall/releases/tag/v1.7.0rc1&#34;&gt;Rekall release candidate 1.7.0RC1&lt;/a&gt;, so it’s easier to get started.&lt;/p&gt;&#xA;&lt;p&gt;The conference had some great talks and workshops, which I’m going to briefly sum up.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Release of Glibc Heap Analysis Plugins for Rekall</title>
      <link>https://insinuator.net/2017/07/release-of-glibc-heap-analysis-plugins-for-rekall/</link>
      <pubDate>Thu, 13 Jul 2017 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2017/07/release-of-glibc-heap-analysis-plugins-for-rekall/</guid>
      <description>&lt;p&gt;I’m happy to announce the release of several Glibc heap analysis plugins (for Linux), resp. plugins to gather information from keepassx and zsh, which are now included in the &lt;a href=&#34;https://github.com/google/rekall&#34;&gt;Rekall Memory Forensic Framework&lt;/a&gt;. This blogpost will demonstrate these plugins and explain how they can be used. More detailed information, including real world scenarios, will be released after the &lt;a href=&#34;https://dfrws.org/conferences/dfrws-usa-2017/sessions/linux-memory-forensics-dissecting-user-space-process-heap&#34;&gt;talk&lt;/a&gt; at this years &lt;a href=&#34;https://dfrws.org/conferences/dfrws-usa-2017&#34;&gt;DFRWS USA&lt;/a&gt;.&lt;/p&gt;&#xA;&lt;p&gt;Before being able to reliably analyze the heap of a process, a profile, for the Glibc version being used, must be provided. However, this step should for most cases be fairly simple and only consist of gathering the offset for the &lt;em&gt;mp_&lt;/em&gt; and &lt;em&gt;main_arena&lt;/em&gt; variables:&lt;/p&gt;</description>
    </item>
    <item>
      <title>A short Addendum on the Mirai Botnet Blog Post</title>
      <link>https://insinuator.net/2016/12/a-short-addendum-on-the-mirai-botnet-blog-post/</link>
      <pubDate>Thu, 08 Dec 2016 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2016/12/a-short-addendum-on-the-mirai-botnet-blog-post/</guid>
      <description>&lt;p&gt;While doing heap research on Linux processes (results are going to be published soon), I came across the bot from the Mirai Botnet. As already mentioned in the blog post by &lt;a href=&#34;https://insinuator.net/2016/10/a-quick-insight-into-the-mirai-botnet/&#34;&gt;Brian&lt;/a&gt;, the Mirai bot uses obfuscated configuration data which contains e.g. the CnC server. When now confronted only with a bot (e.g. in the context of a running task or the ELF binary), but without the according source code, the decryption of this configuration data for e.g. incident analysis purposes might not be easily possible (with the python script from the blog post), if the key has been changed.&lt;br&gt;&#xA;But in this case that is not a problem at all, because&lt;/p&gt;</description>
    </item>
    <item>
      <title>Teaser on the TROOPERS16 Incident Analysis Workshop: Analyzing the current Spam Flood</title>
      <link>https://insinuator.net/2015/12/teaser-on-the-troopers16-incident-analysis-workshop-analyzing-the-current-spam-flood/</link>
      <pubDate>Fri, 18 Dec 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/12/teaser-on-the-troopers16-incident-analysis-workshop-analyzing-the-current-spam-flood/</guid>
      <description>&lt;p&gt;As we are giving another round of our Incident &lt;a href=&#34;https://www.troopers.de/events/troopers16/566_incident_analysis/&#34;&gt;Analysis workshop&lt;/a&gt; at &lt;a href=&#34;https://www.troopers.de/troopers16/&#34;&gt;Troopers16&lt;/a&gt;, we wanted to give a little sample taste what you can expect.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Table of Contents&lt;/strong&gt;&lt;br&gt;&#xA;&lt;a href=&#34;#extraction&#34;&gt;&lt;strong&gt;Extracting Mail Attachments&lt;/strong&gt;&lt;/a&gt;&lt;br&gt;&#xA;&lt;a href=&#34;#word&#34;&gt;&lt;strong&gt;Word Document Analysis&lt;/strong&gt;&lt;/a&gt;&lt;br&gt;&#xA;&lt;a href=&#34;#static&#34;&gt;&lt;strong&gt;Static JavaScript Analysis&lt;/strong&gt;&lt;/a&gt;&lt;br&gt;&#xA;&lt;a href=&#34;#dynamic&#34;&gt;&lt;strong&gt;Dynamic JavaScript Analysis&lt;/strong&gt;&lt;/a&gt;&lt;/p&gt;&#xA;&lt;p&gt;Before we dive into the analysis, I wanted to mention that if you are going to analyze anything unknown/potentially malicious, do it in a safe environment (VM with no internet connection, in the best case on a separate physical analysis device, or at least strip all unnecessary functionality from that VM (CVE-2015-3456 is an example to answer the “why”)). Even things like looking at content with a text editor or extracting zip files should be done in the safe environment, as those tools could contain vulnerabilities.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Investigating Memory Analysis Tools – SSDT Hooking via Pointer Replacement</title>
      <link>https://insinuator.net/2015/12/investigating-memory-analysis-tools-ssdt-hooking-via-pointer-replacement/</link>
      <pubDate>Sun, 13 Dec 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/12/investigating-memory-analysis-tools-ssdt-hooking-via-pointer-replacement/</guid>
      <description>&lt;p&gt;In this blogpost we will briefly explain a well known Syscall hooking technique (a more detailed explanation can be gathered from e.g.  http://resources.infosecinstitute.com/hooking-system-service-dispatch-table-ssdt/) used by multiple malware samples (like the laqma trojan) and right after discuss how some memory analysis tools have trouble in the analysis and/or reporting of these.&lt;/p&gt;&#xA;&lt;p&gt;Before we go further, I just shortly wanted to say, that this post is not intended to be a bashing of any tool. We have the greatest respect for all the effort and work which has been and most probably will be done in the future.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Analysis of an Alarm System – Part 2/3</title>
      <link>https://insinuator.net/2015/05/analysis-of-an-alarm-system-part-2/3/</link>
      <pubDate>Tue, 12 May 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/05/analysis-of-an-alarm-system-part-2/3/</guid>
      <description>&lt;p&gt;A few days later than planned (sorry about that), but here we go with part 2 (&lt;a href=&#34;http://www.insinuator.net/2015/04/analysis-of-an-alarm-system/&#34;&gt;Part1&lt;/a&gt;) and the demodulation/analysis part.&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Initial Analysis&lt;/strong&gt;&lt;br&gt;&#xA;To analyse a captured signal, the tool baudline seems to be the best way at the moment. So we open it with the following options and have a closer look (ContextMenu-&amp;gt;Input-&amp;gt;Open file):&lt;/p&gt;&#xA;&lt;p&gt;&lt;img src=&#34;https://www.ernw.de/download/alarm_system/step3_baudlineOpenOptions.png&#34; alt=&#34;&#34;&gt;&lt;/p&gt;&#xA;&lt;p&gt;After using the open button, you should be able to see something similar to this:&lt;/p&gt;</description>
    </item>
    <item>
      <title>Analysis of an Alarm System – Part 1/3</title>
      <link>https://insinuator.net/2015/04/analysis-of-an-alarm-system-part-1/3/</link>
      <pubDate>Mon, 20 Apr 2015 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2015/04/analysis-of-an-alarm-system-part-1/3/</guid>
      <description>&lt;p&gt;&lt;strong&gt;Introduction&lt;/strong&gt;&lt;br&gt;&#xA;This and the following two posts should serve as a step-by-step guide through the whole process of analyzing a radio frequency black box, demodulate and understand the data transfered and finally modulate our own data in order to e.g. perform a brute force attacks.&lt;/p&gt;&#xA;&lt;p&gt;The information provided and the results are immensely inspired by Michael Ossmann and the workshops he has given at our location. Visit him and his great tool HackRF at &lt;a href=&#34;https://greatscottgadgets.com/hackrf/&#34;&gt;https://greatscottgadgets.com/hackrf/&lt;/a&gt; !&lt;/p&gt;</description>
    </item>
    <item>
      <title>ERNW’s Top 9 Burp Plugins</title>
      <link>https://insinuator.net/2014/08/ernws-top-9-burp-plugins/</link>
      <pubDate>Mon, 25 Aug 2014 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2014/08/ernws-top-9-burp-plugins/</guid>
      <description>&lt;p&gt;In the context of an internal evaluation, we recently had a look at most of the burp plugins available from the BApp store. The following overview represents our personal top 9 plugins, categorized in “Scanner Extensions”, “Manual Testing” and “Misc” in alphabetic order:&lt;/p&gt;&#xA;&lt;p&gt;&lt;strong&gt;Scanner Extensions&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;p&gt;ActiveScan++&lt;/p&gt;&#xA;&lt;p&gt;This plugin adds some tests for Dynamic code injection, &lt;a href=&#34;http://carlos.bueno.org/2008/06/host-header-injection.html&#34; title=&#34;Host header attacks&#34;&gt;Host header attacks&lt;/a&gt; (&lt;a href=&#34;http://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html&#34; title=&#34;Password reset poisoning&#34;&gt;password reset poisoning&lt;/a&gt;, &lt;a href=&#34;https://www.owasp.org/index.php/Cache_Poisoning&#34; title=&#34;cache poisoning&#34;&gt;cache poisoning&lt;/a&gt;, DNS rebinding), OS command injection and &lt;a href=&#34;http://www.thespanner.co.uk/2014/03/21/rpo/&#34; title=&#34;Relative path overwrite&#34;&gt;Relative path overwrite&lt;/a&gt;. In some internal tests, it seemed to deliver what it promises.&lt;/p&gt;</description>
    </item>
    <item>
      <title>tsakwaf 0.9.1 released</title>
      <link>https://insinuator.net/2011/09/tsakwaf-0.9.1-released/</link>
      <pubDate>Sun, 11 Sep 2011 00:00:00 +0000</pubDate>
      <guid>https://insinuator.net/2011/09/tsakwaf-0.9.1-released/</guid>
      <description>&lt;p&gt;A few weeks ago, I released version 0.9 of a web application testing tool called tsakwaf (The Swiss Army Knife for Web Application Firewalls) together with an ERNW &lt;a href=&#34;http://www.ernw.de/content/e15/e28/index_ger.html&#34; title=&#34;Newsletter&#34;&gt;Newsletter&lt;/a&gt; about &lt;a href=&#34;http://www.insinuator.net/2011/06/the-5-myths-of-web-application-firewalls/&#34; title=&#34;web application firewalls&#34;&gt;web application firewalls&lt;/a&gt;. tsakwaf is based on perl and supports fingerprinting of some supported WAFs and code generation methods to circumvent filter rules. Today, version 0.9.1 will be released, which adds SSL support for the WAF fingerprinting function (Big thanks to Simon Rich!) and a bug fix regarding the detection of WAF reactions which may lead to false positives. Additionally, I’m happy to announce that at least one talk at next year’s &lt;a href=&#34;http://www.troopers.de&#34; title=&#34;Troopers&#34;&gt;Troopers&lt;/a&gt; will cover attacks against WAFs (like this one from the 2009 &lt;a href=&#34;http://troopers09.org/content/e644/e649/TROOPERS09_gauci_henrique_web_application_firewalls.pdf&#34; title=&#34;edition&#34;&gt;edition&lt;/a&gt;) . So mark your calendar – Troopers12 will happen on 21^(st) and 22^(nd) March 2012, with the usual workshops before the conference and the round table sessions the day after – and enjoy playing with tsakwaf!&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
