5.6 - Detecting Attacks on Data and Applications
Data Access Detection
Accounting and Activity Monitoring
Accounting means recording and monitoring user activity, tracking exactly who accessed what data and when. A typical log entry captures the username, timestamp, action taken (read, write, modify, delete, copy), the specific resource touched, the source device or IP, and whether it succeeded or failed.
A few patterns are worth watching for. Accessing atypical files, like a marketing intern suddenly opening an executive compensation spreadsheet in HR, is a clear sign someone's outside their normal scope. Unusual access patterns, like an accountant who normally works 9 to 5 from the office suddenly logging in from a Russian IP on a Saturday at 3:47 AM using an Android phone instead of their usual Windows workstation, and accessing over a thousand files in ten minutes instead of their usual handful per day, stacks up multiple red flags pointing to a compromised account. And attempts to delete or copy large volumes of sensitive data, like a contractor trying to copy an entire 15 GB customer database at nearly midnight, well outside their contracted hours, looks like an active exfiltration attempt.
Honeypots (Decoy Files)
A honeypot is a fake file made to look valuable but actually containing fabricated data, existing purely to catch unauthorized access. The logic is simple: there's no legitimate reason for anyone to ever open it, so any access at all is a strong signal of malicious activity. For example, a fake file named something like "CONFIDENTIAL_Credit_Cards.xlsx" sitting in a finance backup folder, filled with fabricated card numbers and configured to trigger an immediate alert on any access, sits untouched for months under normal conditions. If it suddenly gets opened, say by a compromised account, that's an instant, high-confidence signal that something's wrong, often catching an intruder still in the early exploration phase before they ever reach real sensitive data.
Honeypots are appealing because they produce essentially zero false positives (there's no legitimate reason to touch them), they catch attackers early during reconnaissance before real data gets stolen, they're cheap to set up, and they can even reveal what kind of data an attacker's actually hunting for. A reasonable strategy is placing decoys alongside real files with tempting names, like a fake "Credit_Card_Database_BACKUP.xlsx" next to the real budget file in finance, a fake "SSN_Master_List_CONFIDENTIAL.xlsx" next to real HR files, or a fake "Administrator_Passwords.txt" in an IT folder.
Cryptographic Hash Verification
Hashing a file at one point in time and comparing that hash again later is a reliable way to detect whether the file's been altered. If the hashes still match, the file's unchanged; if they differ, something modified it.
This works because cryptographic hash functions are repeatable: the same input always produces the same output (called a digest, or hash) for a given hash function. An unchanged file always hashes to the same digest, so a different digest means the data changed. (Hash functions themselves are covered in Topic 4.2.)
Example: hashing critical system files like a login binary daily and noticing on day three that the hash suddenly changed, with no legitimate update having occurred, is a strong sign of tampering, like an attacker swapping in a backdoored version of that binary. The obvious fix is restoring from a clean backup and investigating how the compromise happened.
The big limitation here is that hashing only catches modification, not viewing or copying. If an attacker just views or photographs a sensitive document without changing it, or copies it elsewhere for exfiltration while leaving the original untouched, the hash stays exactly the same and nothing gets flagged. Hashing protects integrity, not confidentiality.
Choosing Detective Controls
Cost varies a lot depending on the approach. Log analysis is essentially free since systems generate logs automatically, just requiring staff time or a SIEM to actually analyze them. Honeypots cost next to nothing to set up and maintain. Hash verification is also free, using built-in OS tools plus a simple script and a place to store the baseline hashes. On the more expensive end, full Data Loss Prevention (DLP) services run $50 to $150 per user per year but offer real-time monitoring of all data access, content inspection, automated blocking of suspicious transfers, and integration across email, cloud storage, and USB devices, generally justified for large organizations with highly sensitive data or heavy compliance requirements. A small business might get by fine with honeypots and basic log monitoring for a couple thousand dollars a year, while a large enterprise handling regulated data might reasonably spend half a million a year on full DLP given the value of what's being protected and the compliance obligations involved.
Sensitivity and criticality should drive how intensive the monitoring gets. Public data like marketing materials might only need basic access logs reviewed quarterly with no real alerting. Internal data like policies might get monthly review with alerts on mass downloads. Confidential data like customer PII or financials deserves real-time tracking, honeypots, and daily review with alerts on anything unusual or after-hours. Highly confidential data like trade secrets deserves full DLP with content inspection, honeypots, file integrity monitoring, and real-time review with every single action logged and alerted. A critical database holding payment data might justify $50,000 a year in real-time DLP, honeypot tables, query logging, and anomaly detection, while a marketing file share with public brochures might need nothing beyond free basic logging.
Regulatory requirements often mandate specific detection capabilities outright. PII regulations like the Privacy Act, GDPR, and CCPA typically require access logging, audit trails, breach detection, and incident response procedures. HIPAA for PHI requires access controls and logging, audit controls tracking all PHI access, integrity controls to catch unauthorized changes, regular review of those logs, and automatic logoff after inactivity. PCI-DSS for payment card data requires tracking and monitoring all cardholder data access, logging all admin actions, keeping audit trails for at least a year, daily log review, and file integrity monitoring on critical files. Educational records (grades, transcripts, discipline records) are protected by FERPA (the Family Educational Rights and Privacy Act), which requires schools to limit who can see them and to keep a record of each request for, and each disclosure of, a student's records. A healthcare organization facing potential HIPAA penalties of more than $2 million per violation category per year might easily justify a $200,000 a year DLP investment purely to ensure compliance and avoid catastrophic fines.
Evaluating Detection Method Impact
Speed matters enormously. Real-time detection, like honeypots or DLP with live monitoring, can generate an alert within seconds of something happening, letting security respond and contain an incident within minutes, keeping the actual damage minimal. Retrospective detection, like a manual weekly log review, might not catch an attack until days after it happened, by which point the attacker's long gone and whatever damage occurred has already fully happened.
Speed also depends on automation. Log analysis on its own is slow, since no one can read millions of log lines by hand fast enough, so to work at an effective speed it needs some automation, like a SIEM or a script that flags suspicious entries the moment they're written. Honeypots, on the other hand, offer near instantaneous detection. Hash verification is on the slow side: a hash only changes after a file has already been altered, so like retrospective log review, it identifies attacks after they've happened.
Detection can also be thought about by when in the attack it happens. Pre-attack detection, like honeypots catching reconnaissance or behavioral anomalies flagging initial unauthorized access, can prevent data theft before it even starts. During-attack detection, like real-time DLP catching an active bulk download and immediately blocking it, can stop most of an exfiltration attempt in progress, potentially limiting a would-be theft of thousands of records down to just a small fraction actually taken before the block kicks in. Post-attack detection, like a weekly log review, can only identify a breach after the fact, useful for forensics and cleanup, but powerless to have prevented the original damage.
False negatives are worth understanding for each method. Hash verification only catches modification, so an attacker who just views or photographs sensitive files, or copies them without altering the original, sails right past it undetected. Honeypots only catch access to the specific decoy files, so a sophisticated attacker who recognizes honeypot naming conventions and deliberately avoids them, sticking only to real files, won't trigger anything. Log analysis only catches what actually gets logged, so an attacker with admin privileges who simply disables logging before acting leaves nothing behind to review. The fix for all of this is defense in depth, stacking honeypots, DLP, hash verification, and log analysis together, since an attacker would need to successfully evade every single layer at once to stay completely undetected.
A false negative is an attack that really happens but doesn't set off any alert. Here's how the main methods compare:
Method | When it catches an attack | What it can miss | Cost |
Real-time automated log analysis | As it's happening | Anything that isn't logged, or happens after logging is turned off | Low to moderate (setup, or a SIEM) |
Retrospective log review | After it's over | Same as above, and it's too late to stop the damage | Low (staff time) |
Honeypot files | Almost instantly, often early | Adversaries who never touch the decoy | Low |
Hash verification | After a file has been altered | Viewing or copying data without changing it | Low (built-in tools) |
DLP service | As it's happening, and it can block transfers | Data moved through channels it doesn't watch | High (paid service) |
File Integrity Verification with Hashes
Calculating a file's hash is straightforward across platforms: PowerShell uses
Get-FileHash testfile -Algorithm SHA256, Linux BASH uses sha256sum testfile, and macOS zsh uses shasum -a 256 testfile, each producing the same type of fixed-length hash output for comparison.A typical workflow establishes a baseline by hashing a critical file right after setup and storing that hash securely, then periodically re-hashing the same file and comparing against the stored value, flagging a mismatch as a modification. This can easily be automated with a simple script comparing current versus stored hashes and firing off an alert (like an email to security) the moment something doesn't match, commonly run as a scheduled daily job across a list of critical system files.
For example, an admin records a baseline hash of a grade file on Monday:
$ cat grades.csv student,grade jlee,B mpatel,C $ sha256sum grades.csv 9be2c4f63b4e7c350344e62d0fd920cdf97b9ff47f1adaaf1235abe047a8e8a3 grades.csv
On Friday, they hash the same file again:
$ sha256sum grades.csv da96db01cec38a5f1cebc858092b58bd737578feb78dfc26763d66fb70076a9e grades.csv
The two hashes don't match, so
grades.csv was altered sometime between Monday and Friday. Opening it shows jlee's B is now an A. One character changed, and the entire hash changed, not just one character of it. If nobody was supposed to edit the file, that's a sign of malicious activity worth investigating.Detecting Application Attacks in Logs
SQL injection shows up in logs as user input containing telltale characters and patterns: single or double quotes attempting to break out of a query string, boolean tricks like "OR 1=1" designed to always evaluate true and bypass authentication, or SQL keywords like UNION, SELECT, and FROM appearing where they clearly shouldn't in something like a username field. For example, a login attempt where both the username and password fields contain something like
' OR '1'='1 is a textbook SQL injection attempt trying to bypass the login check entirely.Two more SQL injection indicators to check for: a double dash
--, which starts a comment in SQL and is often used to cut off the rest of the real query, and SQL control words written in capital letters, like WHERE, IN, and FROM, showing up in a field that should only hold a name or a search term.XSS shows up as HTML or JavaScript tags embedded in user input, most obviously
<script> tags, but also things like <iframe> pointing to a malicious site, an <img> tag with a broken source triggering an onerror handler, or an <svg> tag with an onload handler, all ways of sneaking executable code into a page through user-submitted content like a comment field.Buffer overflow attempts show up as abnormally long input in places that should normally be short: a URL parameter that's normally a couple dozen characters suddenly stretching to thousands, a cookie that's normally 30 bytes ballooning to 5,000, a query string that should be short running to 10,000 characters, or a total HTTP request that's normally under a kilobyte suddenly running to tens of thousands of bytes. Any of these size anomalies is worth flagging and blocking, since legitimate requests simply don't look like that.
Directory traversal attempts show up as "../" sequences (or their encoded equivalents, like
%2e%2e%2f or double-encoded versions) inside a file parameter, especially when paired with references to sensitive system paths like /etc/ on Linux or /windows/ on Windows. For example, a request for a file parameter that resolves to something like ../../../etc/passwd or ../../../etc/shadow is a clear attempt to escape the intended directory and reach sensitive system files, and detection logic generally just needs to watch for these traversal patterns (in both plain and encoded forms) anywhere in incoming file paths.Practice reading a log: here's part of an application log for an online store. It records each request's time, source IP, the page requested, the total request length in bytes, and the user's input (the log cuts very long inputs short). The entries from 198.51.100.14 show what normal shopping looks like.
Time Source IP Request Bytes Input 10:02:11 198.51.100.14 GET /search 412 q=wireless headphones 10:02:45 198.51.100.14 GET /product 389 id=1042 10:05:09 203.0.113.66 POST /login 455 username=admin' OR 1=1-- 10:05:31 203.0.113.66 GET /search 470 q=' UNION SELECT * FROM users-- 10:07:52 192.0.2.201 POST /reviews 538 comment=Great fit!<script src="http://192.0.2.201/x.js"></script> 10:09:13 192.0.2.40 GET /download 401 file=../../../etc/passwd 10:11:27 198.51.100.90 GET /search 9327 q=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA... 10:12:03 198.51.100.14 GET /cart 395 item=1042
Time | Attack | Indicator in the log |
10:05:09 | SQL injection | A single quote, the Boolean condition OR 1=1, and a double dash -- in a username field |
10:05:31 | SQL injection | A single quote, SQL control words in capitals ( UNION, SELECT, FROM), and -- in a search box |
10:07:52 | XSS (likely stored, since it's a posted review) | A <script>...</script> tag in a comment |
10:09:13 | Directory traversal | A GET request whose file path uses ../ to reach /etc/passwd |
10:11:27 | Buffer overflow attempt | A 9,327-byte request with a huge query string, when every other request here is under 600 bytes |
To report what you found, list each suspicious entry's time, source IP, and input field, name the likely attack and the exact indicator, and recommend a fix: parameterized queries and input sanitization for the SQL injection, output encoding or rejecting HTML tags for the XSS, a length limit for the oversized request, and path validation for the traversal. Point out patterns too, like 203.0.113.66 trying two different SQL injections 22 seconds apart, which looks like one adversary probing the site. The log alone doesn't show whether any attempt worked, so the report should also say what to check next (for example, whether that 10:05:09 login went through).
Summary
Detecting attacks on data and applications relies on a mix of tools: accounting logs to track who accessed what and spot anomalous patterns, honeypots to catch unauthorized access with high confidence and minimal false positives, and hash verification to catch file tampering (though not viewing or copying). Choosing the right combination depends on cost, how sensitive and critical the data actually is, and what regulations require. Detection timing matters a lot too, real-time methods like honeypots and DLP let you catch and contain attacks as they happen, while retrospective methods like periodic log review only reveal what already happened, often too late to prevent the damage. And since every method has blind spots, from hashing missing pure viewing/copying to honeypots missing attackers who avoid them to logging missing anything an attacker manages to disable, the real answer is always defense in depth: layering multiple detection methods together so an attacker has to evade every single one to stay hidden. Recognizing the telltale patterns of SQL injection, XSS, buffer overflow, and directory traversal directly in logs rounds out a solid detection strategy for application-level attacks specifically.