Showing posts with label ctf. Show all posts
Showing posts with label ctf. Show all posts

12 November 2022

Flare-On 9 - The Worst Writeups

Since its inaugural year I have been a participant in the FireEye / Mandiant Flare-On challenges produced by FLARE, the FireEye Labs Advanced Reverse Engineering. FLARE is one of the industry's most accomplished team of reverse engineers and they have created an annual CTF/ that focuses on reverse engineering challenges, many of which are rooted in real life attacks and incident responses.

I have blogged about FLARE challenges in the past and many readers have noticed that my write-ups tend to steer towards the unexpected solutions. The fun, unconventional, and sometimes offensive solutions to the reader. After all, this is a time to have fun and play with challenges that I do not see on a regular basis. Much of my this originates from my prior experience in a reverse engineering team that focused on intrusions from nation state attacks. Our metrics were on how quick we can provide answers, not how in depth or concise we could be. So my immediate goal is on speed, identifying short cuts, and exploiting every advantage I can find. And then putting the proper methodology into tech debt.

And so, with the completion of Flare-On 9 (2022 edition) I have highlighted my own horrible solutions to a few of the challenges. 

02 May 2016

GrrCon 2015 - Memory Forensics - Grabbing all the Flags...

Today we bring you a special guest posting by Tony "@captcook32" Cook. Late last year GrrCon hosted their anticipatory excellent set of challenges which included an in depth memory forensics challenge by Wyatt Roersma. Tony and myself took a few days on a down week to try our hand at the challenge. I lacked the answers to two questions while Tony knocked them all out quickly.

While the scoreboard was reset to before our scores were posted, I'd like to present Tony's write-up on the challenge. The challenge files are still available for download, so feel free to try the challenge on your own and return for hints. Next to each question is the file required to answer it and the password needed to open the archive.

And so follows Tony Cook:





In October 2015 Google put on the GrrCon 2015 CTF challenge which was open to all who wanted to attempt the challenge. My colleague "The Brian Baskin" @bbaskin let me know it was going on & I wanted to test out my memory forensics skills so I gave it a shot. This was one of the most fun & valuable CTFs that I've ever done. I want to give a huge shout out the the Volatility team for their awesome product & for the GrrCon 2015 CTF team for having a semi real world challenge that made you think outside of the box. The following blog post is my walkthrough of how I got through the challenge. There are most likely far better ways to go about doing most of these & I don't claim to be a memory forensic expert but I hope this helps out anyone who got stuck on any of the questions &/or anyone looking for an explanation. 

Question #1


We start out with a question letting us know that user opened a "strange" email that appeared to be a security update, kudos to the CTF creators because who hasn't seen that happen... All we need to provide is the sender's email address. As with all of these questions there are about a million different approaches that we could take to find the answer, however, the way my lazy mind works I wanted to start by finding all the email addresses within the memory dump, then use that list to grep through the memory dump for these email addresses to hope for an email that would resemble the user's . So to start with I utilized Garfunkel amazing tool, the Bulk Extractor. Among several other options this tool can provide you with a histogram of email addresses which will provide us a starting point to start looking through the memory dump.


22 September 2014

A Walkthrough for FLARE RE Challenges



The FireEye Labs Advanced Reverse Engineering (FLARE) challenge was causing a bit of a buzz when it was announced and launched in early July. It read like a recruitment campaign for a new division within FireEye, but still a fun challenge to partake in. The challenge started ... and I was on-site at a client site for the week and forgot all about it. 

Busy under the pressure of releasing the new Dissecting the Hack book, the challenge went to the back of my mind until the 24th of July. I was facing a pretty hard-hitting bit of writer's block and frustration. I agreed to let myself have a break to do the challenge for one week before getting back to my commitments.

After the challenge finished, and answers and methods started floating around (notably CodeAndSec's), I realized that many of my tactics were completely different from others. I'm sure that's to be expected from this field; many of my methods were from working in an environment without Internet access and without an expert on-call for answers. I'm also fully from a forensics background (hex editors and data structures and file parsers, etc), and work in commercial incident response with RSA, so I'd be sure to tackle problems different from someone who had a pentesting or vuln discovery background.

Although the challenge started in early July, it ran up until 15 September. There was an unspoken moratorium on answers/solutions while the challenge ran, but now that the samples are all freely available from their website, some are coming forth with how they completed them.

This is my story.


Challenge 1


The first challenge started out with downloading an executable from the flare-on.com website. I immediately threw it into IDA and started poking around, only to discover that it was just a dropper for the real challenge :)  I let it do its thing, agreed to a EULA without reading it, and received the first challenge file:


File Name       : Challenge1.exe
File Size       : 120,832 bytes
MD5             : 66692c39aab3f8e7979b43f2a31c104f
SHA1            : 5f7d1552383dc9de18758aa29c6b7e21ca172634
Fuzzy           : 3072:vaL7nzo5UC2ShGACS3XzXl/ZPYHLy7argeZX:uUUC2SHjpurG
Import Hash     : f34d5f2d4577ed6d9ceec516c1f5a744
Compiled Time   : Wed Jul 02 19:01:33 2014 UTC
PE Sections (3) : Name       Size       MD5
                  .text      118,272    e4c64d5b55603ecef3562099317cad76
                  .rsrc      1,536      6adbd3818087d9be58766dccc3f5f2bd
                  .reloc     512        34db3eafce34815286f13c2ea0e2da70
Magic           : PE32 executable for MS Windows (GUI) Intel 80386 32-bit Mono/.Net assembly
.NET Version    : 2.0.0.0
SignSrch        : offset   num  description [bits.endian.size]
                  0040df85 2875 libavcodec ff_mjpeg_val_ac_luminance [..162]
                  0040e05d 2876 libavcodec ff_mjpeg_val_ac_chrominance [..162]

Based on this output from the file, I can see first of all that it was built from .NET 2.0 (based on the mscorlib import). That'll be important later to determine what tool to analyze the file in; IDA Pro is not the most conducive tool for .NET applications.

At this point, let's run it and see what happens:



The image shows some happy little trees and a great, big "DECODE" button. Clicking this button changes the image thusly:



Without any clue of what to do with the challenge, or what I'm actually looking for, I open it up for analysis with Red Gate .NET Reflector.