As AV solutions go, Webroot’s Secure Anywhere (WSA) does a decent enough job of protecting against known and unknown threats; but I’ve always has disagreements with the administrative web interface for device management. As a work around if I’ve needed to extensively analyse the endpoints in any way I’ve typically exported the data from the interface to manipulate the data using typical toolkits (grep/Excel/etc.).
There’s still a problem with the exported data in terms of easy manipulation, namely the the chosen date format; which is frankly bizarre given it’s generated by a digital platform in the first place – Example: November 30 2015 16:25. Anyone that has spent any time sorting data sets by date will immediately see problems with this format.
Released today, sanitiseWebroot.py simply reads the standard WSA “export to CSV” file, modifies the date format of the relevant fields and creates a new *-sanitised.csv file. The dates are more easily machine sortable, in the format YYYY-MM-DD HH:MM.
Script sanitises the date format from Webroot Secure Anywhere’s “Export to CSV” output
script expects a single parameter, the filename of the original .csv file
script will create a single csv file with more sensible date format
user@waitean-asus:~/Webroot# ./sanitiseWebroot.py WebrootExampleExport.csv
[*] Opening file: WebrootExampleExport.csv
[*] Updating date fields….
100 records processed…
200 records processed…
300 records processed…
400 records processed…
500 records processed…
[*] Processing complete. 510 corrected and written to WebrootExampleExport-Sanitised.csv
The tool is basic enough, but if you regularly encounter WSA and haven’t already created a similar tool to work with the data, this script may (hopefully) prevent you from pulling your hair out.
P.S. if you’re a developer, please take the time to review ISO 8601 to stop these tools be needed in the future.
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
It’s a while since I’ve found time to add a new tool to my malware environment, so when a ISC post highlighted a new update to Cuckoo sandbox it served as a good reminder that I hadn’t got around to trying Cuckoo, something that has now changed. For those that don’t know, from it’s own site:
[…] Cuckoo Sandbox is a malware analysis system.
Its goal is to provide you a way to automatically analyze files and collect comprehensive results describing and outlining what such files do while executed inside an isolated environment.
It’s mostly used to analyze Windows executables, DLL files, PDF documents, Office documents, PHP scripts, Python scripts, Internet URLs and almost anything else you can imagine.
Considering Cuckoo is the combined product of several tools, mostly focused around VirtualBox, I found install and setup was largely trouble free, mostly thanks to the detailed installation instructions from the tools online documentation. I only encountered a couple of snags.
[2011-12-29 17:21:56,470] [Core.Init] INFO: Started.
[2011-12-29 17:21:56,686] [VirtualMachine.Check] INFO: Your VirtualBox version is: “4.1.2_Ubuntu”, good!
[2011-12-29 17:21:56,688] [Core.Init] INFO: Populating virtual machines pool…
[2011-12-29 17:21:56,703] [VirtualMachine] ERROR: Virtual machine “cuckoo1” not found: 0x80bb0001 (Could not find a registered machine named ‘cuckoo1’)
[2011-12-29 17:21:56,704] [VirtualMachine.Infos] ERROR: No virtual machine handle.
[2011-12-29 17:21:56,705] [Core.Init] CRITICAL: None of the virtual machines are available. Please review the errors.
The online documentation specifies creating a dedicated user for the cuckoo process. Sound advice, but if you create your virtual guest machines under a different user (like I did, under a standard user account), then the cuckoo process cannot interact with the virtualbox guests. Either changing ownership of cuckoo, or specifically creating the guest VMs as the cuckoo user will solve the issue.
Last problem encountered was Cuckoo’s database, which if it doesn’t exist when the process will create a blank database. Which (obviously, in hindsight) will fail if the running user doesn’t have permissions to write to Cuckoo’s base directory.
With problems out of the way, Cuckoo runs quite nicely, with three main parts. the cuckoo.py script does the bulk of the heavy lifting and needs to be running before doing anything else. If all is well it should run through some initialisation and wait for further instructions:
/opt/cuckoo $ ./cuckoo.py
____ _ _ ____| | _ ___ ___
/ ___) | | |/ ___) |_/ ) _ \ / _ \
( (___| ( (___| _ ( | |
\____)____/ \____)_| \_)___/ \___/ v0.3.1
Copyright (C) 2010-2011
[2011-12-29 20:27:17,120] [Core.Init] INFO: Started.
[2011-12-29 20:27:17,719] [VirtualMachine.Check] INFO: Your VirtualBox version is: “4.1.2_Ubuntu”, good!
[2011-12-29 20:27:17,720] [Core.Init] INFO: Populating virtual machines pool…
[2011-12-29 20:27:17,779] [VirtualMachine.Infos] INFO: Virtual machine “cuckoo1” information:
[2011-12-29 20:27:17,780] [VirtualMachine.Infos] INFO: \_| Name: cuckoo1
[2011-12-29 20:27:17,781] [VirtualMachine.Infos] INFO: | ID: 9a9dddd8-f7d6-40ea-aed3-9a0dc0f30e79
[2011-12-29 20:27:17,782] [VirtualMachine.Infos] INFO: | CPU Count: 1 Core/s
[2011-12-29 20:27:17,783] [VirtualMachine.Infos] INFO: | Memory Size: 512 MB
[2011-12-29 20:27:17,783] [VirtualMachine.Infos] INFO: | VRAM Size: 16 MB
[2011-12-29 20:27:17,784] [VirtualMachine.Infos] INFO: | State: Saved
[2011-12-29 20:27:17,785] [VirtualMachine.Infos] INFO: | Current Snapshot: “cuckoo1_base”
[2011-12-29 20:27:17,785] [VirtualMachine.Infos] INFO: | MAC Address: 08:00:27:BD:9C:4F
[2011-12-29 20:27:17,786] [Core.Init] INFO: 1 virtual machine/s added to pool.
The submit.py script is one of the ways for getting cuckoo to analysis files:
python submit.py –help
Usage: submit.py [options] filepath
-h, –help show this help message and exit
-t TIMEOUT, –timeout=TIMEOUT Specify analysis execution time limit
-p PACKAGE, –package=PACKAGE Specify custom analysis package name
-r PRIORITY, –priority=PRIORITY Specify an analysis priority expressed in integer
-c CUSTOM, –custom=CUSTOM Specify any custom value to be passed to postprocessing
-d, –download Specify if the target is an URL to be downloaded
-u, –url Specify if the target is an URL to be analyzed
-m MACHINE, –machine=MACHINE Specify a virtual machine you want to specifically use for this analysis
Most of the options above are self-explanatory, just make sure to select the relevant analysis package depending on what you’re working with; possibilities are listed here.
Finally, web.py provides a web interface for reviewing the results of all analysis performed by cuckoo, bound to localhost:8080.
I’d like to thank the team that developed and continue to develop the cuckoo sandbox. I look forward to getting more automated results going forward and hopefully getting to a point where I’m able to add back to the project; until then I’d recommend getting your hands dirty, from my initial experiments I doubt you’ll be disappointed. But if you won’t take my word for it, watch Cuckoo in action analysing Zeus here.
— Andrew Waite
Like most techies I get the job of fixing and maintaining relatives’ PCs. As part of this after fixing whatever is broken I have some common clean-up and install routines that I go through to both help the system run faster and to extend the period before I’m called back, and I’ve used AVG free as part of this for many years to keep costs down for my users.
During a recent job I came across a new (I’m assuming, hadn’t noticed it before) feature of AVG free, the PC Analyzer component. Being the curious sort I hit the go button, scan ran for around 5 minutes and I was presented with this:
Ouch, I was surprised with the number of errors as this is a machine I keep a regular eye on, and in some cases use myself (it’s the missus’). Time to panic? Let’s see:
- Registry errors: Errors affect system stability: (125)
That doesn’t sound good, checking the ‘Details…’ link presented me with a long list Registry keys, which to a standard end-user would result in turning on BofH’s Dummy Mode. In reality, it found a lot of keys to set the ‘open with’ right-click function depending on file extension. ‘Affect system stability’? Not so much, and I find the links useful enough that I’ve previously researched how to add my own…
- Junk Files: These files take up disk space: (599)
Again checking the details, long list of randomly named files. In the temporary folder. All ~600 took a total of less the 300MB, and the machine has more the 200GB free. Something to correct come next house cleaning session, but not really a problem.
- Fragmentation: Reduces disk access speed
In fairness to the tool, it did come back clean and we know that fragmentation can be an issue. But that’s why every machine I’ve ever used has come with a defrag utility, as standard, for free. (OK, my BBC Micro B didn’t, but then it also had a cassette deck rather than a hard disk).
- Broken Shortcuts: Reduces explorer browsing speed(42)
Ok, so I forget a folder of shortcuts to junk that came pre-installed with the system. I’d deleted the junk, forgot the shortcuts. Thanks for the reminder, fixed.
Plenty of ‘problems’ highlighted, time to run out and drop £25 for an annual subscription to the clean-up tool? Nope, ignoring the fact that many of these issues are system settings that actually aid the end user, the remaining issues won’t have any negative impact that the end-user will notice.
In my own opinion, AVG is taking a leaf out of the fake AV scams and scaring non-techies into parting with their hard earned coin in a bid to keep the computer running and bank details away from the scary hackers that the nice lady on the news keeps taking about. Presenting a list of meaningless (to most) information and saying it’s bad is exactly the tactic I encountered with cold call scammers earlier in the year.
As a final side note, I’ve lost two of my ‘users’ this year to AVG simply because when the AVG free license I’d installed expired, they couldn’t find a link to download the latest free version, only MANY links to the paid version. As my users are nice people (latest ‘victim’ was my grandfather), they decided themselves that it was better for them to pay the small fee than have to call me and interrupt my life.
Can anyone recommend a free AV suite that doesn’t con the unwitting into unnecessary purchases to perform a cleanup that could be performed manually with around 5 minutes and half a clue? AVG Free is a great tool, and for free I shouldn’t really complain, but when the sales tactics change to make money selling things people don’t need, to those that don’t know any better?
I’m sure by now most people are aware of a new round of scams where victims are being called by a ‘support company’ suggesting that the victim’s computer has malware installed which they can fix. If you need it, this BBC article covers the basics. Well, I just got the call 😉
First up the caller seemed to be auto-dialling large volumes of numbers looking for someone to pick-up as the caller (male, poor line quality meant I missed the name given) was unprepared when I answered. The caller was clearly reading from a script, I may have over-played the ‘Sorry, I’m just a dumb user that knows nothing about computers card’ but despite telling him I was clueless and willing to accept everything he told me I was still present with a long winded argument for ‘if you don’t believe us this is how I’ll prove it’ speech.
Unfortunately I wasn’t able to through the full process as, despite telling my new friend otherwise, I wasn’t able to get to a Windows machine to work through the process. Only laptop to hand was my netbook running Ubuntu, and my landline isn’t mobile so I couldn’t head up stairs. (My landline never rings, everything I do is via mobile and only have landline for ADSL connection. I’m suspicious of all landline calls before I even pick up the phone.)
After ensuring I was looking at the system wallpaper, I was instructed to press the ‘key on bottom left of keyboard with four squares that looks like the Microsoft logo’ and with another finger press the ‘r’ key. This is where I was given ‘proof’ that my system was infected, using a ‘hidden’ command that will list all infections, what is the magic command? inf (for ‘infections’), which opens Windows Explorer in C:\Windows\inf, screenshot below shows the infections on my system. I’m guessing at this point, the every user may have just entered dummy mode.
At this point I lost the caller, whether a technical fault or he’d guessed something wasn’t right (I can’t act for toffee). I’m hoping that I’ll get a second bite at the cherry at some point; my missus took a similar call a few weeks back, having spent too long listening to my security rants she immediately spotted the scam, pointed out that I was a ‘security guy’ and hung up. Information that they clearly didn’t have when ringing back (could be more that one cold calling organisation).
Unfortunately, despite my usual laughing at people who fall for these scams I can see how those with less knowledge could fall for the premise. Computers and software regularly phone home to check for updates etc, using this information to identify infected systems would/could make sense, and from an end user perspective I struggled to tell the difference between the sorts of actions I was asked to take by my ‘friend’ than those I regularly instruct friends and family members when I’m trying to provide remote support.
Be safe and spread the word to those less knowledgeable about computers that this is an active scam. Bottom line is: no legit IT company will call you to fix a problem that you weren’t aware of.
I just received a new call following the same theme but with a different vector. This time the call came from ‘Microsoft Service Department’, and with a different convincer; this time I was baby-stepped through to opening the Security log with each entry being ‘evidence’ of the malware infection that ‘at this very moment is damaging my computer and hard drive’. To be fair, in this case they ‘could’ be right.
Other differences indicate that either this is a different group from the first caller, or they’ve improved the call systems used to implement the scam. On lifting the receiver I was placed immediately to on hold music before speaking to my ‘MS representative’ a few moments later. I believe that automated dialling is illegal within the UK, but given the nature of the call I doubt they care much either way.
REMEMBER: Microsoft will NOT call home (or business) users to inform that you’ve got a malware infection
<UPDATE>Live download mirror: carnivore.it</UPDATE>
Mercury Live DVD was initially (I believe) announced in a post to the Nepenthes Mailing list. It is a remastered Ubuntu distribution with pre-installed honeypot applications and malware analysis tools created by John Moore. From the ReadMe:
This live DVD is a remastered version of Ubuntu 10.0 Beta LTS x86_32. It was designed due to my being disappointed with another reverse engineering malware live CD that was released recently. I have decided to call my creation MERCURY, which is an acronym for Malware Enumeration, Capture, and Reverse Engineering.
The Mercury live DVD contains tools used for digital forensics, data recovery, network monitoring, and spoofing. It should primarily be used as a honeypot or network monitoring platform as well as a laboratory and teaching aid. There are three honeypots installed – honeyd, nepenthes, and dionaea. Four, if you include netcat.
The majority of the additional applications reside in /opt:
- Dionaea (0.1.0) – Dionaea is a malware collection honeypot focusing primarily on SMB emulation, covered on InfoSanity numerous times before.
- FFP – Fuzzy Fingerprinting is a util to aid SSH MitM attacks.
- Kippo (svn rev.169) – Kippo is an low-medium interaction SSH honeypot, Also covered
- mitm-ssh – Unsurprisingly, a utility for aiding man in the middle attacks against SSH connections.
- Origami & pdftools – Two frameworks for analysing malicious PDF files.
- Volatility – an excellent memory analysis toolkit
- Zerowine-vm – A malware behavior analysis platform. I’ve covered ZeroWine here before, and whilst I find it useful for initial analysis I found it a pain to setup and get running. The fact this works out of the box on Mercury is enough reason alone to keep the .iso handy.
Other tools are installed on the system as started, access from standard locations (/etc, /usr/bin, etc.). I won’t try to list them all, but some highlights include:
- Nepenthes – Dionaea’s predecessor
- Honeyd – Honeypot system, perfect for emulating multiple different systems from one platform. Covered in more depth here.
- John – John the Ripper, password cracker
- ircd-hybrid – irc server daemon, useful for analysis irc-based malware’s interaction with command and control systems.
- Snort – de-facto intrusion detection system.
- Wireshark – Packet capture and network analysis tools.
I could go on, but I’m sure you get the idea.
Setting up a honeypot, and analysing the results, has never been easier. And I’m sure the toolkit’s functionality will also be useful in other scenarios; incident response, general network administration or as a safe learning platform. So what are you waiting for?
N.B. there have been several mirror’s and downloads established, the most reliable download source I’ve used is Markus’ mirror at carnivore.it
So far my Kippo honeypot installation has recieved a number of successful log ins from maliciuos users, some of which have been helpful enough to provide some tools for further analysis. A lot of the archives which have been downloaded show that the kits have been in use for a while, with some archive timestamps going back as far as 2004 (of course this could simply be an incorrect clock on the machine that created the archive). Picking on the most recent download (2010-07-18) I’ve taken a look at the archive containing gosh.tgz.
The archive was downloaded from linux<dot>hostse<dot>com<slash>gosh<tgz>, system is down at time of writing but take care if attempting to investigate yourself. Before downloading the user checked around the system with commands: w, uname -a and cat /proc/cpuinfo, and archive was downloaded and extracted in /dev/shm/.
Once extracted, the archive contains a number of files:
|1:||ISO-8859 English text, with CRLF line terminators|
|3:||ASCII C++ program text, with CRLF line terminators|
|a:||ISO-8859 text, with CRLF line terminators|
|common:||ASCII C++ program text|
|gen-pass.sh:||Bourne-Again shell script text executable|
|pscan2:||ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped|
|scam:||Bourne-Again shell script text executable|
|secure:||Bourne-Again shell script text executable|
|ss:||ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0,stripped|
|ssh-scan:||ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.0.0, stripped|
- Interesting files:
- Files 1 to 5, common and pass_file are password lists, totalling 235,523 potential passwords.
- mfu.txt is a list of IP addresses, mostly in the 184.108.40.206/16 address space.
- pscan2 is a fairly common and generic port scanner.
- scam is a shell script that appears to be the core brains of the toolkit. It essentially looks through scanning a different ranges of IP addresses while periodically emailing the contents of vuln.txt back to it’s master (firstname.lastname@example.org).
- ss: appears to be another scanner used for looking for potential targets.
- ssh-scan: appears to be a Romanian tool from the message provided if run without arguments, according to Google Translate (possibly NSFW), and as you would guess from the file name is a scanner for SSH services.
- vuln.txt is blank in the archive, and will be the output of vulnerable systems located by the scanners.
All told this appears to be a kit for performing further scans for unsecured SSH sessions, and it is likely that a similar kit hosted on a different compromised machine was responsible for identifying my installation in the first place. Kits like this also quickly show the problem with tracking down the malicious user behind an compromise or attempt, it is rare for attacks to be launched from systems that can easily be traced back to the malicious user.
A quick Google search confirms that this kit (and user) has been seen in the wild attacking other systems, this posting on the Shell Person blog writes up the aftermath after a production system was compromised by the same kit.