CASSIDIAN CyberSecurity Blog

2014/07/11

The Eye of the Tiger

Cyber espionage has been a hot topic through the last years. Computer attacks known as “APT” (Advanced Persistent Threat) have become widely reported and emphasized by the media, damages are now considered as real and strategic trends are moving in cyber defense.

Today, we decided to release publicly information on a specific group of APT attackers known as “Pitty Tiger”. This information comes directly from investigations led by our Threat Intelligence and enlights the activities of a structured organization working in the APT field.

You can get more information in our Whitepaper.

Continue reading...

2014/06/20

APT Kill chain - Part 4 : Initial compromise

This blog post is part of a series on APT killchain. In the previous step, we've seen how the attacker used reconnaissance techniques to collect data on its target. Now we will focus on the initial compromise.

At this stage, the APT attackers have a solid knowledge of their target and its key employees. The attackers have everything they need to start looking for an entry point to the company’s network and establish one or several permanent backdoor accesses.

Continue reading...

2014/06/03

Local root vulnerability in Android 4.4.2

Google has just released Android 4.4.3 version in AOSP (Android Open Source Project). The Funky Android website has published the whole changelog between versions 4.4.2 and 4.4.3. 

This time, it seems Google has fixed an old vulnerability, allowing to elevate privileges from an application with a few permissions to root, on any Android version supporting Android Secure External Caches (ASEC).

Continue reading...

2014/05/23

APT Kill chain - Part 3: Reconnaissance

This blog post is part of a series on APT killchain. On this blog post we focus on the reconnaissance step. All the information written here comes directly from our observations and experience on APT incident handling and APT pentest simulations.

Time for action has started. The attackers have chosen one target, now they have to start working on it.

It does not mean they will rush into the attack as soon as they have a target name. There is no interest in blindly attacking a company’s servers. Like in a lot of other subjects, a good attack is an attack which has been prepared carefully.

The longer the attackers spend time in knowing their target and its online presence, the easiest it will be to find efficient ways to penetrate that company’s systems. This is a bit like penetration testing. If you have ever been involved in such an activity, you know that there are different kinds of pentests, mostly depending on the perimeter to evaluate. Some pentests will cover a narrow part of a company’s network infrastructure (web server for example) while some others will cover a wider area. In the widest case (probably the most interesting one if you have enough time), such a pentest will consist of getting only a company’s name and digging for any vulnerability one can find. The pentester has to find several ways to attack the system, and penetrate it successfully before showing his results to the system’s owner.

After all, technically speaking, in which aspect is the beginning of an APT attack different to a penetration test?

The penetration tester will try to find as many vulnerabilities as he can, to report it to the customer. The APT attacker will try to find one or several vulnerabilities to penetrate the system. The APT attacker won’t search for all the vulnerabilities: one or two are enough for him.

The first phase of an APT is similar to the first phase of a penetration testing service; it is the reconnaissance phase, which can also be called “information gathering” phase.

Continue reading...

2014/05/07

APT Kill chain - Part 2 : Global view

Last week we defined what an APT is. As we have seen, there are different definitions, and I bet nearly all companies working on APT incident handling do have their own definition.

What every experienced APT incident responder agrees on, is the way APT attacks are conducted.

The APT kill chain can be presented with some variations, depending on the detail level you want to show, yet its content is always the same. We chose to show here the easiest kill chain we could draw, not to panic anyone with technical details (yet). We will really go deep into every process of an APT attack in this serie of blog posts, yet we believe it is good to start explaining it from a distant point of view.

Continue reading...

2014/04/28

APT Kill chain - Part 1 : Definition

Today we decided to release a serie of blog posts regarding the APT kill chain, in an effort to share our experience and knowledge on this hot topic.

For starters, “APT” stands for Advanced Persistent Threat.

