“You’re Invited!” to Phishing Links Inside .ics Calendar Attachments

Posted On June 25, 2020 By Cofense In SEG Misses, Microsoft 365, Phishing, Phishing Defense Center, Proofpoint /   No Comments

Phishes Found in Environments Protected by SEGs

Proofpoint
Microsoft 365

By Ashley Tran, Cofense Phishing Defense Center

Every day threat actors find more and more ingenious ways to deliver phishing emails to end users. From direct attachments to using third party document hosting sites and… calendar invitations? The Cofense Phishing Defense Center (PDC) has unearthed a new phishing campaign in multiple enterprise email environments protected by Proofpoint and Microsoft that delivers .ics calendar invite attachments containing phishing links in the body. It’s assumed that the attackers believe stuffing the URL inside a calendar invite would help avoid automated analysis.

Figure 1: Email Body

The subject of this phish is “Fraud Detection from Message Center,” reeling in curious users. The sender display name is Walker, but the email address appears to be legitimate, possibly indicating a compromised account belonging to a school district. Cofense observed the use of several compromised accounts used to send this campaign. Using a compromised real account originating from Office 365 allows the email to bypass email filters that rely on DKIM/SPF.

The story in this phish is a version of a classic lure “suspicious activity on the user’s bank account.” This attachment, however, doesn’t jibe with the ruse considering it’s a calendar invite. A more fitting lure would have been something like “I attached a meeting invite; can you please attend?” Maybe this attacker flunked out of Internet bad guy school.

Figure 2 shows what the calendar invite looks like when opened. Note that it’s hosted on the legitimate Sharepoint.com site, an issue that continues to be problematic for Microsoft.

Figure 2: Calendar invite (.ics) Attachment

Upon clicking the link in the fake invitation, a relatively simple document opens with yet another link to follow, as seen in Figure 3 below:

Figure 3: Phishing Page

If the victim follows that link, they are redirected from sharepoint.com to a phishing site hosted by Google. Clicking anywhere on the document then redirects users to a bogus phishing page seen in Figure 4.

Figure 4: Phishing Page

As shown in Figure 4, the final phishing page users are directed to is hosted on:

hXXps://storage[.]googleapis[.]com/awells-putlogs-308643420/index[.]html

This is not the first time threat actors have utilized “storage[.]googleapis[.]com” to host their phish. In fact, it is becoming increasingly common thanks to its ease of use as well as the built-in SSL certificate the domain comes with which adds the “trusty” padlock to the side of its URL.

Once redirected here from the previous SharePoint page, users are presented with a convincing Wells Fargo banking page, as seen in Figure 4. This page asks for a variety of Wells Fargo account information including login details, PIN and various account numbers along with email credentials. At surface value, it may seem excessive to request this level of information, but under the pretense of “securing” one’s account, it may not appear to be so much.

Should users provide all the requested information, they will finally be redirected to the legitimate Wells Fargo login page to make the user believe they have successfully secured their account and nothing malicious has taken place.

And to think, all of this from a simple calendar invite. It goes to show, users and their security teams must constantly maintain phishing awareness training and remain vigilant as threat actors continue to find new ways to slip past gateways right into inboxes.

Network IOCs IPs
hXXps://mko37372112-my[.]sharepoint[.]com/:b:/g/personal/admin_mko37372112_onmicrosoft_com/ERto2NKXu6NKm1rXAVz0DcMB431N0n1QoqmcqDRXnfKocA 172[.]217[.]13[.]240
hXXps://storage[.]googleapis[.]com/awells-putlogs-308643420/index[.]html 13[.]107[.]136[.]9
All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks. Any observations contained in this blog regarding circumvention of end point protections are based on observations at a point in time based on a specific set of system configurations. Subsequent updates or different configurations may be effective at stopping these or similar threats.
The Cofense® and PhishMe® names and logos, as well as any other Cofense product or service names or logos displayed on this blog are registered trademarks or trademarks of Cofense Inc.
Read More

Practice Makes Perfect

Posted On June 19, 2020 By Cofense In SEG Misses, Phishing, Phishing Defense Center, Proofpoint /   No Comments

Phishes Found in Environments Protected by SEGs

Proofpoint

By Noah Mizell and Kyle Duncan, Cofense Phishing Defense Center

The Phishing Defense Center (PDC) has discovered two distinct phishing campaigns found in environments protected by Proofpoint that spoof Twitter by using registered fraudulent domains.

Threat actors utilize numerous attacks throughout their careers; others stick with tried-and-true attacks proven to be effective. The latter is the case in the following scenarios with these attacks coming from the same campaign based on similar tactics: registered fraudulent domains, specifically tailored sender emails, and nearly identical phishing emails and pages.

Figures 1-2: First Iteration of Attack

The subject of the phishing email is “Security alert: new or unusual login” followed by the sender email “verify[@]tlwtttierz[.]com”.  Although it is obviously not Twitter.com, it is similar to the actual name, that users may overlook due to the urgent tone.  However, users must be careful when reacting in haste, as threat actors seek to turn quick thinking against targets to steal their credentials.

