Many threat actors use multiple attack vectors to ensure success. The individuals using Hancitor malware (also known by the name Chanitor) are no exception and have taken three approaches to deliver the malware in order to ultimately steal data from their victims. These techniques include uncommon API abuse and PowerShell methods.

We recently observed Hancitor attacks against some of our FireEye Exploit Guard customers. The malicious document used to deliver the Hancitor executable was observed being distributed as an attachment in email spam. Once downloaded and executed, it drops an intermediate payload that further downloads a Pony DLL and Vawtrak executable, which perform data theft and connect to a command and control (C2) server.

Stage 1: Email Delivery

We observed a number of phishing emails that reference an invoice, as seen in Figure 1. The attachment in these emails is a weaponized Microsoft Office document containing a malicious macro that – when enabled – leads to the download of Hancitor.

Figure 1:  Email with a malicious document attached

Stage 2: Macro and Luring Mechanism

Upon opening the attachment, a typical luring mechanism is employed instructing the victim to enable macros, as seen in Figure 2. FireEye has observed the attackers behind this campaign using three different approaches.

Figure 2:  Luring the victim to enable macros

First Approach

Unlike other malicious macros, this one is not using APIs directly to run the payload. Macros can call APIs directly, but normally are not supposed to run shellcode. The macro used to deliver Hancitor calls the native Windows API, “CallWindowProc”, which can be used to interpret and execute shellcode, as depicted in Figure 3.

Figure 3:  Code within the macro that uses the CallWindowProc API to execute shellcode

Second Approach

Recently, FireEye Exploit Guard captured Hancitor samples that leverage a new API Callback function. In addition to “CallWindowProc”, Hancitor samples may use the function EnumResourceTypesA to interpret and execute shellcode, as seen in Figure 4.

Figure 4:  EnumResourceTypesA API declaration

Third Approach

We also observed a third approach used by a malicious document file to deliver Hancitor. Although the threat actor and command and control servers are similar to the second Hancitor delivery approach, this one uses an alternate tactic to reach its goal of data theft.

With this approach, the luring message shown in the Figure 2 now serves another purpose. Not only does it lure the victim into enabling the macros, but it also is assigned an alternate text: “fkwarning”, as seen in Figure 5. The macro has code to check this attribute to make sure the luring message shape object is present. If this object is not found, the macro will exit without downloading additional payloads.

Figure 5:  Code to ensure that the luring message is intact and the malicious document is executed for the first time

Even if it finds the luring message, it will run the macro once and will delete the shape so that the macro will never be executed again, as seen in Figure 6.

Figure 6: Code to delete the shape that includes the lure message

The malicious macro replaces the deleted image with another that displays the text “network error” to reduce user suspicions, as shown in Figure 7. Note that text is always present in the malicious macro, but it will only be made visible by the macro when it is executing for the first time.

Figure 7: The hidden text that becomes visible once the macro is executed for the first time

The macro then combines fragments of code to make a PowerShell command. However, unlike in the other approaches, the malicious code is not hidden in the code or form or metadata. We observed that the malware extracts malicious code fragments from within the section_header of the embedded image and combines them into a PowerShell command on the fly, as seen in Figure 8. This technique will evade some basic static methods of detection applied to macros macro forms.

Figure 8:  PowerShell command observed in header after increasing font size

The malware authors have taken a very simple but interesting approach to obscure the PowerShell command text. The font size is set to microscopic level 1, as seen in Figure 9. This reduces the likelihood that a casual observer will notice something unusual.

Figure 9:  Minimal font size to hide content of header

Using the “DownloadFile” method, PowerShell obtains a payload from an attacker-controlled website in a ZIP archive format. PowerShell uses the “copyhere” function to unzip the payload. The “.Item” attribute is also set to “16”, which ignores all warnings, as seen in Figure 10.

Figure 10: Code to download archived payload and unzip it

Once the downloaded executable is extracted from the ZIP archive, the macro code deletes the archive using the “Kill” function, as seen in Figure 11. After the executable is executed, it downloads Pony and Vawtrak malware variants to steal data.

Figure 11:  Code to delete the archive

Different Approaches, Same Hancitor

Although there are differences between the second and third approaches to distributing Hancitor, the objective of the threat actor is the same, as we found the same command and control server being used in both approaches.

However, we can see a minor change in the second Hancitor approach command and control servers when compared to the first Hancitor approach command and control servers, with URLs ending with ls5/gate.php instead of ls4/gate.php, as seen in Figure 12.

Figure 12: Earlier and newer Hancitor gates

Stage 3: First stage payload

The file copies itself to “%system32%” and creates a registry run key entry for persistence. Upon execution, it will communicate with an attacker-controller website to download a variant of the Pony malware, “pm.dll” along with a standard Vawtrak trojan.

Stage 4: Second stage payload Pony data exfiltration capabilities

We observed a number of data theft capabilities in the second stage Pony variant, including:

1) Stealing autocomplete Intelliforms data, which may include user passwords, as seen in Figure 13.

Figure 13: Stealing the content of the Intelliforms registry key

2) The unique GUID seen in Figure 14 helps to decrypt credentials from credential store. There is a good amount of documentation on various forums on how to use this salted value to access credentials.

Figure 14: Credential stealing

3) Accessing Mozilla saved passwords from “signons.txt,” as seen in Figure 15.

Figure 15: Accessing Mozilla saved passwords

4) Figure 16 shows the malware code related to theft via accessing Microsoft OMI Email configuration information. We can also see registry entries related to storing Outlook Profile, which contains information about where emails and other data is stored being accessed.

Figure 16:  Malware code for Outlook data theft via registry access

Conclusion

The malware authors responsible for Hancitor have developed several capabilities within malicious macros that support malware installation and data theft. These capabilities include leveraging uncommon APIs and obscuring malicious PowerShell commands, tactics that made detection more challenging.

FireEye Exploit Guard provides organizations with the ability to detect malicious shellcode in the initial phase of the attack lifecycle, regardless of these evasion techniques.

FireEye recommends that organizations block macros in Microsoft Office documents that originate from the Internet by Group Policy. In all cases, users should be cautious about enabling macros and should practice vigilance about opening email messages from untrusted sources.

FireEye iSIGHT Intelligence has been tracking a pair of cybercriminals that we refer to as the “Vendetta Brothers.” This enterprising duo uses various strategies to compromise point-of-sale systems, steal payment card information and sell it on
their underground marketplace “Vendetta World.”

The Vendetta Brothers – who we believe operate from Spain and Eastern Europe – have been observed using everything from phishing to installing physical skimmers to steal payment card data, and their targets have mostly been located in the U.S. and Nordic countries.

Our latest report shines light on the Vendetta Brothers’ tactics, techniques and procedures, which involve the use of practices more commonly seen
in legitimate business, including outsourcing, partnerships, diversifying their market, and insulating liability.

We expect to see other cybercriminal groups using these more advanced techniques as a way of scaling their operations and increasing profits, all while mitigating risk and potentially frustrating investigators.

Download the report to learn more about the Vendetta Brothers.

Introduction

Throughout the past few months, FireEye Labs has observed an increased use of Windows Management Instrumentation (WMI) queries for environment detection and evasion of dynamic analysis and virtualization engines. WMI provides high-level interaction with Windows objects using C/C++, VBScript, JScript, C#, etc. in the form of WMI Query Language (WQL). Last year, FireEye published a white paper detailing an in-depth analysis of WMI infrastructure and potential abuses of WMI services by malware writers.

In this post we will present an analysis of some samples found in the wild in 2016. For the purposes of this blog post, we will focus on evasion only, ignoring other malicious aspects of the samples.

Evasion after Anti-Virus Detection

Anti-virus can be detected by a WMI query as they are registered in AntiVirusProduct class under root\SecurityCenter2 (root\SecurityCenter before Vista) namespace. We analyzed a sample that checked the operating system from Win32_OperatingSystem class under root\cimv2 namespace first and if the OS version was above 6 (Windows Vista and above), then anti-virus check was performed. Figure 1 shows the VBScript code of anti-virus check.

 Figure 1: Anti-virus product checks in VBScript code using WMI query

Anti-virus and other user information is sent to the server for fetching the right payload or performing evasion, as shown in Figure 2.

 Figure 2: Anti-virus and other info being sent to the server and actions against response

Virtualization Detection and Evasions

One of the samples was found to monitor many security products using different techniques, but most popular virtualization software (such as VMware and VirtualBox) was being detected using WMI queries. It retrieves BIOS information from Win32_BIOS class under root\cimv2 namespace. Specific fields/columns can also be retrieved similar to an SQL query. The following queries were found in this sample binary (Figure 3).

Figure 3: Virtualization software checks by the malware using WMI queries

The query yields the following result when executed in PowerShell in Bochs Emulator, as shown in Figure 4.

Figure 4: Query result in PowerShell in Bochs Emulator

Figure 5 shows the full scale environment detection being performed by this sample. Other services may be checked by populating the running processes or using Windows Registry.

Figure 5: Security products being monitored by the malware

Another sample used Win32_ComputerSystem class for virtual machines detection, as show in Figure 6. The result of the query (Figure 9) has ’Model’ field (Figure 7), which holds the virtual machine information in case of VMware, VirtualBox and Virtual Machine.  

Figure 6: ComputerSystem WMI query found in the sample

Figure 7: Model column retrieval

When any of the three strings matched with ‘Model’ field output, virtualization gets detected by matching the stored value with the one created in the process, as evident in Figure 8.

Figure 8: VirtualBox, VMware and Virtual Machine checks

When the aforementioned query was executed in PowerShell in VMware workstation 12.0, it gave the result illustrated in Figure 9.  

Figure 9: Query result in PowerShell 2.0

Another sample used Win32_VideoController and Win32_DiskDrive classes to detect virtual environments. Figure 10 shows the WMI queries found in the text section of this sample along with process names of VMware, Wireshark, Fiddler and other security products, which are also being checked before execution of WMI queries.

Figure 10: WMI queries found in the text section of the sample

The WMI query in Figure 10 has been highlighted in the code section in Figure 11. When executed in PowerShell (Figure 12) it reveals a wealth of information through which virtual machines can easily be detected, as VMware is being detected in Figure 11.

Figure 11: WMI query in the code

Figure 12: WMI query, to get Video Controller information, result when executed in PowerShell

The same sample has used Win32_DiskDrive to detect VirtualBox (Figure 13), Virtual Hard disk (Figure 14) and VMware (Figure 15). When any of the virtual machines are detected, the process terminates itself, evading the behavioral analysis.

 Figure 13: VirtualBox detection

Figure 14: Virtual Hard disk detection

Figure 15: VMware detection

Process Detection

We analyzed a sample that not only checked a specific process from Win32_Process class under namespace root\cimv2, but also killed it. Immunity debugger, a well-known debugger, is terminated and its folder is deleted after changing permissions using Windows Script Host shell, as evident in the code in Figure 16.

Figure 16: Immunity debugger being killed and folder being deleted

Moreover, anti-virus vendor Kingsoft Corporation’s processes are also forced to stop execution, meaning its anti-virus processes are being killed. The code is shown in Figure 17. Usually samples use CreateToolHelp32Snapshot, Process32First and Process32Next APIs for finding a process, but here it is evident that one WMI query comes in handy to replace tens of lines of code.

Figure 17. Code designed to kill processes associated with Kingsoft (an anti-virus product company)

Windows Services Detection

Another sample, an MS Office key generator, checked Windows Office Software Protection Service through WMI queries (Figure 18). This service enables software vendors to enforce secure licensing on the client machines. If this service is not running, it is started as shown in Figure 19. Once Office Software Protection Service object is retrieved, it is then used to install MS Office product key.

Figure 18: Office Software Protection Service check using WMI query

Figure 19: Code to start/restart Office Software Protection Service

Summary

During analysis and research, it has been observed that WMI queries, shown in Figure 20, can be used for environment detection and (with more details) for evasion as well. There may be more queries that are not listed in Figure 20, but we suggest security researchers should at least monitor the listed queries for evaluating the samples.

Figure 20: Possible WMI queries for environment detection

Conclusion

Malware writers are always in search of new ways to evade analysis frameworks and sandboxes to make the payload execution successful in their targeted environments and platforms. WMI provides a simple way of environment detection that can be used to evade sandboxes and dynamic analysis tools, which seem to be underestimated by reverse engineers and others in the security community. Mitigation steps should be taken to monitor WMI queries that could lead to possible evasion.       

Acknowledgements

We would like to thank Matthew Dunwoody for his valuable input. Moreover, we are also grateful to Muhammad Umer Khan and Imran Khan for their continuous support in providing relevant sample sets and validation effort.

Introduction

Brazil has been designated a major hub for financially motivated eCrime threat activity. Brazilian threat actors are targeting domestic and foreign entities and individuals, with frequent targeting of U.S. assets. The country routinely places in "Top Five" lists of various global cyber crime rankings, and multiple sources claim that financially motivated threat activity in the country has increased within the past few years.

In this blog we provide insight into the tactics, techniques and procedures (TTPs) of a Brazilian cyber crime group that specializes in payment card fraud operations. The threat actors, observed by FireEye Labs, use a variety of different methods to either compromise or acquire already compromised payment card credentials, including sharing or purchasing dumps online, hacking vulnerable merchant websites and compromising payment card processing devices. Once in their possession, the actors use these compromised payment card credentials to generate further card information. The main methods used by the observed group to launder and monetize illicit funds include online purchases of various goods and services as well as ATM withdrawals.

