Phishing – Ask and ye shall receive

During penetration tests, our primary goal is to identify the difference in paths that can be used to obtain the goal(s) as agreed upon with our customers. This often succeeds due to insufficient hardening, lack of awareness or poor password hygiene. Sometimes we do get access to a resource, but do not have access to the username or password of the user that is logged on. In this case, a solution can be to just ask for credentials in order to increase your access or escalate our privileges throughout the network. This blogpost will go into the details of how the default credential gathering module in a pentesting framework like MetaSploit can be further improved and introduces a new tool and a Cobalt Strike module that demonstrates these improvements.

Current situation

Let’s say that we have a meterpreter running on our target system but were unable to extract user credentials. Since the meterpreter is not running with sufficient privileges, we also cannot access the part of the memory where the passwords reside. To ask the user for their credentials, we can use a post module to spawn a credential box on the user’s desktop that asks for their credentials. This credential box looks like the one in the image below.

old_pwd_prompt

While this often works in practice, a few problems arise with using this technique:

  • The style of the input box stems from Windows XP. When newer versions of Windows ask for your credentials, a different type of input box is used;
  • The credential box spawns out-of-the-blue. Even though a message and a title can be provided, it does not really look genuine; it misses a scenario where a credential box asking for your credentials can be justified.

A better solution

Because of these issues, this technique will perhaps not work on more security aware users. These users can be interesting targets as well, so we created a new script that solves the aforementioned problems. For creating a realistic scenario, the main approach was: “What would work on us?” The answer to this question must at least entail the following:

  • The credential box should be genuine and the same as the one that Windows uses;
  • The credential box should not be spawned out-of-the-blue; the user must be persuaded or should expect a credential box;
  • If (error) messages are used, the messages should be realistic. Real life examples are even better;
  • No or limited visible indications that the scenario is not real.

As a proof of concept, Fox-IT created a tool that uses the following two scenario’s:

  • Notifications that stem from an (installed) application;
  • System notifications that can be postponed.

With this, the attacker can use his creativity to deceive the user. Below are some examples that were created during the development of this tool:

Outlook lost connection to Microsoft Exchange. In order to reconnect, the user must specify credentials to reestablish connection to Microsoft Exchange.

outlook_toast

Password that expires within a short period of time.

change_password

The second scenario imitates notifications from Windows itself, such as pending updates that need to be installed. The notification toast tricks the user into thinking that the updates can be postponed or dismissed. When the user clicks on the notification toast the user will be asked to supply their credentials.

updates_toast

If the user clicks on one of these notifications, the following credential box will pop up. The text of the credential box is fully customizable.

creds_outlook

Once the user has submitted their credentials, the result is printed on the console which can be intercepted with a tool of your choosing, such as Cobalt strike. We created an aggressor script for Cobalt Strike that extends the user interface with a variety of phishing options.

cs

Clicking on one of these options will launch the phishing attack on the remote computer. And if users enter their credentials, the aggressor script will store these in Cobalt Strike as well. The tool as well as the Cobalt Strike aggressor script are available on Fox-IT’s GitHub page: https://github.com/fox-it/Invoke-CredentialPhisher

 

Technical details

During the development of this tool, there were some hurdles that we needed to take. At first, we created a tool that pops a notification balloon. That worked quite well, however, the originating source of the balloon was mentioned in the balloon as well. It’s not really genuine when Windows Powershell ISE asks for Outlook credentials, so that was not a solution that satisfied us.

balloon_powershell

In recent versions of Windows, toast notifications were introduced. These notifications look almost the same as a notification balloon that we used earlier, but work entirely different. By using toast notifications, the problem that the originating source was shown was solved. However, it proved not possible to use event handlers on the toast notifications with native PowerShell. We needed an additional library that acts as a wrapper, which can be found on the following GitHub page: https://github.com/rkeithhill/PoshWinRT

That library solved one part of the issue, but needed to be present on the filesystem of the target computer. That leaves traces of our attack which we do not want, plus, we want to leave the least amount of traces of our malicious code. Therefore, we encoded the library as base64 and stored that in the PowerShell script. The base64 equivalent of the library is evaluated and loaded from memory during runtime and will leave no trace on the filesystem once the tool has been executed. So, now we had a tool capable of sending toast notifications that look genuine. Because of how Windows works, we could also create an extra layer of trust by using an application ID as the source of the notification toast. That way, if you were able to find the corresponding AppID, it looks like the toast notification was issued by the application rather than an attacker.

The notifcation toasts supports the following:

  • Custom toast notification title;
  • Custom credential box title;
  • Custom multiline toast notification message.

To make it more personal, it is possible to use references to attributes that are part of the System.DirectoryServices.AccountManagement.UserPrincipal object. These attributes can be found on the following Technet article: https://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.userprincipal_properties(v=vs.110).aspx. Additionally, the application scenario supports the following extra features when an application name is provided and can be found by the tool:

  • AppID lookup for adding extra layer of credibility. If no AppID is found, the tool will default to control panel;
  • Extraction of the application icon. The extracted icon will be used in the notification toast;
  • If no process is given or the process cannot be found, the tool will extract the information icon from the C:\Windows\system32\shell32.dll library. By modifying the script, it is easy to incorporate icons from other libraries as well;
  • Hiding of application processes. All windows will be hidden from the user for extra persuasion. The visibility will be restored once the tool is finished or when the user supplied their credentials.

Cmdline examples

For the examples above, the following onliners were used:

Outlook connection:

.\Invoke-CredentialPhisher.ps1 -ToastTitle "Microsoft Office Outlook" -ToastMessage "Connection to Microsoft Exchange has been lost.`r`nClick here to restore the connection" -Application "Outlook" -credBoxTitle "Microsoft Outlook" -credBoxMessage "Enter password for user ‘{emailaddress|samaccountname}'" -ToastType Application -HideProcesses

Updates are available:

.\Invoke-CredentialPhisher.ps1 -ToastTitle "Updates are available" -ToastMessage "Your computer will restart in 5 minutes to install the updates" -credBoxTitle "Credentials needed" -credBoxMessage "Please specify your credentials in order to postpone the updates" -ToastType System -Application "System Configuration"

Password expires:

.\Invoke-CredentialPhisher.ps1 -ToastTitle "Consider changing your password" -ToastMessage "Your password will expire in 5 minutes.`r`nTo change your password, click here or press CTRL+ALT+DELETE and then click 'Change a password'." -Application "Control Panel" -credBoxTitle "Windows Password reset" -credBoxMessage "Enter password for user '{samaccountname}'" -ToastType Application

Recommendations

