I've been working for a few years in offensive security, mostly pentesting. Pentesting is basically web-focused attacks, you can learn about it in OWASP, for example. I'm a pentesting teacher myself, and pretty much got used to it, so I developed a good instinct to look for vulnerabilities in web-based environments such as websites or servers. Some months ago I drastically switched my career into blue team related tasks (threat hunting) and I had to change my mindset into protecting rather than attacking. Even if I tried to use my previous knowledge for tipping my new team into catching attacks, I kind of stored the offensive expertise in a different "box" inside my mind, so I didn't care about actually thinking about pentesting and detection in the same line.

I recently was encouraged into thinking in a way of detecting web related attacks. Each EDR (End and Detection Response, a blue team tool for monitoring, detecting and working with irregular or suspicious stuff) has a different hunting-queries language and logic, but I guessed I could share some tips in order to write queries on your preferred way:

• Detecting downloads or execution of some of the most common pentesting tools-pack. Knowing about the most common tools depends on how familiar you are with pentesting, but here you go a github awesome list on some of them. You can download, execute them and getting the hash to learn about them. Mind the operating system in your monitored devices when looking for the tools.

• Detecting enumeration tools or processing. A huge amount of pentesting campaigns time is focused on enumerating and tagging the victim's webservices. If you are monitoring servers, look for unfamiliar enumerating processes. Some of the tools mentioned in the tip above are actually enumerating-focused.

• Detecting weird SQL commands. A considerable amount of attacks are SQLI (SQL injection) focused, as this would lead into remote code execution from a remote server in severe cases. Therefore, try to list all the regular SQL commands and look for he ones that doesn't match on the list.

• Detecting brute force from accounts or input forms in the servers. Some of the most commonly automated attacks are brute forced-related using "common passwords" lists and other tools. Also, there are leaks almost every month (you can check for leaked mails in here), so it's a good idea to use that or similar tools to see if any email from the organization is leaked, and then check for brute force using that account, or simply looking for brute force. Looking for botnet related things is smart as well. For checking if a device is being used as a part of a botnet you can check on new, active botnet frameworks.

This is pretty much a nice list, they way of making it perfect depends on each case: the context, the amount of devices, the amount of accounts...

But this should be enough for guiding a nice investigation.

Have fun!