Working Pepex Followup

I tried working on unpacking the file found in the .rsrc section of the Pepex variant that I analyzed, and had mixed results. I first tried a couple of things like simply looking for a far jump in a disassembly (like with UPX), which didn’t work. I can’t say I’m too surprised, but I figured I would give it a try. I tried running the original malware and then patching the code to force the branch where the file is loaded and executed, but the file that drops is just the packed file from .rsrc (in this case, dropped as %system%\system32\LSASvc.exe).

Next I tried putting breakpoints on Kernel32.LoadLibraryA and Kernel32.LoadLibraryW which showed that a couple of libraries were loaded (GDI32 and imm32). However, the binary keeps failing shortly after the calls to GetProcAddress for various functions from imm32 and GDI32 complete. I notice a string on the stack that says:


So, it clearly knows it’s being messed with. Not sure if this had something to do with what I was trying to do in the debugger, or if it just didn’t like being taken out of the .rsrc section of the overall malware.

Some online tutorials suggest doing something like this:

1) find the PUSH EAX instruction following the PUSHFW and PUSHAD instructions
2) follow what’s in ESP
3) find the string 46 02 C4 FF:


4) set a hardware breakpoint (on access, word) for that string
5) Run program, when BP is hit you should be close to OEP

Trying to follow this keeps resulting in exceptions/errors and crashes. However, a few lines below the original PUSH EAX instruction, I saw this:


I figured that I would just check out what is at 400000, and:


I see the 4D 5A magic numbers and then dumped from there. I ended up dumping the file three ways – used each of Olly’s methods of reconstructing the PE header, and then also without reconstructing it.

What I ended up with was a somewhat unpacked file from the .rsrc section and then the file from the .rsrc section that was created after patching the code to follow that branch (which is what I had originally gotten from the .rsrc section running Resource Hacker).

The unpacked file actually reveals many strings. I’ll go through some of what I find the most interesting, with the full set of strings at the end. First we see what appear to be pretty typical imports – Kernel32, User32, ADVAPI32, WS2_32 and some error message strings. Following this is the first block of function names. Some of the more interesting ones are:

VirtualAlloc, CreateThread, VirtualFree: These are some functions associated with process replacement. I’m not seeing others (such as ResumeThread, WriteProcessMemory, etc.) but perhaps I’m just not seeing them in this file because of the way it was unpacked. This is something to keep in mind as I take a look at what this executable does when run by the parent malware.

WriteFile, DeleteFileA, ReadFile, CopyFileA: I’m always happy to see these functions because it tells me there might be some obvious file system artifacts to look for, but it also makes me wonder if this file copies an existing, legitimate file somewhere else (such as a temp directory) and then does some sort of MiTM thing.

GetSystemDirectoryA, GetTempFileNameA, GetTempPathA: Related to the thoughts above regarding replacement of a legitimate file. I wonder if something happens like: 1) copy legitimate file to a temp path 2) replacement legitimate file with malicious file 3) malicious file receives input from system first before passing on to the legitimate file now residing in the temp directory so that nothing seems amiss.

FindFirstFileA, FindNextFileA: Looks like this thing will look for a specific file.

GetComputerNameA, GetVersionExA, GetDriveTypeA: Makes me think of some sort of system inventory.

CreateProcessA: Will be interesting to see what, if anything, this file creates with a call to this function.

CreateServiceA, StartServiceA: Another interesting clue that some of the other strings here might relate to a service name that this file uses when it creates a service with itself.

The smaller block of libraries and functions at the end just appears to be a repeat of what we’ve seen earlier. Below the large block of functions, we see an interesting set of strings:

