The morning begins with a minor disappointment: matching the file signatures has not produced any new findings. I will therefore need to look over the installed programs. Mr Waldmann immediately wants to get stuck into the program folder. However, I make it clear to him that we are operating according to my rule book – orderly and systematic. Otherwise, he could have done the investigations himself in the first place – and risk going down in flames in court.
As the notebook was installed via a deployment server, I first get my reticent security officer to provide a freshly installed notebook of the same type as Mr Steinbach's for reference.
After thoroughly checking the device manually, and finding nothing, I work on the assumption that the computer is virus free, but I make a mental note that an unknown rootkit could still be at work. A few mouse clicks later I've used the reference PC to create a hash table of all executable programs including .exe files, DLLs, drivers etc. I then match the hash values with the image of Steinbach's hard disk and mark all known program files as irrelevant.
The remaining number of program files is manageable, and one product particularly stands out: VNC, the remote maintenance program we already found on the haunted PC. Of particular interest is PushVNC.exe, a program that, given sufficient admin privileges, can install the VNC service on another computer without causing an icon to appear in the system tray.
The pieces of the puzzle are beginning to form a picture. Mr Steinbach apparently installed a VNC service on the IT executive's computer and was stupidly caught out when remotely controlling the computer via VNC. To find out whether Steinbach viewed other information, I examine the
Recent\ directory in his user profile. This folder is usually hidden under Windows and often contains hundreds of link files, each of which includes the file that was opened as well as its path and time stamp.
The user profile contains numerous links to network shares that have an
\\IP_address\C$ structure and are, therefore, connections to the admin shares on various computers. Waldmann quickly establishes that Steinbach has no business on any of these systems. I create a time line using the time stamps in the link files. The result reveals a regular pattern: Steinbach searched the computers' administrative shares for potentially interesting files during his working hours, and then studied the files after work.
We print out some of the compromised documents and present our findings to the head of IT and the head of human resources. The latter is shocked to find his secretary among the victims of the spying attack, but calms down again after briefly looking over the documents we have found. Only the org chart has attracted his attention: the draft restructuring measures have so far only been discussed by the board and the human resources department, and the document was still classified as "strictly confidential" at the time. Further discussions soon reveal that the management's trust in their employee has been shattered. Nevertheless, I convince them to postpone their decision about what further action is to be taken. One item is still open on my to-do list: I want to examine the system start in detail to make sure that the virus scanners haven't missed a rootkit after all.
Very carefully, I look at the registry and file system to find out which drivers and services are launched during start-up. The drivers and services are listed in the Services key of the
CurrentControlSet; individual flags handle the activation of the software. The entire boot process is described in detail in the Windows Internals standard work. Another opportunity for my forensic toolkit's registry report feature to come to the rescue. After combining my data with a table that contains the configuration of a freshly installed Windows system, I soon detect the additionally installed drivers and services. They are all associated with a product that has been installed in the regular way. Checking the usual keys such as
RunOnce doesn't produce any abnormalities. I can therefore offer no reason to believe that Steinbach is innocent.
All that's left for me to do is the last, and most elaborate, part of my work: to write an investigation report which explains the technical scenario in such a way that someone who doesn't "breathe bytes" can understand them. The final document is 40 pages long and doesn't give Steinbach any room for excuses. I later find out that he left the company "by mutual agreement", and I wonder, slightly frustrated, whether a slightly less systematic approach would have been enough to produce the same result.
In our "Crime Scene Investigation:Internet" series, experts examine suspicious files using every trick in the book. Watch over their shoulders as they track down malware – because all this really could have happened. All the malware samples shown in CSI:Internet have been used in real attacks and have been analysed using methods including those described. The accompanying narratives are inspired by real incidents, and only the names of those involved have been invented.
Eduard Blenkers, our expert for series two episode two, works as a senior consultant at the Fast Lane Institute of Knowledge Transfer in Düsseldorf, Germany. He is one of the specialists that companies call when they have unwanted visitors in the form of viruses, worms or hackers, or when their data has fallen into the wrong hands.