Database forensics is the process of examining a database's internal evidence to determine whether someone accessed data without permission or changed data they should not have. For the 312-49 exam, understanding how to identify and prove these database intrusions is critical, because most modern data breaches end with stolen or tampered records in a relational database like SQL Server, MySQL, or Oracle.
Jump to a section
A simple way to picture Database Forensics: Investigating Data Breaches
A quiet suburban street, rows of identical-looking houses. A detective arrives because a homeowner reported someone tampered with their locked filing cabinet inside a locked study, inside a locked house, and took nothing obvious but stole a password written on a sticky note, copied some documents, and left things slightly rearranged.
The detective's job is not just to yell 'The door was unlocked!' The detective must examine every single page in every folder, check the filing cabinet's lock for scratch marks (like checking database logs for brute-force attempts), compare the current arrangement of papers against yesterday's photo evidence (like comparing database hashes), and figure out if the burglar came through the front door using a copied key (valid credentials stolen from someone inside the house) or picked the back door lock (an SQL injection vulnerability).
The hardest part is telling the difference between mess left by the homeowner and mess left by the burglar. If the detective finds a coffee cup ring on a document, that could be innocent — but what if the burglar moved that document after spilling coffee? This is exactly the challenge of database forensics: finding the truth in a place full of normal activity, where the criminal is trying to hide inside the noise.
Database forensics is the systematic investigation of a database to uncover unauthorised access, data tampering, or data exfiltration (theft of data). Think of the database as a giant digital filing cabinet with millions of folders. Every time someone opens a drawer, pulls out a folder, reads a page, or scribbles on a page, the database can log that action in a special journal.
The core components you need to understand are:
The database transaction log: This is a highly detailed journal that records every single change made to the database (INSERT, UPDATE, DELETE statements). It exists so the database can recover from a crash, but for a forensic investigator, it is the most valuable source of evidence. It tells you who made a change, what they changed, the old value, the new value, and the exact timestamp.
The database audit log: Unlike the transaction log (which is mostly about data changes), an audit log records who logged in, what queries they ran (SELECT statements too, not just changes), and what permissions they used. Audit logs are optional and must be explicitly enabled by a database administrator.
The data dictionary: This is a set of tables that describe the database structure itself. It contains metadata such as table names, column names, data types, and constraints (rules about what data is allowed). A tampered data dictionary might show that a column suddenly allowed longer text — potentially hiding evidence?
Timestamps and time zones: Every log entry has a timestamp. But databases often store timestamps in UTC (Coordinated Universal Time, like Greenwich Mean Time without the time zone differences). You must convert to local time to match with employee work schedules or security badge access logs.
The database schema: This is the blueprint design of the database. If an attacker added a new table called 'backup_passwords' and then deleted it, the schema history (if recorded) would show the table was created and dropped.
Why does this exist? Before database forensics existed, investigators could only examine network logs or file timestamps on a server. If someone had valid login credentials and made changes through a legitimate application, those logs could be clean. The database transaction log catches the actual keystroke-level data change that an application made, even if the application's own logs were cleared. This replaces the 'trust the application, not the database' approach.
Real example: Imagine an employee with login rights to a human resources database. They use their own credentials to log in through the web application and change their own salary from $50,000 to $80,000. The web application logs only show 'User ID 1234 accessed the salary form'. But the database transaction log shows: 'Old value: 50000, New value: 80000, Change made by SQL query at 2:34 AM local time, using the 'hr_app' login.' That evidence distinguishes an innocent query from a malicious one.
Preserve the Evidence
Take a forensic image of the entire database server's hard drives and the transaction log files. This locks in the current state so no further tampering can affect evidence. You then work exclusively from the copy.
Examine the Transaction Log
Use database-specific tools (e.g., fn_dblog for SQL Server) to read the transaction log for the suspected time window. Look for INSERT, UPDATE, or DELETE statements that seem out of place or involve unusual values.
Analyse the Audit Log
If audit logging was enabled, check which user accounts logged in during the incident period. Cross-reference their IP addresses and access times against known employee schedules or VPN logs.
Check Schema Changes
Run a comparison of the current database schema against a known-good backup to detect any tables, columns, or constraints that were added, dropped, or altered — these could indicate data hiding or tampering structures.
Correlate with Other Log Sources
Match the database log entries with network logs, application logs, and physical access logs (e.g., badge swipes). This helps determine if the database log timestamps align with normal office hours or suspicious off-hours activity.
What does an IT professional actually do with this? Let us say you work as a junior forensic analyst at a financial services firm. On Monday morning, the chief security officer tells you: 'Our accounting database shows a suspicious transfer of $20,000 last Friday night. The application logs say the transaction was processed under the CFO's account, but the CFO was on a flight to London at that exact time.'
Here is the step-by-step real-world process you would follow:
Secure the database server. You would take a forensic image (an exact bit-for-bit copy) of the hard drives, including the database data files (typically .mdf for SQL Server) and transaction log files (.ldf). You never touch the original server once you start the investigation.
Enable database audit if it was not enabled before. This is often too late for the current incident, but you need to ensure no further tampering happens while you investigate.
Examine the transaction log for the specific timeframe around the suspicious transaction. You would use a tool like ApexSQL Log or the built-in fn_dblog function in SQL Server to read the transaction log records. You are looking for the exact SQL statement and the old/new values for that $20,000 transfer.
Cross-reference the transaction log timestamp with the CFO's flight records. If the transaction log shows the change was made at 8:05 PM UTC, and the CFO's flight departed at 7:00 PM UTC and had no internet access, you have a mismatch. That indicates credential theft.
Look at the source IP address. If the database logs show the connection came from an IP address in a different country (or from a VPN the CFO does not use), that strengthens the case.
Check for schema changes. Use a tool like SQL Compare to see if any tables were altered in the previous 72 hours. An attacker might have added a new column to hide stolen data in plain sight (for example, adding a Notes column that actually stores copied credit card numbers).
Finally, you would produce a forensic report that summarises the timeline, the evidence from the transaction logs, the discrepancy with the CFO's alibi, and recommend that the company rotate all database credentials and implement multi-factor authentication (MFA) for database access.
The key tools you could use in this scenario:
SQL Server Management Studio (SSMS) for exploring the database.
fn_dblog or DBCC LOG for reading transaction logs.
ApexSQL Log or Log Explorer for a graphical view of transaction log history.
SQL Server Audit or third-party tools for enabling detailed audit logs.
The 312-49 exam tests database forensics primarily through scenario-based multiple-choice questions. They will present a narrative of a data breach and ask what log or evidence you should examine first, or what a specific log entry means.
Exam traps they love to set:
They will describe a breach where only the application logs were examined and no suspicious activity was found. The correct answer is always 'examine the database transaction log directly'. Because application logs can be altered by the attacker or may not log detailed enough data.
They might ask: 'Which component records the old and new values for every write operation?' The answer is the transaction log (also called redo log or undo log, depending on the database system). Do not confuse this with the audit log, which records who executed the query but often not the before-and-after values.
They love testing the difference between a transaction log and an audit log. A typical question: 'An investigator finds a SQL injection attack that deleted rows from a table. Which log will provide the most precise evidence of the deletion?' Answer: transaction log, because it shows the exact DELETE statement and the deleted rows.
Time zone traps: They will give a timestamp in UTC and ask what local time that corresponds to, or they will show two logs from different systems (database server vs. web server) and you must reconcile them by converting to a common time zone.
They might test the concept of 'database immutability' — some database systems allow transaction logs to be truncated (cleared) by an administrator. The trap is that an attacker who became admin could delete evidence. The correct answer is that you must also rely on backup copies of transaction logs stored elsewhere.
Key concepts to memorise for the exam:
The transaction log is the primary evidence source for data modifications.
Audit logs are secondary and must be enabled ahead of time.
Always document the chain of custody for the forensic image.
Hashing (creating a unique digital fingerprint of a file) is used to verify the integrity of the forensic image.
SQL injection attacks produce entries in the transaction log that show non-typical SQL statements (e.g., many semicolons, UNION statements).
The database transaction log is the single most important source of evidence for unauthorised data changes because it records every before-and-after value.
Audit logs must be enabled in advance and are useless if an attacker has disabled them before the breach.
Timestamps in logs are often in UTC — always verify the time zone before matching them with other evidence.
An SQL injection attack will appear in the transaction log as a non-typical SQL statement with excessive quotation marks or UNION clauses.
Deleted transaction log data can sometimes be recovered from unused hard drive space using forensic tools.
Always create a forensic image (bit-for-bit copy) of the database server before performing any analysis to avoid altering evidence.
These come up on the exam all the time. Here's how to tell them apart.
Transaction Log
Records every data modification for database recovery
Shows old and new values for every INSERT, UPDATE, DELETE
Automatically created by the database system
Audit Log
Records who executed a query and when
Does not show before-and-after data values
Must be manually enabled by an administrator
Live Forensics
Performed on a running database
Captures volatile data like active connections
Higher risk of altering evidence
Static Forensics
Performed on a forensic image of the database
No risk of altering original evidence
Cannot capture volatile data like active connections
Data Exfiltration
Involves copying or exporting data without authorisation
Often leaves evidence in SELECT queries in audit logs
Goal is to steal, not modify
Data Tampering
Involves changing or deleting existing data
Often leaves evidence in transaction logs as old/new values
Goal is to hide evidence or alter records
Mistake
Database transaction logs and audit logs are the same thing.
Correct
Transaction logs record every change for recovery purposes (old/new values), while audit logs record who ran what query and when, but rarely show the actual before-and-after data.
The terms 'log' and 'audit' sound similar, and many beginners assume all database logs contain the same information.
Mistake
If an attacker deletes the transaction log, all evidence is gone forever.
Correct
Deleted transaction log data can often be recovered from unallocated disk space using file carving tools until overwritten, and backups of the log may exist elsewhere.
Movies show deleting a file as permanently destroying it, but in reality, the data remains on the hard drive until overwritten.
Mistake
A database forensic investigation always starts by questioning the database administrator.
Correct
A professional investigator first secures an image of the database and its logs, preserving evidence, before questioning anyone to avoid alerting a potential insider.
People think of detective shows where the first step is interrogation, but in digital forensics, preservation of evidence is the absolute first priority.
Mistake
If someone logs in with valid credentials, any changes they make cannot be a crime.
Correct
Valid credentials do not imply authorisation. The transaction log can prove the exact change was made outside of the normal application interface, indicating malicious intent.
People assume logging in equals permission, but database forensics distinguishes between 'access' and 'authorised access'.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A transaction log records every data modification for recovery purposes and shows old and new values. An audit log records who ran which query and when, but not necessarily the before-and-after data.
Yes, partially. Deleted transaction log files remain on disk until overwritten. Forensic file carving tools can recover them from unallocated space, though some data loss is possible.
Live forensics means analysing the database while it is still running, to capture volatile data like active connections and temporary tables. This is riskier because the investigator might accidentally alter evidence.
In a corporate investigation, internal policies usually permit database examination for security incidents. For criminal cases, a court order or warrant is typically required, especially if the database contains user data.
Check the application login user versus the database user used for the change. Authorised applications use a service account. An attacker might use a different login or inject SQL through a web form.
Assuming the transaction log is too complex to read and skipping it, then relying only on application logs. The transaction log is the most trustworthy evidence because it is harder for an attacker to alter.
You've finished Database Forensics: Investigating Data Breaches. Continue through the 312-49 study guide to build a complete picture of the exam.
Done with this chapter?