Port 22

Vulnerability in French Government Tchap Chat App
April 24, 2019

A researcher found a vulnerability in the French government WhatsApp replacement app: Tchap. The vulnerability allows anyone to surreptitiously join any conversation. Of course the developers will fix this vulnerability. But it is amusing to point out that this is exactly the backdoor that GCHQ is proposing….

Congress Asks Google 10 Questions On Its Location Tracking Database
April 24, 2019

U.S. Congress has sent an open letter to Google CEO Sundar Pichai asking for more information about its Sensorvault database thats reportedly being used by law enforcement agencies to solve crime cases.

Last week, we reported a story based upon NY Times findings that revealed how using a “geofence” warrant, authorities obtain location history of all devices from Google’s Sensorvault database

'Karkoff' Is the New 'DNSpionage' With Selective Targeting Strategy
April 24, 2019

The cybercriminal group behind the infamous DNSpionage malware campaign has been found running a new sophisticated operation that infects selected victims with a new variant of the DNSpionage malware.

First uncovered in November last year, the DNSpionage attacks used compromised sites and crafted malicious documents to infect victims’ computers with DNSpionagea custom remote administrative

New Twist in the Stuxnet Story
April 23, 2019

What a newly discovered missing link to Stuxnet and the now-revived Flame cyber espionage malware add to the narrative of the epic cyber-physical attack.

Stuxnet Family Tree Grows
April 23, 2019

What a newly discovered missing link to Stuxnet and the now-revived Flame cyber espionage malware add to the narrative of the epic cyber-physical attack.

CARBANAK Week Part Two: Continuing the CARBANAK Source Code Analysis
April 23, 2019

In the previous installment, we wrote about how string hashing was used in CARBANAK to manage Windows API resolution throughout the entire codebase. But the authors used this same string hashing algorithm for another task as well. In this installment, well pick up where we left off and write about CARBANAKs antivirus (AV) detection, AV evasion, authorship artifacts, exploits, secrets, and network-based indicators.

Antivirus Evasions

Source code unquestionably accelerates analysis of string hashes. For example, the function AVDetect in AV.cpp iterates processes to detect AV by process name hash as shown in Figure 1.


Figure 1: Antivirus detection by process name hash

What does CARBANAK do with this information? It evades AV according to what is installed. Figure 2 shows the code for an AVG evasion that the authors disabled by commenting it out. Based on this, it appears as if the AVG evasion was retired, but FLARE team member Ryan Warns confirmed in November 2017 that it still worked with one minor tweak. FLARE disclosed this to AVG immediately upon confirming it. Avast indicates that after our disclosure, they updated the affected DLL to ignore DLL_PROCESS_DETACH and leave its hooks in place.


Figure 2: Commented out source code to unload AVG user-space hooks

In November of 2017, FLARE also disclosed an evasion for Trend Micros detection of process injection that remained active in the CARBANAK source code. The evasion mirrors a technique used in Carberp that replaces remote heap allocation and a call to CreateRemoteThread with memory mapping and queueing of an asynchronous procedure call via QueueUserAPC. Following our disclosure, Trend Micro indicated that they had updated their behavior monitoring rules and released OfficeScan XG SP1 in December 2017 with a new Aggressive Event detection feature that covers this behavior.

Author Characterization

Having source code could pose unique opportunities to learn about the individuals behind the keyboard. To that end, I searched for artifacts in the source code dump that might point to individuals. I found the most information in Visual Studio solution files. Most of these referenced drive O: as the source root, but I did find the following host paths:

  • C:\Users\hakurei reimu\AppData\Local\Temp
  • C:\Users\Igor\AppData\Local\Temp
  • E:\Projects\progs\Petrosjan\WndRec\...
  • E:\Projects\progs\sbu\WndRec\...

Unfortunately, these data points dont yield many answers. If they are observed in later artifacts, connections might be inferred, but as of this writing, not much else is known about the authors.

Source Code Survey

The CARBANAK source code contained numerous exploits, previous C2 hosts, passwords, and key material. I decided to comprehensively search these out and determine if they led to any new conclusions or corroborated any previous observations.

Exploits

I wanted to know if the CARBANAK authors wielded any exploits that were not publicly disclosed. To the contrary, I found all the exploits to be well-documented. Table 1 breaks out the escalation code I reviewed from the CARBANAK source code dump.

