The document discusses innovative techniques for evading antivirus detection by employing various obfuscation methods and payload generation strategies utilized by penetration testers. It highlights the challenges posed by the evolving landscape of cybersecurity and the continuous arms race between security measures and attackers. The author emphasizes the importance of understanding anti-virus limitations and the ethical implications of developing tools that can bypass these defenses.

1. Adventures in Asymmetric
Warfare:
Fighting the AV Vendors
Will
@harmj0y
Veris Group - Adaptive Threat Division

2. @harmj0y
● Security researcher and red teamer for the
Adaptive Threat Division of Veris Group
● Co-founder of the Veil-Framework #avlol
o www.veil-framework.com
o Shmoocon ‘14: AV Evasion with the Veil
Framework
o Defcon ‘14: Veil-Pillage: Post-exploitation 2.0
o co-wrote Veil-Evasion, wrote Veil-Catapult, Veil-
PowerView,Veil-Pillage, and PowerUp
● Active Cortana and PowerShell hacker

3. tl;dr
● Problem Space
● How we got here and ethical issues
● Approaches #avlol
● Obfuscation methods
● Payload Analysis

4. Teh Halting Problem?
● Input:
o a potentially malicious program P
● Output:
o True if executing P would cause a the host computer
to be “compromised”
o False otherwise
● def halts(P):
return
isMalicious(“removeMaliciousLogic(P)
compromiseHost()”)

5. Problem Space
● Anti-virus detection is an undecidable
problem
o That is, it’s impossible to design a 100% effective
anti-virus solution
● Though a perfect approach is impossible,
approximations can be made
● But detection is really really hard

6. Our Problem

7. How We Got Here
● From 2009 on, antivirus started snarfing up
more and more stock MSF payloads
● We started researching basic ways to keep
doing our job
● All of our initial efforts drew from prior
work, we don’t claim to have invented
any of this stuff!!

8. Previous Work
● Mark Baggett’s post Tips for Evading Anti-
Virus During Pen Testing was the first
public resource to talk about using Python to
inject shellcode
● We ended up mostly drawing from Debasish
Mandal's Execute ShellCode Using Python
o Uses the
VirtualAlloc/CreateThread/WaitForSingleObject
pattern

9. Our Solution
● A way to get around antivirus as easily as
professional malware
o don’t want to roll our own backdoor each time
o codebase built by myself, @ChrisTruncer and
@TheMightyShiv
● Generate payloads in a language and
technique agnostic way
● See the Shmoocon ‘14 presentation AV
Evasion with the Veil-Framework for more
background

10. Our Solution

11. Ethical Issues
● The disclosure debate is
nothing new...
● Pentesters are 5+ years
behind the professional
malware community
● This is a problem the bad
guys have already solved,
and better than we have!

12. Public Reaction
“surely this will just result in 21 new signatures for all major
AVs and then we're back to square one?”
“Isn't our entire field meant to be working towards
increasing security, rather than handing out fully
functioning weapons?”
“The other point here is that anything that helps to expose
how in-effective AV really is at stopping even a
minimally sophisticated attacker is a good thing.”
http://www.reddit.com/r/netsec/comments/1fc2xp/veil_a_metasploit_payloa
d_generator_for_bypassing/

13. Twitter Reaction

14. Approaches
● We started with Python based shellcode
injection techniques, soon branched into
other languages
● Similar payloads = : (
o started implementing basic obfuscation methods
o and by basic, we mean basic
● static signatures = #avlol

15. Obfuscation 1.0
● Let’s randomize everything we possibly can
o This works better than you think
● Substitute in a randomized string for all
variable and method names
● Shuffle up everything as appropriate

16. Obfuscation 1.0

17. “Pyherion”
● What if vendors still find a way to trigger on
the malicious Python script sources?
● We introduced Pyherion, a python ‘crypter’
inspired by Hyperion
● Encrypts an entire Python file with a random
AES key, base64’s it and and rolls it all up
into an exec(*) wrapper

20. Obfuscation 1.5: Pure Stagers
● What if vendors are triggering on the raw
shellcode and decoders?
● How about we eliminate shellcode all
together, and build some native stagers?
● They aren’t that complicated, thanks Raffi!
o https://github.com/rsmudge/metasploit-loader
o http://blog.strategiccyber.com/2013/06/28/staged-payloads-
what-pen-testers-should-know/

21. Pure Stagers
The meterpreter stager is surprisingly simple:
1) a tcp connection is opened to the handler
2) the handler spits back 4 bytes indicating
the .dll size, and then the .dll itself
3) socket number is pushed into EDI
4) execution is passed to the .dll just like we
do regular shellcode (void * or VirtualAlloc)

22. Pure Stagers
● The following are the pure stagers currently
available in the framework:
Language Stager
Python meterpreter/reverse_tcp
Python meterpreter/reverse_http
Python meterpreter/reverse_https
C meterpreter/reverse_tcp
C meterpreter/reverse_tcp_service
C meterpreter/reverse_http
C meterpreter/reverse_http_service

23. Pure Stagers
Language Stager
C# meterpreter/reverse_tcp
C# meterpreter/reverse_http
C# meterpreter/reverse_https
Powershell meterpreter/reverse_tcp
Powershell meterpreter/reverse_http
Powershell meterpreter/reverse_https
Ruby meterpreter/reverse_tcp

