433 Central Ave., 4th Floor, St. Petersburg, FL 33701 | info@poseidon-us.com | Office: (813) 563-2652

A Nasty Trick: From Credential Theft Malware to Business Disruption

FireEye is tracking a set of financially-motivated activity referred to as TEMP.MixMaster that involves the interactive deployment of Ryuk ransomware following TrickBot malware infections. These operations have been active since at least December 2017, with a notable uptick in the latter half of 2018, and have proven to be highly successful at soliciting large ransom payments from victim organizations. In multiple incidents, rather than relying solely on built-in TrickBot capabilities, TEMP.MixMaster used EMPIRE and RDP connections to enable lateral movement within victim environments. Interactive deployment of ransomware, such as this, allows an attacker to perform valuable reconnaissance within the victim network and identify critical systems to maximize their disruption to business operations, ultimately increasing the likelihood an organization will pay the demanded ransom. These operations have reportedly netted about $3.7 million in current BTC value.

Notably, while there have been numerous reports attributing Ryuk malware to North Korea, FireEye has not found evidence of this during our investigations. This narrative appears to be driven by code similarities between Ryuk and Hermes, a ransomware that has been used by APT38. However, these code similarities are insufficient to conclude North Korea is behind Ryuk attacks, as the Hermes ransomware kit was also advertised for sale in the underground community at one time.

It is important to note that TEMP.MixMaster is solely a reference to incidents where we have seen Ryuk deployed following TrickBot infections and that not all TrickBot infections will lead to the deployment of Ryuk ransomware. The TrickBot administrator group, which is suspected to be based in Eastern Europe, most likely provide the malware to a limited number of cyber criminal actors to use in operations. This is partially evident through its use of “gtags” that appear to be unique campaign identifiers used to identify specific TrickBot users. In recent incidents investigated by our Mandiant incident response teams, there has been consistency across the gtags appearing in the configuration files of TrickBot samples collected from different victim networks where Ryuk was also deployed. The uniformity of the gtags observed across these incidents appears to be due to instances of TrickBot being propagated via the malware’s worming module configured to use these gtag values.

Currently, we do not have definitive evidence that the entirety of TEMP.MixMaster activity, from TrickBot distribution and operation to Ryuk deployment, is being conducted by a common operator or group. It is also plausible that Ryuk malware is available to multiple eCrime actors who are also using TrickBot malware, or that at least one TrickBot user is selling access to environments they have compromised to a third party.  The intrusion operations deploying Ryuk have also been called GRIM SPIDER.

TrickBot Infection Leading to Ryuk Deployment

The following are a summary of tactics observed across incident response investigations where the use of TrickBot preceded distribution of Ryuk ransomware. Of note, due to the interactive nature of Ryuk deployment, the TTPs leading to its execution can vary across incidents. Furthermore, in at least one case artifacts related to the execution of TrickBot were collected but there was insufficient evidence to clearly tie observed Ryuk activity to the use of TrickBot.

Initial Infection

The initial infection vector was not confirmed in all incidents; in one case, Mandiant identified that the attackers leveraged a payroll-themed phishing email with an XLS attachment to deliver TrickBot malware (Figure 1). The campaign is documented on this security site. Data from FireEye technologies shows that this campaign was widely distributed primarily to organizations in the United States, and across diverse industries including government, financial services, manufacturing, service providers, and high-tech.

Once a victim opened the attachment and enabled macros, it downloaded and executed an instance of the TrickBot malware from a remote server. Data obtained from FireEye technologies suggests that although different documents may have been distributed by this particular malicious spam run, the URLs from which the documents attempted to retrieve a secondary payload did not vary across attachments or recipients, despite the campaign’s broad distribution both geographically and across industry verticals. Note that the domain “deloitte-inv[.]com” is not a legitimate Deloitte domain, and does not indicate any compromise of Deloitte.

From: Adam Bush <Adam.Bush@deloitte-inv.com>
Subject: FW: Payroll schedule
Attachment: Payrollschedule.xls

Pay run summary report and individual payslips.
Kind Regards,
Adam Bush
CONFIDENTIALITY NOTICE:
The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.

Figure 1: Email from a phishing campaign that downloaded TrickBot, which eventually led to Ryuk

Persistence and Lateral Movement

When executed, TrickBot created scheduled tasks on compromised systems to execute itself and ensure persistence following system reboot. These instances of TrickBot were configured to use their network propagation modules (sharedll and tabdll) that rely on SMB and harvested credentials to propagate to additional systems in the network. The number of systems to which TrickBot was propagated varied across intrusions from fewer than ten to many hundreds.

Dwell Time and Post-Exploitation Activity

After a foothold was established by the actors controlling TrickBot, a period of inactivity sometimes followed. Dwell time between TrickBot installation and Ryuk distribution varied across intrusions, but in at least one case may have been as long as a full year. Despite this long dwell time, the earliest reports of Ryuk malware only date back to August 2018. It is likely that actors controlling Trickbot instances used to maintain access to victim environments prior to the known availability of Ryuk were monetizing this access in different ways. Further, due to the suspected human-driven component to these intrusion operations, we would expect to commonly see a delay between initial infection and Ryuk deployment or other post-exploitation activity, particularly in cases where the same initial infection vector was used to compromise multiple organizations simultaneously.

