SIG: BPFDoor icmpShell ICMP artifacts from Rapid7 whitepaper

Pb-22 · April 23, 2026, 11:44pm

@bingohotdog I put together a small BPFDoor ICMP lab and wanted to share a few tested rule ideas based on a recent Rapid7 whitepaper (link in rules).

I built a minimal PCAP to exercise the icmpShell related behaviors described by Rapid7 and tested the rules separately in Suricata. As part of the normal workflow, I first checked ET Open / free rules before testing the local rules.

The three candidate ICMP rules are:

alert icmp any any -> any any (msg:"LOCAL BPFDoor-inspired ICMP visible X marker request"; itype:8; icode:0; content:"X:"; depth:2; reference:url,https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/; sid:9002001; rev:2;)

alert icmp any any -> any any (msg:"LOCAL BPFDoor-inspired ICMP invalid echo code 1 heartbeat"; itype:8; icode:1; reference:url,https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/; sid:9002002; rev:3;)

alert icmp any any -> any any (msg:"LOCAL BPFDoor-inspired ICMP hardcoded sequence 1234"; itype:8; icode:0; dsize:>0; icmp_seq:1234; reference:url,https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/; sid:9002003; rev:1;)

Observed hits on the lab PCAP were:

visible X: request rule → 4 hits
invalid echo code 1 heartbeat rule → 1 hit
hardcoded sequence 1234 rule → 4 hits

My reading of the Rapid7 whitepaper is that these three are directly supported as network artifacts:

plaintext X: transport tag
technically invalid ICMP code 1 used by the heartbeat thread
hardcoded ICMP sequence number 1234

I also shared the lab PCAP and related notes here in case it is useful for review:
https://github.com/Pb-22/Network_Detections/tree/main/BPFDoor

Do these seem like reasonable ET Open candidates?

Thanks!

bingohotdog · April 28, 2026, 10:29pm

Hi Pb-22! Great to see you here again. I’ll start reviewing this and get back to you.

Cheers,

Pb-22 · April 29, 2026, 9:19pm

Thanks!

bingohotdog · May 5, 2026, 8:44pm

Hi Pb-22,

The Rapid7’s report provided a comprehensive look into BPFDoor’s evolution. ET has done work on previous iterations of BPFDoor. Here are the references to the recent work, if you’re curious:

I reviewed the Rapid7 report about icmpShell content and your rules. I would say 2/3 rules are good candidates for ET OPEN.

The rule addressing the invalid ICMP packet will not forward as it is covered by a deactivated GPL rule. More specifically…

alert icmp any any -> any any (msg:"LOCAL BPFDoor-inspired ICMP invalid echo code 1 heartbeat"; itype:8; icode:1; sid:2; rev:1;)

is covered by...

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"GPL ICMP PING undefined code"; icode:>0; itype:8; classtype:misc-activity; sid:2100365; rev:9; metadata:created_at 2010_09_23, confidence Medium, signature_severity Informational, updated_at 2019_07_26;)

SID:2100365 is currently deactivated in the published ruleset and it is up to our users’ discretion to activate it. In your future investigations, changing “#alert” to “alert” in the rulesets during testing will provide a complete coverage picture. Also, I agree with SID:2100365’s usage of Informational as an ICMP packet with an undefined code isn’t always malicious.

For the other rules, I think they are good candidates for ET OPEN! They will be added this week.

See below for change notes.

Rule 1, LOCAL BPFDoor-inspired ICMP visible X marker request

# Initial Rule
alert icmp any any -> any any (msg:"LOCAL BPFDoor-inspired ICMP visible X marker request"; itype:8; icode:0; content:"X:"; depth:2; reference:url,https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/; sid:9002001; rev:2;)

From the report, there is an ICMP Packet with “X:” in clear text. Let’s start with this skeleton rule:

alert icmp any any -> any any (msg:"ET MALWARE BPFDoor ICMP Packet (X:)"; content:"X:"; startswith; sid:9002001; rev:1;)