Unable to load function: %s (%s)
Unable to load ordinal: %d (%s)
Microsoft LSA Logon Authorization Service
( Win32s )
( Windows 98 )
( Windows 95 )
ver %d.%d %s (Build %d)
( Windows2000
( WindowsNT
( Unknown )
%s <%uk>

Looks like the first two are some error messages specific to this sample. After that I’m going to guess that when this calls CreateServiceA and StartServiceA it calls itself LSAService/Microsoft LSA Logon Authorization Service. Next we see what appears to be some sort of system inventory creation text. I’m going to try to get this to run and see what happens dynamically.

Looking at the malware in the debugger, after the file is written from the .rsrc section, there is a call to CreateProcess with these parameters:


Stepping through the parameters with the help of MSDN:

pProcessInfo: Pointer to a PROCESS_INFORMATION struct that receives info about the new process. In this run this value happens to be 18FB44.

PstartupInfo: Pointer to a STARTUPINFO or STARTUPINFOEX struct. In this run this value is 18FB00. We also see this string:


CurrentDir: The path to the current directory for the process. In this run, it’s set to NULL, so the new process will have the same path as the calling process (which in our case would be c:\ma\lab\)

pEnvironment: NULL in our run, which means that the new process will use the environment of the calling process

CreationFlags: In our case this has been set to CREATE_NO_WINDOW (0x08000000). I’m going to change this to 0x00000010 (CREATE_NEW_CONSOLE) so we can see what it does:


InheritHandles: In our run, this is set to FALSE, so no handles are inherited from the main malware process.

pThreadSecurity: Set to NULL, so handles to the new thread cannot be inherited by child processes.

pProcessSecurity: Also NULL, so handles to the new process cannot be inherited by child processes.

CommandLine: The command line to be executed, which in our case is the string from above – C:\Windows\system32\lsasvc.exe -i (though on our system that’s the SysWOW64 directory since I’m running this on a Win7 VM). The -i argument is interesting. Maybe this means “-install”? I wonder if there is a corresponding -u or -r argument.

ModuleFileName: NULL, so “…the module name must be the first white space-delimited token in the lpCommandLine string…”, therefore lsasvc.exe.

After this, we see some MOVs that zero out some areas in ESP and then we see the parameters set up for the call to CreateProcessA – looks like how I want it:


Running this, however, didn’t produce a console. I was hoping that since the author went out of their way to set this as CREATE_NO_WINDOW, that perhaps I could change the CreationFlags to get something to appear. In discussing this with someone online (thanks Defunct), my current thought process is that since the parent isn’t run in its own console and since this child process should be getting the parent’s STARTUPINFO struct, that could be one reason why we aren’t “seeing” anything. The malware could also have been compiled to be a GUI app and not as a console app. Anyway…

Despite this, we do see some interesting things happen when the process is run. First, Regshot reveals the following changes in the registry:

Keys added: 2
Values added: 14
HKLM\SYSTEM\ControlSet001\services\LSAService\Type: 0x00000010
HKLM\SYSTEM\ControlSet001\services\LSAService\Start: 0x00000002
HKLM\SYSTEM\ControlSet001\services\LSAService\ErrorControl: 0x00000001
HKLM\SYSTEM\ControlSet001\services\LSAService\ImagePath: “C:\Windows\system32\LSASvc.exe”
HKLM\SYSTEM\ControlSet001\services\LSAService\DisplayName: “Microsoft LSA Logon Authorization
HKLM\SYSTEM\ControlSet001\services\LSAService\WOW64: 0x00000001
HKLM\SYSTEM\ControlSet001\services\LSAService\ObjectName: “LocalSystem”
HKLM\SYSTEM\CurrentControlSet\services\LSAService\Type: 0x00000010
HKLM\SYSTEM\CurrentControlSet\services\LSAService\Start: 0x00000002
HKLM\SYSTEM\CurrentControlSet\services\LSAService\ErrorControl: 0x00000001
HKLM\SYSTEM\CurrentControlSet\services\LSAService\ImagePath: “C:\Windows\system32\LSASvc.exe”
HKLM\SYSTEM\CurrentControlSet\services\LSAService\DisplayName: “Microsoft LSA Logon Authorization
HKLM\SYSTEM\CurrentControlSet\services\LSAService\WOW64: 0x00000001
HKLM\SYSTEM\CurrentControlSet\services\LSAService\ObjectName: “LocalSystem”

Per MSDN, the service Type (0x00000010) is a Win32 program that can be started by the service controller. The Start type (0x00000002) indicates that it should automatically load at startup. This looks to be how this other file achieves some persistence and also stealth as it tries to masquerade as a legitimate-sounding service.

Process Explorer and Process Monitor let us observe that the call to CreateProcessA spawns an LSASvc.exe process (PID 1160) and then that process terminates with another LSASvc.exe process being created (PID 2816). This new process (2816) starts listening on port 186. This is pretty interesting, because the parent malware didn’t appear to have any C2 functionality, and this might indicate how the malware can be worked with remotely.

I tried to fix the dumped file with LordPE and ImpRec, but still had issues with the file so I’m probably going to leave it be, at least for now. There were some interesting things going on in this file, though, so I’ve updated the report from the last post and am including that here. Please let me know if you have any thoughts on any of this, particularly on unpacking Petite!

Updated Report (with additions in bold): MalEXE003-updated

Full Strings:

!This program cannot be run in DOS mode.
runtime error
TLOSS error
SING error
DOMAIN error
– unable to initialize heap
– not enough space for lowio initialization
– not enough space for stdio initialization
– pure virtual function call
– not enough space for _onexit/atexit table
– unable to open console device
– unexpected heap error
– unexpected multithread lock error
– not enough space for thread data
abnormal program termination
– not enough space for environment
– not enough space for arguments
– floating point not loaded
Microsoft Visual C++ Runtime Library
Runtime Error!

<program name unknown>
This file has been tampered with and
Unable to load function: %s (%s)
Unable to load ordinal: %d (%s)
Microsoft LSA Logon Authorization Service
( Win32s )
( Windows 98 )
( Windows 95 )
ver %d.%d %s (Build %d)
( Windows2000
( WindowsNT
( Unknown )
%s <%uk>
Corrupt Data!

New Pepex Variant (this one works)

I spent the morning sorting through samples from all the GRAB honeypots, and settled on a sample that happened to come in via the NYC honeypot. 50/53 detection ratio on VirusTotal, so let’s look into it in more depth.

Static Analysis

Running strings on the sample reveals only four strings that make any sense at all:


Looks packed to me, but not UPX like the last sample. PEiD identifies the packer as Upack 0.39 beta. I opened the file in PE Explorer and that automatically unpacked the malware (revealing many more strings than before), but I am going to take a shot at manually unpacking it anyway.

Upack is trickier than UPX, in my opinion. Opening the packed sample doesn’t show a clear jump to OEP, so I opened it in Olly and went to where the code for LoadLibraryA is found by pressing ctrl-G and then going to kernel32.LoadLibraryA, then set a breakpoint on the first instruction:


I watch the malware call LoadLibraryA seven times, ending with Mpr.dll, and then hitting run again causes it to run and not hit the breakpoint again. Restoring the VM snapshot, I go back to where Mpr.dll was called and then set another breakpoint on GetProcAddress, and then run through that five times until it appears that GetUserNameEx is the final function called with GetProcAddress before the rest of the program runs and the second breakpoint is no longer hit.

Stepping through the rest of that particular call to GetProcAddress and returning to the rest of the code, I’m ready to start stepping through the remains of the unpacking stub to get to the actual code entry point:


After following a few branches, I see what I believe to be the entry point:


This doesn’t look too typical for me in terms of address and code, but mainly what I was looking at here was a relatively long block of code compared with the branches I just looked at, plus starting at 756AA4E9 you can see what looks like it could be the start of a function with PUSH EBP | MOV EBP, ESP. Trying to dump that as an OEP didn’t really work – I did get something that I could disassemble and also do other analysis on, but this doesn’t seem to be the right place. Using OllyDump and its feature “Find OEP by Section Hop (Trace Over)” got me to this general area which looks much more promising:


Checking this against the automatically unpacked file, this is the entry point area. What’s sort of strange is that whether I dump this process from the other address above (756AA4E9) or the one right here (4023A0), I end up with basically the same dumped file and OllyDump can’t do anything with the import table. ImpRec doesn’t work either, and either way I’m left with something that doesn’t function but nevertheless offers a lot of interesting data statically or in disassembly. Since I was successful with the automated tool, I’m going to move on to static analysis of the unpacked sample that I obtained with PE Explorer.

Going through the meaningful strings from the unpacked malware, we now see a more normal set of sections:


I don’t typically see a .code section, but this must be the equivalent of the .text section containing the sample’s code. I also don’t usually see .idata, but this should have the import function info which I’m more accustomed to finding in the .rdata section. I’m guessing that something is contained in .rsrc, but we’ll get to that later.

I see some function names, and date/time strings, but then I see a very long list of three digit numbers (here’s just an excerpt):


I wonder if this is being used in some fashion to “construct” IP addresses. I notice that some of the “special” numbers like 239 and 255 are not included in this list, though if this is what it’s being used for, one would think you’d see numbers below 130 also. These could also be ports.

Below this, I see some interesting strings that remind me of some of the stuff revealed in my analysis of Pepex:

That SMTP server is an exact string from the Pepex sample I took apart previously. Those other addresses could make for some interesting signatures once we get to that point. After this, we see many strings of inexcusably horrendous passwords (crap like 1234, angel, password, passwd, BUMBLE, asdf, asdfgh, 4321, db2admin, and so on).

I see what looks like the framework for constructing an IP address dynamically:


Below that, something very interesting:

Subject: Hello
From: <
From: “Microsoft” <>
Reply-To: “Microsoft” <>
Windows Genuine Update
Windows Update

This looks EXACTLY like some of the info pulled from Pepex. We see the same email addresses in use as in that other sample. The IP address points to Google. I’m starting to think that this is a Pepex variant, if it wasn’t already pretty clear. Strangely, the antivirus products weren’t too consistent in naming this sample when scanned, though I recall that one of them did identify it as Pepex. I wonder if that lsascv.exe file is what the sample uses to install itself and achieve some stealth, and the Windows Genuine Update string points to additional stealth / persistence methods.

Further on, we see:

Subject: %s|%s|%s

Again, something to keep in mind. This might do something with lsass because of lsass’ privilege levels and API access. Finally, that Subject: %s|%s|%s is the same string we saw in the other Pepex sample for constructing the spam subject line.

We see a bunch of OS names:

Unkown [sic]

I find it interesting that this is the same list as in the other Pepex sample, however Win7 is not here (which I wouldn’t expect from a sample created in 2004). Perhaps the reason why we had so many problems with the other sample was because someone tried updating the code and screwed up.

I see many imported function names, but I’ll look at those when I view the file in PEview, as it’s an easier interface. One final and very interesting set of strings:

!This program cannot be run in DOS mode.
Corrupt Data!

Looks like we have another file inside. I’m not sure what a .petite section is but it’s not a normal section like .text, .rsrc, .rdata, or others. Some weird error messages follow, so perhaps this is a packed file within the previously packed malware. After that I see a handful of process names and library imports, so I think we’ll need to continue digging to get to the bottom of this.

PEiD doesn’t detect and packers, under any settings. KANAL, however, detects a zlib deflate reference at 0000BE74 / 0040D474. Resource Hacker shows an obvious file stored in the resource section that is named “FILE”:


This file, however, is packed, using Petite 2.x:


KANAL also sees a reference to zlib in this file from the .rsrc section. Depending on how it goes analyzing this malware, I may look at this file in a follow-on analysis. Also, please see the following note from the readme file inclued with the current version of Petite, which is another reason why I’m probably going to tackle this in a subsequent analysis:

There is no Petite decompressor. So if it is not possible for you to
reinstall or recompile a file, then you should keep a backup of the
original incase[sic] you should want to go back to it at any time.

Opening the main malware file in PEview doesn’t reveal anything weird as far as some possible anti-debugging stuff – number of data directories is 0x10 and no TLS table. Imported libraries are Kernel32, User32, AdvApi32, and WS2_32. Here are some of the interesting things that can be seen as imported functions under each library:

RegOpen/CloseKeyExA, RegSetValueExA, Create/Open/Start/DeleteServiceA: Based on these imports and the prior work done on the other Pepex variant, I’m guessing that this is used to both achieve persistence and also start the malware as a service.

CopyFileA, WriteFile: I see a call to CopyFileA but not to DeleteFileA, so maybe this file makes a copy of itself and then deletes itself some other way when it installs. This also could mean that this file relocates some system file so that it can put itself in between the user and the legitimate file (maybe it gets in between lsass.exe, for instance). I suppose that one clue that this is not the case is that I don’t see any exports, but we still don’t know how the file from the .rsrc section functions yet. WriteFile is always good for looking for file system signatures.

WaitForSingleObject: perhaps this malware creates a mutex.

CreateProcessA: Always good for signatures, and also this means we’ll need to look out for child processes of this main malware process. Could possibly also be used to load drivers.

The interesting thing here is that I’m only seeing client-side functions imported (socket, connect, send, recv) but not server-side functions (like bind, listen, accept).

Dynamic Analysis

For the dynamic analysis, I ran and recorded the packed malware two times – once as a regular user, and once as an administrator.

Watching the run as a regular used showed a ton of activity taking place in Wireshark. RegShot didn’t reveal much going on. There was a UserAssist value added under HKU, but other than that, no other changes in the registry or file system that could be linked to the malware (speaking strictly from the RegShot perspective). Process Explorer revealed only the single malware process being created (PID 2576) but nothing else. It could be we missed other stuff happening in Process Explorer, so we’ll look at Process Monitor and other places too. I’m not seeing anything in Autoruns, so perhaps persistence wasn’t achieved.

Looking in Process Monitor, I see that the malware did not appear to spawn any child processes. The main things observed, some of which match up with the static analysis, include:

– reads the current version of Windows through HKLM
– many registry keys related to networking are queried
– the malware gets the computer name from the registry
– the malware creates 256 threads, and this is the final set of actions recorded by Process Monitor

I’m not seeing any files being written, or any registry entries being added or modified (values or keys). The Wireshark traffic is more interesting. In only a few minutes I could see a few tens of thousands of packets being sent out to apparently random IP addresses. Take a look at the protocols:


Basically all TCP. I didn’t see any addresses resolved, however endpoints revealed something interesting:


Thousands and thousands of lines of traffic on port 445, which is associated with SMB (which is where this sample came from on the honeypot, by the way). Looking over on the UDP tab of this window:


We see traffic on some broadcast IP addresses and on ports 137 and 138 which, for UDP, are associated with SMB also (NetBios API). There’s also traffic on port 1900, which is the UPnP port that we saw a lot of action on in the honeypot statistics.

Reviewing the recorded malware activity that was run as an administrator didn’t reveal any new or different behavior. The same activity both on the host and the network was observed.

I didn’t see any activity on the IP address we found in the strings of the malware ( I dumped the traffic from Wireshark and then ended up with 39,203 unique IP addresses from that. I did a little research into where these IP addresses were located, and with whatever whois data I was able to obtain, the vast majority of the IP addresses are in the USA with some falling outside the country:


Disassembly and Debugging

Opening the unpacked malware in Ida, the first thing we see the sample do (in winmain) is call WSAstartup, and then then there is a call to a sub at 4020E0 which imports some DLLs. The DLL names are obfuscated, and 4020E0 builds the imports in the same manner as the other Pepex variant. Following some branches, which I’m finding difficult to figure out just using Ida, we either move towards a “scanning” branch (which is the behavior that I’ve observed so far) or towards the installation branch. The installation branch begins with a call to 401950, which starts with loading the binary that is in the .rsrc section and then writing it as %SYSTEM%\lsasvc.exe, which makes for a nice file system signature:

Then, later on in this sub, we see the file being written and then a process being created from it.

The next sub that is called, 4018E0, sets up persistence for the newly installed malware by adding it to the registry (under the name “Windows Update”) to run at startup:


This also makes for a nice host signature under “SOFTWARE\Microsoft\Windows\CurrentVersion\Run”.

Sub 401000 involves some calls to gethostbyname and then a loop that writes a series of IP address strings to a buffer. After this, we see a string being put in a buffer:


Then we see a call to GetVersion and then the system derives an OS name (one of the strings mentioned earlier such as “WinVista”) and this string is passed to the buffer also:


Following this, we see an email address being pushed onto the stack and then we get into some really interesting stuff beginning with a call to 401210:


Before getting into 401210, I’m going to take a quick look at the alternate branch that this sample seemed to follow when I ran it in my test environment. This is the branch that was taken at the conditional jump at 40243F which branched us away from the installation/system inventory/email generation branch and instead did the IP scanning and thread creation.

Going down this alternate branch results in a call to Sleep (for 100ms) and then an indirect call to sub 402C50. This is a somewhat large sub that generates IP addresses through a combination of calls to GetTickCount and generated random numbers. There is a loop related to thread creation, and we can see where the condition jump is put in place in order to create the 256 threads we observed during the dynamic analysis:


Note that I displayed the number in base 10 for clarity.

Also within this overall thread creation/scanning sub, there is a call to a fairly deep branch called sub 402840. This sub begins with establishing some network connectivity and then calls another sub, 401F20. This sub contains several indirect calls (annoying). I see something being done with the string “administrator” so it’s possible that this is some sub that either logs into an account somewhere (or tries to do so). We do see a call to sub 401AE0, though. This sub makes a reference to IPC, and then appears to send system inventory information to the address:


Then after that we can see stuff being done with lsass.exe (notice also the hard coded directory of \winnt\ rather than an environment variable). Here are another couple of examples of hard-coded directory references:


After setting up with these paths, we see a call to 401800. Here we see the malware being set up and started as a service:


Windows Genuine Update” and “Wupdate” are nice signatures to be aware of.

Going back to the large branch, where we really get into the heart of this thing, sub 401210 begins with a connection to and then a check of connectivity. If we get past that, then the malware starts to build a set of SMTP commands:


This gets sent, and then checked for errors again:


If at any time we have an error, the sub will exit. Next we see more SMTP commands being built, this one showing that this mail is from


Continuing through the code, we see where the recipient email address is passed via SMTP, and then we see where the malware starts to build out the area for the body of the email:


After this, we get to an area that I’m not sure I fully understand:


What it looks like is happening here, is that the string “” is pushed onto the stack twice, and then these two strings are compared with a call to strcmpi (which is deprecated according to MSDN). Then, there is a conditional jump based on this comparison – If the strings are the same, then the function should return 0 and therefore this conditional jump should always be followed in this instance, which would take us down the branch on the left. If anyone out there has a better understanding of what is going on here, please let me know, as it appears that we have a situation where there’s a condition jump that is never followed. In any case, on the left branch, we see some more signatures that were common with the other Pepex variant analyzed (,

At the end, we see the wrap up of the SMTP traffic and the return:


At this point, I’m done looking at this sample. As we’ve seen, it’s closely related to a prior sample, except that this one actually seems to work so we were able to observe more functionality. I might take a look into manually unpacking the file in the resource section since this is a packer that is new to me and this might make for an interesting analysis.

Findings and observations:
Mass-mailer worm. Similar to the prior sample analyzed, which I believe was derived from this new sample as this sample did not appear to have the execution issues observed previously. Sample appears to both scan new IP addresses, both for remote and local systems, probably with the intent of spreadnig itself. It also contains functionality around reporting system inventory and sending spam messages.

– Block ports 445, 137, and 138 as this is where this sample was obtained and this sample was observed connecting to remote and local systems on these ports
– Usual recommendations against opening unsolicited mail (especially with attachments)
– Filter email associated with “”, “”, and “”, “”, “

Interesting, old malware. It was good to see this worm running successfully so as to get a better opportunity to view its capabilities.



Manually Unpacked:

Automatically Unpacked:


Continuing on the subject of honeypots, I wanted to see if I could get something set up as an ICS/SCADA honeypot. I’ve noticed traffic on some of the GRAB series honeypots that could be Modbus connections, for instance. I’m also pretty interested in ICS/SCADA in general, so I looked into whatever I could find regarding honeypots that I might be able to set up myself. In the end I set up a single Conpot honeypot, and I thought I’d share my notes in case it helped save someone some time.

I identified several potential honeypots to try:
– Digital Bond’s SCADA Honeynet
– Cisco CIAG’s SCADA Honeynet
– Fieldbus Honeypot
– SHaPe honeypot
– Conpot

Ultimately, Conpot was the only one I got to work. Here are my notes on everything:

Digital Bond’s SCADA Honeynet
This sounded like it would be the most robust and realistic of all the honeypots that I could find, but I ran into issues during installation. First, the documentation and system is from 2006, so a lot of the instructions are really out of date (for instance, one document referred to installation on an Ubuntu 6.x system). I ran into a few issues while installing dependencies, but I was able to get past those — specifically, instead of xlibs-dev, install libx11-dev, and automake1.11 instead of automake1.9. The real issues came when I tried to install VMware server. This used to be freely available, but isn’t really available anymore from VMware (I’ll explain what I mean by this). The installation instructions from Digital Bond specifies a link to download an old version of VMware server for Linux (1.0.2) and this link still works, however with my current version of Ubuntu (16.04) I ran into too many issues with the installation and just gave up on it.

Cisco CIAG’s SCADA Honeypot
This system requires Scientific Linux 3 and a formatted, empty floppy disk. Next…

Fieldbus Honeynet
This system came up during searches for these types of honeypots. The info sheet indicates that it handles Modbus and also lists some contact info for creators, however trying to reach out to them resulted in bounced email. Not sure if this is publicly available, and searching didn’t turn up any other email addresses to use to contact them. The overall project page can be found here.

SHaPe Honeypot
I found this one through an interesting academic paper about electric power substation honeypots. They have the source up here. I liked the idea that this would be a module for Dionaea, which meant that I could either add this module to an existing honeypot, or quickly set up a new honeypot running Dionaea (which is very easy) and just use it to run this module. I ultimately ran into various issues during setup, and at this point I was pretty burned out and not interested in pursuing this anymore. If you have more luck, please let me know and maybe I’ll give it another try if you can send me some ideas on what to try.

This was the first such honeypot I had heard of, and ended up being the one I installed. They have a great website for the honeypot, and installation was pretty easy. Instructions were sparse but clear. I installed from the git repository, not using pip. I did have issues during installation, but nothing out of the ordinary. One issue was that I needed to install libmysqlclient-dev (apt-get install libmysqlclient-dev), no big deal. The other issue I had, though, appears to be a known issue but again the fix was pretty simple. Basically, I had to downgrade stix and cybox to lower versions and then I was fine:

sudo pip install 'stix>=,<'
sudo pip install "cybox=="

I copied both of those right out of the issue logged on the github page and then I was no longer getting errors. To keep Conpot running in the background after logging out, I used setsid in case you’re wondering how to do that. Finally, to test the honeypot, I went ahead and tried connecting to it:

2016-08-03 15:42:07,581 New Modbus connection from x.x.x.x:38816. (x-x-x-x-x)
2016-08-03 15:54:31,643 New Modbus connection from x.x.x.x:38828. (x-x-x-x-x)

Seems to be working (the xs are in place of my connection info).

I found a great article by Darren Martyn over at xrl about OPSEC for honeypots. There’s a lot of great points there, but overall — DON’T leave the default Conpot settings in place when you run your honeypot. Go to the /conpot/templates/default directory (or the directory for whatever template you are using) and look in the .xml file for that template. Here is my default Conpot template before editing:


You should see the issues right away. Darren’s post highlights some of these, but to recreate his quick check on this, I did a search on and look what I found:


Don’t be these people. Change your default settings. I found dozens of these honeypots all over the world this way. One note — you might go to change the template settings in the /opt/conpot/templates directory. Per this post, go to /usr/local/lib/python2.7/dist-packages/Conpot-0.5.1-py2.7.egg/conpot/templates [you may have a different version number than I do] and change your templates there. You can test it quickly to be sure by just pulling up your site in your web browser.

Digital Ocean is not great as a host for this type of honeypot because it’ll show up as such in a search — putting it another way, why would an ICS/SCADA system be on a Digital Ocean VPS, or AWS, or Doesn’t really make sense, but for now that’s what I have so I went with another droplet there. Ideally I’d put this new honeypot somewhere that it might actually make sense to have such a system, but I don’t have access to any such facility. I did, however, look around the area and do a little research on some ICS/SCADA sites, and entered values that should be plausible enough to collect some attacks in the honeypot. I’m not going to post any of that info here as that would potentially ruin the honeypot I set up, but what I’d say is look around the area where your honeypot is hosted and try to create a plausible “identity” for your system. Try to also pick a system that 1) uses Modbus and 2) might actually be in use at your choice of cover story. We’ll see how successful I was at setting this up, and hopefully at some point soon I’ll have some interesting info to share about this new system.

I’ve decided to place ICS/SCADA honeypots under the series JUMPSEAT.


I thought it would be a good time to talk a little bit about the “constellation” of honeypots that I have going right now, and what statistics I have gathered on their activity. My Dionaea honeypots are organized under the name GRAB, and the first GRAB honeypot was located in NYC. Several days later I set up the same kind of honeypot and VPS in Frankfurt, and on July 30th I created two more in Singapore and Bangalore.


I’m not completely satisfied with this constellation just yet – I feel like there are a few gaps here that would be relevant to me. I’m glad that I have coverage in the US and Europe but I’d like to have some coverage in LATAM and Africa. The main reason that I was able to get the VPS coverage in these current locations so quickly was that this is where Digital Ocean has datacenters, and it’s incredibly easy to get a system set up with them (I set up both of the new VPSs and honeypots simultaneously in about 10 minutes). I feel that I absolutely need to get something created in the Russian Federation, and have been looking into options for this. Africa would be interesting, particularly around the Horn, but I have no idea about what the state of hosting is for this region. LATAM would be interesting, and I wonder if there is something good available for hosting in Argentina or Mexico. I’m hoping that the GRAB system I have in Singapore is sufficient for covering East/Southeast Asia and Australia, but we’ll see how that turns out.

My reasoning is that I imagine that while there are malware that will propagate world-wide (and I’ve already seen some samples show up in both NYC and Frankfurt), I imagine there might be some more regional samples that are targeted to a specific region or even a specific country or userbase that I could collect by having honeypots in various locations. I’m also interested to see the levels of activity in the various regions over time, which is what I’m going to get into next, starting with the NYC honeypot.

Some quick notes on how this data was obtained and graphed – I have my Dionaea honeypots set up to store data in sqlite databases. There are a few options out these for graphing (e.g., there’s a recipe in the Malware Analyst’s Cookbook for using gnuplot) but I used DionaeaFR. I thought that the best instructions for setting this up were found at Koen Van Impe’s site but even so I had some issues as far as getting it to run on my system. What I ultimately did was follow those instructions but use the most up to date versions of the dependencies (such as nodejs) when I did my install as the exact instructions posted there didn’t work on my system. I also ran “npm install -g promise” in addition to installing less as this was mentioned on another website.

New York City
Connections: 617,440
Unique IPs: 12,586
Files Downloaded: 48


Since this is my first time doing this, I don’t have much to compare these results with, however that seems like a LOT of connections. I’m not shocked to see that most of the connections came from the United States but it was interesting to see that the most unique IP addresses came from France, Spain and the USA. For all that activity, not too many binaries recovered, but even so I’m backed up on analysis. Romania was unexpected (0.71% of the total IPs).

A mix of services, but interesting to see that the vast majority of activity came in over UPnP.

Therefore, I suppose it’s not a shock that the most activity also came through port 1900, the UDP port for UPnP.

The top IP address (with 80,000 connections) can be linked back to Tinet in Germany, though I’m not getting much out of this whois record, just info about Tinet. VirusTotal finds no domains resolving to that IP address and actually puts it in France. Similarly, the next one on the list,, links back to Telefonica in Spain (VirusTotal also has not resolved anything to this address, though it does not find any location info on this IP). This isn’t showing too much, as it’s sort of the equivalent of tracing an IP back to Level III or Comcast. The ninth IP on the list,, lists info as BlazingFast LLC in Kiev Oblast, Ukraine. They seem to be a hosting provider, maybe I should set up a honeypot with them…nothing about this IP address in VirusTotal. Not much comes up about any of these addresses.

Here’s a map showing the attacker locations:


Next is the Frankfurt honeypot – It’s interesting that this honeypot was created several days after the NYC honeypot, and yet it had more activity (but fewer files downloaded).

Connections: 702,786
Unique IPs: 10,896
Files Downloaded: 35



Pretty similar proportions to the stats from the NYC honeypot. There’s a certain country that doesn’t show up on either graph, which is surprising. Maybe it’s lumped into “others”, but keep in mind that the lowest ranks on this graph make up less than 1% (e.g., Germany on this chart is only 0.91%) so I’m surprised that these others ranked high enough to show up here.

Services is really very similar to the NYC results, UPnP being the most popular by a huge margin, along with port 1900:



Looking at the IP addresses from Frankfurt, there are several overlaps, either in terms of the same IP or just the same subnet. Only and are new.

grab12 is interesting – its whois record says “Santa Clara County Office of Education” in San Jose, CA. I’m wondering why so many connections would be coming from here? Some searching showed that someone’s already added this IP to FireHOL’s blocklist. I wonder what the story is with this one. is just another Telefonica IP address, nothing too interesting there.

Here’s another map of the attackers, with an alternate view of the same data as well:




New sample in from the NYC honeypot – 50/54 detections on Virustotal, so let’s take a look.pepex1

UPX is a popular packer used more for compression than security. Packing the malware does obfuscate it, but typically UPX isn’t very hard to figure out compared with certain other packers. We can actually see some stuff “leaking” through the packing:


At the end we see a tiny number of function names, along with .dlls such as WS2_32.dll and others. Along the way I saw bit and pieces of a string that suggest that this malware might construct emails, so maybe this malware is spam-focused.

PEiD confirms this, and also gives us some other info like the entrypoint:


There are various ways you can approach unpacking. Something like UPX can probably be unpacked with an automated tool (which I actually end up doing later on in this analysis), but I actually like unpacking things manually. One thing you can do is open the file in IDA and see if there are any “far” jumps within the code, as this is probably the start of the unpacked code. In this sample, the entry point of the malware was at 4098A0, but a little bit down from there at 409A2C I see this:


Sort of strange to see a jump to a place relatively far away from where we are now. I opened this in Olly and set a memory breakpoint (on access) at 404C50. After this breakpoint was hit the first time and I noticed that code started to appear where there was previously just meaningless data, I set a regular breakpoint and then came back to this area once that was hit:

pepex5I’m using a plugin called Ollydump to dump the unpacked process:


We still see some of the same UPX-related junk in the beginning, but looking through the strings, we start to see some really interesting (and unobfuscated) stuff:


Now we can really take a look through this thing.

Static Analysis

Running strings on the unpacked sample, one of the first things we come across are what appear to be really bad password choices:


There are some that on first glance appear like they might be not completely horrible choices like “baseball”, but those that look like they might be OK are actually just some silly keyboard patterns, such as “qazwsxedc” which is just the first three alphabetic columns on the left side of an English keyboard. Moving on through the strings, we start to see a few more interesting things such as what appears to be the construction of an IP address and what might be a name given to this process in case it’s run as a service:


Few more pages in, we see some SMTP commands and some strings that look like they are part of an email to make it seem more legitimate, as well as some specific IP addresses:


Going through function names revealed by strings and by PEview reveals some interesting info about how this sample likely operates (meaning, until I observe the sample I can’t just assume that this is definitely what it does regardless of what functions are mentioned or imported):

– I see several functions around opening/copying/deleting files as well as functions related to the temp file path. I always like to see these because it implies that there is going to be some file system change taking place that can be used to both construct a signature and also identify the malware objectives. One string recovered was “Isass.exe” which is supposed to mimic “lsass.exe” – perhaps this sample copies itself somewhere as “Isass.exe” as a stealth measure.
– WaitForSingleObject appears to be called, so there might be a mutex created by this malware that could also form a signature.
– I see multiple functions related to services such as OpenService, CreateService, StartService, DeleteService, that suggest that this might be how the malware achieves persistence and stealth. I saw a few strings earlier that might make for good fake service names to blend in with other, legitimate services running on the host.
– There is an import of WS2_32.dll and several functions such as connect, socket, listen, bind, send/recv, gethostbyname,WSAstartup, inet_addr and so on that suggest that 1) there is a networking component to this malware and 2) since this is a lower-level networking dll, there will probably be some fabrication of traffic info (such as header info) to make the malware traffic blend in better with legitimate traffic, which also helps us identify network signatures (particularly in the case of poorly-written fake headers).

PEview reveals nothing unusual in terms of possible anti-debugging steps (i.e., number of data directories looks fine, no TLS). KANAL detects no known crypto signatures. I saw strings that look like a “normal” set of sections (.text, .data, .rdata, .rsrc) but Resource Hacker wasn’t finding anything. I might try to mess around with this later to rename the sections in the unpacked header, but for now I’m just taking note of this in case it’s useful later.

Dynamic Analysis

I tried running this sample multiple times, as a regular user and as administrator, both with a simulated Internet connection and on a real one, but absolutely nothing appeared to happen. The packed sample ran and then exited, while the unpacked sample crashed shortly after execution.

Nothing interesting is coming up in Wireshark, process explorer, autoruns, or anything else. The process monitor data basically shows the malware process being created, some registry lookups (nothing obviously interesting there either), some libraries being loaded, and then the malware terminates.

I’ve seen strings that suggest that this malware could run on various versions of Windows, including Windows 7 which is what I’m running in the analysis VM. Perhaps there is an issue with the Windows environment, but at this point I think that there must be some issue with the malware not liking VirtualBox. I’m going to have to look through it in the disassembly and the debugger to see what seems to be preventing this sample from fully executing.

Before doing this, I tried a couple of other things. One was I ran the unpacked sample through Import Reconstructor (ImpRec) to see if maybe there was just an issue with the way the import table was set following the unpacking.


This didn’t help, the sample still crashes. During a quick glance through the disassembly, and during debugging, I didn’t notice anything checking for artifacts left over from VirtualBox or VMware, but even so I tried terminating all VirtualBox related functions and then rerunning the sample, but it didn’t help. It’s possible that this is just a poorly formed piece of malware that isn’t working right in my environment, but that seems too simple of an explanation, so I need to dig into the disassembly more.

Disassembly and Debugging

Basically what’s observed when debugging is that this sample almost immediately starts to encounter exceptions. My feeling is that this isn’t simply an anti-debugging / anti-analysis technique in place. There absolutely are some things that look suspicious when I run the sample in the debugger (for example, a call to NtRaiseException followed by INT 3, or there MIGHT be something going on with the PEB structure beginning at fs:[30]), but the thing is that this sample doesn’t seem to function at all outside of the debugger either. The unpacked version crashes shortly after execution, and the packed version runs some innocuous functions and then terminates. I see many exceptions taking place, but nothing that appears to look for a VM (either VMware, VirtualBox, or another). I looked through all of the process monitor results to see if the malware checked:

– user/computer name (it checked the username, but this would not indicate a VM)
– registry keys/values (it did check some, but nothing checked would indicate a VM)
– Files/directories associated with VirtualBox or Vms

Nothing was apparent. I checked the unpacked disassembly for:
– CPU instructions (sidt, sgdt, sldt, smsw, str, in, cpuid)
– Timing instructions (rdtsc, GetTickCount, QueryPerformanceCounter)
– GetTickCount is actually seen many times but not in an anti-debugging context
– Checks on running processes, services, or mutexes
– Hardware info checks
– OS info checks (it checks for the Windows version but nothing that would indicate a VM)
– Checks for INT 3 or others such as 0xCD03 (there is a line where 0CCh is moved into AL, but this is part of a coding sub, and not related to anti-debugging)

I’m just not seeing anything that indicates that this thing is checking for a VM or a debugger. One thing I did notice however, was that there seems to be an issue in the code between the packed and unpacked versions of the malware:

Packed location 404C50:


Unpacked location 404C50:


The OR DWORD PTR DS: [EBX+68FF6AEC], 004051C8 instruction doesn’t make sense and immediately starts causing exceptions, which then seems to send the unpacked version into a tailspin. I’ll use the unpacked version just for disassembly, but will continue trying to debug the packed version.

I eventually got UPX and used it to automatically unpack the sample, and the unpacked version is much cleaner than what I had dumped manually. There is a section at 404C50 that pretty much matches exactly what we can see at the RCE Endeavors blog as something that sets a new exception handler which would allow for sneaky code execution. I feel like there has to be something there. Looking at the code that was unpacked by the malware again:


Following along with the article, at 404C53 we see 0FFFFFFFFh being PUSHed and then 004051C8 PUSHed (scope table and the try level). At 404C5A we see PUSH 00404DD0, which is a jump to __except_handler3 (4 being the topmost exception handler, IIRC). Then we see the value at fs:[0] being put into EAX (fs:0 is the start of the TIB, and in my case is 0018FFC4). Then this is PUSHed, and the stack pointer is moved into fs:[0] (which, in my case, is 0018FF78). This is what we see at 0018FF78:


This is something I’ll have to come back to someday, as I can recognize that something is going on here but I just can’t figure out what. On one hand, it makes no sense to me that someone would create and propagate a worm that didn’t work. On the other, there are some design decisions in this sample (like hard coding directories, plaintext domains and IP addresses) that calls into question the quality of the construction. I’m going to concentrate on disassembly of the rest of the unpacked file to try to see how the rest of it works.

404C50 is where we see the shenanigans with the SEH:


Down below at 404D7F we see the call to WinMain.

Inside of WinMain, we see a call to __p____argc and then a comparison, then where the code wants to go is to the left side (i.e., not take the jump):


However, as soon as the call to StartServiceCtrlDispatcherA happens, a non-continuable exception triggers. Following this doesn’t get my anywhere, so I’m going to go back to where this JNZ occurs and make sure that we follow the jump:


Getting to the next block at 402F3B, the jump is taken again so I’ll modify the flags and avoid the jump again. Getting to the call to ds:strncpy, the sample again hits exceptions, so I’m just going to through the disassembly and stop debugging completely for now.

The code on the right is a bit funny because I did get that to execute successfully in the debugger, and you’d think that a malware author would not want the malware to have error messages pop up. This is one of those examples I’m thinking of when I question the design of this sample.

Below all of this, we see a couple more branches but both ultimately call sub 402C30. This sub calls 402050, which reads a file called stm8.inf located in the Windows directory (or we see this being created if it doesn’t exist). After this takes place, we see a call to a sub at 402970 which involves moving lots of data into various registers and then several calls to sprintf to write this stuff to buffers. After those sprintf calls, there are several calls to LoadLibraryA and then several calls to GetProcAddress, so here we’re seeing the sample call several different libraries and functions before moving on to the rest of the code.



Again, if this sub fails, then the code exits. The pattern here is pretty much if any of these parts fail to execute successfully, the code will terminate. This might help explain why the code appears to do nothing when being executed in the VM. Following the success of the previous sub, there’s a call to WSAstartup (version 2.2 requested) and then the code flows to a call to sub 403BF0.

403BF0 is a large sub that begins with moving the byte 88h into BL before storing a string (a total of 0x40 times, based on the value moved into ECX) and moving several more bytes into other offsets:


I opened this in the debugger and patched the code to call 403BF0. This initial block creates the following string in memory:


The next bit of code loops through this string (up to 16 bytes long) and then XORs each byte with 0xEF, which leaves us with the string


This string then gets PUSHed and then sub 403170 is called to work with it. There are several subs nested here, one of the main ones called next is 4049F0. Within sub 4049F0, you see a call to DnsQueryA and then you see several strings being put on the heap:


The strings are:

If 4049F0 is successful, then you jump over the call to 404AF0 which appears to gather network info on the local host and then I presume tries to gather the info above in another way since following this branch would mean that 4049F0 failed. Back in sub 403170, there’s a call to GetTickCount and then a test between AL and 3, then a conditional jump to either exit and return 0 or continue with the function. In my debugger the code continued and took the string and passed it to a call to 403070. We see more work being done with the string, the heap, and calls to GetTickCount. We then pass the string to 403030. More comparisons, more movement of the string, and finally the entire 403170 sub returns and we end up at 403C75, where we come upon another interesting set of branches:


The debugger isn’t following the jump (which leads to another XOR decoding). For now I want to see what’s in the XOR branch so I’ll mess with the flags so we go there.


As you can see, it just ends up decoding Much later on in this branch, we see that string being passed to sub 4031D0. There we see a call to GetHostByName, and if that fails, then the function returns 0 and eventually this branch dies (I’m not connected to the Internet while I am running this instance), but I’ll change the flags and keep this going. Eventually this branch loops back up and runs through the same iterations but for the “alt%d” variations such as alt1,2,etc.

All roads seem to lead to location 403E4E, which checks to see if any of the branches leading up to this point were successful or not – if not, we exit. If they were, then we continue on to the hard-coded IP address blocks.


You can see the string being moved into EDI, and then shortly after there’s a comparison using that string, and then in my case it moves on to the next string which is 173.1944.68.27, and so on until it finds the IP it wants or it runs through all of them. Then, the return is made to 402C30, which we left a long time ago, it feels.

At this point, something weird happens again involving exception handling, and we find ourselves blown out into 7- land (so to speak), but I patched something to get us back to 402C92 which is where I wanted to continue from. We see a call to GetModuleFileNameA (which fails, incidentally) and then a call to GetUserNameA (perhaps to form part of the data used to create the mass emails?) and then the username is passed to strupr to make it all upper case.


We work our way down to 402D79 without any further intervention in the debugger, and it appears we’re in the right place to begin constructing totally legit-looking emails:


But first, a call to 4019C0 where it looks like we have another one of those encoding subs. The first encoding loop here decodes this little string:


ows\\CurrentV. Next loop in this sub decodes:


E\\Micro. Next loop:


ersion\\R, then:


SOFTW, then:


soft\\wind, then finally this entire mess gets passed as “SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run” under HKLM to RegOpenKeyExA:


If this operation is successful, then we skip the rest of this sub. If not, then we go on to decode more stuff and do more things, so I’m going to keep going on this branch.

Soon we see a call to LoadLibraryA for advapi32.dll, and then another XOR decoding:


The malware decodes the string RegSetValueExA:


kernel32.dll gets loaded, then the function RegSetValueExA is imported:


Then later we see what appears to be this malware being set up to run at boot under the guide of “Local Security Authority Process”:


We can see this change being made in Process Monitor:


It’s also apparent in Autoruns, though it appears the name of the file isn’t quite there just yet:


Then after all of this, a call to RegCloseKey and then back to the other sub where we can finally get into crafting some email (I hope)!

A few dozen lines in, I see a strange subject line being created:


I also saw the user name string that was converted into all upper case earlier. I accidentally stepped-over one of the subs here at 401E90, but in there you see that and a nested function create and bind a TCP socket and then call listen, looping until the string “” is seen, then back to the previous sub. We see the string “Subject:” put in a buffer with a call to sprintf, and some further manipulations of strings. There’s a call to sub 402350, where we see a call to GetHostByName (a deprecated function, according to MSDN, which probably speaks to the age of this sample). If this function fails (which it did in my debugger), then the sub returns, otherwise it builds a string out of an IP address from the GetHostByName call. Soon after this, we see the “Subject:\09h\30h\09h\30h” string in its current form being passed to a call to 402170.

Sub 402170 is the sub where the Windows version is obtained and named using one of the strings we observed earlier, e.g. “WinVista”, “WinNt”, “Win2000”, “Unknown”, “WinXp”, “Win2003”, “Win7”. This done via a call to GetVersion and then parsing that info to identify the version. The sample correctly identified the version running in my test environment (Windows 7). Before returning, there is a call to a sub at 4022C0 which is to obtain the local and system time, and then this information is parsed into various pieces such as day, month, year, hour, etc. I imagine for the purpose of constructing the mass emails. Returning from these subs, we see that our subject line continues to change:


After all these changes to the string, including a few more minor ones, we return back to 402E92, and the a few lines later there’s a call to 4033C0 – THIS finally seems to be the construction sub. It begins with a whole lot of byte movements, reminiscent of the XOR encoding though I don’t see that happening here:


After ALL of these many things are MOVed around, we pass through a few conditional jumps that either take the whole mess and return (returning 0) or we do actually get to an XOR decoding loop – I didn’t have to intervene to get there, and the first string decoded is “nbweinf12160”:


So as not to make you sit through every loop like I did earlier, here’s what we get at the end of these three loops:


nbwein12160 [this email is no longer valid, by the way]

We get kicked over to a call to 403340, which is a sub that tries to set up some networking with one of the hard-coded IPs mentioned earlier, where we also see a call to ioctlsocket (nonblocking).

The debugger wants to follow the code over to where there’s another decoding sub called (402C70), which receives our subject line as an argument. Oddly, this branch re-encodes the subject line that was being constructed and then basically breaks everything down and exits. I’m reloading the VM snapshot and trying the other branch…

Unfortunately, that other branch also died, running into exceptions. Perhaps this is because of the patching I’ve done, maybe things are messed up now. I’m going to just try to get back to the SMTP part of the malware and see how that works.

I patched that last line of code to JMP 403690, so I can see how the SMTP commands are sent. Not too far into that sub we see the first SMTP command being constructed and then a large block of code related to a call to send:


Long story short, we see HELO ( being sent:


Since I’m not really letting this thing connect to the Internet, it tries to exit but I’ll keep intervening to keep it sending info. Next up is another big block of code, all pertaining to a call to send:

We can continue to observe the SMTP commands being sent in this manner. There are numerous conditional jumps throughout the code that necessitate intervention in order to keep going on the path I want. We see a few calls to GetSystemTime and some random number generation before the construction of the command that specifies the destination email address (in this run, no email address was populated):


It seems that this is meant to be a “Microsoft News Letter”:



We eventually see QUIT being sent, and then the socket getting closed:


And then the malware had a meltdown since I had been patching all kinds of stuff to jump around. This is about all I want to really check out in the malware in tandem with the debugger. Some other highlights include:

– Sub 401000 is where the malware appears to install itself by copying itself as the file Isass.exe (a string we saw earlier – it places this file in the %system% directory, though I’d point out that in this file it tends to hard code these areas (e.g., one branch of its code refers to the c:\windows\ directory, rather than using the environment variable)
– Sub 404010 shows that it attempts to run itself as a service called “Windows Genuine Updater”:


– Sub 404110 attempts to open this newly created service and start it
– 4015D0 looks like it might generate IP addresses using a combination of calls to GetTickCount and random numbers

Dynamic Analysis, Revisted

Now that I actually got the sample to do something, I’m going to revisit some of the things I would normally try under dynamic analysis which were unrevealing due to the sample not fully executing.

Taking a look at Wireshark, there actually was almost nothing that seemed like it could have been attributed to the malware except for a DNS resolution to which was something that was observed when I was forcing execution through the debugger. I suspect that the reason why there isn’t any SMTP traffic being observed is that while I was forcing execution of the malware in Ollydbg, networking was never completely started via a successful call to WSAStartup.

RegShot does show the following change being made to the Registry, as we saw earlier in the debugger and in Autoruns:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\Local Security Authority Process: “ %1”

Other than this, nothing else interesting came out of RegShot. Process Monitor also didn’t have anything interesting in it, apart from what was already discussed above.


This was a weird sample to work on because of the issues getting it to run. I don’t have a dedicated physical testing system, otherwise I would have tried it on there to see if I could get it to run properly. I’m torn between whether this was a very sophisticated sample that employed anti-VM techniques that I couldn’t detect (like the SEH shenanigans referenced in the post) or if it was just not well-written and this was causing the execution issues. Just because I didn’t find something doesn’t mean that it wasn’t there, but on the other hand my opinion is that there were several questionable design decisions throughout the sample, so… Not sure on this. This type malware appears to be very old. I’ve seen references to this worm going back as far as 2002, so perhaps this would help explain some of the execution issues also.

I didn’t see anything obvious as far as how the malware gets its email addresses to mail to, however we did see many examples of what appear to be bad passwords hard-coded in the sample. My intuition is that this program tries to harvest email addresses from the host computer. I didn’t see any C2 functionality in here, so I suppose this is sort of a fire-and-forget piece of malware. This sample doesn’t appear to have any clear goal in mind, so maybe it was created for its own sake.

Persistence is attempted via the registry and creating a copy of itself (Isass.exe) that is meant to resemble the lsass.exe file. Persistence wasn’t fully achieved, probably due to the malware not functioning correctly as I forced it through the debugger. I also didn’t see any movement of this sample through a network (or really anything like this in the code), though again, the sample wasn’t functioning 100% so I’m not sure it’s wise to completely rule it out.

Finally, it seems that Pepex is a fairly consistent name for this sample, so no need to name it like I did with BEAR.


Findings and observations:
Mass-mailer worm with execution issues. Design flaws reveal functionality and signatures. This sample was first observed 14+ years ago, but doesn’t seem to have any obvious malicious function besides wasting resources.

Detection is very high for this sample, probably due to age, so up-to-date AV probably would help mitigate this sample. Not opening suspicious files received via email or other routes also stands for this sample. Use of strong passwords (and definitely NOT the very poor examples found in this malware) is advised. Removal can be done by modifying the registry entry for persistence (if successful in the first place) and also the Isass.exe file.

Interesting to see this very old piece of malware, even if it didn’t fully run in the test environment. Not a terribly destructive sample, mostly just annoying.

Report: MalEXE002pdf


Manually Unpacked:

Automatically Unpacked: