Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Code & Data Reuse in the Malware Ecosystem

Published: 2019-12-12
Last Updated: 2019-12-12 07:47:00 UTC
by Xavier Mertens (Version: 1)
0 comment(s)

In the past, I already had the opportunity to give some "security awareness" sessions to developers. One topic that was always debated is the reuse of existing code. Indeed, for a developer, it's tempting to not reinvent the wheel when somebody already wrote a piece of code that achieves the expected results. From a gain of time perspective, it's a win for the developers who can focus on other code. Of course, this can have side effects and introduce bugs, backdoors, etc... but it's not today's topic. Malware developers are also developers and have the same behavior. Code reuse has been already discussed several times[1]. For example, tools exist to detect cloned or reused code in the IDA disassembler[2][3].

A Trendmicro report demonstrated that different malware families (URSNIF, EMOTET, DRIDEX, and BitPaymer) have code similarities[4].

But, code or data reuse is present everywhere, even in simple macro languages. Yesterday, I found an interesting sample that contained a function to kill AV and other security products. To achieve this, the best approach is to have a list of potential process names, search for them and try to kill the process:

a2adguard.exe
a2adwizard.exe
a2antidialer.exe
a2cfg.exe
a2cmd.exe
a2free.exe
a2guard.exe
a2hijackfree.exe
a2scan.exe
a2service.exe
a2start.exe
a2sys.exe
a2upd.exe
aavgapi.exe
aawservice.exe
aawtray.exe
ad-aware.exe
ad-watch.exe
[...]

The complete list contained 233 items! On Twitter, one of my followers pointed me to a GitHub page that had a file containing exactly... 233 items! I searched for more references and found other ones which also contained the same list:

  • Reverse Shell Backdoor framework[5]
  • Dr0p1t framework[6]
  • Metasploit[7]

Why malware developers should take time to compile their own list of interesting processes while such lists are already publicly available? If you have written some code or compiled data like those and published them somewhere (for any valid reason - nothing malicious), they're chances that they will be found and (ab)used by attackers in their code!  The best example is Mimikatz that has been (and is still) used in many attacks. This is valid not only for pieces of code but also for any "data". Keep this in mind!

[1] https://www.first.org/resources/papers/london2019/1630-Code-Reuse-Analysis-Holtzman-.pdf
[2] https://github.com/BinSigma/BinClone
[3] https://www.hex-rays.com/products/ida/tech/flirt/in_depth.shtml
[4] https://blog.trendmicro.com/trendlabs-security-intelligence/ursnif-emotet-dridex-and-bitpaymer-gangs-linked-by-a-similar-loader/
[5] https://github.com/tarcisio-marinho/RSB-Framework/blob/master/Python/victim/av.txt
[6] https://github.com/D4Vinci/Dr0p1t-Framework/blob/master/resources/killav.py
[7] https://github.com/rapid7/metasploit-framework/blob/master/scripts/meterpreter/getcountermeasure.rb

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

0 comment(s)
Diary Archives