Some people do not use this word at all, considering that this acronym is just a buzzword, created by some creative marketing wizard –or even a team of wizards- to describe a computer attack aimed at companies. These three words do strike the spirit of anyone who is inexperienced in computer security and immediately raise fear, not to mention terror. A sure thing is that it does not leave anyone indifferent. People do imagine a lot of different things behind these words, depending on their knowledge and experience. It basically goes from “well, another attack” to “attackers are everywhere in the system, they’re inside all the computers, ALARM ! ALARM ! HELP !”

Yet, there have been different definitions for APT, which we will now explore briefly.

Continue reading...

2014/04/18

HINT Project will help to Detect Hardware Trojans in the Next Future

Hardware Trojans are considered to be an emerging threat for critical infrastructures. We are going to develop Hardware Trojans detection method in the European funded HINT project, that is described below.

Continue reading...

2014/04/10

Bitcrypt 2 - Financial aspects

Some weeks ago, we have been blogging about a new ransomware called BitCrypt.

To sum it up shorty, we had found a new ransomware which encrypted all pictures on the machine it infected, and asked the user to pay a ransom to get the files back.

While we do not usually work on that kind of malware, preferring to dive into APT malware, we spent several hours on this one because of an indirect impact on a friend.

So we started reverse engineering the binary, and found a flaw in its encryption implementation, which we managed to break and get the encrypted files back.

During the following week, the decryption tool we released publicly helped some victims to successfully decrypt their images. That was before the BitCrypt author released a new version of his ransomware: Bitcrypt 2. We were curious enough to have a look on it.

Continue reading...

2014/03/17

The Active Directory Permissions Analysis Challenge

Analyzing permissions in Active Directory is a quite difficult task for Active Directory administrators.

First, because the Active Directory delegation capabilities are extremely powerful and could lead to highly complex hierarchy which is then hard to check.

Second, because the built-in tools are limited: The permissions are displayed in the properties of each object, the effective permissions for a user on an object can be calculated but the usage is limited in large environment and provide approximated and sometimes inaccurate results (See Microsoft KB 933071). Other alternatives will also be describe in this post.

Third, because the company may not have a defined delegation model, or may have an old one defined at the forest or domain creation. In a perfect world, every Active Directory "should" have a defined (and documented) delegation model which "should" evolve as the Enterprise evolves (Teams reorganizations, Companies acquisitions, Partnerships...). In the same perfect world, Active Directory administrators should be able to check if the current delegations in Active Directory are in accordance with the defined delegation model, and modify either part accordingly to the desired state.

Last, because this task is a shared responsibility of both the Active Directory service administrators (for the top-level delegations) and Active Directory data administrators (See Microsoft Best Practices for Active Directory Delegation)

Continue reading...

2014/03/11

Prefetch file parser in pure Python

During our forensics investigations regarding Microsoft Windows operating systems, extracting information from the several Prefetch files can be pretty useful in many cases. Indeed, these files contain, amongst other values, the last time the program was launched, a counter of how many times it has been used, the full path where the EXE file was, etc.

Unfortunately, the best tool we have found so far is pf from TZWorks LLC but it is closed-source. And even if there are some documentations on the Internet about those files, they were either incomplete or we found mistakes in them. All things together lead us to implement an opensource parser in Python for those files.

Today we are releasing our tool and this blog post is going to describe the Prefetch file format in details.

Continue reading...

2014/03/06

Disass, script reverse engineering for dummies

On our daily job, we have to manage malicious piece of code every day. On this domain, we historically had two approaches: dynamic analysis on our own sandbox or manual and static analysis with reverse engineering skills. Because static analysis can be boring for known samples, we developed a framework to automatically analyzing malware. We released Disass some time ago and gave a short explanation of the tool during Botconf 2013 in Nantes, France. We received many comments and questions so we thought a blog post could help explain the way Disass is working.

Until last year, in order to automate static analysis, we wrote scripts (often in Python because Python is cool) that can highlight and extract relevant informations from malicious binaries. But these scripts are seldom robust and their behaviour is only guaranteed on the sample the manual analysis has been done.