Based on extensive observation of this group's activity, we are able to characterize their operations lifecycle starting with the initial operational setup; followed by the methods used to compromise credentials or, conversely, purchase already compromised credentials; then the process of generating new cards for subsequent abuse, which includes validation and cloning; and finally the subsequent monetization strategies. Figure 1 depicts this operation workflow.

Figure 1: Brazilian carding operation workflow

Phase 1: Setting Up the Workplace

We observed this group taking several preparatory measures to maintain anonymity.

The members of the group use a variety of tools, including CCleaner, on a daily basis to effectively remove any evidence of their operations. This includes browsing history, temporary files, Clipboard, typed URLs, cookies, recently opened documents, and conversations via Skype, Windows Messenger, etc. This almost certainly limits the potential amount of evidence that law enforcement could obtain and use against the suspects in the case of an arrest or property search.

Another common step taken by threat actors is changing their system's MAC Address to avoid being uniquely identified. For this purpose, these actors often use tools such as Technitium MAC Address Changer.

We have observed these actors using Tor or proxy-based tools similar to Tor (e.g., UltraSurf, as seen in Figure 2). We have also observed them using virtual private network services that use IPs based in numerous countries to ensure anonymity and obfuscate criminal operations.

Figure 2: Ultra Surf 12.10

Additionally, many actors conduct transactions using virtual currencies, most prominently Bitcoin, to anonymize criminal transactions. Due to the comparative anonymity and lack of government oversight often associated with the use of virtual currencies, virtual currency is of significant value for actors involved in illicit operations when they are performing transactions among themselves.

Phase 2: Data Acquisition

Based on our observations, this group uses a variety of different methods to either compromise or acquire already compromised payment card credentials.

Payment card "dumps" are commonly shared amongst Brazilian threat actors via social media forums such as Facebook, Skype, and web-based WhatsApp messenger. These social media circles are highly prevalent amongst these regional actors and are often the preferred method of communication. This group takes advantage of those communities to obtain stolen data from peers. Similarly, the group takes advantage of freely available consolidations of email credentials, personal information, and other data shared in eCrime forums for fraud purposes.

The group systematically purchases payment card data via different online shops. These shops include "Toy Store," "Joker's Stash," and "Cvv2finder." The venues, called "dump shops," allow customers to use a web-based platform to sort through thousands or millions of individual pieces of card data and purchase as much or as little as they want. The shops provide customers with filters to select the individual pieces of card data they wish to purchase and add to their carts for checkout, similar to legitimate sites. The same types of shops also allow malicious actors to steal credentials stolen from other services such as email providers, online bill payment websites, entertainment services, or travel booking websites.

These actors scan websites for vulnerabilities to exploit to illicitly access databases. They most commonly target Brazilian merchants, though others use the same tactics to exploit entities outside Brazil. One simple method the group uses is Google Dorks, advanced Google searches used to identify security loopholes on Google-indexed websites. An example is shown in Figure 3.

Figure 3: Example of Portuguese-language Google Dork used in exploitation

The group also uses the SQL injection (SQLi) tools "Havij Advanced SQL Injection Tool" and "SQLi Dumper version 7.0" (Figure 4) to scan for and exploit vulnerabilities in targeted eCommerce sites. Of note, these tools can dump whole databases from targeted victims.

Figure 4: SQLi Dumper v7.0

This group has also shown interest in modifying point-of-sale (POS) terminals to harvest magnetic stripe and EMV chip data.

"Toy Store"

FireEye Labs identified "Toy Store" as one of the card shops frequently used by the group. It appears that this card shop has operated since November 2015. Despite the fact that the website has been taken down multiple times (most recently in July 2016), it keeps operating, sometimes with newly registered domains.

The store offers a large amount of dumps from multiple sellers. The sold credentials are associated with payment cards of various types, issued by variety of financial institutions from multiple countries. At least eight sellers update the website as frequently as daily, offering newly obtained databases from the U.S.

Examination of dumps uploaded between May 2016 and July 2016 revealed that one vendor uploaded 1,900 credit cards issued by Brazilian banks. Further examination shows sellers uploading dumps regularly from the same locations. In Table 1, seller "X" uploaded the listed data during the first two weeks of August 2016.

Table 1: Data advertised by one "Toy Store" vendor

This seller uploads dumps exclusively from either Texas or Florida. Some base names they provide even contain the word "POS," with a validity rate of 90 percent. This suggests that ATM skimming devices or malware are probably installed in these locations.

The shop allows users to make bulk purchases for any U.S. state, ranging from packages of 30 to 500 units with prices ranging from $250 to $1,000 per bulk.

Registration is free and the only payment method accepted is Bitcoin. A unique Bitcoin payment address is generated per user.

Finally, the website has checker functionality – charging $0.50 per check – that allows users to quickly check for credit card validity and ask for a refund if a purchased card is not valid (Figure 5).

Figure 5: Toy Store shop site

Phase 3: Generating Further Card Numbers

Once in possession of compromised payment card credentials, these actors use tools commonly known as "card generators" to generate new card numbers based on the compromised ones, creating additional opportunities for monetization. These tools require as input a valid 16-digit credit card number, expiration date, and a file name to store the new cards generated. Examples of such tools commonly used by Brazilian carders include "WZP" (Figure 6) and "Gerador CC" (Figure 7).

Figure 6: "WZP" card generator

Figure 7: "Gerador CC" card generator

"Gerador CC" generates credit card numbers based on the Bank Identifier Number (BIN), with a fixed expiration date and CVV equal to 000. Typically, 1,000 cards will be generated per round. Then threat actors use public websites set up to check if the credit card number is valid. However, the fact that the card number generated is valid does not necessarily mean the card can be used for real purchases at any website. This method of generating card data cannot determine what validation information (e.g., expiration date) or personal information should be associated with the card numbers. So, to make purchases with the data, actors have to find websites with vulnerable authentication systems.

Phase 4: Validating New Card Numbers

After stealing, buying, or generating card data, the group validates it through multiple tools and services available in underground communities.

Vulnerable merchant websites – websites that accept payments with generated or compromised payment cards – are identified and used regularly by carders. For example, in March 2016, we observed an advertisement in an underground community for a list that contained the addresses of 10,000 vulnerable merchant websites. Criminals take advantage of these sites to not only make purchases, but also to bulk-check card data for usability.

One bulk card-checking tool this group uses is "Testador Amazon.com v1.1" (Figure 8). Despite its name, this tool does not use Amazon’s website, but exploits an unauthenticated Cross-Site Request Forgery (CSRF) vulnerability of a merchant website allowing the abuse of PayPal Payflow link functionality (Figure 9).

Figure 8: Testador Amazon v1.1 GUI

Figure 9: PayPal Payflow Link page

A Payflow Link is a PayPal-hosted payment solution that allows merchant websites to securely connect their customers to PayPal's secure server and use it to automate order acceptance, authorization, processing, and transaction management, making it useful for carders to check the validity of credit card numbers. Payflow links cannot be accessed directly, but only from trusted and authenticated merchants. "Testador Amazon" abuses legitimate merchant sites to submit unauthenticated valid orders, providing access to a legacy PayPal Payflow Link. At this point, actors can test the generated credit card numbers by filling the input field of the form automatically via the tool. This tool then continues submitting thousands of valid orders, simultaneously checking for the validity of the next credit card number in the list.

The actors use a dedicated IRC channel provided by the eCrime community service "ChkNet" (Figure 10) to validate credit cards. Based on our observations of interactions in this channel, between May 2016 and June 2016, malicious actors validated 2,987 cards from 62 countries, with the most coming from the U.S. (nearly half), Brazil, and France. The actors in the channel share instructions on validation and advice on maintaining anonymity during these operations. The channel is accessible without registration; however, actors interested in using the IRC bot to verify the validity of credit cards are charged 0.003 BTC ($1.88 USD).

Figure 10: ChkNet IRC service activation

Another validation method involves using online charity donations. ChkNet also provides an API and a software tool named “Checker” that leverages charity websites for this purpose. This type of exploitation of charities is popular in the Brazilian eCrime community. Figure 11 shows a credit card tested by Checker. The Status “Live” means the card was successfully used during an online payment transaction.

Figure 11: Checker credit card validation result

Phase 5: Laundering and Monetization

We observed this group using multiple tactics to monetize the card data it steals and generates.

The actors frequently use the stolen data to create cloned physical cards, which they use to attempt to withdraw funds from ATMs. The group has performed these activities at multiple locations across Brazil, possibly using multiple mules. The group primarily uses the MSR 606 Software (Figure 12) and Hardware (Figure 13) to create cloned cards.

Figure 12: MSR606 software

Figure 13: MSR606 Magnetic Stripe card reader/writer

Additionally, we observed the group exploiting popular eCommerce sites to perform fraudulent transactions. This monetization tactic requires the group to constantly refine its tactics to deal with measures put in place to validate that card and cardholder data is legitimate and other anti-fraud checks. Carders in the community with whom this group interacts regularly share recommendations based on this experience, such as using virtual private networks, limiting the number of items purchased at a time, and cleaning machines used to make purchases of any profiling information such as cookies.

Whether this group uses any further means to launder the proceeds from these activities is unclear. However, Brazilian actors commonly use several methods to do so, such as reselling cards they have created, paying bills with stolen cards in return for a portion of the bill's value and reselling illicitly obtained goods.

Outlook

Payment card fraud has been extremely profitable for malicious actors for years. Given its profitability and actors' investment in this type of fraud, we see no indication of actors moving away from this type of activity for the foreseeable future. As security measures continue to evolve to counter this area of fraud, we will likely see actors attempting to devise new schemes to maintain the profits they are obtaining and continue capitalizing on their investments in this area.

This material was originally posted to the FireEye iSIGHT Intelligence MySIGHT Portal on Oct. 7, 2016. The FireEye iSIGHT Intelligence MySIGHT Portal contains additional information based on our investigations of a variety of topics discussed in this post, including Joker’s Stash, ChkNet, virtual currencies, and point-of-sale systems. Click  here  for more information.

In June 2016, we published a blog about a phishing campaign targeting the Apple IDs and passwords of Chinese Apple users that emerged in the first quarter of 2016 (referred to as the “Zycode” phishing campaign). At FireEye Labs we have an automated system designed to proactively detect newly registered malicious domains and this system had observed some phishing domains that were designed to appear as legitimate Apple domains. Most of the domains reported by this system were suspended in June 2016, which resulted in a loss of momentum for the Zycode phishing campaign. Throughout the second quarter of 2016, the Zycode phishing campaign was in hibernation.

We recently observed a resurgence of the same phishing campaign when our systems detected roughly 90 phony Apple-like domains that were registered from July 2016 to September 2016. Once again, Chinese Apple users are being targeted for their Apple IDs and passwords using the same content reported on in our earlier blog. The majority of these domains are registered in the .com TLD by email accounts from qq[.]com, and the IPs of these domains point to mainland China, as seen in Figure 1.

Figure 1: Google map showing the location of the hosted phishing domains

What has not Changed?

The attackers have not changed the content of the phishing sites. The obfuscated JavaScript used in the earlier version is once again being used here in this campaign. We have provided the details of JavaScript and screenshots of interaction with the website in our earlier blog.

What has Changed?

Apparently the domains and email addresses used in previous version of the campaign were effectively taken down. Now the attackers have moved to a new malicious infrastructure; new domains, IPs and email addresses are being used for this campaign. The new domain names for the campaign are listed in Table 1, while their IPs and registrant emails are reported in Table 2 and Table 3, respectively.

Domains List

Table 1: Apple phishing domains serving the Zycode phishing kit.

Unique IP(s)

Table 2 shows the list of unique IPs, which are not the same as what was seen before.

Table 2. IP addresses used by the domains.

Unique Email Addresses

The email addresses used to register these domains, showing no similarity with email addresses in the previous campaign, are shown in Table 3.

Table 3. List of unique registrant emails.

Unique Registrants

Table 4 shows the registrant names, which have no similarity with the previous registrant name information.

Table 4. List of registrant names used by the phishing domains.

How to Avoid Being a Victim

Apple provides information on phishing here and here, and on iCloud security here. There are simple ways for a user to be more secure against this and similar attacks. The following are a few tips:

• Enable two-factor authentication for Apple ID.
• Always check the address bar for the correct web address.
• Avoid clicking links in emails and SMS messages that supposedly direct to iCloud pages.
• Use our FireEye EX appliance, which provides effective detection for the Zycode phishing campaign.

I would like to thank the challenge authors this year:

1. Alexander Rich
2. Matt Williams (@0xmwilliams)
3. Dominik Weber
4. James T. Bennett (@jtbennettjr)
5. Tyler Dean
6. Josh Homan
7. Alex Berry
8. Nick Harbour (@nickharbour)
9. Jon Erickson (@2130706433)
10. FireEye Labs Advanced Vulnerability Analysis Team (FLAVA)

