Discussion


For this week’s discussion our focus will be upon developing a brief (1-2 page) forensics data collection plan to be used during a Red Team exercise. Your plan will be used as part of training exercise for incident response personnel to help them learn to identify and collect evidence.
Your first task is to analyze the Red Team’s report to determine what they attacked or what attack vectors were used.  Next, analyze the environment to determine what types of forensic evidence should be collected after the attack(s) and where that evidence can be collected from. You should consider both volatile sources such as RAM (memory) and static sources such as disk drives, thumb drives (USB storage devices), etc. After you have identified the types of evidence and the devices from which evidence should be collected, document that in your short paper (the “plan”).
At a minimum your plan must document evidence collection for three specific attack vectors or vulnerabilities that were exploited by the Red Team as part of its penetration testing. For each vector or vulnerability, document what type of evidence could be collected and where the evidence should be collected from.

Resource
Red Team Penetration Testing
Sifers-Grayson hired a cybersecurity consulting firm to help it meet the security requirements of a contract with a federal agency. The consulting firm’s Red Team conducted a penetration test and was able to gain access to the engineering center’s R&D servers by hacking into the enterprise network through an unprotected network connection (see figure 2). The Red Team proceeded to exfiltrate files from those servers and managed to steal 100% of the design documents and source code for the AX10 Drone System. The Red Team also reported that it had stolen passwords for 20% of the employee logins using keylogging software installed on USB keys that were left on the lunch table in the headquarters building employee lounge (see Figure 3). The Red Team also noted that the Sifers-Grayson employees were quite friendly and talkative as they opened the RFID controlled doors for the “new folks” on the engineering staff (who were actually Red Teamers).
The Red Team continued its efforts to penetrate the enterprise and used a stolen login to install malware over the network onto a workstation connected to a PROM burner in the R&D DevOps lab (See Figure 3). This malware made its way onto a PROM that was then installed in an AX10-a test vehicle undergoing flight trials at the Sifers-Grayson test range (See Figures 1 and 4). The malware “phoned home” to the Red Team over a cellular connection to the R&D center. The Red Team took control of the test vehicle and flew it from the test range to a safe landing in the parking lot at Sifers-Grayson headquarters.
The Red Team used three stolen logins to send Phishing Emails to employees. These phishing emails appeared to come from coworkers (employees of the company) and contained a link to one of three videos. Each video was linked to a server that tracked the email address and IP address of the computer used to access the video. The Red Team reported that over 80% of the recipients clicked on the video link for cute kittens or cute cats. Twenty percent (20%) of the recipients clicked on the video link for a business news story. A video link to a sports event wrap-up for the Kentucky Volunteers basketball team had over 95% click-through rate. All three videos displayed a “Page Not Found (404 Error)” message from the target server. The Red Team did not put a tracking beacon in the emails to track forwarding of the phishing emails. But, the team reported that the target server collected email addresses and IP addresses for over 1500 external recipients within 24 hours of the original mailing; at that point, the target server was shutdown.
After completing their penetration tests, the Red Team provided Sifers-Grayson executives with a diagram showing their analysis of the threat environment and potential weaknesses in the company’s security posture for the R&D DevOps Lab (see figure 5).
Incident Response During the Penetration Test
Sifers-Grayson has limited Incident Handling and Response capabilities in place. The company’s Chief Operating Officer has a small IT team (team lead and two support specialists) that focuses primarily on the IT needs of headquarters personnel. Their duties include staffing the help desk phone line and handling any incidents that affect availability of company owned IT equipment and networks. The single firewall for the company falls under this team’s management and control. It was not capable of detecting the Red Team’s intrusions and was not configured to provide alerts for any failures or faults.
Computer and network operations for the SCADA Lab and R&D DevOps Labs have traditionally been the responsibility of the Engineering department. Engineering sees itself as separate from the rest of the company and takes care of its own IT needs. There is no formal incident response capability. Instead, the lab manager for each lab tasks engineering staff to manage the workstations. If network maintenance or upgrades are required, the Engineering Department hires contractors to perform the work. Responsibility for providing oversight for these contractors is rotated between the junior engineers.
The Data Center manager has a staff of two systems administrators who are also responsible for identifying and responding to incidents which impact server availability. The Data Center does not have any automated detection systems in place to provide alerts for intrusions. It does, however, have heat alarms, smoke detectors, and water detectors which sound audible alerts through klaxon horns. Neither of the system administrators detected any anomalies in server or local area network operations during the penetration test.
There was no effective incident response during the penetration test. In large part, this was due to the lack of a centralized team with responsibility for enterprise monitoring and response for network incidents and computer security incidents. Incident response also fell short because there were no automated detection capabilities. Finally, the company’s ability to perform forensics investigations after the penetration testing was limited due to a lack of knowledge (no trained personnel), lack of forensic analysis tools, and a limited number of log files on the servers and firewall.