Saturday, September 11, 2021

Flare-On 2020 Question 2 - Garbage

I'm not exactly well versed in reverse engineering.  I completed the first question easily, here:  https://adventuresincyberchallenges.blogspot.com/2021/09/flare-on-2021.html.  So I thought I'd try question 2.  Oh my goodness.  The difficulty went up a bit.

The second question, I got most of the way through it, but in a really inefficient way, and I doubt I would've been able to complete it on my own.  Like I said, I'm not well versed in this.  So here's what I did.  I examine things in both Linux and Windows.  Linux more for safety purposes, and Windows because native diassemblers and debuggers seem to work better.  Also, I want to note - these are both vms, that I've snapshot and don't have any network connectivity with my host.  I make a backup of the original exe before doing anything.  When I save it, I save it with different names, so I have a step-by-step snapshot of the process.  I can easily go back to the last step if there's a problem.

The first thing I do with an executable is make sure it's an executable. (This is a Linux command, but you can have it in Windows in various ways.  I just use a Linux VM.)

file -i garbage.exe
garbage.exe: application/x-dosexec; charset=binary

Yup, it's an executable.

Then I check to see if there's any strings that can give anything away.  Sometimes the flag is in the executable.  Unfortunately, it's not that easy in this challenge.  

Also, when I'm using Linux Strings, I use different flags in strings to see if the executable has different types of encoding.  In the sysInternals version in Windows, I think by default it checks this, so extra flags aren't necessary.

I notice a couple base64 strings - trying to decode them - they aren't valid of course.

At the end, I notice some xml - I looked it up and found out this is an executable manifest.  I've seen this before in an ICS challenge, but never really looked up what it actually meant.  I'm not a dev.  I do notice it's truncated.  I file that away for later.

Then I use 7Zip to decompress the executable.  Sometimes you can see more things this way.  You can do this with exes.  I see UPX.  I know that that means it might be packed with upx.  Again, I've seen this before in a different challenge.

So I try

upx -d garbage.exe -o garbage2.exe.

I get an error: "upx: garbage.exe: OverlayException: invalid overlay size; file is possibly corrupt."

Of course it can't be this easy.

So I open it in hxd.  I really like this hex editor in Windows.

I look up what this manifest thing is, and without even really knowing what it is, I paste it in, and get rid of the other part of the manifest that was corrupt.  Try unpacking it again.  No dice.  Still an OverlayException.

I've done challenges, and remember that many times, programs work in blocks.  So I add a bunch of null characters to the end of the file.  Still getting errors.  I try to look up the error.  I don't really want to use a write-up right now, because I want to give it a good shot before turning to the write-ups.  I find that it has to do with some kind of checksum.  So I look up tools for reverse engineering.  I have the Flare VM, because the challenge recommends it, so I start opening various tools looking at them.  None of the debuggers will let me open this file.  So I find this tool CFF Explorer.  This shows I might be  right - it was packed with UPX.  I try the unpacker in CFF Explorer thinking maybe it would work - still the same error.  I look it up, and it looks like there are ways to keep upx -d from working.  There's a bunch of information about manually unpacking it, but I don't really know much about assembly.  Then I notice, the PE and File header are different.  For all I know, this is normal, so I look it up. 

Google:  Can a file size and PE size be different?

They can.  https://reverseengineering.stackexchange.com/questions/12121/how-can-file-size-and-pe-size-cant-be-equal.  However, just for the fun of it, since I have no idea what I'm doing, I calculate the size difference.  Remembering that 1 byte is 2 hex characters, I calculate the missing number of bytes, 41472-40960=512.  I open up powershell and print out '00'*512.  Then I appended it to the end of garbage.exe in hxd on the hex side.  Tried opening the file again.  No dice.  Different error this time, though.  Side by side comparison is incorrect.  Looking up this error - there are a bunch of different problems that could be this.  Most of them say, "Try reinstalling the application".  Well, I didn't exactly install this to begin with, so that didn't help much.

