Traditionally, in a phishing campaign the success condition is the callback. Then we know, the user clicked a thingy. Matt Hand of SpecterOps proposes phishing for persistence instead. So, instead of the immediate callback a delayed reaction should be utilized. His example: the lure only drops a DLL where Microsoft Teams will load it, and the callback arrives the next time Teams restarts. In ATT&CK terms that is DLL search order hijacking (T1574.001), whose detection advice watches for new or modified DLLs and DLLs loaded from abnormal paths, not for the odd child process of WINWORD.EXE. A week later @mariuszbit’s WarCon slides credited the idea and dropped a proxy DLL for Teams the same way. This situation creates a delay between action and outcome. Does this break alert logic?