Once activity restarted, the actors moved to interactive intrusion by deploying Empire and/or leveraging RDP connections tunneled through reverse-shells instead of relying on the built-in capabilities of TrickBot to interact with the victim network. In multiple intrusions TrickBot’s reverse-shell module (NewBCtestDll) was used to execute obfuscated PowerShell scripts which ultimately downloaded and launched an Empire backdoor.

Variations in Ryuk Deployment Across Engagements

Post exploitation activity associated with each Ryuk incident has varied in historical and ongoing Mandiant incident response engagements. Given that collected evidence suggests Ryuk deployment is managed via human-interactive post-exploitation, variation and evolution in methodology, tools, and approach over time and across intrusions is expected.

The following high-level steps appear common across most incidents into which we have insight:

  • Actors produce a list of targets systems and save it to one or multiple .txt files.
  • Actors move a copy of PsExec, an instance of Ryuk, and one or more batch scripts to one or more domain controllers or other high privilege systems within the victim environment.
  • Actors run batch scripts to copy a Ryuk sample to each host contained in .txt files and ultimately execute them.

Some of the notable ways Ryuk deployment has varied include:

  • In one case, there was evidence suggesting that actors enumerated hosts on the victim network to identify targets for encryption with Ryuk, but in multiple other cases these lists were manually copied to the server that was then used for Ryuk distribution without clear evidence available for how they were produced.
  • There have been multiple cases where TrickBot was deployed broadly across victim environments rather than being used to maintain a foothold on a small number of hosts.
  • We have not identified evidence that Empire was used by the attackers in all cases and sometimes Empire was used to access the victim environment only after Ryuk encryption had started.
  • In one case, the attackers used a variant of Ryuk with slightly different capabilities accompanied by a standalone .bat script containing most of the same taskkill, net, and sc commands normally used by Ryuk to terminate processes and stop services related to anti-virus, backup, and database software.

Example of Ryuk Deployment – Q3 2018

  • Using previously stolen credentials the attacker logged into a domain controller and copied tools into the %TEMP% directory. Copied tools included AdFind.exe (Active Directory enumeration utility), a batch script (Figure 2), and a copy of the 7-Zip archive utility.
  • Downloaded utilities were copied to C:WindowsSysWOW64.
  • The attacker performed host and network reconnaissance using built-in Windows commands.
  • AdFind.exe was executed using the previously noted batch script, which was crafted to pass the utility a series of commands that were used to collect information about Active Directory users, systems, OUs, subnets, groups, and trust objects. The output from each command was saved to an individual text file alongside the AdFind.exe utility (Figure 2).
  • This process was performed twice on the same domain controller, 10 hours apart. Between executions of Adfind the attacker tested access to multiple domain controllers in the victim environment, including the one later used to deploy Ryuk.
  • The attacker logged into a domain controller and copied instances of PSExec.exe, a batch script used to kill processes and stop services, and an instance of Ryuk onto the system.
  • Using PsExec the attacker copied the process/service killing batch script to the %TEMP% folder on hundreds of computers across the victim environment, from which it was then executed.
  • The attacker then used PsExec to copy the Ryuk binary to the %SystemRoot% directories of these same computers. A new service configured to launch the Ryuk binary was then created and started.
  • Ryuk execution proceeded as normal, encrypting files on impacted systems.

adfind.exe -f (objectcategory=person) >  <user_list>.txt

adfind.exe -f objectcategory=computer > <computer_list>.txt

adfind.exe -f (objectcategory=organizationalUnit) > <ou_list>.txt

adfind.exe -subnets -f (objectCategory=subnet) > <subnet_list>.txt

adfind.exe -f “(objectcategory=group)” > <group_list>.txt

adfind.exe -gcb -sc trustdmp >  <trustdmp>.txt

Figure 2: Batch script that uses adfind.exe tool to enumerate Active Directory objects

Example of Ryuk Deployment – Q4 2018

  • An instance of the EMPIRE backdoor launched on a system that had been infected by TrickBot. The attacker used EMPIRE’s built-in capabilities to perform network reconnaissance.
  • Attackers connected to a domain controller in the victim network via RDP and copied several files into the host’s C$ share. The copied files included an instance of PsExec, two batch scripts, an instance of the Ryuk malware, and multiple .txt files containing lists of hosts within the victim environment. Many of the targeted hosts were critical systems across the victim environment including domain controllers and other hosts providing key management and authentication services.
  • The attackers then executed the first of these two batch scripts. The executed script used PsExec and hard-coded credentials previously stolen by the actors to copy the Ryuk binary to each host passed as input from the noted .txt files (Figure 3).
  • Attackers then executed the second batch script which iterated through the same host lists and used PsExec to execute the Ryuk binaries copied by the first batch script (Figure 4).