From report screenshots, there are Echo Requests and Replies containing the hardcoded “X:”. These ICMP types are useful for defining source, destination, and our itypes. Notice that I did not define the Suricata code values as we know BPFDoor may use undefined codes.

# Final Rules
alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE BPFDoor ICMP Echo Request X: (Outbound)"; itype:8; content:"X:"; startswith; url,rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/; sid:90020011; rev:1;)

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET MALWARE BPFDoor ICMP Echo Reply with X: (Inbound)"; itype:0; content:"X:"; startswith; url,rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/; sid:90020012; rev:1;)

Rule 2, LOCAL BPFDoor-inspired ICMP hardcoded sequence 1234

# Initial Rule
alert icmp any any -> any any (msg:"LOCAL BPFDoor-inspired ICMP hardcoded sequence 1234"; itype:8; icode:0; dsize:>0; icmp_seq:1234; reference:url,https://www.rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/; sid:9002003; rev:1;)

From the report, we know that there is a ICMP packet with a hardcoded 1234 sequence number. Let’s start with this skeleton rule:

alert icmp any any -> any any (msg:"ET MALWARE BPFDoor ICMP with hardcoded sequence 1234"; icmp_seq:1234; sid:9002003; rev:1;)

From report screenshots, there are Echo Requests and Replies containing the hardcoded 1234 number. Like the previous skeleton rule, let’s consider this creating two rules for Outbound and Inbound traffic.

alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE BPFDoor ICMP Echo Request with (Outbound)"; itype:8; icmp_seq:1234; sid:90020031; rev:1;)

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET MALWARE BPFDoor ICMP Echo Reply (Inbound)"; itype:0; icmp_seq:1234; sid:90020032; rev:1;)

To ensure these rules alert on BPFDoor activity, we need to prevent alerting on any benign ICMP packet with icmp_seq:1234. We can use threshold to define strange frequencies. The defined threshold below alerts if a second instance of these rules appear within 60 secs.

# Final Rules
alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE BPFDoor ICMP Echo Request (Outbound)"; itype:8; icmp_seq:1234; threshold: type threshold, track by_dst, count 2, seconds 60; url,rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/; sid:90020031; rev:2;)

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET MALWARE BPFDoor ICMP Echo Reply (Inbound)"; itype:0; icmp_seq:1234; threshold: type threshold, track by_src, count 2, seconds 60; url,rapid7.com/blog/post/tr-new-whitepaper-stealthy-bpfdoor-variants/; sid:90020032; rev:2;)

References:

Report: New Whitepaper: Stealthy BPFDoor Variants are a Needle That Looks Like Hay
Technical Paper: https://www.rapid7.com/cdn/assets/bltd3dbeae8537bb21b/69ce33a499d6c52de57e4a02/unmasking-the-new-stealthy-BPFDoor-variants.pdf
IOCs: Rapid7-Labs/BPFDoor at main · rapid7/Rapid7-Labs · GitHub

Pb-22 · May 6, 2026, 4:37pm

Thanks, @bingohotdog, this is very helpful, and I appreciate the detailed review.

That makes sense on the invalid ICMP code rule being covered by SID 2100365. I also agree that Informational severity is appropriate there, since an undefined ICMP echo code is not necessarily malicious by itself.

I also appreciate the testing tip about changing disabled #alert rules to alert during local coverage review. I have now added an option in my Suricata workbench to run a separate disabled-rule coverage pass for this kind of review.

One thing I realized while retesting is that my BPFDoor lab PCAP was internal to internal, so SID 2100365 would not fire as written because it is scoped $EXTERNAL_NET -> $HOME_NET. I should have changed the test IPs to better reflect actual traffic.

I also saw generic decoder-event coverage during testing via:

alert pkthdr any any -> any any (msg:"SURICATA ICMPv4 unknown code"; decode-event:icmpv4.unknown_code; classtype:protocol-command-decode; sid:2200025; rev:2;)

So between SID 2100365 and the Suricata decoder event, I agree the invalid-code behavior is better treated as existing/generic anomaly coverage rather than a BPFDoor-specific malware rule.

The split between outbound Echo Request and inbound Echo Reply for the X: marker and icmp_seq:1234 rules makes sense. The threshold on the sequence-number rule also seems like a good way to reduce noise from benign ICMP traffic that may happen to use sequence 1234.

Thank you again for taking the time to review and improve these. This was very useful feedback!

Pb-22 · May 6, 2026, 5:21pm

While rebuilding my PCAP with a cleaner internal/external IP layout, I went back through the Rapid7 whitepaper and realized the X: behavior appears to be attacker-sent command traffic inbound to the victim, with the victim then responding outward using RC4-encrypted ICMP.

Because of that, I wonder whether X: may be more faithful as a seed event rather than as a standalone outbound indicator. Would it make sense to model X: as an inbound seed and correlate it with a follow on outbound irregular ICMP response using xbits?

That seems a bit closer to the behavior described in the whitepaper. I will work on testing this as well, in case this approach would be useful.

Pb-22 · May 6, 2026, 7:18pm

Thanks again, @bingohotdog — I tested that idea locally, and the xbits approach did work on a rebuilt PCAP with the corrected internal/external layout.

The version I tested was:

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL BPFDoor inbound ICMP X: seed"; itype:8; content:"X:"; startswith; xbits:set,bpfdoor_icmp_x_seed,track ip_dst,expire 30; noalert; sid:99020011; rev:1;)

alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL BPFDoor possible ICMP reply after inbound X: seed"; itype:0; dsize:>0; xbits:isset,bpfdoor_icmp_x_seed,track ip_src; sid:99020012; rev:1;)

This seemed to fit the whitepaper behavior a little better in testing, since it treats X: as the inbound trigger and then looks for the follow-on outbound ICMP response rather than treating X: itself as the main outbound artifact.

Not suggesting any change to the sequence-1234 rules those still make sense to me, but I wanted to share the result in case this correlation approach is useful for the X: side of the behavior.

The new pcap is here if needed Network_Detections/BPFDoor/scenario11_bpfdoor_icmp.pcap at main · Pb-22/Network_Detections · GitHub

Pb-22 · May 6, 2026, 7:46pm

Hi @bingohotdog one more small follow-up from testing.

The rebuilt the PCAP with a cleaner internal/external layout to better match the Rapid7 whitepaper behavior were also tested, and in that version the proposed icmp_seq:1234 rules did not fire as written. However, direction-flipped test versions did fire.

In the rebuilt PCAP, the icmp_seq:1234 Echo Requests are EXTERNAL_NET → $HOME_NET, and the corresponding Echo Replies are $HOME_NET → $EXTERNAL_NET, which seemed more consistent with the command/response flow described in the whitepaper.

So I wanted to mention that the sequence-1234 artifact may have the same directional question as the X: behavior, depending on how strictly the rules are meant to follow the Rapid7-described traffic flow.

Sorry for al the posts sharing the test results in case it is useful while you are finalizing the rules.

So I was thinking :

BPFDoor ICMP Echo Request with sequence 1234 - inbound

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL TEST BPFDoor ICMP Echo Request seq 1234 (Inbound)"; itype:8; icmp_seq:1234; threshold:type threshold, track by_dst, count 2, seconds 60; sid:99020031; rev:1;)

BPFDoor ICMP Echo Reply with sequence 1234 - outbound

alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL TEST BPFDoor ICMP Echo Reply seq 1234 (Outbound)"; itype:0; icmp_seq:1234; threshold:type threshold, track by_src, count 2, seconds 60; sid:99020032; rev:1;)

and
for the ‘X:’ inbound request and encrypted response

alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"LOCAL BPFDoor inbound ICMP X: seed"; itype:8; content:"X:"; startswith; xbits:set,bpfdoor_icmp_x_seed,track ip_dst,expire 30; noalert; sid:99020011; rev:1;)

alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"LOCAL BPFDoor possible ICMP reply after inbound X: seed"; itype:0; dsize:>0; xbits:isset,bpfdoor_icmp_x_seed,track ip_src; sid:99020012; rev:1;)

Thanks!

bingohotdog · May 7, 2026, 10:51pm

Excellent idea with xbits usage. The recently released “X:” rules will be updated with xbits. Thank you for providing your test PCAP and the conversation on this!

dever · May 9, 2026, 8:39am

I recently got a warning via a Threat Prevention package on my Synology RT6600AX router for this BPFDoor malware. The only thing I can contribute is that I got 2 warnings & drops. The first was initiated out of my router as the source to a remote IP 209.249.51.194 with payload pasted below:

ICMP Header
Type: 8
Code: 0
Identification: 28842
Sequence number: 512
Checksum: 2948
Payload
00000000  58 3a 71 47 00 00 00 00 00 00 00 00 00 00 00 00  X:qG............
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030  00 00 00 00 00 00 00 00                          ........

I immediately blocked 209.249.51.194/24

Roughly 40 mins later the 2nd signature match happened from my router to remote IP 172.113.224.1 with the following payload:

ICMP Header
Type: 8
Code: 0
Identification: 21776
Sequence number: 0
Checksum: 44918
Payload
00000000  58 3a 18 c1 00 00 00 00 00 00 00 00 00 00 00 00  X:..............
00000010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000030  00 00 00 00 00 00 00 00                          ........

