Office 365 phishing now with fake SharePoint alerts

Employees using Microsoft Office 365 are targeted in a phishing campaign that makes use automated SharePoint notifications to steal their accounts.

The phishing emails delivered as part of this phishing campaign are addressed to all employees working at targeted organizations and have until now reached an estimated number of up to 50,000 mailboxes based on stats from email security company Abnormal Security.

What makes these phishing messages potentially dangerous is the fact that they’re using a shotgun approach, trying to trick at least one employee and then use their credentials to further compromise their employer’s systems.

Fake SharePoint alerts used as lures
The attackers behind this phishing campaign did their best to keep the phishing messages as short and vague as possible, and they also made it a point to include the targeted company’s name multiple times within the emails.

This strategy is supposedly designed to help induce a feeling of trust and make the targets think that the phishing emails were really sent from within their organization.

“In the email body, the recipient’s company name was also used numerous times to impersonate an internal document shared by this service,”.

“Recipients may be convinced that the email is safe and coming from their company because of the repetitive inclusion of the company name.”

The phishing messages’ goal is to make the targets click on an embedded hyperlink that sends them to a SharePoint themed landing page through a series of redirects.

This is where they are required to click on a button to download “important documents” mentioned within the phishing emails, a button that will either download a PDF that sends them to another website or that will redirect them to a submission form where they are asked to input their credentials.

If the targets fall for the phishers’ tricks, their Microsoft credentials will give the attackers’ full control of their Office 365 accounts, with their information to be stolen and used as apart of identity theft and fraud schemes such as Business Email Compromise (BEC).

“This places employees and their networks at considerable risk as attackers can launch internal attacks to steal more credentials and information from the organization”.

DMARC ! Factors to be considered ..

Domain-based Message Authentication, Reporting & Conformance (DMARC), is an email authentication, policy, and reporting protocol. It builds on the SPF and DKIM protocols to improve and monitor protection of the domain from fraudulent email.

Factors that need to be considered while taking a DMARC decision

Cloud-based (SaaS) deployment. This eases the burden on company IT teams, allowing for the solution to be easily deployed and configured with out-of-the-box security policies.

Domain diagnosis. This will ensure your business is aware of any domain vulnerabilities, many of which can be common for SMBs to overlook and consequently increase their risk.

User friendly dashboard. This will ensure your team does not need a lot of time to understand how the solution works.

Forensic reporting. This allows for detailed information on why emails may have failed DMARC checks and allow for additional system tuning.

DNS record change tracking. This allows for additional insight into malicious activity

API integration. Large companies typically have internal dashboards and workflows. API Integration with the DMARC solution will allow you to tailor the solution into your enterprise reporting & analysis tools.

A good DMARC solution should clearly identify high-risk sources, forwarders, and common email providers. It should provide actionable next steps in mitigating risk and minimize details until you actually need them. Avoid solutions that don’t show all authentication domains, differentiating between just passing SPF/DKIM and alignment.

Remember that adding a DMARC solution is essentially just adding a reporting address to your policy, so try on a few (or several at a time) if you’re curious about any provider.

Other key consideration

Accuracy: What is the level of completeness for classification of IP’s from the reports of mail senders and subsequent categorization that represent the mail that belongs to my organization?

Insight: The best solutions will have easy to use, staged flows that display recommended actions and contextual guides from the data presented to explain misconfigurations in email authentication. Data needs to be actionable with insight.

Automation: More recent platform solutions for DMARC use hosted management for SPF authentication which allows for expansion past the 10 SPF lookup limit and provides a far more reliable and resilient email delivery. Ongoing automated monitoring with alerting which recognizes changes in authentication, identifies new sources and takes immediate action should be requirements.

Value: How much should I budget and how can total cost and time resources be efficiently managed? Look for automation of defined actions and applying expertise to specifically implement those actions in the best manner for the organization.

Cloud services hit by Phishing campaign

Researchers analyzed a new phishing campaign that pretends to from a help desk named “servicedesk.com” that mimics similar wording used by real IT helpdesk domains in corporate environments.

The email imitates a “quarantined mail” notification frequently sent out in workplaces by email security products and spam filters, asking the user to “release” messages stuck in the queue.

The “From:” (envelope) address in the email is listed as “noreply@servicedesk.com,” and while sender domains can easily be spoofed, the mail headers for this phishing campaign show that the email was sent through this domain.

As you can see from the email headers below, the phishing email is sent through an intermediary “cn.trackhawk.pro” domain, but the originating domain is clearly “servicedesk.com.”

In most email spoofing scenarios, a mismatch between the “From:” email domain and the domain listed in the bottommost “Received:” header is a red flag.

