A court workstation incident involved a fake invoice attachment; after opening it, a remote-access tool executed. Which role separation is most accurate?

Social delivery and malware payload are distinct roles. In a court workstation incident involving a fake invoice attachment after which a remote-access tool executed, the fake invoice functioned as the social lure (the bait that obtained user execution), while the remote-access tool was the malware payload that provided follow-on control. Court IR reports that separate lure from payload produce clearer tickets, cleaner lessons learned, and better user-awareness follow-up without confusing bait content with the tooling that ran afterward.

Calling the RAT only a propagation vector and the invoice persistence fails: persistence keeps malware across restarts, and propagation spreads between hosts—neither correctly assigns lure vs payload here. Saying both were anti-analysis checks with no delivery role ignores the fake invoice’s delivery/social role and the RAT’s payload role. Calling the invoice the vulnerability exploit and the tool removable-media propagation mislabels both: a social fake invoice is not itself a software vulnerability exploit, and a RAT executing after open is not defined as USB propagation.

Exam caveat: lure/document delivery versus payload tooling is foundational. Do not relabel social bait as ‘the exploit’ unless the stem describes vulnerability exploitation.

Operational check for court IR: preserve the invoice sample and email headers, identify the RAT binary/process and any persistence it installed, isolate the workstation, reset credentials used on that bench, hunt for the same lure hash or RAT indicators on other court clerks’ PCs, and brief staff that unexpected invoices remain a high-risk civic delivery path.