The body of the email looks like a legitimate Twitter notification. Similar font type, layout, the familiar Twitter logo showing – nothing appears to be amiss. Reading the contents of the message though, users may be surprised to see there has been a new login from a new device from Spain! Supposing the user is not connected to this location, this is likely to be cause for concern. But worry not, “Twitter” has sent a handy link to secure the account in question.

Hovering over the link “Secure my account”, it shows the redirect is:

twltt%C4%99r[.]com

However once clicked, users are sent to a URL that looks like “Twitter.com”:

twlttęr[.]com

For this attack, the threat actor uses punycode to make the final URL look like “Twitter.com”. The use of punycode has been noted as an extremely easy way to make phishing URLs look very similar to the site they are impersonating. Punycode essentially takes words that cannot be written in ASCII and puts them into an ASCII encoding that browsers will understand.

For example, the URL to which the attack directs does not actually include a letter ‘e’ ASCII would understand; it uses the hexadecimal encoding ‘C4 99’ for a character that can be seen in the first URL. When the browser gets this encoding, twltt%C4%99r, it renders the string, %C4%99, to the Polish letter ę, which just so happens to look very similar to the ‘e’ we’re used to seeing in the legitimate Twitter.com URL.

Figure 3-4: Second Iteration of Attack 

Although this second attack may appear to be the same one from Figures 1-2, it is an improvement – the threat actor made minor tweaks to enhance its believability.

The subject of the email has changed: “New login from Safari on iPhone”. Like the previous attack’s subject, this is also meant to evoke a sense of urgency. This time, however, the sender email is not the obviously wrong “verify[@]tlwtttierz[.]com” but rather a more subtle “verify[@]mobiles-twitter[.]com”.

Although this email looks like an exact copy of the last attack, the threat actor added a small yet impactful detail: at the bottom they specifically reference the recipient: “We sent this email to _____”. Most users have been told to look out for generic “Dear sir/ma’am” terms in emails. If the email is not specifically addressed to the recipient, it is likely a mass mailing, perhaps with malicious intent. For most users, personalization adds legitimacy.

Like in the last attack, the threat actor included disclaimer under this hyperlink to “help” users know this is a legitimate email from Twitter. Both emails mention the display of a padlock to mean a secure and legitimate site. This padlock only shows that the website is using an active SSL certificate to signify encrypted communications between the user and the web server.  However, contrary to widespread belief, a padlock does not equal safe. The attacker is simply trying to erase any doubts about the site.

The final change of this second attack can be seen when hovering over the “Confirm my identity” hyperlink and finding a new fraudulent domain:

mobiles-twitter[.]comThis domain appears to be more legitimate than the one from the first attack, as it contains the word “twitter”. Considering mobile[.]twitter[.]com leads to the legitimate mobile version of Twitter, this “mobiles-twitter[.]com” was more than likely supposed to be a dupe.

Perhaps this attack may have intended to typosquatt to lure victims the attacker never initially targeted. Typosquatting, or URL hijacking, relies on users making small mistakes when typing a URL, whether adding a period where there was a dash or misspelling the domain. The attacker has registered that mistakenly typed out URL, so should anyone accidentally visit it they will be subject to whatever is on that page.

Figure 5: Phishing Page

As seen in Figure 5 above, users are presented with a login page for either attack, however this one is specifically for the phish located at twlttęr[.]com. This page is made to look extremely close to the current Twitter login page that can be seen on a desktop browser. The obvious difference between this phishing attack and the legitimate Twitter login page would be the URL, with its unusual letter ‘ę’, and the atypical tab icon.

This is just the first iteration of the threat actor’s attack. The second attack has an even more dismissible body email and a URL that looks closer to a legitimate URL. Regardless, it is no secret that users should pay close attention to the URLs in their address bar.

 

Network IOCs  IPs  
hXXps://mobiles-twitter[.]com/login/ 70[.]37[.]100[.]82
hXXps://twltt%C4%99r[.]com 70[.]37[.]100[.]82
hXXps://xn--twlttr-04a[.]com/login/ 70[.]37[.]100[.]82
hXXps://t[.]co/U6DLQ2B1xC

 

All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks. Any observations contained in this blog regarding circumvention of end point protections are based on observations at a point in time based on a specific set of system configurations. Subsequent updates or different configurations may be effective at stopping these or similar threats.
The Cofense® and PhishMe® names and logos, as well as any other Cofense product or service names or logos displayed on this blog are registered trademarks or trademarks of Cofense Inc.
Read More

Zoom Phish Zooming Through Inboxes Amid Pandemic

Posted On June 10, 2020 By Cofense In SEG Misses, Cisco IronPort, Internet Security Awareness, Microsoft 365, Phishing, Phishing Defense Center, Proofpoint /   No Comments

Phishes Found in Environments Protected by SEGs

Proofpoint
Microsoft ATP
Microsoft EOP
Cisco IronPort

By Ashley Tran, Cofense Phishing Defense Center

The Cofense Phishing Defense Center (PDC) has observed a new phishing campaign that acts as a Zoom video conference invitation to obtain Microsoft credentials from users.

