Showing posts with label CTF. Show all posts
Showing posts with label CTF. Show all posts
Sunday, November 29, 2015
Labels:
CTF
,
Information Security
Starting a list to track sites where you can download vulnerable images to learn and for research purposes
Read More
Vulnerable Images
Starting a list to track sites where you can download vulnerable images to learn and for research purposes
| Name | Website | |
|---|---|---|
| VulnHub | https://www.vulnhub.com/ | |
| Hackerdom | http://ftp.hackerdom.ru/ctf-images/ | |
Sunday, November 8, 2015
Labels:
Conferences
,
CTF
,
forensics
,
Information Security
Just a list to start tracking InfoSec Conferences I become aware of:
Read More
Information Security Conferences
Just a list to start tracking InfoSec Conferences I become aware of:
| Event Name | General Theme | Last Known Dates | Website/Email | Status | CTFs |
|---|---|---|---|---|---|
| BloomCON | Forensics and Security | February 5-6, 2016 | Over | Yes | |
| nullcon | Latest attacks, exploits, and vulns | March 11-12, 2016 | nullcon.net | Attendee Registration | Yes |
| BSides Charm City | InfoSec | April 23-24, 2016 | securitybsides.com | Call for Papers | Unsure |
| RVAsec | InfoSec | June 2-3, 2016 | rvasec.com | Call for Papers | Yes |
| RECON | RE and Advanced Exploitation | January 27-29, 2017 | recon.cx | Call for Papers | Unsure |
| hack4 | Tech talks and tech stuff in the old sense of hacker meetups | December 29-30, 2016 | hack4.org | Call for Papers | Unsure |
Friday, April 18, 2014
Labels:
CTF
,
forensics
These are the two clues provided to help you get started:
Read More
Write-Up: [SOLVED] SANS Easter Challenge - The Mystery of the Missing Easter Bunny
WARNING
Complete spoilers ahead! If you want to try the challenge first on your own, do not read this post. You've been warned.
Bunny-Napped!
Scenario: The Easter Bunny has been kidnapped, and YOU have to save him! Quickly collect yourself and help save him. Put on your detective hat and start investigating the clues provided.
These are the two clues provided to help you get started:
- An intercepted message from the bunny-nappers
- Ciphertext:
- Dsemvnqwlnmmzvi! Cc jagpbussnpwg tfgzvlroknt mlta cfwjgkr vqu phywl bfx kni Rxutrk Tztydi btsj lh tux asmhfesuygp qf gai Piiuii Zieoqrvlxd. Bxf gioqvkclf aegm ivgtkwfcwlyr fpmd btgxiubpdrw, xsidlw ku cbr! Vhngod nes cfav tlqd jhvv, ide M yutr fv wnl jfv. Xfvv ow geg fvgew xqsx fl xub Gafmic Kxbpckrtb: jtgi://ahe.ifglxiflnugbsya.dp/iryxro-ehneppvwf-xyk-qlpveer-sq-bxf-qzywvki-enlxpz-rvree/
- Hva aoh emvm yu? Pvgzr x eozfiyb qoh ckx zb mnbp :)
My Methodology
First try: the lazy way. I snagged the ciphertext and threw it in Decrypto by Blisstonia software in the hopes the answer would be solved by automation. No such luck.
Second try: experience based on past crypto challenges. I downloaded Cryptocrack, which I heard about in the CyberPatriot competition and ran it through a couple ciphers. Again, no such luck.
Winning try: tackling the mp3 first.
This Sounds Weird
After downloading the mp3, I listened to it, and it had that weird sound I can only describe as recognizing when something is played backwards. To see if that hunch was right, I downloaded Audacity and used the Reverse effect. Playing it after that effect revealed someone speaking letters in the NATO phonetic alphabet. When you record all the letters it instructs you to access a dropbox user content URL.
Image Analysis
Visiting the dropbox URL invokes a download of an image of John Malkovich holding a gun to a bunny's head. The file was a jpeg, so I figured there had to be something embedded in either the metadata or the picture itself via steganography. I didn't feel like downloading a piece of software for analysis, so I searched for photo forensics and came across this handy site: http://fotoforensics.com. Once you upload the picture and look at the metadata output, you'll see in the Comment field this description:
The ciphertext is created using the famous Vigenere cipher, once considered unbreakable. The key to reveal the cleartext is a combination of the a town located at the X Y coordinates where this picture was taken, and the make of the camera.
Obtaining the Vigenere Key
If you pop in the coordinates to mapping tools, you'll see it locates the town you need. Adding the town name only plus the make with no spaces provided the key.
Last Step
Deciphering the text reveals a URL for you to visit along with a message of thanks for assisting and instructions for you to let the Easter police know what you've found. When you visit the URL, you'll see a password prompt, into which you can enter the Vignere key and get a nice picture of the Easter Bunny waving and saying how thankful he is that you helped save him!
I submitted more details of my write-up in response to the challenge, but alas, I was too late. It was fun though! Thanks to the SANS folks to continue to provide these fun contests!
Wednesday, March 19, 2014
Labels:
CTF
,
maccdc
Read More
MACCDC 2014: Virtual Quals Lesson Learned
MACCDC 2014 - Virtual Qualifier Round
Some found my MACCDC 2013 write-up helpful, and more information is always better, so here's this year's lesson learned for the virtual qualifier round.
Choose a later time slot
This lesson is pretty subjective and I don't mean for it to sound negative or whiny, so please keep that in mind.
We chose one of the first time slots available this year in which to compete, and right after we were told "go!" we saw problems with the game infrastructure. The external IP addresses listed on the Flags tab were different than those listed on the Assets tab.
Here's a modified view of the Assets tab:
And here's the modified view of the Flags tab:
Struggling for Control
We connected to the external IP addresses on the Assets tab according to what team member was tasked to a respective system and tried to start the system hardening. Within the first 10 minutes, we noticed odd behavior that wasn't attributable to red team activity. We saw multiple sessions on Linux boxes and there were RDP battles on Windows. We then found out that our assets were swapped with those of another college! Once the game masters were aware of the issue, they started working on the fix.
In the mean time, all teams retained access to the systems to which they were connected. This meant that teams could still scour the systems to look for flag values to be submitted once the assets were re-aligned, as well as continue hardening their boxes. At this point, injects weren't assigned, so they weren't a concern.
Access Restored?
Once all machines were fixed in the scoreboard to be assigned to the correct teams, the games masters graciously reset the game clock. However, they did not reset the machines or the flags teams may have already captured. Of concern on that point is that according to the rules, whichever team submits flags first wins in the event of a tie. Well, with the start and end times now adjusted, we quickly went back to work.
Nope, Still Broken
Even after the game was reset, when we tried submitting flag values, they were not accepted by the scoreboard. The problem was that when you click on a flag to submit the value, although the main entry in the list was re-mapped correctly, the pop-up flag submission prompt still reported the old system. We had to take screen caps to prove what we were saying, as the game masters didn't believe us.
Conclusion
Now that you have a sense of the issues we were facing, I would recommend not choosing an initial time slot for fear of the game infrastructure being "buggy". The thought process behind this is that if your team chooses a later slot, then maybe by then the issues will be resolved and the game experience will be smooth. From a practical perspective, the time spent having to converse with the game masters about what is broken and why takes away time from your focus on system hardening, etc.
Something we found interesting is that not a single team from our round progressed to regionals...
Tuesday, March 18, 2014
Labels:
CTF
,
maccdc
Read More
MACCDC 2014: Sahana Eden Write-Up
This year, I was tasked to a linux box, even though my greater strength is in Windows. With the theme of this year's MACCDC being related to disaster recovery, I discovered the distro I had was Sahana Eden.
The tl;dr of this part is that I recommend once you learn of the MACCDC theme, look for related open-source linux distros (virtual appliances). Download a couple and mess around with them. Who knows, you might get lucky and pick the actual distro used in the qualifiers. At best, it will save you time once the competition starts and at worst you'll still learn to navigate your way around a linux box if you already aren't familiar.
What am I getting myself into?
Sahana Eden is, from their description:
... an Emergency Development ENvironment platform for rapid deployment of humanitarian response management. Its rich feature set can be rapidly customized to adapt to existing processes and integrate with existing systems to provide effective solutions for critical humanitarian needs management either prior to or during a crisis.If you'd like to download it yourself for experimentation, click here.
The Sahana Eden distro has webmin running by default, which coincidentally was a monitored service by the scorebot. Webmin, if you're not familiar (because I'd never seen it before!) is a web-based linux administration portal. By default, it was only accessible from internal addresses so you could only access it on the local host itself or from another asset. I debated trying to modify the configuration files to make it externally accessible, but since our Active Directory guy had his system set already I used his box to look at the webmin portal for anything useful. One less external vector for the red team, right? Since I'd never seen it, I originally assumed it was the web-app itself. Once I figured out that it wasn't, I was able to re-focus my attention on getting Sahana Eden up and running.
Sahana Eden Administration
First, let me say that the Sahana Eden documentation in terms of administration is not something you want to have to weed through during competition time, because the paths listed on the turnkeylinux site and the wiki are confusing and potential time-wasters.
The screenshot for Sahana Eden administration shows it being accessible via Web2Py:
The screenshot for Sahana Eden administration shows it being accessible via Web2Py:
To clarify though, this isn't really web-app administration in the sense of application-specific settings. It's more about installing the eden app itself. So where then do you go to manage the app? Many web-apps have an administration portal off the customer-facing component, which is accessible after you log in. The customer-facing portal of Sahana Eden looks like this:
According to the turnkey linux page:
first registered user will become the administrative user account
Seems simple, right? Riiiiiiiight... Attempting to create a user resulted in a database error. That means I need to fix the database issue before I can register a user so that I can get into the web-app!
Sahana Eden's DBMS
By default, when you launch the /var/www/web2py main script, you'll see a note in the loading banner that unless otherwise specified in the config files the database management system will be sqlite3. When I checked, sqlite wasn't installed, hence the failure.
I did notice however that mysql was installed, and it happened to have an empty eden database. My guess is that the distro has the eden database in mysql preset via the web2py console. The questions then are: (1) how to point the web2py config files to use mysql instead of sqlite3, and (2) how to populate the database with what's necessary to create the admin account.
To save time, just go to the Wiki's Virtual Machine Installation Guide and scroll down to the Next Steps section. We need to modify two files:
web2py/applications/eden/models/000_config.py
web2py/applications/eden/models/zzz_1st_run.py
The config.py file has all settings necessary to point web2py to use the mysql instance, so you can make the necessary changes there (NOTE: I backed up the existing file first to have something to revert to).
The 1st_run.py file will generate the tables, etc. in the mysql instance.
After re-launching web2py, the app will now be pointed to an installed DBMS and allow you to create the user, so you can then take a look around at the app and maybe complete an inject or two. wink, wink
Good Luck!
Friday, August 16, 2013
Labels:
Altamira
,
CTF
Last weekend, I participated in the first annual Altamira CTF competition, and I'm posting a review of my experience for those that would like to know what it was like and for those that may be interested in attending next year. The general overview of the game can be found on Altamira's Game Information Page, but the synopsis can be parsed down to three core objectives:
Offense
Altamira CTF 2013: Lessons Learned
Last weekend, I participated in the first annual Altamira CTF competition, and I'm posting a review of my experience for those that would like to know what it was like and for those that may be interested in attending next year. The general overview of the game can be found on Altamira's Game Information Page, but the synopsis can be parsed down to three core objectives:
- Defend a nuclear reactor from attack as well as maintain services and generate energy
- Actively exploit and attack opponents to obtain flags
- Scan network and identify hidden assets and obtain flags
Before the game began, we were provided with the rules of the game along with our internal/external IP space. Each team had a similar set up.
Tools
All team members used Kali 1.0.4 as their operating system of choice
for game play. Tools within Kali used in
the game included: metasploit 4.7.0 with postgres 9.1, armitage, nessus 5.0.3,
and ufw/gufw.
Special note. If using metasploit 4.7.0 as your framework, you must use Nessus 5.0.3 if you want to load the Nessus plug-in. Visiting Tenable's download page only leads you to links for 5.2.x. Here are a couple shortcuts to 5.0.3 to save you time from analyzing their site code and finding the package names:
Sharing
the Database
Prior to the competition, the team agreed that to eliminate duplication
of effort, we needed to use a shared database for offensive
purposes. At the same time, the shared
database needed to be protected. We set
up the postgres database, nessus, and an armitage team server instance to all
be accessible remotely. To protect the
centralized infrastructure, we leveraged ufw/gufw, which works great since it starts out with a default deny for incoming traffic. When the competition started, team members quickly fed me their IP addresses, and I loaded the rules into gufw. I'll be posting a separate guide on how to share out the database, which is simple once you've done it a couple times.
Defense
Once the game began, offense provided the defense the results of
scanning the team Scram server with the identified ports (80, 22). Accessing the team server via HTTP on port 80
showed us the web page where the actual Scram game was running:
Check out the video above for the full briefing, or click here to jump to what our interface looked like.
After logging in to the server via SSH, the
root password was changed. With the
password changed, the defenders set about learning how to play the Scram game
since megawatts per hour (MwH) was a scored component.
Discoveries
We learned about halfway through the game that another team analyzed their team
server's game code and found a way to accelerate their point gain. We did not dedicate enough resources to
emulating this approach until the last hour of the game (fail!).
The Scrame game itself was built in python and had multiple
components. There was an environment.py
script which contained variables and formulas in which the score was
calculated. In another directory was a
network.py script which took the results and sent them to the scorebot. The packet was ultimately crafted using scapy
in another python script. The service
for these python scripts was something called "twisted" that utilized
websocket initialization scripts, also written in python. A danger in altering the game code was that
depending on the alteration, teams would need to restart the service components
and do so in the right order. Failure to do so would result in a loss of
accumulation of points. Note to self, learn things...
Offense
As soon as the team was wired in, offense scanned both the
internal network and the external network to identify hosts. The scan was run
using Armitage, and because we didn't know of any hosts, we included the whole
ranges. Results populated
"live" hosts and "ghost" hosts. Scanning a "ghost" host resulted in
no open ports. Not having read
Armitage's documentation, Armitage may automatically place an entry for each
host in the range through its scanning script.
For cleaning our visual display, we set the view to table view and
removed "ghost" hosts. Note to self, learn to avoid this in the future.
With the remaining live targets, we ran multiple port scans
and nessus scans against them. We were
able to get shells on two or three linux machines. All Windows machines were running Windows 7. More on that in the next paragraph.
Discoveries
From one of the shells, there was limited command line
access. Commands like "ls"
worked, but "cd" and pretty much anything else did not. We did not attempt to load another shell (fail!).
Several of the Windows machines were Windows 7 Service Pack
1, build 7601. The default install of
Metasploit 4.7.0 does not have any exploits for that build. MS_09_50 did not work. Enumerating these machines using the endpoint
mapper auxiliary module revealed 6 to 7 machines were part of the same domain
(PONY_GROUP), while 3 to 4 were part of another domain (NOVAC). Had we gained access to one Windows 7 machine
in either domain, we could've used pass the hash to get access to the others. Shoulda, coulda, woulda...
Lessons Learned
- CTFs in this format are "unknowns", meaning be prepared the best you can and expect something new and different
- In CTFs where hacking the game mechanism itself is allowed, resources should be devoted to analyzing the game code at the start
- Where CTFs provide information about the infrastructure, such as in this case the game Scram, study and any all related resources prior to the start of the competition
- Have a tool such as WinSCP or know how to secure copy in Linux to copy files and folders from an SSH session
- Identify all known metasploit modules/exploits built by others for use against Windows 7 and test usage
Additional Information
Sunday, May 5, 2013
Labels:
CCDC
,
CTF
,
maccdc
This is the fourth part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is the table of contents:
1) Make the most of your time. This can be construed multiple ways, but if team members don't have access to the machines as expected, immediately start finding an alternate path. Familiarize yourself with the scorebot gui to locate flags and injects. If you're waiting for an answer on something, try to multi-task. There ideally should never be a time where someone is sitting and doing absolutely nothing.
2) Don't get over-confident. I'm guilty of this myself. I set down the basics on two linux boxes without setting deeper security, and they both got owned on day two. So, no matter the standings point-wise, don't stop securing a system until the end of the competition.
3) Communication. It's the team captain's responsibility to receive and assign injects. At the same time, the team captain is going to be pulled in multiple directions. Therefore, the team captain needs to effectively disseminate the injects so that the whole team can be aware of all the details. This can be done by having the team captain log in to every machine so each team member can see the injects, or he/she can assign the injects. If assigning injects, the approach should be the team captain asking the team for familiarity with the subject and assigning the inject to the team member with the most familiarity. If no one knows the inject subject, then the team captain should assign it to the person with the most availability to multi-task.
3) Receiving injects. Injects are a high scoring component of the game, so the team needs to identify all potential ways injects can be delivered. This year that included a) email, b) phone, and c) sneakernet. Within the first two hours of competition time, these methods should be identified and monitored.
4) Inject handling. When team members receive an inject, those same team members may get pulled away from completing it. If so, then the team member that was handling that inject needs to hand it off to another team member to ensure it gets completed or progress is made. Basically, an inject should never stop being worked. This will ensure the team receives points for completing the inject and that it will be finished in case another inject builds upon it. When injects are received the team captain needs to identify the deadline and keep monitoring progress as time ticks down to the deadline so the inject completion does not fall by the wayside.
5) Scorebot. Each team member needs to, at some point, open scorebot and monitor the respective services on their assigned VMs. Identify the services with the most points scored, and try to ensure that they stay active. If the team members do not have time, then the team captain can perform this function on the "high side" (if there is one).
And that wraps up my lessons learned from a high-level. I hope this helps those preparing for CCDC-type competitions. Check out Rob Fuller's presentation for more technical detail.
Read More
MACCDC 2013, A Blue Teamer's Lessons Learned: Part 4 - Game Time
This is the fourth part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is the table of contents:
#1 - Team selection
#4 - Game Time
Game Time
1) Make the most of your time. This can be construed multiple ways, but if team members don't have access to the machines as expected, immediately start finding an alternate path. Familiarize yourself with the scorebot gui to locate flags and injects. If you're waiting for an answer on something, try to multi-task. There ideally should never be a time where someone is sitting and doing absolutely nothing.
2) Don't get over-confident. I'm guilty of this myself. I set down the basics on two linux boxes without setting deeper security, and they both got owned on day two. So, no matter the standings point-wise, don't stop securing a system until the end of the competition.
3) Communication. It's the team captain's responsibility to receive and assign injects. At the same time, the team captain is going to be pulled in multiple directions. Therefore, the team captain needs to effectively disseminate the injects so that the whole team can be aware of all the details. This can be done by having the team captain log in to every machine so each team member can see the injects, or he/she can assign the injects. If assigning injects, the approach should be the team captain asking the team for familiarity with the subject and assigning the inject to the team member with the most familiarity. If no one knows the inject subject, then the team captain should assign it to the person with the most availability to multi-task.
3) Receiving injects. Injects are a high scoring component of the game, so the team needs to identify all potential ways injects can be delivered. This year that included a) email, b) phone, and c) sneakernet. Within the first two hours of competition time, these methods should be identified and monitored.
4) Inject handling. When team members receive an inject, those same team members may get pulled away from completing it. If so, then the team member that was handling that inject needs to hand it off to another team member to ensure it gets completed or progress is made. Basically, an inject should never stop being worked. This will ensure the team receives points for completing the inject and that it will be finished in case another inject builds upon it. When injects are received the team captain needs to identify the deadline and keep monitoring progress as time ticks down to the deadline so the inject completion does not fall by the wayside.
5) Scorebot. Each team member needs to, at some point, open scorebot and monitor the respective services on their assigned VMs. Identify the services with the most points scored, and try to ensure that they stay active. If the team members do not have time, then the team captain can perform this function on the "high side" (if there is one).
And that wraps up my lessons learned from a high-level. I hope this helps those preparing for CCDC-type competitions. Check out Rob Fuller's presentation for more technical detail.
Monday, April 29, 2013
Labels:
CCDC
,
CTF
,
maccdc
This is the third part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
The team needs to have practice sessions where the systems are actually available to be utilized. Scenarios should be utilized for practices to provide a sense of what the competition will be like. During the practice sessions, each person should tackle the systems they're comfortable with first and then swap to something they are not comfortable with, such as starting on Windows and switching to Linux.
Any tools desired to be used for competition time need to be vetted first. Concerning tools, a quick note:
Toolsets - 1st party. Each system has its own built-in security tools that could be leveraged. Windows Server 2008 has an advanced firewall in which rulesets can be provisioned pretty granularly. Linux distros typically have IPTables. These types of basic built-in tool sets need to be learned through practices. Before the shiny, fancy tools can be downloaded from the internet station these built-in tools are all you have to work with.
Toolsets - 3rd party. Everyone loves finding research indicating a particular tool can do this or that, but unless you've actually used it and are comfortable implementing it, it's a waste of time and effort. Team members should prune the tool set at least a month before competition time to narrow down a definitive list. During that month or so prior to the competition, during practice sessions these tools need to be tested and tested from both a standalone and live-attack scenario (red-team sessions).
Scripting. Red teamers automate as much as possible, and so should the Blue team. Find simple scripts that can do some brute force defense while trying to lock down the system. These scripts can be kicked off immediately and just run in the background, without waiting to be attacked first. If they're already running from the start, at least they immediately kick off a Red team member, which prevents them from setting up persistence or at least slows them down.
Continue reading MACCDC 2013, Part 4
Read More
MACCDC 2013, A Blue Teamer's Lessons Learned: Part 3 - Practice
This is the third part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
#1 - Team selection
#3 - Preparation (PRACTICE!)
#4 - Game Time
Preparation (PRACTICE!)
The team needs to have practice sessions where the systems are actually available to be utilized. Scenarios should be utilized for practices to provide a sense of what the competition will be like. During the practice sessions, each person should tackle the systems they're comfortable with first and then swap to something they are not comfortable with, such as starting on Windows and switching to Linux.
Any tools desired to be used for competition time need to be vetted first. Concerning tools, a quick note:
Da Tools
Toolsets - 1st party. Each system has its own built-in security tools that could be leveraged. Windows Server 2008 has an advanced firewall in which rulesets can be provisioned pretty granularly. Linux distros typically have IPTables. These types of basic built-in tool sets need to be learned through practices. Before the shiny, fancy tools can be downloaded from the internet station these built-in tools are all you have to work with.
Toolsets - 3rd party. Everyone loves finding research indicating a particular tool can do this or that, but unless you've actually used it and are comfortable implementing it, it's a waste of time and effort. Team members should prune the tool set at least a month before competition time to narrow down a definitive list. During that month or so prior to the competition, during practice sessions these tools need to be tested and tested from both a standalone and live-attack scenario (red-team sessions).
Scripting. Red teamers automate as much as possible, and so should the Blue team. Find simple scripts that can do some brute force defense while trying to lock down the system. These scripts can be kicked off immediately and just run in the background, without waiting to be attacked first. If they're already running from the start, at least they immediately kick off a Red team member, which prevents them from setting up persistence or at least slows them down.
Continue reading MACCDC 2013, Part 4
Labels:
CCDC
,
CTF
,
maccdc
This is the second part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
If possible, teams should stage ESXi servers with VMs emulating the systems they can expect to see at MACCDC. These VMs are nothing more than basic installations including Windows 2000 (yes, really), Windows XP, Windows Server 2008, Ubuntu and more with web applications or other services. These systems can be staged and a scenario could be executed similar to that for MACCDC to get an idea of what's involved in securing each system.
Speaking from experience, if the centralized lab cannot be easily worked out or it turns out to be unreliable, team members should fall back on using VM Workstation and working with the VMs one at a time. The independent work can be performed between sessions where the main ESXi server is available or if there isn't an ESXi server at all.
Continue reading MACCDC 2013, Part 3
Read More
MACCDC 2013, A Blue Teamer's Lessons Learned: Part 2 - Staging a Lab
This is the second part of a series of blog posts I'm writing to relate the various things I learned from getting to experience the glory that is MACCDC. Here is a "table of contents" which I'll update with relevant posts:
#1 - Team selection
#2 - Preparation (staging a lab)
#4 - Game Time
Preparation: Staging a Lab
If possible, teams should stage ESXi servers with VMs emulating the systems they can expect to see at MACCDC. These VMs are nothing more than basic installations including Windows 2000 (yes, really), Windows XP, Windows Server 2008, Ubuntu and more with web applications or other services. These systems can be staged and a scenario could be executed similar to that for MACCDC to get an idea of what's involved in securing each system.
Speaking from experience, if the centralized lab cannot be easily worked out or it turns out to be unreliable, team members should fall back on using VM Workstation and working with the VMs one at a time. The independent work can be performed between sessions where the main ESXi server is available or if there isn't an ESXi server at all.
Continue reading MACCDC 2013, Part 3
Subscribe to:
Posts
(
Atom
)
