Malicious Inactivity

We covered an example of this in the first half of Device Code Phishing, Part 2. In that case, which was uncovered via a retrospective Petra Scan, the attacker created an inbox rule and then waited for 27 days before sending out thousands of emails.

This is common. Sometimes, the attacker will just sit in the account, read emails, and prepare the best possible exploit, tailored to the actual behavior of the user and their contact. For example, also uncovered via a Petra Scan, we saw a recent incident where an attacker lurked in an inbox, waited until the user was closing on a house, and then sent them a fraudulent invoice to reroute the closing expenses to the attacker.

If you had suspected a compromise, but then did not see any sent emails or new inbox rules for a couple of weeks and assumed all was fine, you would have missed this attack.

Sometimes, the initial attacker doesn't read emails at all.

"So if they don't even read emails, it's not a real compromise... right?"

Unfortunately, that's not enough to conclude that the suspected activity is benign. It is all too common to see a compromised account show no malicious activity after the initial malicious login for weeks or even months.

Why? Because they are sitting on a compromised session and are busy finding the highest bidder.

When an attacker succeeds in compromising an account and then just sits in it without setting inbox rules, registering malicious devices or apps, sending emails, or even reading emails, they are often looking for the highest bidder for the authenticated session.

And then after that long period of "inactivity," the session is transferred to someone else, and there's a burst of malicious events.

To detect and remediate these attacks (particularly in the retrospective Petra scans), we have to understand how attackers use sessions. On marketplaces in the dark corners of the internet, malicious actors will buy these stolen authenticated sessions to run whatever exploitative scheme they've concocted. So the first attacker isn't just sitting around during the inactive stretch; they are working to sell the stolen session to another malicious actor.

When they sell it, they use a device code flow to hand it off:

1. 1.The buyer triggers Microsoft's device code flow to sign in, which prompts the device code confirmation on the initial attacker's device.
2. 2.The seller is paid, and then inputs the buyer's code.
3. 3.The buyer now owns the fully authenticated session.

Interestingly, this handoff looks similar to the attacks we discussed in Device Code Phishing, Part 1.

To provide complete forensics and fully remediate the account, it is important to tie all of the actions together.

If you discount the prolonged period of inactivity, you might mistake the transferred session as benign based on its long history in the user's account with no malicious activity. However, by understanding the full picture, we can tie the initial malicious login to this malicious session transfer and correctly remediate the account.

Having observed countless examples of this pattern here at Petra, we confidently lock and remediate the account on the very first malicious login and prevent an authenticated session from ever being sold, preventing future harm.