So I'm poking around CFF Explorer and notice the UPX utility.  I didn't try unpacking it again since the change to garbage.exe.  Duh.  So I save it and try running it again.  Side by Side configuration error.  Still something wrong.  So I look in CFF Explorer, click around, and then view Dependency Walker.  I see that the manifest that I corrected is there.  But it doesn't look right.  Part of it is truncated.  I try to fix it in CFF Explorer and save it.  Try to run it again... still side by side configuration error.

This is the point where I consult a write-up, because I simply don't know enough.  I don't read the whole thing - just enough to get a nudge in the right direction.  So I delete the resource.  I think I should've thought about that, because I've had to delete configs before that were rebuilt in other challenges.  I try to run it again.  This time, I'm getting a different error.  "The code execution cannot proceed because a .DLL was not found.  Reinstalling the program might fix this error."  The weird thing is that this popped up twice.  Again with the reinstalling... so I look up that error.  "Install some dubious program repair software", no thanks.

I do remember that .dll stands for dynamic link library.  From my programming classes/ctfs, I remember that in order to use certain functions, you need to call or import other functions or libraries.  (It's been a while, so if I'm using the wrong terminology, sorry.)  So I'm looking in CFF Explorer again, and I see Import Directory.  What's this?  There's two of them that are blank.  I have no idea if this is normal, So I click on one, and I see a list of things.  So I look them up.  One has to do with kernel32.dll and the other has to do with shell32.dll.  DLLs... lightbulb.  When I double-clicked, I noticed that there was a blinking cursor.  So, I typed in kernel32.dll in the top one, and shell32.dll in the bottom one.  I saved the file and ran it again.  It pops out sink_the_tanker.vbs and the flag: C0rruptGarbag3@flare-on.com.  I'm looking at the screen like O_O.  Finally.  

I don't usually attempt Flare-On, because they really ramp up the difficulty level, and it used to be, they would only give you one challenge at a time, so if you got stuck on one, you can't go to the others and try solving them.  That is one cool thing about other CTFs.  If you get more than one challenge, sometimes you can solve others even if you don't solve one.  Sometimes I find that I'll solve another one easily that's supposed to be more difficult than the one I'm stuck on.  Weird, right?  I'm glad that Flare-On does release the challenges to try later though.  And so many write-ups.  I'm interested in learning this for fun.  Have been for a while... but finding time.  Sometimes that's not easy.

Tuesday, September 7, 2021

Flare-On 2021 & Flare-On 2020 Challenge 1

My colleague said he saw that the Flare-On Challenge was coming up soon.  I've attempted a couple challenges here or there for this one in past years, but haven't really given it much of an attempt.  I wouldn't say I'm the best at reverse engineering.  I've tinkered with a couple things, but not really deep dived into it.  Here's the link:  https://www.fireeye.com/blog/threat-research/2021/08/announcing-the-eighth-annual-flare-on-challenge.html.

Today, I saw that Flare-On had some challenges from last year and solved the first one in about 10 minutes.  It was easy to me.  I remember a couple short years ago, this would be a challenge.  I didn't read any write-ups, and I don't recommend doing so unless you get stuck.  Try them, then read write-ups.  You might surprise yourself.

Flare-On 2020 - Challenge 1

Welcome to the Seventh Flare-On Challenge!

This is a simple game. Win it by any means necessary and the victory screen will reveal the flag. Enter the flag here on this site to score and move on to the next level.

This challenge is written in Python and is distributed as a runnable EXE and matching source code for your convenience. You can run the source code directly on any Python platform with PyGame if you would prefer.

I didn't run the game at all.  I went straight to the source code and found this function:

def decode_flag(frob):
    last_value = frob
     encoded_flag = [1135, 1038, 1126, 1028, 1117, 1071, 1094, 1077, 1121, 1087, 1110, 1092, 1072,
    1095, 1090, 1027, 1127, 1040, 1137, 1030, 1127, 1099, 1062, 1101, 1123, 1027, 1136, 1054]

    decoded_flag = []
    for i in range(len(encoded_flag)):
        c = encoded_flag[i]
        val = (c - ((i%2)*1 + (i%3)*2)) ^ last_value
        decoded_flag.append(val)
        last_value = c
   return ''.join([chr(x) for x in decoded_flag])

