Yahoo released its Transparency report covering the number of government requests for user data.

Requests from Belgium to Yahoo

In 2014 the Belgian government requested 5 times user data from Yahoo for 17 accounts. All these requests were rejected by Yahoo.

• 5 “Government Data Request”, meaning a government agency seeking information about Yahoo accounts. These are generally made in connection with criminal investigations.
• 17 “Government Specified Accounts”, meaning the number of Yahoo accounts, users, or other unique identifiers.
• Yahoo “Rejected” all 5 requests.
• Yahoo returned 0 replies or “No Data Found” because no responsive data could be found.

The rejected cases were either because no data was found because of a defect, because the request was not legal or because the request was withdrawn. See further down this post for a complete definition.

Netherlands, France, Germany and United Kingdom

All the requests coming from the Netherlands were rejected. France and Germany had above 60% of their requests rejected and 53% of the requests coming from the United Kingdom were rejected.

Globally

Compared to the rest of the world 49% of the requests from Europe were rejected. The numbers for the United States do not include emergency requests and U.S. national security requests.

Other countries

Yahoo did not receive requests from Luxembourg. Yahoo received 4814 requests for 7952 accounts from Taiwan and only 281 requests were rejected.

The number of requests for Taiwan is high if you compare this to the number of internet users. There are 18,687,942 internet users as of Dec 31, 2013 in Taiwan. The same source returns 582,441,059 users in Europe and 277,436,130 users in the United States.

Emergency requests

Yahoo received 88 emergency requests in the first part of 2014 and 147 emergency requests in the second part of 2014. In total Yahoo received 235 emergency requests for 305 accounts.

Yahoo definitions

No Data Found: Yahoo produced no data in response to the Government Data Request because no responsive data could be found (i.e., the account didn’t exist or there was no data for the date range specified by the request).

Rejected: Yahoo may have possessed data responsive to the Government Data Request, but none was produced because of a defect or other problem with the Government Data Request (e.g., the government agency sought information outside its jurisdiction or the request only sought data that could not be lawfully obtained with the legal process provided). This category also includes Government Data Requests that were withdrawn after being received by Yahoo. We carefully review Government Data Requests for legal sufficiency and interpret them narrowly in an effort to produce the least amount of data necessary to comply with the request.

NCD: Non-content data such as basic subscriber information including the information captured at the time of registration such as an alternate e-mail address, name, location, and IP address, login details, billing information, and other transactional information (e.g., “to,” “from,” and “date” fields from email headers).

Content: Data that our users create, communicate, and store on or through our services. This could include words in a communication (e.g., Mail or Messenger), photos on Flickr, files uploaded, Yahoo Address Book entries, Yahoo Calendar event details, thoughts recorded in Yahoo Notepad or comments or posts on Yahoo Answers or any other Yahoo property.

Government Data Request: Legal process to a Yahoo entity from a government agency seeking information about Yahoo accounts and/or the activity of Yahoo users within Yahoo products. The Government Data Requests reflected in this report are generally made in connection with criminal investigations.

Government Specified Accounts: The number of Yahoo accounts, users, or other unique identifiers listed in a Government Data Request. This number is typically larger than the number of users and accounts actually involved because: 1) a single account may be included in more than one Government Data Request; 2) an individual user may have multiple accounts that were specified in one or more Government Data Requests; and 3) if a Government Data Request specified an account that does not exist, that nonexistent account would nevertheless be included in our count of Government Specified Accounts.

Share malware with a security team

With the recent increase of notifications of cryptolocker malware I was wondering if this dropped malware was always the same version or if the attackers used different versions. I was also curious if the delivery path (e-mail route or otherwise) was different. This raised the question : “How to share malware with a security team?”.

Some teams have a service where you can upload samples. If they do not have an upload service then you will have to use more traditional methods.

Sharing workflow

Ideally you notify the team, either before sending the sample or with a separate message, that you are going to share a sample. Smart virus scanners might block the message with your sample and the receiving part might never know you wanted to share something.

