Suricata

When attempting use a flowbit pair of rules to detect a successful FTP login (rules below) results in a False Negative event when run against the attached redacted agent-tesla FTP exfil traffic.

# slightly modified to remove noalert;and swap src/dst host vars
alert ftp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET FTP USER login flowbit"; flow:established,to_server; content:"USER "; nocase; depth:5; flowbits:set,ET.ftp.user.login; flowbits:noalert; reference:url,doc.emergingthreats.net/bin/view/Main/2002850; classtype:not-suspicious; sid:2002850; rev:5; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

alert tcp $EXTERNAL_NET 21 -> $HOME_NET any (msg:"ET POLICY FTP Login Successful"; flow:from_server,established; flowbits:isset,ET.ftp.user.login; flowbits:isnotset,ftp.user.logged_in; flowbits:set,ftp.user.logged_in; content:"230 "; depth:4; reference:url,doc.emergingthreats.net/2003410; classtype:misc-activity; sid:2003410; rev:9; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

Once removing the `flowbits:noalert;` from 2002850, it does produce an alert, so we know the flowbit is getting set. Removing the `flowbits:isset,ET.ftp.user.login;` from 2003410 results in both rules firing correct without the flowbit pairing

[
  {
    "timestamp": "2021-12-01T21:47:27.220504+0000",
    "flow_id": 108851339681112,
    "event_type": "alert",
    "src_ip": "192.168.1.10",
    "src_port": 49159,
    "dest_ip": "5.10.40.50",
    "dest_port": 21,
    "proto": "TCP",
    "metadata": {
      "flowbits": [
        "ET.ftp.user.login" 
      ]
    },
    "community_id": "1:pqbfkyQt/WARC58fIBkgr6P1OxI=",
    "alert": {
      "action": "allowed",
      "gid": 1,
      "signature_id": 2002850,
      "rev": 5,
      "signature": "ET FTP USER login flowbit",
      "category": "Not Suspicious Traffic",
      "severity": 3,
      "metadata": {
        "created_at": [
          "2010_07_30" 
        ],
        "updated_at": [
          "2010_07_30" 
        ]
      }
    },
    "app_proto": "ftp",
    "app_proto_tc": "failed",
    "flow": {
      "pkts_toserver": 10,
      "pkts_toclient": 17,
      "bytes_toserver": 697,
      "bytes_toclient": 1597,
      "start": "2021-12-01T21:47:27.220504+0000" 
    },
    "payload": "VVNFUiByZWRhY3RAcmVkYWN0ZWR4LmNvbQ0KUEFTUyBYUkVEQUNURURYWA0KT1BUUyB1dGY4IG9uDQpQV0QNClRZUEUgSQ0KUEFTVg0KU1RPUiBQV19YWERPTUFJTlhYLlVTRVJOQU0tQ09NUFVURVJOQU1FWF9YWFhYX01NX0REX0hIX01NX1NTLmh0bWwNCg==",
    "payload_printable": "USER redact@redactedx.com\r\nPASS XREDACTEDXX\r\nOPTS utf8 on\r\nPWD\r\nTYPE I\r\nPASV\r\nSTOR PW_XXDOMAINXX.USERNAM-COMPUTERNAMEX_XXXX_MM_DD_HH_MM_SS.html\r\n",
    "stream": 1,
    "packet": "RQAAKAAAAABABoviwKgBCgUKKDLABwAVxWLYpeWeMQZQMgoAQfoAAA==",
    "packet_info": {
      "linktype": 12
    }
  }
]

To troubleshoot the rule the following additional rules were created

alert tcp-pkt $HOME_NET any -> $EXTERNAL_NET 21 (msg:"ET FTP USER login flowbit - TCP PKT"; flow:established,to_server; content:"USER "; nocase; depth:5; flowbits:set,ET.ftp.user.login1; sid:1; rev:5;)
alert tcp-pkt $EXTERNAL_NET 21 -> $HOME_NET any (msg:"ET POLICY FTP Login Successful - TCP PKT"; flow:established,to_client;  flowbits:isset,ET.ftp.user.login1; flowbits:isnotset,ftp.user.logged_in; flowbits:set,ftp.user.logged_in; content:"230 "; depth:4; sid:2;)

which, while using the same basic logic utilize the tcp-pkt "protocol" instead of "ftp". The troubleshooting rules correctly cause sid:2 to alert.