Phishing and the Identity Attack Vector in Legal Practice

Why an account can be a valuable entry point

A business identity connects a person to email, documents, calendars and other services. The damage from compromise depends on the permissions attached to that identity.

An attacker who gains mailbox access may see correspondence that helps them impersonate a known participant. Access to document systems can expose client information. Administrator privileges can expand the effects beyond one user.

The FBI describes business email compromise schemes that use impersonation, targeted messages and compromised correspondence to make fraudulent requests appear credible. [1] A law firm's payment and document-sharing workflows should therefore verify more than whether a message has a familiar display name.

Phishing can target several forms of access

Credential phishing asks a user to enter a password into a fraudulent sign-in page. But a password is not the only target.

Microsoft documents attacks that steal authenticated session tokens, including through adversary-in-the-middle phishing. An attacker may replay a stolen session without repeating the user's original authentication steps. Its response guidance also includes reviewing mailbox rules, authentication changes and affected data. [2]

Another route is consent phishing. Instead of asking for a password, an application asks for permission to read mail, access documents or perform other actions. Microsoft explains that users can be tricked into granting those permissions to a malicious application. [3]

These distinctions matter because the right protection and recovery steps depend on what was exposed.

These are illustrative scenarios, not reports about a particular firm.

Familiar branding and good grammar do not prove legitimacy

A message can reuse a logo, refer to a real matter or arrive through a compromised account. A cloud permission screen can be hosted by a legitimate provider while still granting access to an inappropriate application.

Teach staff to evaluate the action being requested. Is the document expected? Does the sender normally use this sharing method? Why does a document task need permission to read the entire mailbox? Why has the payment procedure changed?

When something is inconsistent, verify through a known channel. Open the approved application directly instead of relying on an unexpected sign-in link. Confirm document and support requests using established contact details. Do not treat an urgent tone as authorization to bypass the process.

Use authentication that resists fake websites

CISA urges organizations to adopt phishing-resistant MFA. It recommends number matching as an interim measure for push-based MFA where stronger methods are not yet available, while noting that the two are not equivalent. [4]

FIDO passkeys use cryptographic credentials associated with the registered service, so a user does not type a reusable secret into a lookalike site. [5] Evaluate supported passkeys or security keys for business accounts, starting with administrators and other high-impact roles.

Require the intended method through policy where supported, and review weaker fallback and account-recovery paths. Train users never to approve an unexpected authentication request or provide a verification code to someone claiming to be support.

Phishing-resistant authentication still needs protected devices, controlled app permissions and trustworthy recovery procedures. It does not prevent someone from authorizing an inappropriate application or following a fraudulent payment instruction.

Review applications as well as users

Maintain an inventory of integrations that can access email and client documents. Record the owner, purpose, permissions and approval status of each.

Microsoft recommends managing user consent, reviewing requested permissions and auditing approved applications. A verified publisher is useful information, but its guidance still calls for reviewing the request itself. [3]

Give staff a clear route to request a new integration. Restrict unreviewed permissions in line with the firm's needs, and remove access when an application is no longer used. Broad access granted for a small convenience deserves particular scrutiny.

Make payment verification an independent process

Treat new or changed bank details as a separate approval event. A reply in the same email thread is not independent verification if the thread or account is compromised.

The FBI recommends verifying payment requests and changes to account numbers or payment procedures, and using independently obtained contact information when a request is suspicious. [1]

For a law firm, put that principle into a written workflow. Use contact details already established through a trusted process, document the confirmation and require a second authorized reviewer for sensitive transfers. Establish who can approve an exception, and avoid informal shortcuts under deadline pressure.

Apply the procedure consistently to settlement disbursements, vendor payments and other transfers. A familiar name, letterhead or matching invoice number should not replace the required check.

Respond to suspected compromise beyond the password

Give staff a reporting route they can use immediately, including when they clicked a link, entered credentials, approved a request or granted application access. Encourage prompt reporting without blame.

The security team should assess the exposure, preserve relevant evidence and choose containment appropriate to the incident. That can include restricting the account, resetting credentials, revoking sessions, reviewing authentication methods and checking mailbox rules. Microsoft's token-theft playbook includes these recovery actions. [2]

Review app permissions separately when consent is involved. A password reset does not by itself remove an application's granted access. Coordinate account, device and application remediation before returning the user to ordinary work.

If money was transferred fraudulently, contact the financial institution immediately and report the incident to IC3, as the FBI advises. [1] Legal and security leadership should assess affected information and any applicable client, contractual or regulatory notification obligations.

Measure how well the defenses operate

Review authentication coverage, app-consent controls and payment-verification records. Test how quickly staff can report a suspicious request and how quickly the responsible team responds.

Use training scenarios that resemble the firm's actual workflows: shared documents, client portals, billing requests and support calls. Measure reporting behavior and process adherence alongside training completion.

Protecting identity requires several decisions to work together. Strong sign-in controls reduce opportunities for account takeover. Limited permissions reduce what an account can expose. Independent payment checks and a practiced response process address the risks that authentication alone cannot solve.

Allnext Legal helps law firms strengthen identity protection, manage cloud access and establish practical security procedures around client information and everyday operations.