Name

CVE

Notes

PathRec

2013-3660

Exploit proof of concept (poc) from May 2013

Sdrop

2013-3660

Exploit poc from June 2013

NDProxy

2013-5065

NDProxy.sys exploit originally authored by secniu

UACBypass

UAC bypass by DLL hijacking found in Carberp

COM

UAC bypass by disabling elevation prompts and dialogs via the IFileOperation COM interface

CVE-2014-4113

2014-4113

Win32k.sys exploit derived from code that can be found online

BlackEnergy2

AppCompat shim-based UAC bypass

EUDC

2010-4398

UAC bypass by EUDC exploitation

Table 1: Exploits for elevation found in CARBANAK source code

The CARBANAK source code also contains code copied wholesale from Mimikatz including the sekurlsa module for dumping passwords from lsass.exe and Terminal Services patching code to allow multiple remote desktop protocol connections.

Secrets

My analysis included an audit of passwords and key material found in the source code and accompanying binaries. Although many of these were used for debug versions, I curated them for reference in case a need might arise to guess future passwords based on passwords used in the source code. Table 2 shows recovered passwords used for RC2-encrypted communications and other purposes along with the corresponding name in the source code and their status as they were encountered (active in source code, commented out, or compiled into a binary).

Credential Identifier Per Source Code

Password

Status

ADMIN_PASSWORD

1He9Psa7LzB1wiRn

Active

ADMIN_PASSWORD

1234567812345678

Commented out

ADMIN_PASSWORD

cbvhX3tJ0k8HwnMy

Active

ADMIN_PASSWORD

1234567812345678

Commented out

N/A

1234567812345678

Compiled

Table 2: Passwords found in CARBANAK source code and binaries

I found an encrypted server certificate in a debug directory. This seemed like it could provide a new network-based indicator to definitively tie operations together or catch new activity. It was trivial to brute force this container by adapting a publicly available code sample of X509 handling in C# to cycle through passwords in a popular password list. The password was found in less than 1 second because it was the single-character password 1. The certificate turns out to be for testing, hence the weak password. The certificate is shown in Figure 3, with details in Table 3.


Figure 3: Test Company certificate

Parameter

Value

Subject

CN=Test Company

Issuer

CN=Test Company

Serial Number

834C6C3985506D8740FB56D26E385E8A

Not Before

12/31/2004 5:00:00 PM

Not After

12/31/2017 5:00:00 PM

Thumbprint

0BCBD1C184809164A9E83F308AD6FF4DBAFDA22C

Signature Algorithm

sha1RSA(1.3.14.3.2.29)

Public Key

Algorithm: RSA

Length: 2048

Key Blob:

30 82 01 0a 02 82 01 01 00 e4 66 7f d2 e1 01 53

f9 6d 26 a6 62 45 8b a8 71 ea 81 9a e6 12 d4 1c

6f 78 67 6d 7e 95 bb 3a c5 c0 2c da ce 48 ca db

29 ab 10 c3 83 4e 51 01 76 29 56 53 65 32 64 f2

c7 84 96 0f b0 31 0b 09 a3 b9 12 63 09 be a8 4b

3b 21 f6 2e bf 0c c1 f3 e4 ed e2 19 6e ca 78 68

69 be 56 3c 1c 0e a7 78 c7 b8 34 75 29 a1 8d cc

5d e9 0d b3 95 39 02 13 8e 64 ed 2b 90 2c 3f d5

e3 e2 7e f2 d2 d1 96 15 6e c9 97 eb 97 b9 0e b3

be bc c3 1b 1e e1 0e 1c 35 73 f4 0f d9 c3 69 89

87 43 61 c9 9e 50 77 a2 83 e4 85 ce 5a d6 af 72

a9 7b 27 c5 f3 62 8d e7 79 92 c3 9b f7 96 ed 5c

37 48 0a 97 ee f7 76 69 a2 b9 25 38 06 25 7d 8a

e4 94 b2 bb 28 4a 4b 5d c5 32 0d be 8e 7c 51 82

a7 9e d9 2c 8e 6b d8 c7 19 4c 2e 93 8d 2d 50 b4

e0 a4 ed c1 65 a4 a1 ba bf c7 bf 2c ec 28 83 f4

86 f2 88 5c c4 24 8b ce 1d 02 03 01 00 01

