Phishing Actor Using XOR Obfuscation Graduates to Enterprise Cloud Storage on AWS

Overview

Proofpoint researchers observed a phishing campaign in late July that continues as of this writing (with certain aspects that were active many months prior), that appears to target specific individuals at a variety of organisations using the branding and email transaction format of DocuSign. The DocuSign phishing email campaign landing pages are hosted at Amazon public cloud storage (S3) which is a fairly uncommon practice among phishing actors monitored by Proofpoint.

While relatively uncommon, Proofpoint has also documented threat actors using other enterprise-class public cloud infrastructure for such purposes, including the recent abuse of Microsoft’s GitHub service and a credential phishing scheme leveraging Microsoft Azure blob storage.

DocuSign Phishing Analysis

Below is a redacted example of the email template using stolen DocuSign branding that the actor sent to a small number of individuals at a variety of companies, with no particular vertical targeting. Visually, it appears as a fairly standard phishing lure for documents pretending to be shared via DocuSign.

While the landing page for the credential phish also convincingly resembles DocuSign in branding and overall format, it is actually a phishing template that has been commonly used over the past few years:

Figure 2: Stolen DocuSign branding and visual elements used in a phishing landing page.

The DocuSign phishing landing page was hosted on Amazon S3, which, as noted, remains fairly uncommon. This particular example was located at:

https://s3.us-east-2.amazonaws [.] com/docusign.0rwlhngl7x1w6fktk0xh8m0qhdx4wnbzz1w/t993zTVQwqXuQLxkegfz1CAUtcrGfe0bRm0V2Cn/eeu69zk7KqAmofMrHr6xrWgrKUoTrOn2BJhhnQg/eAzUroFtr7Gw9JrkWkX9.html

As with many phishing landing pages, a closer examination of the source code reveals some JavaScript encoding. It begins with a large array of hex-encoded strings which, when decoded, appears to include some ciphertext as well as a few strings, and then an eval statement to decode the encoded blob:

Figure 3: Beginning of the encoded phishing landing data array

Figure 4: The decoding eval statement

The fields within the main data array are just hex-encoded on the surface. Proofpoint researchers have observed that the encoding and variable names will often change with each deployment of the landing. It is worth noting that some more recently observed deployments of the kit are doing multiple rounds of this encoding. Below is the hex-decoded content from three different landing pages, demonstrating that actors are putting significant effort into detection evasion.

Figure 5: ASCII content of JavaScript on the phishing landing page.

Near the end of the data array, after decoding the hex to ASCII, we can observe some plaintext strings as well that will be used within the decoding process.

Figure 6: Plaintext strings at the end of the ASCII decoded text block

After this decoding is complete, we are presented with another more typical JavaScript unescape encoding that we see much more commonly in phishing campaigns:

Figure 7: JavaScript unescape encoding

Decoding this leads to another encoding:

Figure 8: Additional encoding

Decoding this leads to the Multibyte XOR obfuscation encoding technique that Proofpoint researchers analysed in the Threat Insight blog entry on “Hiding in Plain Sight: Obfuscation Techniques in Phishing Attacks” in February of 2016:

Figure 9: Multibyte XOR obfuscation encoding

However, in this particular example, the phishing landing was divided into four sections, all using different values to perform this type of encoding.

Figure 10: Four-part XOR Obfuscation encoding of the phishing landing page.

Decoding all four of these sections finally leads us to the raw HTML, in which we are able to observe very typical phishing code. Below is the credential POST URL as well as the contents of the email address drop-down containing multiple webmail providers:

Figure 11: Phishing code for user credentials at webmail providers.

There is also a very typical validation of the email and password fields:

Figure 12: Validation for email and passwords.

Within the cleartext phishing landing, we can see that this kit pulls some remote resources from multiple websites that include “dancelikejoseph” in the domain name. The presence of these DNS / TLS SNI requests in network traffic logs could indicate attempts by users to visit these pages.  

These domains presently have TLS certificates from “Let’s Encrypt” and all appear to have been registered by “phasephaser@yandex.com”.

After trying to get the credentials on this page, if the visitor enters their information on the DocuSign landing page, they will then be redirected to a lookalike of the webmail service they indicated, and another phishing landing will try to steal the credentials for a second time.

Figure 13: Phishing landing page attempting to mimic a Microsoft webmail login.

