Category: cloudsecurity

Google App en gine and Azure App service hits with phishing

A phishing campaign abused both the Google App Engine and the Azure App Service to steal victims’ Microsoft Outlook credentials.

A Google Cloud Platform (GCP) service used for developing and hosting web applications, Google App Engine enables customers to direct SSL-protected traffic through their appspot.com domain.

This characteristic thereby lent the domain used in this campaign a sense of legitimacy.

The phishing page informed the visitor that their account credentials were incorrect after they had submitted their username and password. It then sent those details to ‘handler.php,’ a page hosted via Azure’s App Service at “july-28[.].azurewebsites[.]net.”

This domain was one of 110 bait URLs and 72 credential hosting URLs that traced back to this phishing campaign. As noted by Netskope, however, the vast majority of those sites used Azure’s App Service

The threat actor has mostly used Azure App Service to host the credential harvester at azurewebistes.net. It appears the attacker tried out multiple different options to serve the credential harvester and chose to use Azure App Service on an ongoing basis, likely because of its ease of use and Microsoft-issued SSL certs.

The campaign described above highlights the need for organizations to defend themselves against a phishing attack. One of the ways they can do this is by training their employees to spot some of the most common types of phishing campaigns that are in circulation today. They can use this resource to lay the basis for their education efforts.

by Categories: cloudsecurity, Phishing, SecurityTags: , , Leave a comment

SkyArk.. New AWS Stealth watch for shadow IT

A new open-source tool designed to identify Shadow Admin accounts in Microsoft Corp. Azure and Amazon Web Services Inc. cloud environments.

Called CyberArk SkyArk, the tool is designed to help organizations combat Shadow Admins by targeting and securing the most privileged entities in both Azure and AWS environments.

Shadow Admin accounts have sensitive privileges on a network and are typically overlooked because they are not members of a privileged Active Direct group. Instead, Shadow Admin accounts are typically granted their privileges through the direct assignment of permissions.

They’re highly desired by attackers because they provide administrative privileges necessary to advance an attack while having a lower profile than well-known admin group members.

“While organizations may be familiar with their list of straightforward admin accounts, Shadow Admins are much more difficult to discover due to the thousands of permissions that exist in standard cloud environments (i.e. AWS and Azure each have more than 5,000 different permissions),” CyberArk explained. “As a result, there are many cases where Shadow Admins might be created. Despite the appearance of limited permissions, a Shadow Admin with just a single permission has the ability to gain the equivalent power of a full admin.”

SkyArk offers two main scanning modules, AzureStealth and AWStealth, to scan Azure and AWS environments. The tool only requires read-only permissions because it simply queries cloud entities and their assigned permissions before performing an analysis and providing results.

The results can be used by both internal red and blue teams. For red teams, which are used to break into systems to test security, the results can be used to target discovered Shadow Admins through password matching, spear-phishing or a targeted attack on the endpoints of the employee discovered to have admin or shadow rights. For blue teams, which defend against attacks, the results can be used to eliminate unintended admins and remove unnecessary permissions from Shadow Admins.

by Categories: cloudsecurity, cybersecurity, SecurityTags: , Leave a comment

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”.

by Categories: cloudsecurity, Email Security, O365, PhishingTags: Leave a comment

Microsoft will end TLS 1.1 Finally in O365

Microsoft has set the official retirement date for the insecure Transport Layer Security (TLS) 1.0 and 1.1 protocols in Office 365 starting with October 15, 2020, after temporarily halting deprecation enforcement for commercial customers due to COVID-19.

“As companies have pivoted their supply chains and countries have started to re-open we have re-established a retirement date for TLS 1.0 and 1.1 in Office 365 to be October 15, 2020,” the company said in the MC218794 Microsoft 365 admin center announcement on Friday.

“As previously communicated [..], we are moving all of our online services to Transport Layer Security (TLS) 1.2+ to provide best-in-class encryption, and to ensure our service is more secure by default.”

The TLS 1.0/1.1 retirement was first announced in December 2017 and, as explained by Microsoft, the effect of this change for end-users is expected to be minimal.

TLS 1.0 and 1.1 retirement

TLS 1.0/1.1 retirement guidance

IT administrators can use the official KB4057306 documentation to prepare for TLS 1.2 in Office 365 and Office 365 GCC.

They can also download this Office 365 TLS deprecation report to quickly identify the users and devices that connect to Exchange servers via TLS 1.0/1.1.

At the moment, users of the following clients are advised to update to the latest versions as they are known to be unable to use TLS 1.2:

  • Android 4.3 and earlier versions
  • Firefox version 5.0 and earlier versions
  • Internet Explorer 8-10 on Windows 7 and earlier versions
  • Internet Explorer 10 on Windows Phone 8
  • Safari 6.0.4/OS X10.8.4 and earlier versions

Microsoft also provides a whitepaper with guidance on how to identify and remove TLS 1.0 dependencies in software built on top of Microsoft operating systems as a starting point for a migration plan to a TLS 1.2+ environment.

Microsoft recommends including the following:

  • Application code analysis to find/fix hardcoded instances of TLS 1.0/1.1.
  • Network endpoint scanning and traffic analysis to identify operating systems using TLS 1.0/1.1 or older protocols.
  • Full regression testing through your entire application stack with TLS 1.0/1.1 and all older security protocols disabled.
  • Migration of legacy operating systems and development libraries/frameworks to versions capable of negotiating TLS 1.2.
  • Compatibility testing across operating systems used by your business to identify any TLS 1.2 support issues.
  • Coordination with your own business partners and customers to notify them of your move to deprecate TLS 1.0/1.1.
  • Understanding which clients may be broken by disabling TLS 1.0/1.1.

Microsoft has already begun deprecating insecure TLS for any clients, devices, or services connecting to Office 365 through TLS 1.0 or 1.1 DoD or GCC High instances as of January 2020.

The two protocols will also become unsupported for commercial Office 365 customers, with the company recommending “that all client-server and browser-server combinations use TLS 1.2 (or a later version) in order to maintain connection to Office 365 services.”

by Categories: cloudsecurity, Security Leave a comment