Returning to the decision in stage 720, if, however, the message is a simulated or known phishing attack, flow 700 proceeds to stage 708, as in FIG. 18. As a redundant check, if the system is unable to determine metadata in stage 708 (step S4) or decode and/or decrypt the metadata in stage 710 (step S5), flow 700 also proceeds to stage 740. Otherwise, flow 700 proceeds to stage 712 (step S6), where the user reputation score is updated.
In some embodiments, code executing at the network server device can parse the header and make the determination as to whether or not the message being reported is a simulated phishing message generated by the system. In those embodiments, certain information may be first stripped from the message before forwarding for further analysis. In particular, identifying information such as the to: header field and domain name information may be removed.
As in FIG. 18, in stage 712 after decoding and decrypting, the system derives a tracking URL (step S6). The tracking URL could be in the form of “https://phishreporter.phishmessage.com/3918d3df-94ea-459f-af17-084474c0a801”. Having successfully decoded and decrypted the string (the contents of which are a tracking URL in step S6), the system calls out to that URL to update metrics related to the simulated phishing message. As example metrics, tracking and identifying information from the string can be used to update a reputational score associated with the user reporting the message, as further described below.
Suspicious Message Received at Management Console Module