start PsExec.exe @C:<shared_folder>$<list>.txt -u <domain><username> -p <password> cmd /c COPY “<shared_folder><ryuk_exe>” “C:windowstemp”

Figure 3: Line from the batch file used to copy Ryuk executable to each system

start PsExec.exe -d @C:<shared_folder>$<list>.txt -u <domain><username> -p <password> cmd /c “C:windowstemp<ryuk_exe>”

Figure 4: Line from the batch file used to execute Ryuk on each system

Consistency in TrickBot Group Tags

Each individual TrickBot sample beacons to its Command & Control (C2) infrastructure with a statically defined “gtag” that is believed to act as an identifier for distinct TrickBot customers. There has been significant uniformity in the gtags associated with TrickBot samples collected from the networks of victim organizations.

  • The instance of TrickBot identified as the likely initial infection vector for one intrusion was configured to use the gtag ‘ser0918us’.
    • At the time of distribution, the C2 servers responding to TrickBot samples using the gtag ‘ser0918us’ were sending commands to request that the malware scan victim networks, and then propagate across hosts via the TrickBot worming module.
    • It is possible that in some or all cases instances of TrickBot propagated via the malware’s worming module are configured to use different gtag values, specific to the same TrickBot client, designed to simplify management of implants post-exploitation.
  • A significant proportion of TrickBot samples obtained from the victim environments, including in the case where the infection vector was identified as a sample using gtag ‘ser0918us’, had gtags in the below formats. This may suggest that these gtags are used to manage post-exploitation instanced of TrickBot for campaigns distributed via gtag ‘ser0918us’ and other related gtags.
    • libxxx (ex: lib373, lib369, etc)
    • totxxx (ex: tot373, tot369, etc)
    • jimxxx (ex jim373, jim369, etc)
  • The numbers appended to the end of each gtag appear to increment over time, and in some cases multiple samples sharing the same compile time but using different gtags were observed in the same victim environment, though in each of these cases the numbers appended to the end of the gtag matched (e.g. two distinct samples sharing the compile time 2018-12-07 11:28:23 were configured to use the gtags ‘jim371’ and ‘tot371’).
  • The C2 infrastructure hard-coded into these samples overlaps significantly across samples sharing similar gtag values. However, there is also C2 infrastructure overlap between these samples and ones with dissimilar gtag values. These patterns may suggest the use of proxy infrastructure shared across multiple clients of the TrickBot administrator group.

Implications

Throughout 2018, FireEye observed an increasing number of cases where ransomware was deployed after the attackers gained access to the victim organization through other methods, allowing them to traverse the network to identify critical systems and inflict maximum damage. SamSam operations, which date back to late 2015, were arguably the first to popularize this methodology and TEMP.MixMaster’s is an example of its growing popularity with threat actors. FireEye Intelligence expects that these operations will continue to gain traction throughout 2019 due the success these intrusion operators have had in extorting large sums from victim organizations.

It is also worth highlighting TEMP.MixMaster’s reliance on TrickBot malware, which is more widely distributed, to gain access to victim organizations. Following indiscriminate campaigns, threat actors can profile victims to identify systems and users of interest and subsequently determine potential monetization strategies to maximize their revenue. Various malware families have incorporated capabilities that can aid in the discovery of high-value targets underscoring the necessity for organizations to prioritize proper remediation of all threats, not only those that initially appear to be targeted.

Acknowledgements

The authors would like to thank Brice Daniels, Edward Li, Eric Montellese, Sandor Nemes, Eric Scales, Brandan Schondorfer, Martin Tremblay, and Isif Ibrahima for their contributions to this blog post.

Global DNS Hijacking Campaign: DNS Record Manipulation at Scale

Introduction

FireEye’s Mandiant Incident Response and Intelligence teams have identified a wave of DNS hijacking that has affected dozens of domains belonging to government, telecommunications and internet infrastructure entities across the Middle East and North Africa, Europe and North America. While we do not currently link this activity to any tracked group, initial research suggests the actor or actors responsible have a nexus to Iran. This campaign has targeted victims across the globe on an almost unprecedented scale, with a high degree of success. We have been tracking this activity for several months, mapping and understanding the innovative tactics, techniques and procedures (TTPs) deployed by the attacker. We have also worked closely with victims, security organizations, and law enforcement agencies where possible to reduce the impact of the attacks and/or prevent further compromises.

While this campaign employs some traditional tactics, it is differentiated from other Iranian activity we have seen by leveraging DNS hijacking at scale. The attacker uses this technique for their initial foothold, which can then be exploited in a variety of ways. In this blog post, we detail the three different ways we have seen DNS records be manipulated to enable victim compromises.

Initial Research Suggests Iranian Sponsorship

Attribution analysis for this activity is ongoing. While the DNS record manipulations described in this post are noteworthy and sophisticated, they may not be exclusive to a single threat actor as the activity spans disparate timeframes, infrastructure, and service providers.

  • Multiple clusters of this activity have been active from January 2017 to January 2019.
  • There are multiple, nonoverlapping clusters of actor-controlled domains and IPs used in this activity.
  • A wide range of providers were chosen for encryption certificates and VPS hosts.

