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

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

Category Archives: Security

{quick post} PySC Project

Back at the beginning of 2012 I played around with some Python ctypes as part of a project I was working on in the background. At the time I released a few code snippets that used ctypes to do a few fun things, but never really got around to releasing the main project I was working on.

Python ctypes posts from 2012:

PySC_ascii_art

The main project I was working on was a simple Python script that injects shellcode into a running process using CreateRemoteThread (nothing brand new here). The interesting part of the project (for me anyway) was the ability for the Python script to request the shellcode to inject using DNS TXT requests, ICMP request/responses or simple HTTP(S) request (using SSPI if required). I demo’d the code at the BSides London conference in 2012 at the underground / lightning talks an had some positive feedback, however the time just hasn’t been there to finish things off since then.

As a result of the lack of time to finish things off, I’ve put up the latest modular version of PySC (version 0.8) on Github for people to use, tear apart , and generally laugh at as you see fit. As the project is still in prototype your mileage may vary.

PySC was designed to be configured using the config.py file present in /config directory, and run headless on a Windows system after being packed into an executable using something like PyInstaller. However you can run it using command line options as well by running it with -h to see the various options.

The /optional directory also includes some example server-side implementations for Metasploit and a Python Scapy ICMP listener for delivering Shellcode to the PySC client.

Check the source-code for details…

https://github.com/ChrisJohnRiley/PySC

PySC 0.8 (prototype release – 26 December 2013)

PySC expands on the numerous available tools and scripts to inject into a process on a
running system.

Aims of this project:

- Remove shellcode from the script to help avoid detection by AV and HIPS systems
- Offer a flexible command line based script
- Also provide the ability to run fully automated, as an EXE (by using pyinstaller)

To this end this prototype script offers the ability to download shellcode from a
remote DNS server (using TXT records) or through Internet Explorer (using SSPI to
utilize system-wide proxy settings and authorization tokens) and injects it into a
specified process. If injection into the specified process is not possible, the script
falls back to injecting into the current process.

Module dependancies: none

Notes:

PySC will by default run silent (no user feedback) to enable user
feedback (error/status messages) please use debug mode (-d/–debug
at command-line, or set debug = True in the script itself)

Any command-line options passed to PySC at runtime override the
hard-coded values within the script.

To use PySC as a stand-alone executable, set the desired parameters
in the script itself, and use pyinstaller to create an .exe

{Book Review} Offensive Countermeasures: The Art of Active Defense

A few months back at Blackhat, John and Paul were nice enough to give me a copy of their book “Offensive Countermeasures: The Art of Active Defense” to read. It’s been a whirlwind few months since then, but the quiet of Christmas has given me a chance to really sit down and soak up the contents.

offensive_countermeasures

Active Defense has been getting a bit of a bashing after all the “hack back” bullsh*t that people have been throwing around. John and Paul make a good effort to put some of this to rest by really discussing the things that an enterprise really can achieve without getting into the revenge of hacking the hackers business. Some of people’s main concerns in active defense have been the lack of information on what you can and can’t do in the eyes of the law. The first section of the book puts a spotlight on a few court cases that deal with differing degrees of hacking back or active defense… and not all successful ones. This section helps to put the books content in focus and aims to really explain the whys and whatfors to come in the sections that follow.

The main section of the book is split up into the 3 A’s. Annoyance, Attribution and Attack. Each section goes into depth on some of the options enterprises have to more actively defend their networks. Each section has a number of example tools, mostly focused around the ADHD distribution, that people can use to perform some of the actions discussed.

I found it particular interesting that the book finished off with a section dedicated to core concepts. Far too many companies think they can jump from 0 straight to 100 without building a secure base to build from. Active defense isn’t for everyone, and if you don’t have your basics all in-hand, then anything you do is more likely to backfire than help.

The book itself is compact, but is a good starting point for meaningful discussions about active defense that don’t devolve into legal arguments from moment one. Because of the compact size of the book, there are a few things that aren’t really discussed although they fall into the active defense category. These omissions where a little disappointing, but keeping true to the core of active defense makes sense for what has to be seen at the first introductory text on the subject. Here’s hoping that future revisions expand on the base and start covering fun things like honeytokens. Overall the information that is presented is useful for people looking for a quick schooling in how they can use active defense to improve their overall level of security, and as an education for people who jump straight to hacking back without considering any other options.

If this book is anything to go by, the discussion on what really is possible in defending your networks intelligently from attackers should be a very interesting one to follow. The time for standing still and just taking punch after punch is over. Time to duck and dodge, and make it harder for attackers!

Links:

DEF CON 21 Video – Defense by numbers: Making problems for script kiddies

For those that didn’t manage to wake up for the crack of dawn DEF CON Sundays slot, the fine folks over at DC have released the videos of most (if not all) presentations –> https://www.youtube.com/user/DEFCONConference/

My presentation, for those interested, can be found below.

http://www.youtube.com/watch?v=H9Kxas65f7A

Links:

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.

Follow

Get every new post delivered to your Inbox.

Join 118 other followers