This page uses the same type of encoding/decoding process as the DocuSign phishing page. Instead of utilizing the classic credential POST, this page example employs AJAX to make the credential POST. The destination of the credentials is the same domain as that used for the DocuSign phishing landing page.

Figure 14: Credential submission using AJAX

At this point, the victim would be redirected to the real office.com at the URL seen above.

Campaign Information

The actor engaging in this activity is not new to hosting on AWS, as we have observed it in similar low-volume campaigns throughout the year. All non-AWS domains have utilized “Let’s Encrypt” TLS certificates, and most appear to be registered with Russian domain registration services. While all phishing was hosted on AWS during this period, in some cases the actor used other public cloud infrastructure to host-specific resources for the landing pages.

Specific campaigns and evolutionary features leading to the present degree of encoding are summarized below:

Figure 16: An earlier iteration of the actor’s initial landing encoding with multibyte XOR; in this case, the multibyte XOR was a single statement

In some instances of Microsoft Office phishing landings, Proofpoint researchers observed the actor trying other encoding techniques as seen below:

Figure 17: Another iteration of encoding used by the observed phishing actor for the initial landing page.

In late June, we saw the first instances of the actor's current iteration of encoding described in this blog.

DocuSign Phishing Campaign Conclusion

Threat actors, and most recently phishers, have been able to evade detection by using well-known and trusted consumer cloud, social networking, and commerce services to host malicious phishing kits. 

Some actors have now graduated from using consumer cloud storage such as Google Drive and Dropbox to more enterprise-class public cloud storage providers such as Amazon Web Services (AWS) and Microsoft Azure, and continue to use various encoding techniques in their landing web page via JavaScript in order to evade detection.

While Amazon itself appears to be responsive and especially vigilant in taking down abusive accounts hosting this type of material, for threat defence defenders should be aware of potentially malicious content on webpages hosted on AWS S3 cloud storage.

Indicators of Compromise (IOCs)

Landing page URLs

Over the course of the most recent campaign we observed the following URLs in use:

Note that these are abbreviated for ease of reading. All URLs will follow a regex in the following format

https://s3.us-east-2.amazonaws [.] com/ *Phrase* [A-Za-z0-9/]{100,}\.html

https://s3.us-east-2.amazonaws [.] com/alan.d0cus1gn
https://s3.us-east-2.amazonaws [.] com/alan.interactive.business.services.
https://s3.us-east-2.amazonaws [.] com/aland0cus.1gn
https://s3.us-east-2.amazonaws [.] com/alanprat.doc.sign
https://s3.us-east-2.amazonaws [.] com/c0nnecticut.d0.cusig.n
https://s3.us-east-2.amazonaws [.] com/c0nnecticut.g0vernment
https://s3.us-east-2.amazonaws [.] com/c0nnecticut.government
https://s3.us-east-2.amazonaws [.] com/connecticut.government
https://s3.us-east-2.amazonaws [.] com/connecticut.government.d0cu
https://s3.us-east-2.amazonaws [.] com/d0cu
https://s3.us-east-2.amazonaws [.] com/d0cu.sign
https://s3.us-east-2.amazonaws [.] com/d0cudig.n
https://s3.us-east-2.amazonaws [.] com/d0cusign
https://s3.us-east-2.amazonaws [.] com/d0cusigned
https://s3.us-east-2.amazonaws [.] com/diarylandseed
https://s3.us-east-2.amazonaws [.] com/docu.s1gn
https://s3.us-east-2.amazonaws [.] com/docus.ign
https://s3.us-east-2.amazonaws [.] com/docusign
https://s3.us-east-2.amazonaws [.] com/docusigned
https://s3.us-east-2.amazonaws [.] com/homecredit.philippines
https://s3.us-east-2.amazonaws [.] com/interactive.business.service
https://s3.us-east-2.amazonaws [.] com/interactivebusiness.services

Prior to publication, Proofpoint notified Amazon of the URLs of the malicious landing pages hosted on their infrastructure for a takedown.

ET and ETPRO Suricata/Snort Signatures

2837889 ETPRO CURRENT_EVENTS AWS S3 Hosted Phishing Landing M1

2837890 ETPRO CURRENT_EVENTS AWS S3 Hosted Phishing Landing M2

2837891 ETPRO CURRENT_EVENTS AWS S3 Hosted Phishing Landing M3