There are no specific recommendations that are applicable to this phishing technique, however, some more generic recommendations are still applicable:

  • Check if PowerShell script logging and transcript logging is enabled;
  • Raise security awareness;
  • Although it is quite hard to distinguish a fake notification toast from a genuine notification toast, users should have a paranoid approach when it comes to processes asking for their credentials.

Introducing Team Foundation Server decryption tool

During penetration tests we sometimes encounter servers running software that use sensitive information as part of the underlying process, such as Microsoft’s Team Foundation Server (TFS). TFS can be used for developing code, version control and automatic deployment to target systems. This blogpost provides two tools to decrypt sensitive information that is stored in the TFS database.

Decrypting TFS secrets

Within Team Foundation Server (TFS), it is possible to automate the build, testing and deployment of new releases. With the use of variables it is possible to create a generic deployment process once and customize it per environment.1 Sometimes specific tasks need a set of credentials or other sensitive information and therefor TFS supports encrypted variables. With an encrypted variable the contents of the variables is encrypted in the database and not visible for the user of TFS.

TFS_Variable

However, with the correct amount of access rights to the database it is possible to decrypt the encrypted content. Sebastian Solnica wrote a blogpost about this, which can be read on the following link: https://lowleveldesign.org/2017/07/04/decrypting-tfs-secret-variables/

Fox-IT wrote a PowerShell script that uses the information mentioned in the blogpost. While the blogpost mainly focused on the decryption technique, the PowerShell script is built with usability in mind. The script will query all needed values and display the decrypted values. An example can be seen in the following screenshot:

tfs_decrypted

The script can be downloaded from Fox-IT’s Github repository: https://github.com/fox-it/Decrypt-TFSSecretVariables

It is also possible to use the script in Metasploit. Fox-IT wrote a post module that can be used through a meterpreter session. The result of the script can be seen in the screenshot below.

msf_tfs

There is a pull request pending and hopefully the module will be part of the Metasploit Framework soon. The pull request can be found here: https://github.com/rapid7/metasploit-framework/pull/9930

References

[1] https://docs.microsoft.com/en-us/vsts/build-release/concepts/definitions/release/variables?view=vsts&tabs=batch
[2] https://lowleveldesign.org/2017/07/04/decrypting-tfs-secret-variables

Introducing Orchestrator decryption tool

Researched and written by Donny Maasland and Rindert Kramer

Introduction

During penetration tests we sometimes encounter servers running software that use sensitive information as part of the underlying process, such as Microsoft’s System Center Orchestrator.
According to Microsoft, Orchestrator is a workflow management solution for data centers and can be used to automate the creation, monitoring and deployment of resources in your environment.1 This blogpost covers the encryption aspect of Orchestrator and new tools to decrypt sensitive information that is stored in the Orchestrator database.

Orchestrator, variables, encryption and SQL

In Orchestrator, it is possible to create variables that can be used in runbooks. One of the possibilities is to store credentials in these variables. These variables can then be used to authenticate with other systems. Runbooks can use these variables to create an authenticated session towards the target system and run all the steps that are defined in the runbook in the context of the credentials that are specified in the variable.

Information, such as passwords, that is of a sensitive nature can be encrypted by using encrypted variables. The contents of these variables are stored encrypted in the database when they are created and are decrypted when they are used in the runbooks. The picture below displays the dialog to create an encrypted variable.

dialog

Orchestrator uses the internal encryption functionality of Microsoft SQL server2 (MSSQL). The decryption keys are stored in the SYS database and have to be loaded in to the SQL session in order to decrypt data.

To decypt the data, we need the encrypted content first. The following query returns the encrypted content:

SELECT VARIABLES.value, objects.Name FROM VARIABLES INNER JOIN OBJECTS ON OBJECTS.UniqueID = VARIABLES.UniqueID;