Preliminary technical evidence allows us to assess with moderate confidence that this activity is conducted by persons based in Iran and that the activity aligns with Iranian government interests.

  • FireEye Intelligence identified access from Iranian IPs to machines used to intercept, record and forward network traffic. While geolocation of an IP address is a weak indicator, these IP addresses were previously observed during the response to an intrusion attributed to Iranian cyber espionage actors.
  • The entities targeted by this group include Middle Eastern governments whose confidential information would be of interest to the Iranian government and have relatively little financial value.

Details

The following examples use victim[.]com to stand in for the victim domain, and private IP addresses to stand in for the actor controlled IP addresses.

Technique 1 – DNS A Records

The first method exploited by the attacker is altering DNS A Records, as seen in Figure 1.


Figure 1: DNS A Record

  1. The attacker logs into PXY1, a Proxy box used to conduct non-attributed browsing and as a jumpbox to other infrastructure.
  2. The attacker logs into the DNS provider’s administration panel, utilising previously compromised credentials.
  3. The A record (e.g. mail[.]victim[.]com) is currently pointing to 192.168.100.100.
  4. The attacker changes the A record and points it to 10.20.30.40 (OP1).
  5. The attacker logs in from PXY1 to OP1.
    • A proxy is implemented to listen on all open ports, mirroring mail[.]victim[.]com.
    • A load balancer points to 192.168.100.100 [mail[.]victim[.]com] to pass through user traffic.
  6. certbot is used to create a Let’s Encrypt Certificate for mail[.]victim[.]com
    • We have observed multiple Domain Control Validation providers being utilised as part of this campaign.
  7. A user now visits mail[.]victim[.]com and is directed to OP1. The Let’s Encrypt Certificate allows the browsers to establish a connection without any certificate errors as Let’s Encrypt Authority X3 is trusted. The connection is forwarded to the load balancer which establishes the connection with the real mail[.]victim[.]com. The user is not aware of any changes and may only notice a slight delay.
  8. The username, password and domain credentials are harvested and stored.
Technique 2 – DNS NS Records

The second method exploited by the attacker involved altering DNS NS Records, as seen in Figure 2.


Figure 2: DNS NS Record

  1. The attacker again logs into PXY1.
  2. This time, however, the attacker exploits a previously compromised registrar or ccTLD.
  3. The nameserver record ns1[.]victim[.]com is currently set to 192.168.100.200. The attacker changes the NS record and points it to ns1[.]baddomain[.]com [10.1.2.3]. That nameserver will respond with the IP 10.20.30.40 (OP1) when mail[.]victim[.]com is requested, but with the original IP 192.168.100.100 if it is www[.]victim[.]com.
  4. The attacker logs in from PXY1 to OP1.
    • A proxy is implemented to listen on all open ports, mirroring mail[.]victim[.]com.
    • A load balancer points to 192.168.100.100 [mail[.]victim[.]com] to pass through user traffic.
  5. certbot is used to create a Let’s Encrypt Certificate for mail[.]victim[.]com.
    • We have observed multiple Domain Control Validation providers being utilised during this campaign.
  6. A user visits mail[.]victim[.]com and is directed to OP1. The Let’s Encrypt Certificate allows browsers to establish a connection without any certificate errors as Let’s Encrypt Authority X3 is trusted. The connection is forwarded to the load balancer which establishes the connection with the real mail[.]victim[.]com. The user is not aware of any changes and may only notice a slight delay.
  7. The username, password and domain credentials are harvested and stored.
Technique 3 – DNS Redirector

The attacker has also been observed using a third technique in conjunction with either Figure 1 or Figure 2 above. This involves a DNS Redirector, as seen in Figure 3.


Figure 3: DNS Operational box

The DNS Redirector is an attacker operations box which responds to DNS requests.

  1. A DNS request for mail[.]victim[.]com is sent to OP2 (based on previously altered A Record or NS Record).
  2. If the domain is part of victim[.]com zone, OP2 responds with an attacker-controlled IP address, and the user is re-directed to the attacker-controlled infrastructure.
  3. If the domain is not part of the victim.com zone (e.g. google[.]com), OP2 makes a DNS request to a legitimate DNS to get the IP address and the legitimate IP address is returned to the user.

Targets

A large number of organizations have been affected by this pattern of DNS record manipulation and fraudulent SSL certificates. They include telecoms and ISP providers, internet infrastructure providers, government and sensitive commercial entities.

Root Cause Still Under Investigation

It is difficult to identify a single intrusion vector for each record change, and it is possible that the actor, or actors are using multiple techniques to gain an initial foothold into each of the targets described above. FireEye intelligence customers have received previous reports describing sophisticated phishing attacks used by one actor that also conducts DNS record manipulation. Additionally, while the precise mechanism by which the DNS records were changed is unknown, we believe that at least some records were changed by compromising a victim’s domain registrar account.

Prevention Tactics

