Verify an Out-of-Band Client Instruction Before Managed LinkedIn Outreach Changes

A managed LinkedIn outreach provider receives an email from a client's marketing director requesting an immediate change to the campaign's connection request message. The email says the legal team flagged compliance issues and needs the update live within the hour. The message looks legitimate, the signature matches past emails, and the sender's domain is correct.

One problem: this client always requests changes through their project management platform, never email. That single inconsistency is enough to hold the request and verify it independently.

Business email compromise (BEC) cost U.S. businesses $2.7 billion in 2024, according to the FBI Internet Crime Complaint Center. Fraudsters impersonate executives, vendors, and service providers to trick employees into transferring funds, changing payment instructions, or handing over credentials. Managed service providers handling client campaigns face the same risk: an attacker who compromises a client's email can issue fraudulent instructions that damage the campaign, expose data, or redirect billing.

This playbook covers how to recognize a suspicious instruction, perform out-of-band verification, and document the incident for your records and your client's security team.

What qualifies as a suspicious instruction?

Any instruction from an apparently authorized client stakeholder becomes suspicious when it exhibits one or more anomalies:

Channel anomaly: the request arrives through a method the client has never used before, such as email when they always use Slack, or SMS when you have no mobile number on file.

Timing anomaly: the request is marked urgent, uses language like 'before end of day' or 'legal requires this immediately,' or arrives outside normal business hours.

Scope anomaly: the instruction asks for a change outside the client's usual pattern, such as updating billing details, sharing login credentials, pausing the entire campaign without explanation, or targeting a new audience segment never discussed.

Tone anomaly: the message's writing style differs from past communications, contains spelling or grammar errors uncharacteristic of the sender, or uses overly formal or overly casual language.

Domain or address anomaly: the sender's email address uses a look-alike domain (for example, 'clientcornpany.com' instead of 'clientcompany.com') or a personal email address when the contact has always used their corporate account.

• Request to change payment information or add a new payee
• Request to share admin credentials or API keys
• Instruction to pause or delete an active campaign with no context
• Request to export contact lists or campaign data to a new destination
• Change to target audience that contradicts the agreed scope
• Urgent demand for action with no explanation

How do you verify an instruction through out-of-band authentication?

Out-of-band authentication (OOBA) means verifying a request through a communication channel separate from the one that delivered the instruction. If the request arrived by email, you verify it by phone. If it arrived by Slack, you verify it by calling the client at a known number.

The National Institute of Standards and Technology (NIST) defines out-of-band authentication as a method that uses a separate channel to confirm identity, reducing the risk that both channels are compromised simultaneously.

Step one: hold all changes. Do not act on the instruction until verification is complete. If the request involves a live campaign, document the hold and notify your internal team that the account is under review.

Step two: retrieve a known contact. Use your company's client contact database, contract signature page, or onboarding records to find a phone number, Slack handle, or email address you know is legitimate. Never use contact information provided in the suspicious message.

Step three: initiate contact through the known channel. Call the client at the number from your records. If you reach voicemail, leave a message with your callback number and send a follow-up email to the known address explaining that you are verifying a recent instruction. Do not describe the content of the instruction in detail in case the email account is compromised.

Step four: confirm the request. When you reach the client, describe the instruction and ask them to confirm they sent it. If they did not, inform them that their account may be compromised and that you are holding all changes pending further review.

Step five: document the verification. Record the date and time of your call, the person you spoke with, the outcome, and any actions taken. If the instruction was fraudulent, escalate to your security team and notify the client's IT or security contact.

What should the verification receipt include?

A verification receipt is an internal record of the anomaly, your verification steps, and the outcome. It serves as evidence of your due diligence and helps your security team identify patterns if the same client or attacker attempts fraud again.

Include these fields in every verification receipt:

How do you escalate a confirmed fraud attempt?

If the client confirms they did not send the instruction, treat the incident as a confirmed business email compromise attempt and escalate immediately.

Notify the client's security team. If the client has an IT or security contact on file, inform them that their stakeholder's email account may be compromised. Provide the verification receipt and a copy of the fraudulent message if you have preserved it.

Notify your own security team. Share the incident details with your internal security contact or incident response team. They will review your verification steps, check for similar attempts against other clients, and decide whether to report the incident to law enforcement.

Preserve evidence. Do not delete the fraudulent message. Forward it to your security team with full headers so they can analyze the sender's origin, any embedded links, and other indicators of compromise.

Review your access controls. Confirm that no unauthorized changes were made to the client's campaign, billing information, or account settings. If the attacker gained access to any systems, follow your incident response plan to contain the breach.

The U.S. Secret Service recommends contacting law enforcement immediately if you suspect a BEC attempt, preserving all digital evidence, and documenting every step of your response.

How do you prevent future fraud attempts?

Out-of-band verification is a reactive control: it stops fraud after a suspicious instruction arrives. Preventive controls reduce the likelihood that fraudulent instructions reach your team in the first place.

Document each client's approved communication channels during onboarding. Record whether they use email, Slack, project management platforms, or scheduled calls for campaign changes. Note contact names, roles, and phone numbers. Update this record whenever the client changes personnel or processes.

Set payment and credential change policies that require dual approval. For example, any request to update billing information must be verified by two people: the account manager who receives the instruction and a finance team member who calls the client independently.

Train your team to recognize anomalies. Share examples of real BEC attempts, run tabletop exercises where staff practice verifying suspicious requests, and review your verification procedures at least once per year. JPMorgan Chase recommends consistent validation as the most effective defense against payment fraud.

Use email authentication protocols like SPF, DKIM, and DMARC to reduce the likelihood that spoofed emails reach your inbox. Enable multi-factor authentication (MFA) on all internal accounts, especially those that handle client communications or billing.

Monitor for unusual activity. Review account logs for login attempts from unexpected locations, changes to billing or campaign settings that no one on your team initiated, or repeated failed verification attempts from the same client.

What if the client insists the request is urgent?

Urgency is a common social engineering tactic. Fraudsters create pressure to bypass verification procedures, hoping the recipient will act before thinking.

Hold the request regardless of claimed urgency. No legitimate business process should require you to skip verification. If the client truly needs an urgent change, they will confirm it when you call them at a known number.

If the instruction claims legal, compliance, or executive urgency, that increases suspicion rather than reducing it. Attackers frequently impersonate legal counsel, CFOs, or CEOs because recipients are less likely to question authority figures.

When you verify the instruction by phone and the client confirms it is real and urgent, document the urgency as part of your verification receipt. This creates a record that you followed procedure even under time pressure.

How do you handle instructions that arrive through legitimate but compromised channels?

An attacker who compromises a client's Slack workspace, project management account, or email can send instructions through the client's normal channel. The message appears in the expected place, from the expected person, using the expected tone.

This is why out-of-band verification requires a channel completely separate from the one that delivered the instruction. If the instruction arrives through Slack, you verify by phone. If it arrives through your project management platform, you verify by calling a known number or sending a text to a mobile contact you have used before.

Never verify through the same channel, even if it looks legitimate. An attacker with access to the client's Slack account will see your verification message and respond as if they are the client.