Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: malware

SANS FOR610: Reverse Engineering Malware – Course Review

malware_chrome

What follows is a review of the SANS FOR610: reverse engineering malware class taken at the SANS Prague 2013 event. What follows are rough notes, feelings and impressions from the class as it was taking place… Take it as you will, and I hope it proves useful for you in evaluating the class.

Note: Prior to the class I’d never done reverse engineering of malware… however I have done limited exploit dev and other tasks that dovetail well with some of the concepts.

Day1

Day 1 started off slowly walking through some simple malware using some behavioral and code analysis, before moving into the setup of our lab environments. Although the first half of the day was a little slow (and instructor led, so no hands-on), it brought everybody up to speed on what we’d be doing in the coming days and helped to lay the foundation for some of the more fun topics I’m sure are headed our way in the later part of the class. After a quick bite to eat we moved into the first hands-on section of the class.

The afternoon was spent slowly walking through the step by step process of performing a behavioral analysis of brbbot in our labs. The pace for the hands-on was a little slower than I’d have liked, but the step by step methodology helped really push home the process required. It was also nice to see procDOT (from the Austrian CERT team) mentioned as well, as an easy way to perform some of the steps.

The day finished off by walking through debugging brbbot in OllyDBG to perform code analysis and dive into some of the malware’s inner workings. Again that walk-through with the class was slow-paced with a few students struggling. With a class like this it’s hard to find a suitable pace to ensure everyone can follow along. That said, even though I’ve never done malware reversing before day 1 seemed slower than it really needed to be in a lot of places.

Day 2

As is standard with most SANS classes, we kicked-off day 2 with a quick recap of the topics covered in day 1 of the class, finishing off the day 1 material with a brief discussion of what should be included in a malware analysis report.

Diving into the real day 2 content we starting looking at commonly seen packers and how to deal with them. Aside from the simple UPX cases (which are apparently more common than I thought in malware) we looked at dumping the unpacked code from memory using a number of tools. Unfortunately we didn’t dive more into the process and how to do it without the tool. I know this isn’t a simple process, but I’ve always been more of the “do it the hard way and learn, before you use the point and click tool” guy. Still you can’t have everything, and the walk-through on doing the same kind of dump using OllyDbg and the OllyDump plugin was an interesting diversion.

After a quick bite to eat we ventured into some patching of executables using OllyDbg (in particular patching to avoid debugger checks). Moving away from Windows executables, we began looking at analyzing browser-based malware.

After going through the standard JavaScript de-obfuscation techniques (as well as some debugging of JavaScript with Firebug) we moved on to a brief (possibly too brief) look at Java based malware. To finish up the final hour we dove into SWF decompilation and static analysis of some older Flash malware. The tools and techniques covered were not that different from what we’d already covered. Seems that the debugging of SWF files is still trickier than it should be (at least without the aid of costly and specialist Flash debuggers). There’s just too many ways to trick the tools into misunderstanding the code, and an area that needs a lot more research.

Day 3

No reversing class would be complete without some serious time spent crawling around in assembly. The morning was filled with the usual fare, compilers, linkers, commonly seen assembly codes and the like. Nothing that most wouldn’t have already seen and read if they were interested in this area of security. Where I think the topics really made things clear was breaking down recursion and jumps and looking at the raw C and compiled assembly versions (or one possible assembly version). It really helped to show that you can tell if the original code was a loop or an If Else. Probably nothing earth shattering for most, but I found it interesting to go down to the level. We also covered jump logic extensively looking at the way the registers are used to store the results used for common jumps. Good stuff to know if you’re reversing unknown code.

The afternoon covered some anti-disassembling examples that malware authors use to cause headaches for people reversing their work, before moving into the final real topic of the day, user-mode rootkits. The afternoon session seemed to be a little rushed, maybe due to some delays earlier on in the day. Day 3 certainly tries to cram in more than previous days have and it showed at the end with a few sections covered in a little less detail than I’d have liked. Pity really, as I’d rather a few day 1 or 2 topics were given short shrift and replaced with more time to really dig in and look at sniffers, keyloggers and the like in Olly/IDA. Overall though, the best day so far… very good stuff!

