Email Spoofing: Abusing the SharePoint REST API

Introduction

Famously, Microsoft loves to make out that they love developers (developers, developers, developers). Maybe it’s this love of developers that spurred them to implement a generous range of features into their SharePoint RESI API, with the intention of enabling custom web-apps to extend default functionality.

One day, I was looking through the documentation for the PnP SharePoint Library (as you do), and I noticed a feature labelled ‘sendEmail’. On closer inspection, this feature allows you to send an email to anybody inside your Microsoft 365 tenancy with an arbitrary sender ‘name’ (the actual sending address is no-reply@sharepointonline.com), subject and HTML-enabled body.

Turning Theory into Practice

To call the PnP library function, I created a SharePoint custom web part project. The function to send the email is called with the simple code below:

const sendEmail = async () => {
    // Make request to REST API to send email
    await sp.utility.sendEmail({
        To: ["EMAIL HERE"],
        Subject: "SharePoint REST API Fun",
        Body: `
            <h1>This could be a convincing phishing email!</h1>
            <br><br>
            <button type="button">malicious payload here</button>
        `,
        AdditionalHeaders: {
        "content-type": "text/html"
        },
        // Optional. If blank it will display name of SharePoint Group.
        // Can spoof any name in the tenancy.
        From: "EMAIL HERE"
    });
};

Many SharePoint sites allow you to access something called a ‘workbench’ to test locally hosted web-apps. You can access this by navigating to a SharePoint site that you are part of, and entering the URL:

[YourTenancy].sharepoint.com/sites/[YourSite]/_layouts/15/workbench.aspx Run the ‘gulp serve’ task to locally host the web-app, then trigger the function.

This results in an email sent to the ‘to’ address, and conveniently does not get picked up by any of Microsoft’s spam filtering as a bonus.

In the above screenshot, I used my own address in both the sending and recipient address.

Conclusion

With the right payload, I expect this technique could be quite effective as part of a targeted phishing campaign, or simply for workplace mischief. But consider - with this you can send emails from no-reply@sharepointonline.com—which is coincidentially the same address security alerts originate from—to SharePoint admins.

In any case, if I was a SharePoint admin, this is something I would investigate means to prevent on my tenancy.