Noticed that all the characters were just encoded as numbers and that they were all four digits.  So I made it guess some.

def decode_flag(frob):
    last_value = frob
    encoded_flag = [1135, 1038, 1126, 1028, 1117, 1071, 1094, 1077, 1121, 1087, 1110, 1092, 1072,            1095, 1090, 1027, 1127, 1040, 1137, 1030, 1127, 1099, 1062, 1101, 1123, 1027, 1136, 1054]
    decoded_flag = []
    for i in range(len(encoded_flag)):
        c = encoded_flag[i]
        val = (c - ((i%2)*1 + (i%3)*2)) ^ last_value
        decoded_flag.append(val)
        last_value = c
    return ''.join([chr(x) for x in decoded_flag])

for last_value in range(1025,1200):
    print last_value
    print decode_flag(last_value)
    decoded_flag = []

The token that is sent by the game for the value of last_value is 1030.  The first flag is idle_with_kitty@flare-on.com.

I can see the next challenge is packed.  I haven't really messed with a packer that I can remember.  Looks like UPX.  I'll give it a shot.

Tuesday, July 27, 2021

Evading EDR/AV Again

It's been a while since I posted.  I found another method for evading AV/EDR, and this time, it took nothing special at all.  I used an unmodified version of impacket secretsdump.py.  Didn't use the "useVSSMethod" option.  I saw one thing in the logs for this, and that alert wasn't shown because it's "too noisy", so I'm looking through the logs to see if there's anything I can use to detect this.  So far, I haven't seen anything in this particular solution.

Friday, February 19, 2021

AV/EDR - Fun Shenanigans

Working with a vendor to find out why my customized rules are firing on an RDP script that someone I know uses.  Word.exe was considered the parent process even though I was fairly sure it wasn't.  Usually this person accesses this specific script via a shortcut on their Desktop so that they don't have to navigate through a maze of a directory structure every time they want to launch this script.  So I started experimenting with a Word document to see if I could reproduce the error.  I put a link to a shortcut.    I didn't get an alert.  So then I tried putting a link in the Word document directly to the script.  I got an alert.  So then, the adversary brain in me thought, if I put a macro that launches a shortcut which then launches wscript.exe, then maybe the AV/EDR won't detect and alert about this.  Sure enough, this vendor didn't.  Most vendors will look for a parent process of Word.exe to Wscript.exe when the script launches. They aren't looking for a middle man so to speak - in this case being a shortcut link.  The vendor has been notified, so I hope to see a fix soon.  Using shortcuts in an attack isn't exactly new - it's been done before - but it's just kind of a fun bypass I didn't expect.

Friday, January 15, 2021

Burp - Kerberos Authentication

Sometimes in my job, I'm asked to do an assessment of web applications.  And plenty of web applications use Kerberos Authentication.  I'm not exactly an expert in Burp, so I had issues with this.  Since I had issues, I thought I'd share what I did in case others have problems.  Keep in mind, this could be wrong, but it worked for me.

Symptom:  You're getting a login prompt for certain web applications that are expecting credentials.  So you look at the headers and you see WWW-Authenticate: Negotiate <some long string>.


This means that the application is expecting Kerberos and may fall back to NTLM if Kerberos fails.


So how to get Kerberos Authentication working in Burp?


Source 

https://github.com/nccgroup/Berserko/issues/5 

 

As of the time of this writing, there isn't native Kerberos support in Burp, that I'm aware of.  I'm running 2020-12-1.  If support was added for that, it wasn't working for me.  So, as far as I know, you must use an extension called Kerberos Authentication. 


In my case, Burp is located in /opt/Burp. 

 

In order for this to work, I had to launch Burp in a specific way.  This was supposed to be fixed, but apparently it wasn't.   The problem, according to rtt-ncc in that source up there, is that Burp "is now using OpenJDK instead of the Oracle JDK, and the version of OpenJDK being shipped doesn't include the jdk.security.auth modules." 

 