As noted in numerous other articles posted by Cofense, it is no secret this pandemic has changed the threat landscape. From emails to employees regarding safety guidelines to the latest news from the WHO or CDC on Coronavirus cases in the area- threat actors have done it all to make the most of this situation, especially targeting remote workers. Within that group of remote workers there are users who are unfamiliar with teleconferencing and the emails that come with using the service. Some users may not have the best home office set up and work on monitors that barely afford them a proper view, making it difficult to look over these emails closely. The attack covered below is specifically aimed toward those users.

Figure 1– Email Bodies

For this attack, users are informed of an invite to a video conference from what appears to be “Zoom Video Communications” which is followed by either as noted in Figures 1-2. For now, this all appears to be in order, however looking more closely at the senders, there are barely noticeable typos- communcations missing an ‘i’, confrence missing an ‘e’. While this may seem like just an innocuous mistake, it’s in fact a carefully crafted scheme.

Mere hours before sending this email, the threat actors registered the domains zoomcommuncations.com and zoomvideoconfrence.com, as noted in s 3-4.

Figure 2-3: Email Body

When visiting either domain, it may appear to be a German site speaking on different Lasik treatments and surgery options. However, this is merely a cover for its true purpose of helping send malicious emails while impersonating teleconferencing giant Zoom.

The email itself is reminiscent of a legitimate Zoom communication- the blue Zoom logo, a vague mention of a video conference for users to join and a link for them to review said invitation; it’s inconspicuous enough and mostly free of the grammatical mistakes phish often contain.

Hovering over the “Review Invitation” the link shown is:

hxxps://r[.]smore[.]com/c?u=pastell[.]in/ca07-b36n5-65m-c53b-o26v-62h-e79-t56e-c44=REDACTED[@]company[.]com

For this attack, the threat actor used a redirector link from Smore, a newsletter creation and distribution website. This is not the first time threat actors have used a legitimate online service’s personal redirect links to pilot users to malicious sites. In this case, this redirect link, once clicked, navigates users to:

hxxp://www[.]pastell[.]in/ca07-b36n5-65m-c53b-o26v-62h-e79-t56e-c44

Which then redirects to the final page:

hxxps://logonmicrosftonlinezoomconference[.]azureedge[.]net/

For this attack, the threat actor has utilized Microsoft’s Azure is used to host the phishing domain, but this is not a new tactic. Threat actors flock to these domain hosting services due to some of the perks it offers. For this service, a free SSL certificate comes with any website hosted through it which adds a padlock next to the URL in the address bar, most people incorrectly assumes this indicates a site is legitimate. Another benefit of Azure is the customization option for the subdomain, allowing a URL to mimic or at least appear as a legitimate URL for the service attacks are attempting to impersonate. In this case, the subdomain is “logonmicrosftonlinezoomconference”, with all the keywords most users would expect to see in a Zoom email that goes to a Microsoft login page: “logon microsoft” and “zoom conference”. With both a padlock in the address bar along with relevant names displayed, this attack becomes less noticeable to most users.

Figure 4: Phishing Page

Figure 5 shows the phishing page users are presented with should they make it this far. The page is a generic Microsoft phish with an accompanying URL which, once again, seems to legitimize the phish to users.

The request is simple: “Sign in to Zoom with your Microsoft 365 account.” At face value, this seems like a completely reasonable use of credentials. And since Zoom allows for users to login in via SSO and most companies have linked Microsoft credentials to the platform, some users may even be familiar with Microsoft helping to access their Zoom account.

Meanwhile, with the user’s email appended in the URL, it in turn pre-populates the username field with that information, leaving only the password left for the user to provide.

Network IOC  IP 
hxxps://r[.]smore[.]com/c?u=pastell[.]in/ca07-b36n5-65m-c53b-o26v-62h-e79-t56e-c44?e5=REDACTED[@]company.com 52[.]27[.]29[.]106
hXXp://www[.]pastell[.]in/ca07-b36n5-65m-c53b-o26v-62h-e79-t56e-c44 209[.]159[.]154[.]74
13[.]107[.]246[.]10
hXXps://logonmicrosftonlinezoomconference[.]azureedge[.]net/ 13[.]107[.]246[.]10
All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks. Any observations contained in this blog regarding circumvention of end point protections are based on observations at a point in time based on a specific set of system configurations. Subsequent updates or different configurations may be effective at stopping these or similar threats.
The Cofense® and PhishMe® names and logos, as well as any other Cofense product or service names or logos displayed on this blog are registered trademarks or trademarks of Cofense Inc.
Read More

Phishers Cast a Wider Net in the African Banking Sector

Posted On May 29, 2020 By Cofense In SEG Misses, Microsoft 365, Phishing, Phishing Defense Center, Proofpoint /   No Comments

Phishes Found in Environments Protected by SEGs

Proofpoint
Microsoft 365

By Elmer Hernandez, Cofense Phishing Defense Center (PDC)

The Cofense Phishing Defence Center (PDC) has uncovered a wide-ranging attempt to compromise credentials from five different African financial institutions. Posing as tax collection authorities, adversaries seek to collect account numbers, user IDs, PINs and cell phone numbers from unsuspecting customers.

One such email, which was found in environments protected by Proofpoint and Microsoft, alleges to come from the South African Revenue Service’s (SARS) eFiling service. It claims a tax return deposit of R12,560.5 (South African Rands), approximately $700 USD, has been made to the user’s account and urges them to click on their financial institution in order to claim it. The real sender of the email, however, appears to be a personal Gmail address that may have been created or compromised by the adversaries.

