Deceptive Links: Unmasking SharePoint Phishing Attacks

Contributors: Prajeesh Sureshkumar & Niranjan Jayanand

Executive Summary

Traditionally, phishing emails aimed to harvest credentials through redirection links embedded directly in the message. However, with modern extended detection and response (XDR) and email security solutions becoming adept at detecting these attacks, threat actors have shifted their tactics, techniques, and procedures (TTPs) to evade detection. In recent weeks, CyberProof security operations center (SOC) analysts have observed a significant surge in the abuse of SharePoint for phishing attacks.

Why Attackers Increasingly Depend on SharePoint Phishing

Attackers are increasingly leveraging SharePoint-themed phishing to exploit user trust in Microsoft platforms. By disguising malicious links as legitimate SharePoint file shares, threat actors trick users into clicking on URLs that lead to credential harvesting pages or malware downloads. The rising popularity of SharePoint phishing can be attributed to several factors:

• Trusted Platform: SharePoint is a widely used and trusted Microsoft platform within businesses.
• Evasion: Emails containing SharePoint links are less likely to be flagged as malicious or phishing by EDR or antivirus software. Users also tend to be less suspicious, believing Microsoft links are inherently safer.
• Stealthy Hosting: Attackers can easily host malicious content, such as fake login pages or payloads, within SharePoint, making them difficult to identify at first glance.
• Dynamic Nature: Since phishing pages are hosted on SharePoint, they are often dynamic and accessible only through a specific link for a limited time, making them harder for automated crawlers, scanners, and sandboxes to detect.

Leveraging SharePoint allows attackers to easily bypass network security tools and email gateways; and since malicious domains hosted on SharePoint are not easily identified by security analysts or tools, and are not widely reported, attackers can reuse them for future attacks on the same or different organizations.

Technical Details

Attackers are no longer solely redirecting users to credential harvesting pages. Instead, they are making these types of attacks increasingly convincing and legitimate, leading users to believe they are interacting with genuine sources or real business emails.

Sample Emails sent by Attackers

^{Figure 1}

^{Figure 2}

URL Redirection

The images below illustrate the URL redirection process, which often includes an identity checking phase:

^{Figure 3}

^{Figure 4}

Figure 3 & 4: Page examples where the victim had to enter their username to proceed to a validation page.

Validation Phase

The following images demonstrate how users are then tricked into a validation phase.

^{Figure 5}

^{Figure 6}

Figure 5 & 6: Sample validation pages that cannot be skipped by test accounts or other domain accounts. Progression to the next stage is only possible if the victim’s/recipient’s email is provided.

After redirection to the validation phase, unlike traditional validation, this acts as a spear-phishing model where only the intended recipients of the specific URL can proceed to the next stage. It is not possible to bypass this validation stage by simply providing generic usernames, as could be done in older phishing attacks.

^{Figure 7}

After the user successfully enters their username, an authentication code is sent to their mailbox.

^{Figure 8}

Figure 7 & 8: These figures show the validation step is bypassed by providing the victim’s email, leading to the code verification phase.

The authentication code is sent to the user’s mailbox as shown below. This is a legitimate Microsoft validation code, which further convinces users that the sender and content are safe and secure.

^{Figure 9}

Figure 9: Sample email delivering the authentication code.

Once the user enters the validation code, the SharePoint URL redirects to content hosted with a fake Microsoft login page. This fake page can be difficult for security analysts to detect by simply checking URL click events or Browse the SharePoint link.

How to Identify if SharePoint is Compromised

One scenario now observed is attackers compromising a sender’s account and using their identity to target a victim. In such cases, it becomes significantly more difficult to determine if a mail is genuine, especially if there are existing mail communications and business relationships with the affected sender or their domain.

Therefore, the primary way to identify if a link is compromised is to analyze the content within the email and its malicious nature. As discussed, it can be challenging to obtain and identify the malicious content of the email directly. Instead, we can use methods to detect if a user has been compromised.

One of the most effective methods to identify a compromised URL is to detect risky or suspicious sign-in activity from the user after they click on an unknown SharePoint link. While checking every SharePoint link in an organization with extensive communications can be difficult, focusing on suspicious sign-ins or malicious audit activity that occurs after a SharePoint URL click is a more efficient use case.

After confirming the URL as the root of the compromise, further investigation on the host can reveal traces of malicious activities, especially if the activity occurred on the user’s machine rather than a personal device. To identify malicious activity, you can examine the host timeline where the user clicked on the SharePoint URL. This may reveal redirections to malicious domains, often fake Microsoft domains.

^{Figure 10} 

^{Figure 11}

You might only find malicious domains from the host timeline. To further investigate fake logins, you would need to check proxy logs.

^{Figure 12} 

To find malicious content faster, check the device’s timeline of when the victim received the validation OTP, not just the time of the URL click. There may be a delay between the click and the validation stage.

 

^{Figure 13} 

^{Figure 14}

Figures 10-14: Illustrate some of the phishing domains discovered during our SharePoint phishing analysis.

Some cases are even more intriguing, as malicious domains are sometimes used in conjunction with genuine ones. Figures 15-17: Show some of the interesting lookalike and deceptive domains from our investigation.

^{Figure 15} 

^{Figure 16}

^{Figure 17} 

Indicators of Compromise (IOCs)

Here are some interesting IOC domains discovered during this investigation:

• ushackagea[.]ru
• revishbos[.]ru
• jessnline[.]vegebit[.]com
• kj[.]vhjvoqrvub[.]com
• documents[.]rescloudofficeshareddrive365[.]com
• int-oracle[.]com
• office[.]int-oracle[.]com

Possible Outcomes Seen Through the Investigation Phase due to SharePoint Phishing

Normal phishing typically involves credential stealing, which attackers later use to infiltrate user accounts. In SharePoint phishing, if an attacker gains access to a victim’s account, they often add malicious Multi-Factor Authentication (MFA) to the user. Previously, attackers used direct MFA additions that were visible to most Blue Teams. Now, attackers are adding authentication methods that are less visible, making it difficult to identify exactly what has been added to the user account. The only way to address this is to remove all MFA methods for that user account.

After MFA addition, we have observed attackers creating malicious inbox rules and forwarding malicious content both inside and outside the organization. The most effective way to reduce the impact of such an attack is to disable the compromised account as soon as the blue team recognizes the attack. This should be followed by resetting the user’s password, removing any malicious MFA, deleting malicious inbox rules, and eliminating any malicious content shared with multiple users. We have also seen situations where attackers invited and created over 100 external user accounts after compromising a single user account, highlighting the severity of attacks conducted through SharePoint.

Remediation Recommendations

If a user is confirmed to be compromised via phishing, the following immediate remediation steps should be taken:

1. Immediately reset the affected user’s password.
2. Check for any malicious MFA additions and remove them if found.
3. Block the initial SharePoint URL and any associated malicious domains.
4. Block and delete the phishing emails.
5. Check for any malicious rules created in the user’s inbox and remove them immediately.
6. The most crucial step is to educate the user. User education remains the best defense against these types of attacks.