When attackers copy the verify footer

Attackers will copy the verify footer, and Fromenance communication provenance is built on the assumption that they will. A copied footer says "forward this to verify@bank.com", which is an instruction to deliver the lure straight to the institution's fraud team, where it fails verification because the code is bound to a registration and a recipient the attacker does not control.

Why the footer gets copied

The footer is the most trustworthy looking sentence in a real message: "Not sure this email is from Northfield Bank? Forward it to verify@northfieldbank.com or enter code KX73-PQ9G at northfieldbank.com/verify." A lure that includes it looks more legitimate to a customer, so copying it is rational. It is also the last thing the attacker wants the customer to actually do.

What happens when they do

The verify code is bound to one registration, which carries one recipient hash and one content fingerprint. When a copied footer arrives on a lure:

1. The code resolves to the original registration. That is a real code.
2. The recipient is compared. If the lure went to a different person, the HMAC of their address does not match the registration. Not verified, flagged as a replay.
3. The content is compared. If the lure went to the same person (the attacker harvested the original), the fingerprint of the lure is far from the fingerprint of the real message. Not verified, flagged as a replay.

Either way the customer gets "no registered communication matches this message", and the fraud team gets a submission marked replay with high priority, carrying the lure's domains, URLs, and phone numbers as indicators, and the registered template it imitates.

What the attacker learns

That codes are recipient bound and content bound, so copying one does not work. The likely adaptations are to fabricate codes or to drop the footer.

A fabricated code must pass the checksum to be extracted at all, and a code that passes the checksum but resolves to nothing is treated as no code: the submission falls through to the recipient plus fingerprint rule, which the lure also fails. Dropping the footer removes the thing that made the lure look legitimate in the first place, and the customer who has learned to look for it notices.

What the institution learns

Every replay is a signal about which template is being imitated and how quickly. Replay counts appear on the overview, replay events go out as submission.replay_detected webhooks to the SIEM, and the imitated template guess on each Not verified submission tells the analyst which stream to watch.

The one thing to get right

None of this works if the code is not bound to the recipient. A footer with a static per template code proves only that someone had a real message from that template. Fromenance issues one code per message, computed at registration with the recipient hash, and the reserve flow does the same for ESPs that cannot provide the body. The static code is a stopgap for journal fed vendor streams and is documented as such.

Definitions for replay attack and footer replay are in the glossary. The full rule table is on how it works.