Category Archives: Forensic Analysis

Being a tool while using a tool

Posted on by

This case is kinda DFIR-fascinating.

There is an unwritten rule in the DFIR world that says – always check the results provided by one tool, with another tool, or manually…

Well… it all sounds nice in theory, until we come across a case that will change it all.

So…

If you use many different tools, and on regular basis, be warned that this case will destroy your faith in them…

Ready?

Let’s go!

I have been using Total Commander for over 2 decades. I absolutely love this tool, and can’t imagine working with gazillion of files and samples that I play with on regular basis, without using it.

But recently, I got fooled by it.

When you download the Signal desktop client installer for Windows (v7.39), you can browse its contents with Total Commander+its (various) archive plugins to see the following output:

I was specifically interested in the Signal.exe binary so I used TC to copy Signal.exe to my temporary work folder.

To my surprise, the sigcheck reported that this binary was compiled for… ARM processors!

Verified:       Signed
Signing date:   01:00 2025-01-23
Publisher:      Signal Messenger, LLC
Company:        Signal Messenger, LLC
Description:    Signal
Product:        Signal
Prod version:   7.39.0.0
File version:   7.39.0
MachineType:    64-bit ARM

Huh?

I was puzzled.

I literally downloaded what I believed to be an installer of Signal that was meant for Intel-based Windows, but now I am seeing the ARM binary inside it!

<Anxiety level intensifies>

I then tried the very same approach with the installer of the older version of Signal (7.38), but the result was the same….

What’s going on here? I wondered…

I must make a note here that the Signal setup program is using the Nullsoft installer to deliver the software to users. And in the reverse engineering world, once you recognize the installer type, the natural step in analysis is to decompile the script used by the installer.

Using the older version of 7z (7z_1505) that extracts the [NSIS].nsi script file I got the following output listing all the embedded files inside the most recent Signal installer:

$PLUGINSDIR\app-64.7z
$PLUGINSDIR\app-arm64.7z
$PLUGINSDIR\nsExec.dll
$PLUGINSDIR\nsis7z.dll
$PLUGINSDIR\SpiderBanner.dll
$PLUGINSDIR\StdUtils.dll
$PLUGINSDIR\System.dll
$PLUGINSDIR\WinShell.dll
$R0\Uninstall Signal.exe
$PLUGINSDIR\installerHeaderico.ico
[NSIS].nsi

Huh…

As you can see, there are two embedded 7z files listed above:

  • $PLUGINSDIR\app-64.7z
  • $PLUGINSDIR\app-arm64.7z

The first one is Intel-based, and the second one is ARM-based.

The [NSIS].nsi script references them here (using the respective 7z file depending on the architecture):

label_796:
  StrCmp $_40_ ARM64 0 label_799
  SetOverwrite on
  AllowSkipFiles on
  File $PLUGINSDIR\app-arm64.7z
  Goto label_802
label_799:
  StrCmp $_40_ 64 0 label_802
  File $PLUGINSDIR\app-64.7z
  Goto label_802

Kinda surprisingly, we can actually locate these 2 7z files inside the main installer file at the following offsets:

  • 0x0003C57B – app-arm64.7z
  • 0x087904C4 – app-64.7z

and after carving/extraction, browsing them with Total Commander we can reveal their content as shown below:

ARM (app-arm64.7z):

INTEL (app-64.7z):

Do you see where it is going?

With files/installers using many embedded files, the Total Commander’s (+its plugins’) visibility seems to be limited only to the first embedded archive, in this case it is the app-arm64.7z file! (in fact, it’s a bit more complicated in case TC or its plugins can parse PE file/their sections of the sample, adding an additional layer in a game of nested dolls).

When I look at that original Signal installer again now I can see the Total Commander (+its plug-ins) only see the first embedded archive. As a result, I see the Intel-targeting setup file embedding the ARM-targeting file shown in TC. The proper handling would include full file analysis of the installer and recognition of all embedded archives as virtual subfolders… at least.

The bottom line is this:

  • Let’s admit it, file formats are complicated, especially if they are mixed/overlapping
  • Trust, but verify — use multiple tools to extract/parse installer scripts, analyze/compare their outputs
  • Don’t trust GUI-only programs
  • Question what you see (in my case: the Intel-CPU targeting installer including ARM binaries as seen by TC in the installer’s body looked odd)
  • Analyze as many properly formatted file types as possible on a file format level to spot anomalies and inconsistencies in the future
  • Use carving and static analysis tools on samples: extracted sections, embedded media files, executables, configuration files, URLs, IPs. github repository addresses, PDB paths, etc. – this can add a lot of intelligence value long term

Smuggling payloads and tools in, using WIM images, Part 2

Posted on by

In this post we explore the dism.exe and WIM images a bit more.

It turns out that WIM files are containers that can include more than one image. One can create the first image using the /Capture-Image option, and then append new images to the same WIM file using the /Append-Image command line argument.