This type of attack is difficult to defend against, because valuable information can be stolen, even if an attacker is never able to get direct access to your organization’s network. Some steps harden your organization are below:

  1. Implement multi-factor authentication on your domain’s administration portal.
  2. Validate A and NS record changes.
  3. Search for SSL certificates related to your domain and revoke any malicious certificates.
  4. Validate the source IPs in OWA/Exchange logs.
  5. Conduct an internal investigation to assess if attackers gained access to your environment.

Conclusion

This DNS hijacking, and the scale at which it has been exploited, showcases the continuing evolution in tactics from Iran-based actors. This is an overview of one set of TTPs that we recently observed affecting multiple entities. We are highlighting it now so that potential targets can take appropriate defensive action.

Digging Up the Past: Windows Registry Forensics Revisited

Introduction

FireEye consultants frequently utilize Windows registry data when performing forensic analysis of computer networks as part of incident response and compromise assessment missions. This can be useful to discover malicious activity and to determine what data may have been stolen from a network. Many different types of data are present in the registry that can provide evidence of program execution, application settings, malware persistence, and other valuable artifacts.

Performing forensic analysis of past attacks can be particularly challenging. Advanced persistent threat actors will frequently utilize anti-forensic techniques to hide their tracks and make the jobs of incident responders more difficult. To provide our consultants with the best possible tools we revisited our existing registry forensic techniques and identified new ways to recover historical and deleted registry data. Our analysis focused on the following known sources of historical registry data:

  • Registry transaction logs (.LOG)
  • Transactional registry transaction logs (.TxR)
  • Deleted entries in registry hives
  • Backup system hives (REGBACK)
  • Hives backed up with System Restore

Windows Registry Format

The Windows registry is stored in a collection of hive files. Hives are binary files containing a simple filesystem with a set of cells used to store keys, values, data, and related metadata. Registry hives are read and written in 4KB pages (also called bins).

For a detailed description of the Windows registry hive format, see this research paper and this GitHub page.

Registry Transaction Logs (.LOG)

To maximize registry reliability, Windows can use transaction logs when performing writes to registry files. The logs act as journals that store data being written to the registry before it is written to hive files. Transaction logs are used when registry hives cannot directly be written due to locking or corruption.

Transaction logs are written to files in the same directory as their corresponding registry hives. They use the same filename as the hive with a .LOG extension. Windows may use multiple logs in which case .LOG1 and .LOG2 extensions will be used.

For more details about the transaction log format, see this GitHub page.

Registry transaction logs were first introduced in Windows 2000. In the original transaction log format data is always written at the start of the transaction log. A bitmap is used to indicate what pages are present in the log, and pages follow in order. Because the start of the file is frequently overwritten, it is very difficult to recover old data from these logs. Since different amounts of data will be written to the transaction log on each use, it is possible for old pages to remain in the file across multiple uses. However, the location of each page will have to be inferred by searching for similar pages in the current hive, and the probability of consistent data recovery is very small.

A new registry transaction log format was introduced with Windows 8.1. Although the new logs are used in the same fashion, they have a different format. The new logs work like a ring buffer where the oldest data in the log is overwritten by new data. Each entry in the new log format includes a sequence number as well as registry offset making it easy to determine the order of writes and where the pages were written. Because of the changed log format, data is overwritten much less frequently, and old transactions can often be recovered from these log files.

The amount of data that can be recovered depends on registry activity. A sampling of transaction logs from real world systems showed a range of recoverable data from a few days to a few weeks. Real world recoverability can vary considerably. Registry-heavy operations, such as Windows Update, can significantly reduce the recoverable range.

Although the new log format contains more recoverable information, turning a set of registry pages into useful data is quite tricky. First, it requires keeping track of all pages in the registry and determining what might have changed in a particular write. It also requires determining if that change resulted in something that is not present in later revisions of the hive to assess whether or not it contains unique data.

Our current approach for processing registry transaction files uses the following algorithm:

  1. Sort all writes by sequence number descending so that we process the most recent writes first.
  2. Perform allocated and unallocated cell parsing to find allocated and deleted entries.
  3. Compare entries against the original hive. Any entries that are not present are marked as deleted and logged.

Transaction Log Example

In this example we create a registry value under the Run key that starts malware.exe when the user logs in to the system.


Figure 1: A malicious actor creates a value in the Run key

At a later point in time the malware is removed from the system. The registry value is overwritten before being deleted.


Figure 2: The malicious value is overwritten and deleted

Although the deleted value still exists in the hive, existing forensic tools will not be able to recover the original data because it was overwritten.


Figure 3: The overwritten value is present in the registry hive

However, in this case the data is still present in the transaction log and can be recovered.


Figure 4: The transaction log contains the original value

Transactional Registry Transaction Logs (.TxR)

In addition to the transaction log journal there are also logs used by the transactional registry subsystem. Applications can utilize the transactional registry to perform compound registry operations atomically. This is most commonly used by application installers as it simplifies failed operation rollback.

