CHAPTER 12
Administrator Abuse
We’ll Cover
 
image   Dealing with challenges in administrator abuse cases
image   Investigating an administrator running his own business out of his employer’s network
image   Investigating an ex-administrator spying on his prior employer
 
Chapter 11 covered how to work human resources cases. This chapter covers the challenges in administrator abuse cases, as well as how to investigate theft and espionage. In my experience, cases involving administrator abuse are as bad as it gets, especially in terms of challenges presented from an analytical perspective and damage that can be inflicted upon an organization. Make sure to go to www.learndfir.com to watch videos on working the cases in this chapter and download images to work on your own.
An administrator as a suspect presents a challenge unlike others, because an administrator has the access and the technical ability to wipe out the forensic evidence you rely on. If this person is cautious, they will also be watching the e-mail accounts of those who could investigate them to get advance notice to wipe the evidence. When an administrator is your suspect, make sure you advise those you are working with not to use corporate-owned or controlled systems to communicate about the investigation. Examples of internal systems to avoid include Voice over IP (VoIP) phones, e-mail, corporate instant messaging, and anything else your rogue administrator can monitor.
The Abuse of Omniscience
Administrator abuse is the abuse of omniscience. Why? Because administrators know everything: they are paid to know everything. They know how everything is configured—remember the IT director from Chapter 11 who created the rule on the content filter that allowed only his IP address to access pornographic web sites? Beyond allowing themselves access to restricted web sites by exempting themselves in the systems meant to restrict them, administrators also have the network credentials that will grant them access to whatever information they desire on the network. As we’ll see later on in this chapter, admins can also use those privileges to change evidence and hide their tracks.
Knowing how everything is configured and having unlimited access results in a one-two punch that most often means the forensic analyst must fully understand how the interconnected networks operate in order to find the evidence.
LINGO
Network credentials refers to such things as the username and password required to log into a company computer as the administrator, or the password to network routers and security appliances, for example.
LINGO
Security appliances can be firewalls, content filters, data leakage prevention systems, and so on. Any type of dedicated system that is made to secure the company’s network applies here.
While participating in an expert panel, I was asked, “What makes a good forensic investigator?” My answer was, “Someone who not only understands how to reverse a user’s actions while thinking as an investigator, but who also understands how a network operates.” Computer forensic examinations of a single system are essentially straightforward, because all the data you need to review is contained in a single place: the hard drive of the system(s) you’re working on. Yes, finding evidence of pornography, chat sessions, and e-mails is important, but when compared to the investigation of a network and the activities that span it, these types of cases are simple.
If you want to step up your game in terms of a challenge, performing a forensic investigation across a corporate network is the place to do it, and networks are the world of the administrator. In most of your investigations, you will be reviewing the activities of a user who may or may not have technical knowledge. An administrator suspect will have gained a large amount of technical skills and configured the systems you will be investigating, which means they will know the systems far better than you do. Your advantage will be in your specific knowledge of computer forensics and forensic artifacts—knowledge that, hopefully, the suspect will be lacking. This knowledge and the element of surprise are what you will have to even the playing field.
IMHO
In my dealings with administrator suspects, I’ve found that their greatest weakness is usually their confidence in their abilities. One ex-administrator who was assisting another in spying on his former company never thought of deleting the logs he left behind, because no one, in his opinion, was smart enough to find them. Other administrators assumed they knew how to hide or delete data but then failed to wipe it, making it easy for simple recovery. The worst thing that can happen is if the administrator becomes aware of your investigation, because they will focus their efforts on hiding the evidence. Most administrators leave the evidence of their actions in place because they think it’s “their systems” and no one else will look at them, or know how to.
The world of the administrator is much broader than a group of machines you might have to image as part of your normal investigation. The admin’s world is about routers, firewalls, databases, e-mail servers, authentication mechanisms, physical and virtual machines, and the list goes on. And you have to know how it all works together.
In Actual Practice
It’s important that you find out what other potential sources of evidence exist on the network. Although you may start your review with the current network infrastructure, it’s important that you determine what kind of network logging and correlation systems are in place already. Security Information and Event Manager (SIEM) is one such system that maintains all of the events and logs generated from systems across the network, and they are a goldmine of evidence when you’re looking to determine the actions of a network user. Recorded historical log information can be overwritten quickly if it is stored within a network appliance, especially firewalls, so examining where a suspect might be sending those logs can help you tremendously. Just make sure that you don’t tip off your suspect to your investigation when you inquire about such information.
Suppose you know how to find evidence of pornography, chat sessions, and e-mails; how would you even begin to work a case in which an unauthorized person is reading the e-mails of the top executives in your company? In such cases, the suspect may reveal himself, because top executives get suspicious when the only place a specific piece of information that was leaked to your competitor exists is in a single confidential e-mail sent by the CEO to the CFO just the day prior. With the mandate of identifying where the leak came from, can you discern whether spyware has been installed on potentially every computer in the organization, or whether an insider working against the company?
For a larger list of the kinds of administrator abuses we’ve come across, look back at Chapter 10.
Scenario 1: Administrator Runs a Pornographic Site Using Company Resources
This real-life scenario begins with, of all things, spam. A woman received spam via e-mail at home on her personal computer. She clicked on the link included in the e-mail and was immediately redirected to a pornographic web site. She was paranoid about reporting spam and knew how to track down domains via the IP in the message header. After she identified the domain, she discovered that the IP was assigned to a management company. She called the company, and she talked directly to the company owner. She explained to him how the originating IP address came from his company’s domain. The company owner requested that the woman forward him a copy of the e-mail and explain to him how she obtained their IP address.
The woman later sent the requested information, and when the company owner clicked the links, he saw that they did indeed redirect him to a pornographic web site located on his company’s network.
The company owner then assigned the task of investigating the matter to the company IT director. A few days later, the IT department reported that they could not find any evidence that their servers had been compromised, and they also reported finding no unusual content on any of the web servers.
After the meeting with the IT director, the company owner decided to take the IT department’s report at face value; he determined that no further action was required. Several days later, the company owner was watching a news report about network hacking and how tracks are typically hidden; he decided to have a thorough threat assessment made of his company’s network, so he contacted a private investigator. At that point, the PI contacted me to consult on the investigation.
IMHO
It’s a “special” type of suspect who thinks he or she can get away with something as brazen as running a business out of his employer’s systems. Although these cases are not common, when they do occur, it’s almost always the case that someone at an executive level is involved to ensure that your overall investigation activities and resource usage can be hidden from others. Keep this in mind as you talk to your contact person; they need to be aware that they must not communicate to anyone involved with the systems—executive or otherwise—of your presence, or else the suspect(s) may get tipped off and destroy the evidence before you have a chance to preserve it.
Beginning an Investigation
As you begin an investigation that may span an entire corporate network, you need to know that, ultimately, you’ll be dealing with many different pieces of equipment. You should understand that you are responsible for putting all those pieces together to access all the evidence you are looking for. If you don’t feel up to the task, ask for help early on.
You might assume that the first place to start, when dealing with a rogue web site, is the web server. However, it’s very important to keep one thing in mind as you work with one of these systems: Any web server, regardless of the host operating system, needs to be considered for what it is primarily designed to be—an interface to other systems and services.
In Actual Practice
As you begin your work on a complex case, you can create a list of all of the possible evidence you may want to review and the artifacts you know should exist. As you work through the case, keeping this list and updating it ensures that you don’t miss anything and helps you keep your eye on the big picture.
The Web Server’s Role in the Network
A web server is usually considered a static system that provides pages after a browser requests them. However, a web server can also be an interface to other systems and services, connecting to databases and business applications that feed it data to display on those pages. In this case, the web server is not the only piece of forensic evidence you must preserve, but it’s your starting point in determining what other systems are involved. But first, you have to find the web server.
LINGO
A web server provides web pages to web clients. The amount of systems and processing involved in generating a web page depends on the developers and the underlying code that exists in the page.
A web server can be designed as a doorway, or an interface, to the world, exposing data stored on other systems in the network. In that capacity, more so than with other kinds of servers, web servers present unique challenges both to administrators who must secure them and to investigators who must put the pieces together to solve a case. If you look at the statistical measures for network breaches or exploitation of other system or service vulnerabilities, the web server is often used as the point of entry, or system penetration vector.
Accessing Other Systems
In our pornography scenario, the suspect web server was a Microsoft Internet Information Services (IIS) server. As an interface to other systems and services, IIS provides a functional set of methods for accessing system resources, such as the file system. This can be accomplished by using HTTP GET and PUT commands, directory browsing with WebDAV, and so on. Web servers do not necessarily store the content they access on the local system. They can rely on something as simple as a network drive or as complicated as a Distributed File System (DFS) for that. So, for example, even though the physical web server may be in Miami, the actual web content (that is, pages, images, and so on) can be in Los Angeles, or overseas, or anywhere within the corporate network.
LINGO
Any network of servers in which shared data is replicated and stored can be considered a Distributed File System (DFS). Microsoft uses the term to describe its implementation of this technology within Windows Servers. Multiple systems appear to have local storage, which is actually mapped across multiple systems across the network. To recover any deleted data or create a forensic image of the physical disks that make it up, you must track down those servers.
From a computer forensics perspective, instead of imaging just one system, you may need to image multiple systems in diverse locations (and with differing laws in other countries) to perform the analysis of a single web server if you’re looking for deleted files and other artifacts. That’s much different from standalone PC forensics, in which each system is its own island; even if that system has a RAID attached, it’s still a limited set of drives that contain the evidence you need to preserve and analyze. In contrast, with a DFS, you may have to forensically image multiple systems and then re-create the network back in your lab to examine how it functioned. Add in the complexities of virtual machines, and you realize you’ll need to make sure you understand the environment you are examining before you decide what to preserve and what not to.
Accessing Other Services
Certainly, web servers can interface with relational databases such as Microsoft SQL and e-mail servers such as Microsoft Exchange. In both cases, “other services” are being accessed, and the web server is acting as the interface to those back-end services. This means the evidence you need to preserve isn’t limited to the servers where data is physically stored, per se, but it also includes the underlying data contained in the services to which the data is connected.
Web pages can be coded to interact and access databases in myriad ways (such as server pages, ASP.NET, Java, PHP, and so on), but the framework is always essentially the same. This is important to keep in mind when you’re trying to understand the source of the data being presented in your examination. Consider the following:
 
