The event that inspired this article series on phishing attacks began with what appeared to be a routine document-sharing request. The email appeared to come from a former customer and invited recipients to review a document through Microsoft OneDrive. At first glance, the message looked legitimate.
The sender was known. The context appeared plausible. The request resembled countless other business communications exchanged every day. Yet, something felt unusual.
The message was unexpected, and several indicators suggested it might not be genuine. Rather than opening the document, I contacted the business owner directly. A few days later, the response arrived. The email had not been sent by the company.
By that point, however, many employees, vendors, and customers had already clicked the malicious link. The company initiated remediation efforts, reset passwords, enabled multi-factor authentication across accounts, and ultimately informed affected parties that the issue had been resolved.
From an operational perspective, the incident was closed. From an investigative perspective, however, a number of unanswered questions remained.
Disclaimer
To protect privacy and confidentiality, identifying details have been removed or altered. The observations discussed in this article are based on publicly available information and independent analysis performed after the incident was disclosed. The purpose of this case study is to illustrate investigative methodology rather than determine a definitive root cause.
Previous articles on this series
- #1 - Anatomy of a modern OneDrive phishing attack
- #2 - Why even smart users click: the psychology behind phishing attacks
- #3 - Phishing early detection: the warning signs
- #4 - A practical guide to phishing incident response
- #5 - Phishing attacks: what attackers already know about your business
- #6 - Building a Microsoft 365 defense strategy against phishing attacks
- #7 - Building a phishing resilience programme for organisations
Looking beyond the immediate incident
I was not involved in the company’s internal investigation. I had no access to their systems, logs, email infrastructure, or identity platform. However, as someone who had received the phishing email, I wanted to understand whether my own exposure extended beyond simply receiving the message.
That process led to several observations. None of them prove how the incident occurred. None identify the attacker. None establish a definitive root cause.
What they do illustrate is how open-source intelligence can reveal additional questions worth asking.
Observation one: A history of exposure
The email address used by the business owner appeared in multiple historical data breaches. Several of these exposures were relatively recent. More interestingly, some originated from services that appeared unrelated to the company’s business activities.
Examples included consumer-oriented services, online shopping platforms, and other websites with no obvious connection to the organization’s industry. This observation does not prove compromise: millions of individuals appear in breach datasets every year. However, it raises legitimate questions.
Was the business email address being used for personal registrations? Was account separation consistently maintained? Were the exposed credentials ever reused elsewhere? Could threat actors have collected information about the account from multiple independent sources over time?
These questions are often overlooked during incident response.
Observation two: historical credential exposure
Additional searches revealed that credentials associated with the account had appeared in historical breach data. Some entries contained password hashes. Others contained passwords in clear text. Again, this does not prove that those credentials were used during this incident. Nor does it prove that any current systems remained vulnerable.
However, from an investigative standpoint, historical credential exposure changes the risk profile of an account. If credentials have appeared in multiple breaches over time, investigators may wish to examine:
The objective is not assigning blame. The objective is understanding potential attack paths.
Observation three: digital footprint analysis
I also performed open-source username analysis. The results identified a variety of accounts associated with the username. Some appeared legitimate. Others raised questions regarding impersonation, abandoned accounts, or unauthorized reuse of identity elements.
One particularly interesting finding involved a profile image associated with the business owner. Evidence suggested the image had been downloaded from social media using a third-party service. This finding does not indicate malicious activity. It does, however, demonstrate how publicly available information can be collected, repurposed, and redistributed across platforms.
From an attacker’s perspective, publicly available profile photographs, usernames, biographies, and business affiliations can all contribute to creating convincing impersonation campaigns.
The difference between remediation and investigation
The company’s response focused primarily on remediation.
Actions reportedly included:
- Password changes
- Multi-factor authentication deployment
- Customer communications
- Vendor communications
These are appropriate and necessary steps. However, remediation and investigation are not the same thing.
Remediation asks: “How do we stop the immediate threat?” Investigation asks: “How did the threat emerge in the first place?” Both are important.
Organizations often perform the first extremely well while spending little time on the second.
Questions that remained unanswered
Without access to internal evidence, there is no way to answer many of the questions that emerged. Examples include:
- How did attackers obtain the contact lists?
- Were credentials actually compromised?
- Was a third-party platform involved?
- Was a supplier compromised?
- Was a personal account involved?
- Were previous breach exposures relevant?
- Did attackers perform reconnaissance before launching the campaign?
These questions may have been investigated internally. They may not have been. The important point is that they exist. Declaring an incident resolved does not necessarily mean every relevant question has been answered.
The communication challenge
One aspect of the case that deserves attention involves stakeholder communication. Customers and vendors who actively raised concerns received explanations and assurances. However, this raises an interesting question.
What about recipients who clicked the link but never reported it? What about vendors who ignored the email entirely? What about customers who forwarded the message internally?
Incident communication is often more complex than identifying a list of known complainants.
Organizations must decide:
- Who should be notified?
- What information should be shared?
- How much evidence is required before communication occurs?
- How can confidence be restored without overstating certainty?
These are difficult decisions with operational, legal, and reputational implications.
The risk of premature closure
Perhaps the most important lesson from this case study is the distinction between containment and understanding. An incident can be contained quickly. Passwords can be reset. MFA can be enabled. Systems can appear secure. Yet important investigative questions may still remain unresolved.
Security teams naturally focus on restoring operations. Investigators focus on understanding causation. The healthiest organizations recognize that both perspectives matter.
What an investigator sees
A business owner may see a phishing email. An IT administrator may see an authentication problem. An investigator sees something different.
They see:
- A chain of events
- A collection of hypothesis
- Multiple possible attack paths
- Historical exposure indicators
- Publicly available intelligence
- Unanswered questions
The purpose of investigation is not proving a preferred theory. The purpose is eliminating possibilities until the most likely explanation remains. Sometimes that process takes days. Sometimes it takes weeks.
Sometimes the available evidence never permits a definitive answer.
The real lesson
The most valuable lesson from this incident is not that phishing attacks occur. Every organization already knows that. The lesson is that incidents often reveal broader issues than initially expected. Historical breach exposure. Digital footprint management. Identity protection. Vendor relationships. Publicly available information. Credential hygiene. Third-party risk.
The phishing email may have been the event that triggered attention. It was not necessarily the most interesting part of the story.
For investigators, the most valuable discoveries often emerge after the immediate crisis appears to be over.
Every incident tells two stories. The first is how the attack occurred. The second is what the incident reveals about an organization’s broader exposure.
Negative PID helps organizations investigate phishing incidents, assess digital exposure, analyse public intelligence, and identify risks that may otherwise remain hidden after remediation activities are complete. Learn more at Negative PID.