Figure 1 – (Partial) Email Body

As seen in Figure 2, it is erroneously assigned a score of zero in Proofpoint’s “phishscore” metric.

Figure 2 – Proofpoint Header

Dragging and Dropping a Net

Each of the images embedded in the email corresponds to a different bank. Clicking on any of these will take the user to a spoofed login portal corresponding to the selected bank. The spoofed banks include ABSA, Capitec, First National Bank (FNB), Nedbank and Standard Bank, all of which are based in South Africa. The lookalike sites are located at 81[.]0[.]226[.]156 and hosted by Czech hosting provider Nethost. It should be noted that, at the time of analysis, only the site for Standard Bank was unavailable. Figures below -6 show the phishing portals imitating each bank.

Figure 3 – ABSA

Figure 4 – Capitec

Figure 5 – FNB

Figure 6 – Nedbank

All spoofed portals were created using Webnode, a website building service known for its friendly drag and drop features. Despite this ease of use, adversaries have kept things rather simple, as all portals are basic forms with a few or no images. The portals ask for a variety of personal information, including account numbers, passwords, PINs and even cell phone numbers.

Adversaries can access all entries directly from the form itself. They can also receive notifications to an email address of their choosing every time a submission is made; the Gmail account used to send the phishing email may also be where adversaries are notified of each and every new victim. Webnode also allows the export of form submission data in xml and csv formats.

Webnode therefore is an optimal way to store and retrieve stolen user data. There is no need for additional infrastructure, nor to compromise any third parties. As in the case of the Standard Bank portal, the risk of discovery and subsequent closure of spoofed sites means adversaries can lose access to any unretrieved information. However, this risk seems to be offset by the ease with which replacement spoofed sites can be created.

IOCs:

Malicious URLs:

  • hxxps://absa9[.]webnode[.]com
  • hxxps://capitec-za[.]webnode[.]com
  • hxxps://first-national-bnk[.]webnode[.]com
  • hxxps://nedbank-za0[.]webnode[.]com
  • hxxps://standardbnk[.]webnode[.]com

Associated IPs:

  • 81[.]0[.]226[.]156

 

How Cofense Can Help:

Easily consume phishing-specific threat intelligence in real time to proactively defend your organization against evolving threats with Cofense Intelligence™. Cofense Intelligence customers were already defended against these threats well before the time of this blog posting and received further information in the Active Threat Report 38237 and a YARA rule.

All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks. Any observations contained in this blog regarding circumvention of end point protections are based on observations at a point in time based on a specific set of system configurations. Subsequent updates or different configurations may be effective at stopping these or similar threats.
The Cofense® and PhishMe® names and logos, as well as any other Cofense product or service names or logos displayed on this blog are registered trademarks or trademarks of Cofense Inc.
Read More

MFA Bypass Phish Caught: OAuth2 Grants Access to User Data Without a Password

Posted On May 18, 2020 By Cofense In SEG Misses, Microsoft 365 EOP, Phishing, Phishing Defense Center, Symantec /   No Comments

SEG Misses

Symantec
Microsoft 365 EOP

By Elmer Hernandez, Cofense Phishing Defense Center (PDC)

The Cofense Phishing Defense Center (PDC) uncovered a phishing tactic that leverages the OAuth2 framework and OpenID Connect (OIDC) protocol to access user data. The phish is not a typical credential harvester, and even if it was, Multi-Factor Authentication (MFA) wouldn’t have helped. Instead, it attempts to trick users into granting permissions to a rogue application. This is not the first time the tactic has been observed, but it’s a stark reminder that phishing isn’t going to be solved by Multi-Factor Authentication.

Using the lure of a Q1 bonus, the email is crafted to appear to be a normal invite to a SharePoint hosted file. The prospect of receiving an increase to their salary is an effective lure that can lead users to fall prey.

Figure 1 – Email Body

After clicking on the link, users are taken to the legitimate Microsoft Office 365 login page at https://login.microsoftonline.com (Figure 2). However, if one inspects the URL in its entirety, which average users are unlikely to do, a more sinister purpose is revealed.

Figure 2 – O365 Login Page

Anatomy of a URL

First, a quick primer: applications that want to access Office 365 data on behalf of a user do so through Microsoft Graph authorizations. However, they must first obtain an access token from the Microsoft Identity Platform. This is where OAuth2 and OIDC come in. The latter is used to authenticate the user who will be granting the access, and if authentication is successful, the former authorizes (delegates) access for the application. All of this is done without exposing any credentials to the application.

Figure 3 – Entire URL

The response_type parameter denotes the type of access being requested to the Microsoft Identity Platform /authorize endpoint. In this case, both an ID token and an authorization code (id_token+code) are requested. The latter will be exchanged for an access token which will, in turn, be presented by the application to Microsoft Graph for data access.

Next, the redirect uri parameter indicates the location to which authorization responses are sent. This includes tokens and authorization codes. As we can see, responses are sent to hxxps://officehnoc[.]com/office, a domain masquerading as a legitimate Office 365 entity, located at 88[.]80[.]148[.]31 in Sofia, Bulgaria and hosted by BelCloud.

