Sphinx Moth: Expanding our knowledge of the “Wild Neutron” / “Morpho” APT

The Kudelski Security Cyber Fusion Center together with the KS-CERT has been monitoring and investigating the “Sphinx Moth” threat activity since mid-2014.

When Kaspersky and Symantec released reports on a powerful threat actor earlier this year, it became clear that what they had respectively called “Wild Neutron” or “Butterfly”/“Morpho”, corresponded with the “Sphinx Moth” advanced persistent threat that Kudelski Security was investigating as well.

Now that the threat actor has been exposed, we can expect them to change their Tactics, Techniques and Procedures (TTPs). We have decided to disclose several new Indicators of Compromise (IOCs) related to “Sphinx Moth” group with a view to furthering a collective understanding of the attack methods, tools and targets, and helping enterprises detect and eliminate any intrusion into their networks.

Attacks like “Sphinx Moth” are increasing. Yet despite their prevalence and our awareness about their impact, strategies to address the risk of cyberattacks remain inadequate. It is no longer possible to work on the assumption that we can fully protect a corporate network. With the rise of advanced persistent threats, enterprises can have an intruder in their network for months or years, without even being aware of its presence.

Key findings

Our report contains the analysis of 5 new binaries, and provides 5 new command and control server IP addresses, 2 new Command and Control domains, 6 new YARA rules, 1 new tactic to regain access and a Powershell script to detect the named pipes IOC on an SCCM infrastructure.

It’s available on the Kudelski Security website: Sphinx Moth Report

Closing the Password Hashing Competition, releasing Argon2

In fall 2012, I proposed to organize an open competition in order to develop a new crypto standard for hashing passwords—be it to protect users’ credentials in web services, derive keys for disk encryption schemes, or to log in your operating system. That’s how the Password Hashing Competition (PHC) started.

Almost three years later, I’m happy to announce the first Password Hashing Competition winner, Argon2. Since Monday, specifications and public-domain code are available at https://password-hashing.net/#argon2, and on a GitHub repository:

Continue reading

Dridex static configuration extractor

Despite recent takedowns of multiple CnCs related to dridex, we still see a significant amount of Dridex samples.

To facilitate triage and extraction of IOCs, we developed a configuration extractor that is able to obtain the version and “server list” (CnC) of dridex version 120, 220 and 301.

This tool performs a static analysis by enumerating the sections, trying to deobfuscate and finally decompresses the results with aplib (thanks to @angealbertini for the python implementation of aplib).