If there are secret variables stored in the database, this will result in encrypted data, such as:
\`d.T.~De/00F04DA615688A4C96C2891105226AE90100000059A187C285E8AC6C1090F48D0BFD2775165F9558EAE37729DA43BE92AD133CF697D2C5CC1E6E27E534754099780A0362C794C95F3747A1E65E869D2D43EC3597\`d.T.~De/

The data between \`d.T.~De/ is the data we are interested in, which leaves us with the following string:
00F04DA615688A4C96C2891105226AE90100000059A187C285E8AC6C1090F48D0BFD2775165F9558EAE37729DA43BE92AD133CF697D2C5CC1E6E27E534754099780A0362C794C95F3747A1E65E869D2D43EC3597
Please note that the \`d.T.~De/ value might differ per data type.

Since this data is encrypted, the decryption key needs to be loaded in the SQL session. To establish this, we open an SQL session and run the following query:

OPEN SYMMETRIC KEY ORCHESTRATOR_SYM_KEY DECRYPTION BY ASYMMETRIC KEY ORCHESTRATOR_ASYM_KEY;

This will load the decryption key into the SQL session.

Now we run this string against the decryptbykey function in MSSQL3 to decrypt the content with the encryption key that was loaded earlier in the SQL session. If successful, this will result in a varbinary object that we need to convert to nvarchar for human readable output.

The complete SQL query will look like this:

SELECT convert(nvarchar, decryptbykey(0x00F04DA615688A4C96C2891105226AE90100000059A187C285E8AC6C1090F48D0BFD2775165F9558EAE37729DA43BE92AD133CF697D2C5CC1E6E27E534754099780A0362C794C95F3747A1E65E869D2D43EC3597));

Executing this query will return the unencrypted value of the variable, as can be seen in the following screenshot.
orch_result_sql

Automating the process

Fox-IT created a script that automates this process. The script queries the secrets and decrypts them automatically. The result of the script can be seen in the screenshot below.
orch_tool_result

The script can be downloaded from Fox-IT’s Github repository: https://github.com/fox-it/Decrypt-OrchestratorSecretVariables

Fox-IT also wrote a Metasploit post module to run this script through a meterpreter.
msf_output

The Metasploit module supports integrated login. Optionally, it is possible to use MSSQL authentication by specifying the username and password parameters. By default, the script will use the ‘Orchestrator’ database, but it is also possible to specify another database with the database parameter. Fox-IT did a pull request to add this module to Metasploit, so hopefully the module will be available soon. The pull request can be found here: https://github.com/rapid7/metasploit-framework/pull/9929

References

[1] https://technet.microsoft.com/en-us/library/hh237242(v=sc.12).aspx
[2] https://technet.microsoft.com/en-us/library/hh912316(v=sc.12).aspx
[3] https://docs.microsoft.com/en-us/sql/t-sql/functions/decryptbykey-transact-sql?view=sql-server-2017

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

Lessons learned from a Man-in-the-Middle attack

It’s become a widely accepted mantra that experiencing a cyber breach is a question of ‘when’ and not ‘if’. For Fox-IT ‘if’ became ‘when’ on Tuesday, September 19 2017, when we fell victim to a “Man-in-the-Middle” attack. As a result of the multi-layered security protection, detection and response mechanisms we had in place, the incident was both small and contained, but as a cyber security specialist it has made us look long and hard at ourselves. While the police investigation is still on-going, we are sharing details of this incident with the public now that we feel confident that most details are sufficiently clear. This is about who we are and what we do. We believe that ultimately in these cases, transparency builds more trust than secrecy and there are lessons to be learned, both good and bad, that we want to share.

So what happened?

In the early morning of September 19 2017, an attacker accessed the DNS records for the Fox-IT.com domain at our third party domain registrar. The attacker initially modified a DNS record for one particular server to point to a server in their possession and to intercept and forward the traffic to the original server that belongs to Fox-IT. This type of attack is called a Man-in-the-Middle (MitM) attack. The attack was specifically aimed at ClientPortal, Fox-IT’s document exchange web application, which we use for secure exchange of files with customers, suppliers and other organizations. We believe that the attacker’s goal was to carry out a sustained MitM attack.

Because we detected and addressed the breach quickly we limited the total effective MitM time to 10 hours and 24 minutes. In the scheme of the industry average time of detection of weeks this was a short exposure, but we couldn’t prevent the attacker from intercepting a small number of files and information that they should not have had access to. An important first step in our response was to contact Law Enforcement and share the necessary information with them to enable them to start a criminal investigation.

The incident unfolded as follows (all times are CEST):

Sept 16 2017 First reconnaissance activities against our infrastructure that we believe are attributable to the attacker. These included regular port scans, vulnerability scans and other scanning activities.
Sept 19 2017, 00:38 The attacker changed DNS records for fox-it.com domain at a third party provider.
Sept 19 2017, 02:02 Latest moment in time that we have been able to determine that clientportal.fox-it.com still pointed to our legitimate ClientPortal server. This means that traffic destined for the ClientPortal was not being intercepted yet.
Sept 19 2017, 02:05-02:15 Maximum 10-minute time window during which the attacker temporarily rerouted and intercepted Fox-IT email for the specific purpose of proving that they owned our domain in the process of fraudulently registering an SSL certificate for our ClientPortal.
Sept 19 2017, 02:21 The actual MitM against our ClientPortal starts. At this point, the fraudulent SSL certificate for ClientPortal was in place and the IP DNS record for clientportal.fox-it.com was changed to point to a VPS provider abroad.
Sept 19 2017, 07:25 We determined that our name servers for the fox-it.com domain had been redirected and that this change was not authorized. We changed the DNS settings back to our own name servers and changed the password to the account at our domain registrar. This change will have taken time to have full effect, due to caching and the distributed nature of the domain name system.
Sept 19 2017, 12:45 We disabled the second factor authentication for our ClientPortal login authentication system (text messages), effectively preventing users of ClientPortal from successfully logging in and having their traffic intercepted. Other than that, we kept ClientPortal functional in order not to disclose to the attacker that we knew what they were doing, and to give ourselves more time to investigate. At this point, the MitM against ClientPortal was still active technically, but would no longer receive traffic to intercept as users would not be able to perform two factor authentication and log in.
Sept 19 – Sept 20 2017 A full investigation into the incident was undertaken, along with notification of all clients that had files intercepted and the relevant authorities, including the Dutch Data Protection Authority. A police investigation was launched and is still ongoing. Based on the outcome of our investigation, we understood the scope of the incident, we knew that the attack was fully countered and we were prepared to re-enable two factor authentication on ClientPortal in order to make it fully functional again.
Sept 20, 15:38 ClientPortal fully functional again. Our internal investigation into the incident continued.

What kind of information did the attacker intercept?

As mentioned, the attacker was able to redirect inbound traffic to ClientPortal and emails going to the fox-it.com domain for a short period of time. At no stage did they have access to any external or internal Fox-IT system, or indeed system level access to our ClientPortal.

When investigating the attack, we made heavy use of our own technology. For all Fox-IT traffic, we employ CTMp network sensors to detect anomalies and alert us of attacks. All our sensors do full packet capture and this is what allowed us to determine precisely, beyond any doubt, which information was intercepted by the attacker, the timeline of the event and who was affected by the attack.

Because of this we know the following about the information that the attacker was able to intercept:

  • We know the following facts about the information that the attacker intercepted:
    1. Nine individual users logged in and their credentials were intercepted and all users were contacted immediately. Because we use two factor authentication, these credentials alone were not enough for the attacker to log in to ClientPortal.
    2. Twelve files (of which ten were unique) were transferred and intercepted.
      • Of these, three files were client confidential in nature, none were classified as state secret. Files classified as state secret are never transferred through our ClientPortal.
      • Other files were in the public domain and not confidential.
      • All affected clients in respect of these files were contacted immediately.
    3. One mobile phone number was intercepted and this person was informed.
    4. A subset of names and email addresses of ClientPortal users were intercepted.
      • We determined that this information alone would not be considered sensitive, but we have nevertheless informed those people affected.
    5. The names of accounts in ClientPortal were intercepted.
      • This is a list of the names of organizations that we have exchanged files with in the past. This includes organizations such as customers, partners and suppliers.
      • After review, we determined that the names alone would not be considered sensitive.
  • Email: we know that the attacker intercepted Fox-IT email for a maximum of 10 minutes, and that during those 10 minutes, emails destined for Fox-IT were redirected to an external email provider. Since email distribution is decentralized on the internet, we have no way of determining which emails were intercepted by the attacker during that time.

The start of the incident response process

We have determined that the attacker successfully logged in to the DNS control panel of our third party domain registrar provider using valid credentials. This raises two key questions:

  • How were valid credentials obtained?
  • Why was access to the domain registrar possible with single factor rather than multi factor authentication?

On the question of how the credentials were obtained we have conducted extensive internal investigations alongside those conducted by the police investigating the incident. We interviewed people that had access to the vault, carried out extensive forensic investigation of all the systems that the password could been used on, and performed additional network forensics. We currently have no evidence that the password was stolen from any of our own internal systems. Right now, based on our own and the police investigation, we have strong evidence that supports our hypothesis that the adversary gained access to our credentials through the compromise of a third party provider. Investigations are ongoing.

A factor which possibly helped the attacker was that the password had not been changed since 2013. While our password is considered strong and can withstand brute force attacks, it was not changed because it was hardly ever used: DNS settings in general change very rarely. Nevertheless, this was something we could clearly have improved in our process.

The infrequency of our engagement with our domain registrar is also behind the answer to the second question, as to how the attacker was able to gain access to the DNS records solely using a username/password combination. Two factor authentication (2FA) – whereby the initial attempt to log-on can only be completed once a code sent to an authorized device is entered as second factor authentication – should be standard practice here. We chose our domain name registrar provider 18 years ago when 2FA was neither a consideration nor a possibility. We were surprised to find that the registrar still does not support 2FA. It is always worth asking: does your DNS registrar support 2FA? The answer may surprise you.

Reasonably quick detection but room for improvement

We hold our hands up to a number of errors on prevention, but we did decidedly better in the areas of detection and response. Once the attack was ongoing, we detected it reasonably quickly: within a few hours compared to the typical industry average of weeks before an attack is detected.

Our Security Operations Center (SOC) had noticed that a number of scans for weaknesses on our infrastructure were made in the days leading up to the attack. These were treated as regular “background noise on the internet” and not followed up on. While paying attention to those scans would probably not have helped us predict the following attack, it would certainly have raised our attention and we have now established mechanisms to improve early warning of suspicious security probing of this nature.

Effective response, containment and scope determination

In general, once an incident is detected, the most important goal becomes to limit the incident and determine the impact of the attack. Once we knew about the incident, we acted quickly and we were able to limit the impact of the incident quite effectively and in a timely manner.

The most important action that we took in order to limit the impact of the attack was to disable 2FA, in lieu of disabling login functionality altogether. We did this specifically to prevent people from successfully logging in but so as not to alert the attacker to the fact that we knew of the attack. This allowed us to better understand the modus operandi and scope of the attack before taking specific actions to mitigate it, an approach which is standard operating procedure for our CERT team. From that moment on, nobody could log in, effectively preventing traffic to our ClientPortal from being intercepted. Note that this did not directly stop the attack, but it stopped its effectiveness.

The use of full packet capture and CTMp network sensors was crucial in determining the scope of the attack. We could, within a few hours of finding out about the attack, determine exactly who was affected and what the scope of the attacker was. This helped us to understand the incident with confidence and to quickly notify those directly affected and the Dutch Data Protection Authority.

Lessons learned and recommendations

Looking back on this incident, we learned the following lessons and have the following recommendations:

  • Choose a DNS provider that doesn’t allow changes through a control panel but requires a more manual process, considering that name servers are very stable and hardly every change. If you do require more frequent changes, use 2FA.
  • Ensure that all system access passwords are reviewed regularly and changed, even those which are used rarely.
  • Deploy certificate transparency monitoring in order to detect, track and respond to fraudulent certificates.
  • Deploy full packet capture capabilities with good retention in crucial points of your infrastructure, such as the DMZ and border gateways.
  • Always inform Law Enforcement at an early stage, so that they can help you with your investigations, as we did in our case.
  • Make it a management decision to first understand an attack before taking specific actions to mitigate it. This may include letting an attack continue for a short period of time. We consciously made that decision.

Looking back in conclusion

While we deeply regret the incident and the shortcomings on our part which contributed to it, we also acknowledge that a number of the measures we had in place enabled us to detect the attack, respond quickly and confidently and thereby limited the scale and length of the incident. And that’s why the twin mantras in security should always be followed:

  • layered security; and
  • prevention, detection and response.

At the time that ‘if’ becomes ‘when’, it is the combination of these that ultimately determines your overall resilience and cyber security stance.

Criminals in a festive mood

This morning the Fox-IT Security Operations Center observed a large number of phishing e-mails that contained a link to a downloadable zip file. Anyone downloading and opening that zip file would infect themselves with banking malware, that would subsequently try to lure the victim into divulging their credit card information.

So far nothing new: e-mail as attack vector, distribution of the Zeus Panda banking trojan, targeting the same institutions.

Except that this time, it appears the criminals are preparing for the festive season. What stood out to us is the inclusion of a number of local retailers that are now targeted by this banking trojan. Some targeted websites which were extracted from the configuration are:

  • Coolblue
  • Booking.com
  • Otto
  • Amazon
  • De Volksbank (SNS, ASN & Regiobank)
  • ING
  • ABN Amro
  • Knab
  • Triodos

So now, when someone has infected themselves with this malware by opening the malicious zip file, not only will the malware ask for their credit card details when they visit their bank’s website, but also when they visit an online retailer for (Christmas) shopping.

Read on for recommendations, notable observations, stats and screenshots and technical details including indicators of compromise.

Recommendations
The usual recommendations for end users apply: be alert for criminals attacking you by sending legitimate looking e-mails with links and attachments. And be alert for websites behaving differently and asking for credit card details or other personal data where they normally don’t. If you suspect an infection, you may check out a website from a different device to see if it behaves the same. If it doesn’t, you may be infected.

The e-mail itself is nothing out of the ordinary. It appears to be targeting the Netherlands and Germany, using Dutch text and faking the Dutch DHL Group. This is what it looks like:

Beste heer/mevrouw,
UW ZENDING IS ONDERWEG ,Informatie Over Uw Zending is in dokument.

Controleer hieronder uw zending- en contactgegevens. Klik op om te bevestigen.
Bedankt dat u heeft gekozen voor On Demand Delivery.
DHL Express – Excellence. Simply delivered.
Nederlandse Post DHL Group

For organisations, the recommendations are also familiar: isolate any infected systems prior to cleaning them, change any password that was used after infection and consider client certificates on that system compromised. You may refer to the indicators of compromise later on in this post.

Additional interesting observations
The malware that is being distributed is called Zeus Panda, which we’ve followed for almost two years now. This is a variant of the Zeus family of malware that Fox-IT has observed since around 2006, for the purpose of protecting its own customers. The name Zeus Panda comes from the web panel used by the malware operators.

At the time of writing, the two malicious zip file referred in the emails received a little over 48 thousand clicks, mostly in the Netherlands, but also in other parts of Western Europe and some in North America. Out of those 48 thousand clicks, only 11 thousand came from a Window system, which is the only platform that the malware runs on. The other 37 thousands people were safe! A clear example and proof of the shotgun approach that criminals still successfully use.

Also interesting is the clunky nature of the injects. As shown in the screenshots below, the code that the criminals inject into the website on the infected system looks, well, unfinished.

Full statistics
The link in the email is a Google Shortened URL, which downloads the zip-file from
hxxp://partytimeevents.nl/contactgegevens%2012_2017_10_00_.zip
hxxp://stegengaweb.nl/files/contactgegevens%2012_2017_10_00_.zip

By default Google shortened URL’s keeps track of the following statistics:
– Amount of clicks
– Used Browsers
– Referrers
– Countries
– Platforms

Requesting the statistics of the shortened URL results in the following statistics for:

 

Screenshot of the inject asking for credit card details
From an infected system, Zeus Panda will inject extra code into a website. Once the code is injected into one of the targeted web pages, an extra form is added for creditcard information. For example, Coolblue’s webshop page would look like this, clunky and unfinished. Please note that Coolblue has no control over the fact that criminals attempt to inject code into their website from infected machines.

coolblue_main

Zeus Panda Banker web inject

EDIT: the total click count for both domains has increased to a total of 66 thousand, even though both ZIP-files are not available anymore.

Indicators of Compromise
—Dropper—
hxxp://partytimeevents.nl/contactgegevens%2012_2017_10_00_.zip (compromised website)
hxxp://stegengaweb.nl/files/contactgegevens%2012_2017_10_00_.zip (compromised website)
hxxp://axprofessional.it/onenl.exe

—Command-and-Control—
hxxps://avimart.ru/3inexowtoqiyzlonyunku.dat
hxxps://astronatal.ru/2odirnaogfaugdoxiwoex.dat
hxxps://abci.ru/1yhubydnopyakleqinyyx.dat
185.224.133.57 (SSL connection)

—External panel for injects—
hxxps://adsfun.club/

—Hashes—
contactgegevens 2012_2017_10_00.zip
MD5: aefc0fe15836165291cb66eac5ffd177
SHA256: 588e31ac96bd6318f787602e87f86b75d4b5537679e11ba5a509589148033275

contactgegevens 12_2017_10_00_.js
MD5: deb9a0aa69270a0b263b80ed13880b24
SHA256: eb65b1d5f5b3ccc263a4984275c084b63b0a262a87d55887d6a4d744a75e4112

onenl.exe
MD5: 4ac38a4efa276f8d64c1ed39a53e7ab8
SHA256: e556273db50d4588d7e4b5183d06d39b0ebedbb094fc2a39b59416212c829324

Fox-IT debunks report on ByLock app that landed 75,000 people in jail in Turkey

The Turkish government has been actively pursuing the prosecution of the participants of the Gülen movement in what it calls “the Fetullahist Terrorist Organization/Parallel State Structure (FETÖ/PDY)”. To this end, the Turkey’s National Intelligence Organization (Millî İstihbarat Teşkilatı or MİT in Turkish) has investigated the relation of a publicly available smart phone messaging application called ByLock to “FETÖ/PDY”, which is alleged to have been used during the failed coup attempt in Turkey on July 15, 2016.

The MİT is reported to have identified 215,092 users of the ByLock. Of which approximately 75,000 were detained. In an attempt to link a user of ByLock to a real person, the MİT has written a report on its findings which concluded that “ByLock has been offered to the exclusive use of the ‘FTÖ/PDY’ members”.

However, the investigation performed by Fox-IT contradicts the key findings of the MİT. Fox-IT also discovered inconsistencies in the MİT report that indicated manipulation of results and/or screenshots by MİT. What is more, Fox-IT found that the MİT investigation is fundamentally flawed due to the contradictory and baseless findings, lack of objectivity and lack of transparency.

Overall, Fox-IT concluded that the quality of the MİT report is very low, especially when it was weighed against the legal consequences of the conclusions which is the detention of 75,000 Turkish citizens.

This blog contains the conclusions of Fox-IT’s expert witness report. You can also download the full report of Fox-IT and the technical MİT report. The translated version of the MIT report will be made available later.

Reports

Fox-IT’s Expert Witness Report can be downloaded here.

md5: 3dac076d4e0d9d8984533bc04be336a7
sha1: 450ba8665d3a508d569bbc7ec761e9793e42d9c6
sha256: 7dbc402b8e03c311245814fb74dff699330d459f2067ecd574974538086caa7e

MIT’s Technical Report can be downloaded here.

md5: a9f18e08db62ef1c1f71101d37589157
sha1: 68a86e7b8b78c9d1493cb63318dba1f09cc62437
sha256: 17768d91bdae3e78499cb20214bf83abe49948a5d5f41c1aa35a1d1561dd0e62

Conclusions

1. What is Fox-IT’s opinion on the investigation methodology used by MIT in the ByLock investigation?

Multiple key findings from the MIT investigation were contradicted by open-source research conducted by Fox-IT and other findings were shown not to be supported by the evidence presented by MIT. Furthermore, the MIT investigation lacks in transparency: evidence and analysis steps were in many cases omitted from the MIT report. Multiple findings (that could be verified) were shown to be incorrect, which leaves the impression that more findings would proof to be incorrect or inaccurate if they could only be verified.

Fox-IT finds the MIT investigation lacking in objectivity, since there is no indication that MIT investigated the alternative scenario: namely that ByLock has not exclusively been offered to members of the alleged FTÖ/PDY. Investigating alternate scenarios is good practice in an investigation. It helps prevent tunnel vision in cases where investigators are biased towards a predefined outcome. Fox-IT’s examination of the MIT investigation suggests that MIT was, in advance, biased towards the stated conclusion and that MIT has not shown the required objectivity and thoroughness in their investigation to counter this bias.

Fox-IT concludes that the MIT investigation as described in the MIT report does not adhere to the forensic principles as outlined in section 3.1 of this report and should therefore not be regarded as a forensic investigation. The investigation is fundamentally flawed due to the contradicted and unfounded findings, lack of objectivity and lack of transparency. As a result, the conclusions of the investigation are questionable. Fox-IT recommends to conduct a forensic investigation of ByLock in a more thorough, objective and transparent manner.

2. How sound is MIT’s identification of individuals that have used the ByLock application?

The MIT report contains very limited information on the identification of individuals. Fox-IT has shown that ByLock user accounts are, on their own, difficult to attribute to an individual: it is easy to impersonate other individuals when registering a ByLock account and MIT is limited to an IP address from the ByLock server log to identify individuals. Attributing this IP address to actual individuals is not straightforward and error-prone; therefore, possibly leading to identification of the wrong individuals as ByLock users.

Fox-IT is unable to assess the soundness of the identification method, since the MIT report does not provide information on this method. The omission of a description of this method is troubling. Any errors in the method will not be discovered and the reader is left to assume MIT does not make mistakes. While transparency is one of the fundamental principles of forensic investigations, this critical part of the investigation is completely opaque.

3. What is the qualification of soundness on MIT’s conclusion regarding the relation between ByLock and the alleged FTÖ/PDY?

The conclusions and findings of the MIT report were examined by Fox-IT. It was shown that the argumentation is seriously flawed and that seven out of nine stated arguments are incorrect or questionable (see conclusion 6.1). The remaining two arguments are, on their own, not sufficient to support MIT’s conclusion. As a result, the conclusion of the MIT report, “ByLock has been offered to the exclusive use of the members of the terrorist organization of FTÖ/PDY”, is not sound.

4. Are there any other issues identified by Fox-IT that are relevant to the ByLock investigation?

Fox-IT encountered inconsistencies in the MIT report that indicate manipulation of results and/or screenshots by MIT. This is very problematic since it is not clear which of the information in the report stems from original data and which information was modified by MIT (and to which end). This raises questions as to what part of the information available to MIT was altered before presentation, why it was altered and what exactly was left out or changed. When presenting information as evidence, transparency is crucial in differentiating between original data (the actual evidence) and data added or modified by the analyst.

Furthermore, Fox-IT finds the MIT report implicit, not well-structured and lacking in essential details. Bad reporting is not merely a formatting issue. Writing an unreadable report that omits essential details reduces the ability for the reader to scrutinize the investigation that lead to the conclusions. When a report is used as a basis for serious legal consequences, the author should be thorough and concise in the report as to leave no questions regarding the investigation.
Fox-IT has read and written many digital investigation reports over the last 15 years. Based on this experience, Fox-IT finds the quality of the MIT report very low, especially when weighed against the consequences of the conclusions.

FAQ about PETYA/GOLDENEYE/PETR outbreak

Revision history:

  • 29th of June, 2017 18:00 (UTC +2) – Update 2 (current) – Added Q11
  • 28th of June, 2017 22:00 (UTC +2) – Update 1 – Initial FAQ

Q1 Is the Petya attack still in progress?
A: The initial attack vector appears to have been the accounting software M.E.Doc, for which a malicious software update was pushed, that was executed by clients in an automated fashion. Multiple organisations confirmed that this was their initial infection vector. After the initial infection vector Petya can utilize different kind of spreading mechanisms:

Using the EternalBlue and EternalRomance exploits, which are both exploits of the NSA that were published on the 14th of April 2017 by the Shadow Brokers. These exploits can be used to gain unauthorized access to remote Windows systems and execute malicious software with administrative privileges. Using a variety of methods, both legitimate and illegitimate. The following 4 steps are followed by the malware to spread itself:

  1. Tries to find credentials:
    • Method 1: Uses a custom tool to extract credentials from memory (code similarities with MimiKatz and accesses Windows LSASS process)
    • Method 2: Steals credentials from the credential store on the infected systems
  2. Makes an inventory of the local network for other machines. If found, it checks whether port 139 or 445 is open
  3. Checks via WebDAV whether the enumerated systems have already been infected. If this is not the case, it will transfer the malware to the other systems via SMB;
  4. Utilizes PSEXEC or WMI tools, to remotely execute the malware.

Please note that the initial infection vector of the M.E.Doc update (and a related watering hole attack on a Ukrainian website) were cleaned. However, Petya can still spread to the following networks for a limited amount of time, based on the functionality outlined above:

  1. The local network (reserved IP spaces);
  2. To remote networks of third parties that are directly connected with the networks that contain systems that are already infected with Petya.

Q2 Which attack vectors are used to enter internal networks of organizations?
A At the moment the first infection method that has been observed in the wild concerns the infected update from M.E.Doc. After initial entry into an internal network of an affected organization has been obtained, different spreading methods are used to further infect systems. These methods include the NSA exploits EternalBlue and EternalRomance in combination with harvesting and reusing passwords to perform remote command execution (with psexec and WMI) on other systems.

Q3 Are only companies affected  that use M.E.Doc?
A No, the attack initially targeted organizations that were using M.E.Doc, but the worm also spread to other (connected) organizations that were not related to M.E.Doc.

Q4 How is it possible that I became infected with Petya, while being full up to date and having all patches installed?
A: The Microsoft patch MS17-010 protects Windows systems against direct infection by the EternalBlue and EnternalRomance NSA-exploits. However, Petya includes additional methods to spread to Windows systems.

Most notably, the Petya malware can extract local Administrator and domain credentials from systems that are initially infected (for example because these systems were not patched). Subsequently, the malware can leverage these administrative credentials in combination with legitimate Microsoft tools and protocols (PSEXEC and WMI) to infect fully patched Windows systems.

Q5 How can I check if my organization is at risk for the Petya attack?
A Checking if you are at risk for this attack involves multiple actions, due to the fact that the attack itself uses different methods to propagate within networks. The following actions can be performed to identify potential vulnerable machines within the network:

  • Perform a network portscan to identify systems on which the TCP ports 139 and 445 are open. The more machines that are accessible on these ports, the more potential risk of the attack spreading to large amounts of systems within the network.
  • Perform a vulnerability scan to identify machines which are missing the MS17-010 (and the KB2871997) patch. If the patches are missing, the identified systems are vulnerable to the one of the spreading and infection methods used by the malware.
  • Perform an inventarisation of administrative credentials to identify if there are passwords shared between multiple machines. If this is the case, the systems which can be accessed using these administrative credentials are vulnerable to one of the spreading and infection methods used by the malware.
    • The most important accounts to focus on during this inventarisation are accounts with elevated privileges such as local Administrator accounts and  domain accounts with local administrator privileges.

It is important to consider that the infection, privilege escalation and lateral movement techniques used by the Petya malware are also frequently used during penetration testing on internal networks. It is therefore advised to review previous reports that followed internal penetration tests to get a quick overview of relevant vulnerabilities and to ensure that penetration tests on the internal networks are performed periodically.

Q6 We have infected machines what can we do to recover them? Should we pay the ransom?
A The email address that was used by the attackers to receive payments and release decryption keys has been blocked by the email provider. This makes it impossible for the actor(s) behind the Petya malware to confirm the payments and return the decryption keys to its victims. It is therefore not recommended to pay the ransom of $300 (or the equivalent in the Bitcoin currency) as requested by the malware authors.

Please note that after a system is infected, the malware attempts to spread before it is rebooted and the encryption process is started. Consequently, if a system is infected with Petya, but has not yet been rebooted or the fake CHKDSK process has not been completed, it may still prove possible to (partially) recover data from the infected system.

Q7 Do you know anything about the target of the Petya attack or the actors behind it?
A One of the few confirmed facts is that initially infections occurred due to an infected update from the Ukraine based company M.E.Doc. The software of this company is both broadly and mostly used by organizations in the Ukraine. These organizations within the Ukraine were thus initially targeted by the Petya attack.

This fact, combined with some of the characteristics of the attack, have led to extensive speculation in regard to the actors behind the attack (of which the grugq provides an extensive overview). However, at the moment there is no definitive public evidence to attribute the attack to a specific actor. The investigation into the purpose of the attack and the actors behind the attack are still being actively investigated by Fox-IT and many others.

Q8 How does the Petya attack differ from the Wanacry/Wannacrypt attack?
A This Petya attack seems to be more targeted than Wanacry. While WanaCry included functionality to scan for vulnerable systems on the Internet, the Petya attack primarily targets other systems within the restricted IP spaces of affected networks.
One of the few similarities between Petya and Wanacry concerns the usage of the SMB exploit EternalBlue, which is an exploit that was originally used by the NSA and was subsequently leaked by the Shadow Brokers. This is the only spreading vector of Petya which can be stopped and prevented by installing the MS17-010 patch. The other spreading vectors cannot be fully reduced by patching the systems, although installing the KB2871997 patch can reduce the impact of the other spreading vector.

In addition to EternalBlue, Petya includes further methods for spreading using lateral movement techniques such as credential re-use, PSEXEC and WMI. These techniques, which are often used in manual attacks by advanced attackers as well as during penetration tests on internal networks, have now been adapted and incorporated into an automated attack by the attackers in the Petya malware.

In regards to the encryption of the files Petya and Wanacry differ in the way that the system is rendered inoperable. Petya, in addition to encrypting individual files also encrypts critical operating system components thereby rendering the system inoperable after a reboot. The encryption of the individual files differs due to the way that the files are encrypted as well as the file types that are targeted.

Q9 I have heard rumors about an antidote or kill switch, is this true?
A Petya does not have a remote killswitch in the same way as was present in Wanacry. That is, there is no universal way to stop all Petya infections from occurring. A more limited and local way to prevent the Petya malware from spreading does exist, which is also referred to as a “killswitch” or an “antidote”.

This local antidote involves placing a file called “perfc” or “perfc.dat” in the C:\Windows directory. The reason why this works is because Petya checks if that file exists before infecting a vulnerable system. If the file exists, Petya won’t infect the system. Please note that Petya actually checks for a file with the same name as the filename that it was started from. So if the Petya file is renamed to “example.dll”, subsequent variants of that strain of the Petya malware will actually check if C:\Windows\example” exists, instead of “perfc”. It just so happens to be that “perfc” is the filename of the main variant that’s currently spreading.

Q10 Are the patches for Wanacry and Petya automatically installed by Windows Update?
A On supported operating systems the patch can be installed through the Windows update mechanism. If Windows update has been configured to update automatically, these systems should have been updated with MS17-010 several months ago. However, this is not the case on unsupported operating systems such as Windows 2003, XP and 8. Microsoft has released patches for these operating systems that need to be downloaded and applied manually.

Q11 Will Petya encrypt network drives as well?
A In the regular file encryption part of Petya, it will try and encrypt files on every disk drive available to the victim machine. Notably, it will only encrypt local hard drives, and not network drives that are mounted as a hard drive. It does this by checking which type of drive it is, and only encrypt drives that is a fixed media, for example a hard disk drive or flash drive.

Liveblog: Huge Petya ransomware wave

Revision history:

  • Update 2 (current): 28th of June, 2017 22:45 (UTC +2) – Added Snort rule for detection purposes
  • Update 1: 27th of June, 2017 18:04 (UTC +2) – Initial post

A new variant of the Petya ransomware started to spread havoc within various companies around the world the 27th of June 2017 . The first news came from the Ukraine where at least two energy companies were struck.

WannaCry

This Petya variant comes only weeks after the WannaCry hack made headlines around the world where hundreds of thousands devices were infected.

This variant of Petya has more spreading methods than WannaCry (in specific PSEXEC and WMI) but does share at least one of the exploits, namely: EternalBlue, which is an exploit leaked by ‘The Shadowbrokers’ and originally used by the NSA.

The Petya ransomware was in the news earlier this year for encrypting the entire hardisk rather than only files on local and remote drives, something which is more common with other ransomware.

Source

Cisco Talos reports that the infections started in Ukraine following the auto-update feature of software by the Ukrainian company Me-Doc. Attackers likely got access to the Me-Doc update servers, using the update feature of the software to infect all their, mostly Ukrainian customers. This explains the disruptions observed within various Ukrainian companies, including airports, hospitals and other vital infrastructure. This supports what Fox-IT is observing, affected companies have business in Ukraine and observed initial Petya activity from those networks.

Because of the various spreading mechanisms of Petya the ransomware managed to reach companies in other countries, most likely as a result of existing network connections between (branch) offices or suppliers.

Infection

When a computer gets infected with this specific version of Petya, it starts to encrypt files on the local machine and also attempts to spread across the local network to other machines.

After a number of hours, the infected client is restarted and is faced with a ransom screen. At this point it is no longer possible to start the Windows operating system. On this ransom screen a bitcoin address is shown, together with a string of text that uniquely identifies this infection as well as the email address to contact the authors when the payment has been made.

Infection vector

Where WannaCry was scanning random IP addresses on the internet, and in that way infecting other companies, this version of Petya is only scanning internal hosts. This means that there must be a different initial infection vector. What this vector exactly is, is unknown for the time being. If the ransomware is run on a Windows Server, it will attempt to spread to all connected clients by looking at DHCP-leases, to greatly improve spreading speed within a network.

Prevention

The following measures can be taken to limit the chances of infection:

  • Apply Windows update MS17-010
  • Disable the outdated protocol SMBv1
  • Limit the use of accounts that are ‘local administrator’
  • Make back-ups and verify that they can be restored

Detection

Currently the Fox-IT CTMP network module is able to detect a number of the spreading methods of Petya and work is being done to identify other methods of spreading. Among others the following rule has been developed:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"FOX-SRT - Trojan - Possible Petya ransomware connection"; flow:established,to_server; uricontent:"admin$/"; content:"User-Agent: Microsoft-WebDAV-MiniRedir/"; http_header; classtype:trojan-activity; threshold:type limit, track by_src, count 1, seconds 600; reference:url,https://blog.fox-it.com/2017/06/27/liveblog-huge-petya-ransomware-wave/; sid:21002170; rev:1;)

FAQ on the WanaCry ransomware outbreak

Last updated: May 16th 2017

A ransomware variant known as WanaCry/WanaCrypt0r has spread on a massive scale around the world since the 12th of May 2017. For more information about the context with regards to this WanaCry variant, see also our earlier blog. The section below outlines the frequently asked questions and corresponding answers.

Q: What makes this ransomware variant so dangerous?
A: This variant of WanaCry posesses the capability to spread itself as a so-called worm, beside the fact that the ransomware starts encrypting possible important data on systems. This means that the initial infection in a network is possibly not only system that could be impacted, but potentialy a large amount of systems in the internal network as well. This might result in your business processes coming to a grinding halt.

Q: What was the initial infection vector for the ransomware outbreak?
A: As there is no evidence that the initial infection vector is email, after 72 hours of research by the security community, Fox-IT believes the infection vector is more likely to be vulnerable machines directly exposing SMB to the internet.
At the moment it appears that the only confirmed infection vector is the usage of the ETERNALBLUE SMB exploit.

Q: Which versions of Windows are vulnerable?
A: The SMB exploit works on all versions of Windows, which have not yet been patched by MS17-010 on the 14th of March 2017, except for Windows 10 and Windows Server 2016, as they are already protected in the default configuration.

Q: What about Windows XP?
A: Microsoft has also released a patch for the unsupported operating systems Windows XP and Windows Server 2003.

Q: Are we safe from WanaCry if we apply the security update to Windows Server 2003?
A: Yes, but the patch KB4012598 applies specifically to this SMB exploit, known as ETERNALBLUE. However, similar NSA exploits, leaked by the Shadow Brokers, for vulnerabilities in Windows Server 2003 and Windows XP were published that lead to remote code execution (RCE). This includes the ERRATICGOPHER exploit for SMBv1 and the ESTEEMAUDIT exploit for RDP, which could be repurposed by malicious actors to create the next ransomworm.

Q: How many endpoints are affected?
A: The sinkhole statistics currently show a total of 160,000+ infections, this amount is still rapidly increasing.

Q: Should we block the ‘kill-switch’ domain on our firewall/proxy?
A: No you should not. When the malware is capable of reaching the ‘kill-switch’ domain it will not further spread the malware. Please note that when you block this domain, it will in fact continue spreading both internal and external.

Q: Is the kill switch domain being monitored (counting infections, origin infections)?
A: Yes the sinkhole statistics can be found here.

Q: Do we expect new attacks with the same Modus Operandi (MO)?
A: This is very likely, as this is a lucrative way of earning money for criminals. It is unknown at what moment in time a new attack will start and we do not have indications at this point in time that another campaign is scheduled.

Q: Where can I find the ‘kill switch’ domain?
A: Two ‘kill-switch’ domains have been seen in the wild:

iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com
ifferfsodp9ifjaposdfjhgosurijfaewrwergwea.com

Q: Is the malware persistant and will it become active after a reboot of the end point.
A: Yes, a registry run-key is added to the registry:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\\ = “\tasksche.exe”

Q: How can I check if an endpoint was infected?
A: Though there is no specific script there are several specific indicators for this ransomware campaign which can be used to detect compromised machines, such as:

HKLM\SOFTWARE\WanaCrypt0r\\wd = “”
HKCU\Control Panel\Desktop\Wallpaper: “\@WanaDecryptor@.bmp”

Q: Is CIFS also vulnerable?
A: CIFS is a dialect of the SMBv1 protocol, and is impacted by this vulnerability.

Q: What impact will disabling SMB v1 have on end users?
A: Please note that this might differ depending on the situation. It is highly recommended to follow the best practices with regards to applying patches, meaning that a thorough impact assessment needs to take place to determine the actual impact of disabling SMBv1. Please note that at least those systems that could solely communicate via SMBv1 will be impacted, for example an old file sharing system.

Q: What are Anti-Virus vendors doing about this?
A: It seems logical that most cybersecurity companies are currently working on finding out all of the details that are related to this attack. It also seems very likely that all cybersecurity vendors are creating prevention and detection capabilities. Though new detection or prevention capabilities can only be applied if updates for these products are being downloaded and installed. We would not encourage customers to focus and wait on these vendors to prevent these kind of attacks but rather focus on installing the Microsoft update (MS17-010) that will prevent the spreading completely.

Q: What if infected laptops are currently offline because people are enjoying their weekends and are returning on monday?
A: It depends on which stage the infection is in the victim machine. If the machine has already been infected and was half way during the infection then it is very likely that the victim machine will continue encrypting files and start spreading when it will become active again. Therefor we strongly suggest to install the Microsoft update (MS17-010).

Q: What are the chances that a new campaign will be launched with more or improved functionality?
A: Based on our experience it is very likely that the same or other attacker(s) will start launching new campaigns rather sooner then later. We expect that they have learned from the small mistakes they have made in the initial version, such as not registering the ‘kill switch’ domain. They could also improve the malwares functionalities that can bypass current prevention or detection techniques. Therefor we strongly suggest to install the Microsoft update (MS17-010).

Additionally, the exploitation of this vulnerability will serve as an example for other (cyber) criminals seeking to achieve similar goals, so called copycats.

Q: Do we have to block the the ‘kill switch’ domain in the firewall, or other security controls like Proxy Servers?
A: NO! Do not block access to the unique ‘kill switch’ domain as infected clients will then start using the SMB exploit against reachable machines that are vulnerable.

The unique ‘kill-switch’ domain has been registrered by a known security researcher. By doing this the ransomware and the spreading mechanism used in the current malware campaign will not function.
If you block access to this domain then an infected client will start encrypting all of your files and will start spreading to available vulnerable devices.

Q: Does the ‘kill-switch’ domain need a valid HTTP connection or is resolving this domain name enough for the malware to stop functioning?
A: Yes, the ‘kill-switch’ domain does need a valid HTTP connection to a webserver listening on port 80. If the malware is not able to make a succesfull connection on port 80 it will start the ransomware and spreading process.

Q: Is the Linux Samba equivalent also vulnerable?
A: No, the Linux Samba protocol is not vulnerable to this exploit, only the Microsoft SMB protocol, without the latest Microsoft patch (MS17-010) installed, is affected.

Q: There are some reports of WannaCry variants with no ‘kill-switch’ functionality, have you seen this?
A: Yes, Fox-IT has this variant. It seems that someone modified the original malware sample. Likely with a common tool like hexedit. There has been another sample where the ‘kill switch’ domain has been completely patched out, thus resulting in a corrupt binary. Fox-IT is actively monitoring for new versions of the WanaCry ransomware.

Q: Has the ransomware’s implementation of the encryption process been looked at, to see if files are recoverable?
A: The crypto that is used in the malware seems to have been implemented in an unbreakable way. At this point decryption does not seem possible.

Q: Is there anything known about what group is behind this ransomware campaign?
A: Fox-IT, like other security researchers, is investigating connections of WanaCry to other known groups.