Moving on, the scope parameter shows a list of permissions the user gives to the application (note “%20” represents a blank space). These allow the application to read (read) and/or modify (write) specific resources for the signed in user. If the “All” constraint is present, permissions apply for all such resources in a directory.

For example “contacts.read” enables the application to read only the user’s contacts, whereas “notes.read.all” allows it to read all OneNote notebooks the user has access to, and “Files.ReadWrite.All” to both read and modify (create, update and delete) all files accessible to the user, not only his or her own.

If the attackers were successful, they could grab all the victims’ email and access cloud hosted documents containing sensitive or confidential information. Once the attacker has sensitive information, they can use it to extort victims for a Bitcoin ransom. The same permissions can also be used to download the user’s contact list to be used against fresh victims. Using the address book and old emails would allow the attacker to create hyper-realistic Reply-Chain phishing emails.

Perhaps most concerning however is “offline_access” As access tokens have an expiration time, this permission allows the application to obtain refresh tokens, which can be exchanged for new access tokens. Therefore, users need only to authenticate and approve permissions once to potentially enable indefinite access to their data.

Finally, we find openid and profile which are technically scopes in themselves; openid indicates the application uses OIDC for user authentication, while profile provides basic information such as the user’s name, profile picture, gender and locale among others. This information, known as claims, is sent to the application in the ID token issued by the /authorize endpoint.

After signing in, the user will be asked to confirm one last time that he or she wants to grant the application the aforementioned permissions. If users fail to act, it will be up to domain administrators to spot and deal with any suspicious applications their users might have misguidedly approved.

The OAuth2 phish is a relevant example of adversary adaptation. Not only is there no need to compromise credentials, but touted security measures such as MFA are also bypassed; it is users themselves who unwittingly approve malicious access to their data.

Network IOC IP
hxxps://officehnoc[.]com:8081/office 88[.]80[.]148[.]31

 

How Cofense Can Help

Visit Cofense’s Remote Work Phishing Infocenter to stay up to date as threats evolve. Our site is updated with screenshots of real phish that have evaded secure email gateway detection and other helpful resources so you can help keep your organization protected.

All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks. Any observations contained in this blog regarding circumvention of end point protections are based on observations at a point in time based on a specific set of system configurations. Subsequent updates or different configurations may be effective at stopping these or similar threats.
The Cofense® and PhishMe® names and logos, as well as any other Cofense product or service names or logos displayed on this blog are registered trademarks or trademarks of Cofense Inc.
Read More

COVID Relief Phishing Emails: A Not So Relieving Tax Relief Email

Posted On May 8, 2020 By Cofense In SEG Misses, Microsoft 365 EOP, Phishing, Phishing Defense Center, Proofpoint /   No Comments

SEG Misses

Proofpoint
Microsoft 365 EOP

By Ashley Tran, Cofense Phishing Defense Center

The Cofense Phishing Defense Center (PDC) has observed a new phishing campaign that aims to harvest a variety of email credentials specifically from United States citizens.

Countries all around the world are providing relief programs to their citizens to help alleviate the financial strain as a result of the COVID-19 pandemic. This threat actor, however, targets US relief efforts and the citizens who need it most. This email campaign uses the logo of the Internal Revenue Service (IRS) to bolster its credibility.

Figure 1: Email Preview

The threat actor made both the subject and sender information eye catching, as seen in Figure 1. The email appears to be from ‘IRS GOV’ regarding the subject “Tax Relief Fund,” which would be enough to gain the attention of anyone, especially those who may not have received their relief or need more. Upon clicking into the email, users are presented with the following message, as seen in Figure 2 below.

Figure 2-3: Email Body

Despite the image missing from this email sample, assumed to once have been a DocuSign logo based on the image description, the email may appear legitimate at first glance. The IRS has sent a secure document via DocuSign along with a security code to view it, but it must be used soon as it will “expire.” The email is also marked “High Importance.”

A closer look at the body of the email reveals many warning signs this email is a phish. Anyone acquainted with DocuSign would know this is not what an invitation from the service looks like. Not to mention there is odd spacing and capitalization found in the text – atypical for professional emails. There is also mention of a security code that must be used “before expiration,” a common social engineering tactic used to illicit a sense urgency.

The link found in the email, “View Shared Folder,” redirects users to the phishing site located at:

hxxp://playdemy[.]org/office/doc-new

Figures 4-5: Phishing Page and Confirmation Page

Figures 4-5 are examples of the first page users will see upon navigating through the link found in the email. The page is a simple DocuSign page prompting for the user’s email address in order to access the promised document. Visually there aren’t many differences compared to DocuSign’s website, other than the incorrect URL displayed in the address bar. However, the threat actor may have intentionally used a .org-based domain to make it appear safe, as many end users have heard .org top-level domains are “secure.”

Should a user proceed to enter their email address on this page, they are prompted once again to verify the information before being redirected to the next step of this attack.

Figures 6-7: AOL login page

The next step involves redirecting users to a phishing page based on their email provider. In Figures 6-7 above, we used a dummy AOL email and were redirected to an AOL phish. The attacker’s AOL login page rivals the look and feel of AOL’s — the only real difference is the incorrect URL in the address bar. The email entered in the first step is already pre-filled as well. This same occurs with other email providers inputted into the first step of the attack. Figures 8-10, for example, show the Gmail phish that users are redirected to if that was the email provider they entered.

