Missing "payload" attribute in eve.json alert

Reference:
- Suricata version: 7.0.5
- OS: Ubuntu 22 server
- Suricata installed via apt

I am trying to figure out why some of the observed alerts in eve.json are missing the “payload” attribute. I have isolated it somewhat using a handcrafted rule (which parses successfully):

alert ip $HOME_NET any -> [192.168.254.253] any (msg:"Test: Missing payload"; classtype:misc-attack; sid:1200200; rev:1; metadata:affected_product Any, attack_target Any, deployment Perimeter, tag Threatview_CS, signature_severity Major, created_at 2024_12_03, updated_at 2024_12_03;)

The following shows the results of how I triggered the alert, and the resulting eve.json results. My question is: why am I missing the “payload” attribute when triggering it using TCP (via ssh command), but I do receive the expected “payload” attribute when triggering it using ICMP (via ping)? I want to ALWAYS get the “payload” attribute for the eve log output—regardless of protocol. I’m guessing I need to tweak my suricata.yaml file—including my current file for examination.
suricata_missingpcap.yaml (10.8 KB)

Resulting triggering/eve.json results:

TEST CASE #1:
ssh user@192.168.254.253

{"timestamp":"2024-12-03T20:35:13.259201+0000","flow_id":550310190386111,"in_iface":"enp5s0","event_type":"alert","src_ip":"172.16.1.60","src_port":48094,"dest_ip":"192.168.254.253","dest_port":22,"proto":"TCP","pkt_src":"wire/pcap","ether":{"src_mac":"00:03:2d:45:8e:9e","dest_mac":"60:15:2b:aa:6e:11"},"alert":{"action":"allowed","gid":1,"signature_id":1200200,"rev":1,"signature":"Test: Missing payload","category":"Misc Attack","severity":2,"metadata":{"affected_product":["Any"],"attack_target":["Any"],"created_at":["2024_12_03"],"deployment":["Perimeter"],"signature_severity":["Major"],"tag":["Threatview_CS"],"updated_at":["2024_12_03"]}},"direction":"to_server","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":74,"bytes_toclient":0,"start":"2024-12-03T20:35:13.259201+0000","src_ip":"172.16.1.60","dest_ip":"192.168.254.253","src_port":48094,"dest_port":22},"stream":0}


TEST CASE #2:
ping 192.168.254.253

{"timestamp":"2024-12-03T20:35:57.541653+0000","flow_id":1481957009962777,"in_iface":"enp5s0","event_type":"alert","src_ip":"172.16.1.60","src_port":0,"dest_ip":"192.168.254.253","dest_port":0,"proto":"ICMP","icmp_type":8,"icmp_code":0,"pkt_src":"wire/pcap","ether":{"src_mac":"00:03:2d:45:8e:9e","dest_mac":"60:15:2b:aa:6e:11"},"alert":{"action":"allowed","gid":1,"signature_id":1200200,"rev":1,"signature":"Test: Missing payload","category":"Misc Attack","severity":2,"metadata":{"affected_product":["Any"],"attack_target":["Any"],"created_at":["2024_12_03"],"deployment":["Perimeter"],"signature_severity":["Major"],"tag":["Threatview_CS"],"updated_at":["2024_12_03"]}},"direction":"to_server","flow":{"pkts_toserver":1,"pkts_toclient":0,"bytes_toserver":98,"bytes_toclient":0,"start":"2024-12-03T20:35:57.541653+0000","src_ip":"172.16.1.60","dest_ip":"192.168.254.253"},"payload":"rWtPZwAAAACqRAgAAAAAABAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc=","stream":0}

I’m still learning and discovering, so this could be wrong. It might be that your XFF stanza is in the wrong place. As I have been after XFF replacement and payloads when I want them, I noticed the version specific YAML that is in the online documentation and the YAML that works with Suricata after 7.05 appears to differ (I’m using Suricata on an OPNSense, so that might change my mileage some).

If you replace your eve.json output with this one, does it work?

  - eve-log:
      enabled: yes
      filetype: regular
      filename: eve.json
      metadata: yes
      pcap-file: false
      community-id: true
      community-id-seed: 0
      types:
        - alert:
            payload: yes
            payload-buffer-size: 100kb
            payload-printable: yes
            packet: yes
            http-body: yes
            http-body-printable: yes
            tagged-packets: yes
            metadata:
              app-layer: true
              flow: true
              rule:
                metadata: true
                raw: true
            xff:
              enabled: yes
              mode: extra-data
              deployment: reverse
              header: X-Forwarded-For
        - frame:
            enabled: no
        - anomaly:
            enabled: no

As far as payloads for SSH, just checked my logs, about the half the time I see an SSH payload.