An unexpected shared document: check the work request before opening the file

The notification says a supplier shared a proposal. The service is familiar, the file title fits your work and the sender’s organization has dealt with your team before. It looks like an ordinary task waiting in the inbox.

The file may still contain an unsafe request. It might lead to another sign-in page, ask you to authorize an application or direct you to a payment change. A genuine sharing notification verifies a sharing event, not the legitimacy of every instruction inside the shared material.

The practical question is not simply “Is this a real cloud service?” It is “Is this the document and action I expected from this person, for this piece of work?”

Start with the work, not the logo

Before opening an unexpected file, identify the task it supposedly belongs to. Is there an existing project, invoice, contract or conversation? Were you waiting for a document from this person? Does the title match the stage of the work?

A plausible title is only a starting point. Public information or a compromised mailbox may provide enough context to make a document sound relevant. Verify the specific request through an established contact route when the file is unexpected or asks for something sensitive.

Ask a concrete question: “Did you share this proposal with me today, and does it require me to sign in again?” A generic reply such as “Yes, we sent documents” may not confirm the file or the action you are about to take.

Two documented examples of trusted-service abuse

Microsoft’s January 21, 2026 investigation of a multistage phishing campaign describes misuse of SharePoint sharing in a credential-theft and business-email-compromise sequence. The report concerns observed activity, not a claim that SharePoint itself is inherently unsafe.

An earlier Microsoft investigation, File hosting services misused for identity phishing, also explains how familiar hosting and sharing workflows can lend credibility to malicious content.

The lesson from these reports is about trust boundaries. A legitimate service can host material controlled by someone whose intentions you have not verified. The service name, the sharing notification and the document’s instructions should not be collapsed into one approval.

Use three separate checks

Check the sender

Establish who intended to share the material. Do not rely only on a display name or the fact that you have previously worked with the organization. A familiar account can be compromised, and an unfamiliar employee may be impersonated.

Use a contact route from your records, not a new phone number printed in the document. If the document itself supplies the only way to verify it, the check remains inside the same untrusted story.

Check the task

Confirm why you need the file. A proposal should relate to a proposal process; an invoice should correspond to an actual purchase; a shared policy should come through your organization’s usual communication route.

This is where a colleague’s context can be valuable. The project owner may know that no proposal is expected or that the supplier uses a different process. Ask without forwarding a live suspicious attachment to more people than necessary.

Check the next action

Reading a document, downloading a file, entering a password, approving access and sending money are separate actions. Stop when the workflow changes into one you did not expect.

A document that says “authenticate to view the secure contents” is making a new claim. A genuine sign-in requirement can exist, but it should fit the service and sharing arrangement. Do not assume an embedded button is safe merely because the outer document opened on a familiar platform.

A real access error can still be confusing

Cloud-sharing permissions vary. A file may be restricted to named recipients, people in an organization or another configured audience. Microsoft’s sharing documentation explains that sharing settings and organizational restrictions affect access.

This means a request to sign in is not automatically malicious. It also means an access problem should be resolved with the sender through the established workflow, not by surrendering credentials to any page that offers to fix it.

If a verified colleague shared to the wrong address, ask them to correct the share. If your work account lacks permission, consult your internal support process. Do not use a personal account or disable a security control merely because an external sender says that is the easiest workaround.

The table does not certify any particular file. It keeps uncertainty from pushing you into an unexplained workaround.

The moment a document asks for money

An invoice or proposal can contain bank details, but a file’s presence in a trusted service does not authorize a payment change. Use your organization’s independent payment-verification process, especially for a new destination or changed account details.

Do not let the document choose both the new bank account and the person who confirms it. A phone number inside the same file is not an independent source. A reply in an existing email thread may also be insufficient if the thread itself is compromised.

For a small organization without a formal process, agree in advance who approves changes and which existing contact information will be used. The rule should be predictable enough that an urgent document cannot quietly suspend it.

This is a work-control question, not a judgment about whether the sender sounds polite. A genuine supplier can tolerate a clearly explained verification step. If a payment deadline is real, the responsible people can resolve it through the agreed process.

If you opened the file but did not go further

Do not assume every exposure requires the same response. Note whether the file remained in a browser preview, downloaded, opened in a local application or asked you to enable something. If the service blocked a file as suspicious, do not bypass the block to satisfy the sender.

On a work device, use the designated reporting route and include the relevant link or message in the form your organization requests. Microsoft provides reporting guidance for suspicious messages and files, but your own organization may route reports differently.

Do not upload confidential business material to a public analysis service without authorization. The attempt to check a file should not expose the legitimate contents to another audience.

If you entered credentials or approved access

Report the exact action promptly. Identify the account, approximate time and whether an additional authentication prompt or permission screen appeared. If you granted an application access, that may require a different review from changing a password.

Use trusted account controls and your security team’s instructions. If a file or application executed locally, include that fact. Account cleanup and device cleanup are related but distinct tasks.

Avoid deleting evidence just to make the inbox look normal. Preserve what the response team needs while keeping it out of public channels. You do not need to understand the full attack to give an accurate report of what you did.

For senders: make legitimate sharing easier to verify

A short message outside the automated notification can reduce ambiguity: what you are sharing, why the recipient needs it and whether a sign-in or other step is expected. Use the contact route already associated with the project.

Give files meaningful names, but do not assume a meaningful name proves authenticity. Agree on where sensitive documents belong and how access problems should be handled. If recipients report that a shared file asks for an unexpected operation, take the report seriously even if the notification came from your account.

For recurring workflows, make verification routine rather than an accusation. “We confirm new payment details through the number in our records” is easier to apply than deciding case by case whether a sender feels suspicious.

Our guide to GitHub issue notifications examines another trusted delivery system carrying user-authored instructions. The article on OAuth consent phishing explains why an apparently normal authorization step can grant unintended access.

Cloud collaboration works because sharing is easy. Keep that convenience while making the sensitive next step—signing in, granting permissions or paying—an explicit decision of its own.