OK, here are my responses. Anyone care to comment?
Challenge Question 1: What is the most probable reason Michael could not get network connectivity from the desk Ethernet jack? What actions should the team take to determine exactly what is going on, collect full traffic captures, and gain full access to the network?
A probable explanation is that GATE corporation is using the equivalent of Cisco's port security on the network port where Michael was connected. This allows them to lock down the use of a port to a device with a specific MAC, or a range of MACs (for VOIP phones with a built-in switch).
The team should try to spoof the MAC of the voip phone in order to gain network access. If the MAC of the phone is not easily accessible, they could reconnect the phone to a portable ethernet hub and sniff the DHCP requests. This would likely require a portable power injector like the Cisco AIR-PWRINJ1. Once the MAC is discovered, use the "macchanger" utility included on the BackTrack 4 CD to spoof the MAC and issue a DHCP request.
As long as the network port allows traffic beyond SIP and voip protocols, the team should be able to continue with their packet captures.Challenge Question 2: What tool should Lincoln download, if any, to be able to capture traffic on the desktop computer?
From the screenshot provided, it looks like nmap 4.85beta9 and windump have been copied to the machine already. Since nmap includes the winpcap libraries that windump relies on, it is only necessary to unpack and install them. Given that the account we have on the desktop is Administrator, we won't need to perform a reboot to use winpcap.
As described below, unless an unzip utility like winrar, 7-zip, or pkunzip is available, we would need to get that in place. If Java is installed, it may be possible to use the "jar" utility to uncompress the nmap package.Challenge Question 3: Starting with the reverse connection from the desktop computer, describe a step-by-step approach that could be applied prior to 09:00 the next day in order to capture the network traffic on the remote network and get a capture file for further in-depth analysis. Make sure your approach follows Michael's advice to avoid detection.
First, winpcap libraries must be installed so that we can capture packets using windump. Fortunately, the nmap package that is present on the General's machine includes a version of the winpcap installer that can be started in silent mode.
The biggest problem we face is unzipping the nmap package. Upload a copy of 7-zip or some other unzip utility that would escape detection (this should be ok to upload, since the filesize of 7-zip is 939,956 bytes).
Note: although this is one way of unzipping the file, it is certainly not the best way. It would probably be detected since the new software will show up in Add/Remove programs, and any host based package management or inventory software will detect it.
Follow the steps below to unzip and install the necessary software and begin the packet capture. All of these steps are performed from within the metasploit console, unless otherwise indiciated.
1.Navigate to C:\Scylla:
2.Upload the 7-zip installer and run it in silent mode:
execute -f "7z465.exe /S /D=C:\Scylla"
3.Unzip the nmap package and install winpcap:
execute -H -i -f "cmd"
"c:\program files\7-zip\7z" x nmap-4.85BETA9-win32.zip
4.Once winpcap is installed, we can create a script to run windump from a hidden shell:
echo CreateObject("Wscript.Shell").Run "C:\Scylla\windump.exe -w capture.pcap", 0, False > run.vbs
5.Run the script as follows:
execute -H -f "run.vbs"
It may be possible to run the script as a scheduled task, but running it by hand is simpler at this point. It would also make sense to add further options to the windump command line to capture only the first 1000 or so packets after the General begins his web session. Once the packet capture is finished, use the other allotted transfer of a file to retrieve the capture from the desktop.
One major flaw in this approach is the fact that Windows UAC will prompt the user that the software installation is taking place. As an administrator it is possible to disable this prompting according to the following (from http://blogs.msdn.com/windowsvistasecurity/archive/2007/08/09/faq-why-can-t-i-bypass-the-uac-prompt.aspx
Having said all that, there is a Local Security Policy option to change the behavior of the elevation prompt for Administrators to "elevate without prompting". With this option selected, anything that requests elevation gets elevated without prompting the user. (The default setting is "prompt for consent"; the third option is "prompt for credentials". Note that "elevate without prompting" is available only for members of the Administrators group. The options for standard users are "prompt for credentials" and "automatically deny elevation requests".) While "elevate without prompting" may be useful in well-constrained, secure environments for automated testing and possibly for initial system setup, having this option selected otherwise is very risky and strongly discouraged. (Note also that Vista's Home SKUs do not include the policy editor.)
The challenge here is that this needs to be performed with the Local Policy Editor, which requires GUI access. I didn't have a chance to perform this myself, but it may be possible to use the ”getgui” custom meterpreter script to enable RDP to the desktop. With that in place, an RDP session could be established to the desktop. From there, using the policy editor could be accomplished.Challenge Question 4: Help the team complete this aspect of their mission by analyzing the packet capture file collected on the desktop computer and provide detailed information about the environment. Your response should at least include the type of network traffic collected, details about the General’s laptop computer, details about the Scylla Codes server plus any other server available, and provide the names and contents of the files stored on the server the input passphrase is based on.
I began by loading the packet capture into Wireshark. I first noticed that there was SSL data in the capture. Fortunately, the server's private key can be found in the backup.zip file provided by Roland.
In order to decode the HTTPS session data in Wireshark, I loaded the server's private key, by performing the following steps:
1Navigate to Edit -> Preferences -> Protocols -> SSL
2In the RSA keys list field, type the following:
We now have the capability of following decrypted SSL streams in the session. Following each transaction in order, we have the request/response cycles listed below.
<all HTTP request/responses redacted for brevity - suffice it to say that all images and HTML data was recovered.> Analysis of hosts based on packet capture
The packet capture contains 7 request/response cycles originating from 10.10.10.91 (the general's laptop), destined for 10.10.20.94 (the server). The transactions were sent over an SSL connection. No other hosts appear in the packet capture, and all miscellaneous network traffic, such as ARP, have been removed.
O/S: Microsoft Windows Vista
Browser: Internet Explorer 7
Features: .Net common language runtime v. 2.0.50727, .Net common language runtime v. 3.0.04506, Security Licensing Component
Most of this was determined using the UA-string in the requests:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)
HTTP Server: Apache 2.2.8
Features: mod_ssl 2.2.8, OpenSSL 0.9.8g, mod_dav 2, PHP 5.2.9
This was determined from the server response headers:
Apache/2.2.8 (Unix) mod_ssl/2.2.8 OpenSSL/0.9.8g DAV/2 PHP/5.2.9
Challenge Question 5: What are the validation code and input passphrase used by the General to generate the Scylla validation code for this week?
I was able to determine from the HTTP post below that the code is: “6189db841f01413a05a53b7135137a17”.
POST /code.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, */*
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506)
The file that was downloaded, file.zip, contained two files that appear to be robots.txt files. The files, new.txt and old.txt hold a long list of directories and files on the server. Digging through the old.txt file, there are several filenames that indicate they were part of a government website. One line in the file stood out:
The validation code looks like an md5 hash to me, so after a little digging, I found that the hash “6189db841f01413a05a53b7135137a17” is the md5 hash returned for the string “http://www.whitehouse.gov/robots.txt". I confirmed this with the following php code:
php -r 'echo md5("http://www.whitehouse.gov/robots.txt") . "\n";'
I am going to presume that the input passphrase is the string above (the URL http://www.whitehouse.gov/robots.tx
), and that the validation code is the md5 hash produced.
I have a strong suspicion that the two GIF images (Scylla.gif and TheCompany.gif) contain hidden information. I stumbled across a site that allows users to generate logos using the same font and color scheme that Google uses (http://googlefont.com
). I generated my own images and noticed that the canvas sizes of the GIFs were identical to those that were recovered from the packet capture. However, the images I generated were about one quarter of the size of those recovered.BONUS QUESTION: Briefly describe your recommendations about how The Company could have detected and defended against the tactics you described in your answer to Question 3.
The simplest way to detect the method I described would be to implement group policy that would prompt even the Administrator account when installing software. As mentioned earlier, the policy should be set to either “Prompt for consent”, or “Prompt for credentials”.