Impacket SMB Server GUID

Rule Signatures
1

Hi, I recently investigated an incident in which attackers abused a tool that had a specific GUID by default. I propose rules for detecting this identifier

alert smb any any -> any any (msg: "ET CURRENT_EVENTS [ANY.RUN] Impacket Framework SMB Server GUID Detected";
flow: established, from_server;
content: "SMB"; offset: 5; depth: 3;
content: "|00 00|"; distance: 8; within: 2;
byte_jump: 2, -10, relative, little, post_offset 2;
content: "|4141 4141 4141 4141 4141 4141 4141 4141|"; within: 16;
threshold:type limit, seconds 60, count 1, track by_dst;
reference: url,github.com/fortra/impacket;
reference: md5,53b820f2ab8dc03987109c6282d9d74b;
reference: url,app.any.run/tasks/dd2e2001-0808-440f-9115-29b36a77c6d1; 
classtype: policy-violation;
metadata:  created_at 2024_02_26;
sid: 1; rev: 1;)

I saw the rules written for the service

M.HackTool.SMB.Impacket-Obfuscation.[Service Names]

This is for correct naming, I leave it to your choice

ps: I would like to write more but I can’t because it’s a little hot

✧˚ ༘ ⋆｡:heart:˚
Jane

3 Likes
2

Hello Jane,

As always we appreciate your support, and that of any.run.

I’ve made some slight stylistic changes to the rule, but all in all, its about the same as the rule you submitted:

alert smb any any -> $HOME_NET any (msg:"ET INFO [ANY.RUN] Impacket Framework Default SMB Server GUID Detected"; flow:established,to_client; content:"SMB"; offset:5; depth:3; content:"|00 00|"; distance:8; within:2; byte_jump:2,-10,relative,little, post_offset 2; content:"|41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41|"; fast_pattern; within: 16; threshold:type limit, seconds 60, count 1, track by_dst; reference:url,github.com/fortra/impacket; reference:md5,53b820f2ab8dc03987109c6282d9d74b; reference:url,app.any.run/tasks/dd2e2001-0808-440f-9115-29b36a77c6d1; classtype:credential-theft; sid:1; rev:1;)

Something else I would like to mention: In our testing ,this rule hits performance pretty hard. Depending on where and how its deployed, this could be checking every single SMB request passing by both internally and externally. For those of you at home running honeypots, sandboxes, using Dalton, or running limited environments, this shouldn’t be too big of a deal. But for big enterprise networks, this could result in having to be a bit careful as to where this rule is deployed.

We have the rule performance metadata marked as SIGNFICANT, and the rule will be shipped as inactive. However, its still an extremely valuable rule, so long as you take care in planning where you deploy it.

For instance, if you plan on utilizing this rule on your perimeter sensor(s), it may perform a bit better, and catch potential impacket credential harvesting attacks in which clients are interacting with an external SMB server outside of the local network.

In other cases, you may wish to deploy this internally because impacket is a popular penetration testing tool used for pivoting and credential harvesting. In which case, you’ll have to be careful in regards to which sensor(s) you enable on the rule on, as well as being extremely judicious as to how the HOME_NET variable is configured on those sensors.

Another factor to consider would be potentially making a copy of this rule, deploying it to a local.rules file and modifying the rule header to better suit particular deployment needs – for example using the $EXTERNAL_NET variable in place of any for catching external attacks or attacks from other network segments (in the event that you have a well-defined, well-tuned HOME_NET variable defined), or definding a specific set of “internal” network subnets that should be considered “External” networks, and so on and so forth.

Our internal threat research team was looking at recent impacket activity, and we’ll be shipping another fairly similar rule to this in today’s daily release, so keep an eye out for that, as well.

Happy Hunting,

Tony Robinson

1 Like
3

Thank Tony for the detailed answer, most likely this is due to the jump back. Given the importance, I can propose to significantly simplify the detection if we take the header length of 64 bytes in most cases.

alert smb any any -> $HOME_NET any (msg:"ET INFO [ANY.RUN] Impacket Framework Default SMB Server GUID Detected (64b SMB Header)";
flow:established,to_client;
content: "|fe 53 4d 42 40 00 00 00 00 00 00 00 00 00|"; offset: 4; depth: 14; 
content: "|41414141414141414141414141414141|"; distance: 58; within:16;   
reference:url,github.com/fortra/impacket;
reference:md5,53b820f2ab8dc03987109c6282d9d74b;
reference:url,app.any.run/tasks/dd2e2001-0808-440f-9115-29b36a77c6d1; 
reference:url,community.emergingthreats.net/t/impacket-smb-server-guid;
classtype:credential-theft;
sid:2051432; rev:1;
metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, affected_product Windows_11, attack_target Client_and_Server, tls_state plaintext, created_at 2024_02_29, deployment Perimeter, deployment Internal, former_category INFO, performance_impact Significant, confidence High, signature_severity Major, tag impacket, updated_at 2024_02_29; target:dest_ip;)

I apologize for not taking performance into account, I hope we can provide at least a basic level of protection.

Jane Ostin

1 Like