That's precisely why we wrote Disass. Basically, Disass is a binary analysis framework written in Python to ease the automation of malware reverse engineering. The purpose of Disass is to automatically retrieve relevant information in malware such as the C&C, the user agent, cipher keys, etc. By the way, Disass allows to understand static analysis in human readable code

There are two types of disassembler algorithms: linear and flow-oriented. Disass is based on a linear disassembly module named "diStorm", which is a lightweight, easy-to-use and fast decomposer library.

A linear disassembly uses the size of the disassembled instruction to determine which byte should be disassembled next, without regarding flow-control instructions. The interesting point in a linear disassembly is that it's made for iteratively work on a block of code. The bad point is that linear disassembly is unsuitable to distinguish code and data. It can be partially circumvented with the use of a tool such as pefile.

Let's go deeper: to understand how to use the framework, the example below shows the usage of a Disass script on a real malware called "Trojan.Letsgo". This malware was made famous by the APT1 report from Mandiant. Further information on this malware can be obtained on http://www.cyberengineeringservices....

Continue reading...

2014/02/20

Bitcrypt broken

Ransomware is nothing new. You might already have heard about it already, since it is a kind of fraud which can impact anyone and do severe damages. Some ransomware forbid you to access to your computer, while some others do crypt files on your system so that you cannot open them anymore.

No matter the action this kind of malware does, the victim always ends with a frightening message, which tells him to pay a ransom to get the computer access or data back.

People do not react to this message the same way. It all depends on their computer knowledge and on the value of the presumably "lost" data. People get stuck in front of the screen, wondering if they should pay or not. They think of trying to launch anti-virus products, but they are afraid the operation would definitely destroy their data...

Some lucky people do not care at all: they have done regular backup of their important data on an external harddrive. Luckily enough, they disconnect that external harddrive every time they do not use it. Their data is safe, and they will just try to disinfect their computer from the malware. If they cannot do it, well, they will reinstall the whole operating system.

Continue reading...

2014/02/10

Dumping firmware out of a Z-Wave ASIC

Recently, in our team, we had to deal with Z-Wave equipments, including the RF protocol that we handled with a Software Defined Radio (SDR) and GnuRadio. The purpose of this article is not to go into details on the radio part as it will be done on a later publication. Nevertheless, during our researches, we had to extract the firmware from the Z-Wave ASIC that was in use.

Continue reading...

2014/01/29

PlugX "v2": meet "SController"

In our previous blog post about the PlugX RAT, we dealt with the original version, and recapped some internal features. Back in mid 2013, we started to see a new version of the RAT in the wild, with enough differences with the previous one to be considered as a new major version. We thus called it internally "PlugX v2". Some posts from SecureList and FireEye were dealing with this new version, but none of them gave a full analysis.

In this post, we will detail the main differences and new features introduced by this version.

Continue reading...

2014/01/23

Reversible log anonymization tool

How do you inject valuable data into your test platforms? How do you provide your data to external stakeholders for investigation? Don't you have to face personal data issues?

In our missions, we have to handle customer data and they don't want us to have access to sensitive information or personal information. We don't want it either.

For instance, we sometimes need to analyze a customer's logfile that contains sensitive data such as username or internal address. We thought it could be very useful to replace real and sensitive data with anonymous tokens (with a one-to-one correspondence) without hindering analysis.

This is sometimes useful to comply with the following requirements:

  • Logs are stored for research or training purposes after the log analysis job

has been completed, and no data that allows identification of the customer should be present.

  • Privacy laws (ex. CNIL regulation in France) or regulations prevent the

customer from giving over sensitive or personal data.

So, we wrote a tool that was designed to replace sensitive fields in customer's logs with anonymized values, while generating a lookup table.