To run the script, first you need to clone the github repository and copy the python aplib implementation (you can find the python file for aplib here: https://corkami.googlecode.com/svn-history/r522/trunk/misc/MakePE/examples/packer/aplib.py) in the same folder. Obviously, if the sample is packed you’ll need to unpack it (no need to reconstruct the imports).

See below the output on some samples:

Version 120:

dridex120 Continue reading

Crisis vs. Risk Management – know the difference and account for the unforeseeable

Account for non-obvious and unidentified risks  

Risk identification is mostly a mental process, which from data analysis (i.e., processes, past events, financials figures, logs, analytics, etc.) and interviews lead to a list of identified risks.

Whatever the volume of data, the number of interviews, the cleverness, and mental or computer calculation power applied to it, this process is bound by humans and by the complexity and chaotic nature of the world.  We will never be able to identify all the “would have never thought or imagined” risks and events, not to mention that, by virtue of nature, memory of past events fades away with staff turn-over, retirement, data loss and deletion, etc. Continue reading

Hacking Arista appliances for fun and profit

I have been playing a lot with Arista hardware lately, as we’re mainly using their products in our data center’s as Tor or Spine switches, but not only. We were already using a multi-layer switch (mls) the Arista 7150S-24 as an edge router . It’s quite uncommon to have this device in such a place but we needed it in order to route the smallest packets (cf my previous blog-post) at 10Gbit/s line-rate and it performed very well in this task. It performed so well that it became one of our main Internet routers.

The initial setup was quite simple:

  • A 10GbE interface connected to the upstream provider router.
  • Interconnection subnets for IPv4 and IPv6.
  • Two default gateways (v4+v6) pointing towards the IP-Transit provider router.
  • Public subnets (public#1, public#2) associated to different VLANs with the mls configured as their gateways.
  • IP resources announced from a VM running OpenBGPd using multi-hop eBGP sessions (v4+v6) with the provider.

Initial setup

Continue reading

Machine learning and security: who should care?

Screen Shot 2015-09-21 at 9.37.11 AM

Machine learning has been the new hot thing for a while now, and yet it’s still unclear what it’s good for in information security, if anything at all.

We wanted to know where and how machine learning can be of use in infosec, with a focus on intrusion detection. For a review of what’s being done in industry and academia, download the white paper, available here.

Special thanks to Patrica Egger, former intern at Kudelski Security, for her research into this issue.

If you’ve any question about this report, please contact me at jean-philippe.aumasson@nagra.com.

How to crack Ubuntu encryption and passwords

During Positive Hack Days V, I made a fast track presentation about eCryptfs and password cracking. The idea came to me after using one feature of Ubuntu which consists in encrypting the home folder directory. This option can be selected during installation or activated later.
If you select this option, nothing changes for the user except that data in his home folder is encrypted. I was interested to know how this process works since the passphrase for decryption is never requested. I discovered that eCryptfs is included in the GNU/Linux kernel and tools called ecryptfs-utils are used to setup the home folder encryption by the Ubuntu distribution.

After reading the code, I discovered how the encryption is performed. First a 16-byte random passphrase is generated. This passphrase will be used with AES-128 to encrypt and decrypt the data in the folder. This passphrase is stored encrypted in the file


The process of encrypting the passphrase is called key wrapping. To generate a wrapping key used to wrap the passphrase, an 8-byte salt and a password are concatenated and given as input to SHA-512. The result is hashed again 65535 times. As shown by the following figure:wrappingkey
The 16 first bytes of the result are the wrapping key. The intermediate result is hashed one more time and the 8 first bytes of this operation represent the signature of the wrapping key. The passphrase is encrypted with the wrapping key using AES-128 and stored with the signature in the wrapped-passphrase file as shown here:


To unwrap the key the process is similar, the salt and the password are hashed 65536 times.


The result is hashed one more time. If the 8-byte signature obtained matches the one stored in the file then eCryptfs detects that the correct wrapping key has been generated. Thus it can unwrap the passphrase for file decryption.

From an adversary’s point of view, to recover the passphrase, the naive approach would be to brute-force the passphrase with encrypted data. However since it is randomly generated over 16-bytes the brute-force approach is not practical. The adversary can also try to brute-force the password used during the key wrapping and thus he would be able to generate the wrapping key and recover the passphrase. He could use precomputed dictionaries or rainbow tables over the signature to recover the password but as a salt is used in the wrapping process this makes such attacks much more difficult.

At this point, I noticed that, for Ubuntu systems, the password used in the wrapping process is directly the login password. This explains why no further information is asked when performing home folder decryption. It means that an adversary who is able to crack the wrapping password will not only obtain the passphrase but also the user password. Next I looked how the salt is generated since it is not stored anywhere in the wrapped-passphrase file. I finally found in the code that ecryptfs-utils is looking for a salt in the configuration file


If the file does not exist, a default value of 0x0011223344556677 is used. This behavior had already been noted previously.

For a system using eCryptfs, as the configuration file is stored in the (now encrypted) home folder it cannot be found and so the default salt value is used to decrpyt the home folder.

In practical terms this means that, for a system to use this version of eCryptfs the salt value used must be the default value. If not, the initial encryption, using a salt from ~/.ecryptfsrc would never be decrypted correctly as, now unable to find the config file, eCryptfs would apply the default salt at the moment of decryption.
dictionnaryattackCleary a precomputed dictionary attack or a rainbow table attack can be mounted against such a system in order to crack the user passwords. To set-up such an attack, I looked at my favorite cracking tool: John the ripper (JTR) and I discovered that the algorithm was already implemented in the 1.8.0-jumbo version. The format is


where the pink value is obviously the salt and the green value is the signature corresponding to the password you want to crack.

I also noticed a Python script ecryptfs2john.py in JTR which directly read the wrapped-passphrase file and convert it to the correct format. The algorithm is also implemented in hashcat. As a proof of concept, I computed a dictionary of 14 million signatures based on the famous rock you dictionary. It took me about one month on my personal computer. But with this dictionary it is now possible to reverse a signature with a single look up assuming the password was in the rock you list of password. This dictionnary is available at https://github.com/kudelskisecurity/ecryptfs-dictionary-v1.

Of course we notified the ecryptfs-utils developers about the problem with Ubuntu distributions, a CVE was opened and quickly corrected. They issued a new file format for the wrapped-passphrase file. It now starts with 0x3a02. The salt is generated from /dev/urandom/ and stored in the same file by default. The old version files are automatically converted after the update and a logoff. To ensure the correction was successfully applied to your system you should check the wrapped-passphrase file. The new file contents should look like this:


Even with the correction the user password is still exposed to bruteforce attack with a randomly generated salt. However the standard Linux password hashing is 5000 iterations of SHA-512 which is easier to crack compared to the 65536 iterations of eCryptfs. As such, and due to the dual use of this password the eCryptfs implementation is a less interesting target for a password cracker. In the future it could be interesting if Argon2, the winner of the Password Hashing Competition, could be used eCryptfs.

My PHDays slides are available here.

Creative Commons License