Parameters: 05 00

Private Key

Key Store: User

Provider Name: Microsoft Strong Cryptographic Provider

Provider type: 1

Key Spec: Exchange

Key Container Name: c9d7c4a9-2745-4e7f-b816-8c20831d6dae

Unique Key Container Name: 5158a0636a32ccdadf155686da582ccc_2bb69b91-e898-4d33-bbcf-fbae2b6309f1

Hardware Device: False

Removable: False

Protected: False

Table 3: Test Company certificate details

I also parsed an unprotected private key from the source code dump. Figure 4 and Table 4 show the private key parameters at a glance and in detail, respectively.


Figure 4: Parsed 512-bit private key

Field

Value

bType

7

bVersion

2

aiKeyAlg

0xA400 (CALG_RSA_KEYX) RSA public key exchange algorithm

Magic

RSA2

Bitlen

512

PubExp

65537

Modulus

0B CA 8A 13 FD 91 E4 72 80 F9 5F EE 38 BC 2E ED

20 5D 54 03 02 AE D6 90 4B 6A 6F AE 7E 06 3E 8C

EA A8 15 46 9F 3E 14 20 86 43 6F 87 BF AE 47 C8

57 F5 1F D0 B7 27 42 0E D1 51 37 65 16 E4 93 CB

P

8B 01 8F 7D 1D A2 34 AE CA B6 22 EE 41 4A B9 2C

E0 05 FA D0 35 B2 BF 9C E6 7C 6E 65 AC AE 17 EA

Q

81 69 AB 3D D7 01 55 7A F8 EE 3C A2 78 A5 1E B1

9A 3B 83 EC 2F F1 F7 13 D8 1A B3 DE DF 24 A1 DE

Dp

B5 C7 AE 0F 46 E9 02 FB 4E A2 A5 36 7F 2E ED A4

9E 2B 0E 57 F3 DB 11 66 13 5E 01 94 13 34 10 CB

Dq

81 AC 0D 20 14 E9 5C BF 4B 08 54 D3 74 C4 57 EA

C3 9D 66 C9 2E 0A 19 EA C1 A3 78 30 44 52 B2 9F

Iq

C2 D2 55 32 5E 7D 66 4C 8B 7F 02 82 0B 35 45 18

24 76 09 2B 56 71 C6 63 C4 C5 87 AD ED 51 DA 2

D

01 6A F3 FA 6A F7 34 83 75 C6 94 EB 77 F1 C7 BB

7C 68 28 70 4D FB 6A 67 03 AE E2 D8 8B E9 E8 E0

2A 0F FB 39 13 BD 1B 46 6A D9 98 EA A6 3E 63 A8

2F A3 BD B3 E5 D6 85 98 4D 1C 06 2A AD 76 07 49

Table 4: Private key parameters

I found a value named PUBLIC_KEY defined in a configuration header, with comments indicating it was for debugging purposes. The parsed values are shown in Table 5.

Field

Value

bType

6

bVersion

2

aiKeyAlg

0xA400 (CALG_RSA_KEYX) RSA public key exchange algorithm

Magic

RSA1

Bitlen

512

PubExp

65537

Modulus

0B CA 8A 13 FD 91 E4 72 80 F9 5F EE 38 BC 2E ED

20 5D 54 03 02 AE D6 90 4B 6A 6F AE 7E 06 3E 8C

EA A8 15 46 9F 3E 14 20 86 43 6F 87 BF AE 47 C8

57 F5 1F D0 B7 27 42 0E D1 51 37 65 16 E4 93 CB

Table 5: Key parameters for PUBLIC_KEY defined in configuration header

Network Based Indicators

The source code and binaries contained multiple Network-Based Indicators (NBIs) having significant overlap with CARBANAK backdoor activity and FIN7 operations previously observed and documented by FireEye. Table 6 shows these indicators along with the associated FireEye public documentation. This includes the status of each NBI as it was encountered (active in source code, commented out, or compiled into a binary). Domain names are de-fanged to prevent accidental resolution or interaction by browsers, chat clients, etc.

NBI

Status

Threat Group Association

comixed[.]org

Commented out

Earlier CARBANAK activity

194.146.180[.]40

Commented out

Earlier CARBANAK activity

aaaabbbbccccc[.]org

Active

stats10-google[.]com

Commented out