You can also use the prior notification to verify that you are sending the notification to the correct recipients. Some teams can have a dedicated mailbox for receiving malware samples.

You should also let them know what feedback you are expecting. Are you sharing the malware for “information only” or do you expect an analysis and feedback?

The accompanying message for sharing the sample should contain context, impact and delivery route.

1. Set context.
   • What is your organization type?
   • What is the volume of detected malware?
   • What is the typical user environment (OS, software installed)?
   • Do you have server based protections (firewall, anti-virus, IDS) that triggered or that failed?
   • Are there host based protections that triggered or that failed?
2. Define impact
   • Did the malware execute?
   • If the malware did not execute, why do you suspect this to be malicious?
   • What was the impact (host infected, server infections)?
   • Is the incident ongoing or did you contain it?
3. Delivery route
   • How was the malware delivered (e-mail, USB, website)?

Sharing the sample

You can not just “send” the sample via e-mail or share it via an online file sharing platform. If it is recognized malware then it’s certain to be blocked either in transit or at the receiving part. So how do you share?

The easiest way is not technologically challenging : use a password protected ZIP file.

1. Create a new ZIP file;
2. Add the sample to the ZIP file;
3. If delivered by e-mail, add the source or the entire message to the ZIP file;
4. Set a password (easiest: ‘infected‘) on the ZIP file.

Do not forget to inform the receiving team of the password that you used to protect the ZIP file.

CIRCL.lu mentioned that nowadays a lot of mail providers brute-force ZIP passwords. An alternative for a ZIP with ‘infected’ could be to either use GPG encryption with a symmetric key or use your own customised password.

If you want to verify the integrity of the file then do an MD5 sum of the original files (the malware, not the ZIP file) and include that in your notifications. Digitally signing your messages is also a good idea.

If your company policies allow you to share logs then including e-mail, fileserver or firewall logs (possibly anonimized) can also help the security team for doing the analysis and providing feedback on the possible impact.

Malware analysis, signatures and CERTs

CERTs have to provide their constituency early warnings and alerts about new threats.

A typical example is a new form of malware being distributed by e-mail. It takes a while before anti-virus vendors include the new signature to recognise the malware. This means that there’s a time window where the malware is not filtered and users in your constituency can get infected.

To protect your constituency you can provide them your own signature with indicators of compromise describing what the malware does exactly, how to detect it and possibly prevent it from weaponizing further. The process of getting these indicators from a binary is malware analysis.

Doing it manually can be time consuming, difficult and not always feasible. By the time you have finished your analysis there’s already a new mutated form of the malware.

Automated malware analysis

An automated analysis saves you time. You feed it the presumably malicious file and once the analysis is done you have a basic set of IOCs (Indicator of Compromise) that you can distribute to your constituency (possibly via a malware information sharing tool).

Automated analysis also allows you to analyse the behaviour of the malware in different configurations. Think of situation where you have to support multiple versions of Microsoft Office or Adobe Acrobat Reader.

There are several malware analysis sandboxes and services that can examine malware automatically but in this post I focus on one product : VMRay Analyzer.

VMRay

Some of the features of VMRay Analyzer are

• it covers different windows flavors;
• process creation, code injection, and driver installation methods are tracked and detected;
• analysis of contemporary 64-bit kernel rootkits;
• the client-server-architecture allows distribution of jobs.

VMRay got my attention because it claims to be impossible to evade, to be fast and to be reliable. Also I was searching for something similar to CWSandbox. The author of CWSandbox is the CEO of VMRay.

I requested and received a 30-day evaluation account to test the product.

VMRay technology

The first generation of malware analysis platforms used emulation. This delivers good results but can quickly become very slow. The second generation used hooks. This is faster but comes at a price. Hooks can be detected and can allow malware to prevent the analysis.

VMRay positions itself as the third generation of malware analysis because of its microprocessor functionality and monitoring methodology. Malware would be oblivious of it being monitored. Of course it would still be able to detect that it’s being run in a virtualization environment but, because of the high adoption of virtualization, that’s for most malware not an issue.

