Monday, July 30, 2018

Russian Government cyber attacks on US Energy sector - TA18-074A summary



US Cert has a great intelligence report on Russian TTPs against US Energy sector entities since 2016. I attended one of the DHS briefings and many folks struggled with the software used to conduct the briefings. I am publishing my notes on the briefings to help share this information.

Summary:
                Generally, the attacks are well thought out and reasonably sophisticated. However, the TTPs rely on typical windows and network functions and features. Many of the TTPs could be detected in Windows event logs if they were available in a SIEM.

There’s a lot here so I will separate highlights within the Cyber Kill Chain stages (CKC), splitting out stages 1-4 and then 5-7.

Highlights (CKC Stage 1-4):
  • Small organizations were deliberately targeted
    • Executives and control system operators were the most likely targets
    • Trusted partners were compromised first to use as pivot points (Example -  through a trusted vendor connection)
    • US energy sector was the specific target, and US utilities were affected
    • Spear phishing included references to legitimate equipment or resumes
    • URL shorteners such as bit.ly and tinyurl were used in spear phishing
  • Threat actors combed the websites of their targets, including downloading and examining photographs to gain intelligence
    • This includes downloading the entire website and examining documents, images, and public code
    • Threat actors were able to identify control system equipment information from a photo on an HR page
  • Spear phishing and watering hole attacks both depended on SMB outbound (using file://IP) (tcp 139/445 outbound)
  • A large portion of watering hole domains were trade publications and informational websites relates to ICS or critical infrastructure
  • Threat actors modified legitimate JavaScript libraries on compromised servers to include malicious code



Highlights (CKC Stage 5-7):
  • Threat actors used the stolen credentials to establish local admin accounts
    • Achieved with a simple batch script using baked-in windows commands
  • Created a scheduled task named ‘reset’
  • Disabled Windows host firewall, opened RDP inbound
  • Logs were deleted with an administrator account
  • Fake accounts were made to mimic real ones in Exchange
  • Threat actors installed FortiClient to maintain persistence in at least one case
  • Additional tools downloaded from threat actors had the .exe extension swapped with .txt
    • Threat actors modified shortcut files (.lnk) to obtain their icon image from a remote server. This would pass the credential hash over SMB to the attacker.
  • Another variant included modifying a word document to get its normal.dotm file from a remote location
  • Both used file:// outbound
  • Network traffic for both variants is discussed below
  • Threat actors modified the registry to force WDigest to store plaintext credentials in memory
  • Threat actors had access to take actions resulting in physical actions, but did not take actions.
  • Threat actors collected data such as:
  • ICS architecture, layout diagrams, reference documents, vendor information
  • Configuration screenshots of HMIs
  • Configuration details for remote access



Recommendations:
  • Ensure that TCP ports 139 and 445 outbound are denied
  • Consider blocking URL shorteners such as Bit.ly and TinyURL
  • Collect and analyze Windows logs for both servers and desktops
  • Decrypt and inspect Web traffic
  • Enforce geo-IP blocking (inbound and outbound). Blacklist IPs for regions you don’t work in
  • Don’t create overly permissive whitelists for  connections with vendors
  • Enable 2 factor for all external facing systems



Network traffic for attacks
  • These attacks relied on SMB outbound. The infected machine would request the file from the server, which would request credentials.
  • The victim provides the hash, which the attackers were able to brute force
  • Pcap sample of things that happen just to get an icon



Tuesday, June 26, 2018

Windows Search service vulnerability - Bookworm

What is Bookworm?

  • Bookworm is an information disclosure vulnerability affecting all versions of Microsoft windows at least back to Windows 7
  • Bookworm affects the default configuration of Windows operating systems

Is Microsoft aware?

I have disclosed this vulnerability to Microsoft Security response. The vulnerability has been acknowledged but is not planned to be fixed at this time.

How does it work?

Bookworm is an issue with how SearchProtocolHost.exe consumes .url files. Specifically, .url files which have a value in the URL field representing an FTP site on the internet.

A needle in a needle stack

I was examining FTP traffic from a machine that didn't make sense. The traffic occurred at seemingly random intervals for seemingly no reason. I copied a portion of a batch script from the internet for a loop and modified it to dump the connection table to a file every 5 seconds. After waiting for the attempt to connect again, I was able to observe that the image attempting to initiate the traffic was SearchProtocolHost.exe.





SearchProtocolHost.exe?

This behavior really didn't make sense. Why would an indexing service attempt to make an FTP connection outside of the country? The PTR record for 87.238.53.166 resolves to "gunpowder.gitorious.c.bitbit.net" and resides in Norway. I needed to determine how this IP was getting in to  SearchProtocolHost.exe's memory space. Process explorer to the rescue!


Digging in to the process

Using Process explorer, I examined the handles on the image SearchProtcolHost.exe and found this one referencing FTP. Notice that the FTP site is ftp.qt.nokia.com.The string is a file handle, pointing to a URL file in the favorites folder. This is a file created when a site is bookmarked in Internet Explorer.

Dirty, Dirty DNS

The string found is FTP directory –qt-source- at ftp.qt.nokia.com.url. The link in the .url file is ftp.qt.nokia.com.url - this resolves to 87.238.53.166. Someone left their "A" hanging out! Reverse DNS for this IP is nothing related to Nokia. In retrospect, Norway should have been a clue.

What does the traffic look like?

SeachProtocolHost actually does quite a bit. It will login as anonymous, give the password "User@", change to the first specified directory, change the mode, and ask for a list of files, among other commands. Here's a pcap, with the example '48_hour' as the directory


The culprit

In the end, what I discovered as a .url file with the following pattern will trigger this vulnerability: ftp://<anysite>/<dir>/<dir>. Example:

The vulnerability is triggered as follows:
  • On a regular basis when the folder containing the file is indexed 
  • Single clicking on the file
  • Inserting a USB or other drive with the file on the drive
It should be noted that single clicking on the file can cause the process explorer.exe to hang, potentially causing a denial of service condition.

Versions of Windows affected

I tested this in Windows 7, Windows 10, and Server 2012. All are fully patched. Antivirus did not detect this.

What's the value?

We know, at a minimum, the following about a user when exercising this vulnerability
  • The machine is on, and it is at the following public IP
  • The user is not behind a firewall or is behind a firewall allowing FTP
  • The user has taken a desired action, such as inserting a USB
  • We could transfer data out as the directory

Final thoughts

I billed this as a zero-day because I have not observed this before. I was not able to find anything like it on the Internet and MSRC did not appear to have observed this before. If you have evidence of previously disclosing this, please let me know and I will update accordingly.