A typical process involves the following steps:

  1. This script is typically run by the customer, or by a log analyst as the first step of the log analysis process.
  2. The customer or a log analyst removes log lines relating to internal customer resources - typically, intranet websites.
  3. Analysts then work on the anonymized logs, and come up with lists of anonymized user identifiers, or anonymized IP addresses.
  4. These anonymized tokens may be looked up in the lookup table, to obtain the original value.

Here are sample commands that may be used to anonymize logs.

Sample log line:

192.168.1.1 johnsmith - [01/Jan/2000:00:00:00 +0200] "CONNECT tunnel://accounts.google.fr:443/" 200 3154 TCP_MISS:DIRECT 115358 DEFAULT_CASE <IW_srch,5.9,"0","-",0,0,0,"1","-",-,-,-,"-","1",-,"-","-",-,-,IW_srch,-,"Unknown","-","Unknown","Unknown","-","-",0.22,0,-,"-","-">

Create a file named "filters" that contains pattern to filter out access to internal resources, such as the intranet's fqdn. Use the following command to filter these out:

grep -VFf filters logfile

If you want to anonymise the first two fields (IP and user name), run the anon.py as shown

./anon.py -f 1=USER,0=SRCIP -t lookupTable.json -F ' ' -i logfile

The script has generated a lookup table in lookupTable.json with the following content:

{"0": {"192.168.1.1": "SRCIP_1"}, "1": {"johnsmith": "USER_1"}}

The script has also generated an anonymized log line as output:

SRCIP_1 USER_1 - [01/Jan/2000:00:00:00 +0200] "CONNECT tunnel://accounts.google.fr:443/" 200 3154 TCP_MISS:DIRECT 115358 DEFAULT_CASE <IW_srch,5.9,"0","-",0,0,0,"1","-",-,-,-,"-","1",-,"-","-",-,-,IW_srch,-,"Unknown","-","Unknown","Unknown","-","-",0.22,0,-,"-","-">

Find out more in the documentation folder of the repository!

Source, documentation and unit tests can be found here: http://bitbucket.cassidiancybersecurity.com/log-anon

2014/01/20

Introducing MftCrawler, a MFT parser with $i30 carving capabilities

During Incident Response missions, we have to use forensics tools either on a local system or at the company scale. For different reasons, we could not use the available MFT parsers available and we needed to do live $I30 carving as well.
So we decided to create our own. We named it MftCrawler.

MftCrawler is a MFT parser written in Lua with $i30 carving capabilities.
It can be used to parse offline MFT (saved MFT file) or Live (Windows & Linux).

When running in live mode MftCrawler can carve $i30 records and try to resurrect deleted file entries.

MftCrawler was designed with these goals in mind:

  • Simple & easy to modify
  • Fast (*)
  • Low memory consumption (*)

(*) The $i30 carving does impact the performance.

This is still a work in progress (read BETA, so bugs will happen) and several features are still missing (owner SID, non resident attribute spanning several records,...)

Source & documentation can be found here: http://bitbucket.cassidiancybersecurity.com/mftcrawler

Feedback & bug reports highly appreciated !

2014/01/06

PlugX: some uncovered points

PlugX (or Korplug, or Gulpix) is a well-known RAT involved in many APT cases. Some excellent write-ups about this malware have already been published by the CIRCL, Sophos and AlienVault. Since we met it on an incident response case back in 2012, we followed its evolution to improve our knowledge, rules and tools. We're planning to release details about this malware in a small serie of blog posts, to cover some points which have not been published yet.

This first post will cover some internals of the original PlugX malware and we'll deal with its evolution in the next one.

Continue reading...

2013/12/20

Welcome to our new blog!

Welcome to our experts’ blog !

This blog is Cassidian CyberSecurity experts’ territory, for them to share their technical knowledge with the cyber community.

According to the news as well as to our authors’ area of expertise and mood, you’ll find in this blog their thoughts about environment trends and above all their views and specific analysis: from focus on specific malware behaviour to attackers methodologies and newest discoveries.

Indeed we strongly believe in the importance to share cyber expert knowledge, to the benefit of all.