The most noticeable change this year in the Flare-On format was a welcomed move away from the email backend system to an interactive framework based on CTFd. As a result of this change, we have much improved metrics on active players and solutions, and for the first time in Flare-On challenge history: 100 percent uptime. Let’s look at how the challenge went.

By all accounts this was the hardest Flare-On challenge yet, with Challenge 10 holding the dubious title of hardest challenge in Flare-On history and hopefully keeping that title for all time. This year’s first challenge was also significantly more difficult than last year’s first challenge, which was a simple single-byte XOR loop. As a result of this increase in difficulty, the number of people who solved the first challenge dropped by more than 40 percent from last year.

The international appeal of the Flare-On challenge was as strong as ever this year, with less than 14 percent of finishers coming from the United States. Outside of the U.S., Vietnam saw the most finishers with 13, a Flare-On international record, and Singapore more than doubled its finishers from last year, putting them at a solid 9 finishers. A total of 38 countries were represented in the finishers this year, up from 33 last year. Congratulations all around!

All the binaries from this year’s challenge are now posted on flare-on.com. And here are the solutions written by each challenge author:

1. SOLUTION 1
2. SOLUTION 2
3. SOLUTION 3
4. SOLUTION 4
5. SOLUTION 5
6. SOLUTION 6
7. SOLUTION 7
8. SOLUTION 8
9. SOLUTION 9
10. SOLUTION 10

Gaining insight into the files being executed on your system is a great first step towards improved visibility on your endpoints. Taking this a step further, centrally storing logs of file execution data so they can be used for detection and hunting provides an excellent opportunity to find evil on your network.

A SIEM, and to some degree your entire security monitoring program, is only as good as the data you are collecting. Process execution data is incredibly valuable for enabling a multitude of detection and hunting scenarios, which means it’s something you should consider collecting and storing. Customers of our Threat Analytics Platform (TAP) cloud-based SIEM solution frequently ask us about tools that can help them collect this type of file execution data. For Windows systems, our detection team typically recommends the Sysinternals Sysmon tool since it provides excellent visibility into the type of files that are being executed on your Windows machines and both integrates and scales well when properly deployed.

In this post, I’m going to talk about a lesser-known feature of the Linux architecture called the Integrity Measurement Architecture (IMA). When coupled with auditd, IMA will allow you to achieve on Linux hosts a similar executable logging capability as the Sysmon tool for Windows.

The Integrity Measurement Architecture is a component of the Linux kernel’s integrity subsystem. For this post, we’re going to focus on a minimum baseline configuration and policy in order to get file execution logs into a format that can be ingested by your SIEM. File execution logs are available in various forms and locations in Linux, but the logs we will be generating contain a wealth of data in one location that would otherwise need to be gathered from several disparate sources or may have not have been available at all.

First, you should familiarize yourself with documentation for your Linux distribution to verify whether the IMA kernel compilation options are enabled by default. The IMA subsystem has been part of the mainline kernel since version 2.6.30, but not every distribution compiles their kernel with these options enabled. All of the examples in this post were tested on Ubuntu 16.04.1 LTS, as the IMA kernel options are enabled by default in this distribution.

Instructions for compiling a kernel with these options enabled are listed in this Integrity Measurement Architecture documentation. Documentation for auditd can be found here. The reason we need the auditd daemon is because it is the userspace component for Linux’s auditing platform and it is responsible for writing all the resulting audit records to disk. Without auditd, the logs for the events we will be generating would never get written out to disk.

The stated goals of the IMA subsystem are “to detect if files have been accidentally or maliciously altered, both remotely and locally, appraise a file’s measurement against a ‘good’ value stored as an extended attribute, and enforce local file integrity.” To achieve these goals, IMA provides several functions, including:

• Collect – “measure” a file before it is accessed. The term measurement in this context means to grab a hash of the file data, the hash of some file metadata and the file path, and then store this data in a runtime measurement list.
• Store – add the measurement to a kernel resident list and, if a hardware Trusted Platform Module (TPM) is present, extend the IMA Platform Configuration Register (PCR). TPM and PCR are part of an international standard for dedicated microcontrollers intended to secure hardware.
• Attest – if present, use the TPM to sign the IMA PCR value to allow a remote validation of the measurement list.
• Appraise – enforce local validation of a measurement against a “good” value stored in an extended attribute of the file.
• Protect – protect a file’s security extended attributes (including appraisal hash) against off-line attack.

Collect & Store

Part of the way the appraisal function validates a file is to calculate a hash value, which just determines how mathematically unique the file is, and compare this value against a stored “good” hash value. The specific hash function that IMA uses is a configurable option.

Attest

This is effective for locally ensuring integrity of an environment, but what if we also wanted to compare these measured hash values against a list of known bad file hashes through an external or internal blacklist? It could also be the case that runtime integrity checking on every machine isn’t suitable for your environment. Generating and storing these logs opens up the possibility for future investigation as well as centralized detection capabilities if your organization is ingesting these logs into a single repository.

Appraise

We can utilize the auditing function of IMA to generate a log every time IMA measures an executable. When an IMA policy is set to audit any executable and auditd is running, a log will be written containing metadata for each executable.

The simplest IMA policy we can write to log all executables looks like this:

audit func=BPRM_CHECK mask=MAY_EXEC

There are several ways to apply this policy to IMA that are detailed in the IMA documentation. Later versions of systemd will apply a custom policy located in “/etc/ima/ima-policy”. Placing the single line policy set forth above in this file will cause systemd to apply this IMA policy to the system. This version of systemd was included in Ubuntu 16.04.1.

It should be noted that the example policy is extremely broad and will result in a high volume of logs being generated, primarily by daemons – equivalent to a Windows service - performing routine tasks, such as systemd. The policy can be further restricted by file magic values, UID, filesystem mask values and several others, as specified by the policy documentation.

This policy will produce audit INTEGRITY_RULE logs that look like this:

This gives us several great pieces of information for searching and correlation in a SIEM: the path of the file that was executed (kaiten.bin) and the path of its parent (/bin/bash), the PID(8205) and parent PID(1943) of the executable, the SHA-1 hash value(48a3171d8f04c09f6d06362d4c4b995eaa97d489) of this file (or whatever hash value you configured IMA to use), and the UID, GID, etc., of the user that owned the process. A quick check in VirusTotal of the hash supplied to us by IMA in this example shows that this is a variant of the Kaiten IoT bot.

Once you are generating logs with IMA and auditd, you can send them to your SIEM using your normal log ingestion process via something like syslog.

Now that you’re ingesting these logs into your SIEM, there are all sorts of detection and hunting scenarios available:

• Using rules and ingestion decoration services (services that add additional metadata to a log at ingestion time) to check hashes against internal and or external blacklists. For example:

            o   VirusTotal
            o   Lists of hashes seen in public Linux honeypots
            o   Lists of samples seen in previous incidents