Day 4

After a sleepless night (gotta love hotels) we dove into self defending malware and started to look at some of the more commonly seen anti-debugging techniques used by modern malware. Kicking things off we manually walked through a malware sample using SEH to fool analysts, and a simple packer to prevent easy analysis of the real malware. The same was interesting in the way it used multiple techniques to fool people trying to understand the executable, but was pretty simple to bypass the protections given a few minutes and a few hints on how it works. The SEH trick was an interesting one and not one that I’d thought of before (I’m not a malware analyst after all).

The afternoon continued on from the morning session dealing with more anti-debugging tricks used commonly by packers and malware writers (including timing based RDTSC and TLS Callback techniques, amongst others). Some of these techniques are probably well-known and documented amongst analysts, but as I’ve said before, as a non-malware analyst the techniques were new to me and made for an interesting afternoon in OllyDbg and shellcode.

finishing off the theme of malware that fights back, we moved into some web-based malware and JavaScript obfuscation techniques.

Day 5

Despite only 1.5 hours sleep (don’t ask…) day 5 started quickly diving into malicious Office and PDF documents. After covering the basics, we moved into some quick analysis of malicious samples using a range of tools and scripts. As expected, the PDF section of the class was a relative what’s what of Didier Stevens research. Some of it is things I’ve already read or seen based on Didier’s wonderful training and workshops. Still, there were some interesting extensions to this using tools like shellcode2exe to create a debuggable PE in order to walk through injected shellcode in a more controllable way. I particularly liked the technique of using libemu’s sctest to create an overview of what the shellcode is doing. Something that will definitely come in handy…

Moving away from malicious files we focused on the uses of memory forensics and how malware analysis can be performed on forensic images. As expected, volatility played a big part of the afternoon, using it to check connections, find hidden processes and dump out the unpacked malware from memory into a PE file to be analysed in the normal way. Using some of the more run modules in volatility we looked at detection of kernel and user-level rootkits and how to extract information from memory dumps that help us as malware analysts understand what malware is doing on a system.

Day 6

CTF style challenges to reinforce the material covered in days 1-5… I won’t go further into this, but the experience was a good one for sure! I managed to hover around 10th position before having to head off early to catch a train. Not stellar, but for a first time malware analyst, I guess it could have been worse ;)

Conclusions

The pace of the class was a common theme for me throughout the first half of the week, but quickly picked up pace midway through day 3. There’s a number of reasons for this, and it was hard to tell if the class was just paced for a more beginner crowd (disclaimer: I’ve never done malware reversing, but I’ve used a majority of the tools before for various other tasks/purposes), or if the pace was effected by a few people in the class that seemed to get lost pretty easily. I won’t launch into a tirade here about people doing technical classes and not having the chops for it, so consider the issue of pace discussed ;)

The tips/tricks and general processes for working with malware were very clearly discussed and worked very well during the course. How they work in real life with modern malware that wanted to stop you at every turn is to be seen. Although we covered some of the more common methods used by malware to cause problems for analysts, there’s no way you can cover them all. Things like that can only be learnt from experience and expose to different techniques and methods after all. The processes helped me quite a lot with a few debugger questions I had. Not just when it comes to malware, but also for more offense-based reversing (thick clients etc…)

The class is very tools based. This isn’t necessarily a bad thing, as most of what we do on a day-to-day basis is tools based… but the first half in particular lacked a certain amount of “rolling up your sleeves and getting into the dirt” that I personally like to see from classes like this. Although it’s a hard way to learn, I find that learning the hard way before you just load a tool makes you respect and understand the issue and the solution. This was dealt with better in the final days with much more hands on stuff. Also, as much as people like to say the day 6 CTF style challenge is a wasted day, I found that some parts of it helped bring back points I’d forgotten from the earlier parts of the class. This really helped reinforce things for me.

