My Kippo farm has been largely retired as most of the captured sessions where becoming stale and ‘samey’. Thankfully however, I’ve still been getting daily reports thanks to this script (now available in BitBucket repo) and this morning something new caught my attention – a ‘guest’ attempted to turn the compromised machine into a BitCoin miner.
For anyone living under a rock for the last few months, Bitcoin is the first of a new breed of ‘crypto-currency’; essentially a decentralised monetary format with no geographical (or regulatory) boundaries. If you need a refresher, a good basic guide is here if you want to get up to speed.
Our guest connected from an IP address that hasn’t appeared in the honeypot logs previously; whilst the password on the root account is (intentionally) weak, I still find it unlikely that our guest got lucky on the very first attempt. Suspicions at this point are that either the compromised machine was identified as part of a previous compromise; anyone that has run a SSH honeypot for any length of time will be aware that attackers frequently attempt to use compromised machines to scan for other vulnerable victims and that successful rogue log-ins also often disconnect immediately – my assumption has always been that this is nothing more than automated scanners identifying and confirming valid credentials before reporting the system details back to their master for manual follow-up. It is also possible that this particular guest acquired a list of pre-identified vulnerable systems as a foundation for future activities.
How our guest found their way to the system is, unfortunately, pure speculation and for the purposes of this analysis largely irrelevant; what is more interesting is what they chose to do once access was gained. After (very) briefly looking around, and failing to determine the presence of the honeypot a 64-bit, bitcoin miner is downloaded. Details, for those that want to play along from home:
- Location (live at time of writing, browser beware) – http://orfeous.hu/btc/minerd64
- MD5sum – 007471071fb57f52e60c57cb7ecca6c9 (VirusTotal)
Once downloaded, the guest attempts to run the binary with the following parameters:
- -a sha256d –url=stratum+tcp://stratum.bitcoin.cz:3333 –userpass=orfeousb.vps:qwertz1234chmod +x minerd64
It appears that the guest has little experience with falling foul to a honeypot; when running the binary fails he (or she) downloads the same file, from the same location and attempts to execute the miner a second time. When this fails the guest simply exits the system (after being briefly fooled by Kippo’ “localhost” trick on exit.
Those paying attention will notice the link between both the domain and the mining pool username; this leads me to believe that the miner is downloaded from the attackers own system, not a compromised system subverted for this purpose. Whois records indicate that the domain was first registered July 2013 by a private registrant, include both name and address (redacted until verified).
Given the £-value involved with crypto-currency at present it should be no surprise that enterprising criminals are attempting to cash-in on the bandwagon, with hindsight I’d be more surprised if they didn’t seek to use compromised systems to add to their own mining pool(s, username ‘orfeousb‘ suggests the potential for multiple accounts). I’m someone surprised it has taken until now to be noticed. Brief research (ok, Google-fu) tonight indicates that the minerd64 binary has been a present in active attacks since at least the turn of this year, albeit relying on a different compromise vector (Zimbra compromise), and VirusTotal shows that the exact binary has been seen in the wild since at least March 2014.
The change in attack scenario appears to possibly be part of a wider campaign, as well as this session I’m aware of a similar session taking place on another Kippo honeypot within the last 48hrs, again with connections to .hu systems.
How much this campaign has netted the pool owner(s) to this point is anyone’s guess, where there is profit there will be criminals so I doubt this will be the last we see of similar attack patterns.
Until next time, happy honeypotting.
P.S. For the curious, all shell interaction during the compromise:
ls -l /home
./minerd64 -a sha256d –url=stratum+tcp://stratum.bitcoin.cz:3333 –userpass=orfeousb.vps:qwertz1234chmod +x minerd64
chmod +x minerd64
chmod +x minerd64
Pipal is a tool for quickly and easily analysing password trends across many passwords, created by @digininja and @n00bz. Install (such as it is) is a straightforward affair; download, unpack, run. Standard usage is equally straightforward; ./pipal.rb ;
Download Pipal from here
I’ve not had too much opportunity run the tool myself, as Robin has been quick to release the results of Pipal’s analysis whenever a new breach has been made publicly available, results of this analysis can be found here.
So, trying to find an opportunity to give Pipal a run out, I decided to take a look at the passwords gathered by my Kippo installation. First up, I decided to take a look at the passwords used with added accounts once intruders compromise the system. Curious to see if the passwords chosen by those that break systems are vulnerable to the same weaknesses of standard users. This password list is quite short, so I’ll just add below:
The full results of this analysis is available here.
Pipal’s output from the analysis can be found here. I was surprised with some of the findings, >;60% of the passwords were 8 characters or less, many based on dictionaries words and only one utilising non-alphanumeric characters. Considering the people choosing these passwords gained access to the server by taking advantage of weak root password, I’d really expect better awareness of the importance of generating strong passwords. Guess not…..
Next up, I wanted to take a look at the passwords that are being used by bruteforce and scanning attempts to gain access to the honeypot installation. This password list is far longer than the list above, totalling 382374 entries. The full list input file is available here, and was generating by running the below SQL query against Kippo’s database. For the purposes of this analysis I decided to ignore authentication attempts that use blank passwords, but for the curious, attempts with passwords number 244062 attempts.
select count(password) from auth where password ;””;
For those not familiar with Kippo, it’s worth noting that it’s default root password (which I stuck with for this analysis) is ‘123456’, this will definitely have had an impact on the results below; partly because it features more prominently as attackers knowing the password confirm and utilise the the credentials, and bruteforce scanners will (may?) stop their attack once valid credentials are found, so that attempts which would have been made after ‘123456’ are not seen by the Kippo sensor.
The full output from Pipal from this analysis can be found here. Whilst the advice is weaker than ‘best practice’ advice on creating secure passwords, this data set indicates that simply choosing a password with 10 or more characters will avoid more 80% of remote password cracking attempts (local, offline attacks will be a different matter so take with a pinch of salt.
From finally getting my hands dirty with Pipal it’s a great tool, that does exactly what it sets out to do; give the users the numbers, so they can tell the story of the dataset.
Very quick post to highlight a process for clearing all entries from your pass.db file. I had thought that this would take a bit of quick scripting utilising the list and remove modes from the passdb.py utility script. Turns out it’s even easier; simply pass a non-existent file to passdb.pyass.db parameter and it’ll create a fresh database file, no questions asked.
/opt/kippo/utils/passdb.py /opt/kippo/data/idontexistyet.db add testpassword
Will create a new database file with a single entry of ‘testpassword’ (this can be removed once you’ve established everything works). N.B. even with a blank pass.db, kippo will provide access to the password(s) configured in kippo.cfg.
Not sure yet if clearing the database will net any interesting results, only time will tell…..
After a few weeks running my daily Kippo review script I’ve noticed that whilst I’m still mostly receiving several logins per day, it’s rare for a connection to actually interact with my emulated system. (For those new here, Kippo is a medium interaction honeypot emulating an SSH daemon, get started here). So I started trying to investigate what was causing the trend.
One of Kippo’s features is the password database. Basically once an intruder gains access to the shell if they try to change the password or add a different account the system adds the password to the list of allowed. This then allows connections to log into the shell with the new password. Kippo ships with a small utility script to interact with the password database:
@kippo01:/opt/kippo-svn/utils$ ./passdb.py Usage: passdb.py <pass.db> <add|remove|list> [password]
My pass.db file contains 26 entries added by malicious ‘users’; I’m still analysing the contents in detail, but it looks like the Bad Guys(tm) are paying attention to user education 101 and using long, complex passwords.
Using the password used to log into the system, I’ve had a new (to me) way to link disparate logins. For example the query below linked connections spanning two months, originating from multiple source IP address, across three different continents (according to WHOIS records).
Source IPs for same user (based on pass)
SELECT sessions.id AS Session, sessions.ip AS Source, auth.password AS Password, auth.timestamp AS Time FROM sessions, auth WHERE sessions.id = auth.session AND auth.success = 1 AND auth.password = 'mariusbogdan';
Similarly I looked for a connection between multiple successful logins from the same source IP address. The query below provided a list of report offenders:
Successful logins from same source
SELECT COUNT(sessions.ip) AS Num, sessions.ip AS Source FROM sessions, auth WHERE auth.success = 1 AND auth.session = sessions.id GROUP BY sessions.ip ORDER BY COUNT(sessions.ip) desc LIMIT 25;
My summary from this is that Kippo is receiving a lower level of ‘interesting’ connections the longer the system is operational, as attackers login to check if they’ve maintained access to an ‘0wned’ resource, without utilising the resource. I’m intending to clear my pass.db to remove existing access; hopefully this will return to more interesting connections and I’m also curious to see if any of my current tenants return from either the same source location(s) and/or re-using passwords (and proving me wrong with previous comment about user education).
When I first started running Kippo almost a year ago I had no difficulty getting motivated to log into the honeypot, check for new connections and generally get a feel for what my
victims visitors have been up to. As time went by, sessions started to follow familiar patterns and some days would get no hits. Slowly I’d check the logs less frequently, and when I did I’d get an ever increasing backlog to review, decreasing my motivation further.
Recently I got annoyed with myself, my system was ticking along in the background but I was gaining no benefit from it. So in a moment of madness I dusted off my bash and built a quick script to provide a daily review of activity on my system. Essentially this does two things, lists session interaction and files downloaded within the last 24hours.
I’ve had the routine running daily for around a week; for days there was minmal activity on my system, either no logins at all, or logins with immediate disconnects. Today was different, and marked the first success of the script. Delivered to my morning inbox, along with the rest of my regular quick tasks and RSS feed as an interesting session. Malicious user connects, downloads a scanner (archive contents looks like gosh), an irc bot (looks like EnergyMech derivative); and when attempts to run toolkit fail, downloads and runs three (yes, three, paranoia is strong with this one) log cleaners.
Example (snipped) output:
:~$ /opt/kippo-svn/kippo-sessions.sh ***Sessions*** ---START:/opt/kippo-svn/log/tty/20110519-220029-5503.log--- www-dev:~# w 22:00:38 up 14 days, 3:53, 1 user, load average: 0.08, 0.02, 0.01 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 188.8.131.52 22:00 0.00s 0.00s 0.00s w <SNIP> ***DOWNLOADS*** /opt/kippo-svn/dl/20110519220445_http___eduteam_home_ro_mech_gz: gzip compressed data, from Unix, last modified: Sun Oct 4 17:46:52 2009 <SNIP>
Running through my morning routine of catching up with email, twitter, etc. I came across this post showing Sequal7’s first hits on a Kippo installation. In addition to making amusing reading, it gave me a nudge to check back on the InfoSanity Kippo sensor. Initially I was looking to see if the same individual had stumbled across my sensor; they hadn’t at least not from the information I have available.
However, when checking if the newly changed password matched anything in my database I found a new ‘realm’ entry in the ‘input’ table, ‘ssh’. This got me curious, one of my ‘guests’ decided to hit another system whilst logged in to mine; ssh’ing to another IP, accepting the certificate and providing the password to said system (I’m assuming).
It should also be worth noting that by this point the user had already failed to notice that input hadn’t returned to their own system. After (attempting) to change my sensor’s root password (to ‘yahoo’, really) the user exited, but was caught out by Kippo’s trick of clearing the terminal and changing prompt to ‘localhost’, in total I viewed a ~20 minute terminal session of the user trying to compromise other systems, and failing in the same manner.
My assumption is that the user was running through a list of vulnerable systems identified by SSH scanners similar to the kit I wrote about earlier (it wasn’t the same gosh.tgz kit, but first glance shows similar functionality). From this I feel it’s safe to assume that the systems connected to in the logs available are those of other (probably 0wned) systems, rather than anything connected to my guest. Likewise it is probable that the source connection is also a compromised third party rather than belonging to by guest.
For the curious, archive contents:
Whilst investigating the individual exploits and files; I came across this post, indicating ‘my’ archive is a known fire and forget post exploit kit. Here be Skiddies…
As proven by the logs generated by Kippo honeypot sensors have shown, attacks against SSH services are regularly seen in the wild. Even if you follow best practices for securing the service, the malicious scans will utilise resources available to your environment; CPU, bandwidth etc. In sufficient volume legitimate operation may be impacted as the server rejects failed login attempts.
This is where utilities like Breakinguard come into their own. Basically Breakinguard monitors log files for signs of malicious activity, and once a single source has triggered enough alerts blocks all connections from the source location. Other utilities (most notably fail2ban) perform the same activities, but I’m partial to Breakinguard due to it’s small size and simple configuration (and from knowing the author 😉 ).
Installation is straightforward, and for the most part automated. Once downloaded and extracted installation is handled by the configure script. On Debian based systems this will install the pre-requisite Perl modules and transfer the utilities components to the standard locations:
- breakinguard script – /usr/local/sbin/breakinguard
- config – /etc/breakinguard.conf
- init script – /etc/init.d/breakinguard
Once installed you need to edit your configuration. The breakinguard.conf file is fairly self explanatory, I normally edit:
- $alert_email -> set to the email address that you want to receive notifications of blocked attacks. On a publicly accessible system these alerts can be high volume, you may want to use a specific email account or at least setup some auto-move rules in your email client to avoid your inbox being spammed.
- $number_of_attempts -> This specifies the number of malicious log entries need to be generated by a specific IP address before the source is blocked. Due to the timing of the Breakinguard route this isn’t always an exact science, the default of 5 does a good job of avoid false positives whilst still blocking an attack in it’s infancy.
- $log_to_watch -> selects the logfile to monitor for signs of malicious activity. /var/log/auth.log is the obvious choice on a Debian based system.
- @safe_ips -> This array allows you to specify a number of trusted networks that will not be blocked, regardless of the number of times the they trigger alerts in the logs. This is useful for insuring that you don’t get locked out of your own systems in the event your keyboard ‘breaks’. On higher end systems with hardware remote management systems (iLo, DRAC, etc.) or virtual systems that provide remote access to the ‘physical’ console I leave this list to local subnet only and use the alternative options to access the server if I do lock myself out.
- $DEBUG -> set to 1 by default, this runs the utility in test mode without actually blocking malicious sources, perfect for testing configuration before going live. Once you’re good to set set $DEBUG to 0 and wait for the attacks to start. Example testing in debug mode is below:
Blocking and unblocking of malicious sources is handled via iptables. Once the $number_of_attempts limit is hit Breakinguard will run the $block_command (configurable in /etc/breakinguard.conf) which by default is ‘/sbin/iptables -I INPUT -s %s -j DROP’, with %s being replaced with the attacking IP. After a configurable timeout ($block_length), the $unblock_command removes the restriction.
You can see the IP addresses currently blocked as they are listed in /var/run/breakinguard/, alternatively listing the current iptables configuration will show sources currently being blocked, for example:
Download Breakinguard here