Figures 8-10: Alternative Gmail Phish

Should a user enter an email address to proceed this far, the threat actor has made sure to ask for further compromising information, as seen in Figure 10: a recovery number or recovery email address per their back-up login information.

Figure 11: Final Destination

Regardless of the email address, and should the user enter this information, users are then redirected to an unexpected document; in lieu of the promised “Tax Relief Fund,” they see a completely unrelated academic paper hosted on Harvard Business School’s website. This is a common tactic, designed to confuse users into thinking there is nothing amiss, that perhaps this was a mistaken exchange or they received the wrong document in error and must wait for further contact.

Further analysis of the website utilized for this attack yielded further information on the attack and the actors behind it.

Figure 12: Open Directory

Upon navigating to the main domain, as shown in Figure 12, an open directory appears. While the file Chetos.php is password protected at present, the file 039434.php exposes a greater security threat that can be observed in Figure 13, a web shell.

Figure 13: WebAccess Shell

The beginnings of a malicious web shell start with an attacker methodically installing the malicious script for the shell on the targeted site, either by SQL injection or cross-site scripting. From there the web shell is utilized by attackers to maintain persistent access to a compromised website without having to repeat all the work of exploiting the same vulnerability they used the first time – generally, a backdoor. They can remotely execute commands and manage files that they abuse to carry out their attacks, such as a phishing attack.
As observed in Figure 13, investigation of the shell reveals files from the open directory are displayed, last modified 2020-04-24 by “owner/group” “njlugdc”, otherwise known as the attacker. The real guts of this attack, however, can be found within the directory path office/doc-new seen in Figure 14.

Figure 14: office/doc-new Directory

Within the directory are the many steps in what appears to be a simple phish. There are multiple email branded folders such as “a0l”, “earthl1nk”, “gma1l,” all of which help the threat actor target email clients. Each of these email branded folders host a phish that is specifically tailored to that brand, allowing for a more “authentic” experience that lull users into a sense of security.

Figure 15: Code Behind the Attack

Figure 15 demonstrates the code behind the attack that sanitizes user input to determine which of these phish a user is redirected to, along with the associated email brand logo to display during the redirect process.

Figure 16: Threat Actor Emails Exposed

Within the files contained in this web shell, the threat actor’s emails are displayed. Figure 16 shows the code of the Email.php file and information exfiltrated from users during the phishing attack that are sent to:
techhome18[@]gmail[.]com
we.us1[@]protonmail[.]com

Although the identity of the attacker behind this IRS phish is unknown, it is evident they took care to carefully craft this attack and chose to exploit a current event that is closely followed by Americans in an attempt to successfully steal as many log-in credentials as possible.

Network IOC IP
hxxp://playdemy[.]org/office/doc-new 206[.]123[.]154[.]15

 

 

All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks. Any observations contained in this blog regarding circumvention of end point protections are based on observations at a point in time based on a specific set of system configurations. Subsequent updates or different configurations may be effective at stopping these or similar threats.
The Cofense® and PhishMe® names and logos, as well as any other Cofense product or service names or logos displayed on this blog are registered trademarks or trademarks of Cofense Inc.
Read More

Phishers Continue to Spoof WebEx

Posted On May 7, 2020 By Cofense In SEG Misses, Cisco IronPort, Microsoft 365 EOP, Phishing, Phishing Defense Center /   No Comments

Phishes Found in Environments Protected by SEGs

Microsoft 365 EOP
Cisco Ironport

By Kaleb Kirk, Cofense Phishing Defense Center

Last month, the Cofense Phishing Defense Center (PDC) observed a new phishing trend wherein threat actors spoofed WebEx pages to harvest Office365 (O365) credentials. Since the posting of the original blog, the PDC has seen an increase in the number of similarly themed WebEx phishing attacks, yet another example of attackers leveraging the rapid shift to remote work in light of COVID-19 concerns. As many organizations and their workforce are increasingly dependent on remote working tools and solutions, reducing the attack surface (the number of different approaches a threat actor can use to enter or extract data) of such online platforms and services is becoming even more critical.

Attackers know this and are constantly looking at ways to circumvent detection by secure email gateways and position themselves between users and legitimate services. The WebEx phishing campaign is a prime example, slipping past email protection to dupe users into providing their credentials out of fear they will be unable to use the service and perform their job otherwise.  It’s therefore not a surprise the PDC has seen an increase in phishing attacks that spoof legitimate, business critical services.

While this blog focuses on a new phishing campaign imitating WebEx, this style of attack can and has taken multiple forms, mimicking many different legitimate web services. Luckily however, once an end user knows some of the telltale signs,  it’s often easy to identify what is truly legitimate and what is fake.

Figures 1-2: Email Body

Upon an initial glance, this email may appear innocuous enough. It has the look and format one would likely expect when receiving an email from Cisco. The style is professional, the layout of the email isn’t mangled or chaotic, and it appears legitimate – an intentional and easy tactic to pull off. All the threat actor required was a real WebEx email to copy from in order to duplicate the style and alter select elements for nefarious purposes. The sender address appears to come from WebEx. However, this is what is known as the “friendly” from address – while the recipient sees the displaying address, which appears to be authentic, the email headers reveal a very different story. The problem with a “friendly” sender address is that it is easily spoofed by attackers; it’s a well-known, simple trick designed to convince the recipient that an email is legitimate.