1.  A user connects to a web server via her browser, the web client.
2.  The web server takes the request and executes the code in the web page to query the back-end database server.
3.  The database server runs a query with the provided information and returns the results to the web server.
4.  The web server builds a new web page on the spot and inserts the query results on the page, and then sends the page back to the web browser, where it is presented to the user.
 
In Actual Practice
I am discussing an example of a web site whose pages are being created from the database dynamically for every access. Common web platforms, known as content management systems, such as WordPress, ConcretePlatform, Joomla!, and others work in similar fashion. That does not mean that a web platform is the only way that a web server can interact with a database—that depends on what the code in the web page is written to do.
Investigating the Web Server
A database server itself may not store its database on a local disk. Instead, the database may be located on a DFS drive or a SAN drive. Remember that assessing the configuration of the service is not limited to any one service, such as the web server, to determine where the underlying data is stored. You don’t want to make an assumption about where data is stored only to begin your analysis and then realize that you are missing data and have to redo your work.
As we began our investigation into the rogue pornography web site, my team was able to establish that, indeed, the company web server did not contain any of the pornographic material described. However, during our network analysis and documentation, we discovered that all five of the servers on the network were default installations of Windows 2000. Each of these servers came with Microsoft IIS version 5 running by default; therefore, there wasn’t just one web server on the network, as you would infer from the stated purpose of the systems; there were five.
After imaging all the servers, we found that the pornographic site was actually being run on the company’s file server, where no one was looking for it. All of the pornographic site content (graphics, HTML, and ASP) were found in an obscure folder inside the Program Files folder of the machine being used as the file server.
In Actual Practice
I wish I could report that we made the discovery by examination of some grand technically challenging search scheme to trace network traffic in real time, but in fact we just mounted the images into our forensic tool and went over to the graphics tab and scrolled through looking for dirty pictures until we found them. That’s why the existence of porn is so easy to investigate. Remember, however, that in your investigations, you may be limited regarding what you are being asked to review. If there are privacy concerns in your investigation, you may not be allowed to review any pictures stored on the system.
Directories
Web servers use directories to restrict what data a remote user can request to files and folders beneath its web root. In most cases, those files are HTML documents; however, web servers can provide access to any type of data that it’s configured to allow. In addition, in modern web servers, what often appears to be a page is actually a program executing on the web server and returning content instead of just the content of a file in the directory.
LINGO
The web root is the first folder in the hierarchy from which the web server will return data. For instance, if you configured your web root as C:web, then the web server would not serve up any information from the C: directory, because it is outside of the C:web path.
In this case, we were dealing with IIS, so I’ll discuss some of the directory issues with IIS. IIS sets up two directories when it is installed: One is in the %systemroot% System32 directory called Inetsrv, which contains configuration files related to running and administering the IIS server. The other is the web root, in the %systemdrive%Inetpub directory by default, but administrators have the option of changing the web root location during installation. It has several directories that may contain some sample HTML files and includes the default web root directory named wwwroot.
When users connect to the web server without any specific request for a page, such as a request to www.google.com, the web server follows its configuration to load the default page. In the case of IIS, the default page would be located in the wwwroot directory. The web server then returns the default page for that directory (that is, the home page).
In Actual Practice
Because IIS can host virtual servers and virtual directories, these web root locations can be modified. (Surely you didn’t think it would be that easy after getting to this point!) A web server can be configured to host multiple web sites with different web roots and different default pages all from one IP address; each of these web sites would be hosted in what’s known as a “virtual server.” To determine what page to display, the web server looks at what web site has been requested. To determine whether virtual servers exist, you must examine the configuration of the web server.
Virtual Servers
Like most web servers, IIS can be configured to host multiple domain names on the same computer—such as sales.mydomain.com, marketing.mydomain.com, mydomain.com, yourdomain.com, and so on. This can be accomplished by assigning a separate IP address to each site and having the web server configured to respond to each IP address differently—or, more commonly, the web server can take the domain that the web client has requested and determine which virtual site should be accessed. This can make analysis confusing when you are trying to locate a particular virtual server and you don’t know the hostname, so, again, you’ll need to go back to the configuration to determine what exists.
Virtual Directories
IIS allows the files used by web sites to reside either on the local computer hosting the web site or on shares located on other systems, as shown in Figure 12-1.
image
Figure 12-1   Viewing the true location of virtual directories
In the IIS Manager interface (Figure 12-1), you can see that several web sites are being run on this single physical server. Some of the content is local, but the ProFolders, Exchange, and Exadmin folders are not.
During my team’s analysis of the source code for the pornography site, we discovered a database call to a sample database on the company SQL database server. The call was to the Northwind Traders sample database that is installed with Microsoft SQL Server 2000. The next logical step in the investigation was to determine what part the database server played in this matter. Examination of an SQL server is fairly straightforward if you are interested in the actual raw data contained in the databases. Because forensic tools do not mount relational databases or allow you to search them efficiently, the easiest way to examine the server, in the case of a SQL server, is to export the pertinent data file (.mdf) and the related log data file (.ldf) from the forensic image.
After extracting the data and log files from the SQL Server forensic image, my team mounted the database on a separate SQL server and found that the pornographic web site user and credit card information was being maintained in the Northwind database. So all the client data for the porn site was intermixed with all the sample data that ships with the Northwind database from Microsoft, and it looked as though it was sample data, too. This was a very clever way of hiding data in plain sight.
The next step in the investigation was to follow the data packets, which meant we needed to backtrack the route a packet would travel. This led us to the firewall.
Examination of the firewall revealed that the company had four external IP addresses, as provided by their ISP. One of them was assigned to the porn site, according to the DNS record, and the mail server was on a completely different IP range at a commercial hosting company. The firewall had a rule configured that forwarded all traffic associated with the external IP of the porn site to the internal IP of the file server, and when the request was received by the web server, it served up the site.
Obviously, when you discover a firewall configuration like this, it points toward internal IT resources being complicit with the web site’s operation. Our examination of the firewall rule didn’t reveal any further relevant information or configuration anomalies.
image Note
In this case, the firewall didn’t have good logging enabled to capture what changes were being made by which user, and it was not configured to send its logs to another system for long-term storage. If we had this information, we could have determined which internal resources were allowing the traffic to be routed to the file server and capture those systems.
 
