Post-Event Writeup, Ridgeback Acid Test Summer 2015

//Post-Event Writeup, Ridgeback Acid Test Summer 2015

Post-Event Writeup, Ridgeback Acid Test Summer 2015

The Ridgeback Acid Test Summer 2015 event has finally wrapped up.  One important message we got from the spring test event was that participants wanted more feedback on how the test event went.  I am hoping that this post-event writeup will help people learn more about these events, and about computer and network security, in general.

The hidden treasures start with “2600” because that was the frequency once used to hack into phone systems.

A Ridgeback Acid Test event is kind of like a capture-the-flag cyber event.  The big difference is that the events we run are very free-form.  They stress the fundamental nature of attack and defense — that is, there is no right way to do either.  We set up a test environment that is intended to simulate what one might stumble into when performing a penetration test, or what an intruder might come across when they are hacking a corporate network.  The goal is to find “hidden treasures” — secret messages that start with “2600.”  In additional to providing the community with a way to learn and practice skills, we also use the test events as an opportunity to perform testing of our product.

The Plan
I was very ambitious when it came to this event’s test environment.  The diagram on the right shows what I had in mind.  There were to be four physical servers, four hypervisors, 16 virtual machines, and two Internet of Things (IoT) representative devices.  Wow, that’s a lot!  Unfortunately, I had to pare things down a lot before the test.  Ridgeback is a startup company, and sometimes things can get very busy.  Well, things got VERY busy running up to the test.  If it weren’t for some bold and extremely helpful volunteers from UMBC, we might have had to cancel the test altogether.  Many thanks to Arti Deore, Julio Valcarcel, and Yevhen Grinman for helping set things up.  I also greatly appreciate the help we have gotten from Dr. Richard Forno, the graduate program director for cybersecurity at UMBC.  And finally, many thanks for the continued support from the staff at the bwtech@UMBC cyber incubator, to include Ellen Hemmerly, Sarah Purdam, and Jeremy Johnston.  We could not have gotten this test going without you all!


The Reality
When we finally got into the test, we had two servers up (A and B), both running Linux.  There just wasn’t time to fully prep servers C and D, and the Internet devices E and F.  During the first week we brought up a VPN on server A along with three VMs, each running Linux, Apache, and MySQL.  I used QEMU for the virtualization and VNC for remote access to the servers.  The username/password for the MySQL instances was test/test.  The database was named “company,” and the interesting table was named “users.”  The table contained treasures, plus the username/password pairs needed for the bank accounts on server B that came online in week two.  During week one, server B ran an uninteresting instance of Linux.  In week two I finally got Windows 10 running on server B, with the firewall completely disabled, and running a mock banking web site.  During the entire test event my laptop would also show up on the VPN.  Treasures were scattered all over the place.  Some of the treasures were plaintext, and some were coded using various ciphers.

When you connect to a wifi network or a VPN, look at the IP address you got and ping around the network to see what else might be on your subnet.


Trouble Spots
There were four mishaps.  First, and most importantly, I bit off more than I could chew.  Even with help, the test environment was far too complex to set up and maintain given how busy things are.  Keep in mind that Ridgeback is a startup, which generally means working at all hours to make things happen as quickly as possible.  Second, I had trouble getting the VMs to play nice with the network.  Open source is not always the easiest path.  Third, lightning struck during the first weekend, right around midnight on Saturday night.  All systems lost power.  That is not good for a temporary test network originally meant to be online for only one week.  Finally, Windows 10 did not play nice.  In fact, Windows was the greatest headache.  All told, I apologize for the rough start to this test event.

Are you a motivated hacker looking to join a startup? Things have really kicked into high gear and we definitely need extra people on board.


Windows Strikes Back
Just before the test event started I was able to get a pre-release copy of Windows 10.  Fantastic!  I loved the idea of throwing a completely unknown and untested operating system into the mix.  However, Windows was not cooperative.  The first challenge was getting Windows 10, a brand new pre-release version of Windows, to run in QEMU.  The plan was to have another three VMs on server B, all running Windows.  Challenge accepted, and challenge failed.  I wasted far too much time trying to get it to work, only to watch Windows lock up over and over and over.  Next plan — load Windows onto CD and reload server B from scratch.  Whoops — the file was over 3 gigabytes and I did not have any DVDs in the office.  Next plan — load Windows on a USB drive.  Skipping over all the gory details, another terrible failure.  I finally got out to buy some DVDs, burned the ISO, and loaded the OS.  Success!  Now, it has been a while since I have needed to administer a Windows box.  It is not something I enjoy.  And Windows 10 did not make it any more enjoyable.  Sometimes I think the Microsoft motto must be, “Let’s make the unimportant things look pretty, and make the important things clunky.”  After a while I finally managed to get IIS up and running, the loopback device functional (that’s a story for another time), and the firewall shut down.  At last, the Whorfin Bank and Trust web site was live!
The Scores
This test event had many more treasures than last time.  The key to start collecting points was (1) connect to the VPN and start pinging IP addresses to see what was up, and (2) late in week two connect to the Windows server on the other IP address.  This time the scoring is 5 points for every treasure, and 10 bonus points for each encrypted treasure you could decrypt.  The maximum score for this test event was 215 points.  Without further ado, here are the top scores for the Ridgeback Acid Test Summer 2015 event:
Top 4 Ranking
140 Daniel Clark
115 Daniel Coyne
105 Alberto Veiga
65 -name withheld-Bonus Mention
Daniel Clark
Stephan Gross
Two people reported on otherwise hidden information.  While finding and reporting on hidden information does not count toward the official score, it definitely demonstrates how a cybersecurity professional should think.  And so, a bonus shout out to Stephan Gross for finding and decoding the hidden message in the steganographic image that appeared on this web site after the last test event concluded.  And, a bonus shout out to Daniel Clark for reporting on the NetBIOS name of the Windows 10 server.  Congratulations!
Phear Not . . . Stay Tuned
Do not feel bad if you did not do well this time.  Many people try the Ridgeback Acid Test event, but it is a very different kind of event that takes getting used to.  While I cannot promise anything, I would like to add a “getting started” part to the next test event.  The idea is to have a number of treasures discoverable by following fairly straightforward breadcrumbs.  Many people that follow the test event are new to cybersecurity, and a breadcrumb intro should work well to get those folks off to a good start.  For those of you who are very skilled, rest assured that there will be some sneaky things showing up in the next test event.
I hope you all enjoyed the summer test event and hope to see you again for the fall event!
By |2017-05-31T13:01:05+00:00July 10th, 2015|blog|0 Comments

About the Author:

Thomas Phillips is the lead "technical guy" at Ridgeback Network Defense. You can email him at

Leave A Comment