VMRay runs on commodity hardware and you can interface with it via a web browser.

VMRay evaluation

VMRay provides you a hosted test environment. In a production environment you can (or should) have the solution hosted in your premises. This limits the exposure that you give to “sensitive” malware. You still have the possibility to share your information with a community.

After logging in to the secured website you get the dashboard with an overview of your latest samples, analysis and submissions.

Submitting a sample is straightforward with one-click. You can provide a password (for archives) or extra command line options. A check box allows you to choose if you want to share the sample. Basically you just have to add the file and click submit to get it working. The sample type is automatically detected but you can also preset it to the different PE flavors, Word, Powerpoint, Excel, Flash, ….

The analysis is done by a set of rules. The overview of these rules gives you an idea of what is supported in which specific configuration. These rules also allow you to better understand how the artifact behaves with different versions of the operating system or user applications.

Once the analysis is done you get a notification e-mail.

And then the juicy part begins.

VMRay evaluation – analysis

The submissions get analyzed simultaneously in different environments / configurations. This is great because it allows you to easily compare the behavior in different setups. When the analysis is finished you can either download the report (as a zip) or view it online.

The Overview tab lists what has happened. It lists the time it took to complete, a process tree, screenshots and details of dropped or created files. The screenshots and the process tree are valuable to quickly see how the sample behaved in that specific environment. From here you can also download the entire PCAP or the logfiles. Having access to the PCAP file is fun because it gives you access to the bare-metal network details and you can do your own statistics (and network analysis).

The Behavior tab gives a detailed overview of what happened. The behavior is split out per process so you can exactly track the different stages of the sample.

Test sample : a Word document

One of my test samples was a Word document that is recognized by Virustotal as a Trojan Downloader. The file arrived as an attachment to an e-mail. My test case was to quickly extract the IOCs for detecting infected machines.

The submitted file got analyzed with four different Windows configurations (Office 2003, Office 2007, Office 2010 and Office 2013). I downloaded the report for the analysis done with Office 2010.

The overview tab showed that the malware does two ICMP requests to a host in China and creates a number of local files. With the outgoing ICMP traffic and the list of dropped files and their MD5 I can start the IOC signature. I have MD5 checksums that can be used for detection by a host IDS and I have network addresses that should be monitored for ICMP traffic.

In the behavior tab I can see that next to the ICMP packets there are also a couple of HTTP requests. This allows me to extend the IOC signature with a list of network hosts to monitor.

With the help of the automated analysis of this sample I was able to quickly extract useful IOC data. The process did not involve a lot of work, merely uploading the file, waiting for the notification e-mail and reading the report.

VMRay API

VMRay can be used via the web interface or via an API. The API allows you to submit new samples and download the reports. This allows further integration within your existing environment and extensive automation.

Think of a situation where you isolate a new piece of malware and submit it for analysis. Once the job is done you can extract the relevant IOCs (network information, file hashes) and push these to your threat intelligence for sharing and to your security solutions for further monitoring.

Conclusion

I love the ease of use and the flexibility of VMRay. It’s a great addition to the toolset of a CERT, without a lot of manual intervention. This is important because you do not want to spend your resources on babysitting your own lab for every analysis.

The access to the PCAP and log files allows you to analyse the network stream and build your own statistics.

Some of the samples were already manually analysed so I knew what to expect. As far as I could tell none of the automated analysis missed a pointer.

The support during the evaluation period was good. I got quick and detailed replies on my questions.

It is not immediately possible to extract IOCs. But the log files (in XML format) resulting from the analysis allow you to extract the necessary information with your own scripts. Future versions might include XML logfiles that include the high level details, this would make IOC extraction even much easier.

VMRay is currently focused on Windows environments but other platforms (ARM, OSX) might be integrated in the future.

VMRay gets its biggest strength from a lot of simultaneous analysis of malware running in a predefined set of configurations.

During my tests I did not encounter any functional issues. The few remarks that I had were quickly dealt with or I got a satisfying explanation. I’ve not been able to test it with complex malware families but as far as I could check it did its analysis job flawlessly.