After we found the pornographic web site on the file server, the customer and payment records on the SQL server, and modifications to the corporate firewall, we were granted permission to image all of the company computers for analysis to find out who internally was involved. During our review of the network administrator’s computer, we found several hits to the offending pornographic web site’s domain. The first hits were not out of the norm, since he had been tasked with finding out whether a breach had indeed occurred. Later keyword hits came back to the webmail interface for the porn site, located at an external web hosting company, which only someone who was operating the site would know to access. As a result, we were able to recover remnant copies of the porn site’s inbox, including e-mails generated by the online payment system and those from customers.
After exporting the files, the network administrator was interviewed by human resources, and he admitted he owned the site.
Scenario 2: Exploiting Insider Knowledge Against an Ex-employer
Of all the cases I’ve been involved with since I first got into this type of work in 1999, what follows is by far the worst and most damaging in terms of scope. It would not have been possible without the key knowledge of several former network administrators, who used their in-depth knowledge of systems they themselves installed to plan and execute a relentless series of spy and sabotage attacks against their former employer. In the end, tens of millions of dollars were made and lost. This case took more than a year to investigate and then settle in civil court; as of this writing, the suspects are facing criminal charges.
A Private Investigator Calls…
This case began when my team was called by a private investigator, who had been contacted by a local company to check for listening devices in their offices. The company was suspicious that one of their competitors had been listening to their conversations. Why? Because a large portion of their customers had been lost to a brand-new company in their service space. After the private investigator had not been able to locate any listening devices, he suggested they have their computers scanned to determine whether they had been compromised in some manner and gave them our contact information.
As if They’re Reading Our Minds…
My team initially received a small group of computers for imaging and analysis. Some of these computers belonged to five former long-term employees who had very recently resigned—and had gone to work for a new competitor. It turned out that the new company had been started by one of the former employees less than a year earlier. In that short amount of time, the new company managed to take several of our client’s longest standing and most profitable customers.
In Actual Practice
At the beginning of any case, you may find it easy to be led toward a conclusion by the person who brought you in. It’s important that you keep perspective and always let the evidence be your guide when you’re making conclusions. Sometimes, you’ll find that what started off as one type of case turns into something else completely before you are finished!
For some reason, the new company always seemed to be one step ahead of our client and somehow had knowledge of highly confidential information relating to business dealings. Things just didn’t add up (not ethically, at least). During my initial meeting on site, the in-house legal counsel said it was as though the competitors were reading their minds. Now, with no listening devices found anywhere in the office building, they wanted to make sure their network had not been compromised.
We were given several computers for imaging; these belonged to several high-ranking former employees encompassing sales, management, logistics, and network administration. The initial scope was to determine whether the systems contained data indicating that these former employees had accessed critical client information to take with them to the competitor, as well as any communication with the new company while they were still employed.
LINGO
The scope of your investigation is always determined by the person requesting it. I’ve talked about this in previous chapters in the book, but you are rarely given free rein to review a system for what you believe is pertinent. Instead whoever asked you to perform your investigation will explain what they are looking for and what they are asking you to determine.
In addition, we received computers from the highest ranking current staff to determine whether they contained data that would indicate they had been compromised in some fashion, via keystroke loggers or other malware. After imaging and analysis, we found no evidence of system compromise on the current employees’ computers. We then recommended a network vulnerability assessment, which was approved.
In Actual Practice
This case began as a civil investigation, but at the end of the civil case, a criminal investigation was commenced by the FBI. It’s important to remember that your case can also turn criminal, so always make sure that you keep good case records and chain-of-custody records to assist law enforcement in their use of your forensic images.
What a Network Vulnerability Assessment Can Reveal
It was at this stage, during analysis of the Microsoft IIS system that hosted the corporate webmail, where we found the first indications of a compromise.
During the analysis of the web server Outlook Web Access (OWA) logs, we found various instances of a defined group of network service accounts, including the corporate voicemail server account, Blackberry Exchange Server account, and database server account, had been accessing and reading the e-mails of the company president, CFO, legal counsel, marketing director, and more. We found that more than 50 high-ranking staff members’ e-mails had been read.
image Tip
I remember explaining to the company executives and attorneys that it’s not normal for voicemail servers to log into webmail sites. You should not assume that whoever is requesting your work is technical enough to understand why that’s funny. Take the time to explain not only what you found, but what it means and why it’s important.
 
