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 organizations using the branding and email transaction format of DocuSign. The 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.


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:

Figure 1: Malicious email template sent using stolen DocuSign branding.

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 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 encoding technique that Proofpoint researchers analyzed in the Threat Insight blog entry on “Hiding in Plain Sight: Obfuscation Techniques in Phishing Attacks” in February of 2016:

Figure 9: Multibyte XOR 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 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 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 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:

Timeframe (2019)

Phished credentials/ abused brands

Landing pages encoded

Host for page resources

Stolen credentials receiving address



Microsoft Office


Local AWS instance


whistleobohemian [.] info

Early March

ShareFile (Figure 15)


Microsoft Office


Microsoft Azure

whistleobohemian [.] info

Late March to early April



Microsoft Office


dataanarchyofsons [.] site

whistleobohemian [.] info

Early to mid-April



Microsoft Office

Chalbai template (produced by a prolific reseller of general-purpose phishing templates)


dataanarchyofsons [.] site

postmasterpledge [.] ru

Late April through mid-May



dataanarchyofsons [.] site

postmasterpledge [.] ru




Microsoft Office

Yes – simplified version of current encoding; Figure 16 and 17

dataanarchyofsons [.] site

dancelikejoseph [.] xyz

Late June through August


Microsoft Office

Yes – current iteration as described in this blog

300spartans [.] dancelikejoseph [.] xyz and dancelikejoseph [.] site

dancelikejoseph [.] xyz and xplicate [.] dancelikejoseph [.] info

                                                                                                                                                                                                                                                                                                                                                                                                      Figure 15: Phishing landing for ShareFile, March 2019

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.


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, defenders should be aware of potentially malicious content on webpages hosted on AWS S3 cloud storage.

Indicators of Compromise (IOCs)


IOC Type


300spartans [.] dancelikejoseph [.] xyz


Loads up resources

xplicate [.] dancelikejoseph [.] info


Stolen credentials sent here

dancelikejoseph [.] site


Loads up resources




185.255.79 [.] 118



194.58.112 [.] 174



postmasterpledge [.] ru


Historical. Stolen credentials sent here (04/19-05/19)

dataanarchyofsons [.] site


Historical. Loaded up resources (03/19-05/19)

whistleobohemian [.] info


Historical. Stolen credentials sent here (02/19-04/19)

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

Subscribe to our Blog & Newsletter!

Join our mailing list to receive the latest news and updates from our team. We will give you the latest tech articles and updates on our new products!

You have Successfully Subscribed!

Netsafe Client Support Portal

For current clients to communicate their IT issues

Submit a Ticket

Having a technical issue? Submit a ticket to our helpdesk here and a tech will be on your case.

Establish a Remote Connection

Share your screen with our IT helpdesk techs so we can diagnose your issues.

Check the Status of your Support Ticket

Log in to our helpdesk portal to check the status of your ticket.