# Bug in emerging-ciarmy.rules?

**URL:** <https://community.emergingthreats.net/t/bug-in-emerging-ciarmy-rules/3124>\
**Category:** Feedback & Support\
**Tags:** etopen\
**Created:** [December 3, 2025, 7:13pm UTC](https://community.emergingthreats.net/t/bug-in-emerging-ciarmy-rules/3124 "2025-12-03T19:13:11Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![mgjk](https://avatars.discourse-cdn.com/v4/letter/m/bcef8e/32.png) [@mgjk](https://community.emergingthreats.net/u/mgjk)\
**Post date:** [December 3, 2025, 7:13pm UTC](https://community.emergingthreats.net/t/bug-in-emerging-ciarmy-rules/3124/1 "2025-12-03T19:13:11Z")

</div>

I downloaded the latest ruleset and I’m comparing it with the master list [https://cinsscore.com/list/ci-badguys.txt](https://cinsscore.com/list/ci-badguys.txt).

The master list contains 15,000 addresses (they say they capped the list to 15,000),

But what’s weird is that the emerging-ciarmy.rules file appears to have 2500 in _numerical_ order.

It starts at 1.15.135.58 and ends at 68.183.122.101. There are no addresses with a first octet greater than 68.

Of the 15,000 on [cinsscore.com](http://cinsscore.com), the list starts with 1.1.176.58 and ends with 223.95.199.204

Am I missing some files?

```auto
$ grep -oE '[^0-9]([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})[^0-9]' ./rules/emerging-ciarmy.rules | sed 's/[^0-9.]//g' | sort -nk 1,1 | uniq | wc -l

2500

$ grep -oE '[^0-9]([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})[^0-9]' ./rules/emerging-ciarmy.rules | sed 's/[^0-9.]//g' | sort -nk 1,1 | uniq | head -1

1.15.135.58

$ grep -oE '[^0-9]([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})[^0-9]' ./rules/emerging-ciarmy.rules | sed 's/[^0-9.]//g' | sort -nk 1,1 | uniq | tail -1

68.183.122.101

```

edit:

I’m using Snort 2.9 (don’t ask why), but this also seems to be the case for Suricata 7.0.3

> **[Proofpoint Emerging Threats Rules](https://rules.emergingthreats.net/open/snort-2.9.0/rules/)**

> **[Proofpoint Emerging Threats Rules](https://rules.emergingthreats.net/open/suricata-7.0.3/rules/)**

---

<div class="post-metadata">

**Author:** ![rgonzalez](https://avatars.discourse-cdn.com/v4/letter/r/bc79bd/32.png) [@rgonzalez](https://community.emergingthreats.net/u/rgonzalez)\
**Post date:** [December 4, 2025, 2:14am UTC](https://community.emergingthreats.net/t/bug-in-emerging-ciarmy-rules/3124/2 "2025-12-04T02:14:30Z")

</div>

indeed! we ran into a hard-stop in the SID ranges we use for CIArmy sigs and we’re investigating. Thanks!

---

<div class="post-metadata">

**Author:** ![pschroeder](https://avatars.discourse-cdn.com/v4/letter/p/c89c15/32.png) [@pschroeder](https://community.emergingthreats.net/u/pschroeder)\
**Post date:** [December 4, 2025, 6:45pm UTC](https://community.emergingthreats.net/t/bug-in-emerging-ciarmy-rules/3124/3 "2025-12-04T18:45:43Z")

</div>

Thanks for bringing this to our attention! We needed to extend the SID range for these CIArmy signatures. The full list (minus a small number of IPs that we exclude) will be available with today’s release.

One note: if you try the same piped-grep command as you shared in the initial post, you may still see a smaller number than you expect. There is a slight issue with your regex, specifically the anchoring `[^0-9]` on either side of the section that captures an IPv4-style IP address. Those `[^0-9]` chars are **part of the match** (since grep doesn’t support lookarounds with `-E`), so they get consumed.

In a list like:

```shell
[1.2.3.4,5.6.7.8,9.9.9.9]

```

- The first match consumes the comma after `1.2.3.4`.

- The next match **needs** a non-digit **before** `5.6.7.8`, but the only separator was **already consumed** by the previous match.

- Result: it skips every other IP → roughly half the count.

Something like this: `grep -oP '(?<!\d)[0-9]{1,3}(?:\.[0-9]{1,3}){3}(?!\d)'` gave a more accurate count for me.

---

<div class="post-metadata">

**Author:** ![mgjk](https://avatars.discourse-cdn.com/v4/letter/m/bcef8e/32.png) [@mgjk](https://community.emergingthreats.net/u/mgjk)\
**Post date:** [December 4, 2025, 9:15pm UTC](https://community.emergingthreats.net/t/bug-in-emerging-ciarmy-rules/3124/4 "2025-12-04T21:15:50Z")

</div>

Thanks so much for fixing the feed and fixing my grep, it’s very helpful.

I look forward to the updated signatures. Thank you!

---

<div class="post-metadata">

**Author:** ![rgonzalez](https://avatars.discourse-cdn.com/v4/letter/r/bc79bd/32.png) [@rgonzalez](https://community.emergingthreats.net/u/rgonzalez)\
**Post date:** [December 4, 2025, 9:37pm UTC](https://community.emergingthreats.net/t/bug-in-emerging-ciarmy-rules/3124/5 "2025-12-04T21:37:50Z")

</div>

Thanks for the report @mgjk and great work @pschroeder !