I’m currently struggling alot with what should be a actually quite simple.
We’re trying to add a rule that can detect requests for uploading files with WeTransfer to our suricata ruleset.
Firstly I’ve used wireshark to view what requests are happening in the background. I came across this post request:
I’ve tried quite some variants to be able to fire off an alert for this specific requests but none were a succes:
alert tcp any any → any any (msg:“fileupload via WeTransfer website”; http.method; content:“POST”; http.host; content:“wetransfer.com”; http.uri; content: “/api/v4/tranfers”; sid:10001140;)
alert tcp any any → any any (msg:“fileupload via WeTransfer website”; http.method; content:“POST”; content:“wetransfer”; nocase; sid:10001140;)
alert tcp any any → any any (msg:“fileupload via WeTransfer website”; http.uri; content: “/api/v4/tranfers”; sid:10001140;)
alert tcp any any → any any (msg:“fileupload via WeTransfer website”; content: “wetransfer”; pcre:"//api/v[0-9]/transfers/.+/files/i"; sid:10001140;)
I would like to know very much what exactly I’m missing here. Thank you!
Hi!
I’m not sure if there are other things to be fixed as well but I’m looking at the first two rules and I see that you use http.method which is a content modifier and not a sticky buffer. So, you should probably put it after the content. https://suricata.readthedocs.io/en/latest/rules/http-keywords.html#http-method
Will be happy to try it out if you can provide the pcap.
Thank you for the quick response. I’ve tried putting the http.method after content and again I’ve received no error. Nevertheless the alert did not fire off with this fix.
I’m sorry but I cannot share a pcap with you at the moment. But for my test case I simply go to wetransfer.com, upload a dummy file and click on “Get a link”.
It looks like you’re trying to alert on content within a HTTPS request (https://wetransfer.com/...) so without taking extra steps (i.e. decrypting the traffic) I wouldn’t expect to be able to access HTTP specific buffers as I would in a cleartext HTTP request.
You could start by matching against wetransfer.com as the TLS SNI via the tls.sni sticky buffer, if it’s not too unspecific.
I wrote a different rule using tls.sni for download.wetransfer.com and it fired off! But to actually match on the full uri, specificly /api/v4/transfers is probably not possible using the tls protocol is it?
Some extra context, the tests I’m running uses a basic span port, suricata setup.
Nope, the request path is already encrypted, so you will only be able to match on the hostname via SNI. TLS 1.3 also supports encrypted SNI so even that might not always be there.