Looking beyond simple aesthetics, however, other indicators of phishing are evident. The subject line indicates there is an issue with SSL certificates that requires the user to sign in and resolve. This is referenced further in the body of the email, providing a sense of legitimacy and enticing them to open the email and read it.

The wording of the email also employs scare tactics that are prevalent in phishing attacks. The recipient is informed there is a problem that has caused their service to become deactivated and the user must log-in and authenticate by clicking the link. Verbiage like this is often used to coerce the end user into clicking on a link or attachment in haste before they have time to fully think it through – a key tactic used by threat actors in phishing campaigns.

Finally, the link itself reveals something else is fishy about this alert. Hovering over the button shows the embedded link is not, in fact, a WebEx page, but a SendGrid link, a legitimate customer communication service used by marketing professionals. SendGrid links are commonly used in phishing attacks, as they require minimal effort.

Figure 3: Phishing Page, Step 1

Upon clicking the SendGrid link, the user is redirected to a phishing page, as seen in Figure 3. The only difference between a legitimate WebEx login page and this phishing page is the URL itself, suggesting the attacker conducted some form of web scraping to create an intentionally benign looking and familiar login page for the end user. Web scraping, essentially, is the practice of using a tool to automatically copy data from a website and create a convincing copy.

Figure 4: Phishing Page, Step 2

Deception quickly falls apart when reviewing the URL, however; while designed to look like the actual URL, there actually isn’t a portion that includes ‘webex.com’. The numerous dashes, coupled with one very long word followed by ‘index.php’ is not reflective of a professional link, suggesting the phishing URL was registered to appear legitimate at first glance. While phishers commonly make a valiant effort for their pages to look legitimate, looking at the address bar generally reveals if it’s legitimate. Misspelling, similar looking words and strange top-level domains are common tricks used by attackers to guile end users for just long enough to not question it.

While the initial phishing page only requests the user’s email address, the following page then changes URLs from “index.php” to “step2.php” and asks for the user’s password- this is another indicator the site is not legitimate, as the specific internals of which php file is being invoked for this webpage would be usually be hidden to the user.

Figure 5: Final redirect to official WebEx login page

As the final stage of attack, when the user enters their credentials on the page shown in Figure 5 above, the user is then redirected to WebEx’s real sign-in page. At this point, the malicious actor now has the user’s credentials, but it is in their best interest to ensure the user is unaware that a successful credential phishing attack occurred, giving the threat actors time to make use of newly stolen log-in details. The final redirect to WebEx’s legitimate log-in page may make the end user believe there was a log-in error and they need to log-in again. A common theme in a many phishing attacks is appealing to and preying on the feeling that nothing is amiss and there is nothing to question about the experience. In the meantime, threat actors gain precious time to do damage while the end user moves on with his or her workday.

Figure 6: Open Directory

A final interesting finding about this phishing campaign is the main domain itself, which reveals an open directory. This open directory shows the files included in the phishing page: images, fonts, .css files, and more. Although finding this directory was easy, it isn’t necessary to hide it, as most end users will only go through to login rather investigating into the internals of the site. However, it must be noted no professional website allows access to its file directories in this way. If reached, it is an almost sure-fire way of immediately identifying a phish.

Network IOC IP
hXXps://cert-ssl-global-prod-webmeetings[.]com/da4njy=/idb/saml/jsp/index[.]php 137[.]135[.]110[.]140

 

How Cofense Can Help

Visit Cofense’s Remote Work Phishing Infocenter to stay up to date as threats evolve. Our site is updated with screenshots and YARA rules as we continue to track campaigns.

All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks. Any observations contained in this blog regarding circumvention of end point protections are based on observations at a point in time based on a specific set of system configurations. Subsequent updates or different configurations may be effective at stopping these or similar threats.
The Cofense® and PhishMe® names and logos, as well as any other Cofense product or service names or logos displayed on this blog are registered trademarks or trademarks of Cofense Inc.
Read More

Trickbot Is Using Google Docs to Trick Proofpoint’s Gateway

Posted On August 29, 2019 By Cofense In Phishing Defense Center, Proofpoint, SEG Misses /   No Comments

Gateways Bypassed

Proofpoint

By Tej Tulachan

The Cofense Phishing Defense Center (PDC) has detected a phishing campaign that delivers Trickbot embedded in a Google Docs link. Trickbot has been making the rounds for a long time now and is still considered one of the biggest malware threats targeting business today. Threat actors frequently utilize legitimate applications or trusted file sharing sites like Google Docs to bypass the email gateway and lure users to click on the link to deliver malware. In this case, the email made it through Proofpoint’s gateway utilized by our PDC customer.

Email Body

The email attempts to lure curious users to click on the link: “Have you already received documentation I’ve directed you recently? I am sending them over again.” This is a legitimately generated email by Google Docs when a file is shared by one of its subscribers. Unknowingly, the recipient is directed to a document hosted on Google that contains a malicious URL.

