You can find a PCAP of this exploit in our GitHub repository. Looking at the connections via Zeek we see:
The attacker’s IP address is “fe80::88d1:4bb:492e:b104” and the victim IP address is “fe80::1550:7290:1622:4dce”. The raw log is slightly out of order (the time field is set from the connection start, but the conn.log row is written when the connection’s state is removed so this can cause out of order log events), but you will see that the attacker first connects to the victim’s portmapper on 111/tcp. Examining this connection in Wireshark shows that this connection requests the NFS port, which returns 2049/tcp, which the attacker then connects to. Next the attacker sends a Network Lock Manager Protocol (NLMP) command to have the victim machine connect to the attacker’s machine, from which it will request a portmapper universal address (formatted as a string, basically). The attacker’s machine runs a version of portmapper that will return an address too large for the victim’s machine to parse. At this point, a successful exploitation will cause the machine to reboot, which subsequently results in the victim system sending a TCP reset (“RST”) packet to the attacker’s machine.
Here is what an exploit address string looks like in Wireshark:
Our detection consists of some signatures to first detect the NLMP connection prior to the second portmapper connection from the victim’s machine to the attacker’s machine for which the address returned is extremely large. An example “notice.log” from the PCAP in the repository follows:
#fields ts uid id.orig_h id.orig_p id.resp_h id.resp_p fuid file_mime_type file_desc proto note msg sub src dst p n peer_descr actions email_dest suppress_for remote_location.country_code remote_location.region remote_location.city remote_location.latitude remote_location.longitude
#types time string addr port addr port string string string enum enum string string addr addr port count string set[enum] set[string] interval string string string double double