Introduction

Not a month goes by without news about another new POS (point-of-sale) malware or credit card data breach. Obviously, details of this kind of breach cannot be made public (banks, ongoing investigation, reputation …). But what do we know really about POS malware? Can we create groups of malware and relate them to groups of cyber criminals? As is the case for standard malware, we need a honeypot for POS, so we can publicly share the TTP (techniques, tactics, and procedures) of POS cyber criminals.

The goal of this post is to explain how we created a honeypot for POS with open source tools and custom scripts, and to show the results from 3 months of running a honeypot (samples, TTP, groups …).

Infrastructure (First try)

The first infrastructure was hosted in Europe and included all the tools to monitor the honeypot (in terms of host and network).

• We installed Moloch as a full packet capture tool, very useful when you need to drill down on packets and sessions.
• An IDS based on Suricata and the SELKS distribution, always interesting to see directly what kind of malware is beaconing to its CnC.
• We also installed mitm-proxy, a python library that can be used for different Man-in-the-middle tasks.
• A local Bind DNS, to see directly all DNS requests in a text file
• And an OSSEC agent on the host, so we can directly create dashboards on specific events (in our case RDP connections).

Setup of the honeypot

Our setup was based on Windows 7 (32 bits). We installed a POS software (it doesn’t matter which one). We enabled RDP (TCP port 3389) with weak credentials (admin/123456).

We created a fake website hosted on the same IP, pretending to sell leather and fur items. The reverse DNS showed a “POS” in it.

 

The POS software with fake stock

The goal of the setup was to mimic an actual POS and to fool cyber criminals.

First infection

After 3 hours, we got a hit. A successful connection through RDP on our honeypot! But after analysis, we identified that the binary pushed on the honeypot was in fact the “Morto” worm. A really old (2011) worm that is still active, that is basically after the successful infection brute forcing RDP to try to infect a new host. More information can be found on the internet here: Microsoft Worm:Win32/Morto.A or here Trend Micro – Threat encyclopedia.

That was our first fail as this was not the kind of binaries that we are interested in.

Level 2

So we started from the beginning again. Let’s check our  list of words first to avoid the one tested by the Morto Worm.

1. We then changed our credentials to pos/pos.

Then we looked at the security features of RDP, and we found that Morto was not able to log in on RDP with NLA enabled (see here for NLA details: Microsoft msdn NLA).

2. We enabled NLA

We left it to run for 2 weeks but we didn’t have any successful logons (at least we removed the problem with the Morto Worm).

We then figured out that our honeypot was hosted in a country that implemented “Chip & Pin” (Wikipedia EMV) a long time ago! So our best choice would be the US, we then moved the honeypot there.

Infrastructure – reloaded

By moving the honeypot to the US we took the opportunity to add incident response capability with GRR (remote memory dump, remote file extraction…).

Infection

After 3 days, the honeypot was infected.

The attacker installed a 6 months old “Dexter” variant:

They event didn’t change the filename.

Investigation

We confirmed that the infection vector was a brute force attack on RDP.

The cyber criminal connected to a FTP to download the Dexter sample (and other tools).

The sample sends keystrokes to the CnC. The CnC was flagged 6 months ago as an “Alina” panel:

It is also interesting to note that the IP was hosting a lot of phishing websites:

By analyzing the traffic sent and received by the Dexter sample, we saw that the CnC was not answer properly and surprisingly it sent back the keylogged data!
This is very useful when you don’t have a keylogger installed on your honeypot. See below for a sample of the data which was sent back by the CnC:

It helped us to follow what the attacker did:

Here is a list of commands performed by the attacker:

• “net view”
• “net user”
• “get kerberosdrv.exe” –> Dexter sample
• “get fgdump.exe” –> hashes dumper
• “get readpsw56.exe” –> get LSA secrets

Second infection

Less than 24 hours later, the honeypot was infected by another attacker. This one was only looking for a proxy. So the cyber criminal started to install “Firefox”, then “Chrome” and CCleaner (to erase the evidence). He ultimately installed a software named “Socksescort” which is used to share proxies (http://seproxysoft.com/de).

Random binaries

With other infections, we saw other interesting binaries like a port scanner (“KPortScan”):

One cyber criminal even downloaded mimikatz directly from the github repository!

To resume below is a list of the types of binaries that we saw during the 3 months the honeypot was active:

• Dexter
• Alina
• Keylogger (perfect keylogger , …)
• Chewbacca
• Windows hash dumper (fgdump, …)
• Psexec (official binary)
• others (proxy, scanner, …)

The majority are already known on VirusTotal, and the time stamps were almost all at least 1-year-old.

Conclusion

The kind of cyber criminals that we caught on the honeypot didn’t seem to be very professional. They used old samples, they didn’t even seem to run the CnC but looked  just like affiliates. Almost 80% of the time, the traffic was recognized as malicious by an IDS with default open source rules.

But even if the techniques and tools were known, they could still do a lot of damage. You don’t need to be very sophisticated to steal credit card information and propagate the malware with trivial hashes dumping tools.