Reader Matt was targeted with malware via email, and managed to start to analyze the content of the ZIP file served by the compromised server. It contains a .lnk file. Matt figured out that it launches the following PowerShell command:

But what is dikona?

Command findstr is Windows' grep command. Option /s directs findstr to search in all subdirectories. dikona is the string to search for. And $env:userprofile\*.lnk directs findstr to grep through all .lnk files in the users' profile.

Let's try this findstr command on the malicious .lnk file:

This is another PowerShell script (a downloader). Notice that all lines in this script contain the string dikona.

Where is this script stored? Not inside a valid field inside the .lnk file, the analysis report of lnkanalyser does not reveal this script:

It's because the PowerShells script is just appended to the end of the .lnk file:

This script, extracted via findstr, is stored into variable $g, and then executed.

Conclusion: this is a trick to evade AV detection. The malicious PowerShell script is appended to the .lnk file, and will not be found by just analyzing the content of the .lnk file according to the format specification for .lnk files. The PowerShell command (with findstr dikona) that is executed by the .lnk file, is very short and looks benign: it will not trigger many AV programs.

The .lnk file itself has a detection rate of 2/59 on VirusTotal (time of writing).

To easily extract the script from the (binary) .lnk file, findstr (grep) is used to select all lines with string dikona. And since the name of the .lnk file is not know by the initial PowerShell script, all .lnk files (*.lnk) are searched through.

Why does findstr not extract the PowerShell command with "findstr dikona" from the .lnk file? Because that command is stored as a UNICODE string, and the appended PowerShell script is ASCII.

Another sample found by Matt uses glirote3 as selector string.

A bening JPEG image was also present in the ZIP file:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com