Bug #1275

ET Rule 2003927 not matchin in suricata

Added by Andreas Herz about 5 years ago. Updated 7 days ago.

Target version:
Affected Versions:


I have the following rule (from ET) included in my suricata.yaml:

drop http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN Suspicious User-Agent (HTTPTEST) - Seen used by downloaders"; flow:to_server,established; content:"User-Agent|3a| HTTPTEST"; nocase; http_header; threshold: type limit, count 2, track by_src, seconds 300;reference:url,; classtype:trojan-activity; sid:2003927; rev:9;)

This rule is detected by snort but not by suricata 2.0.3 when i use the following command:
exec 80<>/dev/tcp/ && ( echo -e 'GET / HTTP/1.0\r\nUser-Agent: Autotest httpRequest\r\nUser-Agent: HTTPTEST\r\n\r\n' >&80; while read -t 10 <&80; do echo $REPLY; done; exec 80<&- 80>&- )

It's working as soon as i remove the first User-Agent. But IMHO the rule should even match with the additional User-Agent in front of the HTTPTEST.
Victor said it could be that it's rejected in an earlier stage, but that means such traffic could go through although i wanted to drop it.


log.pcap.1410875272 (1.59 KB) log.pcap.1410875272 Andreas Herz, 09/16/2014 11:10 AM



Updated by Andreas Herz about 5 years ago

The related pcap file:


Updated by Victor Julien about 5 years ago

  • Status changed from New to Feedback

Please add results of http-events.rules against this traffic.


Updated by Andreas Herz about 5 years ago

As requested i testet it against the http-events.rules, but they don't trigger either.


Updated by Victor Julien about 5 years ago

Interestingly, it seems that the 2 user-agent headers are merged:

09/16/2014-15:47:52.901650 <hostname unknown> [**] / [**] Autotest httpRequest, HTTPTEST [**] ->


Updated by Andreas Herz about 5 years ago

So is this intended or something that should be "fixed"?


Updated by Andreas Herz almost 5 years ago

Shall i commit a bug report on github for libhtp or is this already known in upstream libhtp?


Updated by Andreas Herz almost 4 years ago

  • Assignee set to Andreas Herz
  • Target version set to TBD

Updated by Andreas Herz over 3 years ago

Still the same with 3.0 and libhtp 0.5.18 so worth reporting to libhtp upstream?


Updated by Andreas Herz about 1 year ago

  • Assignee changed from Andreas Herz to Anonymous

Updated by Andreas Herz 8 months ago

  • Assignee set to Community Ticket

Updated by Andreas Herz 3 months ago

Still valid issue with 5.0


Updated by Victor Julien 21 days ago

  • Status changed from Feedback to Assigned
  • Assignee changed from Community Ticket to Philippe Antoine

Philippe, could you see what we can do about this?


Updated by Philippe Antoine 19 days ago

Well, I see this as about Suricata rule keywords http_header and http_raw_header definition

The rule triggers when we use http_raw_header instead of http_header

The rule does not trigger with http_header keyword because there is a normalization step first
That normalization includes concatenating together the different values for a single header (This is done by libhtp).

That is transforming
User-Agent: Autotest httpRequest
User-Agent: HTTPTEST

User-Agent: Autotest httpRequest, HTTPTEST

Maybe the best solution would be to have some keywords name and value that we could use with http_header


Updated by Victor Julien 7 days ago

I think the normalization is not working in our advantage. I think we should disable the normalization and instead consider this buffer to have 1-N values, instead of just a single one.

This will be quite involved, as it would first require libhtp changes to store this correctly somehow, then in suri we would need to iterate over the 1-N values in detection and logging. The logging (in eve) means we need to change it from scalar to array probably.

Also available in: Atom PDF