In this campaign, the domain “servicedesk.com” is used in the “From:” (envelope) address matches the domain listed in the last “Received:” header, making it more easily bypass spam filters.

And more importantly, lack of DMARC, DKIM and SPF validations on the “servicedesk.com” domain enable spammers to take advantage of this domain as demonstrated in these attacks.

Microsoft and IBM domains add legitimacy

Using three well-known enterprise solutions like IBM Cloud hosting, Microsoft Azure, and Microsoft Dynamics to host the phishing landing pages adds legitimacy to the campaign.

This URL then redirects the user to an IBM Cloud domain, cf.appdomain.cloud used for IBM’s Cloud Foundry deployments, to host the phishing landing page.

Entering a password of decent length and complexity, perhaps once it matches the criteria set forth by IBM Cloud, will redirect the user to another fake page confirming the settings update host on Microsoft Azures hosting domain, windows.net.

Phishing emails are an everyday nuisance for both business and personal email users but could lead to very dire consequences, including data theft and enterprise-wide ransomware attacks.

Increasing cases of phishing campaigns abusing legitimate cloud infrastructure are on the rise as they add legitimacy to the phishing attacks and provide free SSL certificates.

This increased complexity allows attackers to potentially bypass spam filters and security products, which leads to a greater need for sophisticated security systems in this never-ending game of cat and mouse.

Consent Phishing ! Warning from Microsoft

Phishing campaign are a common tactic in which cybercriminals impersonate a well-known company, product, or brand to steal account credentials, financial information, or other data from unsuspecting victims. A typical phishing attack convinces the user to directly enter their password and login credentials, which are then captured by the attacker.

But a more specialized type of campaign known as consent phishing aims to grab sensitive data not by snagging your password but by tricking you into giving the necessary permissions to a malicious app.

This type of consent phishing relies on the OAuth 2.0 authorization technology. By implementing the OAuth protocol into an app or website, a developer gives a user the ability to grant permission to certain data without having to enter their password or other credentials.

Used by a variety of online companies including Microsoft, Google, and Facebook, OAuth is a way to try to simplify the login and authorization process for apps and websites through a single sign-on mechanism. However, as with many technologies, OAuth can be used for both beneficial and malicious

Microsoft details the problem step by step in its blog post:

  1. An attacker registers an app with an OAuth 2.0 provider, such as Azure AD
  2. The app is configured in a way that makes it seem trustworthy, such as using the name of a popular product used in the same ecosystem.
  3. The attacker gets a link in front of users, which may be done through conventional email-based phishing, by compromising a non-malicious website, or through other techniques.
  4. The user clicks the link and is shown an authentic consent prompt asking them to grant the malicious app permissions to data.
  5. If a user clicks Accept, they grant the app permissions to access sensitive data.
  6. The app gets an authorization code, which it redeems for an access token, and potentially a refresh token.
  7. The access token is used to make API calls on behalf of the user.
  8. The attacker can then gain access to the user’s mail, forwarding rules, files, contacts, notes, profile, and other sensitive data.
content-phishing-microsoft.jpg

Microsoft touted some of the steps it’s taken to try to prevent this type of malicious behavior. The company said it uses such security tools as identity and access management, device management, threat protection, and cloud security to analyze millions of data points to help detect malicious apps. Further, Microsoft is trying to better secure its application ecosystems by allowing customers to set policies on the types of apps to which users can give certain consent.

Despite the efforts of Microsoft and other companies, these attacks persist as cybercriminals stay one step ahead of the game. To help protect against consent phishing campaigns, Microsoft offers advice for individuals and organizations.

For individuals:

  • Check for poor spelling and grammar. If an email message or the application’s consent screen has spelling and grammatical errors, it’s likely to be a suspicious application.
  • Keep a watchful eye on app names and domain URLs. Attackers like to spoof app names that make it appear to come from legitimate applications or companies but drive you to consent to a malicious app. Make sure you recognize the app name and domain URL before consenting to an application.

For organizations:

  • Understand the data and permissions an application is asking for 
  • Ensure administrators know how to manage and evaluate
  • Audit consent application and policies in your organisation.
  • Promote the use of applications that have been accessed
  • Configure consent policies.

Three pieces of advice for app and website developers that use OAuth:

  1. Make the permission prompts far more understandable to the casual end user. For instance, include a message that says: “If you say okay, you are giving this third party full control over all documents you can see, so make sure you trust the person asking. The request might be malicious.”
  2. Somehow make the system intelligent enough to make the risk decision on behalf of the user so a user not trained in computer security doesn’t have to make computer security decisions.
  3. Don’t allow high-risk decisions to be made, especially by default and so easily. The system should default to the least permissive permission and make the user go out of their way to give away the keys to the kingdom.