Fig 1. Email body

When the recipient clicks on the link it directs to a genuine Google Docs page as shown below, which contains a fake 404 error message and another embedded link. The threat actor baits the recipient into downloading the document: “Downloading the document manually via the link”. This link hxxps://docs[.]google[.]com/uc?id=112QLCdDtd4y-mAzr8hobCs0TP5mQmKfL downloads the malicious payload.

Fig 2. Google doc page

Once the URL links to a file hosted on Google drive, it downloads a Review_Rep.19.PDF.exe which has been disguised as PDF file. Many recipients will not see the .exe file extension. It’s something that you need to specifically enable in Windows. So, to them it looks like a legitimate PDF file since the attacker uses the icon for a PDF.

Fig 3. Pdf Icon

If we look at the file in a hex editor, we see that in fact it’s an executable file and not a PDF.

Take a look below in the editor, indicated by the magic bytes MZ which denotes a windows executable.

Fig 4. Magic Number

Once the payload is executed it creates a copy of itself (egолаСывЯыФЙ) in C:\ProgramData, where it  undertakes control over execution of the malware.

Fig 5. egолаСывЯыФЙ.exe

Furthermore, it creates another copy in “C:\Users\REM\AppData\Roaming\speedLan” that also includes the config file for Trickbot (settings.ini) (The directory depends on the Trickbot version.)

Fig 6. speedlan

If we look inside the settings.ini we see a lot of the “obfuscated” text.

Fig 7. Obfuscated text

Additionally, if we open up the Task Scheduler, we can see it also sets a task that starts the malicious file from the “Speedlan” folder.

Fig 8. Start Task Scheduler

Looking at the Triggers tab, we can see it has been set to repeat itself every 11 minutes for 596843 minutes (414 days) for this particular version of Trickbot. The scheduled task checks to see if the binary is running in memory every 11 minutes over a 1-year period. This means that the binary will stay persistent on the system if the process is terminated. The 414 day counter just insures that the scheduled task stays running for as long as the system is online (generally, people will reboot their computer at least once a year).

 

 

 

 

 

 

 

 

 

Fig 9. Trigger

This then hollows out Svchost, injects its malicious code, and launches it. It keeps launching more and more Svchost’s if you let it run. Each of these are typically responsible for a module of Trickbot.

Fig 10. Hollows Svchost

Indicators of Compromise (IOCs):

Malicious File(s):

 

Filename: Review_ Rep.19.PDF.exe

MD5: ab2a8fc10e8c1a39ae816734db9480de

SHA-256: 20328b1f169b1edeef38853dafbbacfdac53c66f7f1dd62f387091bedebfd497

File Size: 404,320 Bytes

Extension: exe

 

Malicious URL(s):

 

hxxps://docs[.]google[.]com/document/d/1fgSfd4DwReVKbcLI3ISO2jhX1Yn8WOqbXnmU_bg00_A/edit?usp=sharing_eip&ts=5d5accb1
hxxps://docs[.]google[.]com/uc?id=112QLCdDtd4y-mAzr8hobCs0TP5mQmKfL
hxxps://jaquetas01[.]cordenadorltda[.]org
hxxps://services[.]halapar[.]org

 

Associated IP(s):

200[.]119[.]45[.]140

107[.]181[.]175[.]122

79[.]143[.]31[.]94

198[.]27[.]74[.]146

186[.]47[.]40[.]234

181[.]129[.]93[.]226

190[.]152[.]4[.]210

 

HOW COFENSE CAN HELP

89% of phishing threats delivering malware payloads analyzed by the Cofense Phishing Defense CenterTM bypassed email gateways. Condition users to be resilient to evolving phishing attacks with Cofense PhishMeTM and remove the blind spot with Cofense ReporterTM. Cofense PhishMe offers a phishing scenario, “Shared Google Doc – TrickBot,” to help users identify the attack described in today’s blog.

Quickly turn user reported emails into actionable intelligence with Cofense TriageTM. Reduce exposure time by rapidly quarantining threats with Cofense VisionTM.

Easily consume phishing-specific threat intelligence to proactively defend your organisation against evolving threats with Cofense IntelligenceTM.

Thanks to our unique perspective, no one knows more about REAL phishing threats than Cofense™. To understand them better, read the 2019 Phishing Threat & Malware Review.

 

All third-party trademarks referenced by Cofense whether in logo form, name form or product form, or otherwise, remain the property of their respective holders, and use of these trademarks in no way indicates any relationship between Cofense and the holders of the trademarks. Any observations contained in this blog regarding circumvention of end point protections are based on observations at a point in time based on a specific set of system configurations. Subsequent updates or different configurations may be effective at stopping these or similar threats.

Read More

Remote Access Trojan Uses Sendgrid to Slip through Proofpoint

Posted On August 14, 2019 By Cofense In Phishing Defense Center, Proofpoint, SEG Misses /   No Comments

Gateways Bypassed

Proofpoint

The CofenseTM Phishing Defense CenterTM observed a malware campaign masquerading as an email complaint from the Better Business Bureau to deliver the notorious Orcus RAT, part of the free DNS domain ChickenKiller which we blogged about in 2015. Here’s how it works:

Read More