FIN7

192.168.0[.]100:700

Active

80.84.49[.]50:443

Commented out

52.11.125[.]44:443

Commented out

85.25.84[.]223

Commented out

qwqreererwere[.]com

Active

akamai-technologies[.]org

Commented out

Earlier CARBANAK activity

192.168.0[.]100:700

Active

37.1.212[.]100:700

Commented out

188.138.98[.]105:710

Commented out

Earlier CARBANAK activity

hhklhlkhkjhjkjk[.]org

Compiled

192.168.0[.]100:700

Compiled

aaa.stage.4463714.news.meteonovosti[.]info

Compiled

DNS infrastructure overlap with later FIN7 associated POWERSOURCE activity

193.203.48[.]23:800

Active

Earlier CARBANAK activity

Table 6: NBIs and prevously observed activity

Four of these TCP endpoints (80.84.49[.]50:443, 52.11.125[.]44:443, 85.25.84[.]223, and 37.1.212[.]100:700) were new to me, although some have been documented elsewhere.

Conclusion

Our analysis of this source code dump confirmed it was CARBANAK and turned up a few new and interesting data points. We were able to notify vendors about disclosures that specifically targeted their security suites. The previously documented NBIs, Windows API function resolution, backdoor command hash values, usage of Windows cabinet file APIs, and other artifacts associated with CARBANAK all match, and as they say, if the shoe fits, wear it. Interestingly though, the project itself isnt called CARBANAK or even Anunak as the information security community has come to call it based on the string artifacts found within the malware. The authors mainly refer to the malware as bot in the Visual Studio project, filenames, source code comments, output binaries, user interfaces, and manuals.

The breadth and depth of this analysis was a departure from the usual requests we receive on the FLARE team. The journey included learning some Russian, searching through a hundred thousand of lines of code for new information, and analyzing a few dozen binaries. In the end, Im thankful I had the opportunity to take this request.

In the next episode, Tom Bennett takes the reins to provide a retrospective on his and Barry Vengeriks previous analysis in light of the source code.

When Every Attack Is a Zero Day
April 23, 2019

Stopping malware the first time is an ideal that has remained tantalizingly out of reach. But automation, artificial intelligence, and deep learning are poised to change that.

G7 Comes Out in Favor of Encryption Backdoors
April 23, 2019

From a G7 meeting of interior ministers in Paris this month, an “outcome document”: Encourage Internet companies to establish lawful access solutions for their products and services, including data that is encrypted, for law enforcement and competent authorities to access digital evidence, when it is removed or hosted on IT servers located abroad or encrypted, without imposing any particular technology…

Hackers Actively Exploiting Widely-Used Social Share Plugin for WordPress
April 23, 2019

Hackers have been found exploiting a pair of critical security vulnerabilities in one of the popular social media sharing plugins to take control over WordPress websites that are still running a vulnerable version of the plugin.

The vulnerable plugin in question is Social Warfare which is a popular and widely deployed WordPress plugin with more than 900,000 downloads. It is used to add social

Analysis: Abuse of Custom Actions in Windows Installer MSI to Run Malicious JavaScript, VBScript, and PowerShell Scripts
April 23, 2019

We recently discovered malicious Microsoft Software Installation (MSI) files that download and execute other files, and could bypass traditional security solutions. Malicious actors can abuse custom actions in these files to execute malicious scripts and drop malware that are either capable of initiating a system shutdown or targeting financial systems located in certain locations.

The post Analysis: Abuse of Custom Actions in Windows Installer MSI to Run Malicious JavaScript, VBScript, and PowerShell Scripts appeared first on .

Fujifilm FCR Capsula X/Carbon X
April 23, 2019

This medical advisory includes mitigations for uncontrolled resource consumption and improper access control vulnerabilities reported in Fujifilms FCR Capsula X and Carbon X Computed Radiography cassette readers.

Operation ShadowHammer: a high-profile supply chain attack
April 23, 2019

In late March 2019, we briefly highlighted our research on ShadowHammer attacks, a sophisticated supply chain attack involving ASUS Live Update Utility. Now it is time to share more details about the research with our readers.

Source Code for CARBANAK Banking Malware Found On VirusTotal
April 23, 2019

Security researchers have discovered the full source code of the Carbanak malwareyes, this time it’s for real.