Immediately banned 172.113.224.1/24. Reinstalled the routers firmware, & I haven’t gotten anything since. I ssh’d into the router & searched for the known files listed in Rapid 7’s script & didn’t find any. I might have had a new varient? not sure. I might have wiped out what got in during the firmware reflash.

Anyhow, I figured I’d send the payloads, because I saw the 1st was different than just “X:” you had. This one seems to morph often & is very sneaky.

LMK if you know of a way to aide in detection/cleaning of this backdoor, the Rapid 7 script wasn’t usable with BusyBox’s limited functions that my router has available. It was made for bash.

ace · May 10, 2026, 11:50pm

My org received the ET OPEN rulset update on 5/9, and since then I’ve observed multiple alerts triggering on SID 2069175 rev 2.

While I did not observe any of the additional artifacts referenced in Rapid7’s whitepaper, I did notice a pattern across all events today. Every alert fired within a single one-second window (02:57:12.017-02:57:13.000).

On review of the ICMP payloads, the data appears consistent with standard Linux ping behavior, including the expected incremental ASCII filler pattern following the ICMP timestamp structure.

In my case, I believe Suricata is interpreting the initial bytes of the ICMP struct timeval timestamp as ASCII. Two adjacent bytes in the binary timestamp may coincidentally be decoding to 0x58 0x3A, depending on the specific capture timing.

I’m still validating this against additional captures, but the strict 1-second clustering and payload consistency makes me think this may be a decoding edge case.

For reference, these are the ASCII-rendered ICMP payloads from our misc Linux devices that were alerted on.