Transactional registry logs use the Common Log File Sytstem (CLFS) format. The logs are stored to files of the form <hive><GUID>.TxR.<number>.regtrans-ms. For user hives these files are stored in the same directory as the hive and are cleared on user logout. However, for system hives logs are stored in %SystemRoot%System32configTxR, and the logs are not automatically cleared. As a result, it is typically possible to recover historical data from system transactional logs.

The format of transactional logs is not well understood or documented. Microsoft has provided a general overview of CLFS logs and API.

With some experimentation we were able to determine the basic record format. We can identify records for registry key creation and deletion as well as registry value writes and deletes. The relevant key path, value name, data type, and data are present within log entries. See the appendix for transaction log record format details.

Although most data present in registry transaction logs is not particularly valuable for intrusion investigations, there are some cases where the data can prove useful. In particular, we found that scheduled task creation and deletion use registry transactions. By parsing registry transaction logs we were able to find evidence of attacker created scheduled tasks on live systems. This data was not available in any other location.

The task scheduler has been observed using transactional registry operations on Windows Vista through Windows 8.1; the task scheduler on Windows 10 does not exhibit this behavior. It is not known why Windows 10 behaves differently.

Transactional Registry Example

In this example we create a scheduled task. The scheduled task periodically runs malware.


Figure 5: Creating a scheduled task to run malware

Information about the scheduled task is stored to the registry.


Figure 6: A registry entry created by the task scheduler

Because the scheduled task was written to the registry using transacted registry operations, a copy of the data is available in the transactional registry transaction log. The data can remain in the log well after the scheduled task has been removed from the system.


Figure 7: The malicious scheduled task in the TxR log

Deleted Entry Recovery

In addition to transaction logs, we also examined methods for the recovery of deleted entries from registry hive files. We started with an in-depth analysis of some common techniques used by forensic tools today in the hopes of identifying a more accurate approach.

Deleted entry recovery requires parsing registry cells in hive files. This is relatively straightforward. FireEye has a number of tools that can read raw registry hive files and parse relevant keys, values, and data from cells. Recovering deleted data is more complex because some information is lost when elements are deleted. A more sophisticated approach is required to deal with the resulting ambiguity.

When parsing cells there is only one common field: the cell size. Some cell types contain magic number identifiers, which can help determine their type. However, other cell types, such as data and value lists, do not have identifiers; their types must be inferred by following references from other cells. Additionally, the size of data within a cell can differ from the cell size. Depending on the cell type it may be necessary to leverage information from referencing cells to determine the data size.

When a registry element is deleted its cells are marked as unallocated. Because the cells are not immediately overwritten, deleted elements can often be recovered from registry hives. However, unallocated cells may be coalesced with adjacent unallocated cells to maximize traversal efficiency. This makes deleted cell recovery more complex because cell sizes may be modified. As a result, original cell boundaries are not well defined and must be determined implicitly by examining cell contents.

Existing Approaches for Recovering Deleted Entries

A review of public literature and source code revealed existing methods for recovery of deleted elements from registry hive files. Variations of the following algorithm were commonly found:

  1. Search through all unallocated cells looking for deleted key cells.
  2. Find referenced deleted values from deleted keys.
  3. Search through all remaining unallocated cells looking for unreferenced deleted value cells.
  4. Find referenced data cells from all deleted values.

We implemented a similar algorithm to experiment with its efficacy. Although this simple algorithm was able to recover many deleted registry elements, it had a number of significant shortcomings. One major issue was the inability to validate any references from deleted cells. Because referenced cells may have already been overwritten or reused multiple times, our program frequently made mistakes in identifying values and data resulting in false positives and invalid output.

We also compared program output to popular registry forensic tools. Although our program produced much of the same output, it was evident that existing registry forensic tools were able to recover more data. In particular, existing tools were able to recover deleted elements from slack space of allocated cells that had not yet been overwritten.

Additionally, we found that orphaned allocated cells are also considered deleted. It is not known how unreferenced allocated cells could exist in a registry hive as all related cells should be unallocated simultaneously on deletion. It is possible that certain types of failures could result in deleted cells not becoming unallocated properly.

Through experimentation we discovered that existing registry tools were able to perform better validation resulting in fewer false positives. However, we also identified many cases where existing tools made incorrect deleted value associations and output invalid data. This likely occurs when cells are reused multiple times resulting in references that could appear valid if not carefully scrutinized.

A New Approach for Recovering Deleted Entries

Given the potential for improving our algorithm, we undertook a major redesign to recover deleted registry elements with maximum accuracy and efficiency. After many rounds of experimentation and refinement we ended up with a new algorithm that can accurately recover deleted registry elements while maximizing performance. This was achieved by discovering and keeping track of all cells in registry hives to perform better validation, by processing cell slack space, and by discovering orphaned keys and values. Testing results closely matched existing registry forensics tools but with better validation and fewer false positives.