Carbanaksometimes referred as FIN7, Anunak or Cobaltis one of the most full-featured, dangerous malware that belongs to an APT-style cybercriminal group involved in several attacks against banks, financial institutions, hospitals, and restaurants.

In July last year, there was a

Whos Behind the RevCode WebMonitor RAT?
April 22, 2019

The owner of a Swedish company behind a popular remote administration tool (RAT) implicated in thousands of malware attacks shares the same name as a Swedish man who pleaded guilty in 2015 to co-creating theBlackshades RAT, a similar product that was used to infect more than half a million computers with malware, KrebsOnSecurity has learned.

CARBANAK Week Part One: A Rare Occurrence
April 22, 2019

It is very unusual for FLARE to analyze a prolifically-used, privately-developed backdoor only to later have the source code and operator tools fall into our laps. Yet this is the extraordinary circumstance that sets the stage for CARBANAK Week, a four-part blog series that commences with this post.

CARBANAK is one of the most full-featured backdoors around. It was used to perpetrate millions of dollars in financial crimes, largely by the group we track as FIN7. In 2017, Tom Bennett and Barry Vengerik published Behind the CARBANAK Backdoor, which was the product of a deep and broad analysis of CARBANAK samples and FIN7 activity across several years. On the heels of that publication, our colleague Nick Carr uncovered a pair of RAR archives containing CARBANAK source code, builders, and other tools (both available in VirusTotal: kb3r1p and apwmie).

FLARE malware analysis requests are typically limited to a few dozen files at most. But the CARBANAK source code was 20MB comprising 755 files, with 39 binaries and 100,000 lines of code. Our goal was to find threat intelligence we missed in our previous analyses. How does an analyst respond to a request with such breadth and open-ended scope? And what did we find?

My friend Tom Bennett and I spoke about this briefly in our 2018 FireEye Cyber Defense Summit talk, Hello, Carbanak! In this blog series, we will expound at length and share a written retrospective on the inferences drawn in our previous public analysis based on binary code reverse engineering. In this first part, Ill discuss Russian language concerns, translated graphical user interfaces of CARBANAK tools, and anti-analysis tactics as seen from a source code perspective. We will also explain an interesting twist where analyzing the source code surprisingly proved to be just as difficult as analyzing the binary, if not more. Theres a lot here; buckle up!

File Encoding and Language Considerations

The objective of this analysis was to discover threat intelligence gaps and better protect our customers. To begin, I wanted to assemble a cross-reference of source code files and concepts of specific interest.

Reading the source code entailed two steps: displaying the files in the correct encoding, and learning enough Russian to be dangerous. Figure 1 shows CARBANAK source code in a text editor that is unaware of the correct encoding.


Figure 1: File without proper decoding

Two good file encoding guesses are UTF-8 and code page 1251 (Cyrillic). The files were mostly code page 1251 as shown in Figure 2.


Figure 2: Code Page 1251 (Cyrillic) source code

Figure 2 is a C++ header file defining error values involved in backdoor command execution. Most identifiers were in English, but some were not particularly descriptive. Ergo, the second and more difficult step was learning some Russian to benefit from the context offered by the source code comments.

FLARE has fluent Russian speakers, but I took it upon myself to minimize my use of other analysts time. To this end, I wrote a script to tear through files and create a prioritized vocabulary list. The script, which is available in the FireEye vocab_scraper GitHub repository, walks source directories finding all character sequences outside the printable lower ASCII range: decimal values 32 (the space character) through 126 (the tilde character ~) inclusive. The script adds each word to a Python defaultdict_ and increments its count. Finally, the script orders this dictionary by frequency of occurrence and dumps it to a file.

The result was a 3,400+ word vocabulary list, partially shown in Figure 3.


Figure 3: Top 19 Cyrillic character sequences from the CARBANAK source code

I spent several hours on Russian language learning websites to study the pronunciation of Cyrillic characters and Russian words. Then, I looked up the top 600+ words and created a small dictionary. I added Russian language input to an analysis VM and used Microsofts on-screen keyboard (osk.exe) to navigate the Cyrillic keyboard layout and look up definitions.

One helpful effect of learning to pronounce Cyrillic characters was my newfound recognition of English loan words (words that are borrowed from English and transliterated to Cyrillic). My small vocabulary allowed me to read many comments without looking anything up. Table 1 shows a short sampling of some of the English loan words I encountered.

