This chapter is from the book
This chapter is from the book
This chapter is from the book
Incident Verification
Because of the constraints you face when examining the victim infrastructure, you decide to use an interactive connection for the investigation. During a live interactive analysis, volatile and nonvolatile artifacts are identified and collected using minimal assistance from the victim system.
To automate the preservation of key database artifacts for analysis, you use a SQL Server incident response (IR) CD containing trusted tools—namely, your SQL Server IR scripts and the SQL Server extended version of Windows Forensic Toolchest (WFT). Inserting the IR CD into the victim system, you launch a trusted command shell using the full file path in addition to the binary name, thereby ensuring that the binary is loaded from the trusted CD.
On Sunday, August 31, at approximately 8:43 P.M., you execute the SQL Server extended version of WFT version 3.0.03 from the trusted command shell. This application executes predeveloped scripts and gathers SQL Server artifacts from various Distributed Management Views (DMV), and Database Console Commands (DBCC). You save the outputs from the tools run during the investigation to a sanitized USB drive that you've connected to the victim system as drive letter Z.
The WFT results are stored within the Artifacts\WFTSQL folder on the mapped Z drive. Once execution of WFT is complete, you image the default SQL Server error named Errorlog with no extension using dcfldd. This file is available within the Chapter 11\Artifacts folder of this book's companion DVD.
Preliminary Review of the SQL Server Error Log
You manually review the Errorlog file and identify several failed login attempts as seen in the following error log snippet:
2008-08-31 15:28:44.64 Logon Login failed for user 'SA'. [CLIENT: 192.168.1.20] 2008-08-31 15:28:45.17 Logon Error: 18456, Severity: 14, State: 8. 2008-08-31 15:28:45.17 Logon Login failed for user 'SA'. [CLIENT: 192.168.1.20] 2008-08-31 15:28:45.72 Logon Error: 18456, Severity: 14, State: 8. 2008-08-31 15:28:45.72 Logon Login failed for user 'SA'. [CLIENT: 192.168.1.20] 2008-08-31 15:28:58.64 Logon Error: 18456, Severity: 14, State: 5. 2008-08-31 15:28:58.64 Logon Login failed for user 'Administrator'. [CLIENT: 192.168.1.20]
The error log contains several failed login attempts originating from IP address 192.168.1.20. It's clear that a SQL Server client on this host tried to gain access to the PROD-SQL05 server using the SA, Administrator, Admin, DBAdmin, ASPNET, and MSmith login accounts. These unauthorized access attempts appear to have started at 2008-08-31 15:27:09.50. There were 256 failed login attempts using 6 different accounts over 4 minutes and 20 seconds, which indicates the intruder was using some type of automated brute-force attack tool.
Error messages resulting from failed login attempts using the Administrator, Admin, DBAdmin, and ASPNET accounts have a state value of 5, which signifies the logins did not exist on the server. By contrast, error messages for the SA and MSmith logins have a state value of 8, which signifies they were present on the system and at risk of compromise. A little later in the log, you confirm that the MSmith account—one of the targets of the brute-force attack—was used to gain access to the PROD-SQL05 server from IP address 192.168.20, which is the same source of the brute-force attack.
At this point in the investigation, you've confirmed that unauthorized access was gained to the PROD-SQL05 server via a successful brute-force attack on the MSmith login and that unauthorized access was gained by the attacker at 2008-08-31 15:31:35.24. This point will be the beginning of your investigation timeline. You also note that the attacker then used the login to gain access to the SQL Server four more times by using the compromised credentials, as seen within the following error log snippet:
... 2008-08-31 15:31:28.02 Logon Login failed for user 'MSmith'. [CLIENT: 192.168.1.20] 2008-08-31 15:31:28.56 Logon Error: 18456, Severity: 14, State: 8. 2008-08-31 15:31:28.56 Logon Login failed for user 'MSmith'. [CLIENT: 192.168.1.20] 2008-08-31 15:31:29.10 Logon Error: 18456, Severity: 14, State: 8. 2008-08-31 15:31:29.10 Logon Login failed for user 'MSmith'. [CLIENT: 192.168.1.20] 2008-08-31 15:31:29.66 Logon Error: 18456, Severity: 14, State: 8. 2008-08-31 15:31:29.66 Logon Login failed for user 'MSmith'. [CLIENT: 192.168.1.20] 2008-08-31 15:31:35.24 Logon Login succeeded for user 'MSmith'. Connection: non- trusted. [CLIENT: 192.168.1.20] 2008-08-31 15:36:34.42 Logon Login succeeded for user 'MSmith'. Connection: non- trusted. [CLIENT: 192.168.1.20] 2008-08-31 15:38:15.31 Logon Login succeeded for user 'MSmith'. Connection: non- trusted. [CLIENT: 192.168.1.20] 2008-08-31 15:42:33.61 Logon Login succeeded for user 'OSApp'. Connection: non- trusted. [CLIENT: <local machine>] 2008-08-31 15:43:23.74 Logon Login succeeded for user 'MSmith'. Connection: non- trusted. [CLIENT: 192.168.1.20]
The OSApp account, which successfully logged on to the PROD-SQL05 instance at 2008-08-31 15:42:33.61, was used by an interactive user locally logged on to the server as indicated by the CLIENT: <local machine> information within the preceding log snippet. You also note that the OSApp account was not targeted during the brute-force attack, so it was not deemed malicious as part of your initial investigation.
Now that you've confirmed that a successful database intrusion occurred, you are ready to perform a preliminary review of artifacts collected by WFT in an effort to determine the actions the unauthorized user performed within the database server.
Preliminary Review of WFT Execution Results
You complete a preliminary review of the results of the SQL Server incident response scripts executed via WFT. These results are available within the Chapter 11\Artifacts\ WFTSQL folder of the companion DVD. You open the Artifacts\WFTSQL\PROD-SQL05\2008_08_31\15_47_29\index.htm file to open the main page of the WFT interface. From there, you select the DB Objects & Users | Logins link to view a list of SQL Server logins and their associated creation and last update dates. While searching this page for recent activity, you identify that the EASYACCESS account was created at 15:46:03:340 on the day of the incident. In addition, you note that the name of this account is suspect and nonstandard—that is, it does not follow the naming convention in place for the client. Figure 11.1 is a snippet of the details on the EASYACESS account creation.
)
Figure 11.1 A record of the EASYACCESS login creation
You also select the DB Objects & Users | Database Objects link to view a list of database objects, including information on object creation and modification activity within each database on the server. Your search identifies that the IllB3back table was created within the Master database at 15:41:55 on the day of the incident. This activity came after the MSmith account was compromised and used to gain access to the SQL Server; thus it is within the scope of your investigation. You also note that the table was created in close proximity to the EASYACCESS account previously identified. Figure 11.2 shows the record of the IllB3back table created within the Master database on the victim system.
)
Figure 11.2 A record of the IllB3back table creation
You note that #09DE7BCC, a temporary table, was also created within Tempdb at 15:32:41.367. This timing is also within the scope of the investigation and in close proximity to the other detected activity.
To further investigate the creation of the IllB3back table, you select the Recent Activity | MRE Transactions link within WFT and load a snapshot of recent SQL Server transaction activity for all databases within the database instance. Using the Internet Explorer find utility (Control-F), you search for the 'IllB3back' string on the page. The first hit returned is transaction 0000:00002725. The next hit immediately follows the first; this transaction, 0000:00002724, also affected the IllB3back table as seen in Figure 11.3.
)
Figure 11.3 A record of transaction activity affecting the IllB3back table
By checking the transaction begin time field, you discover that both transactions were executed within the same second. You also match the creation date and time of the IllB3back table to the second transaction. The Transaction Sid field shows that both transactions were executed by SID 0x501AEC871FD432488B4A487B06C61505, which was connected to the database server using SPID 55.
You copy the unique SID value 0x501AEC871FD432488B4A487B06C61505 to the clipboard and search for it on the DB Objects & Users | Logins page. You find that this SID leads to the MSmith login—the same login that was compromised during the brute-force attack.
At this point, you document your findings and present them to the client. She immediately authorizes a full investigation to be conducted with the objective of identifying whether sensitive credit card information had been compromised. You then immediately initiate artifact collection on the victim SQL Server instance.