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:

• newtest.swm – 0
• newtest2.swm – 0
• newtest3.swm – … or… not… yup, okay, we are still getting caught:

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!