Malicious shortcut

Sample identification: 551d3080b6eb510b6688dbc9ce0bfc695f92f2aeba5af337f1c8e4452c27a12a
Virustotal hits: 11/58
Identified as: "windows shortcut"

Another example of the combined used of different scripting languages. Here, we got at least some powershell and some JScript.

.LNK files can be inspected using powershell for example:

PS C:\Users\user\Documents\Sample> $sh.CreateShortcut("C:\Users\user\Documents\Sample\link.lnk") | Get-Member

   TypeName: System.__ComObject#{f935dc23-1cf0-11d0-adb9-00c04fd58a0b}

Name             MemberType Definition
----             ---------- ----------
Load             Method     void Load (string)
Save             Method     void Save ()
Arguments        Property   string Arguments () {get} {set}
Description      Property   string Description () {get} {set}
FullName         Property   string FullName () {get}
Hotkey           Property   string Hotkey () {get} {set}
IconLocation     Property   string IconLocation () {get} {set}
RelativePath    …

From HTA to compromise

This experiments started by looking for malicious powershell scripts to analyse.

I got hands on the following sample: 836ae30b13d7d29d8ff6d9c54a1d8b036e8bcd38fafb6ed95f1248028b48902f

The whole infection chain happens to be analysed at:

This hta file is a powershell dropper using several tricks to avoid simple pattern matching detection.

First, the code hides the browser window:
Window.ReSizeTo 0, 0
Window.moveTo -7911, -7345

Then a one liner VB script code defines several functions with meaningless names which goal is to execute encoded powershell code.

In an attempt to avoid detection routines, the script uses several tricks :
• VBS code is almost a one liner
• mixed case strings
ex. "CrEaTEobJECt"
• numerous spaces between strings
ex. "fuNCTiOn        ncfireszndjkhhyufnjodgulxvxyexewqis        ( "
• base64 encoded powershell code
ex. "PowERsh…

Debugging dotNet malware with dnSpy

What makes .Net malware different from your classical windows malwareWhen building a .Net executable, source code is not compiled to object code but to an intermediate language called “MSIL” (Microsoft Intermediate Language) which uses JIT (Just-In Time) compile at execution time but the “Common Language Runtime” virtual machine. The virtual machine (execution environment) is a bit like the Java virtual machine except that the source code can be written in different high level languages like C#, VB.Net or even PowerShell. As a result, as it is also the case for Java, .Net executables are much easier to reverse to source code than executable written in C++, for example. Such executable must be disassembled and analysed in tools like OllyDBG/Immunity or IDA, mostly at assembly level. PE executables generated for .Net applications are also a bit different in their “aspect” than other PE executables. For example: They usually need less imports; .Net resources are not stored in the resources…