FP? NanoLocker - SID: 2022331

Rule Signatures
1

I have been reviewing Suricata alerts recently. I noticed that the follow side triggered on some Google LLC owned IPs:

trojan.rules:12168:alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET TROJAN NanoLocker Check-in (ICMP) M1"; itype:8; icode:0; dsize:26<>35; content:"|31|"; depth:1; pcre:"/^(?=[A-F1-9]*?[a-km-zGHJ-NP-Z])[a-km-zA-HJ-NP-Z1-9]{25,34}(?:64)?$/R"; reference:md5,24273ce5ca8e84c52b270b52659304a8; reference:url,blog.emsisoft.com/2016/01/01/meet-ransom32-the-first-javascript-ransomware/; classtype:trojan-activity; sid:2022331; rev:3; metadata:created_at 2016_01_05, updated_at 2017_11_22;)

Triggers (examples):

  • 142.250.199.164
  • 142.250.199.132
  • 142.250.199.132
  • 142.250.199.132

Packet Examples (as seen by Suricata - I can’t grab any PCAPs):

1JKKYBravUr6PiWyTeGXQfCH2F4ctZWg

1zvJaaaaaaaaaaaaaaaaaaaaaaaaaaaa

1eLmaaaaaaaaaaaaaaaaaaaaaaaaaaaa

These all appear have reverse dns in *.1e100.net (Google owned domain).

If you look at https://www.proofpoint.com/sites/default/files/proofpoint-all-your-data-are-belong-to-us-threat-insight-en-v2.pdf, which seems to suggest these should only trigger on a single ip: 52.91.55[.]122.

Why does the rule not account for this IP. Yes, I know we don’t want a static IP in some cases for rules, but from any research done on this tool, it always send data here.

2

Hi and welcome@network_goblin!

Thank you for reaching out about this NanoLocker signature and possible False Positive activity.

Before we label anything as False Positive or True Positive, we should review the rule’s intent. This rule aims to …

  • detect NanoLocker’s observed usage of ICMP packets for Command & Control Server activity.
  • match specifically on possible Bitcoin Address strings in the ICMP payload.
  • not restrict itself to any particular IP.

With this in mind, we can address the activity you noted so far.

  • The rule does not use 52.91.55[.]122 as rule content.
    From the Proofpoint report, the IP, 52.91.55[.]122, was hardcoded in the malware at the time (2016), and so this hardcoded IP was shared as an interesting note for other researchers. The IP is not specificed in the rule, but its reputation will drop if malicious traffic was observed from it. Vice versa, if it no malicious traffic was observed, then it’s reputation will be benign. See: Emerging Threat Intelligence - Cyber Threat Solutions | Proofpoint US. This IP belongs to Amazon AWS so considering any traffic from this IP as malicious would affect legitimate users today.

  • The rule alerted on IPs that belonged to Google.
    Infrastructure from Google can be abused, so it’s not too strange for malicious rules to alert here.

  • The rule alerted on the following packet examples:
    1JKKYBravUr6PiWyTeGXQfCH2F4ctZWg
    1zvJaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    1eLmaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Thank you very much for providing this data; very helpful with troubleshooting!

It appears that these packet examples somewhat match the Legacy Address format (Understanding the Differences Between Bitcoin Address Formats When Developing Your App). I do this it’s strange for this ICMP packets to contain these payloads.

At this time, I can not say we have a False Positive / True Positive from looking at these alerts alone. I would advise reviewing the state of the machine(s) sending these packets.

1 Like