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 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.
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:
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 |
|
February |
DocuSign Microsoft Office |
No |
Local AWS instance storage.googleapis.com |
whistleobohemian [.] info |
|
Early March |
ShareFile (Figure 15) DocuSign Microsoft Office |
No |
Microsoft Azure |
whistleobohemian [.] info |
|
Late March to early April |
ShareFile DocuSign Microsoft Office |
No |
dataanarchyofsons [.] site |
whistleobohemian [.] info |
|
Early to mid-April |
ShareFile DocuSign Microsoft Office Chalbai template (produced by a prolific reseller of general-purpose phishing templates) |
No |
dataanarchyofsons [.] site |
postmasterpledge [.] ru |
|
Late April through mid-May |
DocuSign |
No |
dataanarchyofsons [.] site |
postmasterpledge [.] ru |
|
Mid-June |
ShareFile DocuSign Microsoft Office |
Yes - simplified version of current encoding; Figure 16 and 17 |
dataanarchyofsons [.] site |
dancelikejoseph [.] xyz |
|
Late June through August |
DocuSign Microsoft Office |
Yes - current iteration as described in this blog |
300spartans [.] dancelikejoseph [.] xyz and dancelikejoseph [.] site |
dancelikejoseph [.] xyz and xplicate [.] dancelikejoseph [.] info |
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.
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, defenders should be aware of potentially malicious content on webpages hosted on AWS S3 cloud storage.
Indicators of Compromise (IOCs)
|
IOC |
IOC Type |
Description |
|
300spartans [.] dancelikejoseph [.] xyz |
Domain |
Loads up resources |
|
xplicate [.] dancelikejoseph [.] info |
Domain |
Stolen credentials sent here |
|
dancelikejoseph [.] site |
Domain |
Loads up resources |
|
phasephaser@yandex.com |
|
Registrant |
|
185.255.79 [.] 118 |
IP |
Hosting |
|
194.58.112 [.] 174 |
IP |
Hosting |
|
postmasterpledge [.] ru |
Domain |
Historical. Stolen credentials sent here (04/19-05/19) |
|
dataanarchyofsons [.] site |
Domain |
Historical. Loaded up resources (03/19-05/19) |
|
whistleobohemian [.] info |
Domain |
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