The Twin Journey, Part 1

Summary and Introduction: The recent changes in Windows 10, aiming to add case sensitivity (CS) at directory level, have prompted our curiosity to investigate the potential to use CS as a mean of obfuscation or WYSINWYG (What You See is NOT What you Get). While CS was our entry point, we then ventured into other […]

The post The Twin Journey, Part 1 appeared first on McAfee Blogs.

Summary and Introduction:

The recent changes in Windows 10, aiming to add case sensitivity (CS) at directory level, have prompted our curiosity to investigate the potential to use CS as a mean of obfuscation or WYSINWYG (What You See is NOT What you Get). While CS was our entry point, we then ventured into other file naming techniques to achieve similar outcomes.

Threats and Red Teams may include these techniques in their arsenal to execute various versions of persistence tricks, scan avoidance, security bypass or, in extreme cases, make the system totally unusable.

As part of this blog we use the term “Evil Twins” to describe a scenario where 2 files on disk are crafted using specific file naming techniques to confuse security mechanisms, leading to the good twin being scrutinized while the evil twin flies under the radar.

This is part of a series that will explore each of the different scenarios and techniques we researched.

Evil Twins and WSL (Windows Sub-System for Linux) to the Rescue

Windows Linux Subsystem introduces a set of new cool features and provides interoperability between Linux & Windows, including the ability to execute ELF files.

Some time ago, case sensitiveness was enabled by default when using DRVFS, the file system driver that allows to mount Windows drives. (C:\\, D:\\) from a WSL instance.

After some internal releases it was removed, and case-sensitiveness did change over time in terms of CS inheritance, including the restriction to change sensitiveness of folders that already have “twins”.

The following technique relies on the ability to mount DRVFS with case=force that will literally override any case-sensitiveness set for any directory.

Any attacker that has admin rights and wants to achieve any of the following goals can rely on this approach to:

  • Persist & Hide files
  • Make the OS unusable
  • Stop many products from starting (even if they have other kinds of protection).
  • Alter dlls loaded to control the applications.

This scenario is based on the premise that WSL and a Linux distribution are installed. In case those requirements are not met, scripts that automate that process, or even importing your custom distribution.

For complex scenarios where installing WSL & importing a distribution is required, even although it’s possible to di programmatically for any adversary and even remove WSL, it will still be very noisy in terms of suspicious activities whether the workstation does not belong to a developer for instance. As time goes on, many companies that have Linux development will include WSL as part of the daily basics for developer workstations, servers, etc.

The execution steps would include something like:

  1. Enable WSL
  2. Check if a distribution is already installed / Install it if missing
  3. Look for LXSS and enable DRVFS force flag
  4. Depending on how the twin will be created you can do several things:
    1. Create a WSL conf file with automount options. This is optional since you can remount the /mnt/c folder with new options.
    2. Copy files from the rootfs folder in Windows to preserve permissions (read/execute/etc.) without messing with ACL’s on the Linux side.
      1. Approach #1: Create the proper files without starting bash until the end (only touching Windows files): Ex: One of the scripts just copies the environment file and, if it is empty, it adds some content, so it is executed from bashrc next time bash is launched.
      2. Approach #2: Create the proper files from bash itself, so you do not need to mess with permissions (this will depend on how systems will be alerted by detecting bash execution, etc.)
    3. Terminate WSL instances.
    4. Start bash (by using a task, autorun, or just as part of the PowerShell script)
      1. From here you can just execute commands on the POC example, depending on the script arguments; the commands to be executed are of /etc/bashrc file.
      2. VOILA, the script will create a folder or copy the twin dll in a non-cs enabled folder, thus promoting the twin as the file to look for next time.

Sample script:

Executing the technique to implant an Evil Twin dll: (replacing IEPROXY.dll for a mock that will just change the background)

The IEPROXY.DLL implant taking effect😊

Watch the video recorded by our expert Cedric Cochin, illustrating the entire technique:

Outcomes for this technique include:

  • A piece of ransomware creating C:\Windows\SYSTEM32 twin folder and not allowing a normal boot.
  • A targeted attack could create a IEPROXY.DLL so next time any application loads the dll it will load the compromised dll.
  • A targeted attack could create a C:\Program Files\[FAVORITE VENDOR] to disable such application, if the application is not CS aware/compatible

