After an incident the access log has everything: what was requested, when, from where, and what the server answered. The problem is never a lack of data, it is a million lines of it. These commands cut it down.

Who is asking the most

sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

What they asked for

sudo grep " 203.0.113.42 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30

A scan is obvious in this list: dozens of paths, each requested once, most of them 404. A human browsing looks nothing like it.

What SUCCEEDED, which is the real question

sudo awk '$9 ~ /^(200|301|302)$/ {print $1, $7}' /var/log/nginx/access.log \
  | grep -E 'wp-login|xmlrpc|/admin|\.php' | sort | uniq -c | sort -rn | head -20
A wall of 404s is noise. A 200 on a path you do not recognise is the line to stop at - especially a POST to a file in an uploads directory.

POSTs only

sudo awk '$6 ~ /POST/ {print $1, $7, $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

When it happened

sudo grep "203.0.113.42" /var/log/nginx/access.log | awk -F'[\\[\\]]' '{print $2}' | cut -d: -f1-2 | uniq -c

And the shape of a successful upload

sudo awk '$7 ~ /uploads/ && $9 == 200 {print}' /var/log/nginx/access.log | grep -i '\.php' | head
Copy the logs somewhere else before you start. Rotation is running, and a busy server can overwrite the evidence within a day - which is usually just before you work out what to look for.