Cyrillic

English Phonetic

English

Occurrences

Rank

f ah y L

file

224

5

s e r v e r

server

145

13

a d r e s

address

52

134

k o m a n d

command

110+

27

b o t a

bot

130

32

p l ah g ee n

plugin

116

39

s e r v ee s

service

70

46

p r o ts e s s

process

130ish

63

Table 1: Sampling of English loan words in the CARBANAK source code

Aside from source code comments, understanding how to read and type in Cyrillic came in handy for translating the CARBANAK graphical user interfaces I found in the source code dump. Figure 4 shows a Command and Control (C2) user interface for CARBANAK that I translated.


Figure 4: Translated C2 graphical user interface

These user interfaces included video management and playback applications as shown in Figure 5 and Figure 6 respectively. Tom will share some interesting work he did with these in a subsequent part of this blog series.


Figure 5: Translated video management application user interface


Figure 6: Translated video playback application user interface

Figure 7 shows the backdoor builder that was contained within the RAR archive of operator tools.


Figure 7: Translated backdoor builder application user interface

The operator RAR archive also contained an operators manual explaining the semantics of all the backdoor commands. Figure 8 shows the first few commands in this manual, both in Russian and English (translated).


Figure 8: Operator manual (left: original Russian; right: translated to English)

Down the Rabbit Hole: When Having Source Code Does Not Help

In simpler backdoors, a single function evaluates the command ID received from the C2 server and dispatches control to the correct function to carry out the command. For example, a backdoor might ask its C2 server for a command and receive a response bearing the command ID 0x67. The dispatch function in the backdoor will check the command ID against several different values, including 0x67, which as an example might call a function to shovel a reverse shell to the C2 server. Figure 9 shows a control flow graph of such a function as viewed in IDA Pro. Each block of code checks against a command ID and either passes control to the appropriate command handling code, or moves on to check for the next command ID.


Figure 9: A control flow graph of a simple command handling function

In this regard, CARBANAK is an entirely different beast. It utilizes a Windows mechanism called named pipes as a means of communication and coordination across all the threads, processes, and plugins under the backdoors control. When the CARBANAK tasking component receives a command, it forwards the command over a named pipe where it travels through several different functions that process the message, possibly writing it to one or more additional named pipes, until it arrives at its destination where the specified command is finally handled. Command handlers may even specify their own named pipe to request more data from the C2 server. When the C2 server returns the data, CARBANAK writes the result to this auxiliary named pipe and a callback function is triggered to handle the response data asynchronously. CARBANAKs named pipe-based tasking component is flexible enough to control both inherent command handlers and plugins. It also allows for the possibility of a local client to dispatch commands to CARBANAK without the use of a network. In fact, not only did we write such a client to aid in analysis and testing, but such a client, named botcmd.exe, was also present in the source dump.

Toms Perspective

Analyzing this command-handling mechanism within CARBANAK from a binary perspective was certainly challenging. It required maintaining tabs for many different views into the disassembly, and a sort of textual map of command ids and named pipe names to describe the journey of an inbound command through the various pipes and functions before arriving at its destination. Figure 10 shows the control flow graphs for seven of the named pipe message handling functions. While it was difficult to analyze this from a binary reverse engineering perspective, having compiled code combined with the features that a good disassembler such as IDA Pro provides made it less harrowing than Mikes experience. The binary perspective saved me from having to search across several source files and deal with ambiguous function names. The disassembler features allowed me to easily follow cross-references for functions and global variables and to open multiple, related views into the code.


Figure 10: Control flow graphs for the named pipe message handling functions

Mikes Perspective

Having source code sounds like cheat-mode for malware analysis. Indeed, source code contains much information that is lost through the compilation and linking process. Even so, CARBANAKs tasking component (for handling commands sent by the C2 server) serves as a counter-example. Depending on the C2 protocol used and the command being processed, control flow may take divergent paths through different functions only to converge again later and accomplish the same command. Analysis required bouncing around between almost 20 functions in 5 files, often backtracking to recover information about function pointers and parameters that were passed in from as many as 18 layers back. Analysis also entailed resolving matters of C++ class inheritance, scope ambiguity, overloaded functions, and control flow termination upon named pipe usage. The overall effect was that this was difficult to analyze, even in source code.

