In 2021, workers everywhere reevaluated their professional and personal choices, leading to what became known as the Great Resignation. In 2022, a new trend that many are calling the Great Reshuffle has emerged, with 43 percent of the workforce saying they’re very likely to consider changing jobs or exiting their industry altogether in the coming year.1
As our 2022 Work Trend Index, Great Expectations: Making Hybrid Work Work, revealed, employees have a new “worth it” equation and are voting with their feet.2 As a result, employees are onboarding and offboarding more frequently. The constant flow of tasks, starting with applying for a job and navigating the first few days of employment, leaves much room for error, thus increasing stress for HR, IT, and each new employee.
Given that 73 percent of employees want to keep their work options flexible, more than three-quarters of Chief Human Resource Officers (CHROs) plan to preserve the newer hybrid work options available today and accommodate the flexibility that existing and prospective employees desire.3 Unfortunately, the complexity and cost of both onboarding and offboarding employees have increased in our new hybrid reality.
The 2022 Work Trend Index surveyed more than 31,000 people in 31 countries and found that 53 percent of people are likely to consider transitioning to hybrid work in the year ahead.
The rising costs and frustration of employee onboarding
The typical multistep process of the new hire onboarding journey became even more convoluted during the pandemic with the rise of both hybrid and fully remote work. As a result, managing the details of recruiting, interviewing, and hiring has become increasingly challenging, leading to a sharp rise in costs.
Organizations struggle with navigating the start of the employee journey for both in-person and remote workers in the most efficient and secure way possible. For example, the chart in Figure 1 summarizes the findings of a private study Microsoft conducted in 2021 to understand who’s involved in tasks associated with identity verification for new employees. Responses from 3,000 organizations show that HR and IT split these tasks almost evenly and that across the 14 industries surveyed, onboarding accounts for an astounding 14 to 31 percent of all ID verification spending.
In fact, 69 percent of employees are more likely to stay with a company if they experience great onboarding.4
Traditionally, HR teams have relied on physical documents—such as a driver’s license, birth certificate, or passport—and in-person communications to verify a new employee’s identity and credentials, a semi-manual process that can cause frustrating onboarding delays, flagging a potential concern given more remote, in-person, and hybrid options available in a competitive labor market. The modern workforce expects a more automated experience that’s also more secure. In fact, 82 percent of study participants wish there was a better way to perform verification.
Fortunately, recent advances in technology are making it possible to digitize identity information in a way that’s portable and privacy-respecting for the user, while helping businesses streamline their verification processes. This new technology, called verifiable credentials, is based on a decentralized identity approach and allows organizations to verify an individual’s credentials, such as employment or education. For the background check process, employers can confirm a new hire’s identity information digitally and within seconds from an authoritative source. The business can then issue an employee ID as a verifiable credential, which the employee can store in their digital wallet and use to access other resources that require employment confirmation, such as benefits enrollment or equipment purchases.
Although these modernization efforts must still align with government regulations that require physical inspection of original documents, they have the potential to significantly transform the employee’s onboarding experience and their first days on the job, making it easier for them to access the resources they need to be immediately productive in their new role.
Microsoft Entra Verified ID will help streamline the process of credential attestation, reducing frustration and delays that HR, IT, and new employees currently experience. The chart in Figure 2 illustrates a transformed onboarding journey, and how HR and IT manage both pre-onboarding (blue) and onboarding (green) to ensure the process runs smoothly for the employee.
As we all know, first impressions matter. By simplifying and expediting the onboarding experience, using verifiable credentials can help create a positive first impression that helps make employees feel good about joining an organization, rather than second-guessing their decision.
Increased risks of employee offboarding
When an employee leaves an organization, their access credentials—along with their access permissions—should be wiped clean to prevent valuable company information from walking out the door with them. Using modern identity governance tools such as verifiable credentials, IT can select one box to decommission a departing employee’s access to the organization’s digital assets. If HR tools are integrated with identity systems, then any changes HR makes in their systems automatically perpetuate to other IT systems, and vice versa.
The offboarding governance process may include revoking any employer-issued verifiable credentials used to grant access to organizational programs, such as employee discounts, or employee-only resources. Verifiable credentials also give employees a new level of control over their personal information. They can revoke permissions they’ve given their former employer to access verifiable credentials that share educational history, government-issued identity numbers, and other sensitive data. And with the introduction of Microsoft Entra Verified ID, it’s now possible to allow individuals, organizations, and devices to decide what information they share with whom, and to take it back if necessary.
The benefits of using verifiable credentials
According to the 2021 Employee Experience Survey Highlights, organizations that provide digitally transformed experiences are nearly three times more likely to report higher productivity than their industry peers, and 90 percent more likely to report lower annual turnover.5
Using verifiable credentials creates tangible benefits for HR and IT departments and the employees they support:
Faster, easier, and less expensive processes. HR can start replacing some paper-based or in-person identity or credential verification processes to reduce onboarding time and get new hires productive sooner. IT can easily integrate verifiable credentials into existing systems without writing any custom code.
Compliance with ever-changing global privacy regulations. IT can implement decentralized identity solutions based on open standards that allow HR to verify an employee’s skills, certifications, education, and career history in a privacy-respecting manner.
A better employee experience that strengthens recruiting and retention. Today’s employees expect easy, convenient, and contactless digital experiences that protect their privacy. Verifiable credentials provide a secure way for individuals to share their personal information with their employers and revoke access when they leave.
Avanade, a leading professional services and technology provider, is using Microsoft Azure Active Directory (Azure AD) verified ID to streamline credentialing processes and facilitate collaboration among employees, vendors, and clients.
Navigating the path ahead
The Great Reshuffle is the living, evolving proof that organizations need to pay closer attention to the employee experience. HR and IT business leaders must therefore respond to employee expectations for flexibility, safety, security, and support for their overall wellbeing. This response must start with a smoother onboarding process, in which verifiable credentials can significantly simplify and streamline.
Learn more about how Microsoft and verified ID can help your organization navigate the Great Reshuffle.
Read more information on the solution and open standards initiative with decentralized identities.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.
What could the world achieve if we had trust in every digital experience and interaction?
This question has inspired us to think differently about identity and access, and today, we’re announcing our expanded vision for how we will help provide secure access for our connected world.
Microsoft Entra is our new product family that encompasses all of Microsoft’s identity and access capabilities. The Entra family includes Microsoft Azure Active Directory (Azure AD), as well as two new product categories: Cloud Infrastructure Entitlement Management (CIEM) and decentralized identity. The products in the Entra family will help provide secure access to everything for everyone, by providing identity and access management, cloud infrastructure entitlement management, and identity verification.
The need for trust in a hyperconnected world
Technology has transformed our lives in amazing ways. It’s reshaped how we interact with others, how we work, cultivate new skills, engage with brands, and take care of our health. It’s redefined how we do business by creating entirely new ways of serving existing needs while improving the experience, quality, speed, and cost management.
Behind the scenes of all this innovation, millions and millions of connections happen every second between people, machines, apps, and devices so that they can share and access data. These interactions create exciting opportunities for how we engage with technology and with each other—but they also create an ever-expanding attack surface with more and more vulnerabilities for people and data that need to be addressed.
It’s become increasingly important—and challenging—for organizations to address these risks as they advance their digital initiatives. They need to remove barriers to innovation, without the fear of being compromised. They need to instill trust, not only in their digital experiences and services, but in every digital interaction that powers them—every point of access between people, machines, microservices, and things.
Our expanded vision for identity and access
When the world was simpler, controlling digital access was relatively straightforward. It was just a matter of setting up the perimeter and letting only the right people in.
But that’s no longer sustainable. Organizations simply can’t put up gates around everything—their digital estates are growing, changing, and becoming boundaryless. It’s virtually impossible to anticipate and address the unlimited number of access scenarios that can occur across an organization and its supply chain, especially when it includes third-party systems, platforms, applications, and devices outside the organization’s control.
Identity is not just about directories, and access is not just about the network. Security challenges have become much broader, so we need broader solutions. We need to secure access for every customer, partner, and employee—and for every microservice, sensor, network, device, and database.
And doing this needs to be simple. Organizations don’t want to deal with incomplete and disjointed solutions that solve only one part of the problem, work in only a subset of environments, and require duct tape and bubble gum to work together. They need access decisions to be as granular as possible and to automatically adapt based on real-time assessment of risk. And they need this everywhere: on-premises, Azure AD, Amazon Web Services, Google Cloud Platform, apps, websites, devices, and whatever comes next.
This is our expanded vision for identity and access, and we will deliver it with our new product family, Microsoft Entra.
Video description: Vasu Jakkal, Corporate Vice President, Security, Compliance, Identity and Management, and Joy Chik, CVP of Identity, are unveiling Microsoft Entra, our new identity and access product family name, and are discussing the future of modern identity and access security.
Making the vision a reality: Identity as a trust fabric
To make this vision a reality, identity must evolve. Our interconnected world requires a flexible and agile model where people, organizations, apps, and even smart devices could confidently make real-time access decisions. We need to build upon and expand our capabilities to support all the scenarios that our customers are facing.
Moving forward, we’re expanding our identity and access solutions so that they can serve as a trust fabric for the entire digital ecosystem—now and long into the future.
Microsoft Entra will verify all types of identities and secure, manage, and govern their access to any resource. The new Microsoft Entra product family will:
Protect access to any app or resource for any user.
Secure and verify every identity across hybrid and multicloud environments.
Discover and govern permissions in multicloud environments.
Simplify the user experience with real-time intelligent access decisions.
This is an important step towards delivering a comprehensive set of products for identity and access needs, and we’ll continue to expand the Microsoft Entra product family.
“Identity is one of the cornerstones of our cybersecurity for the future.”
—Thomas Mueller-Lynch, Service Owner Lead for Digital Identity, Siemens
Microsoft Entra at a glance
Microsoft Azure AD, our hero identity and access management product, will be part of the Microsoft Entra family, and all its capabilities that our customers know and love, such as Conditional Access and passwordless authentication, remain unchanged. Azure AD External Identities continues to be our identity solution for customers and partners under the Microsoft Entra family.
Additionally, we are adding new solutions and announcing several product innovations as part of the Entra family.
Reduce access risk across clouds
The adoption of multicloud has led to a massive increase in identities, permissions, and resources across public cloud platforms. Most identities are over-provisioned, expanding organizations’ attack surface and increasing the risk of accidental or malicious permission misuse. Without visibility across cloud providers, or tools that provide a consistent experience, it’s become incredibly challenging for identity and security teams to manage permissions and enforce the principle of least privilege across their entire digital estate.
With the acquisition of CloudKnox Security last year, we are now the first major cloud provider to offer a CIEM solution: Microsoft Entra Permissions Management. It provides comprehensive visibility into permissions for all identities (both user and workload), actions, and resources across multicloud infrastructures. Permissions Management helps detect, right-size, and monitor unused and excessive permissions, and mitigates the risk of data breaches by enforcing the principle of least privilege in Azure AD, Amazon Web Services, and Google Cloud Platform. Microsoft Entra Permissions Management will be a standalone offering generally available worldwide this July 2022 and will be also integrated within the Microsoft Defender for Cloud dashboard, extending Defender for Cloud’s protection with CIEM.
Additionally, with the preview of workload identity management in Microsoft Entra, customers can assign and secure identities for any app or service hosted in Azure AD by extending the reach of access control and risk detection capabilities.
Enable secure digital interactions that respect privacy
At Microsoft, we deeply value, protect, and defend privacy, and nowhere is privacy more important than your personal identity. After several years of working alongside the decentralized identity community, we’re proud to announce a new product offering: Microsoft Entra Verified ID, based on decentralized identity standards. Verified ID implements the industry standards that make portable, self-owned identity possible. It represents our commitment to an open, trustworthy, interoperable, and standards-based decentralized identity future for individuals and organizations. Instead of granting broad consent to countless apps and services and spreading identity data across numerous providers, Verified ID allows individuals and organizations to decide what information they share, when they share it, with whom they share it, and—when necessary—take it back.
The potential scenarios for decentralized identity are endless. When we can verify the credentials of an organization in less than a second, we can conduct business-to-business and business-to-customer transactions with greater efficiency and confidence. Conducting background checks becomes faster and more reliable when individuals can digitally store and share their education and certification credentials. Managing our health becomes less stressful when both doctor and patient can verify each other’s identity and trust that their interactions are private and secure. Microsoft Entra Verified ID will be generally available in early August 2022.
“We thought, ‘Wouldn’t it be fantastic to take a world-leading technology like Microsoft Entra and implement Verified ID for employees in our own office environment?’ We easily identified business opportunities where it would help us work more efficiently.”
Next, let’s focus on Identity Governance for employees and partners. It’s an enormous challenge for IT and security teams to provision new users and guest accounts and manage their access rights manually. This can have a negative impact on both IT and individual productivity. New employees often experience a slow ramp-up to full effectiveness while they wait for the access required for their jobs. Similar delays in granting necessary access to guest users undermine a smoothly functioning supply chain. Then, without formal or automated processes for reprovisioning or deactivating people’s accounts, their access rights may remain in place when they change roles or exit the organization.
Identity Governance addresses this with identity lifecycle management, which simplifies the processes for onboarding and offboarding users. Lifecycle workflows automate assigning and managing access rights, and monitoring and tracking access, as user attributes change. Lifecycle workflows in Identity Governance will enter public preview this July 2022.
“We were so reactive for so long with old technology, it was a struggle. [With Azure AD Identity Governance] we’re finally able to be proactive, and we can field some of those complex requests from the business side of our organization.”
—Sally Harrison, Workplace Modernization Consultant, Mississippi Division of Medicaid
Create possibilities, not barriers
Microsoft Entra embodies our vision for what modern secure access should be. Identity should be an entryway into a world of new possibilities, not a blockade restricting access, creating friction, and holding back innovation. We want people to explore, to collaborate, to experiment—not because they are reckless, but because they are fearless.
Visit the Microsoft Entra website to learn more about how Azure AD, Microsoft Entra Permissions Management, and Microsoft Entra Verified ID deliver secure access for our connected world.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.
On Monday May 30, 2022, Microsoft issued CVE-2022-30190 regarding the Microsoft Support Diagnostic Tool (MSDT) in Windows vulnerability. A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word. An attacker who successfully exploits this vulnerability can run arbitrary code with the privileges of the …
UPDATE July 12, 2022: As part of the response by Microsoft, a defense in depth variant has been found and fixed in the Windows July cumulative updates. Microsoft recommends installing the July updates as soon as possible.
Windows Version Link to KB article LInk to Catalog Windows 8.1, Windows Server 2012 R2 5015805 Download Windows Server 2012 5015805 Download Windows 7, Windows Server 2008 R2 5015805 Download Windows Server 2008 SP2 5015805 Download On Monday May 30, 2022, Microsoft issued CVE-2022-30190 regarding the Microsoft Support Diagnostic Tool (MSDT) in Windows vulnerability.
UPDATE July 12, 2022: As part of the response by Microsoft, a defense in depth variant has been found and fixed in the Windows July cumulative updates. Microsoft recommends installing the July updates as soon as possible.
Windows Version Link to KB article LInk to Catalog Windows 8.1, Windows Server 2012 R2 5015805 Download Windows Server 2012 5015805 Download Windows 7, Windows Server 2008 R2 5015805 Download Windows Server 2008 SP2 5015805 Download On Monday May 30, 2022, Microsoft issued CVE-2022-30190 regarding the Microsoft Support Diagnostic Tool (MSDT) in Windows vulnerability.
Microsoft uncovered high-severity vulnerabilities in a mobile framework owned by mce Systems and used by multiple large mobile service providers in pre-installed Android System apps that potentially exposed users to remote (albeit complex) or local attacks. The vulnerabilities, which affected apps with millions of downloads, have been fixed by all involved parties. Coupled with the extensive system privileges that pre-installed apps have, these vulnerabilities could have been attack vectors for attackers to access system configuration and sensitive information.
As it is with many of pre-installed or default applications that most Android devices come with these days, some of the affected apps cannot be fully uninstalled or disabled without gaining root access to the device. We worked with mce Systems, the developer of the framework, and the affected mobile service providers to solve these issues. We commend the quick and professional resolution from the mce Systems engineering teams, as well as the relevant providers in fixing each of these issues, ensuring that users can continue using such a crucial framework.
Collaboration among security researchers, software vendors, and the security community is important to continuously improve defenses for the larger ecosystem. As the threat and computing landscape continues to evolve, vulnerability discoveries, coordinated response, and other forms of threat intelligence sharing are paramount to protecting customers against present and future threats, regardless of the platform or device they are using.
Uncovering the vulnerabilities
Our research on the framework vulnerabilities began while trying to better understand how a pre-installed System application could affect the overall security of mobile devices. We discovered that the framework, which is used by numerous apps, had a “BROWSABLE” service activity that an attacker could remotely invoke to exploit several vulnerabilities that could allow adversaries to implant a persistent backdoor or take substantial control over the device.
The framework seemed to be designed to offer self-diagnostic mechanisms to identify and resolve issues impacting the Android device, indicating its permissions were inherently broad with access to valuable resources. For example, the framework was authorized to access system resources and perform system-related tasks, like adjusting the device’s audio, camera, power, and storage controls. Moreover, we found that the framework was being used by default system applications to leverage its self-diagnostic capabilities, demonstrating that the affiliated apps also included extensive device privileges that could be exploited via the vulnerable framework.
According to mce Systems, some of these vulnerabilities also affected other apps on both Android and iOS devices. Moreover, the vulnerable framework and affiliated apps were found on devices from large international mobile service providers. mce Systems, which offers “Mobile Device Lifecycle and Automation Technologies,” also permitted providers to customize and brand their respective mobile apps and frameworks. Pre-installed frameworks and mobile apps such as mce Systems’ are beneficial to users and providers in areas like simplifying the device activation process, troubleshooting device issues, and optimizing performance. However, their extensive control over the device to deliver these kinds of services could also make them an attractive target for attackers.
Our analysis further found that the apps were embedded in the devices’ system image, suggesting that they were default applications installed by phone providers. All of the apps are available on the Google Play Store where they go through Google Play Protect’s automatic safety checks, but these checks previously did not scan for these types of issues. As part of our effort to help ensure broad protection against these issues, we shared our research with Google, and Google Play Protect now identifies these types of vulnerabilities.
We initially discovered the vulnerabilities in September 2021 and shared our findings with mce Systems and affected mobile service providers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). We worked closely with mce Systems’ security and engineering teams to mitigate these vulnerabilities, which included mce Systems sending an urgent framework update to the impacted providers and releasing fixes for the issues. At the time of publication, there have been no reported signs of these vulnerabilities being exploited in the wild.
The high-severity vulnerabilities, which have a Common Vulnerability Scoring System (CVSS) score of 7.0-8.9, are now identified as CVE-2021-42598, CVE-2021-42599, CVE-2021-42600, and CVE-2021-42601. We want to thank mce Systems’ engineering teams for collaborating quickly and efficiently in resolving these issues as well as to AT&T for proactively working with Microsoft to ensure customers can safely continue to use the framework.
Several other mobile service providers were found using the vulnerable framework with their respective apps, suggesting that there could be additional providers still undiscovered that may be impacted. The affected providers linked below have made updated app versions available to users before this disclosure, ensuring devices can be protected before these vulnerabilities could be exploited. We encourage these providers’ customers to update to the latest versions of these apps from the Google Play store, which include but are not limited to: com.telus.checkup, com.att.dh, com.fivemobile.myaccount, com.freedom.mlp,uat, and com.ca.bell.contenttransfer.
Additionally, the package com.mce.mceiotraceagent might be installed by several mobile phone repair shops. Mobile users are advised to look for that app name and remove it from their phone, if found.
Analyzing apps that use the mce framework
App manifest and permissions
When analyzing an Android application, the first thing that comes to mind is checking its manifest, maintained under the AndroidManifest.xml file. The manifest describes the application itself and its components, such as the following:
Permissions (for example, camera access, internet access, and others)
Activities and how they respond to Intents sent to them
Content providers
Receivers and the kind of content they expect to receive
Services
Checking the manifest of an app affiliated with mce Systems’ framework shed light on some of its features and capabilities but did not immediately indicate that any vulnerabilities or security issues were present. Therefore, further research into the app’s functionality was needed by understanding its permissions.
Analysis of the app’s permissions on the mobile device revealed authorizations that could lead to powerful access and capabilities for an attacker. Those permissions included control over the following:
Networking: access the internet, modify Wi-Fi state, network state, NFC, and Bluetooth
File access: read and write to the external storage
Peripherals: access the camera, record audio, get fingerprint information, and get the device’s physical location
Private information: read phone numbers, account information, and contacts
Management: install apps and modify device settings
With access to these valuable resources, the app could be abused by an attacker to implant a persistent backdoor on the device.
BROWSABLE activities
The “Activities” section of the app’s manifest detailed that the Intent-filter element included activities with a “BROWSABLE” category. While most Intents do not require a category, category strings detail the components that should handle the Intent. In particular, the BROWSABLE category allows the target Activity to be triggered from a web browser to display data referenced by a link, like an image. BROWSABLE activities appeal to attackers as the latter can exploit them via malicious web pages and other Intent-based attacks.
Figure 1: BROWSABLE Activity with the “mcedigital://” scheme
The Intent-filter element in the manifest dictates how the Activity can be triggered. In the app’s case, the Activity could be triggered by simply clicking a link with the “mcedigital://” scheme. This would start the com.mce.sdk.AppActivity Activity with an Intent with arbitrary data (besides the scheme).
Digging deeper: Reviewing the mce framework’s main functionality
We reviewed the effects of triggering the com.mce.sdk.AppActivity. Also known as appActivity, this Activity refers to the different functionalities provided by the app. AppActivity extends Activity and therefore has an onCreate method, which traditionally handles the creating Intent.
AppActivity
Here’s a brief description of AppActivity:
AppActivity has a member called “webView” and type “JarvisWebView,” a specialized class that extends WebView.
Upon creation, AppActivity has some optional display choices from the Intent (if they exist) and then loads a predefined web page to the WebView. That predefined page can get arbitrary query parameters from the Intent’s data; that is, everything after a “\?” will be added to the web page.
A JavaScript Interface is a conspicuous target to look for security issues, as it uses a JavaScript Bridge to allow invoking specific methods inside an Android app. In the case of JarvisJSInterface, three methods are exported:
init(String): takes a string that will be used as a JavaScript callback method; in our case, it will always be window.AndroidCallback
windowClose(): runs a callback registered by the Android app
request(String): sends a service request from the JavaScript client to the server (Android app)
The request method is by far the most interesting, as it performs the following:
Interprets the given string as a JSON object
Extracts the following pieces from the JSON object:
Context: a random GUID generated by the client, used to link requests and responses
Service: the service we are about to call to
Command: an integer
Data: optional parameters sent to the service call
Invokes the method serviceCall, which finds the registered service, gets the method based on the command number, and eventually invokes that method using Java reflection
Figure 2: Service::callServiceMethod
The serviceCall is a powerful method, as it allows the WebView to invoke “services” freely. But what are these services, exactly?
Services offered by the mce framework
After we examined the services offered by this framework per the app manifest, we then obtained a list of services that practically give the WebView complete control over the device. The most notable services include:
Audio: access and manipulate volume levels, as well as play a tone with a given duration and frequency
Camera: take a silent snapshot
Connectivity: control and obtain valuable information from NFC, Wi-Fi, and Bluetooth
Device: includes various device controlling mechanisms like battery drainage, performing a factory reset, and obtaining information on apps, addresses, sensor data, and much more
Discovery: set the device to discoverable
Location: obtain the location in various modes and set the location state
PackageManager: acquire package info and silently install a new app
Power: obtain charging state
Sensor: acquire sensor data such as barometer data, light data, proximity data, and whether fingerprinting is working
Storage: obtain content such as documents, media, images, and videos
These services inherit from a base class named “Service” and implement two methods:
setServiceName: for service identification purposes
setServiceMethodMap: for setting up the mapping between the command integer and the method name, argument names, and argument types
For example, here is the Camera service setting its methods:
Method 0 is “getCameraList” and expects no arguments.
Method 1 is “captureStillImageNoPreview” and expects one String argument.
Figure 3: The Camera service setting its methods
Vulnerability findings
Based on our analysis of the mce framework, we discovered several vulnerabilities. It should be noted that while mobile service providers can customize their apps respective to mce framework so as not to be identical, the vulnerabilities we discovered can all be exploited in the same manner—by injecting code into the web view. Nonetheless, as their apps and framework customization use different configurations and versions, not all providers are necessarily vulnerable to all the discovered vulnerabilities.
We found a command-injection vulnerability, tracked as CVE-2021-42599, in the Device service mentioned in the previous section. This service offers rich functionality, including the capability to stop activities of a given package. The client fully controls the argument “value,” and simply runs the following command:
am force-stop "value"
Since the argument is not sanitized, an attacker could add backticks or quotation marks to run arbitrary code, like the following:
am force-stop "a"; command-to-run; echo "a"
Figure 4: Command injection proof-of-concept (POC) exploit code implemented in the Device service
According to mce Systems, they have since removed the functionality behind this vulnerability and it is no longer present in more advanced framework versions.
Exploitation by JavaScript injection with PiTM in certain apps
The services offered by the mce framework further indicated that the following vulnerability resided in the logic of the JavaScript client for apps that are configured to enable plaintext communications such as the app that we initially analyzed. Interestingly, the code for the client is a heavily-obfuscated dynamic JavaScript code that is implemented over several files, mainly bundle.js. Due to the blind trust between the JavaScript client and the JarvisJSInterface server, an attacker who could inject JavaScript contents into the WebView would inherit the permissions that the app already has.
We conceived two injection strategies most likely to be leveraged by attackers:
Affect the JavaScript client behavior by supplying specific GET parameters from the BROWSABLE Intent.
Trigger an app with the BROWSABLE Intent to become a person-in-the-middle (PiTM) and view the device’s entire traffic. Inject JavaScript code if the client ever tries to fetch external content and interpret it as a script or HTML.
Once we reverse-engineered the client’s obfuscated code, we discovered that it could not inject JavaScript from the GET parameters. The only capability permitted was to affect some of the client’s self-tests upon initialization, such as a battery-draining test or a Wi-Fi connectivity test. However, the WebView-fetched plaintext pages that we discovered could be injected into with a PiTM attack.
Our proof-of-concept (POC) exploit code was therefore:
Perform a PiTM for the target device and lure the user into clicking a link with the “mcesystems://” schema.
Inject JavaScript into one of the plaintext page responses that does the following:
Hijack the JavaScript interface by calling init with our callback method
Use the JavaScript interface request method to get servicing
Send the data to our server for information gathering using XHR (XMLHttpRequest)
Figure 5: Injecting a similar JavaScript code to the WebView could allow an attacker to call arbitrary services and methods
Local elevation of privilege with deserialization followed by injection (CVE-2021-42601)
Some of the apps we analyzed did not pull plaintext pages. Thus, we looked for a local elevation of privilege vulnerability, allowing a malicious app to gain the system apps’ privileges, tracked as CVE-2021-42601.
In the apps mentioned above, we discovered that the main Activity attempted to handle a deep link (a link that launches an app instead of a browser on click) with Google Firebase. Interestingly, this deep-link handling tried to deserialize a structure called PendingDynamicLinkData (representing a link) from an Intent Extra byte array with the key com.google.firebase.dynamiclinks.DYNAMIC_LINK_DATA. This structure was used later by the mce framework to generate various JSON Objects that might contain data from a categoryId query parameter in the original link, and eventually ended up in the member mFlowSDKInput to be injected into the JarvisWebView instance in an unsafe way:
Figure 6: Unsanitized JavaScript loading allowed arbitrary code injection to the WebView
Since the categoryId query parameter might contain apostrophes, one could inject arbitrary JavaScript code into the WebView. We decided to inject a code that would reach out to a server and load a second-stage code, which was the exact one we used for our PiTM scenario.
Figure 7: Local injection POC exploit
Software design against JavaScript injection vulnerabilities
We worked closely with the mce Systems engineering team and discovered that the reason for unsafe loadUrl invocations with JavaScript injections was that the framework used an asynchronous model of operation. When the JavaScript client performs a request, it expects to be notified later when there are results. Since Android JavaScript Bridge only allows primitive types to be sent (for example, Strings), the mce framework notified the JavaScript client by injecting JavaScript with potentially unsafe arguments (the results themselves).
We offered mce Systems a slightly different software design that prevents unsafe JavaScript injection. The description of the flow of information in our proposal is as follows:
The JavaScript client invokes the request method on the Android JavaScript Bridge, supplying the request itself along with a request ID.
The Java server performs the request and stores the result in a cache. The said cache then maps request IDs to results.
The Java server notifies the client by carefully injecting the JavaScript loadUrl(“javascript:window.onMceResult(<requestID>);”) into the WebView. Note that the only non-constant string is the request ID, which can easily be sanitized. This method “wakes the client up”
The JavaScript client implementation of onMceResult invokes the Android JavaScript Bridge with the method String fetchResult(String requestId). Note that this method returns a string (which contains the result).
This way, the JavaScript client does not need to poll for asynchronous results while data is safely transferred between the client and the server.
Interestingly, Google AndroidX offers a very similar API: webMessageListener. While the said API works quite similarly to our suggestion, it only supports Android versions greater than Lollipop. Thus, the new mce framework now checks the Android version and uses this new Google API if supported or our offered solution for older devices.
The above is just one example of our collaboration to help secure our cross-platform ecosystem. According to mce Systems, all of our reported vulnerabilities were addressed.
Improving security for all through threat intelligence sharing and research-driven protections
Microsoft strives to continuously improve security by collaborating with customers, partners, and industry experts. Responding to the evolving threat landscape requires us to expand our capabilities into other devices and non-Windows platforms in addition to further coordinating research and threat intelligence sharing among the larger security community. This case highlighted the need for expert, cross-industry collaboration to effectively mitigate issues.
Moreover, collaborative research such as this informs our seamless protection capabilities across platforms. For example, intelligence from this analysis helped us ensure that Microsoft Defender Vulnerability Management can identify and remediate devices that have these vulnerabilities, providing security operations teams with comprehensive visibility into their organizational exposure and enabling them to reduce the attack surface. In addition, while we’re not aware of any active exploitation of these mobile vulnerabilities in the wild, Microsoft Defender for Endpoint’s mobile threat defense capabilities significantly improve security on mobile devices by detecting potential exploits, malware, and post-exploitation activity.
We will continue to work with the security community to share intelligence about threats and build better protection for all. Microsoft security researchers continually work to discover new vulnerabilities and threats, turning a variety of wide-reaching issues into tangible results and improved solutions that protect users and organizations across platforms every single day. Similarly inquisitive individuals are encouraged to check opportunities to join the Microsoft research team here: https://careers.microsoft.com/.
Jonathan Bar Or, Sang Shin Jung, Michael Peck, Joe Mansour, and Apurva Kumar Microsoft 365 Defender Research Team
On April 24, 2022, a privilege escalation hacking tool, KrbRelayUp, was publicly disclosed on GitHub by security researcher Mor Davidovich. KrbRelayUp is a wrapper that can streamline the use of some features in Rubeus, KrbRelay, SCMUACBypass, PowerMad/SharpMad, Whisker, and ADCSPwn tools in attacks.
Although this attack won’t function for Azure Active Directory (Azure AD) joined devices, hybrid joined devices with on-premises domain controllers remain vulnerable. Microsoft Defender for Identity detects activity from the early stages of the attack chain by monitoring anomalous behavior as seen by the domain controller. In addition, signals from Defender for Identity also feed into Microsoft 365 Defender, providing organizations with a comprehensive solution that detects and blocks suspicious network activities, malicious files, and other related components of this attack. Microsoft Defender Antivirus detects this attack tool as the malware family HackTool:MSIL/KrbUpRly.
Microsoft encourages customers to update Domain Controller: LDAP server signing requirements to Require signing as detailed in this advisory and enable Extended Protection for Authentication (EPA) as detailed in this blog.
Originally, KrbRelayUp supported only one method that’s based on taking advantage of resource-based constrained delegation (RBCD); it later added several additional attack methods. In this blog, we discuss RBCD to provide further insights into how the initial KrbRelayUp attack method works. We also detail the stages that make up the said attack. Finally, we provide recommendations and guidelines that can help organizations strengthen their device configurations and defend their networks from attacks that use this tool.
Understanding the attack: What is resource-based constrained delegation?
Resource-based constrained delegation (RBCD) represents the key to this attack method, enabling the tool to impersonate an administrator and eventually run a code as the SYSTEM account of a compromised device.
Authentication protocol basics
An authentication protocol verifies the legitimacy of a resource or identity. When a user signs into a website, that website uses a methodology to confirm the authenticity of the resource requesting access. In simpler terms, the authentication process involves signing in with a password—made possible by the user knowing the password anticipated by the website. The Kerberos protocol serves as the main authentication framework for this process in on-premises Active Directory.
Delegation
Sometimes, however, a resource needs to request access to another resource on behalf of a different identity. A common example of this is mail delegation, wherein executives often give delegation rights to their executive assistants to send and receive emails on their behalf without providing the assistant with the executive’s password. The executive assistant isn’t authenticating as the executive; the executive has just allowed the assistant’s account to “pretend” that they are.
Resource-based constrained delegation
Initially, only users with the SeEnableDelegation role could configure delegation, typically domain admins. These domain admins can manage resources and dictate which identities can act on behalf of a different resource. They achieve this by updating the msDS-AllowedToDelegateTo property of a user account or device. This property contains a list of all the unique identifiers (service principal names, or SPNs) to which this object can delegate or act on behalf of.
However, as organizations expanded, administrators struggled to manage all the delegation requirements, raising the need for a new type of delegation: resource-based. For instance, in an organization with several file servers that all trust a web server for delegation, an admin would have to change the msDS-AllowedToDelegateTo priority in all of the different file servers to introduce a second web server. With resource-based delegation, the list of trusted computers is held on the receiving end. Thus, in our example, only the newly created server would require a change of settings.
Unsigned LDAP and relay attacks
For the RBCD method of the KrbRelayUp tool to work, the LDAP protocol must not use signing to communicate between LDAP clients and domain controllers. While this setting is still the default on Windows, as of 2019 Microsoft recommends configuring LDAP to use LDAP channel binding and signing.
LDAP is one of the main protocols that directory services tools, such as Active Directory, use to query and access directory information. By default, LDAP is vulnerable to credential relaying attacks. For example, in a credential relaying attack, a web server requesting a password to sign in would have its request relayed by an attacker to an authorized client. The attacker then relays the client reply containing the correct password back to the server, thus signing in. Once the attacker is signed in, they have the same permissions as the user whose credentials were relayed.
If LDAP signing is required, each request to the server needs to be cryptographically signed. In this case, the attacker would still be able to relay the sign-in request and reply, but all further requests from the attacker would be disregarded because each request must be signed, and the attacker doesn’t have the proper keys to do the signing.
Ms-DS-MachineAccountQuota
The final key concept behind the RBCD method of KrbRelayUp tool is the ms-DS-MachineAccountQuota attribute, which all User Active Directory objects have. This attribute is set to 10 by default, which means that any user in Active Directory can create up to 10 computer accounts associated with them. The legitimate usage of this attribute is to allow users to have multiple devices on a network that belong to them that they can then manage. However, if a compromised user doesn’t have 10 actual devices associated with their account, an attacker can create an account for a non-existing device that will be an object in Active Directory. This fake computer account isn’t associated with a real device but can perform Active Directory authentication requests as if it were.
Initially, the ability to obtain such an account was a prerequisite for this attack method, but since the release of the tool, other security researchers found ways to get around this requirement.
KrbRelayUp attack flow
To launch an attack using the RBCD method of KrbRelayUp, an attacker performs four main steps:
Step 1: Acquisition of a suitable resource
The attacker first obtains a resource suitable to be the source of an RBCD. There are several ways to obtain such a resource; the most straightforward way is to create a new computer account as discussed above.
Step 2: Modification of the msDS-AllowedToActOnBehalfOfOtherIdentity attribute
Next, the attacker adds their resource to the current device’s list of trusted resources. To do this, the attacker starts an LDAP session and relays the credentials of the current device to the LDAP server.
The new KrbRelayUp tool implements this step with these two smaller consecutive actions:
Authenticates to the LDAP service by triggering and performing a Kerberos relay attack
Edits the msDS-AllowedToActOnBehalfOfOtherIdentity attribute to add the attacker’s resource to the list of entities permitted to delegate the target device.
Step 3: Privileged ticket acquisition
Here, the attacker leverages their control over their resource gained through the first step with the trust for their resource gained through the second step. As such, the local device trusts the attacker’s resource to request a ticket addressed to the host SPN as the domain administrator. The request is made by first pretending to be the attacker’s resource and consists of three requests:
AS-Req – A request to generate a Ticket Granting Ticket (TGT) for the attacker’s impersonated resource.
S4U2self – A request to generate a Ticket Granting Service (TGS) ticket from an administrator to the resource.
S4U2proxy – A request to generate a TGS ticket for the host SPN as an administrator delegating their access via the impersonated resource.
After this step, the attacker has a valid ticket for the local device that allows the administrator to be impersonated.
Step 4: Privileged ticket leverage
The last step leverages the attacker’s newly acquired ticket to run code on the device. In the attack, as it’s published online, the Service Control Manager (SCM) is asked to create a new service with SYSTEM permissions.
Protecting against KrbRelayUp attacks through coordinated threat defense
It’s important to note that KrbRelayUp cannot be used in attacks against organizations that are only using Azure AD. However, in hybrid identity environments where organizations synchronize their domain controllers with Azure AD, if an attacker compromises an Azure virtual machine using a synchronized account, they’ll receive SYSTEM privileges on the virtual machine.
To reduce the impact of this threat, organizations should apply the mitigations below. Microsoft 365 Defender customers can check the recommendations card for the deployment status of monitored mitigations.
Organizations should also consider setting the ms-DS-MachineAccountQuota attribute to 0 to make it more difficult for an attacker to leverage the attribute for attacks. Setting the attribute to 0 stops non-admin users from adding new devices to the domain, blocking the most effective method to carry out the attack’s first step and forcing attackers to choose more complex methods to acquire a suitable resource.
Detection details
Organizations should also deploy a comprehensive security solution like Microsoft 365 Defender to detect and block this threat across the stages of the attack chain. Microsoft 365 Defender has multiple layers of dynamic protection technologies, including machine learning-based protection, and correlates threat data from email, endpoints, identities, and cloud apps to provide in-depth and coordinated threat defense. All of these are backed by threat experts who continuously monitor the threat landscape for new attacker tools and techniques.
Microsoft Defender for Identity detects activity from the first three steps of the attack flow by monitoring anomalous behavior as seen by the domain controller. Starting in version 2.180, Defender for Identity has two detections that raise an alert when this attack is attempted:
Suspicious Kerberos delegation attempt by a newly created computer.
Suspicious edit of the Resource Based Constrained Delegation Attribute by a machine account (KrbRelayUp).
Figure 1. ‘Suspicious Kerberos delegation attempt by a newly created computer’ alert in Microsoft Defender for Identity
Microsoft Defender for Endpoint includes new and enhanced network inspection capabilities to correlate network and endpoint signals and emit high-confidence alerts. Defender for Endpoint leverages these network signals and looks for suspicious LDAP and Kerberos requests to Active Directory domain controllers to accurately detect attacks using KrbRelayUp. Defender for Endpoint also detects suspicious Kerberos sign-ins and service creations.
Figure 2. ‘Possible Kerberos local privilege escalation relay attack’ alert in Microsoft Defender for Endpoint
Microsoft 365 Defender customers may refer to the threat analytics report to determine if this threat is present in their network and to get additional details and recommendations. Threat analytics enables organizations to assess the impact of a threat to their network, review exposure and resilience, and perform mitigation, recovery, or prevention actions to stop or contain active attacks.
In 2020, MSRC awarded two Identity Project Research Grants to support external researchers working to further strengthen the security of identity protocols and systems. Today we are pleased to release the results of the first of these projects. This research, led by independent security researcher Avinash Sudhodanan, investigated account pre-hijacking – a new class of …
Amplification attacks are one of the most common distributed denial of service (DDoS) attack vectors. These attacks are typically categorized as flooding or volumetric attacks, where the attacker succeeds in generating more traffic than the target can process, resulting in exhausting its resources due to the amount of traffic it receives.
In this blog, we start by surveying the anatomy and landscape of amplification attacks, while providing statistics from Azure on most common attack vectors, volumes, and distribution. We then describe some of the countermeasures taken in Azure to mitigate amplification attacks.
DDoS amplification attacks, what are they?
Reflection attacks involve three parties: an attacker, a reflector, and a target. The attacker spoofs the IP address of the target to send a request to a reflector (e.g., open server, middlebox) that responds to the target, a virtual machine (VM) in this case. For the attack to be amplified the response should be larger than the request, resulting in a reflected amplification attack. The attacker’s motivation is to create the largest reflection out of the smallest requests. Attackers achieve this goal by finding many reflectors and crafting the requests that result in the highest amplification.
Figure 1. Reflected amplification attack
The root cause for reflected amplification attacks is that an attacker can force reflectors to respond to targets by spoofing the source IP address. If spoofing was not possible, this attack vector would be mitigated. Lots of effort has thus been made on disabling IP source address spoofing, and many organizations prevent spoofing nowadays so that attackers cannot leverage their networks for amplification attacks. Unfortunately, a significant number of organizations still allow source spoofing. The Spoofer project shows that a third of the IPv4 autonomous systems allow or partially allow spoofing.
UDP and TCP amplification attacks
Most attackers utilize UDP to launch amplification attacks since reflection of traffic with spoofed IP source address is possible due to the lack of proper handshake.
While UDP makes it easy to launch reflected amplification attacks, TCP has a 3-way handshake that complicates spoofing attacks. As a result, IP source address spoofing is restricted to the start of the handshake. Although the TCP handshake allows for reflection, it does not allow for easy amplification since TCP SYN+ACK response is not larger than TCP SYN. Moreover, since the TCP SYN+ACK response is sent to the target, the attacker never receives it and can’t learn critical information contained in the TCP SYN+ACK needed to complete the 3-way handshake successfully to continue making requests on behalf of the target.
Figure 2. Reflection attack in TCP
In recent years, however, reflection and amplification attacks based on TCP have started emerging.
Independent research found newer TCP reflected amplification vectors that utilize middleboxes, such as nation-state censorship firewalls and other deep packet inspection devices, to launch volumetric floods. Middleboxes devices may be deployed in asymmetric routing environments, where they only see one side of the TCP connection (e.g., packets from clients to servers). To overcome this asymmetry, such middleboxes often implement non-compliant TCP stack. Attackers take advantage of this misbehavior – they do not need to complete the 3-way handshake. They can generate a sequence of requests that elicit amplified responses from middleboxes and can reach infinite amplification in some cases. The industry has started witnessing these kinds of attacks from censorship and enterprise middle boxes, such as firewalls and IDPS devices, and we expect to see this trend growing as attackers look for more ways to create havoc utilizing DDoS as a primary weapon.
Carpet bombing is another example of a reflected amplification attack. It often utilizes UDP reflection, and in recent years TCP reflection as well. With carpet bombing, instead of focusing the attack on a single or few destinations, the attacker attacks many destinations within a specific subnet or classless inter-domain routing (CIDR) block (for example /22). This will make it more difficult to detect the attack and to mitigate it, since such attacks can fly below prevalent baseline-based detection mechanisms.
Figure 3. Carpet bombing attack
One example of TCP carpet bombing is TCP SYN+ACK reflection, where attacker sends spoofed SYN to a wide range of random or pre-selected reflectors. In this attack, amplification is a result of reflectors that retransmit the TCP SYN+ACK when they do not get a response. The amplification of the TCP SYN+ACK response itself may not be large, and it depends on the number of retransmissions sent by the reflector. In Figure 3, the reflected attack traffic towards each of the target virtual machines (VMs) may not be enough to bring them down, however, collectively, the traffic may well overwhelm the targets’ network.
UDP and TCP amplification attacks in Azure
In Azure, we continuously work to mitigate inbound (from internet to Azure) and outbound (from Azure to internet) amplification attacks. In the last 12 months, we mitigated approximately 175,000 UDP reflected amplification attacks. We monitored more than 10 attack vectors, where the most common ones are NTP with 49,700 attacks, DNS with 42,600 attacks, SSDP with 27,100 attacks, and Memcached with 18,200 attacks. These protocols can demonstrate amplification factors of up to x4,670, x98, x76 and x9,000 respectively.
Figure 4. UDP reflected amplification attacks observed from April 1, 2021, to March 31, 2022
We measured the maximum attack throughput in packets per second for a single attack across all attack vectors. The highest throughput was a 58 million packets per second (pps) SSDP flood in August last year, in a short attack campaign that lasted 20 minutes on a single resource in Azure.
Figure 5. Maximum pps recorded for a single attack observed from April 1, 2021, to March 31, 2022
TCP reflected amplification attacks are becoming more prevalent, with new attack vectors discovered. We encounter these attacks on Azure resources utilizing diverse types of reflectors and attack vectors.
One such example is a TCP reflected amplification attack of TCP SYN+ACK on an Azure resource in Asia. Attack reached 30 million pps and lasted 15 minutes. Attack throughput was not high, however there were approximately 900 reflectors involved, each with retransmissions, resulting in a high pps rate that can bring down the host and other network infrastructure elements.
Figure 6. TCP SYN+ACK amplification attack volume on an Azure resource in Asia
We see many TCP SYN+ACK retransmissions associated with the reflector that doesn’t get the ACK response from the spoofed source. Here is an example of such a retransmission:
The retransmitted packet was sent 60 seconds after the first.
Mitigating amplification attacks in Azure
Reflected amplification attacks are here to stay and pose a serious challenge for the internet community. They continue to evolve and exploit new vulnerabilities in protocols and software implementations to bypass conventional countermeasures. Amplification attacks require collaboration across the industry to minimize their effect. It is not enough to mitigate such attacks at a certain location, with a pinpoint mitigation strategy. It requires intertwining of network and DDoS mitigation capabilities.
Azure’s network is one of the largest on the globe. We combine multiple DDoS strategies across our network and DDoS mitigation pipeline to combat reflected amplification DDOS attacks.
On the network side, we continuously optimize and implement various traffic monitoring, traffic engineering and quality of service (QoS) techniques to block reflected amplification attacks right at the routing infrastructure. We implement these mechanisms at the edge and core of our wide area networks (WAN) network, as well as within the data centers. For inbound traffic (from the Internet), it allows us to mitigate attacks right at the edge of our network. Similarly, outbound attacks (those that originate from within our network) will be blocked right at the data center, without exhausting our WAN and leaving our network.
On top of that, our dedicated DDoS mitigation pipeline continuously evolves to offer advanced mitigation techniques against such attacks. This mitigation pipeline offers another layer of protection, on top of our DDoS networking strategies. Together, these two protection layers provide comprehensive coverage against the largest and most sophisticated reflected amplification attacks.
Since reflected amplification attacks are typically volumetric, it is not only enough to implement advanced mitigation strategies, but also to maintain a highly scalable mitigation pipeline to be able to cope with the largest attacks. Our mitigation pipeline can mitigate more than 60Tbps globally, and we continue to evolve it by adding mitigation capacity across all network layers.
Different attack vectors require different treatment
UDP-based reflected amplification attacks are tracked, monitored, detected, and mitigated for all attack vectors. There are various mitigation techniques to combat these attacks, including anomaly detection across attacked IP addresses, L4 protocols, and tracking of spoofed source IPs. Since UDP reflected amplification attacks often create fragmented packets, we monitor IP fragments to mitigate them successfully.
TCP-based reflected amplification attacks take advantage of poor TCP stack implementations, and large set of reflectors and targets, to launch such attacks. We adopt our mitigation strategies to be able to detect and block attacks from attackers and reflectors. We employ a set of mitigations to address TCP SYN, TCP SYN+ACK, TCP ACK, and other TCP-based attacks. Mitigation combines TCP authentication mechanisms that identify spoofed packets, as well as anomaly detection to block attack traffic when data is appended to TCP packets to trigger amplification with reflectors.
Figure 7. Amplification attack detection
Get started with Azure DDoS Protection to protect against amplification attacks
Azure’s DDoS mitigation platform mitigated the largest ever DDoS attacks in history by employing a globally distributed DDoS protection platform that scales beyond 60Tbps. We ensure our platform and customers’ workloads are always protected against DDoS attacks. To enhance our DDoS posture, we continuously collaborate with other industry players to fight reflected amplification attacks.
Azure customers are protected against Layer 3 and Layer 4 DDoS attacks as part of protecting our infrastructure and cloud platform. However, Azure DDoS Protection Standard provides comprehensive protection for customers by auto-tuning the detection policy to the specific traffic patterns of the protected application. This ensures that whenever there are changes in traffic patterns, such as in the case of flash crowd event, the DDoS policy is automatically updated to reflect those changes for optimal protection. When a reflected amplification attack is launched against a protected application, our detection pipeline detects it automatically based on the auto-tuned policy. The mitigation policy, that is automatically set for customers, without their need to manually configure or change it, includes the needed countermeasures to block reflected amplification attacks.
Protection is simple to enable on any new or existing virtual network and does not require any application or resource changes. Our recently released Azure built-in policies allow for better management of network security compliance by providing great ease of onboarding across all your virtual network resources and configuration of logs.
To strengthen the security posture of applications, Azure’s network security services can work in tandem to secure your workloads, where DDoS protection is one of the tools we provide. Organizations that pursue zero trust architecture can benefit from our services to achieve better protection.
“Compliance is all about risk management and lessening risk, and the same is true of Zero Trust.”
—Abbas Kudrati
What’s risk management and why is it important?
Risk management, the process of developing a strategy for addressing risk throughout its lifecycle, normally involves four phases: risk identification, assessment, response, and monitoring and reporting.
Risk management plays a critical role in helping organizations with their security posture enhancement. Taking insider incidents as an example, they are not only costly to organizations but also time-consuming to be contained. Given the limited resources available, we have seen many organizations often prioritize investment in security controls, which can address the more critical risks. As such, the return on investment (ROI) is maximized in effectively protecting the organizations’ assets as well as ensuring their business operations. Risk management is an ongoing activity. Are the long-established risk management programs in the enterprises staying on top of the evolving digital and threat landscapes?
With trends like digital transformation, cloud migration, and hybrid work, traditional trust boundaries are getting blurred. Perimeter-driven defense is no longer adequate in protecting against the rising attack vectors. More attention has been drawn to the Zero Trust security model that assumes attackers are in the enterprise environment and encourages organizations to always verify explicitly and enforce least-privilege access.
How can Zero Trust architecture help with risk management?
Microsoft approaches the following Zero Trust architecture as a reference for customers to defend their digital estates.
Let’s look at how Zero Trust architecture can help an organization effectively manage enterprise risk management practice throughout the four phases:
1. Identification: More thorough asset discovery and risk identification with the six pillars
In the initial step of risk management, organizations need to categorize the system and information processed, stored, and transmitted based on impact analysis. With prioritization, activities of identifying threats and vulnerability to the assets are then performed. The Zero Trust architecture emphasizes the full coverage of organization assets across the entire digital estate, with six pillars specified as identity, endpoint, network, data, application, and infrastructure. Following the reference architecture would allow organizations to obtain a holistic view of their IT landscapes and associated risks.
Some questions for organizations to consider during the asset discovery and risk identification phase:
What types of structured and unstructured data do you create, process, and store? Are all data classified, labeled, and encrypted?
What applications do you access? Are they in the cloud or on-premises?
What types of infrastructure do you manage—in the cloud or on-premises?
Who has access to your resources, including network, data, applications, and infrastructure? Are they internal or external stakeholders, human or non-human actors? How are the authentication and authorization of the identities enforced?
From which endpoints are access to your resources allowed? Are they owned by a company or individuals? How is device management performed and compliance reviewed?
What are the normal and abnormal paths of an identity accessing your resources of any kind?
2. Assessment: Continuous risk assessment as input to access control evaluation and enforcement
Typically, a risk assessment on an information asset is performed periodically or upon major changes. It allows organizations to determine the potential risks and evaluate if the existing processes and controls are sufficient to lower the risks to an acceptable level. In the more dynamic digital world where attacks happen at cloud speed, Zero Trust architecture recommends continuous risk assessment—each request shall be intercepted and verified explicitly by analyzing signals on user, location, device compliance, data sensitivity, and application type. In addition, rich intelligence and analytics can be leveraged to detect and respond to anomalies in real-time, enabling effective risk management at the request level.
In addition, the security controls included in the Zero Trust architecture enable defense-in-depth, which shall be taken into consideration during regular risk assessment at system or organizational levels. With identity being the new first line of defense, strong multifactor authentication helps to determine if the actor is who it claims to be, reducing the likelihood of unauthorized access. Device compliance check then helps to reduce the likelihood of actors using compromised or outdated endpoints to access organization resources. In case of a breach, network micro-segmentation based on least-privilege access principle will minimize the lateral movement of malicious actors, narrowing the attack surface and containing the damage. Encryption of data in transit and at rest renders data unreadable and unusable without decryption keys, further lessening the impact of data breaches.
3. Response: Real-time responsive measures to mitigate risks throughout the request life cycle
Zero Trust architecture can also be aligned with the four general categories of risk response strategies: tolerate, operate, monitor, and improve. By design, it is recommended that telemetry, state information, and risk assessment from threat protection shall all feed into the Zero Trust policy engine to enable automatic response to threats immediately. Upon collection and evaluation of all risk signals from various sources, Zero Trust policies shall be enforced in real-time to allow, deny, restrict, or further authenticate access requests. Such approaches offer great responsiveness to risks detected in real-time throughout a request lifecycle, allowing organizations to address risks in a timely manner.
4. Monitoring and reporting: Visibility at all levels empowering risk monitoring and reporting
Risk monitoring and reporting are also critical components to ensure risk governance and assurance. It is common for organizations to keep risk monitoring and reporting at the system level. With Zero Trust architecture, organizations would benefit from the flexibility of gaining visibility at all levels into risks. At the granular level, risks of a single-user identity or sign-in will be evaluated, logged, and reported. With IT and security tools integrated, other potential breach indicators like a high volume of data access and transfer and malware detection can be associated, allowing the first line of the risk management team to obtain all necessary details for investigation. The rich threat and vulnerability data can be further processed to offer an aggregated view of an organization’s risk posture, making the risk reporting to senior management and auditors more accurate and hassle-free. With the insights generated from risk monitoring and reporting, risk management strategy and policy can be continuously reviewed and improved to stay relevant and effective.
Organizations may leverage the free Microsoft Zero Trust Maturity Assessment Quiz to understand their current state of Zero Trust maturity and our recommendations on the next steps. More details of how Microsoft can empower organizations in their Zero Trust journeys can be found in the Zero Trust Essentials eBook.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.
Microsoft security researchers recently observed that web skimming campaigns now employ various obfuscation techniques to deliver and hide skimming scripts. It’s a shift from earlier tactics where attackers conspicuously injected malicious scripts into e-commerce platforms and content management systems (CMSs) via vulnerability exploitation, making this threat highly evasive to traditional security solutions. As of this writing, some of the latest skimming HTML and JavaScript files uploaded in VirusTotal have very low detection rates.
Web skimming typically targets platforms like Magento, PrestaShop, and WordPress, which are popular choices for online shops because of their ease of use and portability with third-party plugins. Unfortunately, these platforms and plugins come with vulnerabilities that the attackers have constantly attempted to leverage. One notable web skimming campaign/group is Magecart, which gained media coverage over the years for affecting thousands of websites, including several popular brands.
In one of the campaigns we’ve observed, attackers obfuscated the skimming script by encoding it in PHP, which, in turn, was embedded inside an image file—a likely attempt to leverage PHP calls when a website’s index page is loaded. Recently, we’ve also seen compromised web applications injected with malicious JavaScript masquerading as Google Analytics and Meta Pixel (formerly Facebook Pixel) scripts. Some skimming scripts even had anti-debugging mechanisms, in that they first checked if the browser’s developer tools were open.
Given the scale of web skimming campaigns and the impact they have on organizations and their customers, a comprehensive security solution is needed to detect and block this threat. Microsoft 365 Defender provides a coordinated defense that’s enriched by our visibility into attacker infrastructure and continuous monitoring of the threat landscape.
In this blog, we provide the technical details of the recent skimming campaigns’ obfuscation techniques. We also offer steps for defenders and users to protect themselves and their organizations from such attacks.
How web skimming works
This primary goal of web skimming campaigns is to harvest and later exfiltrate users’ payment information, such as credit card details, during checkout. To achieve this, attackers typically take advantage of vulnerabilities in e-commerce platforms and CMSs to gain access to pages they want to inject the skimming script into. Another common method is web-based supply chain attacks, where attackers use vulnerabilities in installed third-party plugins and themes or compromise ad networks that may inevitably serve malicious ads without the site owner’s knowledge or consent.
Figure 1. Overview of a web skimming attack
As mentioned earlier, one notable skimming campaign is Magecart. First observed in 2010, Magecart campaigns have increased in number and become stealthier through heavy obfuscation techniques, new injection points, and delivery methods. In the last five years, popular organizations or brands have been affected by Magecart—from an airline company and online ticketing services to a sports brand and personal transporter. In 2019, tens of thousands of websites got compromised because of a misconfiguration in the cloud service provider where these sites were hosted. Such an increase in these types of attacks prompted the Payment Card Industry Security Standards Council (PCI SSC) to release a bulletin that warns users about the threat. In April 2022, PCI also released a major revision in its Data Security Standard (DSS), which now includes additional requirements for e-commerce environments to help prevent skimming.
Recent developments
In their earlier iterations, most web skimming campaigns directly targeted unpatched e-commerce platforms like Magento. Also, the malicious JavaScript they injected were very conspicuous. However, as the campaigns’ attack vectors and routines evolved, attackers also started using different techniques to hide their skimming scripts.
Malicious images with obfuscated script
During our research, we came across two instances of malicious image files being uploaded to a Magento-hosted server. Both images contained a PHP script with a Base64-encoded JavaScript, and while they had identical JavaScript code, they slightly differed in their PHP implementation. The first image, disguised as a favicon (also known as a shortcut or URL icon), was available on VirusTotal, while the other one was a typical web image file discovered by our team. Their hashes are included in the Indicators of compromise section below.
We first observed the malicious favicon in November 2021, when a few campaigns started dropping remote access trojans (RATs) on target web servers, in addition to injecting scripts into web pages. This delivery method moves away from the usual modus; it appears that attackers are now targeting the server side to inject their scripts, enabling them to bypass conventional browser protections like Content Security Policy (CSP), which prevents the loading of any external scripts. Meanwhile, the more recent image file was uploaded on the /media/wysiwyg/ directory, most likely by leveraging a vulnerability in the Magento CMS.
The insertion of the PHP script in an image file is interesting because, by default, the web server wouldn’t run the said code. Based on previous similar attacks, we believe that the attacker used a PHP include expression to include the image (that contains the PHP code) in the website’s index page, so that it automatically loads at every webpage visit.
In both images’ cases, once the embedded PHP script was run, it first retrieved the current page’s URL and looked for the “checkout” and “onepage” keywords, both of which are mapped to Magento’s checkout page.
Figure 2. Screenshot of a Magento shopping cart page with the “checkout” keyword in the URL
Before serving the skimming script, the PHP script also checked that administrator cookies weren’t set to ensure that a web admin isn’t currently signed in. Such a check ensured that the script only targeted the site visitors (online shoppers).
Figure 3. Portion of the PHP script that checks for admin cookies
The skimming script was encoded multiple times using hexadecimal (Base16) and then Base64. When decoded, it had an array of strings that were referenced and substituted further to construct a complete JavaScript code. Below are snippets of the decoded skimming script.
The boms() function (Figure 4) was responsible for creating and serving the fake checkout payment form (Figure 5) that collected target users’ payment details.
Figure 4. Portion of the skimming script that creates and serves the fake checkout payment formFigure 5. Sample screenshot of the fake checkout form that collects user payment details
The said function is only triggered if the __ffse cookie value wasn’t set to “236232342323626326”—most probably a check to ensure that the website isn’t already infected.
Figure 6. Portion of the skimming script that checks for a specific cookie value
When the user submitted their details in the fake form, the glob_snsd() function is triggered (Figure 7), which then collected the said details in the form elements (input, select), encoded them in hex and Base64, and finally added them to the cookies (Figure 8).
Figure 7. Portion of the skimming script that launches the credential theft and exfiltration routinesFigure 8. Portion of the skimming script that performs the credential theft routine
The encoded stolen information was then exfiltrated to an attacker-controlled C2 via PHP curl requests.
Figure 9. Portion of the skimming script that performs the exfiltration routine
Concatenated and encoded skimming host URL
We also came across four lines of JavaScript injected into a compromised webpage. Like the malicious images we previously analyzed, the script in this scenario would run only when it finds the “checkout” keyword in the target web page URL. It would then fetch the skimming script hosted on an attacker-controlled domain to load a fake checkout form.
The attacker-controlled domain was encoded in Base64 and concatenated from several strings. As of this writing, the said domain is still active.
Figure 10. Code snippet containing the concatenated and encoded URL that hosts the skimming script
The skimming script itself wasn’t obfuscated and had two main functions: getData() and __send(). getData() was responsible for getting form data on the web page, converting them to JSON, and passing it onto __send(). Interestingly, this function also checked for crawlers and other possible debugging attempts before skimming data. It specifically checked if the user had opened the browser developer tool, as seen in the snippet below:
if (devtools.open) return; if (/bot|googlebot|crawler|spider|robot|crawling/i.test(navigator.userAgent)) return;
The __send() function, in turn, created an image object and prepared the URL for exfiltration. Note that while it formed the image, this function loaded the URL with the captured data in the dataparameter. The parameter value was also encoded in Base64.
Figure 11. Snippet of the hosted script that exfiltrates web page data
Google Analytics and Meta Pixel script spoofing
Attackers have also started masquerading as Google Analytics and Meta Pixel (formerly Facebook Pixel) scripts to trick site administrators or developers into thinking they’re looking at non-malicious codes, thus evading detection.
The screenshot below illustrates how a Base64-encoded string was placed inside a spoofed Google Tag Manager code. This string decoded to trafficapps[.]business/data[.]php?p=form.
Figure 12. Encoded skimming script in a spoofed Google Analytics code
We also observed a similar technique where the skimming script mimicked Meta Pixel’s function parameters and JavaScript file name to avoid detection. Like the example in the previous section, the URL in this technique was encoded in Base64 and split into several strings. The concatenated string decoded to //sotech[.]fun/identity[.]js, and it contained obfuscated code. Interestingly, the decoded URL also had the query string d=GTM-34PX2SO, which is specific to Google Tag Manager and not Meta Pixel.
Figure 13. Encoded skimming script in a spoofed Meta Pixel code
The attackers behind the Meta Pixel spoofing used newly registered domains (NRDs) hosted on HTTPS to carry out their attacks. All the domains we saw associated with this skimming campaign were registered around the same time via a popular budget hosting provider, as seen in the list below. However, the actual hosting sites were hidden behind Cloudflare’s infrastructure.
sotech[.]fun – created August 30, 2021
techlok[.]bar – created September 3, 2021
dratserv[.]bar – created September 15, 2021
The hosted script had multiple layers of obfuscation. Based on what we were able to partially de-obfuscate, not only did the code serve the skimming script, but it also did the following:
perform an anti-debugging technique – function isDebugEnabled()
Figure 14. Snippet of the encoded skimming script
Defending against web skimming
For organizations, the impact of web skimming campaigns could translate into monetary loss, reputation damage, and loss of customer trust. Web administrators and other defenders should therefore keep a close eye on such attacks. As it is, web skimming scripts closely resemble other JavaScript code used to perform legitimate business functions like web analytics. In addition, skimming scripts aren’t only found in HTML files; CSS, SVG, and other file types can also embed code that runs JavaScript once the related web pages load.
Given the increasingly evasive tactics employed in skimming campaigns, organizations should ensure that their e-commerce platforms, CMSs, and installed plugins are up to date with the latest security patches and that they only download and use third-party plugins and services from trusted sources. They must also perform a regular and thorough check of their web assets for any compromised or suspicious content. Among the similarities we found in these recent skimming scripts include the presence of Base64-encoded strings such as “checkout” and “onepage” and the presence of the atob() JavaScript function in compromised pages. Such clues could help defenders surface these malicious scripts.
Organizations should also complement best practices with a comprehensive security solution like Microsoft 365 Defender, which can detect and block skimming scripts on endpoints and servers by coordinating threat defense across various domains. It’s also backed by threat experts whose continuous monitoring of the computing landscape for new attacker tools and techniques enriches our protection technologies. For example, in the case of Magecart, RiskIQ published a report that profiled the attacker groups behind it. Updates about the latest skimming campaigns observed are also provided.
Figure 15. Microsoft Defender for Endpoint detecting a web skimming malware
Meanwhile, online shoppers can protect themselves from web skimming attacks by ensuring their browser sessions are secure, especially during the checkout process. They should be wary of any unexpected or suspicious pop-ups that ask for payment details. Finally, users should turn on cloud-delivered protection and automatic sample submission on Microsoft Defender Antivirus (or a similar feature in their security product). This capability utilizes artificial intelligence and machine learning to quickly identify and stop new and unknown threats.
Below is a list of Base64-encoded URLs injected in affected CMSs and their corresponding decoded values. These URLs host the malicious JavaScript the attackers use for web skimming.
In 2020, MSRC awarded two Identity Project Research Grants to support external researchers working to further strengthen the security of identity protocols and systems. Today we are pleased to release the results of the first of these projects. This research, led by independent security researcher Avinash Sudhodanan, investigated account pre-hijacking – a new class of attacks affecting websites and other online services.
In 2020, MSRC awarded two Identity Project Research Grants to support external researchers working to further strengthen the security of identity protocols and systems. Today we are pleased to release the results of the first of these projects. This research, led by independent security researcher Avinash Sudhodanan, investigated account pre-hijacking – a new class of attacks affecting websites and other online services.
In the last six months, we observed a 254% increase in activity from a Linux trojan called XorDdos. First discovered in 2014 by the research group MalwareMustDie, XorDdos was named after its denial-of-service-related activities on Linux endpoints and servers as well as its usage of XOR-based encryption for its communications.
XorDdos depicts the trend of malware increasingly targeting Linux-based operating systems, which are commonly deployed on cloud infrastructures and Internet of Things (IoT) devices. By compromising IoT and other internet-connected devices, XorDdos amasses botnets that can be used to carry out distributed denial-of-service (DDoS) attacks. Using a botnet to perform DDoS attacks can potentially create significant disruptions, such as the 2.4 Tbps DDoS attack Microsoft mitigated in August 2021. DDoS attacks in and of themselves can be highly problematic for numerous reasons, but such attacks can also be used as cover to hide further malicious activities, like deploying malware and infiltrating target systems.
Botnets can also be used to compromise other devices, and XorDdos is known for using Secure Shell (SSH) brute force attacks to gain remote control on target devices. SSH is one of the most common protocols in IT infrastructures and enables encrypted communications over insecure networks for remote system administration purposes, making it an attractive vector for attackers. Once XorDdos identifies valid SSH credentials, it uses root privileges to run a script that downloads and installs XorDdos on the target device.
XorDdos uses evasion and persistence mechanisms that allow its operations to remain robust and stealthy. Its evasion capabilities include obfuscating the malware’s activities, evading rule-based detection mechanisms and hash-based malicious file lookup, as well as using anti-forensic techniques to break process tree-based analysis. We observed in recent campaigns that XorDdos hides malicious activities from analysis by overwriting sensitive files with a null byte. It also includes various persistence mechanisms to support different Linux distributions.
Figure 1. A typical attack vector for XorDdos malware
XorDdos may further illustrate another trend observed in various platforms, in which malware is used to deliver other dangerous threats. We found that devices first infected with XorDdos were later infected with additional malware such as the Tsunami backdoor, which further deploys the XMRig coin miner. While we did not observe XorDdos directly installing and distributing secondary payloads like Tsunami, it’s possible that the trojan is leveraged as a vector for follow-on activities.
Microsoft Defender for Endpoint protects against XorDdos by detecting and remediating the trojan’s multi-stage, modular attacks throughout its entire attack chain and any potential follow-on activities on endpoints. In this blog post, we detail our in-depth analysis of XorDdos to help defenders understand its techniques and protect their networks from this stealthy malware.
XorDdos propagates primarily via SSH brute force. It uses a malicious shell script to try various root credential combinations across thousands of servers until finding a match on a target Linux device. As a result, we see many failed sign-in attempts on devices successfully infected by the malware:
Figure 2. Failed sign-in attempts on a device affected by XorDdos
Our analysis determined two of XorDdos’ methods for initial access. The first method involves copying a malicious ELF file to temporary file storage /dev/shm and then running it. Files written at /dev/shm are deleted during system restart, thus concealing the source of infection during forensic analysis.
The second method involves running a bash script that performs the following activities via the command line:
Iterates the following folders to find a writable directory:
/bin
/home
/root
/tmp
/usr
/etc
If a writable directory is found, changes the working directory to the discovered writable directory.
Uses the curl command to download the ELF file payload from the remote location hxxp://Ipv4PII_777789ffaa5b68638cdaea8ecfa10b24b326ed7d/1[.]txt and saves the file as ygljglkjgfg0.
Changes the file mode to “executable”.
Runs the ELF file payload.
Moves and renames the Wget binary to evade rule-based detections triggered by malicious usage of the Wget binary. In this case, it renames the Wget binary to good and moves the file to the following locations:
mv /usr/bin/wget /usr/bin/good
mv /bin/wget /bin/good
Attempts to download the ELF file payload for a second time, now only using the file good and not the Wget binary.
After running the ELF file, uses an anti-forensic technique that hides its past activity by overwriting the content of the following sensitive files with a newline character:
Sensitive File
Description
/root/.bash_history
Contains the commands that were run earlier
/var/log/wtmp
Contains login related record for users
/var/log/btmp
Contains record of failed login attempt
/var/log/lastlog
Contains the recent login information for users
/var/log/secure
Contains information related to security such as logs for authentication failure, sudo logins, and authorization privileges
/var/log/boot.log
Contains information related to system boot and message logged via system startup processes
/var/log/cron
Contains information related to cron job launch, success and failure error logs
/var/log/dmesg
Contains information related to kernel ring buffer messages, hardware devices, drivers, etc.
/var/log/firewalld
Contains logs related to firewall activities
/var/log/maillog
Contains information related to a mail server running on the system
/var/log/messages
Contains generic system activity messages
/var/log/spooler
Contains messages from usenet
/var/log/syslog
Contains generic system activity messages
/var/log/yum.log
Contains the package logs related to installation\remove\update activities done via yum utility
Figure 3. Remote bash script command used for initial access
Whichever initial access method is used, the result is the same: the running of a malicious ELF file, which is the XorDdos malware. In the next section, we do a deep dive into the XorDdos payload.
XorDdos payload analysis
The XorDdos payload we analyzed for this research is a 32-bit ELF file that was not stripped, meaning it contained debug symbols that detailed the malware’s dedicated code for each of its activities. The inclusion of debug symbols makes it easier to debug and reverse engineer non-stripped binaries, as compared to stripped binaries that discard these symbols. In this case, the non-stripped binary includes the following source-code file names associated with the symbol table entries as part of the .strtab section in the ELF file:
crtstuff.c
autorun.c
crc32.c
encrypt.c
execpacket.c
buildnet.c
hide.c
http.c
kill.c
main.c
proc.c
socket.c
tcp.c
thread.c
findip.c
dns.c
The above list of source-code file names indicate that the binary is programmed in C/C++ and that its code is modular.
Detection evasion capabilities
XorDdos contains modules with specific functionalities to evade detection, as detailed below.
Daemon processes
A daemon process is a process that runs in the background rather than under the control of users and detaches itself from the controlling terminal, terminating only when the system is shut down. Similar to some Linux malware families, the XorDdos trojan uses daemon processes, as detailed below, to break process tree-based analysis:
The malware calls the subroutine daemon(__nochdir, __noclose) to set itself as a background daemon process, which internally calls fork() and setsid(). The fork() API creates a new child process with the same process group-id as the calling process.
After the successful call to the fork() API, the parent stops itself by returning “EXIT_SUCCESS (0)”. The purpose is to ensure that the child process is not a group process leader, which is a prerequisite for the setsid() API call to be successful. It then calls setsid() to detach itself from the controlling terminal.
The daemon subroutine also has a provision to change the directory to the root directory (“/“) if the first parameter __nochdir is called with a value equal to “0”. One reason for the daemon process to change the directory to the root partition (“/“)is because running the process from the mounted file system prevents unmounting unless the process is stopped.
It passes the second parameter __noclose as “0” to redirect standard input, standard output, and standard error to /dev/null. It does this by calling dup2 on the file descriptor for /dev/null.
The malware calls multiple signal APIs to ignore a possible signal from the controlling terminal and detach the current process from the standard stream and HangUp signals (SIGHUP) when the terminal session is disconnected. Performing this evasive signal suppression helps stop the effects of standard libraries trying to write to standard output or standard error, or trying to read from standard input, which could stop the malware’s child process. The API signal() sets the disposition of the signal signum to the handler, which is either SIG_IGN, SIG_DFL, or the address of a programmer-defined signal handler. In this case, the second parameter is set to “SIG_IGN=1”, which ignores the signal corresponding to signum.
Figure 4. Ignore signals associated with the terminal-related operations
XOR-based encryption
As its name suggests, XorDdos uses XOR-based encryption to obfuscate data. It calls the dec_conf function to decode encoded strings using the XOR key “BB2FA36AAA9541F0”. The table below shows the decoded values of the obfuscated data used across the malware’s various modules to conduct its activities.
Encrypted strings
Decoded value
m7A4nQ_/nA
/usr/bin/
m [(n3
/bin/
m6_6n3
/tmp/
m4S4nAC/n&ZV\x1aA/TB
/var/run/gcc.pid
m.[$n__#4%\C\x1aB]0
/lib/libudev.so
m.[$n3
/lib/
m4S4nAC/nA
/var/run/
!#Ff3VE.-7\x17V[_
cat resolv.conf
<Encrypted_Remote_URL>
hxxp://aa.hostasa[.]org/config.rar
Process name spoofing
When a process is launched, arguments are provided to its main function as null-terminated strings, where the first argument is always the process image path. To spoof its process name, XorDdos zeroes out all argument buffers while running and overrides its first argument buffer containing the image path with a fake command line, such as cat resolv.conf.
Figure 5. Process name spoofing achieved by modifying memory associated with argument vectors.Figure 6. Output of the ‘ps -aef’ contains an entry for “cat resolv.conf”
Kernel rootkit
Some XorDdos samples install a kernel rootkit. A rootkit is a kernel module that hides the presence of malicious code by modifying operating systems data structures. The XorDdos kernel rootkit generally has following capabilities:
Provide root access
Hide the kernel module
Hide the malware’s processes
Hide the malware’s network connections and ports
Based on the debug symbols found in the rootkit, it’s likely that XorDdos’ rootkit code was inspired by an open-source project called rooty. The following table describes the symbols found in the rootkit and their corresponding functionalities:
Function name
Description
give_root
Provides a root privilege by setting a new set of credentials and assigning its UID, GID to “0”
module_hide
Hides the rootkit kernel module
module_show
Unhides the rootkit kernel module
get_udp_seq_show
Hides the UDP4 connection by hooking /proc/net/udpHides the UDP6 connection by hooking /proc/net/udp6
get_tcp_seq_show
Hides the TCP4 connection by hooking /proc/net/tcpHides the TCP6 connection by hooking /proc/net/tcp6
hide_udp4_port
Adds a provided port to a list of hidden UDP4 ports
unhide_udp4_port
Deletes a provided port from a list of hidden UDP4 ports
hide_udp6_port
Adds a provided port to a list of hidden UDP6 ports
unhide_udp6_port
Deletes a provided port from a list of hidden UDP6 ports
hide_tcp4_port
Adds a provided port to a list of hidden TCP4 ports
unhide_tcp4_port
Deletes a provided port from a list of hidden TCP4 ports
hide_tcp6_port
Adds a provided port to a list of hidden TCP6 ports
unhide_tcp6_port
Deletes a provided port from a list of hidden TCP6 ports
unhide_allz
Iterates list of all hidden ports and deletes all entries
Process and port hiding
The malware tries to hide its processes and ports using its kernel rootkit component. Hiding a process assists the malware in evading rule-based detections.
The /proc filesystem contains information related to all running processes. A user-mode process can get any process specific information by reading the /proc directory that contains the subdirectory for each running process on the system, such as:
/proc/7728 – Contains process-id (PID) 7728-related information
/proc/698 – Contains PID 698-related information
Running the strace -e open ps command checks the traces of the open call on /proc/$pid to fetch information on running processes as part of the ps command.
If the malware hides the $pid specific directory, it can conceal fetching the corresponding process from a user mode.
In this case, the malware has a provision for communicating with its rootkit component /proc/rs_dev by sending input and output control (IOCTL) calls with additional information to take appropriate action. IOCTL is one way to communicate between the user-mode service and kernel device driver. The malware uses the number “0x9748712” to uniquely identify its IOCTL calls from other IOCTL calls in the system.
Along with this number, it also passes an integer array. The first entry in the array corresponds to the command, and the second entry stores the value to act on, such as $pid.
Command
Usage
0
Check if its rootkit driver is present
1, 2
Hide or unhide <PID>
3
Hide <port>
Persistence mechanisms
XorDdos uses various persistence mechanisms to support different Linux distributions when automatically launching upon system startup, as detailed below.
Init script
The malware drops an init script at the location /etc/init.d. Init scripts are startup scripts used to run any program when the system starts up. They follow the Linux Standard Base (LSB)-style header section to include default runlevels, descriptions, and dependencies.
Figure 7. Content of the init script dropped at the location /etc/init.d/HFLgGwYfSC.elf
Cron script
The malware creates a cron script at the location /etc/cron.hourly/gcc.sh.The cron script passes parameters with the following content:
Figure 8. Content of the gcc.sh script
It then creates a /etc/crontab file to run /etc/cron.hourly/gcc.sh every three minutes:
Figure 9. System command to delete the /etc/cron.hourly/gcc.sh entry from the /etc/crontab file and add a new entryFigure 10. The content of the file /etc/crontab
System V runlevel
A runlevel is a mode of init and the system that specifies what system services are operating for Unix System V-Style operating systems. Runlevels contain a value, typically numbered zero through six, which each designate a different system configuration and allows access to a different combination of processes. Some system administrators set a system’s default runlevel according to their needs or use runlevels to identify which subsystems are working, such as whether the network is operational. The /etc/rc<run_level> directory contains symbolic links (symlinks), which are soft links that point to the original file. These symlinks point to the scripts that should run at the specified runlevel.
The malware creates a symlink for the init script dropped at the location /etc/init.d/<base_file_name> with the directories associated with runlevels 1 through 5 at /etc/rc<run_level>.d/S90<base_file_name> and /etc/rc.d/rc<run_level>.d/S90<base_file_name>.
Figure 11. Installation of rc.d directory’s symlink scripts with /etc/init.d/<base_file_name>
Auto-start services
The malware runs a command to install startup services that automatically run XorDdos at boot. The malware’s LinuxExec_Argv2 subroutine runs the system API with the provided arguments.
The commands chkconfig –add <service_name> and update-rc.d then add a service that starts the daemon process at boot.
Figure 12. chkconfig and update-rc.d commands install the startup service
Argument-based code-flow
XorDdos has specific code paths corresponding to the number of arguments provided to the program. This flexibility makes its operation more robust and stealthy. The malware first runs without any argument and then later runs another instance with different arguments, such as PIDs and fake commands, to perform capabilities like clean-up, spoofing, and persistence.
Before handling the argument-based control, it calls the readlink API with the first parameter as /proc/self/exe to fetch its full process path. The full path is used later to create auto-start service entries and read the file’s content.
In this section, we will cover the main tasks carried out as part of the different arguments provided:
1: Standard code path without any provided arguments
This code path depicts the malware’s standard workflow, which is also the typical workflow where XorDdos runs as part of the entries created in system start-up locations.
The malware first checks whether it’s running from the locations /usr/bin/, /bin/, or /tmp/. If it’s not running from these locations, then it creates and copies itself using a 10-character string name on those locations, as well as /lib/ and /var/run/.
It also creates a copy of itself at the location /lib/libudev.so. To evade hash-based malicious file lookup, it performs the following steps, which modify the file hash to make every file unique:
Opens the file for writing only
Calls lseek (fd, 0, SEEK_END) to point at the last position in the file
Creates a random 10-character string
Writes the string at the end of the file with an additional null byte
After modifying the file, it runs the binary, performs a double fork(), and deletes its file from the disk.
Figure 13. The end of the malware file contains two random strings, ‘wieegnexuk’ and ‘yybrdajydg,’ indicating that the original malware binary was modified twice
2: Clean-up code path
In this code path, the malware runs with another argument provided as the PID, for example:
/usr/bin/jwvwvxoupv 4849
Using the above example, the malware shares the 64-byte size memory segment with the IPC key “0xDA718716” to check for another malware process provided as an argument. If not found, it runs its own binary without any argument and calls the fork() API twice to make sure the grandchild process has no parent. This results in the grandchild process being adopted by the init process, which disconnects it from the process tree and acts as an anti-forensic technique.
Additionally, it performs the following tasks on a provided $pid:
Fetches the process file name corresponding to the provided $pid
Deletes the file for the provided $pid
Deletes the installed init services:
Deletes /etc/init.d/<file_name>
For runlevels 1-5, unlinks and deletes /etc/rc<runlevel>.d/S90<file_name>
Performs the command chkconfig –del <file_name>
Performs the command update-rc.d <file_name> remove
Ends the process that was provided as an argument.
3: Process name spoofing code path
The malware spawns new dropped binaries with two additional arguments: a fake command line and its PIDs, for example:
/usr/bin/jwvwvxoupv “cat resolv.conf” 4849
/usr/bin/jwvwvxoupv gnome-terminal 4849
/usr/bin/jwvwvxoupv top 4849
/usr/bin/jwvwvxoupv pwd 4849
/usr/bin/kagbjahdic id 4849
The fake commands can include:
cat resolv.conf
netstat -an
bash
whoami
id
cd /etc
ifconfig eth0
ifconfig
echo “find”
uptime
sh
top
gnome-terminal
su
netstat -antop
grep “A”
who
ls -la
pwd
route -n
ps -ef
ls
sleep 1
In this code path, the malware uses process name spoofing to hide from the process tree by modifying its fake command line at runtime. It then hides its process by calling HidePidPort with command “1” and reads the content of the file on disk related to the current process.
It then enters a five-second loop to perform the following checks:
Fetches the file name specific to the $pid provided as part of the third argument by calling the readlink API on /proc/$pid/exe.
If the readlink call fails, that likely indicates that the file on disk doesn’t exist. In this case, it:
Intends to delete all service-related entries for the $pid but fails. This appears to be due to a code flaw that allows a zeroed-out buffer to be passed as a service name when the buffer is supposed to be filled from a successful readlink API call.
Creates directories similar to the standard code path scenario.
Calls the stat API for the file /lib/libudev.so. If the stat API returns a non-zero value, then it attempts to copy the content of the current process’s image-file fetched earlier to the following locations with a random name:
/usr/bin/
/bin/
/tmp/
Copies the /lib/libudev.so file to the same three directories listed above if the stat API call is successful on /lib/libudev.so.
Changes the hash of the written or copied file and then runs it without passing any parameters.
If the readlink call is successful and returns the count of bytes copied, sleeps for one second and then loops for the remaining time out of five seconds.
Unhides the current process and the $pid that was provided as part of the third argument.
Deletes the on-disk file for the current process.
4: Known locations code path without any provided arguments
This code path is similar to the standard code path, with the main difference being that the malware runs from one of the following locations:
/usr/bin/
/bin/
/tmp/
Once it runs from one of these locations, the malware calls the following functions to perform various tasks:
InstallSYS– The name suggests that this function is a wrapper that should deploy a rootkit driver, but it only zeroes-out two local arrays.
Figure 14. Dummy InstallSYS routine
AddService – Creates the persistent auto-start entries previously mentioned so that the malware runs when the system starts.
HidePidPort – Hides the malware’s ports and processes.
CheckLKM – Checks whether the rootkit device is active or not. It uses a similar IOCTL call with the number “0x9748712” and command “0” to find if the rootkit is active. If the rootkit is active, it uses the owner value “0xAD1473B8” and group value “0xAD1473B8” to change the ownership of dropped files with the function lchown(<filename>, 0xAD1473B8, 0xAD1473B8).
decrypt_remotestr– Decodes remote URLs using the same XOR key, “BB2FA36AAA9541F0”, to decode config.rar and the other directories. After decoding the URLs, it adds them into a remote list, which is later used to communicate and fetch commands from the command and control (C2) server:
www[.]enoan2107[.]com:3306
www[.]gzcfr5axf6[.]com:3306
Malicious activity threads
After creating persistent entries, deleting evidence of its activities, and decoding config.rar, the malware initializes a cyclic redundancy check (CRC) table followed by an unnamed semaphore using the sem_init API. This semaphore is initialized with apshared value set to “0”, making the resultant semaphore shared between all the threads. The semaphore is used to maintain concurrency between threads accessing a shared object, such as kill_cfg data.
The malware then initializes three threads to perform malicious activities, such as stopping a process, creating a TCP connection, and retrieving kill_cfg data.
Figure 15. Semaphore and malicious thread initialization
kill_process
The kill_process thread performs the following tasks:
Decodes encrypted strings
Fetches file stats for /var/run/gcc.pid or, if none exist, then creates the file
Fetches file stats for /lib/libudev.so or, if none exist, then creates the directory /lib and creates a copy of itself at the location /lib/libudev.so
Fetches the on disk file information associated with the current process; if it fails, then exits the loop and stops the current process
Reads the content from kill_cfg and performs the corresponding actions, like stopping the process or deleting files, based on the matching specified keys in the configuration file, such as:
md5=
filename=
rmfile=
denyip=
tcp_thread
The tcp_thread triggers the connection with the C2 server decoded earlier using decrypt_remotestr(). It performs the following tasks:
Reads the content of the file /var/run/gcc.pid to get a unique 32-byte magic string that identifies the device while connecting with the C2 server; if the file doesn’t exist, then it creates the file and updates it with a random 32-byte string.
Calculates the CRC header, including details of the device such as the magic string, OS release version, malware version, rootkit presence, memory stats, CPU information, and LAN speed.
Encrypts the data and sends it to the C2 server.
Waits to receive any of the following commands from the C2 server and then acts on the command using the exec_packet subroutine.
Command
Job
2
Stop
3
Create a thread pool for launching DDoS attacks
6
Download file
7
Update file
8
Send system information to the C2 server
9
Get configuration file to stop processes
Figure 16. Collection of system information
daemon_get_killed_process
The daemon_get_killed_processthread downloads the kill_cfg data from the remote URL decoded earlier (hxxp://aa[.]hostasa[.]org/config[.]rar) and decrypts it using the same XOR key previously mentioned. It then sleeps for 30 minutes.
Figure 17. daemon_get_killed_process thread function fetches and decodes the kill_cfg data from the remote URL
DDoS attack thread pool
The malware calls sysconf(_SC_NPROCESSORS_CONF) to fetch the number of processors in the device. It then creates threads with twice the number of processors found on the device.
Invoking each thread internally calls the thread routine threadwork. Using the global variable “g_stop” and commands received from the C2 server, threadwork then sends crafted packets 65,535 times to perform a DDoS attack.
Command
Function
Job
0x4
fix_syn
SYN flood attack
0x5
fix_dns
DNS attack
0xA
fix_ack
ACK flood attack
Defending against Linux platform threats
XorDdos’ modular nature provides attackers with a versatile trojan capable of infecting a variety of Linux system architectures. Its SSH brute force attacks are a relatively simple yet effective technique for gaining root access over a number of potential targets.
Adept at stealing sensitive data, installing a rootkit device, using various evasion and persistence mechanisms, and performing DDoS attacks, XorDdos enables adversaries to create potentially significant disruptions on target systems. Moreover, XorDdos may be used to bring in other dangerous threats or to provide a vector for follow-on activities.
XorDdos and other threats targeting Linux devices emphasize how crucial it is to have security solutions with comprehensive capabilities and complete visibility spanning numerous distributions of Linux operating systems. Microsoft Defender for Endpoint offers such visibility and protection to catch these emerging threats with its next-generation antimalware and endpoint detection and response (EDR) capabilities. Leveraging threat intelligence from integrated threat data, including client and cloud heuristics, machine learning models, memory scanning, and behavioral monitoring, Microsoft Defender for Endpoint can detect and remediate XorDdos and its multi-stage, modular attacks. This includes detecting and protecting against its use of a malicious shell script for initial access, its drop-and-execution of binaries from a world-writable location, and any potential follow-on activities on endpoints.
Defenders can apply the following mitigations to reduce the impact of this threat:
Encourage the use of Microsoft Edge—available on Linux and various platforms—or other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.
Use device discovery to find unmanaged Linux devices on your network and onboard them to Microsoft Defender for Endpoint.
Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to use cloud-based machine learning protections that can block a huge majority of new and unknown variants.
Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode.
Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet.
Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume.
As threats across all platforms continue to grow in number and sophistication, security solutions must be capable of providing advanced protection on a wide range of devices, regardless of the operating system in use. Organizations will continue to face threats from a variety of entry points across devices, so Microsoft continues to heavily invest in protecting all the major platforms and providing extensive capabilities that organizations needed to protect their networks and systems.
Detection details
Microsoft Defender for Endpoint detects and blocks XorDdos components and behavior as the following malware:
DoS:Linux/Xorddos.A
DoS:Linux/Xorddos!rfn
Trojan:Linux/Xorddos
Trojan:Linux/Xorddos.AA
Trojan:Linux/Xorddos!rfn
Behavior:Linux/Xorddos.A
When XorDdos is detected on a device, Microsoft 365 Defender raises an alert, which shows the complete attack chain, including the process tree, file information, user information, and prevention details.
Figure 18. Microsoft 365 Defender alert for detection of XorDdos malware
The timeline view displays all of the detection and prevention events associated with XorDdos, providing details such as the MITRE ATT&CK techniques and tactics, remediation status, and event entities graph.
Figure 19. Microsoft 365 Defender timeline displaying that HFLgGwYfSC.elf was run from a world-writable directory and the remediation of dropped binaries
Events with the following titles indicate threat activity related to XorDdos:
The content of libudev.so was collected into libudev.so.6
bash process performed System Information Discovery by invoking ifconfig
gcc.sh was executed after being dropped by HFLgGwYfSC.elf
A shell command was executed by crond
SUID/SGID process unix_chkpwd executed
Figure 20. Microsoft 365 Defender timeline with an event on a suspicious shell command run by crond after it was dropped from HFLgGwYfSC.elf
Hunting queries
To locate malicious activity related to XorDdos activity, run the following advanced hunting queries in Microsoft 365 Defender or Microsoft Defender Security Center:
Failed sign-ins
DeviceLogonEvents
| where InitiatingProcessFileName == "sshd"
and ActionType == "LogonFailed"
| summarize count() by dayOfYear = datetime_part("dayOfYear", Timestamp)
| sort by dayOfYear
| render linechart
Creation of the XorDdos-specific dropped files
DeviceFileEvents
| extend FullPath=strcat(FolderPath, FileName)
| where FullPath in ("/etc/cron.hourly/gcc.sh", "/lib/libudev.so.6", "/lib/libudev.so", "/var/run/gcc.pid")
Command-line of malicious process
DeviceProcessEvents
| where ProcessCommandLine contains "cat resolv.conf"
“The bug bounty literally changed my life. Before this, I had nothing.” Coolest thing he purchased: His first vehicle! Best gift to give: Buying his nephew gaming accessories. Favorite Hacking Companion: His two cats. They’re always by his side when he is working late. Origin of his Hacker name: The word dog in Spanish is …
“The bug bounty literally changed my life. Before this, I had nothing.”
Coolest thing he purchased : His first vehicle!
Best gift to give: Buying his nephew gaming accessories.
Favorite Hacking Companion : His two cats. They’re always by his side when he is working late.
Origin of his Hacker name : The word dog in Spanish is “perro” @p3RR0.
“The bug bounty literally changed my life. Before this, I had nothing.”
Coolest thing he purchased : His first vehicle!
Best gift to give: Buying his nephew gaming accessories.
Favorite Hacking Companion : His two cats. They’re always by his side when he is working late.
Origin of his Hacker name : The word dog in Spanish is “perro” @p3RR0.
Data is the lifeblood of any organization. Whether you’re a Chief Information Security Officer (CISO) or aspiring to become one, protecting sensitive business data will be your main priority. But the job isn’t getting any easier. In 2021, the number of data breaches climbed 68 percent to 1,862, costing an average of USD4.24 million each.1 The damage from a breach touches everyone, causing diminished brand equity and consumer trust, decreased shareholder confidence, failed audits, and increased scrutiny from regulatory agencies.
It’s easy to become so preoccupied with protecting against the next ransomware attack that you overlook risks within your own organization. Insider leaks of sensitive data, intellectual property (IP) theft, fraud, regulatory violations—any of these can crash a company (and your career) as quickly as a headline-grabbing breach. Given the breadth of today’s digital estate—on-premises, in the cloud, and at the edge—Microsoft Purview provides the inside-out, integrated approach that an effective CISO needs to reduce the risk of internal and external data breaches before they occur. Here are some things to consider, both when prioritizing for yourself and talking to your board of directors.
Mind your own house—insider threats
As the “Great Resignation” or “Great Reshuffle” rolls on, organizations worldwide are dealing with large numbers of people heading for the exits—and climbing aboard. Results from Microsoft’s most recent Work Trend Index indicate that 43 percent of employees are likely to consider changing jobs in the year ahead. This massive shift in employment status has been accompanied by the “Great Exfiltration.” Many of those transitioning employees will, intentionally or not, be leaving with sensitive data stored on personal devices or accessed through a third-party cloud. During 2021, 15 percent of workers uploaded more corporate data to personal cloud apps as compared to 2020. What’s more alarming, 2021 also saw 8 percent of exiting employees upload more than 100 times their usual data volume.2
As a CISO, you’re responsible for data spread across multiple platforms, devices, and workloads. You’ll need to consider how that technology interacts with your organization’s business processes. That includes having policies in place to prevent data exfiltration; especially if you work in a regulated industry, such as finance or healthcare. It starts with asking: Who can access the data? Where should the data reside (or not reside)? How can the data be used? How do we prevent oversharing? A modern data loss prevention (DLP) solution—cloud-native and comprehensive—enables you to centrally manage all your DLP policies across cloud services, devices, and on-premises file shares. Even better, this type of unified DLP solution requires no additional infrastructure or agents, helping to keep costs down. Even in a time of great change, today’s workplace requires that people remain free to create, manage, and share data across platforms and services. However, the organizations they work for are often constrained by limited resources and strict privacy standards when seeking to mitigate user risks. For that reason, you’ll need tools that can analyze insider threats and provide integrated detection and investigation capabilities. The best solution for insider threats will be:
Transparent—balancing user privacy with organizational risk by using privacy-by-design architecture.
Configurable—enabling policies based on your industry, geographical location, and business groups.
Integrated—maintaining a workflow that’s integrated across all your data, wherever it resides.
Actionable—providing insights to enable reviewer notifications, data investigations, and user investigations.
Protecting against insider threats should include templates and policy conditions that define which triggering events and risk indicators require examination. For that reason, your insider-risk solution should be able to look at potential risk patterns across the organization, as well as investigate risky activity with end-to-end workflows. Furthermore, a solution that helps detect code of conduct violations (harassing or threatening language, adult content, and sharing sensitive information) can be a reliable indicator for possible insider threats. Machine learning will help provide greater context around certain words or key phrases, so investigators can speed up remediation.
Automate and integrate your data strategy
Because many organizations resist going all-in on one vendor, most CISOs have to deal with data spread across a patchwork of on-premises and cloud storage. Though clunky, legacy data silos are a fact of life. If large volumes of “dark data” aren’t correctly classified as sensitive, then it becomes difficult to protect personally identifiable information (PII) or sensitive corporate IP and implement data loss prevention policies. A thrifty CISO needs to simplify wherever possible, using a comprehensive solution to help protect the entire digital estate. A good data management solution should provide both the flexibility for users to manually classify their documents, as well as system administrators applying auto-labeling and machine learning-trainable classifiers.
Data discovery: It’s not unheard of to discover that an employee unknowingly stored a customer’s Social Security Number (SSN) on an unprotected site or a third-party cloud. That’s why you’ll want a data management solution like PII that automatically identifies sensitive data using built-in sensitive information types and regulatory policy templates, such as General Data Protection Regulation (GDPR) and Health Insurance Portability and Accountability Act of 1996 (HIPAA). And since sensitive data can land anywhere, the right solution needs to use automation to cast a wide net across on-premises, multicloud, operational, and software as a service (SaaS) data.
Data classification: Look for unified built-in labeling that’s already integrated with broadly used applications and services, allowing users to further customize sensitivity levels for their specific needs. The right solution should also allow automatic labeling and policy enforcement across an organization for faster classification and data loss prevention deployment at enterprise scale. In addition, look for unified data management solutions that identify and classify sensitive data found on-premises, multicloud, and SaaS to create a holistic map of your entire data estate.
Data governance: You want your organization’s data to be discoverable, trusted, and stored in a location where it can be readily protected. Storing data longer than necessary increases your risk of exposure in a breach. On the other hand, deleting data too quickly can put your organization at risk of regulatory violations. Data retention, records management, and machine learning capabilities solve this problem by classifying data and automatically applying lifecycle policies, helping you manage risk and liability by keeping only the data you need and deleting what you don’t.
Make data protection a team effort
A primary responsibility for any CISO is to protect the organization’s IP, such as software source code, patented designs, creative works—pretty much anything that gives the business a competitive edge. But with the growth of big data and changing regulatory standards, CISOs are also expected to protect user data, such as PII, personal health information (PHI), and payment card industry (PCI) data. Privacy laws are also increasing restrictions on the use, retention, and location of user data, both internally and with third-party vendors.
In addition, hybrid and multicloud services create new challenges by distributing data’s geographic origins, storage location, and user access points. Today’s CISO needs to work with colleagues in data protection, privacy, IT, HR, legal, and compliance, meaning, you may be sharing duties with a Chief Data Officer (CDO), Chief Risk Officer (CRO), Chief Compliance Officer (CCO), and Chief Information Officer (CIO). That’s a lot of acronyms at one table. So, rather than duplicate efforts or compete for territory, an effective CISO should adopt a unified solution for data protection that helps eliminate potential redundancies and keeps your entire security team working off the same script.
Bonus tip—simplify
We all know the days of firewalls and perimeter-based security aren’t coming back. Enabling an effective Zero Trust approach requires the ability to protect data across a multicloud, multiplatform environment. Microsoft’s decision to unify data protection, governance, and compliance capabilities as Microsoft Purview—bringing together the former Microsoft Azure Purview and Microsoft 365 Compliance portfolio under one brand—reflects our belief that organizations need a simpler approach to data protection.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.
The acceleration of cloud journeys fueled by the pandemic and ever-increasing concerns about data security and information privacy have made access management one of the hottest topics in application security and Zero Trust architecture discussions. Over the last several years, the industry has made tremendous progress on identity and access management, and Microsoft Azure Active Directory (Azure AD), with its focus on Zero Trust comprehensive cloud-based identity services, is a perfect example of this.
Achieving a secure environment is top of mind for both public and private sector organizations, with research firm markets anticipating the global Zero Trust security market will grow from USD19.6 billion in 2020 to USD51.6 billion by 2026. The United States government has mandated a federal Zero Trust architecture strategy, while businesses of every size are working to implement modern identity and access management solutions that support single sign-on (SSO), multifactor authentication, and many other key features, including adaptive and context-aware policies, governance intelligence, and automation.1
To achieve Zero Trust for applications and services, we must ensure people are who they say they are and that only the right people have access to sensitive information. This is the only way to comply with evolving data privacy regulations such as General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA). Consequently, companies must create a comprehensive, manageable way to authenticate and authorize every attempt to access data—based on a least-privileged access principle—while still providing users with the secure self-service access they need.
Datawiza, a cloud-delivered, no-code platform for easily implementing both authentication and authorization for all types of applications and APIs, works with Azure AD to help IT accelerate this key area of the journey to Zero Trust and get the most value from their hybrid multicloud environments.
As an access management as a service (AMaaS) platform, Datawiza dramatically reduces the time and engineering costs required to integrate applications with Azure AD, eliminating months of development effort thanks to its no-code approach. Developers don’t have to learn complex modern SSO protocols like OpenID Connect (OIDC), OAuth, and Security Assertions Markup Language (SAML), or use different software development kits (such as .NET, Java, and PHP) to write integration code for each application.
Leveraging Datawiza with Azure AD supports comprehensive SSO and multifactor authentication across applications, with fine-grained access controls. The application types can include:
Homegrown applications that are written in different programming languages such as Java, PHP, and Python. These applications can reside in multicloud environments or on-premises.
Legacy applications, such as those from Oracle, that were never designed for the cloud and may still rely on a legacy identity solution, such as Symantec SiteMinder, on-premises Lightweight Directory Access Protocol (LDAP), or custom-built basic authentication. In fact, Datawiza can empower companies to retire their legacy identity solutions.
Business-to-business (B2B) multi-tenant applications available to customers using Azure AD, as well as other identity platforms.
Open-source tools that would otherwise require expensive enterprise license fees from the vendor to use the SSO feature to connect with Azure AD.
Options for integrating homegrown and legacy applications with Azure AD
Integrating homegrown or legacy applications with Azure AD is imperative. Not doing so leads to critical security gaps. It also causes frustration for users who need to sign into multiple applications, as well as administrators who must constantly update user profiles in multiple locations.
Integrating these applications with Azure AD requires coding and security expertise. And whether you use your developer resources or legacy on-premises gateways, as we hear from our customers, it usually takes more time and resources than anticipated—distracting development and DevOps teams from their strategic tasks. If your organization relies on a hybrid multicloud environment, the challenges are even greater. You may also consider using a free open-source software proxy, such as OAuth2-proxy, but this is still time-consuming, providing little benefit compared to the do-it-yourself approach. Further, with each of these approaches, all the effort that goes into integrating a single application must be repeated for each additional application.
How the Datawiza No-Code platform works
The Datawiza No-Code platform offers a new approach, providing authentication and authorization as a service, so it can be implemented quickly, without the need to deploy any hardware or heavyweight enterprise software, or having to rewrite applications or write new code. Datawiza uses a lightweight, cloud-delivered proxy for connecting any application and service to Azure AD, and it can also integrate across other public and private clouds.
Integrating each application takes only minutes, so the more applications you need to integrate, the more time you save—all with a single Datawiza license. And with security expertise built-in, the Datawiza AMaaS platform eliminates the need to hire an expensive new resource or consultant, while also facilitating improved governance by providing policy-defined, URL-level access controls based on detailed user and device attributes, such as group, role, IP, or browser.
How Datawiza and Azure AD work together
When a user attempts to log into any application, Datawiza intercepts the access request and authenticates it using a built-in connection to Azure AD through OIDC or SAML protocols.
The user signs in through the Azure AD login page, and the OIDC or SAML message exchanges with Azure AD and Datawiza are automatically completed on behalf of the application.
Datawiza authorizes the request based on the fine-grained access policies configured in the management console and user attributes from Azure AD.
Datawiza then sends the correct credentials to the application, which uses the fine-grained access policies configured in the management console to display only the appropriate information.
An IT administrator configures the platform, applications, and access policies using the Datawiza management console, instead of having to deal with the configuration files scattered in hybrid multicloud environments.
Datawiza, the no-code path to Zero Trust access management
The Datawiza No-Code platform can accelerate your Azure AD journey to Zero Trust for your applications and APIs by eliminating the need for developers to extend controls to support Zero Trust requirements such as SSO and multifactor authentication. Datawiza authenticates and authorizes every employee, customer, contractor, or partner each time they access an application or API—with fine-grained access controls—and supports every type of application in hybrid multicloud environments. With Datawiza, policy administrators can leverage “change once, propagate everywhere” to keep policies, roles, and permissions updated and synced across hundreds or thousands of datasets. And Datawiza maintains the relationships between applications and Azure AD as the applications are updated, future-proofing your environment.
The Datawiza Platform is available in the Microsoft Azure Marketplace. More information and a free trial are also available on the Datawiza website.
To learn more about MISA, visit our MISA website where you can learn about the MISA program, product integrations, and find MISA members. Visit the video playlist to learn about the strength of member integrations with Microsoft products.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity.