Overall the class was good for a beginner just looking to get a grounding in the topic. That said however the pace made it feel like the class could have achieved so much more in the first 2 days in particular. Missing were more automated and scriptable debugging of malware. Things like pydbg, vdb/vivisect and a number of other script based debuggers would have been nice to cover, even if only in passing. A number of the examples really fell into the category of easily scriptable, and it would have been nice to get some hands on with that stuff.

I think the class really came into its own in the later days… much more focused, technical and designed to really stimulate your thinking.

{BruCON} Botnets and Browsers – Brothers in a Ghost Shell

Botnets and Browsers – Brothers in a Ghost Shell

Aditya K Sood

Browsers exploitation is on rise. Botnets in conjunction with Browser Exploit Packs (BEP’s) are becoming the source of incredible malware infections. The exploitation revolves around the manipulation of browser architectures thereby infecting victims at large scale. Malware infection is proliferating day by day. In spite of the new advanced protection features, subverting the infections that happen through browsers and take control of the victim’s machine remains an arduous task. Exploit packs and attack toolkits play a critical role in the success of malware infections. Browser Exploit Packs (BEPs) are based on the basic philosophy of exploiting the extensibility of browsers by utilizing the technology and developing a code which should work in line with the browser classes.

Talk Outline

  • Browser Malware Taxonomy
  • Bots & Browsers – Collaborative Design
  • Bots & Browsers – Exploitation Paradigm
  • Bots & Browsers – Web Injects / Fakes
  • Conclusions
The big problem is the theft of funds through online attacks.

Browser Malware Taxonomy

Class A – Browser Malware
Exists in the browser process (user-land)
Class B – Browser Malware
Exploits the browser or extensions/plugins
Class C – Browser Malware
Exploits the underlying browser to gain access to Kernel-land

Infection Model – Malware serving

  • Exploiting Web Vulnerabilities (XSS/SQLi)
  • Obfuscated code injected
  • JavaScript eval() – Evil Machine
  • Browser DOM calls
  • Browser loads malicious URL
  • Vulnerability in browser exploited
  • Exploit triggers shellcode
  • Malware binary drop
  • Parasitic infection occurs
  • Malware installed and connect back

Browsers –> Botnets :SDK

Custom designed SDK for communications.
SpyEye has an extensive SDK
Design of Plugins
  • Bot requires separate plugin to communicate with C&C
  • Botnet sends critical information through GET requests
Why use plugins?
  • Provides modularity
  • Updatability
SpyEye APi in action
SpyEye Bot –> Custom Connector Plugin –> Gate.php
The custom connector plugin allows for update bot configuration / executables as well as plugin management and 3rd party executable loading.
Bots & Browsers – Exploitation Paradigm
  • Ring 3 rootkit
    • Hooks DLLs in user-land space
    • Perform injection in web process
  • Hooks HTTP communication interface
    • Exploit browsers
  • Infection (Bots & Plugins)
Man in the Browser
  • Malware (bot/trojan) having ability to infect browsers
  • Capable to modify web pages and perform legitimate actions
  • Invisible to the user
  • Steal credit card data
  • Spying on browser sessions
Hard to protect against in the browser itself. Protections need to be at the server-side. SSL won’t help as the attacker is already in the browser itself.
User-Agent Fingerprinting used to detect the browser exploits to use. UA string provides a great deal of information for an attacker to fingerprint the correct attack vectors. Detection code used by malware writers is often very generic. Entries for everything from Win95 and greater.

Browser Exploits Packs and Bots

  • Used in conjunction with botnets
  • On successful exploitation, bot is dropped into victim machine
  • Harnesses the power of two different frameworks to deliver malware
  • Same traces have been seen of ZEUS (botnet) + Blackhole (BEP)

Browser – Screen Scrapers

  • Capture screenshots from a victim during banking transactions
  • Possible to capture whole system screenshots, not just the browser
  • Provides additional support for bots for data exfiltration
  • Exploit system level functions
Automatically start capture once a victim connects to a banking website. Private browsing doesn’t help this…

