Persistence Mechanisms (Inbox Rules, App Registrations)

Persistence mechanisms (inbox rules, app registrations)

When an attacker compromises an account, they often try to stay in place by creating "persistence"—something that keeps their access or visibility even if the password is changed or the user becomes suspicious. Common persistence mechanisms in Microsoft 365 include inbox rules (e.g., forwarding mail or hiding messages) and third-party app registrations that keep access to mail or data. Petra surfaces these on the incident so you can find and remove them. This article explains what persistence mechanisms are and how to use this information.

Why persistence matters

If you only reset the password and lock the account, but leave an inbox rule that forwards all new email to the attacker, or leave a malicious app with permission to read mail, the attacker may still have access or visibility. So part of incident response is finding and disabling those mechanisms. Petra analyzes the incident and the tenant to identify inbox rules and apps that are tied to the compromise—for example, a rule created around the time of the incident or an app that was granted permission by the compromised user. Those show up as "persistence mechanisms" on the incident so you can take action.

What you'll see

On the incident detail view you may see a section listing persistence mechanisms. For inbox rules, you might see the rule name, what it does (e.g., forward to an external address), and when it was created. For app registrations, you might see the app name and what permissions it has. Each item is something the attacker may have set up to maintain access or exfiltrate data. Petra may recommend disabling or removing them as part of remediation.

What to do

For each persistence mechanism, the goal is to remove the attacker's advantage. Disable or delete the inbox rule so mail is no longer forwarded or hidden. Revoke or disable the app registration so it can no longer access the tenant or the user's data. Petra may offer actions to disable the rule or app directly from the incident view when remediation is enabled. After you take action, the incident view and remediation history will show what you did, so the incident is fully addressed and the attacker's persistence is gone.