• Inspecting the path of the executable for abnormalities. For example:

            o   Binaries named as system utilities executing from unusual locations (/opt/app/sudo, /home/foo/su)
            o   Paths you wouldn’t expect to see with executable files (Executables in your web app’s image upload directory
            o   Binaries executing from hidden directories (/opt/.hidden/foo, /home/user/.hidden/bar)

• Checking specific UIDs and GIDs for unusual execution. For example:

            o   Web app user account attempting to use unusual utilities (top, netstat, su, etc.)
            o   An account under an archive service group attempting to execute something out of /tmp

• Checking specific parent executables and processes for unusual execution. For example:

            o   Communication broker executing directory traversal commands
            o   Apache process executing netcat

Configuration options for both IMA and auditd are extensive so, if this post is of interest to your organization, I highly recommend reading the documentation for both IMA and auditd so they can be further customized to your needs. This post isn’t meant to be an all-inclusive guide to IMA, but our hope is that it introduces you to this capability so that you can dive in and make it useful for improving your visibility into Linux process execution and aid you in finding more evil in your network.

2016 has been a year of significant change to the cyber security landscape. The rapid proliferation of ransomware and the emergence of Internet of Things mass compromise has changed the landscape for responders. Similarly, existing threats have become more brazen, with nation-state actors publishing the results of their campaigns publicly and financial threat actors leaving no piece of PII behind.

While the average global identification time for compromise by advanced attackers has continued to decrease from 206 days in 2014 to 146 days in 2015, it’s still unacceptably long to protect the data that matters for an organization. As an incident responder at Mandiant for the past four years, I have personally worked on cases in 2016 where attackers were able to break into an organization and complete their mission in record time.

Skilled and trained incident responders with access to the latest information on threats, adversaries and tools are one of the best lines of defense in keeping an environment secure and terminating a threat as it happens. With that in mind, for the FireEye Cyber Defense Summit 2016 Incident Response track, I sought to cultivate a group of practitioners who could share their experiences, research and successes with the greater incident response community.

FireEye Labs recently discovered a malicious phishing domain designed to steal a variety of information – including credentials and mobile numbers – from customers of several banks in India. Currently, we have not observed this domain being used in any campaigns. The phishing websites appear to be in the earlier stages of development and through this post we hope users will be able to identify these types of emerging threats in the future.

FireEye phishing detection technology identified a newly registered domain, “csecurepay[.]com”, that was registered on Oct. 23, 2016. The website purports to offer online payment gateway services, but is actually a phishing website that leads to the capturing of victim logon credentials – and other information – for multiple banks operating in India.

Prior to publication, FireEye notified the Indian Computer Emergency Response Team.

Phishing Template Presentation and Techniques

Step 1

URL: hxxp://csecurepay[.]com/load-cash-step2.aspx

When navigating to the URL, the domain appears to be a payment gateway and requests that the user enter their bank account number and the amount to be transferred, as seen in Figure 1. The victim is allowed to choose their bank from a list that is provided.

Figure 1: Bank information being requested

By looking at the list, it is clear that only Indian banks are being targeted at this time. A total of 26 banks are available and these are named in the Appendix.

Step 2

URL:  hxxp://csecurepay[.]com/PaymentConfirmation.aspx

The next website requests the victim to enter their valid 10-digit mobile number and email ID (Figure 2), which makes the website appear more legitimate.

Figure 2: Personal information being requested

Step 3

The victim will then be redirected to the spoofed online banking page of the bank they selected, which requests that they log in using their user name and password. Figure 3 shows a fake login page for State Bank of India. See the Appendix for more banks that have spoofed login pages.

Figure 3: Fake login page for State Bank of India

After entering their login credentials, the victim will be asked to key in their One Time Password (OTP), as seen in Figure 4.

Figure 4: OTP being requested

Step 4

URL: hxxp://csecurepay[.]com/Final.aspx

Once all of the sensitive data is gathered, a fake failed login message will be displayed to the victim, as seen in Figure 5.

Figure 5: Fake error message being displayed

Credit and Debit Card Phishing Website

Using the registrant information from the csecurepay domain, we found another domain registered by the phisher as “nsecurepay[.]com”. The domain, registered in latest August 2016, aims to steal credit and debit card information.

The following are among the list of cards that are targeted:

1.     ICICI Credit Card

2.     ICICI Debit Card

3.     Visa/Master Credit Card

4.     Visa/Master Debit Card

5.     SBI Debit Card Only

At the time of this writing, the nsecurepay website was producing errors when redirecting to spoofed credit and debit card pages. Figure 6 shows the front end.

Figure 6: Nsecurepay front end

Conclusion

Phishing has its own development lifecycle. It usually starts off with building the tools and developing the “hooks” for luring victims into providing their financial information. Once the phishing website (or websites) is fully operational, we typically begin to see a wave of phishing emails pointing to it.

In this case, we see that phishing websites have been crafted to spoof multiple banks in India. These attackers can potentially grab sensitive online banking information and other personal data, and even provided support for multifactor authentication and OTP. Moreover, disguising the initial presentation to appear as an online payment gateway service makes the phishing attack seem more legitimate.

FireEye Labs detects this phishing attack and customers will be protected against the usage of these sites in possible future campaigns.

Appendix

Fake login pages were served for 26 banks. The following is a list of some of the banks:

-Bank of Baroda - Corporate

-Bank of Baroda - Retail

-Bank of Maharashtra

-HDFC Bank

Figure 7: HDFC Bank fake login page

-ICICI Bank

-IDBI Bank

-Indian Bank

-IndusInd Bank

-Jammu and Kashmir Bank

-Kotak Bank

-Lakshmi Vilas Bank - Corporate

-Lakshmi Vilas Bank - Retail

-State Bank of Hyderabad

-State Bank of India

-State Bank of Jaipur

-State Bank of Mysore

-State Bank of Patiala

-State Bank of Bikaner

-State Bank of Travancore

-Tamilnad Mercantile Bank

-United Bank of India

In 2012, a suspected Iranian hacker group called the “Cutting Sword of Justice” used malware known as Shamoon – or Disttrack. In mid-November, Mandiant, a FireEye company, responded to the first Shamoon 2.0 incident against an organization located in the Gulf states. Since then, Mandiant has responded to multiple incidents at other organizations in the region.

FireEye HX and FireEye NX both detect Shamoon 2.0, and our Multi-Vector Virtual Execution (MVX) engine is also able to proactively detect this malware.

Shamoon 2.0 is a reworked and updated version of the malware we saw in the 2012 incident. Analysis shows the malware contains embedded credentials, which suggests the attackers may have previously conducted targeted intrusions to harvest the necessary credentials before launching a subsequent attack.

The following is a summary of what we know about Shamoon 2.0 based on the samples we’ve analyzed:

• The malware scans the C-class subnet of the IP it has assigned to every interface on the system for target systems.
• The malware then tries to access the ADMIN$, C$\Windows, D$\Windows, and E$\Windows shares on the target systems with current privileges.
• If current privileges aren’t enough to access the aforementioned shares, it uses hard coded, domain specific credentials (privileged credentials, likely Domain Administrator or local Administrator) gained during an earlier phase of the attack to attempt the same.
• Once it has access, it enables the Remote Registry service on the target device and sets HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy to 0 to enable share access.
• Once it has performed the earlier actions, it copies ntssrvr32.exe to the %WINDIR%\system32 of the target system and schedules an unnamed task (e.g. At1.job) to execute the malware.
• The identified malware had a hard coded date to launch the wiping. Systems infected with the malware scheduled the job to start the process shortly thereafter.
• The malware sets the system clock to a random date in August 2012. Analysis suggests this might be for the purposes of ensuring the component (a legitimate driver used maliciously) that wipes the Master Boot Record (MBR) and Volume Boot Record (VBR) is within its test license validity period.
• While the original Shamoon malware attempted to overwrite operating system files with an image of a burning U.S. flag, the recently discovered variant attempts to overwrite Windows operating system files, although with a different image, a .JPG file depicting the death of Alan Kurdi, a Syrian child migrant who died while attempting to cross the Mediterranean Sea.

The following is guidance for detecting the malware, counteracting its activity, and attempting to prevent it from propagating in an environment. Please note that performing any of these actions could have a negative effect and should not be implemented without proper review and study of the impact of the environment.

• Monitor any events in the SIEM that show dates in August 2012.
• Monitor for system time change events that set the clock back to and from August 2012.
• Monitor for Remote Registry service starts.
• Monitor for changes to the aforementioned registry key value, if the value is currently non-zero.
• Prevent and limit access to the aforementioned shares, which could have significant impact based on setup.
• Prevent client-to-client communication to slow down the spread of the malware, which could also have a significant impact based on setup.
• Monitor filesystems for the creation of any of the filenames provided in the Indicators of Compromise list at the bottom of the post.
• Change the credentials of all privileged accounts and ensure local Administrator passwords are unique per system.

Indicators of Compromise

The following is a set of the Indicators of Compromise for the identified Shamoon variant. We recommend that critical infrastructure organizations and government agencies (especially those in the Gulf Cooperation Council region) check immediately for the presence or execution of these files within their Windows Server and Workstation environments. Additionally, we recommend that all customers continue to regularly review and test disaster recovery plans for critical systems within their environment.

File name: ntssrvr64.exe
Path: %SYSTEMROOT%\System32
Compile Time: 2009/02/15 12:32:19
File size:717,312

File name: ntssrvr32.exe
Path: %SYSTEMROOT%\System32 NA NA
File size: 1,349,632

File name: ntssrvr32.bat
Path: %SYSTEMROOT%\System32 NA
MD5: 10de241bb7028788a8f278e27a4e335f
File size: 160

File name: gpget.exe
Path: %SYSTEMROOT%\System32
PE compile time: 2009/02/15 12:30:41
MD5: c843046e54b755ec63ccb09d0a689674
File Size: 327,680

File name: drdisk.sys
Path: %SYSTEMROOT%\System32
Compile time: 2011/12/28 16:51:29
MD5: 76c643ab29d497317085e5db8c799960
File Size: 31,632

File name: key8854321.pub
Path: %SYSTEMROOT%\System32
MD5: b5d2a4d8ba015f3e89ade820c5840639 782

File name: netinit.exe
Path: %SYSTEMROOT%\System32
MD5: ac4d91e919a3ef210a59acab0dbb9ab5
File Size: 183,808
Service Details
Display name: "Microsoft Network Realtime Inspection Service"
Service name: "NtsSrv"

Description: "Helps guard against time change attempts targeting known and newly discovered vulnerabilities in network time protocols"
Files created:

• %WINDIR%\inf\usbvideo324.pnf
• %WINDIR%\system32\netinit.exe

Dynamic Analysis Observables

RegistryItem HKLM\SYSTEM\CurrentControlSet\Services\NtsSrv\

RegistryItem HKLM\SYSTEM\ControlSet001\Services\NtsSrv\

RegistryItem HKLM\SYSTEM\CurrentControlSet\Services\wow32\

RegistryItem HKLM\SYSTEM\ControlSet001\Services\wow32\

RegistryItem HKLM\SYSTEM\CurrentControlSet\Services\drdisk\

RegistryItem HKLM\SYSTEM\ControlSet001\Services\drdisk\

FileItem C:\Windows\System32\caclsrv.exe

FileItem C:\Windows\System32\certutl.exe

FileItem C:\Windows\System32\clean.exe

FileItem C:\Windows\System32\ctrl.exe

FileItem C:\Windows\System32\dfrag.exe

FileItem C:\Windows\System32\dnslookup.exe

FileItem C:\Windows\System32\dvdquery.exe

FileItem C:\Windows\System32\event.exe

FileItem C:\Windows\System32\extract.exe

FileItem C:\Windows\System32\findfile.exe

FileItem C:\Windows\System32\fsutl.exe

FileItem C:\Windows\System32\gpget.exe

FileItem C:\Windows\System32\iissrv.exe

FileItem C:\Windows\System32\ipsecure.exe

FileItem C:\Windows\System32\msinit.exe

FileItem C:\Windows\System32\netx.exe

FileItem C:\Windows\System32\ntdsutl.exe

FileItem C:\Windows\System32\ntfrsutil.exe

FileItem C:\Windows\System32\ntnw.exe

FileItem C:\Windows\System32\power.exe

FileItem C:\Windows\System32\rdsadmin.exe

FileItem C:\Windows\System32\regsys.exe

FileItem C:\Windows\System32\routeman.exe

FileItem C:\Windows\System32\rrasrv.exe

FileItem C:\Windows\System32\sacses.exe

FileItem C:\Windows\System32\sfmsc.exe

FileItem C:\Windows\System32\sigver.exe

FileItem C:\Windows\System32\smbinit.exe

FileItem C:\Windows\System32\wcscript.exe

SCCM Software Metering

Reviewing forensic keyword searches can be confusing because it is often difficult for an analyst to determine the source of the various structures that contain string matches. One such structure belongs to Microsoft's System Center Configuration Manager's (SCCM) software metering history, which can record the path, name, size, associated user name, last used time, launch count, and PE metadata of executed files.

Microsoft designed SCCM software metering to report application usage for statistical analysis. Microsoft TechNet provides a more complete overview of this feature. While software metering data is meant to be reviewed by system administrators on the SCCM server, client systems retain execution history of recently used applications. For forensic investigators, this execution history can be a goldmine for identifying both the presence of deleted files and confirming that a file executed on a system.

Since SCCM generates this data, it will only be recorded if the system is connected to a domain with an SCCM server and if software metering is enabled. For these reasons, this artifact will likely only exist on enterprise systems. Personal computers for home users or criminals likely will not contain this artifact.

If enabled, Windows stores software metering execution logs as CCM_RecentlyUsedApps records in the Windows Management Instrumentation repository. The FireEye Labs Advanced Reverse Engineering (FLARE) team released scripts that parse this repository last year. Using FLARE's python-cim application, analysts can enumerate all allocated CCM_RecentlyUsedApps instances from the root\ccm\SoftwareMeteringAgent namespace of a WMI repository.

Allocated Records

To extract allocated CCM_RecentlyUsedApps records from a WMI repository, python-cim requires the CIM repository files OBJECTS.DATA, MAPPING*.MAP, and INDEX.BTR from the C:\Windows\System32\wbem\Repository directory on a host.  Figure 1 provides a command to extract allocated CCM_RecentlyUsedApps records from CIM repository file located in WMI_Repo/ with python-cim.

Figure 1: Extracting allocated CCM_REcentlyUsedApps records with python-cim

This may take a while to execute depending on the WMI repository's size. The output file will be tab delimited, which should parse easily into your favorite spreadsheet application. This data allows for keyword searching of files, paths and user accounts, as well as timeline analysis. However, the most useful analysis method for this data may be anomaly detection.

Figure 2 provides a transposed excerpt of python-cim’s show_CCM_RecentlyUsedApps.py output. Note how legitimate files contain PE metadata fields such as description, company name and product name while the attacker did not configure that information in the malicious file C:\Windows\Temp\evl.exe. Since legitimate files usually contain this metadata, identifying null values is a great place to begin analysis. Also note that some fields may not be recorded.

Figure 2: Extracted CCM_RecentlyUsedApps records from python-cim

Unallocated Records

Even though python-cim can extract CCM_RecentlyUsedApps records, old records may have been moved to inactive pages or even partially overwritten. Due to an easily identifiable header and well defined object structure, we can carve all allocated and unallocated CCM_RecentlyUsedApps records from the OBJECTS.DATA file with CCM_RUA_Finder.py.

Record Structure

To understand how to carve CCM_RecentlyUsedApps records we must understand the structure of the WMI CCM_RecentlyUsedApps class, as each record is an instance of this class. All WMI class definitions share a similar structure that at a high-level consists of a header section, a property section and a data section. The header section contains a unique GUID that allows us to quickly identify class instances in the raw data, and the property and data sections contain the values we are interested in carving. Most importantly, the order of the values in the property and data sections is static, meaning we can reliably carve fields using a combination of offsets and regular expressions.

Figure 3 provides a sample hexdump of a CCM_RecentlyUsedApps class instance from an OBJECTS.DATA file.

Figure 3: Hexdump of a complete CCM_RecentlyUsedApps record from an OBJECTS.DATA file

Figure 4 provides the parsed contents of this CCM_RecentlyUsedApps class instance and highlights values of interest.

Figure 4: Parsed contents of a CCM_RecentlyUsedApps record with highlighted values of interest

A complete analysis of WMI class and class instance structures is covered in the FLARE team’s “Windows Management Instrumentation (WMI) Offense, Defense, and Forensics” white paper.

Carving Records

CCM_RUA_Finder.py can extract complete and even some partially overwritten CCM_RecentlyUsedApps records from any OBJECTS.DAT file that contains such CCM_RecentlyUsedApps class instances. The tab delimited output will open nicely in your spreadsheet editor and provide the same analysis capabilities stated earlier. Figure 5 provides a command to extract allocated, unallocated and partially overwritten CCM_RecentlyUsedApps records from an OBJECTS.DATA file with CCM_RUA_Finder.py.

Figure 5: Extracting allocated, unallocated, and partially overwritten CCM_RecentlyUsedApps records with CCM_RUA_Finder.py

This command should complete quickly and will carve records to produce output as seen in Figure 6.

Figure 6: Extracted full and carved CCM_RecentlyUsedApps records from CCM_RUA_Finder.py

Just One Piece of the Puzzle

CCM_RecentlyUsedApps records are a great artifact to identify both executed files and deleted attacker files when available. As with all forensic artifacts, parsing these software metering agent log records should be just one part of a complete and well-balanced investigation strategy.

Introduction

This post continues the FireEye Labs Advanced Reverse Engineering (FLARE) script series. Here, we introduce flare-qdb, a command-line utility and Python module based on vivisect for querying and altering dynamic binary state conveniently, iteratively, and at scale. flare-qdb works on Windows and Linux, and can be obtained from the flare-qdb github project.

Motivation

Efficiently understanding complex or obfuscated malware frequently entails debugging. Often, the linear process of following the program counter raises questions about parallel or previous register states, state changes within a loop, or if an instruction will ever be executed at all. For example, a register’s value may not become interesting until the analyst learns it was an important input to a function that has already been executed. Restarting a debug session and cataloging the results can take the analyst out of the original thought process from which the question arose.

A malware analyst must constantly judge whether such inquiries will lend indispensable observations or extraneous distractions. The wrong decision wastes precious time. It would be useful to query malware state like a database, similar to the following:

SELECT eax, poi(ebp-0x14) FROM malware.exe WHERE eip = 0x401072

FLARE has devised a command-line tool to efficiently query dynamic state and more in a similar fashion. The following is a description of this tool with examples of how it has been used within FLARE to analyze malware, simulate new scenarios, and even solve challenges from the 2016 FLARE-On challenge.

Usage

Drawing heavily from vivisect, flare-qdb is an open source tool for efficiently posing sophisticated questions and obtaining simple answers from binaries. flare-qdb’s command-line syntax is as follows:

flareqdb "<cmdline>" -at <address> "<python>"

flare-qdb allows an analyst to execute a command line of their choosing, break on arbitrary program counter values, optionally check conditions, and display or alter program state with ad-hoc Python code. flare-qdb implements several WinDbg-like builtins for querying and modifying state. Table 1 lists a few illustrative example queries.

Table 1: Example flare-qdb queries

Using the flareqdb Command Line

The usefulness of flare-qdb can be seen in cases such as loops dealing with strings. Figure 1 shows the flareqdb command line utility being used to dump the Unicode string pointed to by a stack variable for each iteration of a loop. The output reveals that the variable is used as a runner pointer iterating through argv[1].

Figure 1: Using flareqdb to monitor a string within a loop

Another example is challenge 4 from the 2016 FLARE-On Challenge (spoiler alert: partial solution presented below, full walkthrough is here).

In flareon2016challenge.dll, a decoded PE file contains a series of calls to kernel32!Beep that must be tracked in order to construct the correct sequence of calls to ordinal #50 in the challenge binary. Figure 2 shows a flareqdb one-liner that forwards each kernel32!Beep call to ordinal #50 in the challenge binary to obtain the flag.

Figure 2: Using flareqdb to solve challenge 4 of the 2016 FLARE-On Challenge

flareqdb can also force branches to be taken, evaluate function pointer values, and validate suspected function addresses by disassembling. For example, consider the subroutine in Figure 3, which is only invoked if a set of conditions is satisfied and which calls a C++ virtual function. Identifying this function could help the analyst identify its caller and discover what kind of data to provide through the command and control (C2) channel to exercise it.

Figure 3: Unidentified function with virtual function call

Using the flareqdb command-line utility, it is possible to divert the program counter to bypass checks on the C2 data that was provided and subsequently dump the address of the function pointer that is called by the malware at program counter 0x4029a4. Thanks to vivisect, flare-qdb can even disassemble the instructions at the resulting address to validate that it is indeed a function. Figure 4 shows the flareqdb command-line utility being used to force control flow at 0x4016b5 to proceed to 0x4016bb (not shown) and later to dump the function pointer called at 0x4029a4.

Figure 4: Forcing a branch and resolving a C++ virtual function call

The function pointer resolves to 0x402f32, which IDA has already labeled as basic_streambuf::xsputn as shown in Figure 5. This function inserts a series of characters into a file stream, which suggests a file write capability that might be exercised by providing a filename and/or file data via the C2 channel.

Figure 5: Resolved virtual function address

Using the flareqdb Python Module

flare-qdb also exists as a Python module that is useful for more complex cases. flare-qdb allows for ready use of the powerful vivisect library. Consider the logic in Figure 6, which is part of a privilege escalation tool. The tool checks GetVersionExW, NetWkstaGetInfo, and IsWow64Process before exploiting CVE-2016-0040 in WMI.

Figure 6: Privilege escalation platform check

It appears as if the tool exploits 32-bit Windows installations with version numbers 5.1+, 6.0, and 6.1. Figure 7 shows a script to quickly validate this by executing the tool 12 times, simulating different versions returned from GetVersionExW and NetWkstaInfo. Each time the script executes the malware, it indicates whether the malware reached the point of attempting the privilege escalation or not. The script passes a dictionary of local variables to the Qdb instance for each execution in order to permit the user callback to print the friendly name of each Windows version it is simulating for the binary. The results of GetVersionExW are modified prior to return using the vstruct definition of the OSVERSIONINFOEXW; NetWkstaGetInfo is fixed manually for brevity and in the absence of a definition corresponding to the WKSTA_INFO_100 structure.

Figure 7: Script to test version check

Figure 8 shows the output, which confirms the analysis of the logic from Figure 6.

Figure 8: Script output

Next, consider an example in which the analyst must devise a repeatable process to unpack a binary and ascertain the locations of unpacked PE-COFF files injected throughout memory. The script in Figure 9 does this by setting a breakpoint relative to the tail call and using vivisect’s envi module to enumerate all the RWX memory locations that are not backed by a named file. It then uses flare-qdb’s park() builtin before calling detach() so that the binary runs in an endless loop, allowing the analyst to attach a debugger and resume manual analysis.

Figure 9: Unpacker script that parks its debuggee after unpacking is complete

Figure 10 shows the script announcing the locations of the self-injected modules before parking the process in an infinite loop and detaching.

Figure 10: Result of unpacker script

Attaching with IDA Pro via WinDbg as in Figure 11 shows that the program counter points to the infinite loop written in memory allocated by flare-qdb. The park() builtin stored the original program counter value in the bytes following the jmp instruction. The analyst can return the program to its original location by referring to those bytes and entering the WinDbg command r eip=1DC129B.

Figure 11: Attaching to the parked process

The parked process makes it convenient to snapshot the malware execution VM and repeatedly connect remotely to exercise and annotate different code areas with IDA Pro as the debugger. Because the same OS process can be reused for multiple debug sessions, the memory map announced by the script remains the same across debugging sessions. This means that the annotations created in IDA Pro remain relevant instead of becoming disconnected from the varying data and code locations that would result from the non-deterministic heap addresses returned by VirtualAlloc if the program were simply executed multiple times.

Conclusion

flare-qdb provides a command-line tool to quickly query dynamic binary state without derailing the thought process of an ongoing debugging session. In addition to querying state, flare-qdb can be used to alter program state and simulate new scenarios. For intricate cases, flare-qdb has a scripting interface permitting almost arbitrary manipulation. This can be useful for string decoding, malware unpacking, and general software analysis. Head over to the flare-qdb github page to get started using it.

Introduction

Through FireEye’s Email Threat Prevention (ETP) solution, FireEye Labs discovered a phishing campaign in the wild targeting the credit card data and other personal information of Netflix users primarily based in the United States.

This campaign is interesting because of the evasion techniques that were used by the attackers:

• The phishing pages were hosted on legitimate, but compromised web servers.
• Client-side HTML code was obfuscated with AES encryption to evade text-based detection.
• Phishing pages were not displayed to users from certain IP addresses if its DNS resolved to companies such as Google or PhishTank.

At the time of posting, the phishing websites we observed were no longer active.

Attack Flow

The attack seems to start with an email notification – sent by the attackers – that asks the user to update their Netflix membership details. The phishing link inside the email body directs recipients to a page that attempts to mimic a Netflix login page, as seen in Figure 1.

Figure 1: Fake login page mimicking the Netflix website

Upon submitting their credentials, victims are then directed to webpages requesting additional membership details (Figure 2) and payment information (Figure 3). These websites also attempt to mimic authentic Netflix webpages and appear legitimate. Once the user has entered their information, they are taken to the legitimate Netflix homepage.

Figure 2: Fake webpage asking users to update their personal details

Figure 3: Netflix phishing webpage used to steal credit card information

Technical Details

The phishing kit uses techniques to evade phishing filters. One technique is the use of AES encryption to encode the content presented at the client’s side, as seen in Figure 4. The purpose of using this technique is code obfuscation, which helps to evade text-based detection. By obfuscating the webpage, attackers try to deceive text-based classifiers and prevent them from inspecting webpage content. This technique employs two files, a PHP and a JavaScript file that have functions to encrypt and decrypt input strings. The PHP file is used to encrypt the webpages at the server side, as seen in Figure 5. At the client side, the encrypted content is decoded using a defined function in the JavaScript file, as seen in Figure 6. Finally, the webpage is rendered using the ‘document.write’ function.

Figure 4: Client-side code obfuscation using AES encryption

Figure 5: PHP code used at server side for encryption

Figure 6: JavaScript code used at client-side for decryption

Another technique is the host-based evasion, as seen in Figure 7. The host name of organizations such as ‘phishtank’ and ‘google’ are blacklisted. The host name of the client is compared against a list of blacklisted host names. If there is a match against the blacklist, a “404 Not Found” error page is presented.

Figure 7: Server side code for blacklisting known hosts. Click image to enlarge.

As with the majority of phishing attacks, this campaign uses PHP mail utility to send the attacker the stolen credentials. The advantage of using this technique is that the attacker can host their phishing kits on a number of websites and still get the stolen credentials and other information from a single email account. This enables attackers to extend their reach.

Figure 8: Stolen information is sent to an email address using mail() function

Tips to Secure your Netflix Account

To learn more about securing your Netflix account, Netflix provides additional information on how to keep your account safe from phishing scams and other fraudulent activity at https://www.netflix.com/security.

On Jan. 6, 2017, the U.S. Director of National Intelligence released its Intelligence Community Assessment: Assessing Russian Activities and Intentions in Recent US Elections. Still, questions persist about Russian involvement. Did the Russian government direct the group responsible for the breaches and related data leaks? If so, is this simply a matter of accepted state espionage, or did it cross a line? Was the breach at the Democratic National Committee part of a concerted effort by the Russian government to interfere with the U.S. presidential election?

The most consequential question remains unasked: How will Russia continue to employ a variety of methods – including hacks and leaks – to undermine the institutions, policies and actors that the Russian government perceives as constricting and condemning its forceful pursuit of its state aims?

FireEye’s visibility into the operations of APT28 – a group we believe the Russian government sponsors – has given us insight into some of the government’s targets, as well as its objectives and the activities designed to further them.

We have tracked and profiled this group through multiple investigations, endpoint and network detections, and continuous monitoring. Our visibility into APT28’s operations, which date to at least 2007, has allowed us to understand the group’s malware, operational changes and motivations. This intelligence has been critical to protecting and informing our clients, exposing this threat and strengthening our confidence in attributing APT28 to the Russian government.

Our latest report, APT28: At the Center of the Storm, is available here.  

You can also register for our webinar on Feb. 21, 2017, at 8 a.m. PT/11 a.m. ET/4 p.m. GMT (UK), which will feature additional insights from Jonathan Wrolstad, Senior Threat Intelligence Analyst with FireEye, and Robert Morgus, Policy Analyst with New America’s Cybersecurity Initiative.

Introduction

FireEye recently observed a sophisticated campaign targeting individuals within the Mongolian government. Targeted individuals that enabled macros in a malicious Microsoft Word document may have been infected with Poison Ivy, a popular remote access tool (RAT) that has been used for nearly a decade for key logging, screen and video capture, file transfers, password theft, system administration, traffic relaying, and more. The threat actors behind this attack demonstrated some interesting techniques, including:

1. Customized evasion based on victim profile – The campaign used a publicly available technique to evade AppLocker application whitelisting applied to the targeted systems.
2. Fileless execution and persistence – In targeted campaigns, threat actors often attempt to avoid writing an executable to the disk to avoid detection and forensic examination. The campaign we observed used four stages of PowerShell scripts without writing the the payloads to individual files.
3. Decoy documents – This campaign used PowerShell to download benign documents from the Internet and launch them in a separate Microsoft Word instance to minimize user suspicion of malicious activity.

Attack Cycle

The threat actors used social engineering to convince users to run an embedded macro in a Microsoft Word document that launched a malicious PowerShell payload.

The threat actors used two publicly available techniques, an AppLocker whitelisting bypass and a script to inject shellcode into the userinit.exe process. The malicious payload was spread across multiple PowerShell scripts, making its execution difficult to trace. Rather than being written to disk as individual script files, the PowerShell payloads were stored in the registry.   

Figure 1 shows the stages of the payload execution from the malicious macro.

Figure 1: Stages of payload execution used in this attack

Social Engineering and Macro-PowerShell Level 1 Usage

Targets of the campaign received Microsoft Word documents via email that claimed to contain instructions for logging into webmail or information regarding a state law proposal.

When a targeted user opens the malicious document, they are presented with the messages shown in Figure 2, asking them to enable macros.

Figure 2: Lure suggesting the user to enable Macros to see content

Bypassing Application Whitelisting Script Protections (AppLocker)

Microsoft application whitelisting solution AppLocker prevents unknown executables from running on a system. In April 2016, a security researcher demonstrated a way to bypass this using regsvr32.exe, a legitimate Microsoft executable permitted to execute in many AppLocker policies. The regsvr32.exe executable can be used to download a Windows Script Component file (SCT file) by passing the URL of the SCT file as an argument. This technique bypasses AppLocker restrictions and permits the execution of code within the SCT file.

We observed implementation of this bypass in the macro code to invoke regsvr32.exe, along with a URL passed to it which was hosting a malicious SCT file, as seen in Figure 3.

Figure 3:  Command after de-obfuscation to bypass AppLocker via regsv32.exe

Figure 4 shows the entire command line parameter used to bypass AppLocker.

Figure 4: Command line parameter used to bypass AppLocker

We found that the malicious SCT file invokes WScript to launch PowerShell in hidden mode with an encoded command, as seen in Figure 5.

Figure 5: Content of SCT file containing code to launch encoded PowerShell

Decoding SCT: Decoy launch and Stage Two PowerShell

After decoding the PowerShell command, we observed another layer of PowerShell instructions, which served two purposes:

1.     There was code to download a decoy document from the Internet and open it in a second winword.exe process using the Start-Process cmdlet. When the victim enables macros, they will see the decoy document shown in Figure 6. This document contains the content described in the spear phishing email.

Figure 6: Decoy downloaded and launched on the victim’s screen

2.     After launching the decoy document in the second winword.exe process, the PowerShell script downloads and runs another PowerShell script named f0921.ps1 as shown in Figure 7.

Figure 7: PowerShell to download and run decoy decoy document and third-stage payload

Third Stage PowerShell Persistence

The third stage PowerShell script configures an encoded PowerShell command persistently as base64 string in the HKCU: \Console\FontSecurity registry key. Figure 8 shows a portion of the PowerShell commands for writing this value to the registry.

Figure 8: Code to set registry with encoded PowerShell script

Figure 9 shows the registry value containing encoded PowerShell code set on the victims’ system.

Figure 9: Registry value containing encoded PowerShell script

Figure 10 shows that using Start-Process, PowerShell decodes this registry and runs the malicious code.

Figure 10: Code to decode and run malicious content from registry

The third stage PowerShell script also configures another registry value  named HKCU\CurrentVersion\Run\SecurityUpdate to launch the encoded PowerShell payload stored in the HKCU: \Console\FontSecurity key. Figure 11 shows the code for these actions. This will execute the PowerShell payload when the user logs in to the system.

Figure 11: PowerShell registry persistence

Fourth Stage PowerShell Inject-LocalShellCode

The HKCU\Console\FontSecurity registry contains the fourth stage PowerShell script, shown decoded in Figure 12. This script borrows from the publicly available Inject-LocalShellCode PowerShell script from PowerSploit to inject shellcode.

Figure 12: Code to inject shellcode

Shellcode Analysis

The shellcode has a custom XOR based decryption loop that uses a single byte key (0xD4), as seen in Figure 13.

Figure 13: Decryption loop and call to decrypted shellcode

After the shellcode is decrypted and run, it injects a Poison Ivy backdoor into the userinit.exe as shown in Figure 14.

Figure 14: Code injection in userinit.exe and attempt to access Poison Ivy related DAT files

In the decrypted shellcode, we also observed content and configuration related to Poison Ivy.  Correlating these bytes to the standard configuration of Poison Ivy, we can observe the following:

• Active setup – StubPath
• Encryption/Decryption key - version2013
• Mutex name - 20160509                 

The Poison Ivy configuration dump is shown in Figure 15.

Figure 15: Poison Ivy configuration dump

Conclusion

Although Poison Ivy has been a proven threat for some time, the delivery mechanism for this backdoor uses recent publicly available techniques that differ from previously observed campaigns. Through the use of PowerShell and publicly available security control bypasses and scripts, most steps in the attack are performed exclusively in memory and leave few forensic artifacts on a compromised host.

FireEye HX Exploit Guard is a behavior-based solution that is not affected by the tricks used here. It detects and blocks this threat at the initial level of the attack cycle when the malicious macro attempts to invoke the first stage PowerShell payload. HX also contains generic detections for the registry persistence, AppLocker bypasses and subsequent stages of PowerShell abuse used in this attack.

The Veil Framework is a collection of tools designed for use during offensive security testing. When the time calls for it, Mandiant’s Red Team will use the Veil-Framework to help achieve their objective.  The most commonly used tool is Veil-Evasion, which can turn an arbitrary script or piece of shellcode into a Windows executable that will evade detections by common antivirus products.

Veil 2.0 was made publicly available on June 17, 2013, and the core framework has remained largely unchanged since that date. There have been some modifications to the framework itself, but these have generally been minor in nature, with the majority of modifications involving the support of new programming languages and new payload modules.\

After spending a few years developing in Python, I revisited the Veil codebase and identified parts of the backend framework that could be developed more efficiently. Six months later, after refactoring the codebase and adding a large number of updates, I am happy to present Veil 3.0. The main menu is shown in Figure 1.

Figure 1: Veil 3 main menu

Python 3

First and foremost, one of the largest overhauls to Veil was updating the version of Python from Python 2 to Python 3. Python 2 is scheduled to reach end-of-life (EOL) in 2020, so it did not make much sense to spend time performing a large update to Veil in a language that will no longer be supported in three years.

Updating Veil from Python 2 to Python 3 was easily the most time-consuming part of creating Veil 3. Running the 2to3 tool was not an option; the conversion process required manual review for essentially all changes to Veil.

One of the major differences when developing Veil in Python 3 vs. Python 2 is how shellcode is handled and modified. To illustrates this issue, Figure 2 shows a Python 2-based stager that includes encrypted shellcode to be decrypted at runtime.

Figure 2: AES decrypting stager from Veil 2 in Python 2

While the code in Figure 2 works in Python 2, it will not work in Python 3. Specifically, in Python 3, the shellcode no longer needs to be string escaped into a bytearray after decryption. The output of Python 3’s decryption is the original clear text data in a bytearray, which is immediately consumable by the rest of the script. Figure 3 shows the Python 3 version of the same decryption stager.

Figure 3: AES decrypting stager from Veil 3 in Python 3

Ordnance

Early versions of Veil relied on the Metasploit Framework's msfvenom tool to generate shellcode for Veil payloads. After the initial release of Veil, however, this caused a problem. The output for msfvenom changed and it completely broke Veil's ability to process msfvenom output. After providing a patch to fix the issue, the Veil team decided that a different solution would be required instead of relying on a tool outside of our control.

Thus, Veil-Ordnance was developed and released in 2015. Veil-Ordnance is a tool that generates shellcode for use in Veil-Evasion stagers. Developing Veil-Ordnance had two main benefits:

1. The Veil development team is in control of the output, preventing any future compatibility issues with Veil-Evasion.
2. Shellcode generation is faster with Veil-Ordnance.

Previously, Veil-Evasion and Veil-Ordnance were two separate tools. With the release of Veil 3.0, that is no longer the case, as shown in Figure 4.

Figure 4: Ordnance included in Veil 3.0

Veil 3.0 users still have the ability to use msfvenom to generate their shellcode, but they now also have the option to use Ordnance. Ordnance will be able to immediately generate shellcode after users provide the IP and Port that the shellcode should connect to or listen on. Ordnance supports the most popular payload types:

1. Reverse TCP
2. Reverse HTTP
3. Reverse HTTPS
4. Reverse TCP DNS
5. Reverse TCP All Ports
6. Bind TCP

This gives Veil users multiple options to choose from – they can stick with msfvenom, or use the new built-in tool, Ordnance.

Additional Languages

While Veil itself is written in Python, the processed payloads and output files can be in other programming languages. In Veil 3.0, two additional languages are now supported:

• AutoIt3
• Lua

Lua payloads are only supported in a script format that must be compiled and run using a lua runtime, but Veil 3.0 running on Linux can compile AutoIt3 scripts into Windows executables. Veil 3.0 also supports the seven languages previously supported in version 2.0:

• Python
• PowerShell
• C
• C#
• Perl
• Ruby
• Golang

Environmental Detection

Another new feature in Veil 3.0 is the ability to check information about the system where the Veil payload is running. This feature is useful for ensuring that shellcode is only executed on target systems and during the engagement timeframe. The stager performs these checks and will only inject and execute the embedded shellcode if the specified conditions are met. Figure 5 shows the options for this feature.

Figure 5: Environmental detection options

Users can specify one or more of the following checks for Veil stagers:

• The domain that the victim machine must be joined to.
• A date that the payload expires on.
• The hostname of the system running the payload.
• The minimum number of processors on the system running the payload.
• The required username running the payload.

If specifying more than one check, all checks must be met; otherwise the stager will cease execution without executing the shellcode.

This covers the major updates with Veil 3.0's release. If you have any questions, or encounter an issue, please visit Veil's Github repository. I hope that Veil can help further your assessments in the same way that it has helped us.

In late February 2017, FireEye as a Service (FaaS) identified a spear phishing campaign that appears to be targeting personnel involved with United States Securities and Exchange Commission (SEC) filings at various organizations. Based on multiple identified overlaps in infrastructure and the use of similar tools, tactics, and procedures (TTPs), we have high confidence that this campaign is associated with the financially motivated threat group tracked by FireEye as FIN7.

FIN7 is a financially motivated intrusion set that selectively targets victims and uses spear phishing to distribute its malware. We have observed FIN7 attempt to compromise diverse organizations for malicious operations – usually involving the deployment of point-of-sale malware – primarily against the retail and hospitality industries.

Spear Phishing Campaign

All of the observed intended recipients of the spear phishing campaign appeared to be involved with SEC filings for their respective organizations. Many of the recipients were even listed in their company’s SEC filings. The sender email address was spoofed as EDGAR <filings@sec.gov> and the attachment was named “Important_Changes_to_Form10_K.doc” (MD5: d04b6410dddee19adec75f597c52e386). An example email is shown in Figure 1.

Figure 1: Example of a phishing email sent during this campaign

We have observed the following TTPs with this campaign:

• The malicious documents drop a VBS script that installs a PowerShell backdoor, which uses DNS TXT records for its command and control. This backdoor appears to be a new malware family that FireEye iSIGHT Intelligence has dubbed POWERSOURCE. POWERSOURCE is a heavily obfuscated and modified version of the publicly available tool DNS_TXT_Pwnage. The backdoor uses DNS TXT requests for command and control and is installed in the registry or Alternate Data Streams. Using DNS TXT records to communicate is not an entirely new finding, but it should be noted that this has been a rising trend since 2013 likely because it makes detection and hunting for command and control traffic difficult.
• We also observed POWERSOURCE being used to download a second-stage PowerShell backdoor called TEXTMATE in an effort to further infect the victim machine. The TEXTMATE backdoor provides a reverse shell to attackers and uses DNS TXT queries to tunnel interactive commands and other data. TEXTMATE is “memory resident” – often described as “fileless” malware. This is not a novel technique by any means, but it’s worth noting since it presents detection challenges and further speaks to the threat actor’s ability to remain stealthy and nimble in operations.
• In some cases, we identified a Cobalt Strike Beacon payload being delivered via POWERSOURCE. This particular Cobalt Strike stager payload was previously used in operations linked to FIN7.
• We observed that the same domain hosting the Cobalt Strike Beacon payload was also hosting a CARBANAK backdoor sample compiled in February 2017. CARBANAK malware has been used heavily by FIN7 in previous operations.

Victims

Thus far, we have directly identified 11 targeted organizations in the following sectors:

• Financial services, with different victims having insurance, investment, card services, and loan focuses
• Transportation
• Retail
• Education
• IT services
• Electronics

All these organizations are based in the United States, and many have international presences. As the SEC is a U.S. regulatory organization, we would expect recipients of these spear phishing attempts to either work for U.S.-based organizations or be U.S.-based representatives of organizations located elsewhere. However, it is possible that the attackers could perform similar activity mimicking other regulatory organizations in other countries.

Implications

We have not yet identified FIN7’s ultimate goal in this campaign, as we have either blocked the delivery of the malicious emails or our FaaS team detected and contained the attack early enough in the lifecycle before we observed any data targeting or theft.  However, we surmise FIN7 can profit from compromised organizations in several ways. If the attackers are attempting to compromise persons involved in SEC filings due to their information access, they may ultimately be pursuing securities fraud or other investment abuse. Alternatively, if they are tailoring their social engineering to these individuals, but have other goals once they have established a foothold, they may intend to pursue one of many other fraud types.

Previous FIN7 operations deployed multiple point-of-sale malware families for the purpose of collecting and exfiltrating sensitive financial data. The use of the CARBANAK malware in FIN7 operations also provides limited evidence that these campaigns are linked to previously observed CARBANAK operations leading to fraudulent banking transactions, ATM compromise, and other monetization schemes.

Community Protection Event

FireEye implemented a Community Protection Event – FaaS, Mandiant, Intelligence, and Products – to secure all clients affected by this campaign. In this instance, an incident detected by FaaS led to the deployment of additional detections by the FireEye Labs team after FireEye Labs Advanced Reverse Engineering quickly analyzed the malware. Detections were then quickly deployed to the suite of FireEye products.

The FireEye iSIGHT Intelligence MySIGHT Portal contains additional information based on our investigations of a variety of topics discussed in this post, including FIN7 and the POWERSOURCE and TEXTMATE malware. Click here for more information.

On red team engagements, Mandiant consultants are often tasked with identifying and obtaining access to critical Unix systems within our client’s environments. The objectives may include obtaining payment card data on point of sale terminals or accessing intellectual property residing on Apple MacBooks.

Since Unix systems are typically not domain-joined, locating and authenticating to them can be a challenge. In fact, current methodologies often rely on luck. Typically, this can include:

1. Examining live hosts not enumerable through Active Directory.
2. Running netstat across all domain-joined computers and looking for active connections over common Unix-communicating ports.
3. Performing port scans for services indicative of a Unix host.
4. Searching Active Directory for groups such as “Linux Admins” or “Mac Admins” and identifying their members’ workstations and active sessions.
5. Identifying non-AD LDAP instances and hosts associated with them.

In this blog, I address a new approach to finding Unix systems using a small and purely PowerShell tool we created called SessionGopher.

Our thought process was simple: While most Unix systems are off-domain, they are often accessed and managed by domain-joined Windows systems. These Windows systems typically have remote access tools installed on them that would suggest they communicate with Unix systems, and these tools leave behind valuable artifacts that can help consultants both discover and exploit the Unix systems. SessionGopher is designed to identify these remote access tools and extract any auxiliary information about the hosts to which they connect.

Where It Happens: The HKEY_USERS Hive

The HKEY_USERS hive is a Windows hive that contains persistent information about users who have interactively logged on to the system. For each user that authenticates to the system, Windows creates a user subkey at location HKEY_USERS\<SID>, where <SID> is that user’s security identifier. A privileged account, such as a local or domain administrator, can access the contents of every user subkey on the system under HKEY_USERS. A non-privileged account on the same system can only access the user subkey associated with his or her account.

Amazingly, within these user subkeys reside saved session information for some of the remote access tools discussed earlier. If a user creates a session in WinSCP, a file transfer client often used to communicate with Unix systems, and then saves that session, the entire saved session gets stored in the Registry under that user’s <SID> subkey:

HKEY_USERS\<User’s SID>\Software\Martin Prikryl\WinSCP 2\Sessions\<Session Name>

Using regedit, a graphical interface for the Windows Registry, we can examine the contents of one of these sessions.

Figure 1: A WinSCP saved session in the HKEY_USERS hive

By default, the WinSCP password from Figure 1 is obfuscated by several bitwise operations, not encrypted, unless the user explicitly creates a master password to protect these registry values.

Similarly, PuTTY, an SSH client for Windows, stores its session information as a separate subkey:

HKEY_USERS\<User’s SID>\Software\SimonTatham\PuTTY\Sessions\<Session Name>

While PuTTY does not store passwords, it can store the hostnames to which the client connects, as seen in Figure 2.

Figure 2: A PuTTY saved session in the HKEY_USERS hive

A plethora of remote access tools like these exist which store their saved session information in the user’s HKEY_USERS subkey. Enumerating the domain for systems with these artifacts provides an educated guess as to where Unix systems may be hiding, potentially some credentials, and the hosts that serve as jump boxes to those Unix systems.

Windows Management Instrumentation (WMI)

In developing a post-exploitation tool, using WMI’s remote registry querying functionality to extract these Registry-based saved session artifacts made sense. Our tool SessionGopher leverages WMI to query each SID found in the system’s HKEY_USERS hive for the artifacts discussed earlier.

When a master password is not used, SessionGopher automatically deobfuscates WinSCP saved session passwords, as shown in Figure 3.

Figure 3: SessionGopher’s built-in WinSCP password deobfuscator

On top of WinSCP and PuTTY, SessionGopher extracts saved RDP session data from each user’s HKEY_USERS subkey. This expands SessionGopher’s functionality from strictly finding Unix systems to also identifying systems that may serve as jump boxes to different subnets. Figure 4 demonstrates SessionGopher returning saved RDP sessions on remote host “WIN7-CLIENT01” when run against a set of domain computers.

Figure 4: SessionGopher discovering saved RDP sessions when run across a domain

Expanding Analysis Methodology

Certain remote access tools such as SuperPuTTY and FileZilla store saved sessions as files rather than in the Registry, so SessionGopher also searches remote filesystems for those default file locations and extracts saved passwords when stored. In -Thorough mode, SessionGopher searches the entire remote filesystem for PuTTY private key (.ppk), Remote Desktop Connection (.rdp), and RSA Soft Token (.sdtid) files.

Currently, SessionGopher looks for artifacts from the following sources:

• WinSCP saved sessions
  PuTTY saved sessions
• RDP saved sessions
• FileZilla saved sessions
• SuperPuTTY saved sessions
• PuTTY .ppk Files
  Microsoft .rdp Files
• RSA .sdtid Files

Running SessionGopher across targeted systems on a domain with the –o flag can nicely synthesize all session data into .csv files, allowing the user to keep track of the source computer and user account that led to the session’s discovery. Figure 5 shows SessionGopher’s output folder when run with –o.

Figure 5: Folder of .csvs created by SessionGopher’s –o flag

The fallacy in searching for Unix systems is that if they are not domain-joined, interrogating domain systems for clues provides little insight. As with any internal resource, Unix systems often require management and communication with the corporate domain. The Registry found on each of these domain-joined systems can serve as a trail of breadcrumbs to the exact location of these Unix systems, and to any segmented host of interest.

SessionGopher can be found on FireEye's GitHub. The tool was created by Brandon Arvanaghi and any subsequent updates can be found on his personal GitHub.

Malvertising occurs when an online advertising network knowingly or unknowingly serves up malicious advertisements on a website. Malvertisements are a type of “drive-by” threat that tend to result in users being infected with malware for simply visiting a website. The victims of this threat are often compromised when the malvertisement directs them to an exploit kit (EK) landing page. Depending on the applications running on the user’s system, the EK can successfully load malware into a system without user consent and without tipping the victim off that something suspicious is happening.

It is not uncommon for popular ad servers to redirect to affiliate networks – organizations that forward traffic to servers supporting other malicious domains, which are referred to as “Cushion Servers” or “Shadow Servers”. Under control of EK actors, some cushion servers use HTTP redirect protocols such as 301/302/303 etc., or simply iframe redirects. In other cases the visitor receives pages containing a script that the attacker has injected. This is often the consequence of an unmitigated vulnerability that attackers may exploit to their advantage. Some campaigns use the domain shadowing technique to camouflage rogue ad servers as legitimate advertisers.

In this blog, we will look into some of the prominent malvertising campaigns that were active during the last four months, as well as the cushion servers related to different exploit kits.

Magnitude EK

As seen in Figure 1, Magnitude EK is a popular exploit kit in the APAC region. Throughout the final quarter of 2016 and first month of 2017, FireEye Dynamic Threat Intelligence (DTI) observed consistent Magnitude EK hits from several customers, the majority of whom reside in the APAC region.

Figure 1: Zone distribution for Magnitude EK activity as seen on DTI in last 4 months

In all cases, Magnitude EK affected web servers with the following header information:

“Apache/2.2.15 (CentOS) DAV/2 mod_fastcgi/2.4.6”.

A successful Magnitude EK infection follows the stages seen in Figure 2.

Figure 2: Typical path for malvertising to Magnitude EK

Figure 3: TLD distribution of first layer domains with injected redirect script

Throughout the last four months, different malvertising campaigns have been associated with a group of first layer compromise pages (the TLD distribution is seen in Figure 3), which we will discuss based on common indicators. These first layer compromise pages use the same injected script used for redirection to Magnitude EK. Figure 4 shows a typical injected script used in these campaigns.

Figure 4: Typical malicious injected script used for redirection to Magnitude domains

In all observed instances, the injected script only appears when the site is being loaded through the advertisement (many of which have high Alexa ranking, as we will further explain), and not when those URLs are accessed directly.

FireEye notifications have resulted in many of these campaigns being taken down, which are mentioned in their respective sections.

Through Propeller Ad Networks

Table 1 shows the domains we observed that acted as first layer compromise domains with the injected script for redirection to Magnitude EK being spread from the advertisers, with domains hosted on the Webzilla B.V domain hosting service.

Table 1: Domains with injected redirect script involved in this campaign

These domains appear to be from the same actor due to the similar nature of the URI and domain patterns, and the switching to new domains after one is used a certain number of times. The current IP involved in hosting the active domains is 37.130.229.108. Domains seen in Table 1 were redirected by the following advertisers mentioned in Table 2.

Table 2: Ads used in this campaign

A typical URI seen in this campaign appears as:

btcpaying[.]uk/?reg=asia&traff=propeller

On rare occasions the same campaign also used advertiser poptm[.]com hosted on Cloudflare, but for the most part the ad networks listed in Table 2 were used.

The Bill-Finance and Flash Games Gates

Some malvertisements have been leading users to Flash game websites. In these instances, domains containing the word ‘finance’ in their domain name are being used as the first layer of compromise for the injected script, which redirects to domains hosting Magnitude EK. These Flash sites are registered with ‘AlpNames Limited’ registrar and have been hosted using a PlusServer AG server ISP in Germany.

Registrant information for all of these sites is similar. The registrant name is some variation of the name ‘Bill’ and ‘Guil’ (e.g ‘Billii’, ‘Billy’ etc.). Registrant numbers have consistently been +1.2285161853 or +1.7137015286.

Table 3 shows the names of these Flash game websites and Table 4 shows their malvertising information.

Table 3: Domains with injected redirect script involved in this campaign

Table 4: Ads used in this campaign

The ads from click.seodollars[.]com appear to be using the domain shadowing technique, while all others are legitimate advertisers.

AlpNames Limited registrar has taken down domains associated with this campaign following notification by FireEye.

TTA Adults Limited Using Adcash Ad Group

This category of first layer of compromise is for domains registered under [.]organisation: TTA ADULTS LIMITED. In all instances, the registrant information is as follows:

Registrant Name: Andrew Musgrove
Registrant [.]organization: TTA ADULTS LIMITED
Registrant Street: FOURTH AVENUE UNIT 1B FOCUS 4  
Registrant City: LETCHWORTH
Registrant State/Province: Hertfordshire
Registrant Postal Code: SG6 2TU
Registrant Country: GB
Registrant Phone: +44.7538421640
Registrant Phone Ext:
Registrant Fax:  Registrant Fax Ext:
Registrant Email: musgroveandrew1@gmail[.]com

Domains with this registry information are being redirected by advertisers belonging to Adcash group.

Table 5 shows the names of these campaign domains and Table 6 shows their malvertising information.

Table 5: Domains with injected redirect script involved in this campaign

Table 6: Ads used in this campaign

Adcash has closed domain accounts associated with this group following notification from FireEye.

China Coast

This category of first layer of compromise is for domains registered under [.]organisation: China Coast. In all cases, the registrant information is as follows:

Registrant Name: Goran L Deelen
Registrant [.]organization: China Coast
Registrant Street: Davisstraat 27  
Registrant City: Amsterdam
Registrant State/Province: Noord-Holland
Registrant Postal Code: 1057 TG
Registrant Country: NL Registrant Phone: +31.645495613
Registrant Phone Ext:
Registrant Fax:  Registrant Fax Ext:
Registrant Email: antoni309233@gmail[.]com

The malvertisements can be further categorized by different domain types. Some of the domain names with traffic from Taiwan are redirected by ads.adamoads[.]com (a Chinese advertising site). Additional details are shown in Table 7.

Table 7: Domains and ad services involved in this campaign

Some of the malvertisements in this campaign are redirected through other ad sites, including:

• adexchangeprediction[.]com has been observerd to be redirected from serve.popads[.]net.
• n152adserv[.]com is redirected from engine.phn.doublepimp[.]com

The following rogue ad subdomains in this campaign use the domain shadowing technique:

• syndication.exoclick[.]com
• track.reacheffect[.]com

Table 8 shows other malvertisement cases for Magnitude EK.

Table 8: Other domains and ad services involved in redirection to Magnitude EK

Rig EK

Rig EK emerged as the most prolific exploit kit in the latter half of 2016. Its use in campaigns such as EITest Gate, Pseudo-Darkleech and Afraid Gate is well documented, all of which involve scripts being injected directly within legitimate sites. However, going with the theme of this blog, we will be focusing on noteworthy malvertising campaigns involving redirects to Rig EK domains.

Casino Theme Ad Domains

From the final quarter of 2016 to the start of 2017, we have observed [.]info and [.]pw TLD domains acting as intermediate redirect domains invoked via legitimate advertisers, which eventually lead to Rig EK domains. These domains usually have malicious iframes injected into the content for redirection to Rig EK domains. Figure 5 shows the normal workflow of the campaign.

Figure 5: Ad networks hosted on Google Cloud ISP

Figure 6 show how the ad loads casino-themed domains via 302 redirect. The ad service loads these sites, which are acting as shadow servers to redirect users further to exploit kits, as seen in Figure 7 and Figure 8.

Figure 6: 302 redirect to holdem-pokers.info

Figure 7: Malicious iframe from 1st redirect domain to .pw domain hosted on domain of 2nd IP

Figure 8: Malicious iframe from 2nd layer redirect domain loading Rig EK

The most recent whois information for domains related to this campaign is as follows:

Registrant Name: sergei sergeev
Registrant organization: Private Person
Registrant Street: novoselov 44
Registrant City: ekaterinburg
Registrant State/Province: sverdlovskaya
Registrant Postal Code: 140530
Registrant Country: RU
Registrant Phone: +7.9868847677
Registrant Email: fobos@mail.ru

Admin Name: sergei sergeev
Admin [.]organization: Private Person
Admin Street: novoselov 44
Admin City: moscow
Admin State/Province: moscow
Admin Postal Code: 140530
Admin Country: RU
Admin Phone: +7.9868847677

The whois information slightly varies in older domains registered for the same campaign, but the organization name, state and country remain the same.

Domains are currently active on IP 78.46.232.211 (first redirect after legitimate ad) and 88.198.220.122 (second redirect after legitimate ad). Table 9 shows a complete list of the involved domains.

Table 9: Casino themed domains involved as shadow servers in this campaign

Table 10: Ads used in this campaign

All ad service belong to AdCash ad group, which stopped providing services to these domains in February 2017.

Later, the same campaign switched to the following new domains:

lifeerotic6[.]info; lifeerotic6[.]pw; spoutgame22[.]info; spoutgame22[.]pw; lifeerotic[.]info; 100p2[.]pw; 100p0[.]pw; sproutgame[.]info; sproutgames[.]info.

The IP involved with these new domains (other than two mentioned earlier) is 78.46.232.214. The new whois information is as follows:

Registrant Name: sergei sergeev
Registrant Organization: Private Person
Registrant Street: 64 Vicar Lane
Registrant City: SAPEY
Registrant State/Province: COMMON
Registrant Postal Code: WR6 1JY
Registrant Country: GB
Registrant Phone: +1.3128595849
Registrant Fax:
Registrant Email: fobos@mail.ru

This actor’s new set of domains is now leveraging popular ad service popcash[.]net, which FireEye has notified.

Sundown EK

The following are some of the most prominent malvertising campaigns that are currently active for Sundown EK.

Neighboring IPs Redirected From Different Set of Ad Networks

This campaign has been active using domains hosted on 217.23.13.111 and 217.23.13.110. Domains hosted on both neighboring addresses have their whois information protected by Whois Guard. There are similarities in domain names and each group of domains under these IP addresses (with a Netherlands geolocation).

In these instances, legitimate advertisers are redirected to one of the domains hosted on these IPs, which further redirects to a Sundown EK domain. Figure 9 and Figure 10 show how an ad redirects to intermediary domains hosting a malicious iframe to a Sundown EK landing page.

Figure 9: poptm[.]com redirecting to gomedia[.]online hosted on IP 217.23.13.110

Figure 10: Redirect domain leading an iframe to Sundown EK

There are multiple ad services that are currently redirecting to these domains, as seen in Table 11.

Table 11: Intermediary domains redirecting to Sundown EK and their advertisers seen in this domain

Figure 11 and Figure 12 show details of domains hosted on each neighboring IP involved in this campaign.

Figure 11: Domains with iframe load to Sundown EK hosted on IP 217.23.13.111

Figure 12: Domains with iframe load to Sundown EK hosted on IP 217.23.13.111

Leveraging popcash[.]net

A group of redirect domains has been leveraging advertiser popcash[.]net (Alexa #165) for 302/303 redirects to Sundown EK landing pages. In these instances, the advertiser does not directly lead to a Sundown EK domain, but leads them via a chain of two domains involved in the campaign.

Table 12 shows domains involved in the campaign where popcash[.]net usually leads to a domain via 303 redirect, which further leads to second domain (typically via an iframe or another 303 redirect) and eventually redirects users to a Sundown EK domain.

Table 12: List of shadow server domains involved in this campaign

These domains use two IPs, either: 23.238.19.56 or 173.208.245.114.

A typical example of such redirection can be seen in Figure 13 and Figure 14.

Figure 13: Chain of two domains being redirected from popcash[.]net

Figure 14: Second layer of Shadow server domain redirects to Sundown EK landing page

popcash[.]net cleaned the malicious ads after notification.

Through Propeller Ad Networks

This campaign is related to group of domains with the following whois information:

Registrant Name: elise wickson
Registrant [.]organization: None
Registrant Street: 4-4025 Sladeview Crescent  
Registrant City: mississauga
Registrant State/Province: QC
Registrant Postal Code: L6L 5Y1
Registrant Country: CA
Registrant Phone: +1.5148852225
Registrant Name: bruno calisto
Registrant [.]organization: None
Registrant Street: 8807 PIERRE-BOUCHER  
Registrant City: laval
Registrant State/Province: QC
Registrant Postal Code: H7A3R2
Registrant Country: CA
Registrant Phone: +1.5148859965

These domains are being used as shadow servers to Sundown EK domains after being loaded via legitimate ad sites hosted on Webzilla B.V hosting services. Table 13 shows a complete list of these domains.

Table 13: Domains involved in this campaign

Table 14: Ads involved in redirection for this campaign

Other malvertisement cases for Sundown EK are shown in Table 15.

Table 15: Other domains and ad services involved in redirection to Sundown EK

Terror EK

Terror EK is similar to Sundown EK. It has been consistently leveraging advertiser serve.popads[.]net to redirect traffic to domains controlled by it. The advertiser is used to redirect traffic to a domain hosted on IP 144.217.84.234, which is further redirected to domains hosted on 144.217.84.235 / 94.74.81.91 / 94.74.81.8.

Earlier instances against domains hosted on 149.202.164.86 were seen last year in December by our colleagues at Trustwave and Malwarebytes.

In January 2017, new domain names appeared in the campaign hosted on a different IP location. However, as observed in the previous case, Terror EK continued the campaign to download ccminer payloads.

Figure 15 and Figure 16 show ad services redirecting to domain onlinesalespromarketing[.]com (hosted on 144.217.84.234), which further redirects to a landing page domain onlinesalesproaffiliate4[.]us.

Figure 15. serve.popads[.]net redirect to shadow server

Figure 16. Shadow server redirect to Terror EK landing page

Table 16 shows a list of new domains that use the above mentioned IP’s for hosting landing page:

Table 16: New domains used by Terror EK after first campaign

Conclusion

Malvertising and exploit kits continue to be a significant threat to regular users. While we strongly recommend using ad blockers for all web browsers, we understand that it’s not always possible. For that reason, the best approach is to always keep your web browsers and applications fully updated. Also, regularly check your browser to see what plugins are being used and disable them if they are not necessary.

In all of the examples we discussed, FireEye customers were protected from infection by our multi-flow and multi-vector detection engine.

Update (March 17, 2017): We would like to thank PopCash, Adcash, Propeller Ads, AlpNames Limited and Cloudflare for closing down rogue accounts linked to shadow servers that were discussed in this blog.

Just over one year ago (November 2015), I released WMIOps, a PowerShell script that enables a user to carry out different actions via Windows Management Instrumentation (WMI) on the local machine or a remote machine. WMIOps can:

• Start or stop a process.
• Return a list of all running processes.
• Power off, reboot, or log users off the targeted system.
• Get a listing of all files within a directory.
• Read a file’s contents.
• …and more.

As I continued to develop WMIOps and use it during Mandiant Red Team Operations, I realized that it has some of the same capabilities that are in Remote Access Tools (RATs). WMIOps’s capabilities were in a state of disparate functions, but if I wove what existed along with new functionality, I could create a RAT. After months of development and internal testing, I’m happy to publicly release WMImplant.

WMImplant leverages WMI for the command and control channel, the means for executing actions (gathering data, issuing commands, etc.) on the targeted system, and data storage. It is designed to run both interactively and non-interactively. When using WMImplant interactively, it’s designed to have a menu of commands reminiscent of Meterpreter, as shown in Figure 1.

Figure 1: WMImplant main menu

Data Storage and Device Guard

After spending some time developing WMImplant, I ran into issues storing data on systems that used Device Guard, a Microsoft security feature added in Windows 10 and Server 2016. Even though this feature and these operating systems are not widely deployed today, I wanted WMImplant to support these systems since I expect Device Guard protected systems to become more common, especially at security-conscious organizations. Device Guard helps protect systems by employing (among other capabilities not detailed here):

1. Code Integrity Policies – When deploying Device Guard, administrators will create a code integrity policy (CIP) that explicitly defines what is allowed to run on the protected system. This granularity can range from file hash, file name, publisher, both file name and publisher, and much more. Administrators can create the CIP from a gold-imaged computer. Administrators can further enhance their CIP by preventing applications that provide attackers the ability to bypass Device Guard’s protections from running. Finally, administrators can use Group Policy Objects (GPO) to enable Device Guard, preventing executables or select scripts from running unless explicitly allowed, per the CIP.
2. PowerShell Constrained Language Mode – Device Guard auto-enrolls PowerShell into ConstrainedLanguage mode. Constrained Language mode restricts the cmdlets and data types that are allowed to run in PowerShell. In this mode, .NET methods are completely blocked unless they are an allowed data type.

On a Device Guard protected system, attackers cannot run custom executables, and the available PowerShell cmdlets are severely restricted. For example, simple functionality such as base64 encoding a string is not permitted within Constrained Language mode, as shown in Figure 2.

Figure 2: PowerShell Constrained Language mode blocking base64 encoding

At first, I designed WMImplant to use the Windows Registry for data storage, as described in Matt Graeber’s WMI research. However, after discussing using the Windows Registry for data storage with Matt Dunwoody (a Mandiant coworker), he suggested, “Why not also use WMI itself for storage?”

This conversation led me to research using WMI for data storage. I found a proof-of-concept for creating custom WMI properties (Figure 3) in FireEye’s report on WMI Offense, Defense, and Forensics.

Figure 3: Sample code from FireEye report on WMI Offense, Defense, and Forensics

However, after testing this code on a Device Guard protected system, I discovered that this wasn’t permitted within Constrained Language mode, as shown in Figure 4.

Figure 4: Constrained Language mode blocking WMI property creation

After some additional research, I found that within Constrained Language mode, users are able to create custom WMI classes. But, as evidenced by Figure 4, WMI property creation is not allowed, so this wouldn’t work for data storage. Therefore, my next thought was to store data in an existing WMI property. In order to leverage an existing WMI property, a few conditions would need to be present:

1. The property needs to be of type string.
2. The property needs to be writable.
3. The property needs to accept an arbitrary length of data.
4. Modifications to the property need to not blue screen or degrade use of the targeted system.
5. Most importantly, the property needs to be writable within Constrained Language mode.

I modified an existing PowerShell script to enumerate all WMI classes, find the properties of each class, check if each property is a string type, and determine if it is writable (the script is available here).

The script identified a list of candidate WMI properties, but for one reason or another, modifications to those that I initially tested resulted in “general failures”. Then, I came across a class I have not previously used: Win32_OSRecoveryConfiguration. This class has a property named “DebugFilePath”, which is the file path where Windows will place a memory dump after a computer failure, as shown in Figure 5.

Figure 5: Win32_OSRecoveryConfiguration’s DebugFilePath property

The DebugFilePath appears to only accept a file path, and the property should be limited to the length of a valid Windows paths (260 characters by default or 32k with LongPathsEnabled). In testing, however, I discovered that I could write an arbitrary string to the DebugFilePath property within Constrained Language mode without adversely affecting the targeted system. The final test was to determine how much data could be placed in the DebugFilePath property.

Figure 6: Data storage test within DebugFilePath

Figure 6 shows that the DebugFilePath property can store over 57 megabytes of data. This satisfied the data storage requirement for WMImplant, and future testing showed that the DebugFilePath property could store more than 250 megabytes of data. Additionally, using the DebugFilePath WMI property for data storage provides the side-benefits that it is easily retrievable and modifiable remotely.

This discovery shaped WMImplant’s command and control communications methodology. For commands issued by WMImplant that require data storage, the communication process is as follows:

1. Remotely query and obtain the original value for Win32_OSRecoveryConfiguration’s DebugFilePath property.
2. Use WMImplant to execute a command on the targeted system (such as ifconfig), encode the output, and store the encoded results in the DebugFilePath property.
3. Remotely query the targeted system’s DebugFilePath over WMI to receive the encoded results.
4. Decode the results and display them to the console.
5. Set the DebugFilePath property on the targeted system back to its original value.

This methodology for command and control communications minimizes the amount of time that the WMI property is modified from its original state.

WMImplant Usage

I’ve developed WMImplant for both interactive and non-interactive use. Users also have the ability to change the user account that is authenticating to the targeted machine. As shown in Figure 7, users can issue the “change_user” command, provide the username and password to use, and then all future commands through WMImplant will authenticate with the provided credentials.

Figure 7: Changing the current user context within WMImplant

The easiest way to use WMImplant is interactively; however, that isn’t always possible. RATs such as Meterpreter or Cobalt Strike’s Beacon allow users to load and execute PowerShell scripts, but both of those tools require non-interactive use. That is, the tools accept a command to run, execute it, and return the results. They do not allow the user to interact with the command while running, however. WMImplant includes a built-in command-line generating feature specifically for this use case. To generate a command-line, start WMImplant and specify the “gen_cli” command.

After issuing the “gen_cli” command, the user will be presented with the normal WMImplant menu and asked for the command to be run. WMImplant will then ask for any required information for the command specified. Once the user has provided everything that’s required, WMImplant will display the command-line command to run in a non-interactive manner, as shown in Figure 8.

Figure 8: “gen_cli” output

At this point, the user can load WMImplant within the RAT of choice, and copy and paste the command to run WMImplant non-interactively.

Another of WMImplant’s capabilities is the ability to run a PowerShell script on a remote machine and receive script output. This is performed through a multi-step process:

1. The attacking system queries the targeted system’s DebugFilePath property to obtain its original value.
2. The attacking system reads in the specified PowerShell script, encodes it, and stores it in the targeted system’s DebugFilePath property.
3. WMI spawns a PowerShell process on the targeted system that reads the DebugFilePath property, and decodes the PowerShell script.
4. The PowerShell process runs the user-specified function and stores the function output in a variable.
5. The data in the variable is encoded and stored in the DebugFilePath property, and the PowerShell process exits.
6. The attacking system makes an additional WMI query for the DebugFilePath value (currently storing the encoded data), decodes the data, and displays its contents to the console.
7. The attacking system replaces the encoded data with the original DebugFilePath property contents on the targeted system over WMI.

This multi-step process is demonstrated in Figure 9.

Figure 9: Remote PowerShell execution

While I’ve only talked about a limited number of WMImplant’s features, others include:

• Setting/removing the “UseLogonCredential” Windows Registry value to enable credential caching.
• Uploading/downloading files.
• Enabling/disabling Windows Remote Management (WinRM) to remotely connect to and issue commands on a system using PowerShell.
• Identifying users who have logged in to the targeted system.
• Listing files by directory.
• Reading file contents.
• …and more.

I hope that WMImplant can help others as it has helped us on multiple assessments. If you notice any bugs, please let me know and I’ll be happy to get a fix pushed!

WMImplant can be downloaded here.

Thanks

I want to state that I wouldn’t have been inspired to work on this without the previous work of Matt Graeber, Willi Ballenthin, and Claudiu Teodorescu. Their work gave me a lot of great ideas that I was able to build upon when developing WMImplant.