So, according to va-14 in that source up there, the solution is to open up a Terminal and run the following to launch Burp instead of launching it from Applications (I'm on a Kali box). 

 

java -jar /opt/BurpSuitePro/burpsuitepro.jar 

 

After you launch Burp, you'll get a popup asking if you want to load from a saved setting or start a Temp Project.  Start a Temp Project.  Use Default Settings. 


To install Kerberos Authentication, click on the Extender Tab.  This will bring up another set of tabs underneath the original tabs.  Click on BApp Store. 


Scroll down until you see the Kerberos Authentication Extender.  Click on it to select it. 

Click the Install Button on the right hand frame.  Once it is done installing, you'll see a Kerberos Authentication tab on the top row of tabs.  By default it is turned off.  In order to use Kerberos, make sure that the "Do Kerberos" checkbox is checked at the top.  You must do this every time you open a new project if you'd like to use Kerberos. 

 

There are settings that must be configured for it to work.   

 

Click on the Kerberos Authentication tab and put your details in there.  Do not check the "Save password in Burp config?" Checkbox.  We don't want random creds lying around where people can find them.  Also of note, in the Scope area, having the "All hosts in scope for Kerberos authentication" box checked is not recommended.  Otherwise you may actually test hosts that you don't intend to.  The "Do not perform Kerberos authentication to servers which support NTLM" is also not recommended because NTLM challenges and responses can be sniffed and cracked.  We are using TLS, though, so it should be ok, but don't quote me on that.  Just be aware that that might be a security hazard.  In order to use Kerberos, make sure that the Do Kerberos checkbox is checked at the top.  You must do this every time you open a new project if you'd like to use Kerberos.


The details on the Kerberos Extender tab, as long as you're familiar with Burp and your environment, are fairly easy to work out.  If you have questions, ask your sys admins.


Make sure to test your credentials and your connectivity to the domain.


The cool thing about this is that you don't have to be a member of the domain to use it.  You just need valid credentials.


I did run into a couple of errors, but they seemed to be resolved by launching Burp the way that I said above.  I found this solution by using Google.  Chances are, if you have an error, simply Google it.  You're likely to find a solution.


When you use Intruder or Repeater, don't add the WWW-Authenticate header.  Burp will take care of that for you so long as the Kerberos Authentication Extender is enabled.


Hopefully this helps others not spend a lot of time researching this.

Monday, January 11, 2021

SANS Holiday Hack 2020 Write-UP


Completed the 2020 SANS Holiday Hack Challenge.  It was so fun!  I'm attaching images because I've found myself short on time.  Unfortunately, this blog won't let me upload a Powerpoint Presentation or PDF.  I created this in Powerpoint and exported to PDF for submitting my entry.  There's also an option to export to images, so I uploaded the images on here.  If you can't see or read these, send me a message, and I'd be happy to send the PDF over to you.  I highly recommend trying the challenges and then reading multiple write-ups.  I learn so much by trying and then seeing things through others' eyes.  Hopefully everyone has a happy new year!  









































Friday, October 23, 2020

Another AV Bypass

I was going to release this in January 2020, but thought that I probably shouldn't.  I notified the vendor.  The AV vendor doesn't consider this a bypass.  But, that AV vendor is using signatures.  This might be able to bypass that for a while.

This AV vendor blocks execution of encoded powershell commands, or so they thought.  I used to see many powershell -e, -enc- or -encodedcommand attempts in my logs, but then I stopped seeing them as often as AV vendors got wise to this method of attack.  So, I thought, is there a way to run encoded commands without using -e, -enc, or -encodedcommand?

This isn't sophisticated by any means, but it works for now for this specific vendor

#runs whoami
$evilencodedcommand = "d2hvYW1p"
$evilcommand = [System.Convert]::FromBase64String($evilencodedcommand)
$decodedevilcommand = [System.Text.Encoding]::Ascii.GetString($evilcommand)
powershell.exe $decodedevilcommand