Judgment of Acquittal: Breach of Computer Security (P2)
In our first post, we reviewed the breach of computer security statute in Texas and the facts underlying our client’s criminal charges. In this post, we will begin to dive into the forensic weeds of the state’s case. At every step, the state’s allegations fell apart under the scrutiny of competent expert assistance and forensic analysis.
The State’s Case for Breach of Computer Security
The state’s case can be split into two overarching theories. The first theory related to damages observed to the three physical computers that comprised the company’s network. The second theory related to deletion of digital assets within the company’s file repositories. These theories both rely on an accurate understanding of the underlying network and structure.
Factual Background
The company’s network consisted of the three physical devices above. These three devices were connected via a 10 GB switch. If properly connected, and operational, a software engineer could easily navigate the file repositories and other digital assets. Each device had a unique role in the architecture:
- The Development Machine (DM) – this device served as a sandbox for active development. The DM was a Windows Machine with software applications for all development. In addition, the machine was in-tune registered with the company’s Microsoft Azure account.
- The Active Directory Server (ADS) – this device was the ADS for the company’s network. The computer that held the file repository (FR) and the DM were registered with the ADS. The ADS held the password permissions for the other devices on the network. In addition to its central hub status, the ADS served as a host for all virtual machines found on the other devices.
- The File Repository Device (FR) – this computer held numerous virtual machines owned by the company. These .vhd or .vhdx drives held all the digital assets that belonged to the company. The virtual drives could only be opened with access to a virtual machine host. Here, the ADS served as the host machine. Though another computer with the proper configurations could serve as the ADS with proper knowledge of the network.
If all three computers were operational, and properly connected, a user could navigate the company’s digital assets, password permissions, and latest source code entries with ease. However, if any one of those devices failed, the company would need an expert to recreate the wheel.
In addition to the above architecture, the company paid for a Microsoft Azure subscription. The company’s Azure account held numerous registered devices, including hardware needed to run prototypes built by our client. Further, it contained its own virtual machines that were integral to operating the latest demonstration built by our client. In short, the company’s Azure portal was a separate, but equally important, part of their overall network.
While there are numerous complexities within these overarching systems, this general layout should provide a foundation for understanding the state’s case and our defense at trial.
The Company Cannot Set up the Physical Devices
After the three computers were returned to the company, the company shipped the computers to an IT expert. The IT expert’s sole task was to power on the devices, log in, connect them through the switch, and ensure proper function. He was not retained, according the CEO, to troubleshoot any of the devices.
The IT expert struggled immediately to get the devices up and running. For ease of understanding, we will tackle each device separately.
Active Directory Server
We will start with the central hub because problems in the ADS permeate through the other devices. When the IT expert powered on the ADS, he immediately ran into issues. The ADS would not load the login screen. The boot screen would flicker and then the device would shutdown. This behavior occurred in an endless loop.
The IT expert contacted our client for assistance with the device. After walking the IT expert through the Bios on the machine, our client became concerned a card had become unseated or the power supply was failing. He advised the IT expert on next steps. The IT expert continued to allow the computer to continuously restart for hours; against our client’s advice. After a few hours, the power supply failed on the device.
The IT expert replaced the power supply on the machine and booted it back up. This time, the machine registered an error code (blue screen). Instead of troubleshooting the device, the IT expert stopped there. He took photos of the blue screen, passed them along to the CEO for use in the criminal case, and moved on to the other devices.
Development Station
The next computer the IT expert reviewed was the DM. The DM powered on; however, the password our client provided for the machine did not work. The IT expert took a photo of the password not working, sent it to the CEO, and moved on.
File Repository
The IT expert then powered on the file repository machine or FR. The FR powered on as expected. The password the client provided allowed him to login. The IT expert passed along this information to the CEO.
The Issues with the ADS and Development Station Were Attributed to Our Client
The company alleged our client was responsible for the failure of the network. The company alleged our client corrupted the ADS and provided fake passwords for these devices. They alleged our client had taken action to ensure the company could not recover their network.
Without any curiosity, this charge seems possible. At first glance, it seems odd that the computers failed to operate after their return to the company. Having said that, computers do fail for a host of reasons and passwords within a connected network may fail for reasons unrelated to bad acts.
Unfortunately, the prosecution suffered from a dangerous combination that included a lack of curiosity and incompetent experts to guide their analysis. Instead of hiring competent help and figuring out why systems failed, the state took the lazy approach. They took the CEO’s statements at face value. Their case lived as long as no one actually reviewed the network and system logs. Ignorance was bliss.
Though the defense had no obligation to prove any fact, our team was insanely curious about what really happened to these computers. The defense team had access to our client, and a team of experts from Dallas, to resolve that curiosity. Our investigation entailed reviewing the forensics, the network structure, and Windows logs for all three devices to determine the real cause of the issues. Our special focus was on the two machines that were not operational, the ADS and DM. Our findings were as follows:
ADS Findings
After review of the log files, we determined the ADS power supply failed two hours after it was initially booted (presumably at the IT expert’s lab). At the time of the power supply failure, the computer was making critical updates to the SYSTEM registry files. These two facts indicated the power supply failed during a critical Windows update on the device.
With assistance from our expert, we were able to recreate the ADS on a virtual machine host. Once it was recreated, we were able to review the blue screen error code to solidify our findings. The error code in this case was common if a system was shut down during an update. The forensic findings, and the resulting error code, allowed us to make the following findings: 1) the ADS was six years old, 2) the ADS was operational before our client powered it down, 3) the ADS suffered a power supply failure hours after its first reboot with the company, 4) this power supply failure occurred while critical registry files were being updated on the machine, 5) the ADS flashed an error code following the replacement of the power supply, and 6) the error code was consistent with a device being shut down (here, due to a power supply failure) during a critical Windows update. Our experts conclusively proved that the ADS issues had nothing to do with any actions by our client.
We could have stopped there and gutted the state’s allegation under the ADS. However, we decided to take it one step further. With our client’s help, three hours of work, and using only the state’s forensic drives, we were able to recover the ADS. At trial, we were not only able to show why the system failed, but the exact steps required to recover it. The company’s IT person admitted he did not know how to recover it and was never asked to recover it by the company. The company’s cries of “three years” without their network fell flat when the judge was shown the simple steps a competent professional could take to recover that device.
Development Station Findings
The development station was operational; however, the company’s IT personnel could not log in using the password credentials provided by our client. The state argued that our client intentionally provided false passwords to stymy the company.
The state’s charge again suffered from a lack of expertise and incomplete information. Without an adequate understanding of the network, and the role of the ADS within that network, one cannot come to any conclusions regarding the veracity of a password.
The company’s computers were connected via a network domain. The connected systems, and this domain, comprised the company’s “network” referenced throughout the trial. The ADS served an important role within the network. Notably, the ADS stored hash values for all passwords on domain registered devices. For a password to function, one of two things had to happen: 1) the registered device (here, the DM) had to connect to an operational ADS to authenticate the password or 2) the password must have been used before on the DM to create a local hash value. If a new domain level password was created, and the password was never used to login into a domain registered device, the password would only work if the ADS was operational and connected.
This structure is somewhat complicated. A hypothetical will likely assist in understanding the issue. Let’s assume we have two computers, an ADS and a workstation. Those two computers are connected by a switch and are registered to the domain beachofcomputersecuritylawyers.com. If a user logs onto the ADS and changes the administrator password, the new password is only cached on the ADS. The development station will only authenticate the domain password if the station is properly connected to the ADS via the switch. The station must communicate with the ADS and authenticate the password before the machine will load windows. However, once the station has authenticated the password for the first time, the station will cache that password on the local machine. For all logins following that initial login, there is no need for the ADS to be operational for the credentials to authenticate.
Let’s apply that hypothetical to the facts in our client’s case. When our client powered down the three computers for the last time, he changed the domain administrator password. He provided the password to the company. However, he did not use the new password to log into the development station locally prior to returning the equipment.
If the ADS was operational, the development station credentials would have authenticated. However, when the ADS suffered a power supply failure, and subsequent registry error, the development station could not access the cached password for authentication. The company needed to fix the ADS to properly authenticate devices across the domain registered computers.
This phenomenon also explained why the company was able to log into the FR. Through Windows log files, we were able to confirm the client did log into the FR locally after the new password was created. The FR locally cached that password; eliminating the need for the ADS to authenticate each subsequent login attempt.
Through the forensic review, and recovery of the ADS, we were able to show this process in action. Once the ADS was recovered, we could show the change in the password, the cache of the password hash on the ADS, and reasons behind the password’s success on two devices (ADS and AMS) and not the other (DS).
Frustrating Experience
The prosecution fell flat on these issues because they did not have the expertise required for thorough analysis. When you have multiple registration levels (domain and local), and computers that serve different functions on the network, it is imperative that an expert understands the hardware stack before analyzing particular issues. If the company or state had retained competent assistance, they would have highlighted these potential causes, reviewed the forensic drives for confirmation, and likely understood their limitations. Instead, the prosecution took the easy road. They listened to the company, noted the password did not work, and called it a day.
Fortunately for our client, computers have a long-lasting memory. They hold detailed logs of every action on a particular device. Absent foul play, they do not suffer from memory loss or bad facts. They can tell a story more compelling than any witness. The story was right there in the state’s discovery. They just lacked the ability to uncover it.
The state’s charge under the “sabotaged their network” theory was totally eviscerated at trial. The state was left reeling as they tried to revive this argument with no foundation for any of their claims. Unfortunately for them, the computer told a story that undercuts their entire narrative.
Conclusion
The state’s allegation that our client sabotaged the physical devices lacked any real evidence. The state relied on the testimony of interested persons to weave a narrative. That narrative was precisely unwoven over the course of the week long trial. After cross examination of state experts, two things were clear: 1) the state had no evidence our client did anything to sabotage the devices and 2) the state was inadequately prepared to support their narrative.
In part three of this blog, we will review the second part of the State’s case. This theory involved allegations that our client removed vital source code from the file repository in the days following his resignation. This theory will suffer a similar fate.