Further review of the Active Directory records revealed that all of the service accounts that had been used to read the mailboxes had network administration rights and were given administrative rights to the mail server, so they could read any user’s mail. Thus, whoever was using these service accounts was logging onto the domain with full network administrative privileges.
After exporting all the web server logs from this forensic image, we imported them into a relational database for further analysis. This revealed that someone had been using these service accounts to access the e-mails of company executives approximately nine months earlier.
Additionally, the source IP addresses were both external and internal. This meant that in some of the sessions where e-mail was read, the web browser that did the reading was assigned an internal IP address. The logical conclusions at that point were that insiders were involved, or a VPN or other remote access was used.
We then captured a forensic image of the VPN server and analyzed the logs, which indicated that the external IP addresses that were documented in the webmail server logs had also connected to the VPN server. The VPN session logs revealed that the assigned internal IP addresses correlated to the IP addresses found on the webmail server logs. We were then able to re-create the complete series of events, from the external client logging onto the VPN server, being assigned an internal IP address, and then starting a webmail session to read the executives’ e-mails. In other cases, the intruders simply went to the webmail server’s external interface and logged on. The logs also indicated that after the messages were read, they were then remarked as unread.
After we documented all of the relevant external IP addresses from the logs, our next step was to determine their origin. In some cases, the IP addresses were tracked to the new company—where the former employees now worked. In other cases, the ISP data indicated that the users accessed the webmail via their home accounts.
The next phase of this investigation was to determine the scope of damage by documenting which e-mails had been accessed and what sensitive company data had been compromised. When dealing with Outlook Web Access data, as we did in this case, the best place to get that kind of information is in the web server logs. That’s because OWA logs are configured to record the title of each e-mail that’s accessed and every attachment that is opened. The attachments are stored as objects in the Exchange Server database (EDB), and they are documented in the URL column of the OWA server logs. So if you simply copy and paste the URL into a web browser that is currently running an OWA session, you can access the e-mail and attachments exactly as they were read by the user.
Figure 12-2 shows the formatting of the OWA log file and the order in which viewing occurred. In the cs-uri-query column (at right) of the database containing the imported OWA logs, the commands shown were preview, open, and so on, when the message was being previewed, opened, and so on. In the cs-uri-stem column, notice the objects that were accessed, as shown in the figure.
image
Figure 12-2   Reviewing a OWA log in MS Access
In the log, we focused on e-mails titled SuperXXXX Info.eml, or FW: Layne XXXX .eml. We also found that an MS Word attachment, Dance Flyer.doc, had been accessed. Immediately after the filename of the Word document is the object reference in the Exchange database, which must be passed to the server.
We didn’t enter this investigation with an awareness that the OWA logs could be analyzed to determine what e-mails were being accessed. Instead, we found the evidence of the accesses and then began testing ways to determine how to re-create what was being viewed at the time.
E-mail Data Review and Server Restoration
We found thousands of e-mails to review. Over the span of several months, we restored incremental backups of the Exchange Server to our re-created working environment and passed the e-mail and attachment URLs through an automated process to a web browser. This allowed us to provide the client with copies of every e-mail and attachment that had been read, for which the data still existed on the backup tapes.
The former employees took client lists, read highly sensitive marketing and strategic partnership agreements, as well as closely guarded deal information, and used that information to take customers away from our client’s company. All of this would not have been possible if the former IT managers, who now worked for the new competitor, had not exploited their in-depth knowledge of their former network:
 