I only embarked on this top-to-bottom journey once, to search for any surprises. The effort gave me an appreciation for the baroque machinery the authors constructed either for the sake of obfuscation or flexibility. I felt like this was done at least in part to obscure relationships and hinder timely analysis.

Anti-Analysis Mechanisms in Source Code

CARBANAKs executable code is filled with logic that pushes hexadecimal numbers to the same function, followed by an indirect call against the returned value. This is easily recognizable as obfuscated function import resolution, wherein CARBANAK uses a simple string hash known as PJW (named after its author, P.J. Weinberger) to locate Windows API functions without disclosing their names. A Python implementation of the PJW hash is shown in Figure 11 for reference.

def pjw_hash(s):
ctr = 0
for i in range(len(s)):
ctr = 0xffffffff & ((ctr << 4) + ord(s[i]))
if ctr & 0xf0000000:
ctr = (((ctr & 0xf0000000) >> 24) ^ ctr) & 0x0fffffff

return ctr

Figure 11: PJW hash

This is used several hundred times in CARBANAK samples and impedes understanding of the malwares functionality. Fortunately, reversers can use the flare-ida scripts to annotate the obfuscated imports, as shown in Figure 12.


Figure 12: Obfuscated import resolution annotated with FLARE's shellcode hash search

The CARBANAK authors achieved this obfuscated import resolution throughout their backdoor with relative ease using C preprocessor macros and a pre-compilation source code scanning step to calculate function hashes. Figure 13 shows the definition of the relevant API macro and associated machinery.


Figure 13: API macro for import resolution

The API macro allows the author to type API(SHLWAPI, PathFindFileNameA)() and have it replaced with GetApiAddrFunc(SHLWAPI, hashPathFindFileNameA)(). SHLWAPI is a symbolic macro defined to be the constant 3, and hashPathFindFileNameA is the string hash value 0xE3685D1 as observed in the disassembly. But how was the hash defined?

The CARBANAK source code has a utility (unimaginatively named tool) that scans source code for invocations of the API macro to build a header file defining string hashes for all the Windows API function names encountered in the entire codebase. Figure 14 shows the source code for this utility along with its output file, api_funcs_hash.h.


Figure 14: Source code and output from string hash utility

When I reverse engineer obfuscated malware, I cant help but try to theorize about how authors implement their obfuscations. The CARBANAK source code gives another data point into how malware authors wield the powerful C preprocessor along with custom code scanning and code generation tools to obfuscate without imposing an undue burden on developers. This might provide future perspective in terms of what to expect from malware authors in the future and may help identify units of potential code reuse in future projects as well as rate their significance. It would be trivial to apply this to new projects, but with the source code being on VirusTotal, this level of code sharing may not represent shared authorship. Also, the source code is accessibly instructive in why malware would push an integer as well as a hash to resolve functions: because the integer is an index into an array of module handles that are opened in advance and associated with these pre-defined integers.

Conclusion

The CARBANAK source code is illustrative of how these malware authors addressed some of the practical concerns of obfuscation. Both the tasking code and the Windows API resolution system represent significant investments in throwing malware analysts off the scent of this backdoor. Tune into tomorrows installment of this series for a round-up of antivirus evasions, exploits, secrets, key material, authorship artifacts, and network-based indicators.

Analyzing C/C++ Runtime Library Code Tampering in Software Supply Chain Attacks
April 22, 2019

For the past few years, the security industrys very backbone its key software and server components has been the subject of numerous attacks through cybercriminals various works of compromise and modifications. Such attacks involve the original softwares being compromised via malicious tampering of its source code, its update server, or in some cases, both. In either case, the intention is to always get into the network or a host of a targeted entity in a highly inconspicuous fashion which is known as a supply chain attack. Depending on the attackers technical capabilities and stealth motivation, the methods used in the malicious modification of the compromised software vary in sophistication and astuteness.

The post Analyzing C/C++ Runtime Library Code Tampering in Software Supply Chain Attacks appeared first on .

Excellent Analysis of the Boeing 737 MAX Software Problems
April 22, 2019

This is the best analysis of the software causes of the Boeing 737 MAX disasters that I have read. Technically this is safety and not security; there was no attacker. But the fields are closely related and there are a lot of lessons for IoT security – and the security of complex socio-technical systems in general – in here….

Page 1 of 68 Older Posts →