The following is a summary of the improved algorithm:

  1. Perform basic parsing for all allocated and unallocated cells. Determine cell type and data size where possible.
  2. Enumerate all allocated cells and do the following:
    • For allocated keys find referenced value lists, class names, and security records. Populate data size of referenced cells. Validate key ancestors to determine if the key has been orphaned.
    • For allocated values find referenced data and populate data size.
  3. Define all allocated cell slack space as unallocated cells.
  4. Enumerate allocated keys and attempt to find deleted values present in the values list. Also attempt to find old deleted value references in the value list slack space.
  5. Enumerate unallocated cells and attempt to find deleted key cells.
  6. Enumerate unallocated keys and attempt to define referenced class names, security records, and values.
  7. Enumerate unallocated cells and attempt to find unreferenced deleted value cells.
  8. Enumerate unallocated values and attempt to find referenced data cells.

Deleted Recovery Example

The following example demonstrates how our deleted entry recovery algorithm can perform more accurate data recovery and avoid false positives. Figure 8 shows an example of a data recovery error by a popular registry forensics tool:


Figure 8: Incorrectly recovered registry data

Note that the ProviderName recovered from this key was jumbled because it referred to a location that had been overwritten. When our deleted registry recovery tool is run over the same hive, it recognizes that the data has been overwritten and does not output garbled text. The data_present field in Figure 9 with a value of 0 indicates that the deleted data could not be recovered from the hive.

Key: CMI-CreateHive{2A7FB991-7BBE-4F9D-B91E-7CB51D4737F5}
     ControlSet002ControlClass{4D36E972-E325-11CE-BFC1-08002BE10318}019
Value: ProviderName  Type: REG_SZ  (value_offset=0x137FE40) (data_size=20)
     (data_present=0) (data_offset=0x10EAF68) (deleted_type=UNALLOCATED)

Figure 9: Properly validated registry data

Registry Backups

Windows includes a simple mechanism to backup system registry hives periodically. The hives are backed up with a scheduled task called RegIdleBackup, which is scheduled to run every 10 days by default. Backed up hives are stored to %SystemRoot%System32configRegBack. Only the most recent backup is stored in this location. This can be useful for investigating recent activity on a system.

The RegIdleBackup feature was first included with Windows Vista. It is present in all versions of Windows since then, but it does not run by default on Windows 10 systems, and even when it is manually run no backups are created. It is not known why RegIdleBackup was removed from Windows 10.

In addition to RegBack, registry data is backed up with System Restore. By default, System Restore snapshots are created whenever software is installed or uninstalled, including Windows Updates. As a result, System Restore snapshots are usually created on at least a monthly basis if not more frequently. Although some advanced persistent threat groups have been known to manipulate System Restore snapshots, evidence of historical attacker activity can usually be found if a snapshot was taken at a time when the attacker was active. System Restore snapshots contain all registry hives including system and user hives.

Wikipedia has some good information about System Restore.

Processing hives in System Restore snapshots can be challenging as there may be many snapshots present on a system resulting in a large amount of data to be processed, and often there will only be minor changes in hives between snapshots. One strategy to handle the large number of snapshots is to build a structure representing the cells of the registry hive, then repeat the process for each snapshot. Anything not in the previous structure can be considered deleted and logged appropriately.

Conclusion

The registry can provide a wealth of data for a forensic investigator. With numerous sources of deleted and historical data, a more complete picture of attacker activity can be assembled during an investigation. As attackers continue to gain sophistication and improve their tradecraft, investigators will have to adapt to discover and defend against them.

Appendix – Transactional Registry Transaction Log (.TxR) Record Format

Registry transaction logs contain records with the following format:

Offset

Field

Size

0

Magic number (0x280000)

4

 

 

12

Record size

4

16

Record type (1)

4

20

Registry operation type

2

 

 

40

Key path size

2

42

Key path size repeated

2

The magic number is always 0x280000.
The record size includes the header.
The record type is always 1.

Operation type 1 is key creation.
Operation type 2 is key deletion.
Operation types 3-8 are value write or delete. It is not known what the different types signify.

The key path size is at offset 40 and repeated at offset 42. This is present for all registry operation types.

For registry key write and delete operations, the key path is at offset 72.

For registry value write and delete operations, the following data is present:

Offset

Field

Size

56

Value name size

2

58

Value name size repeated

2

 

 

72

Data type

4

76

Data size

4

The data for value records starts at offset 88. It contains the key path followed by the value name optionally followed by data. If data size is nonzero, the record is a value write operation; otherwise it is a value delete operation.

Philips iSite and IntelliSpace PACS

1. EXECUTIVE SUMMARY

  • CVSS v3 6.3

  • ATTENTION: Low skill level to exploit
  • Vendor: Philips
  • Equipment: iSite and IntelliSpace PACS
  • Vulnerability: Weak Password Requirements

2. RISK EVALUATION

Successful exploitation of this vulnerability may allow an attacker with local network access to impact confidentiality, integrity, and availability of a component of the system.

3. TECHNICAL DETAILS

3.1 AFFECTED PRODUCTS

Philips reports the following versions of iSite and IntelliSpace PACS are affected:

  • iSite PACS, all versions, and
  • IntelliSpace PACS, all versions.