In a test scenario, I created 3 subfolders containing:

  • Image1 – Sysmon
  • Image2 – Eicar
  • Image3 – Mimikatz

I then created a multi-image newtest.wim file using the following syntax:

Dism /Capture-Image /ImageFile:”newtest.wim” /CaptureDir:image1_sysmon /Name:sysmon 
Dism /Append-Image  /ImageFile:”newtest.wim” /CaptureDir:image2_eicar /Name:eicar 
Dism /Append-Image  /ImageFile:”newtest.wim” /CaptureDir:image3_mimikatz /Name:mimikatz

To confirm the images were added to the newtest.wim file, I ran these commands:

dism /list-image /imagefile:"newtest.wim" /index:1
dism /list-image /imagefile:"newtest.wim" /index:2
dism /list-image /imagefile:"newtest.wim" /index:3

I was a bit surprised the ADSs were not listed.

Luckily, 7z lists a bit more information:

The content of [1].xml is forensically interesting:

<WIM>
 <TOTALBYTES>2122196</TOTALBYTES>

 <IMAGE INDEX="1">
  <DIRCOUNT>0</DIRCOUNT>
  <FILECOUNT>1</FILECOUNT>
  <TOTALBYTES>4563248</TOTALBYTES>
  <HARDLINKBYTES>0</HARDLINKBYTES>
  <CREATIONTIME>
   <HIGHPART>0x01DB5BD0</HIGHPART>
   <LOWPART>0x5FAF914D</LOWPART>
  </CREATIONTIME>
  <LASTMODIFICATIONTIME>
   <HIGHPART>0x01DB5BD0</HIGHPART>
   <LOWPART>0x5FB40FD8</LOWPART>
  </LASTMODIFICATIONTIME>
  <WIMBOOT>0</WIMBOOT>
  <NAME>sysmon</NAME>
 </IMAGE>
 
 <IMAGE INDEX="2">
  <DIRCOUNT>0</DIRCOUNT>
  <FILECOUNT>1</FILECOUNT>
  <TOTALBYTES>68</TOTALBYTES>
  <HARDLINKBYTES>0</HARDLINKBYTES>
  <CREATIONTIME>
   <HIGHPART>0x01DB5BD0</HIGHPART>
   <LOWPART>0x6DB1F772</LOWPART>
  </CREATIONTIME>
  <LASTMODIFICATIONTIME>
   <HIGHPART>0x01DB5BD0</HIGHPART>
   <LOWPART>0x6DB6281B</LOWPART>
  </LASTMODIFICATIONTIME>
  <WIMBOOT>0</WIMBOOT>
  <NAME>eicar</NAME>
 </IMAGE>

 <IMAGE INDEX="3">
  <DIRCOUNT>0</DIRCOUNT>
  <FILECOUNT>4</FILECOUNT>
  <TOTALBYTES>1440600</TOTALBYTES>
  <HARDLINKBYTES>0</HARDLINKBYTES>
  <CREATIONTIME>
   <HIGHPART>0x01DB5BD0</HIGHPART>
   <LOWPART>0x6FE89BE7</LOWPART>
  </CREATIONTIME>
  <LASTMODIFICATIONTIME>
   <HIGHPART>0x01DB5BD0</HIGHPART>
   <LOWPART>0x6FEDA2E8</LOWPART>
  </LASTMODIFICATIONTIME>
  <WIMBOOT>0</WIMBOOT>
  <NAME>mimikatz</NAME>
 </IMAGE>
</WIM>

I was also curious how the file will be ‘seen’ by VT, so I submitted it here. To my surprise, we got multiple different detections, hitting on different internal images – either Eicar or Mimikatz (I was hoping that my first image, sysmon, will help to bypass most of the scans – I was wrong):

Coming back to the newly created file, newtest.wim, it’s important to mention that apart from the multiple images it can host, it can also be split into smaller chunks (same as 7z, zip, or rar archives).

Running the following command:

dism /split-image /imagefile:"newtest.wim" /SWMFile:"newtest.swm" /FileSize:1

will split our newtest.wim file into 3 swm files:

    4,435 newtest.swm
1,417,386 newtest2.swm
  704,883 newtest3.swm
    2,126,704 bytes

I am not sure I follow how the 1M boundary I asked for led to creation of these 3 files with file sizes looking quite random, but one way or another, an ability to split a WIM file into SWM file chunks may come handy.

They certainly come handy when it comes to bypassing VT detections:

The last bit I want to quickly cover here is the /EA command line argument that we can use during image creation (/Capture-Image). The default behavior for the /Capture-Image is to collect both files, and their Alternate Data Streams, but /EA options extends the collection to Extended Attributes as well. This enables us to ‘outsource’ hiding data and payloads (in either ADS or EAs) to dism.exe process, as all the mounting-related, but ‘dodgy’ file system ‘object creation’ activities will be associated with this process only.

I think dism.exe is a tool that ended up being overlooked by many of us, but I hope we will all pay more attention to it now… This Microsoft page describes this tool’s command line arguments in great detail.

Happy hunting!