Garmin WastedLocker static code analysis. Part I: unpack

Today we’re reverse-engineering a sample of the WastedLocker malware, apparently used in the recent Garmin attack (July 2020). This malware is custom built, so there are many possible variants of the one analyzed here, but this is more about reverse engineering and learning the tricks than getting generic detection rules. This sample is the one referenced by BleepingComputer:

MD5: 2cc4534b0dd0e1c8d5b89644274a10c1
SHA-1: 735ee2c15c0b7172f65d39f0fd33b9186ee69653
SHA-256: 905ea119ad8d3e54cd228c458a1b5681abc1f35df782977a23812ec4efa0288a

A first look at the section looks like this is a packed exe, small code, big rdata:

Stage 1

In the entrypoint function, the sample will play some cat and mouse tricks, presenting unreacheable code and functions that call the Windows API but don’t really do anything meaningful. At the end of the start function, however, the unpacking occurs:

It allocates a buffer to receive the unpacked code, then, those two functions at the end will unpack a piece of the executable. Once unpacked, some more setup is done and control transferred to the new entry point by pushing the address to the stack and retn, effectively transferring control to the unpacked code.