Protection and Detection with McAfee Products:

  • By using Endpoint Security Expert Rules, the registry key required to execute the entire workflow can be protected.
  • Active Response:
    • Setup a trigger to be notified of this situation whenever this registry key or a file is modified
      • File Trigger with condition: Files name equals wsl.conf”
      • Registry Trigger with condition: WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss
    • Custom collector: PowerShell Script that can find duplicated names in a folder. (Scanning the entire disk may take longer that search timeout)
    • Files collector if enabled, looking for wsl.conf modifications.
      • “Files where Files name equals wsl.conf”
    • WinRegistry Collector :
      • “WinRegistry where WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss”
  • MVISION EDR:
    • File collector if enabled, looking for wsl.conf modifications.
      • “Files where Files name equals wsl.conf”
    • WinRegistry Collector:
      • “WinRegistry where WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss”

  • Historical search activity

Artifacts involved:

  • Modification of HKLM:\System\CurrentControlSet\Services\lxss\DrvFsAllowForceCaseSensitivity
  • Bash execution
  • Creation of new folder / dll (twin)
  • Optional:
    • Creation of /etc/wsl.conf ( Can be tracked from Windows rootfs folder)
    • Wslconfig /t execution to terminate instances
    • Installation / Download of Linux distribution or tar file import
    • WSL enabled

The post The Twin Journey, Part 1 appeared first on McAfee Blogs.

Google Releases Security Updates for Chrome

Original release date: July 31, 2019Google has released Chrome version 76.0.3809.87 for Windows, Mac, and Linux. This version addresses multiple vulnerabilities that an attacker could exploit to take control of an affected system.

The Cybersecurity an…

Original release date: July 31, 2019

Google has released Chrome version 76.0.3809.87 for Windows, Mac, and Linux. This version addresses multiple vulnerabilities that an attacker could exploit to take control of an affected system.

The Cybersecurity and Infrastructure Security Agency (CISA) encourages users and administrators to review the Chrome Release and apply the necessary updates.

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

CISA Releases Advisory on Wind River VxWorks Platform

Original release date: July 30, 2019The Cybersecurity and Infrastructure Security Agency (CISA) has released an Industrial Control Systems (ICS) Advisory on multiple vulnerabilities in the Wind River VxWorks Platform. A remote attacker could exploit so…

Original release date: July 30, 2019

The Cybersecurity and Infrastructure Security Agency (CISA) has released an Industrial Control Systems (ICS) Advisory on multiple vulnerabilities in the Wind River VxWorks Platform. A remote attacker could exploit some of these vulnerabilities to take control of an affected system.

CISA encourages users and administrators to review the following products, apply the recommended mitigations, and refer to vendors for appropriate patches, when available.

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

Steps to Safeguard Against Ransomware Attacks

Original release date: July 30, 2019The Cybersecurity and Infrastructure Security Agency (CISA), Multi-State Information Sharing & Analysis Center (MS-ISAC), National Governors Association (NGA), and the National Association of State Chief Informat…

Original release date: July 30, 2019

The Cybersecurity and Infrastructure Security Agency (CISA), Multi-State Information Sharing & Analysis Center (MS-ISAC), National Governors Association (NGA), and the National Association of State Chief Information Officers (NASCIO) have released a Joint Ransomware Statement with recommendations for state and local governments to build resilience against ransomware:

  1. Back up systems—now (and daily). Immediately and regularly back up all critical agency and system configuration information on a separate device and store the backups offline, verifying their integrity and restoration process. If recovering after an attack, restore a stronger system than the one lost, fully patched and updated to the latest version.
  2. Reinforce basic cybersecurity awareness and education. Ransomware attacks often require the human element to succeed. Refresh employee training on recognizing cyber threats, phishing, and suspicious links—the most common vectors for ransomware attacks. Remind employees of how to report incidents to appropriate IT staff in a timely manner, which should include out-of-band communication paths.
  3. Revisit and refine cyber incident response plans. Have a clear plan to address attacks when they occur, including when internal capabilities are overwhelmed. Make sure response plans include how to request assistance from external cyber first responders, such as state agencies, CISA, and MS-ISAC, in the event of an attack.

CISA encourages organizations to review the Joint Ransomware Statement and the following ransomware guidance:

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