Modifying the Fox-IT Meterpreter script to raise a notice

Fox-IT shared a script after Bro Con that looks for evidence of meterpreter payloads being downloaded, but it prints the results, which should work fine with pcaps, but doesn't seem useful for running on live traffic. To run this against live traffic it seems like it would be preferable to raise a notice instead. What I was thinking was something such as below, but I'm not sure if I'm missing any pieces, or if I'm even thinking this through correctly. Will this work? Is it likely to be cluster safe?

Modified code is below:

module Meterpreter;

export {
     #Add new notice type for Meterpreter
     redef enum Notice::Type += {
     redef record connection += {
         meterpreter_payload_size: count &optional;

event tcp_packet(c: connection, is_orig: bool, flags: string,
                  seq: count, ack: count, len: count, payload: string)
     if(|payload| == 4 && seq == 1)
         c$meterpreter_payload_size = bytestring_to_count(payload, T);
     else if (c?$meterpreter_payload_size && seq == 1 && flags == "AP" && ack > 5)
         if (c$meterpreter_payload_size == ack-5)
             #Raise a notice if we think we've seen a payload
             $msg=fmt("%DT: Possible Meterpreter Payload transfered! %s:%s -> %s:%s",
             c$start_time, c$id$resp_h, c$id$resp_p, c$id$orig_h, c$id$orig_p)]);

The original code is here:

## meterpreter.bro

I did something similar, but my Notice code looks like this to help populate the other fields. I haven’t gotten around to doing a production test yet.

$msg=fmt("%DT: Possible Meterpreter Payload transfered! %s:%s → %s:%s",
c$start_time, c$id$resp_h, c$id$resp_p, c$id$orig_h, c$id$orig_p),

Good pointer. I had gotten a couple hits already, and noticed the notice
line had a few empty fields, but hadn't looked into it further yet. I'll
give that a shot.

The identifier is used for notice suppression correct? If I'm reading
this correctly won't this suppress any further notices of this type that
have the same combination of src ip and dst ip for the default
suppression interval? Wouldn't this potentially result in missing
additional payloads?

Yes, it’s a trade off. I generally prefer the one notice/alert to start an investigation into everything the attacking IP was doing.

If any one is curious, the modified script I ended up with after incorporating Mike's suggestions is below. In the 14 hours or so I've been running it against production traffic I've already seen several hits. At least one of those hosts has multiple hits every few hours and appears to need further investigation, while another looks like it may be a false positive triggering on what appears to be a stock checking/trading app that connects to on port 31654.

## meterpreter.bro