image   They used their personal knowledge that those obscure service accounts all had domain administrative privileges.
image   They knew how to log onto the VPN, and once inside they used the pcAnywhere tool to take over client systems to access subsystems and try to cover their tracks.
image   They knew where the front door was, and, more importantly, where the backdoor was.
We learned that the ex-network administrator set up all of the administrative permissions to the network and e-mail systems on these service accounts before he left the company. When training his replacement, he agreed to be recorded via audio tape as a means to keep better notes that would help in the transition. In that audio recording, he informs his replacement that he should never change the passwords on those service accounts “because no one knows what it would break,” although the truth was that changing the passwords would have closed the backdoors he had opened to the network.
Stepping Up Your Game: Knowledge Meets Creativity
Earlier, I said that a case that involves administrator abuse across networked systems is where you really step up your game, because it will pit your personal skills against those of someone who has a greater technical knowledge of the network you are trying to analyze. That is true; however, both of these cases illustrate an essential point: When dealing with administrator abuse, you must exercise patience and approach the investigation in a methodical and logical manner. Just because they know more about their network doesn’t mean they can’t make a mistake or become complacent with their own systems. The administrator who took the time to think of a creative way to hide his porn site by putting it on a back-end server and storing his client transaction records in a sample database didn’t bother to clean his own computer, and he left behind all the Internet history files.
The administrators who took the time to think of using service accounts to read e-mails, and hid their tracks by using the VPN and pcAnywhere, overlooked deleting the simple IIS log of the very service they were exploiting.
In Actual Practice
There is no such thing as a court approved tool, as mentioned in previous chapters in this book. What matters is that you created sound forensic images of the evidence you are preserving and can replicate the evidence you’ve found to another examiner who can reach the same conclusion as you.
In both cases, forensic tools and methodologies were used to obtain and preserve legally defensible data. However, most of the real work was done outside of a forensic tool. Don’t limit yourself to the closest and/or most convenient forensic tool. Nothing says you are a better forensics investigator if you spend days reviewing log files with a forensic tool, painstakingly, one line at a time, versus dumping all the service logs into a database so you can query it in two minutes. There is nothing that says your case will stand up better if you spend days going through IIS configuration files trying to decipher the Inetsrv data using a forensic tool instead of just going to the web server, opening up the administrative interface, and documenting where the web site is storing its data.
We’ve Covered
In this chapter, you got to see how to approach two scenarios involving rogue administrators. We focused mainly on procedures and techniques and not as much on artifacts, as in network investigations the logs usually become the centerpiece of the investigation. Log analysis is a big part of large forensic investigations, especially because you often do not have access to examine the offending system or the administrator wiped the evidence.
Dealing with challenges in administrator abuse cases
 
image   Deal with the unique challenges of investigating those people with access to do what they choose presents the investigator with unique challenges.
image   Work outside the view of the rogue administrator who may be watching.
Investigating an administrator running his own business out of his employer’s network
 
image   Detect and track down network abnormalities.
image   Track down the true location of your evidence.
Investigating an ex-administrator spying on his prior employer
 
image   Detect espionage and find the source of the leak.
image   Determine who is involved and find previously unknown evidence sources to prove your case.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.135.190.182