This
post was originally published on
this siteIn 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
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
For many, applying for a new job is a stressful experience. Before the interview, we can find ourselves worrying about if we know enough for the technical review stage. The truth is that the interview should be about how you tackle a question and work through it, rather than getting the answer exactly right. Even […]