Honey! Where is my POS??


Not a month goes by without news about another new POS (point-of-sale) malware or credit card data breach. Obviously, details of this kind of breach cannot be made public (banks, ongoing investigation, reputation …). But what do we know really about POS malware? Can we create groups of malware and relate them to groups of cyber criminals? As is the case for standard malware, we need a honeypot for POS, so we can publicly share the TTP (techniques, tactics, and procedures) of POS cyber criminals.

The goal of this post is to explain how we created a honeypot for POS with open source tools and custom scripts, and to show the results from 3 months of running a honeypot (samples, TTP, groups …).

Infrastructure (First try)

The first infrastructure was hosted in Europe and included all the tools to monitor the honeypot (in terms of host and network).


1st architecture

• We installed Moloch as a full packet capture tool, very useful when you need to drill down on packets and sessions.
• An IDS based on Suricata and the SELKS distribution, always interesting to see directly what kind of malware is beaconing to its CnC.
• We also installed mitm-proxy, a python library that can be used for different Man-in-the-middle tasks.
• A local Bind DNS, to see directly all DNS requests in a text file
• And an OSSEC agent on the host, so we can directly create dashboards on specific events (in our case RDP connections).

Continue reading

SGX dev environment setup

Intel’s Software Guard Extensions (SGX) is their latest attempt to enable secure remote computation, or the execution of trusted code on a remote computer owned and controlled by someone else. Call it cloud if you will.

Everything you want to know about SGX is in Intel SGX Explained, 100+-page from MIT. See also Joanna Rutkowska’s 2013 discussions (pt. 1 , pt. 2), and Frank McKeen’s Stanford talk (he’s one of the SGX architects at Intel).

SGX has been in the air for years, but it’s only been in Intel chips for a few months with the Skylake microarchitecture, and usable to developers (partially) thanks to Intel’s SGX SDK. So I wanted to try SGX out.

My first task was to find a laptop that supports SGX. You obviously need a CPU with the Skylake microarchitecture, and that supports SGX instructions, as this Core i5-6200U. But it’s not sufficient, you also need drivers enabling the OS to use SGX. Drivers are either chipset drivers or included in the BIOS, depending on the model. You’ll find a partial list of supported notebooks on https://github.com/ayeks/SGX-hardware along with a simple C program that uses the CPUID instruction to test for SGX support on your system (you don’t need the SGX SDK to run it).

A supported notebook not in the above list is HP’s Star Wars Special Edition Laptop (model 15-an051dx, Core i7-6500U).


Continue reading

Getting started with Erlang

Here’s a quick introduction to Erlang programming language as well as some basic examples to show you what it looks like and why you should try it !


I recently had to learn Erlang for a project with no prior knowledge of the language. In this blog post I’ll describe some of my discoveries, the resources I used to dive in and two simple examples that illustrate the power (and beauty) of Erlang.

I won’t dig deep into the description of the language itself. Some books, listed below, do it much better than me. I will, however, jump directly to the heart of the language: Erlang is a dynamically typed functional language running in a virtual machine. It was developed by Ericson and then open sourced in 1998.

Some of its awesome features are:

  • concurrency and distributed programming: this allows you (thanks to its lightweight processes) to spin a lot of concurrent processes, as shown in an example down below. Continue reading

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