X:.j............................ !"#$%&'()*+,-./01234567
X:.j............................ !"#$%&'()*+,-./0123456789:;<=>?
X:.j.....* ..................... !"#$%&'()*+,-./01234567
X:.j...... ..................... !"#$%&'()*+,-./01234567
X:.j...... ..................... !"#$%&'()*+,-./01234567
X:.j.....J...................... !"#$%&'()*+,-./01234567
X:.j.....Y...................... !"#$%&'()*+,-./01234567
X:.j...."Y...................... !"#$%&'()*+,-./01234567
X:.j...... ..................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j.....1...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j.....7...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j.....K...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j.....R...................... !"#$%&'()*+,-./01234567
X:.j.....`...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....9....................... !"#$%&'()*+,-./01234567
X:.j....9q...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....N_...................... !"#$%&'()*+,-./01234567
X:.j....P*...................... !"#$%&'()*+,-./01234567
X:.j....X}...................... !"#$%&'()*+,-./01234567
X:.j....]1...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....^....................... !"#$%&'()*+,-./01234567
X:.j....a....................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....b. ..................... !"#$%&'()*+,-./01234567
X:.j....p....................... !"#$%&'()*+,-./01234567
X:.j....t'...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....z....................... !"#$%&'()*+,-./01234567
X:.j.... ....................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j...."&...................... !"#$%&'()*+,-./01234567
X:.j....#....................... !"#$%&'()*+,-./01234567
X:.j....#7...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....&....................... !"#$%&'()*+,-./01234567
X:.j....(....................... !"#$%&'()*+,-./01234567
X:.j....(s...................... !"#$%&'()*+,-./01234567
X:.j....*+...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....*....................... !"#$%&'()*+,-./01234567
X:.j.....!...................... !"#$%&'()*+,-./01234567
X:.j.....#...................... !"#$%&'()*+,-./01234567
X:.j.....$ ..................... !"#$%&'()*+,-./01234567
X:.j.....*...................... !"#$%&'()*+,-./01234567
X:.j.....,...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j...... ..................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j.....?...................... !"#$%&'()*+,-./01234567
X:.j.....C...................... !"#$%&'()*+,-./01234567
X:.j.....I...................... !"#$%&'()*+,-./01234567
X:.j.....L...................... !"#$%&'()*+,-./01234567
X:.j.....M...................... !"#$%&'()*+,-./01234567
X:.j.....P...................... !"#$%&'()*+,-./01234567
X:.j.....Q ..................... !"#$%&'()*+,-./01234567
X:.j.....Q...................... !"#$%&'()*+,-./01234567
X:.j.....f ..................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j.....h...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j.....v...................... !"#$%&'()*+,-./01234567
X:.j.....x...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j.....y...................... !"#$%&'()*+,-./01234567
X:.j.....z...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....4(...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....6....................... !"#$%&'()*+,-./01234567
X:.j....8....................... !"#$%&'()*+,-./01234567
X:.j....@....................... !"#$%&'()*+,-./01234567
X:.j....B ...................... !"#$%&'()*+,-./01234567
X:.j....C....................... !"#$%&'()*+,-./01234567
X:.j....CP...................... !"#$%&'()*+,-./01234567
X:.j....D....................... !"#$%&'()*+,-./01234567
X:.j....Ee...................... !"#$%&'()*+,-./01234567
X:.j....H+...................... !"#$%&'()*+,-./01234567
X:.j....Ht...................... !"#$%&'()*+,-./01234567
X:.j....Q....................... !"#$%&'()*+,-./01234567
X:.j....S....................... !"#$%&'()*+,-./01234567
X:.j....V#...................... !"#$%&'()*+,-./01234567
X:.j....X....................... !"#$%&'()*+,-./01234567
X:.j....\....................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....`)...................... !"#$%&'()*+,-./01234567
X:.j....b?...................... !"#$%&'()*+,-./01234567
X:.j....e....................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....g....................... !"#$%&'()*+,-./01234567
X:.j....g3...................... !"#$%&'()*+,-./01234567
X:.j....n....................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....n? ..................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....o....................... !"#$%&'()*+,-./01234567
X:.j....oQ ..................... !"#$%&'()*+,-./01234567
X:.j....q. ..................... !"#$%&'()*+,-./01234567
X:.j....q0...................... !"#$%&'()*+,-./0123456789:;<=>?
X:.j....t?...................... !"#$%&'()*+,-./01234567
X:.j....|....................... !"#$%&'()*+,-./0123456789:;<=>?

I currently have no revision recommendations, as I’m away from my lab. I just wanted to bring this up in case this was noticed by anyone else.

EDIT: I’ve validated that rev 2 is firing on 0x58 0x3A in the Unix timestamp. Given we’re dealing with a 32-bit integer, we’re looking at a 65,536-second interval. My original alerts fired between 02:57:12.017-02:57:13.000, then I had another burst between 21:09:12-21:09:13.

I’ve tested a new revision which accounts for the 16-byte timestamp. Please share your thoughts.