24. Obfuscation 2.0
● Variable obfuscation is great
● But for things like C, this doesn’t work as
well as we’d like
● Can we introduce something a little more
interesting?

25. Obfuscation 2.0
● Our (slightly) more “advanced” C obfuscation
involves our interpretation of a method nop
o muck up dynamic analysis without affecting the
actual execution of the program
● General idea:
o throw in enough processing functions that sufficiently
complicate the call tree of the program
● This is a basic version of what malware has
been doing for years
o shouldn’t be that effective, but it is!

26. Obfuscation 2.0
● Choose a set of randomized string processing
functions (reverse, split, etc.)
● Malloc a randomized number of strings of
randomized lengths
● Intersperse these randomized functions
throughout the actual code

27. Obfuscation 2.0

28. Obfuscation 3.0
● What if some vendors trigger on the
Pyinstaller loader.exe itself?
● How about a (reasonably) obfuscated version
of the Pyinstaller loader? :)
o BSides Boston ‘14: Pwnstaller 1.0
o https://github.com/harmj0y/pwnstaller/
● Integrated into Veil-Evasion this past May

29. Pwnstaller
● On each run:
o Obfuscated code for all* source files associated with
the Pyinstaller launcher are generated
o mingw32 is used to compile everything into a new
runw.exe, all on Kali m/
o copy the runw.exe into the correct location
o a randomized Windows icon is chosen for the final
packaged result
*see http://www.harmj0y.net/blog/python/pwnstaller-1-0/ for a full
explanation

30. Obfuscation 4.0: Ruby
● Since some people have started to pay
attention to Pyinstaller binaries, let’s try
some other languages:
● C? sure, with some obfuscation
● C#? mono can help with .NET
● PowerShell? no disk writes? awesome
● Ruby? Why not...

31. Ruby
● Ruby has a foreign function interface just like
Python does, the win32-api gem
o This means we can inject shellcode, and can write
native Meterpreter stagers!
● And it has its own Pyinstaller analogue:
OCRA (One Click Ruby application)
o http://ocra.rubyforge.org/
● I wonder if we can get this running on Kali :)

32. Ruby Shellcode Injection

33. Ruby OCRA Compilation

34. Ruby Module Releases
● The following payload modules are currently
in the development branch, and will be
merged into master for the 9/15/2014
V-Day:
o ruby/shellcode_inject/flat
o ruby/meterpreter/reverse_tcp
● Everything is compiled to a self-extracting
Windows executable, all on Kali!

35. A .NET Crypter
● C#/VB.net code is compiled, not interpreted,
so we can’t build a dynamic obfuscator
equivalent to Pyherion :(
● Or can we? .NET has an interesting feature
called Reflection:
o “you can use reflection to create type instances at
run time, and to invoke and access them”
http://msdn.microsoft.com/en-us/library/f7ykdhsy(v=vs.110).aspx

36. A .NET Crypter
● If we have an array of raw bytes of a .NET
binary, we can run the entire executable
from memory with 3 lines by utilizing
Reflection:
o Assembly a = Assembly.Load(bytes);
o MethodInfo m = a.EntryPoint;
o m.Invoke(a.CreateInstance(m.Name), null);
● We can obfuscate these bytes in any way we
want beforehand

37. Arya: a .NET Crypter
● A crypter for all .NET binaries was just
pushed along with the Ruby payloads
● A payload binary is generated and compiled
as normal, the crypter then:
o reads in the raw bytes
o base64 encodes the data and builds a random
substitution cipher for the string
o builds a launcher/dropper that decodes the raw data
and invokes the original binary using Reflection

38. A .NET Crypter

39. Payload Analysis

40. ssdeep
● ssdeep is a ‘fuzzy hashing’ static malware
comparison tool, allowing for the
comparison of malware families
● “can match inputs that have homologies”
o biology term, fancy way to saying degree of shared
ancestry
● Generated 1000 samples of some payload
families did ssdeep runs over each set

41. python/meterpreter/rev_tcp
● (1000 choose 2) = 499500 possible pairing
combinations for ssdeep
● 169107 pairings (33.8%) matched at a score
of 75/100 or better
o Only 66 (.01%) scored at 90/100 or better
o Average pairwise score: 74
● What this means: only .01% of the samples
scored as a ‘similar’ malware family

42. python/meterpreter/rev_tcp

43. c/meterpreter/rev_tcp
● Same 499500 possible pairings
● 267387 pairings (53.5%) matched at a score
of 25/100 or better
o Only 2615 (0.5%) scored at 90/100 or better
o Average pairwise score: 37
● What this means: only .5% of the samples
scored as a ‘similar’ malware family
o but wider variation than Python families

44. c/meterpreter/rev_tcp

45. cs/shellcode_inject/flat w/ Arya
● Same 499500 possible pairings
● Only 5 pairings (0.001%) matched at a
score of 25/100 or better
o none scored at 90/100 or better
● What this means: 0% of the samples scored
as a ‘similar’ malware family
o variation was all over the map!

46. Recap
● Started our research out of necessity but
continued it out of curiosity
● Fuxoring AV vendors really isn’t that
difficult
● There are still ways to stop us :)
● #avlol

47. Questions?
● Contact me:
o @harmj0y
o harmj0y@veil-framework.com
● Read more:
o https://www.veil-framework.com
● Get the the goods:
o https://www.github.com/Veil-Framework/Veil
o https://github.com/HarmJ0y/stagers