Isolating the Ghost in the Machine: Unveiling Post Exploitation Threats

1. Isolating the Ghost in the Machine: Unveiling Post Exploitation Threats Rotem Salinas HTA-R11 Senior Security Researcher RSA Security Rotem.Salinas@rsa.com @rotemsalinas Uri Fleyder-Kotler Advanced Threats Research Lab Manager RSA Security Uri.Fleyder@rsa.com @ufleyder

2. G00d vs. 3v1l Hackers vs. Hackers -> Attackers vs. Security Researchers Security Researchers are losing Always one step behind HERO!

3. Houston We Have a Problem Agentless/non malware attacks is a rapidly growing threat Attackers are implementing stealthier methods to bypass defenses

4. Research Goals • Goals • Find a way to assess a script’s “maliciousness” automatically • Do it without the potential harm of infection • Make it fast! • Narrow the problem space • VBA • Powershell

5. The “Imaginary Engine” • How can we develop such 1337 imaginary engine • Problem solving in 3 basic steps • Analyze • Brainstorming • Implementation • The same concepts can apply to similar problems

6. The First Step – Malware Analyst Standpoint Traditional Static Analysis Approach Find Suspicious Activity Deobfuscate Determine Execution Flow

7. The First Step – Understanding The Attacker’s Mindset

8. The First Step – The Attacker’s Main Objectives

9. Case Study – Dridex Campaign Peaked during 2015-2016. Used Macro in Office Documents to deploy Dridex variants. Targeted many companies and financial entities around the world. Delivered in a large scale Spam/Spear-Phishing campaigns

10. Case Study – Anunak/Carbanak Financial APT Only 1 submission to VT Attributed to AnunakCybergang

11. The Second Step – Brainstorming • Common approaches pros and cons • Hooking • Use available source code or patch existing dll/exe • Inserting code that would sink certain expressions • Remove potentially harmful code • Taint Analysis / Symbolic Execution • Implement an engine that would emulate the language interpreter • The engine should evaluate each line of code • Instead of invoking potentially harmful expressions would sink them

12. We Have a Winner! • Symbolic Execution • Pros • Cannot harm the machine in any way (even if we missed something) • We know exactly how it works. NO Reverse Engineering. • Cons • Hard to Implement • Might lack some language functionality

13. Symbolic Execution: Double Sweep Method • First sweep • Global context • Global variables • Code • Function declarations • External DLL declarations

14. Symbolic Execution: Double Sweep Method • Second sweep • Function code - starts with entrypoint • Follows execution flow • Executes stubs instead of built-in language functions • Evaluates expressions • Math • String manipulation • Logical expressions (condition evaluation)

15. Implementation Details • Python • PyParsing • Dave Beazley’s (Python guru) PLY – Python Lex Yacc • Lex – lexical analysis/tokenizer • Yacc(Yet Another Compiler Compiler) – Syntax Analyzer • BNF – Backus Naur Form • Where to start  RTFM

16. Lexical Analyzer (Tokenizer) * Diagram courtesy of David Beazley • Tokens • Language keywords • Immediate values • Strings • Integer/numeric values • Floating point values • Arrays/compound data-types • Identifiers – variable names, function names, object names • Operators – math, bitwise, logical, string manipulation

17. Syntax Analyzer (Parser) * Diagram courtesy of David Beazley Parses a language syntax according to the tokenized output from the lexer The language syntax/grammar is defined by multiple functions Each function represents a BNF expression and will pass the parsed/extracted values to the next function inline according to the BNF statement

18. PLY Lex Example * Diagram courtesy of David Beazley

19. PLY Lex Example * Diagram courtesy of David Beazley

20. PLY Lex Example * Diagram courtesy of David Beazley

21. PLY Lex Example * Diagram courtesy of David Beazley

22. PLY Lex Example * Diagram courtesy of David Beazley

23. PLY Lex Example * Diagram courtesy of David Beazley

24. PLY Lex Example * Diagram courtesy of David Beazley

25. PLY Lex Example * Diagram courtesy of David Beazley

26. Tokenizer Demo

27. PLY Yacc Example * Diagram courtesy of David Beazley

28. PLY Yacc Example * Diagram courtesy of David Beazley

29. PLY Yacc Example * Diagram courtesy of David Beazley

30. PLY Yacc Example * Diagram courtesy of David Beazley

31. PLY Yacc Example * Diagram courtesy of David Beazley

32. Engine Design Overview • Scoring • Blacklist (score++) • Whitelist (score--) • A higher score -> more malicious • If score >= threshold Then isMalicious = True;

33. Heuristics If an object is created from a string and the string is a result of a function call then it is highly probable that the code is malicious Data read from controls embedded in the document is considered suspicious Objects creating other objects Self modifying code during runtime

34. Demo The Engine

35. The Age Old Question of FP vs. FN False positives False negatives Decide what works best for you!

36. Lessons Learned • Challenges • Condition evaluation • Recursion limit • Lessons • When in doubt bruteforce! • Use the language specification guide as a guideline rather than implementingevery language feature that exists

37. Apply • Download our POC: link • DIY 1: Develop It Yourself • DIY 2: Deploy In Your Organization • Network • Endpoint • Use for your investigations

38. Q&A Rotem Salinas Uri Fleyder-Kotler • Rotem.Salinas@rsa.com • @rotemsalinas • Uri.Fleyder@rsa.com • @ufleyder