windows.vadyarascan.VadYaraScan is outputting limited information

[35mpded]

Volatility2 yarascan module used to show adjacent offsets, bytes/strings for a match on a rule. Volatility3 yarascan module now only shows the bytes of the strings used as a rule. This creates couple of issues while doing memory analysis:

• windows.vadyarascan.VadYaraScan False-positive hits are hard to dissmiss; sometimes you can match a rule (hex-string or string) that antivirus engines may have in their signature files accross memory (for e.g. WinDefender). As visible in "Example 3", due to adjacent strings it is easy to dismiss as false-positive, but that is not the case in volatility3 as it will only show the match - "6d 69 6d 69".
• windows.vadyarascan.VadYaraScan not showing adjacent strings complicates analysis as it is hard to identify if the rule matched a legitimate strings or a string part of something malicious like powershell command.

Example 1 (Volatility2's yarascan output):

volatility -f mem.raw --profile Win10x64_19041 yarascan -Y "payload"
Volatility Foundation Volatility Framework 2.6.1
Rule: r1
Owner: Process cmd.exe Pid 2712
0x0042a82f  63 73 70 61 79 6c 6f 61 64 20 25 41 50 50 44 41   payload.%APPDA
0x0042a83f  54 41 25 5c 73 63 76 68 6f 73 74 2e 65 78 65 26   TA%\scvhost.exe&
0x0042a84f  25 41 50 50 44 41 54 41 25 5c 73 63 76 68 6f 73   %APPDATA%\scvhos
0x0042a85f  74 2e 65 78 65 26 64 65 6c 20 25 41 50 50 44 41   t.exe&del.%APPDA
0x0042a86f  54 41 25 5c 73 63 76 68 6f 73 74 2e 65 78 65 0a   TA%\scvhost.exe.
0x0042a87f  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0042a88f  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0042a89f  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0042a8af  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0042a8bf  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0042a8cf  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0042a8df  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0042a8ef  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0042a8ff  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0042a90f  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0x0042a91f  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

Example 2 (volatility3 yarascan output):

vol -f mem.raw -r csv windows.vadyarascan.VadYaraScan --yara-rules "payload"
Volatility 3 Framework 2.4.1
TreeDepth,Offset,PID,Rule,Component,Valueing finished
0,0x42a82f,2712,r1,$a,63 73 70 61 79 6c 6f 61 64

Example 3 (volatility2 yarascan output)

volatility -f mem.raw --profile Win10x64_19041 yarascan -Y "mimi"
Volatility Foundation Volatility Framework 2.6.1
Owner: Process MemCompression Pid 3764
0x22e94c658ec  6d 69 6d 69 63 ba 09 41 4c 46 3a 45 78 70 6c 6f   mimic..ALF:Explo
0x22e94c658fc  69 74 c3 16 00 28 00 00 43 56 45 2d 32 30 31 37   it...(..CVE-2017
0x22e94c6590c  2d 31 31 38 38 32 2e 41 56 57 a6 0e fd e0 04 4d   -11882.AVW.....M
0x22e94c6591c  8e bb 38 29 59 00 00 b4 15 02 20 01 00 00 bf c5   ..8)Y...........
0x22e94c6592c  70 ff 55 9a bf e7 57 cc 5b b1 5b d5 fe 36 4e 2f   p.U...W.[.[..6N/
0x22e94c6593c  66 72 61 6d 65 f4 11 3d 22 2d 09 76 73 69 74 2e   frame..="-.vsit.
0x22e94c6594c  60 00 00 cc 18 00 c0 08 01 05 ec 00 e7 12 22 2f   `............."/
0x22e94c6595c  3e 3c 2f 72 65 6c 61 74 69 6f 6e 73 68 69 70 73   ></relationships
0x22e94c6596c  3e b9 09 d9 04 53 43 52 49 50 a1 00 20 00 54 3a   >....SCRIP....T:
0x22e94c6597c  42 61 63 6b 64 6f 6f 72 14 21 44 69 6e 6f 73 6d   Backdoor.!Dinosm
0x22e94c6598c  61 6c 2e 53 30 30 33 c2 09 fe d8 04 f7 cf 48 b6   al.S003.......H.
0x22e94c6599c  d9 04 00 00 00 00 c1 2e a3 ab d3 fb 74 55 45 36   ............tUE6
0x22e94c659ac  03 9c ee 61 a3 f2 34 99 e9 93 24 63 6d 64 73 74   ...a..4...$cmdst
0x22e94c659bc  72 69 6e 67 29 7b 01 04 00 40 69 d0 27 61 75 74   ring){...@i.'aut
0x22e94c659cc  68 6e 73 2d 6e 65 24 6e 75 6c 6c 2d 61 6e 64 24   hns-ne$null-and$
0x22e94c659dc  96 00 30 29 7b 24 7b 90 02 50 24 10 19 05 28 00   ..0){${..P$...(.

[digitalisx]

Related to #317

[35mpded]

Not really. The issue raised by that user is about the hex output not being converted to strings as in volatility2. The issue I raised is that adjacent hex/strings are not displayed. In the old output in vol2 you used to show the next 15 offsets next to the match.

[LatinSuD]

I made a dirty workaround. You have to use a regex to expand the context, then use awk and xxd to re-process the hex dump.

For example, to look for "usermath" in pid 544, with 32 bytes of extra context:

$ vol -f 0zapftis.vmem  windows.vadyarascan.VadYaraScan --pid 544 --yara-rules "/usermath.{32}?/" |
awk '
   /^0x/{
         S=""
         for(i=5; i<NF; i++) {
               S=S sprintf("%s", $i)
         }
         print "PID:" $2 "\tRule:" $3 "\tComponent:" $4
         system("echo " S " | xxd -r -ps | xxd -o " $1 " | sed \"s/^/0x/\"")
         print ""
         next
    }
    /^Offset/{next}
    {print}
'

Volatility 3 Framework 2.4.2    PDB scanning finished                        

PID:544 Rule:r1 Component:$a
0x4ad1f9ad: 7573 6572 6d61 7468 6572 7200 003b 015f  usermatherr..;._
0x4ad1f9bd: 696e 6974 7465 726d 006d 005f 5f67 6574  initterm.m.__get
0x4ad1f9cd: 6d61 696e 6172 67                        mainarg

PID:544 Rule:r1 Component:$a
0x77c5b578: 7573 6572 6d61 7468 6572 7200 5f5f 7468  usermatherr.__th
0x77c5b588: 7265 6164 6861 6e64 6c65 005f 5f74 6872  readhandle.__thr
0x77c5b598: 6561 6469 6400 5f                        eadid._

[github-actions[bot]]

This issue is stale because it has been open for 200 days with no activity.

[github-actions[bot]]

This issue was closed because it has been inactive for 60 days since being marked as stale.