Browser Form Grabbing

  • Keylogging produces too much data
  • Form grabbing extracts from  GET/POST
  • Based on the concept of hooking and DLL Injection
  • Virtual Keyboards
    • Implements the form grabbing in the POST request to avoid issues
    • No real protection against malware
All botnets use this technique, and all browsers can be circumvented to execute non-legitimate hooks. Hard to overcome.

Credit Card Grabber – Verification

Why credit card number stealing is a success!
  • Botnets are always successful in extracting credentials from POSt requests
  • CC Verification – The credit-card number is verified against the LUHN’s algorithm prior to sending to the botnet database
    • Trash is dropped
    • Doing the same checks that the banks make!

Bots & Browsers – Web Injects / Fakes

Web Injects – Infection on the fly
  • Injecting incoming request with malicious content
  • Web Page is tampered which looks legitimate
    • Primary aim to inject credential stealing forms and input tags
    • Similar concept is sued into injection pointers to remote malware sites
    • Concept of third generation botnets
Web Injects – How
  • SLL Injections
    • Long live exploitation techniques
  • Browser Libraries
    • ffhook.dll
      • Hard to edit the FF executable, so DLL injection works best
    • iehook.dll
    • WebInjects.dll
SpyEye WebInjects Parameters –> secniche.blogspot.com
Being in the browser you can customise the WebInjects to match any website required. Customisable and complex rules on what to capture from GET/POST requests. Extraction of sections of the request only.
Web Fakes
  • Plugins are used to spoof content to the browser
  • Supports both protocols (HTTP/HTTPS)
  • Based on the concept of internal URL redirections
  • All browsers are affected
User requests their banking website. Using tricks like CSS injection, it returns fake versions of the site to gather the required data. Lists of which site to fake and which to leave are configured in the botnet.
Links:

DeepSEC: DYI malware analysis with Minibis

DYI malware analysis with Minibis Aaron Kaplan & Christian Wojner

Minibis 2.1b is available for download

Anubis = Analyzing unknown binaries

Problem: malware can check if it runs on the Anubis server (via IP addr)

http://avtracker.info

actually it was a proof of concept to check if specific malware checked if it was running inside a VM

Minibus

Minibis is a total rewrite (no code from Anubis used)

Take 5,000 samples and run them through to check what percentage detect if it’s running in a VM

Behavioral Analysis

  1. Prepare system (VM) with monitoring tools
  2. Transfer sample to VM
  3. Start up monitoring tools in the VM
  4. Run sample
  5. Gave sample some time to do its thing
  6. Save monitoring logs and transfer them back
  7. Analyze logs
  8. (revert VM)
  9. (repeat)

Architecture

Started off with a simple host and virtualized system

Has evolved into a complex multi-system environment to transfer and run the required analysis

Allows for parallel running of malware samples to speed up processing

Minibis is a practical framework to simulate the process a malware analyst would perform.

It’s up to the user to customize to their specific needs.

Customization done using a simple bash script in several key locations

Toolset available with pre-built, customizable widgets.

GUI configuration of many aspects of the environment

Can be configured to run with VirtualBox (default) or VMware

Easy configuration of post/pre run actions, including a list of files to extract from the target after the malware has run.

New in version 2.1: Customized filetypes

Matching based on extension, FILE tool, or regex

postminibis

Analyse results, classify (alert, warning, info)

Then quickly filter for those that are interesting (alert?)

Future

2.1 is in beta

Next full version will be available in summer 2011

  • Parallelization
  • Diffs over different VM configurations
  • GUI for postminibis
  • Installer
  • Support for more VMs (VMware, QEMU)
  • 64big Linux support
  • OSX support
  • Support for physical machines (data recovery cards)
  • More sample based scripts
  • Community

Links:

[BruCON] The Monkey Steals the Berries

The Monkey Steals the Berries (Tyler Shields)

Why would an attacker target a phone

PC’s are becoming smaller and smaller as more data is moved to the mobile platform. Mobile devices are also commonly less protected than desktop systems (like going back in time in some cases). It also allows for very targeted attacks.

