The Ultimate Deobfuscator - ToorCON San Diego 2008


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • of arguments.callee.toString() and how this makes analysis harder. This method allows a function to reference itself, and hence allows a function to detect modifications to its own code. Changing eval() to print() changes the function string, and with it the result. This can usually be defeated by re-defining the eval() function into a simple call to print(), but not so in this case. So let's take a look at some of the protection features in detail.
  • Too high level, need to see results at a lower level.
  • There have been several presentations on building JavaScript simulators in the last two years.Let me show you how our simulator within Websense Security Labs works…
  • When creating a simulator, the simulator must implement all the objects and functions that would be available by the browserSuch as document.write, alert, location.href, navigator, screen, etc.Also you have to load external pages. And all the js code from them, simple to break! Also have to deal with the transaction.If any of you have attempted to write any cross-browser JavaScript you’ll also know that there are lots of differences between them and how they interact with the Document Object Model or DOM inside the browser. Imagine the number of methods to test against to make sure the simulator has implemented everything necessary as well as how it has implemented it.
  • Lacking any object or function will result in an error in deobfuscation process
  • We want to see CreateElement for iframeOr SetAtribute for clsid, etc.CreateObjecte.g msxml2.XMLHTTP, Shell.Application,, etc.
  • Cover this slide in detail…
  • codes that employed one or several of the "document.referrer", "document.location" and "location.href" properties as part of the decoding process.
  • Also doesn’t work for vista or 2003 due to aslr, and the dll base addresses being randomized.We have it working on 2000 and XP.
  • document.write – write to a webpageeval – evaluates a string and executes it as if it were script codeDocument.write was pretty straight forward to hook.Eval wasn’t as straight forward. I had to hook it in the middle of the functon in order to get access to the buffer I wanted to output…kindadity, but it works.But there are tons of other functions within these two dlls that would be interesting to hook and log for analysis.
  • Let’s take a non-malicious example to start.We see x*y or 10*20 which we see in the browser outputs as 200We see 2+2 which we see in the browser as 27And we see 10+17 which makes 27.The hooking has been done in such as way that a dll has been injected inside of IE, hooked document.write and eval and has outputted The results to a DbgView window.
  • So lookng at DebugView we can see the same output that was computed for the browser.
  • Now let’s look at a malicious example.Left off here…
  • Where before an incomplete simulator would failA hooked decoder will have no trouble logging dynamic content.
  • Obfuscation does not equal malicious, we must be able to tell the difference.Malicious files, exploits and content is found on the webAnd security researchers who don’t have the tools needed to analyze web content are going to be missing out on A key ability
  • I will be releasing a blog next week where I’ll release the hooking code that accomplishes what I’ve talked about in this presentationAnd is a subset of what we’ve written for our infrastructure that works on a much larger scale.I also want to mention that we have two open positions, so if you’re interested drop your CV or card my way.
  • The Ultimate Deobfuscator - ToorCON San Diego 2008

    1. 1. ToorConX - The Ultimate DeobfuscatorStephan Chenette, Principle Security ResearcherWebsense Security Labs
    2. 2. AgendaThe Ultimate Deobfuscator: Hooking versus Simulation The Obfuscation “Problem” The “Simulated Solution” The Ultimate Deobfuscator Concluding remarks 2
    3. 3. The Obfuscation “Problem” Most malicious webpages today are obfuscated. 3
    4. 4. An obvious malicious redirect 4
    5. 5. What we actually see in the source 5
    6. 6. DeObfuscation…how far we’ve come… Replacing all occurrences of "document.write" with alert. Replacing eval with document.write Forcing document.write to write between <textarea></textarea> tags But malcode authors added anti-debugging traps like arguments.callee.toString() to break the flow of execution if code were changed in anyway. 6
    7. 7. Script Debuggers… Microsoft Script Editor (MSE) Rhino (Mozilla’s JavaScript debugger) IE Developer’s Toolbar Firebug 7
    8. 8. The “Simulated” solution Various toolkits have been released to Safely Investigating Malicious JavaScript – HTML Parser – DOM Implementation – Scripting Engine(s)/Interpreter(s) 8
    9. 9. The “Simulated” solutionRecent Presentations: Websense – (Alex Rice & Stephan Chenette) PacSec Arbor – (Jose Nazario) CanSecWest SecureWorks - CaffeineMonkey – (Ben Feinstein & Daniel Peck ) Blackhat 9
    10. 10. 10
    11. 11. 11
    12. 12. 12
    13. 13. 13
    14. 14. 14
    15. 15. 15
    16. 16. 16
    17. 17. 17
    18. 18. 18
    19. 19. 19
    20. 20. 20
    21. 21. 21
    22. 22. Objects/functions that must be provided Native JavaScript Browser Supplied eval() alert() String.fromCharCode() document.write() escape() location.href Math.random() window.status 22
    23. 23. Incomplete simulator 23
    24. 24. The ultimate goal would be…. A headless browser basically…. Non-graphical browser that would give us all the details internally of what’s going on without rendering the content. That wouldn’t allow successful exploitation. 24
    25. 25. The Dream… Deobfuscation results – eval, document.write Navigation to a new page Pop-ups prompting user to install an exe DNS errors Changes to the DOM, additional iframe elements or image elements Loading of ActiveX controls, success or failure and CLSID Iteration of the DOM whenever we wanted. All to do this automatically without a debugger 25
    26. 26. Another solution…The “Ultimate” Deobfuscator… What better to use to deobfuscate content than the full browser itself? This presentation focuses on Internet Explorer, but this technique works for every browser. 26
    27. 27. Is it really that easy? Hook the right functions insides the browser and just sit back. 27
    28. 28. Hooking is a dirty job Especially when you’re functions that are neither exported or documented. Requires changes if browser dlls are updated 28
    29. 29. What’s hooked…the basics mshtml.dll – document.write jscript.dll – eval 29
    30. 30. Other interesting events to hook URL redirection Object creation DOM Element additions, removals DOM Attribute additions Etc. 30
    31. 31. In action… Inject the DecoderHook DLL 31
    32. 32. In action… 32
    33. 33. Output now resembles browser 33
    34. 34. Malicious deobfuscation example 34
    35. 35. Malicious deobfuscation example 35
    36. 36. Malicious obfuscated source code 36
    37. 37. Malicious deobfuscation log 37
    38. 38. Malicious deobfuscation log 38
    39. 39. 39
    40. 40. Suspended, but still malicious 40
    41. 41. Hooking has multiple advantages 41
    42. 42. Conclusion Obfuscation != Malicious Security Researchers analyzing web content must have a solid deobfuscation tools to deal with today’s malicious webscape. Hooking the browser is one more solution for manual reversing of obfuscated content. 42
    43. 43. Thank you. Any questions? I will be releasing POC code for this in a blog next week. Also…We’re hiring! One intern and One-Full time position open! San Diego position - Research/Dev skills, C, PERL, etc.! Check out our website and blogs 43