3.2 VULNERABILITY OVERVIEW

3.2.1    WEAK PASSWORD REQUIREMENTS CWE-521

Default credentials and no authentication within third party software may allow an attacker to compromise a component of the system.

CVE-2018-17906 has been assigned to this vulnerability. A CVSS v3 base score of 6.3 has been calculated; the CVSS vector string is (AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L).

3.3 BACKGROUND

  • CRITICAL INFRASTRUCTURE SECTORS: Healthcare and Public Health
  • COUNTRIES/AREAS DEPLOYED: Worldwide
  • COMPANY HEADQUARTERS LOCATION: Netherlands

3.4 RESEARCHER

A user reported this vulnerability to Philips, who then reported it to NCCIC.

4. MITIGATIONS

Philips recommends that users ensure IntelliSpace PACS installations run in a managed service environment that adheres to NCCIC recommendations to minimize the risk of exploitation (Virtual Private Network, Firewall isolation from other networks, no Internet access). In addition, Philips employs an automated Antivirus solution that continuously monitors and remediates threats across all systems in the managed service environment. Philips has a monthly recurring patch program which all IntelliSpace PACS users are encouraged to participate. Users who participate in this program receive all Philips approved operating system and application patches in a timely fashion. The Philips iSite 3.6 platform is currently at its end of life (EoL) and end of service (EoS).

As an interim mitigation to the vulnerability, Philips recommends that users:

  • Ensure only authorized personnel can connect to the controlled network environment.
  • Review instructions for use guidelines available with the application interface and follow the security best practices.

Philips will continue to add cybersecurity vulnerability remediation improvements through their secure development lifecycle (SDL) as threats continue.

Users with questions regarding specific iSite/IntelliSpace PACS solutions are advised by Philips to contact their customer success manager (CSM), local Philips service support team, or regional service support. Philips contact information is available at the following location:

https://www.usa.philips.com/healthcare/solutions/customer-service-solutions

Please see the Philips product security website for the latest security information for Philips products:

https://www.philips.com/productsecurity

NCCIC recommends users take defensive measures to minimize the risk of exploitation of this vulnerability. Specifically, users should:

  • Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
  • Locate control system networks and remote devices behind firewalls, and isolate them from the business network.

NCCIC reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

NCCIC also provides a section for control systems security recommended practices on the ICS-CERT web page. Several recommended practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

Additional mitigation guidance and recommended practices are publicly available on the ICS-CERT website in the Technical Information Paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing any suspected malicious activity should follow their established internal procedures and report their findings to NCCIC for tracking and correlation against other incidents.

No known public exploits specifically target this vulnerability. This vulnerability is exploitable from within the same local device subnet.

Telecrane F25 Series

1. EXECUTIVE SUMMARY

  • CVSS v3 7.6

  • ATTENTION: Low skill level to exploit
  • Vendor: Telecrane
  • Equipment: F25 Series
  • Vulnerability: Authentication Bypass by Capture-Replay

2. RISK EVALUATION

Successful exploitation of this vulnerability could allow unauthorized users to view commands, replay commands, control the device, or stop the device from running.

3. TECHNICAL DETAILS

3.1 AFFECTED PRODUCTS

The following versions of Telecrane remote controls are affected:

  • F25 Series all versions prior to 00.0A

3.2 VULNERABILITY OVERVIEW

3.2.1    AUTHENTICATION BYPASS BY CAPTURE-REPLAY CWE-294

These devices use fixed codes that are reproducible by sniffing and re-transmission. This can lead to unauthorized replay of a command, spoofing of an arbitrary message, or keeping the controlled load in a permanent “stop” state.

CVE-2018-17935 has been assigned to this vulnerability. A CVSS v3 base score of 7.6 has been calculated; the CVSS vector string is (AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:H).

3.3 BACKGROUND

  • CRITICAL INFRASTRUCTURE SECTORS: Multiple
  • COUNTRIES/AREAS DEPLOYED: United States
  • COMPANY HEADQUARTERS LOCATION: Taiwan

3.4 RESEARCHER

Jonathan Andersson, Philippe Z Lin, Akira Urano, Marco Balduzzi, Federico Maggi, Stephen Hilt, and Rainer Vosseler working with Trend Micro’s Zero Day Initiative reported this vulnerability to NCCIC.

4. MITIGATIONS

Telecrane recommends upgrading to the latest firmware. Firmware version 00.0A resolves this vulnerability and can be obtained through the product distributor.

NCCIC recommends users take defensive measures to minimize the risk of exploitation of this vulnerability. Specifically, users should:

  • Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
  • Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
  • When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.

NCCIC reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

NCCIC also provides a section for control systems security recommended practices on the ICS-CERT web page. Several recommended practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

Additional mitigation guidance and recommended practices are publicly available on the ICS-CERT website in the Technical Information Paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies.

Organizations observing any suspected malicious activity should follow their established internal procedures and report their findings to NCCIC for tracking and correlation against other incidents.

No known public exploits specifically target this vulnerability.