1

I have captured a memory dump of recent Ubuntu 22.04 kernel 6.2.0-39-generic.

captured image with LiMe and analyzed with volatility3.

did a yarascan against all known rules and found a suspicious amount of matches for spyeye.

Here is the output

Now I'm checking these results against a clean install of Ubuntu 22.04 with the same kernel on a different system not connected to any networks. To ensure these aren't false positives. However there are too many matches here for spyeye strain for it to be false positives. I also have good reason to believe that computer is being monitored.

So to some of the more senior security guys, how can i go about examining this further aside from cross-checking memory addresses with processes, and what's the next step here?

Any practical advice would be appreciated.

EDIT: I cross-referenced the results with a fresh installation of an ubuntu workstation and found that the spyeye rule matches were largely false positives. Many of the same hits exist on a fresh install of the system. I compiled a list of matches which did not appear on the fresh machine. Most of these PIDs are Chrome.

0x7f3826c9d306  6819    WarpStrings     $       77 79 6c 65
0x7f38270ef063  6819    Cerberus        $generic        43 65 72 62 65 72 75 73
0x7f38272d70e3  6819    Cerberus        $generic        43 65 72 62 65 72 75 73
0x7f321c49558f  6866    memory_shylock  $b      69 64 3d 44 31 38 46 33 46 35 38 38 32 34 45 44 44 37 42 35 39 36 31 34 44 46 37 41 45 33 39 41 42 39 37
0x559888d1b663  7027    spyeye  $d      64 61 74 61 5f 62 65 66 6f 72 65
0x559888d1b663  7118    spyeye  $d      64 61 74 61 5f 62 65 66 6f 72 65
0x7fa7712e1440  7409    Cerberus        $generic        43 45 52 42 45 52 55 53
0x7fa7712e1451  7409    Cerberus        $generic        43 65 72 62 65 72 75 73
0x7fa77156fd80  7409    Cerberus        $generic        43 45 52 42 45 52 55 53
0x7fa77156fd94  7409    Cerberus        $generic        43 65 72 62 65 72 75 73
0x7fa7719f162a  7409    Cerberus        $generic        43 65 72 62 65 72 75 73
0x18b06802b80   12841   Cerberus        $generic        63 65 72 62 65 72 75 73
0x18b069950ac   12841   ScarhiknStrings $       68 61 68 61 31 32 33
0xac40555614b   12841   memory_shylock  $b      69 64 3d 44 31 38 46 33 46 35 38 38 32 34 45 44 44 37 42 35 39 36 31 34 44 46 37 41 45 33 39 41 42 39 37
0xac405556f4b   12841   memory_shylock  $b      69 64 3d 44 31 38 46 33 46 35 38 38 32 34 45 44 44 37 42 35 39 36 31 34 44 46 37 41 45 33 39 41 42 39 37
0xac405558b4b   12841   memory_shylock  $b      69 64 3d 44 31 38 46 33 46 35 38 38 32 34 45 44 44 37 42 35 39 36 31 34 44 46 37 41 45 33 39 41 42 39 37
0xac406ef8f48   12841   xtreme_rat      $signature1     58 00 54 00 52 00 45 00 4d 00 45
0xac407101f4e   12841   xtreme_rat      $signature1     58 00 54 00 52 00 45 00 4d 00 45
0x7f6e0929a58f  12841   memory_shylock  $b      69 64 3d 44 31 38 46 33 46 35 38 38 32 34 45 44 44 37 42 35 39 36 31 34 44 46 37 41 45 33 39 41 42 39 37
0x559888d1b663  12841   spyeye  $d      64 61 74 61 5f 62 65 66 6f 72 65
0x559888d1b663  8502    spyeye  $d      64 61 74 61 5f 62 65 66 6f 72 65
0x559888d1b663  12918   spyeye  $d      64 61 74 61 5f 62 65 66 6f 72 65
0x559888d1b663  13359   spyeye  $d      64 61 74 61 5f 62 65 66 6f 72 65
0x559888d1b663  14337   spyeye  $d      64 61 74 61 5f 62 65 66 6f 72 65
8
  • What are you trying to accomplish? Like from an IT security standpoint, probably just wipe the machine and report the breach if you are obligated to. Is there some specific thing you want to find out from the memory dump? Commented Dec 20, 2023 at 9:57
  • @le3th4x0rbot My goal is to do my best to ensure this doesn't happen again, and if/when it does, how to respond in the most effective way possible. Both from an IT standpoint and legal standpoint. Basically I want to strengthen my security and incidence response policies to align with the nature of the attack. So I want to know exactly what kind of malware it is and how this happened... not sure that would be possible at this point.
    – Zzgooloo
    Commented Dec 20, 2023 at 16:04
  • After some research about yarascan it seems like false positives are a pretty big thing with the tool. It looks like maybe you have some PIDs associated with the detections; have you tried running the binaries through VirusTotal? Commented Dec 20, 2023 at 21:49
  • In terms of how malware got there, sometimes it is really hard to know, especially if the malware does anything to hide itself. Obviously you cannot fully trust anything a compromised machine says, since the attacker can easily delete or modify data and behavior of the computer. Commented Dec 20, 2023 at 21:52
  • @le3th4x0rbot I did a checksum of the binaries (mostly it's google chrome) and they are un altered. But i think the malware will be in memory changing the app behaviour at run time, I doubt the binaries will be infected.
    – Zzgooloo
    Commented Dec 20, 2023 at 21:57

1 Answer 1

0

The first thing to note here is that when you're making a request around rules of any kind, especially those of YARA, it would behoove you to make a reference to the source where you have gotten the rules - this helps the community compare the data from your output. The rule names are arbitrary strings with YARA, so not always does that identify a source rule we can use for comparison.

Secondly, as you have already said "I also have good reason to believe that computer is being monitored", that would indicate a good case for a wipe of the machine (assuming you haven't already), as other comments have referenced.

Of course, we want to learn and practice how to dive into this and discern whether these tools are providing us with actionable data. And the proof is in the data!

As you had already discovered, the SpyEye rule has been found to be rife with false positives namely because of the two strings found in the rule (shortened for relevance):

SpyEye

strings:
    $spyeye = "SpyEye"
    ...
    $d = "data_before"
    ...
    $f = "data_end"
    ...
    
condition:
    $spyeye or (any of ($a,$b,$c,$d,$e,$f,$g,$h,$i,$j,$k,$l,$m,$n))

Filtering all of the results in the provided sample output we can see two repeating patterns for those matches:

grep -i spyeye yarascan-output.txt | cut -d '$' -f 2 | sort | uniq
d      64 61 74 61 5f 62 65 66 6f 72 65
f      64 61 74 61 5f 65 6e 64

What you see repeatedly in the YARA scan match against your memory is against those hexidecimal strings 64 61 74 61 5f 62 65 66 6f 72 65 (data_before) and 64 61 74 61 5f 65 6e 64 (data_end). These could be data structures referenced by many programs or libraries, hence the 614 hits (based on the provided sample).

Moving forward we can review the other 8 unique matches for interesting patterns to discern potential false positives or places in which we can dive further.

ScarhiknStrings

Using the following rule that I found for ScarhiknStrings:

rule ScarhiknStrings : Scarhikn Family
{
    meta:
        description = "Scarhikn Identifying Strings"
        author = "Seth Hardy"
        last_modified = "2014-06-25"
        
    strings:
        $ = "9887___skej3sd"
        $ = "haha123"
        
    condition:
       any of them
}

We see the match for the ScarhiknStrings rule matches on hexidecimal 68 61 68 61 31 32 33 which is haha123. This rule is pretty broad using only two potential strings, and "haha123" could be found in many different contexts.

Xtreme_RAT

Using the following rule I found for xtreme_rat:

rule xtreme_rat : Trojan
{
    meta:
        author="Kevin Falcoz"
        date="23/02/2013"
        description="Xtreme RAT"
    
    strings:
        $signature1={58 00 54 00 52 00 45 00 4D 00 45} /*X.T.R.E.M.E*/
        
    condition:
        $signature1
}

This rule is for one, quite dated, and relies on a single string (noted in the comment in the rule as "X T R E M E") for detection. Additionally, althought developed in Delphi, XTRAT has primarily been observed as targeting Windows systems. You can look at the Malpedia entry for XTRAT for additional context and additional YARA rules that are more fine tuned to samples.

Cerberus

Using the following rule I found for Cerberus:

import "pe"
rule Cerberus : rat
{
    meta:
        description = "Cerberus"
        author = "Jean-Philippe Teissier / @Jipe_"
        date = "2013-01-12"
        filetype = "memory"
        version = "1.0" 

    strings:
        $checkin = "Ypmw1Syv023QZD"
        $clientpong = "wZ2pla"
        $serverping = "wBmpf3Pb7RJe"
        $generic = "cerberus" nocase

    condition:
        any of them
}

The three strings that match are all iterations of the same match on the $generic string, and any of these can exist in many forms on a system:

  • "CERBERUS": 43 45 52 42 45 52 55 53
  • "Cerberus": 43 65 72 62 65 72 75 73
  • "cerberus": 63 65 72 62 65 72 75 73

Shylock

Using the following rule I found for memory_shylock:

rule memory_shylock
{
   strings:
      $a = /pipe\\[A-F0-9]{32}/     //Named pipe created by the malware
      $b = /id=[A-F0-9]{32}/     //Portion or the uri beacon
      $c = /MASTER_[A-F0-9]{32}/     //Mutex created by the malware
      $d = "***Load injects by PIPE (%s)" //String found in binary
      $e = "***Load injects url=%s (%s)" //String found in binary
      $f = "*********************** Ping Ok ************************" //String found in binary
      $g = "*** LOG INJECTS *** %s"     //String found in binary

   condition: 
      any of them
}

The match that hits is for 69 64 3d 44 31 38 46 33 46 35 38 38 32 34 45 44 44 37 42 35 39 36 31 34 44 46 37 41 45 33 39 41 42 39 37 which is "id=D18F3F58824EDD7B59614DF7AE39AB97". This can be utilized in many request/responses to many systems, and the broad any of them combined with a regular expression around a ID identifier likely means this is also a false positive.

WarpStrings

Using the following rule I found for WarpStrings:

private rule WarpStrings : Warp Family
{
    meta:
        description = "Warp Identifying Strings"
        author = "Seth Hardy"
        last_modified = "2014-07-10"
        
    strings:
        $ = "/2011/n325423.shtml?"
        $ = "wyle"
        $ = "\\~ISUN32.EXE"

    condition:
       any of them
}

The match for 77 79 6c 65 is on the string "wyle". Again, given the broad nature of the any of them condition, this too is likely a false positive as that string can be found in many permutations (certificates, identifiers, generated strings, etc.).

with_sqlite

Using the following rule I found for with_sqliite:

rule with_sqlite : sqlite
{
    meta:
        author = "Julian J. Gonzalez <[email protected]>"
        reference = "http://www.st2labs.com"
        description = "Rule to detect the presence of SQLite data in raw image"
    strings:
        $hex_string = {53 51 4c 69 74 65 20 66 6f 72 6d 61 74 20 33 00}
    condition:
        all of them
}

This rule to me is not an indicator of anything malicious, but is instead used forensically to identify where SQLite data is present. As the hex_string specified is "SQLite format 3", this means that it's matching on SQLite 3 database files being loaded into memory.

TLDR

With that about everything that matches, from what I can tell given the rules I found based on their specifiers and the data matches, is effectively considered a false positive. This does not mean that the system isn't itself infected, but combination of the way the memory image was taken along with the YARA ruleset being used means that if there is something specific on that system, it's not being caught. Looking at what the rule catches would give credence to areas in memory to look at, but without decent indications of actual matches it would be a pretty time consuming search to sift through the memory.

If you have ideas about specific functionality for what you mean by the system being "monitored" then you can look for samples of RATs, remote management software, etc. that have public (and well tested) YARA rules to acoompany them to verify, assuming that you have kept the memory dump to play with and learn from.

I hope this helps!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .