HolidayHack 2015

Well, I guess it’s been a year of neglecting my blog.  I guess having a new baby will do that.

This year’s Holiday Hack has just finished up and it was a super impressive job by the team at CounterHack.  It pushed me to the limits of what I could do, and then gave me even more that I couldn’t.

I included more technical details in my submission, but I’ll post just my poem here since it’s the fun part.


How the Kids Saved Christmas

I’m certain you’ve heard of the Grinch and the Whos
His plot to steal Christmas and his way-too-tight shoes
But what you don’t know is that after 60ish years
For Christmas – A brand new challenger appears.

The plot was discovered by two children named Dosis
The villain was dealing with major psychosis
They had vowed to destroy Christmas cheer in all homes
With an army of two million little toy gnomes.

Father Dosis brought home the wee gnomish doll
It seemed quite innocent, cuddly and small
But later when Josh did some network inspection
Some odd transmissions were brought to attention

The .PCAP he gathered showed something amiss
Abnormal packets travelling by DNS
The data field carried some base64
So Josh used some Python to figure out more

Straight away he got Scapy downloaded
He assembled the data, then got it decoded.
They discovered the gnome was a miniature spy
Sending images out from their home…but why?

Then the next step for the duo to do
Jess dumped the firmware from the gnome’s CPU
Binwalk was used to scan and extract
While firmware-mod-kit got the system unpacked

Browsing through files and directories
They found it was build on OpenWRT
A Node.js server, and what else did they see?
A NoSQL database on MongoDB.

Loading the database, soon the kids found
They might just be able to bring this scheme down
The nefarious gnome plan might just be vexed
Since all of the passwords were stored in plaintext!

They found the gnome’s server in two different ways
The firmware’s hosts file and the pcap they’d saved
So, with the address and the admin user
They found a new gnome, but this one was super.

Soon Josh and Jess were nothing but smiles
When they logged into the server and downloaded some files
Armed with the first SuperGnome’s IP address
They set off to see if they could find the rest.

Plugging it into the Shodan search field
A customized header was swiftly revealed
Then using that string to alter the search
They found four more SuperGnomes spread ’round the Earth

The files that they got from SuperGnome one
Gave them some hints of the deed being done
But to uncover the truth they still needed more
So they set off to access the remaining four

All but one reused the same admin credentials
(Somebody failed their security fundamentals)
But though they could log in, downloading was stopped
These four SuperGnomes had to get popped.

The password had changed on SuperGnome three
But bypassing the login was simple, you see.
The input not sanitized, the children were pleased
To send some JSON and get logged in with ease

The client gnome firmware contained server source
(Seriously, could their security get any worse?)
So Josh and Jess looked at the javascript code
For things to examine, exploit, or explode

For SuperGnome four, they found they could break
A function that called eval(), a major mistake!
They opened up Burp Suite to alter their packets
The server wrote files and then they could snag it

SuperGnome two was quite aptly numbered
For two different issues the children discovered
An uploading form allowed the creation
Of any directory name in their imagination

Another page that I should probably mention
Let them view files with a certain extension
But the code checked the entire length of the string
Rather than simply the end of the thing.

So, by making a directory named “.PNG”
And some clever traversal of directories
They copied the files off SuperGnome two
Then checked on the next thing that they had to do.

SuperGnome five was running a service
On port 4242, but what was it’s purpose?
It let them choose some info to reveal
But a hidden command opened an input field.

Examining the code (gotten from gnomes before)
The Dosis kids looked for some flaws to explore
They saw this one would be hard to attack
With a user chroot jail and canary on the stack.

The input let them overflow a buffer
But getting much further was going to be tougher
Their time grew short, so they stopped to find
If they had enough to unmask the mastermind.

Each SuperGnome held a pcap with an email
And opening them revealed the villainous female
The children could hardly believe it was true
But the leader of ATNAS was Cindy Lou Who!

On top of the emails, they also discovered
From static-y files, an image recovered.
XORing the pixels, removing each layer
Gradually showed the boss in her chair.

Josh and Jess picked up the phone in the hall
And gave some federal agents a call
Cindy ran afoul of several statutes
By transmitting images from the bedrooms of youts

So there ends our story, and Christmas was saved
By Josh and Jess Dosis, so clever and brave
But to think this whole thing may have gone undetected
If the Dosis WiFi was password protected!

SANS Holiday Hack 2014

The SANS #HolidayHack is one of my favorite challenges.  Ed Skoudis masterminds a holiday hacking scenario by intertwining cultural touchstones with high-tech hijinks. (This year he worked with Josh Wright and Tom Hessman).

They also encourage creative answers, which I love.  We spend enough time writing dry, technical documentation at work, why do the same on a fun personal project?

I didn’t have the time to finish the challenge last year, but I submitted an entry two years ago.  Now I’ve got this year under my belt as well.

My answer is below.




It was the biggest job I’d ever been offered.  I thought it was impossible to pull off…that kind of hack, against that level of security?  You’d have to be crazy to accept.


Call me crazy.


I don’t know if was for the challenge of it, the potential windfall, or the target’s comeuppance; but I had to try.


Thankfully, it was an inside job.  Without the knowledge coming from inside the organization, I wouldn’t have gotten past square one.


So how would we get Scrooge, one of the most notorious blackh(ear|a)t hackers around, to succumb our social engineering experiment and renounce his malicious tendencies?


There was only one thing that could work…we had to scare the Dickens out of him.




Though he was a rational man, Scrooge harbored quite a few superstitions.  We settled on using the ghost angle, so our first investment was in top-of-the-line holographic projection equipment.  With that in hand, we decided to start him off with a visit from his beloved old server.  Mrs. Lynn Crachit, Scrooge’s clerk, had kept EXCELLENT inventory records of the technology Scrooge employed, so it wasn’t too difficult to set up a machine that looked just like his old one.  We spoofed the MAC and IP addresses, and used the keypair she had archived.  Then we just had to create an account for Scrooge with his public key, and fake it’s last login date.  We prepared the server room with the holographic projections and brought the box online.


After Scrooge got the MOTD we killed the box so he couldn’t dig too deeply into it and discover the ruse.  He went to the server room as expected, and when the door was opened it triggered our holographic display to begin.  I even threw in a phantasm of my Lumia 928 that I just traded in for an iPhone 6.  Now that the stage was set, the real show could begin.



For the apparitions and visions we had planned out to finish out our hack on Scrooge’s brain, the holographic projectors weren’t going to be enough.  So we created some custom software and acquired the latest iteration of the Occulus Rift from a good friend who happened to have access.  It’s gotten very lightweight, and we thought Scrooge wouldn’t notice the VR helmet when aroused from deep sleep.  To be safe, we had his maid slip some extra-strength Nyquil into his evening tea, then she strapped on the helmet while he was asleep.

The first “ghost” arrived, and scrooge found himself in a vision we had programmed just for him.  When the animated image of Turing handed him a slip of paper, we had to have precise timing to have his maid give him a piece of paper with the IP address of the server written on it, then swiftly remove the VR headset and disappear (we used some old magician’s tricks: smokebombs and a hollowed out space under his floorboards we created when he was on a business trip a month back).  We set up a simple ELIZA chatbot at the IP address for him to find on port 31124 (we assume he did a full port scan with nmap).  Once connected we knew he would have to solve the puzzle…the curiosity of a hacker is insatiable.  He quickly found the keywords to trigger non-stock answers from her. He’d have to enter “secret”, “puzzle”, “game”, or “enigma” three times before she would request a website to “surf” to.  But, he’d also have to unlock her ability to visit links by referencing Dr. Turing twice. (Entering “Turing test”, however only resulted in an easter egg we found amusing).  The second time, the bot would pull Turing’s Wikipedia entry, and only then could Scrooge send her to arbitrary locations.  After he figured out to use her own words, “surf to http://****“, he poked around a bit – figured out he could crash the session by sending her to her own address and port – then finally sent her to his own webserver where he had access to the logs.  Then he read our first message in her browser identification:

Eliza Secret: “Machines take me by surprise with great frequency. -Alan Turing”



After passing out into a deep slumber again, we prepared for the second ghost.  This time, we skipped the VR setup.  Johnny Long was flown in from Africa to appear before Scrooge in person.  He shared our vision of a world where Scrooge used his computer skills to make lives better.  We had made a video recording of Mrs. Crachit and Tiny Tom, and used a scrim and the latest smell-o-vision technology to project the deli scene into Scrooge’s room.  As for the website, it was trivial to “hack” when Scrooge’s own staff was in on it.  They simply didn’t patch against some of last year’s biggest exploits: Heartbleed and Shellshock.  However to do nothing at all about those exploits would be very dangerous, so we worked together to carefully limit what information could be accessed…only the secrets for Scrooge to find.  For the Heartbleed vulnerability we made sure to always have the secret inserted into the viewable memory space of the server, so when Scrooge launched an attack on the site he would see:

Website Secret #1=Hacking can be noble.
(Scrooge had built his own POC for Heartbleed months ago, but he could have easily found one on github had he wanted to)


The Shellshock vulnerability was trickier to set up, but we settled on a highly restricted shell, with no escape possible (to the best of our knowledge).  The secret was set in the root directory, but without any file reading capabilities, how would Scrooge see what we wanted him to see? After recognizing the vulnerability, Scrooge simply made requests using curl and altered his User-Agent string to “(){ foo;};echo;<commands>”, where <commands> were the shell commands he tried to execute.  Sending the “help” command to the shell was his biggest asset, since it showed which limited set of commands were allowed.  Without “ls”, he resorted to using “echo *”, a neat trick that he had read about on the SANS Penetration Testing site (  On top of that, he found he could set shell options, so by executing “shopt -s globstar” he could then run “echo **” from the root directory and see everything available on the system.  Ultimately, he needed to get that secret, and figured the best way was to set a variable equal to the file contents and then print out the variables.  He appended this to the initial Shellshock string of his User-Agent:


cd /; declare input=$(<secret);declare;


Then he saw our second website secret:

Website Secret #2: Use your skills for good.



To prepare for the final vision, we really had to pull out all the stops.  If we didn’t succeed, all of our efforts would have been for naught.  I took point and dressed in a long black cloak.  I’d written to the USB drive from a machine with the clock set 20 years into the future to set the illusion.  The biggest challenge was the transition.  We carefully carried the passed-out Scrooge into a nearby graveyard, but how would we “magically” whisk him back to his bedroom?


In a feat of engineering and a dash of good luck, we successfully did it with a trebuchet.


As for the USB drive, the first secret I left out for him pretty trivially.  Looking at the raw data of the document that celebrated his death with a hex editor, he could easily find:


USB Secret #1: Your demise is a source of mirth


The second file he could immediately see was a network capture (again, spoofed to take place 20 years in the future).  Scrooge could read a husband and wife discuss their massive debt to him and how it would all be better now that Scrooge was dead.  With his ever careful eye, Scrooge noticed some packet comments when he viewed expert info in Wireshark, one of which contained a base64 encoded string (VVNCIFNlY3JldCAjMjogWW91ciBkZW1pc2UgaXMgYSBzb3VyY2Ugb2YgcmVsaWVmLg==).  When decoded he saw:


USB Secret #2: Your demise is a source of relief.


The other packet comment was a link to the f5 steganography algorithm ( ), which he would have to use for the fourth secret.  But first, while examining the raw data of the USB drive with his hex editor, Scrooge discovered two more files not immediately available.  The first was a compressed file locked with a password.  Scrooge had a number of cracking dictionaries available and easily decompressed bed_curtains.png using the zip2john extension of John the Ripper.  (We had Johnny try to lead him to this answer as well, since if CeWL were used on Scrooge’s website one would easily find the password – shambolic.  However, it’s hard to differentiate CeWL from cool when spoken.)  Once decompressed, Scrooge found the third secret in the raw data of the file:


USB Secret #3: Your demise is a source of gain for others.


Finally, Scrooge found the jpg file of Tiny Tom’s crutches.  He rightfully assumed it had a secret hidden via steganography, and having seen the packet comments, he downloaded the f5.jar and easily extracted our final secret:


USB Secret #4: You can prevent much grief and cause much joy. Hack for good, not evil or greed.


(In testing phases to make sure Scrooge could successfully retrieve the secrets with the proper amount of effort, one of our testers got stuck working on the jpg before seeing the packet comments.  This lead to some custom scripting to use a dictionary file with Steghide to try and brute force their way in.)



In the end it went off almost exactly as planned.  The experiences we crafted for Scrooge changed his outlook on hacking and life.  His employees were happier and more productive, his family welcomed and enjoyed his company, Scrooge himself was happier and took more pride in his own work, and the world was better off.  I had never cared much for working with wetware, but hacking Scrooge’s brain was one of the most fulfilling jobs I’d ever done.

In fact, I don’t think we had actually hacked him, but instead removed some particularly nasty malware that was corrupting his true self.


It was truly a Christmas miracle.

CTF write-up: Lork edition

Ben0xA has outdone himself with his latest CTF challenge.

In a lead up to BSides Detroit, the website hosting the challenges( suddenly changed into a terminal prompt.

It asked if I wanted to play a game.

Yes….yes I do.

(If you want to play it yourself, it’s up at  Don’t read ahead if you want to figure it out for yourself!)




The scenario is that a rogue agent has hacked our server and replaced it with a complex set of puzzles.  First, I had to start the game.  The obvious choice was “Global Thermonuclear War”, as it references WarGames.  However, being inquisitive, I tried every game that showed up at the “LIST GAMES” command.

I got nothing but trolling responses until entering the obvious choice.

Now the real game begins.

The game is titled “Lork” and it is a clone of the old text adventure Zork, which I have fond memories of playing as a kid.  In the starting room, there is only one way to go.

Going that way gets you eaten by a grue.  Unless you turn on your flashlight first.

Now we get our first challenge.  There’s a door locked by a keypad which we have to get through.  The only clue is a note in a closet saying “Mr. Fuzzing’s name must be fuzzed, trimmed, and truncated.”  After playing around with manipulating my entries to try bypassing the keypad, I took note of the fact that the server response was a block of JSON data followed by a zero.  I also noted that although I could enter up to 45 characters, the username returned was cut down to 20.

If you enter any random data, it says you must be ADMIN.  If you enter ADMIN, it says you are not ADMIN.  But, because of the operations listed in the clue (fuzzing, trimming, truncating), I figured out that entering ADMIN followed by 15 spaces and then 1 would let me through.  The spaces pad it out to the maximum length, but they are then trimmed.  The server then has the name ADMIN, but the extra 1 replaces that 0 in the server response.  That changes the admin flag from false to true, and we are on to the next room.

In this room, there is a blank piece of paper, but when a candle is lit with the provided matches, some glowing symbols appear.  The symbols are <~3<~>, <~2#~>, <~1&~>, and <~1B~>.  The number 85 is also on the page.  Also in the room, there is a four digit lock on a trap door under the carpet.

After a little thinking and research, I realized that the symbols were numbers encoded in ASCII85.  I found a decoder online and got 9,5,2, and 3.  I iterated through combinations on the lock until I succeeded with 3592.

Down into the next room.  This one gave me some trouble.  There was a central room with chambers to the North, East, South, and West.  Each of the four chambers had a touch screen and a button.  The central room had a red and a green button on the floor, and a piece of paper.  The paper had a phone number and code on it.

I had seen this phone number in a prior CTF challenge, it’s a voicemail service.  When the number and code were dialed, a series of tones played.  I knew it was an rtty transmission that I needed to decode.

However, between calling on my cell phone and recording to my laptop speaker I got a very degraded signal.  I tried many settings, but nothing seemed to work.  I thought that perhaps the rtty would decode to a ciphertext that I would have to decode with something else, but that went nowhere.  Finally, I asked some questions to the challenge author, who confirmed the message would result in cleartext.  That focused my attempts, and I was able to see parts of words with certain settings.  Using the minimodem program on a Linux virtual machine, I was able to alter the baud rate by small increments.  These small changes made different letters appear more clearly, and eventually, I was able to tease our parts of the message.  Most importantly, I clearly saw r7=FLOWER.  That let me know that the message had the codes for each of the four touch screens.  Through trial and error and some educated guessing, I got the four codes: CONTRA, FLOWER, NITRO, and FROGGER.  That first password also gave me an idea of what I had to do next.

The rooms were arranged like a Nintendo pad.  I pushed the buttons in the order of the famous Konami code: N, N, S, S, W, E, W, E

The green button in the middle then led to the final room (instead of a painful death, as it did every other time).

The final challenge presented a laptop logged into a bash prompt.  Most normal Linux commands resulted in “command not found”, but a few things worked.

First, I was able to list the current directory and see that there was a Python file.  Trying to run it resulted in a joke, claiming four pythons slithered out of the wall panels.  Thankfully, it did not kill you and make you start over.

I was able to see that contents of the python file with the ‘cat’ command.  The script would generate an encoded string based on three variables, the last variable would depend on the current time every 30 seconds.

The variables had been erased after the last time it was run (according to the history, which also showed the server to connect to when you have the correct password)

Based on the variable names and some quick Google searching, I discovered that the variables (firsthacker, rats, year) were based on Nevil Maskelyne, who famously interrupted Marconi’s demonstration of the telegraph in 1903.  The year was clearly meant to be 1903, and “RATS” was the initial uninvited message Maskelyne sent to Marconi’s telegraph.  The rats variable was mapped to the variable “ditdah” in the function, which indicated we needed to write it out in morse code (.-. .- – …) .

With the variable populated, the last thing to do is synchronize the time between the server and my machine where I could generate the password.  I hardcoded a time that was a little ahead of the reported time from running the ‘date’ command on the laptop.  The passwords I received had some characters which appeared to be erroneous or invalid.  I kept trying different things but (with some assistance from @Ben0xA) I realized that I had to just go ahead and enter those bad characters.  It worked!

This was a fun — occasionally infuriating — but ultimately satisfying challenge.



Latest NSA leak news.

I’ve mostly held my tongue on the entire Edward Snowden issue.  I believe the truth of the situation is very nuanced, and far too many are quick to label him either a hero or a traitor.

However, the latest wrinkle in the story gave me something to say:

Your should NEVER give out your password to an IT administrator (or anyone else, for that matter).  Any systems admin who says they need it to perform any function is either lying or not properly trained to do their job.

A user’s password is supposed to uniquely identify them, as no other person should possess that knowledge.  When a password is shared, it breaks authentication.  In some cases this doesn’t cause major security issues, for example,  your buddy letting you use his Netflix account (Though security isn’t so much a problem here, the content providers will not be happy about it).

However, if you are an employee of a government or corporation, and you have access to sensitive material…


The failure here is in user training.  Since the employees who gave out their information have been relieved of their positions, I can only assume they did receive training and signed some sort of user agreement indicating that they understood their responsibilities in regards to data security.  Clearly though, the training was not effective.
Hopefully this will act as a learning experience to improve user training in the future.

New Poshsec Functions!

Well, it’s been almost a month since the PoshSec Framework was announced, and I’ve been working on integrating some ideas into it.  I’ve finally got something up which I’m pretty happy with.

It’s an IIS log monitor in Powershell.

The monitor function itself runs within the PoshSec Framework, leveraging the built-in alerts.  When you execute Start-SecIISMonitor you can specify an IP address and a filter to isolate which http events you want alerts on.  Here’s a simple example where I am isolating a hit on any .PNG files (I’d do something more interesting if my test IIS server had anything beyond the Microsoft default page on it)iismon


The tab at the bottom showing “Active Scripts(1)” shows that the monitor is still running.  It has a configurable polling frequency so that it periodically checks the latest records of the log file for anything new that matches the given parameters.

At this point it just generates alerts, but future iterations on this can add functions that automatically adjust firewall settings due to certain traffic patterns.  For example, one idea I had was to create a fake page, like a honeypot.  The IIS monitor function can detect any hits to that page, then blacklist the visiting IP address.

Behind the monitoring function, there is another function which can also be utilized in new ways.  The Get-SecIISLog function parses an IIS log file, and outputs an object.  Each piece of the http record is separately addressable through PowerShell, so a forensics investigation could isolate certain IP addresses, URLS, user agent strings, or any combination of attributes.  And, since it outputs into the pipeline, those investigations could have the output formatted and sorted for a final report.

I’m glad to be a part of this project, and look forward to what we can achieve with it.


Major Poshsec update.

I haven’t had the time to post for quite a while now (just moved into a new house), but I’ve finally got both the time and a fantastic reason to post.

The Poshsec project that I have mentioned before just got a major facelift thanks to Ben0xA. By integrating some ideas he was working on with the goals of Poshsec, we now have the Poshsec Framework.

The Poshsec Framework is a customizable GUI tool which can be equipped with any desired Powershell scripts or modules. This extensibility makes it a very powerful tool, and though it’s designed as a defensive monitoring platform, it can easily be adapted into a pen-testing platform or administration center.

I’m excited by the endless possibilities afforded by this structure. I’ll be contributing to it as much as possible, and I’ve already got a few ideas to work on implementing.

Security Fail: Hollywood edition

I went out to the movies for the first time in quite a while (difficult to find the time with two little ones)
We saw Olympus has Fallen at a second run theater ($2 tickets FTW).

I enjoyed the movie, but couldn’t help but notice some glaring failures of security. Of course, without those failures you’d have a pretty boring movie, but I’m going to break down where things went wrong anyway.

There might be some spoilers ahead, so feel free to skip reading if you plan on seeing the movie.

The entire plot wouldn’t go very far without two key failures. Firstly, the terrorist attack begins with an aerial attack on Washington DC. Rightly, the intrusion into restricted airspace is engaged by the Air Force. Now, I’m not familiar with specific USAF protocols, but it seems to me that you should send more than two jets to confront an unknown aircraft. Also, you would probably want your weapons pointed at them, rather than the other way around.
After that, the White House goes into lockdown, and critically, the president ignores protocol and takes the visiting prime minister and his security team into the secure bunker. It’s one thing to admit a known dignitary, but to allow his entire armed security team along is unnecessarily risky.

Later on, we see a secret service agent who was formerly assigned to the White House easily entering access codes for various systems. Those codes should have all been invalidated the moment the agent was transferred out of the White House. Always revoke credentials from users that no longer need them for their duties.

Finally, I was baffled by the fact that a code for a super secret project was able to be cracked by the terrorists. Sure, they had an explanation on why they could do it (only had to crack one of three passwords), but each of those three should not have been breakable by any means. I’m assuming the terrorists were able to access the password hashes since they had direct access to the system. However, a project of this magnitude would have the passwords hashed with the strongest algorithms possible. It should take days to crack with even the most advanced technology available.

Maybe I can write off my next trip to the movies as a training course.

Another BSides CTF Write-up

There have been a trickle of challenges coming out between the BSides Chicago and BSides Detroit events.  This last one was pretty fun, and I got to write some Powershell to solve it.

The challenge title was Flipping Out.

We get lots of references to the so-bad-it’s-good movie, Hackers.  I saw it in the theater and gave it the MST3K treatment with my friends.

The only thing we get to start is a jpg image.  But it seems to take up more disk space than an image this size should….

Scanning through the binary data, I found a “PK” header, indicating a zip file is there.  I fired up HxD, my hex editor of choice, and separated out the bytes.

Now I had a zip file which I could open to find image1.jpg, but it does not contain the flag


Again, the file size is suspect.  The zip file is 187kb, but the single file inside shows a packed size of 95kb.  So I know there’s more data that is not being shown yet.  After investigating a few different paths I ended up reading the specification for the zip file format to try and tease out what was going on in the file.

Then the obvious thing jumped out.

I had seen the binary of the zip ended in ‘KP’, but at that point I assumed it was a normal terminator for the zip file.

It’s not.  Then the title of the challenge made perfect sense, and I knew what to do.

I found the midpoint of the file where the first zip ended, and the end of the second one was reversed onto it, cut out the reversed bytes and saved them to a file.  Now I just had to reverse the whole thing and since I’ve been working with Powershell, I decided to stick with that.

[byte[]]$byte = Get-Content hackerz-rev -Encoding byte;
[byte[]]$flip = New-Object byte[] $byte.Length;
for($i=($byte.length-1);$i -gt 0; $i--){
$flip[$j] = $byte[$i]; $j++;
[System.IO.File]::WriteAllBytes('C:\Users\rcassara\Desktop\files\bsidesctf\', $flip);

I had saved my backwards bytes to ‘hackerz-rev’, so in the first line, I read that into a byte array.  Then I created a second array of equal length, and simply copied each byte over in reverse order.

The final line writes out the bytes to a zip file.

Opening the new zip I saw what I expected, a single file named gpj.egami (the challenge writer reversed the name so the mirror-image wouldn’t be as obvious when looking at strings in the binary).  Opened the file as a jpg and…



sw1tch posted his method of solving this, which involves no coding at all (unless you consider writing RegEx coding)

First con experience plus CTF write-up

Updating this blog has taken a backseat to real life. After a crazy couple of months of searching, it looks like we’ll be moving into our new home in June.  Sometime after that I might be able to settle into a less chaotic routine.

This past weekend I attended my first security conference, BSides Chicago.

A contingent from Michigan all got on the same train in. We dubbed it Hackers on a Train.  Each person had to give a short presentation on the train ride, so I put together a short slideshow based on a bit of coding I’d been working on recently.  I might put it up here when it’s in a more polished state, but for now only those who were present know my secrets….

BSides Chicago was a fantastic experience with a lot of interesting talks, great people, and a Capture the Flag (CTF) event.  The efforts of the organizers (@securitymoey and @elizmmartin)  and volunteers (too many to name) really showed.  I’ve participated in a few CTFs with #misec, but this was the first time I got to work on one at the event hosting it.

This time around, we couldn’t field much of a team with #misec, since many of our usual CTF participants contributed challenges towards the cross-city BSides Chicago / BSides Detroit CTF. Luckily for my final scoring, I did have one teammate, Zandi, who used his lockpicking skills to get the flags tied to the Toool booth.

The computer based challenges were all on me. Here’s my write-up for one of the more interesting ones that I solved.

Phone Home Write-up:

The premise of this challenge was that a piece of malware was discovered attached to a Word document, and we needed to discover where that malware was communicating back to.
The first hurdle was that my antivirus killed the document upon download. Blindly trusting the CTF organizers, I disabled the antivirus and got the file.
I opened the file in Notepad++ to see what dangers lay inside.


click to embiggen

So, there’s a huge block in there that looks like a binary of a separate file.  Staying in Notepad++, I copied the block to a new file, stripped out the ‘&H’ characters, and was left with the hexadecimal representation of a file.  The first two bytes were 4D 5A.  Coincidentally, I had just seen @jwgoerlich’s excellent talk where that same header was pointed out  as the indicator of a Windows executable file.

So next, I fired up a hex editor (HxD), and pasted in the bytes.  Then I could save it out as an EXE. In case there was any checks for it somewhere, I gave it the same randomized name that was expected from the Word macros that were meant to trigger the code installation (AeAIJGcsSqmKdm.exe).  I tried running it and it showed up as a background process.

This is where I hit a wall.  A hint was given out that the key was going to be an IP address, but I had blanked on what to do next.  I wasted some time looking at the macro code inside the original Word document, and switched gears to work on some other challenges.  Later, while walking through Chicago with some #misec colleagues, it hit me.  In retrospect it should have been obvious, but I needed to check my outgoing TCP connections while running that executable!

When I got back to my computer  I launched the executable again, and then ran:
netstat -naob

The ‘b’ switch in netstat (on Windows only) identifies the executable attached to the network connection, so I could easily see my answer.


Flag: Captured!

I entered and completed the challenge!

Posting again with a new focus

It’s been a while since I’ve had the energy or drive to update the blog. There’s been a lot going on between work, home and personal projects.

I’ve decided that I want to try and shift the focus of my blog posts. Instead of mostly reposting interesting news with my own commentary added, I’d like to produce more original content. I’ll start by updating one of my few posts with original content, my baselining code.

In that post I pointed out:

There are probably much more efficient ways of doing this

I’ve been learning PowerShell more thoroughly through a study group (#psstudy) led by @mwjcomputing (aka PowerShell Yoda), and yes, there is a far more efficient way to get system baselines and run regular comparisons.

To get the baselines:
Get-Service | Where-Object {$_.Status -eq 'Running'}`
| Export-Clixml C:\svcs.xml

Get-Process | Export-Clixml C:\procs.xml

The first line retrieves all running services and exports them to an xml format used by PowerShell.
The second line does the same for running processes.

Once the baseline xml files are established, a scheduled task can be created to run a line of PowerShell to compare the current state to the baseline.

Compare-Object -ReferenceObject `
(Import-Clixml C:\svcs.xml) -DifferenceObject `
(Get-Service | Where-Object {$_.Status -eq 'Running'} ) `
-property name

Compare-Object -ReferenceObject (Import-Clixml C:\procs.xml)`
-DifferenceObject (Get-Process) -property name

The Compare-Object cmdlet (which can also be accessed with the alias diff for anyone coming from the Linux world) takes the baseline in through the Import-Clixml cmdlet. Then it gets the current list of services or processes, and shows if there is a name missing from one side or the other. The output looks something like this:

name SideIndicator
---- -------------
taskeng <=

The SideIndicator will be ‘<=’ if the something in the baseline is missing and it will show ‘=>’ if the system is running a new service or process not in the baseline. We can take that output and format it to be more readable.

Compare-Object -ReferenceObject (Import-Clixml C:\procs.xml) `
-DifferenceObject (Get-Process) -property name | Format-List `
@{n=''; e={ `
if ($_.SideIndicator -eq '=>') {$ + ' is not in baseline' };`
if ($_.sideIndicator -eq '<='){ $ + ' is not running'} }}

Now we have a concise list showing what is different from the baseline which can be output to a text file, emailed, or even put up on a webpage.

*Apologies for the code readability. The width constraints required backticks, I tried to place them as logically as I could.