alert icmp any any -> $HOME_NET any (msg:"ET MALWARE BPFDoor ICMP Echo Request, X:[COMMAND] (Inbound)"; xbits:set,ET.bpfdoor,track ip_src,expire 60; itype:8; content:"X:"; offset:16;

Unengaged7387 · May 12, 2026, 7:32am

Hey!

Thanks for this rule, however as it seems, the monitoring tool “CheckMK” does create traffic, which creates false positives…

{“timestamp”:“2026-05-11T01:50:12.526750+0000”,“flow_id”:133892692653364,“in_iface”:“bond0”,“event_type”:“alert”,“vlan”:[185],“src_ip”:“10.1.7.5”,“dest_ip”:“10.85.3.231”,“proto”:“ICMP”,“icmp_type”:8,“icmp_code”:0,“pkt_src”:“wire/pcap”,“community_id”:“1:hzq35g9oEbenJ/+siopobqh9Rp8=”,“alert”:{“action”:“allowed”,“gid”:1,“signature_id”:2069175,“rev”:2,“signature”:“ET MALWARE BPFDoor ICMP Echo Request, X:[COMMAND] (Inbound)”,“category”:“A Network Trojan was detected”,“severity”:1,“source”:{“ip”:“10.1.7.5”},“target”:{“ip”:“10.85.3.231”},“metadata”:{“affected_product”:[“Linux”],“attack_target”:[“Client_Endpoint”],“confidence”:[“High”],“created_at”:[“2026_05_05”],“deployment”:[“Perimeter”],“malware_family”:[“BPFDoor”],“signature_severity”:[“Critical”],“tag”:[“BPF”],“updated_at”:[“2026_05_08”]},“rule”:“alert icmp any any → $HOME_NET any (msg:\“ET MALWARE BPFDoor ICMP Echo Request, X:[COMMAND] (Inbound)\”; xbits:set,ET.bpfdoor,track ip_src,expire 60; itype:8; content:\“X:\”; startswith; reference:url, New Whitepaper: Stealthy BPFDoor Variants are a Needle That Looks Like Hay ; reference:url, SIG: BPFDoor icmpShell ICMP artifacts from Rapid7 whitepaper ; classtype:trojan-activity; sid:2069175; rev:2; metadata:affected_product Linux, attack_target Client_Endpoint, created_at 2026_05_05, deployment Perimeter, malware_family BPFDoor, confidence High, signature_severity Critical, tag BPF, updated_at 2026_05_08; target:dest_ip;)”},“direction”:“to_server”,“payload_printable”:“X:.j…!.. !\”#$%&'()*+,-./01234567",“stream”:0,“packet”:“ABx/pJHF3hHAqGQzgQAAZAgARQAAVN1hQABAAWtLwKhkM6wbIQUIADu4i64AAVg6AWoAAAAADCEMAAAAAAAQERITFBUWFxgZGhscHR4fICEiIyQlJicoKSorLC0uLzAxMjM0NTY3”,“packet_info”:{“linktype”:1}}

Topic		Replies	Views
Flexible Rule Writing: Seeing Around The Bend Tutorials, Tips & Tricks	0	280	March 25, 2025
Ruleset Update Summary - 2024/12/03 - v10785 Ruleset Updates	0	265	December 3, 2024
Detection Exercise: D-Link DIR-513 (CVEs: 2025-8184, 8169, and 8168) Tutorials, Tips & Tricks	0	279	August 2, 2025
Handling False Positive Reports as A Rule Writer! Special Guests: PCREs, Dalton, Dalton’s Flowsynth Tutorials, Tips & Tricks dalton , false-positives , pcre , flowsynth , tutorial	11	647	October 12, 2023
Ruleset Update Summary - 2024/12/16 - v10807 Ruleset Updates	0	162	December 16, 2024

SIG: BPFDoor icmpShell ICMP artifacts from Rapid7 whitepaper

Rule 1, LOCAL BPFDoor-inspired ICMP visible X marker request

Rule 2, LOCAL BPFDoor-inspired ICMP hardcoded sequence 1234

Related topics