Task #8692
opentracking: detect: DCERPC keywords coverage
Added by Stuart DC 4 months ago. Updated about 21 hours ago.
Description
Adding a few new keywords to simplify the rule detection logic. This should apply to both raw dcerpc (tcp/udp) and smb wrapped dcerpc.
dcerpc.ptype (packet type) - request (0x00), response (0x02), bind (0x0B), and fault (0x03)
Create sticky buffers for flags and header.dcerpc.flags (stick buffer)
- dcerpc.is_fragmented (bool) - standalone keyword indicating fragmentation.
dcerpc.header (stick buffer)
LS Updated by Lukas Sismis 4 months ago Actions #1
- Tracker changed from Feature to Task
- Subject changed from New DCERPC Keywords to tracking: DCERPC keywords coverage
- Status changed from New to Triaged
- Assignee set to OISF Dev
I treat this original ticket as an idea aggregator.
When one starts creating the keywords, please create a ticket per keyword.
LS Updated by Lukas Sismis 4 months ago Actions #2
- Subject changed from tracking: DCERPC keywords coverage to tracking: detect: DCERPC keywords coverage
VJ Updated by Victor Julien 3 months ago Actions #3
- Status changed from Triaged to Assigned
- Assignee changed from OISF Dev to Shivani Bhardwaj
- Target version changed from TBD to 9.0.0-beta1
SB Updated by Shivani Bhardwaj 3 months ago Actions #4
- Subtask #8733 added
SB Updated by Shivani Bhardwaj 3 months ago Actions #5
- Subtask #8734 added
SB Updated by Shivani Bhardwaj 3 months ago Actions #6
- Subtask #8735 added
SB Updated by Shivani Bhardwaj 3 months ago Actions #7
JFYI, DCERPC header is already available through the frame support using the syntax: frame:dcerpc.hdr. I'll also add a regular sticky buffer though. Added a ticket for that. :)
SB Updated by Shivani Bhardwaj 3 months ago Actions #8
- Subtask #8736 added
SB Updated by Shivani Bhardwaj 3 months ago · Edited Actions #9
Hi @stu4rt ! Could you please tell your expectations regarding "dcerpc.flags" being a sticky keyword? I was going to implement it as an integer like "tcp.flags" but checked this description before to get an idea of what's needed. Stringified names for flags can also be made available.
SD Updated by Stuart DC 3 months ago 1Actions #10
Shivani Bhardwaj wrote in #note-9:
Hi @stu4rt ! Could you please tell your expectations regarding "dcerpc.flags" being a sticky keyword? I was going to implement it as an integer like "tcp.flags" but checked this description before to get an idea of what's needed. Stringified names for flags can also be made available.
@Shivani Bhardwaj If dcerpc.flags is implemented similarly as tcp.flags, i think that would be great. it doesn't need to be a sticky buffer for my needs.
SB Updated by Shivani Bhardwaj about 2 months ago Actions #11
Hi @stu4rt !
Apologies for being late. Another question has come up while implementing the support for these keywords. As a rule writer, do you expect say dcerpc.flags to match on a single PDU or say the result of reassembled PDUs in case they were fragmented?
Thanks a lot!
SD Updated by Stuart DC 6 days ago · Edited Actions #12
Hi @Shivani Bhardwaj, i believe dcerpc.flags should operate on reassembled PDUs.
SB Updated by Shivani Bhardwaj about 21 hours ago Actions #13
Stuart DC wrote in #note-12:
Hi @Shivani Bhardwaj, i believe dcerpc.flags should operate on reassembled PDUs.
Hi @stu4rt ! Thanks a lot for confirming. Could you please clarify in such a case when should a match happen?
1. if each of the reassembled PDU's flags match the sig
2. if one of the reassembled PDU's flags match the sig
3. if last of the reassembled PDU's flags match the sig
Please note that each PDU comes with its own header and own set of flags. Here, "PDU" is as per https://pubs.opengroup.org/onlinepubs/9629399/chap12.htm