The mobile arena is currently growing more than any other operating system. This makes it the target of the future. Once the various mobile platforms settle and the 2 or 3 major players are defined, things will become more targeted (as it was with Windows).

Mobile applications are another constant growth area giving another great chance to attack users.

Flexispy (http://www.flexispy.com)

  • Features everything needed for attackers.
    • Yearly costs involved
    • Closed source
    • Exfiltrates data to the software provider where you can view it through a web interface.
  • This makes it a hard sell for attackers.

Mobile Spy (www.mobile-spy.com)

  • Less features, but covers a wider range of platforms.
    • Yearly costs involved (cheaper than flexispy)
    • Closed source
    • Exfiltrates data to the software provider where you can view it through a web interface.
  • Same issues as flexispy, including closed source and no direct control of the exfiltrated data.

Etisalat (SS8)

  • As rolled out in the UAE to Blackberry systems.
  • Used Blackberry PIN messaging as the C&C channel. Captured outbound SMS and Emails with complete control given to the provider.
  • Was discovered due to issues users reported with battery life

Storm8

  • Creator of games like iMobster and Vampires Live for the iPhone
  • Gathered phone numbers of users. Company claimed it was coded in error

Symbian Sexy Space

  • Exfiltrates data to a website of the hackers choice.
  • Binary was signed as safe by Symbian!

Symbian MergoSMS

  • Came in the form of games and themes
  • Binary signed as safe!

09Droid

  • Created banking applications for the Android platform
  • Did nothing more than pass calls through to the bank
  • No malicious code found… Could easily have happened however!

3D Anti-Terrorist, …

  • Dialed premium rate numbers (8 per month)
  • Waited 3 days before starting to avoid easy detection
  • Slow win instead of a fast big pay-off
  • Repackaged legitimate game to be malicious

Mobile Security Mechanisms

Only 23% of smartphone owners use the security software installed on a device

13% of organisations currently protect from mobile devices

A balancing act between usability and security.

Corporate Level security Policies

  • Applied at the corporate IT Level
  • Can’t be modified by the end-users

End-User Level security Policies

  • Could be assigned from a provider
  • Can be overridden by end-user
  • Not as common as Corporate protections
  • Not as strict as Corporate protections

Mobile Anti-Virus

  • Implemented at the handset itself
  • Fails due to the same reason PC antivirus is failing today

Checks code

  • How are people like Apple checking apps in the app store?
  • Not all checked code is secure!

Code Signing

  • Subset of Blackberry API considered “controlled”
  • Use of controlled package, class, … needs signature
  • Can be yours for only $20
  • Hash of code sent to RIM (Not full code)
  • No barrier to entry
  • Signature can’t be revoked for existing apps (only to stop future apps)

Blackberry IT Policies

  • Blackberry Enterprise Server (BES)
  • Supersedes lower level security controls
  • Complex and very in-depth
  • Lots of fine-grained controls
  • So many that mod are set to “Default Allow All” as a result

Blackberry Application Policies

  • Can be controlled at the BES
  • Also mostly Allow
    • Gives an app many permissions by default
  • If you say “don’t trust” app still gets access to email, contact data by default!
    • Can be tweaked on a per-app basis (yeah right!)

Blackberry Spyware (TXSBBSpy)

Many ways to install on systems

Extensive logging and data exfiltration features (including SMS, EMail, HTTP, TCP/UDP sockets, DNS requests)

Technical Methods

  • Data Dumpers
  • Listeners
  • Exfiltration Methods
  • Command & Control

Detection

  • AV fails to detect due to the same issues we see on the desktop
  • Resource usage and whitelisting
  • Sandboxed based execution
  • Code Analysis (possible, but tricky/expensive)

Best solution is to use a Defense in Depth strategy and implement any and all protections possible.

Conclusion

A lot of trust lies with vendor application checks –> This is unwarrented

The only real solution is analysis of code

LINK:

Follow

Get every new post delivered to your Inbox.

Join 129 other followers