In the wake of devastating attacks, here are some of the best techniques and policies a company can implement to protect its data.

Artificial Intelligence and Security: What You Should Know

Joshua Bevitz, Partner, Newmeyer Dillion

Gabriella Stevens, Associate, Newmeyer Dillion

Prashant Sharma, Co-Founder & CTO, Secuvy Inc.

7 Ways to Avoid Worst-Case Cyber Scenarios

Most organizations still rely on virtual private networks for secure remote access.

Zero-trust initiatives may be on the security roadmap for most enterprises today, but remote-access architecture today is still highly dependent upon virtual private network (VPN) technology.

Newly published data shows that approximately 90% of organizations still utilize VPN in some capacity to secure remote access for their users. Meantime, across a broad population of IT and security practitioners, fewer than one in three say they have plans to — or have begun to — roll out zero-trust network access (ZTNA) to supplant VPN.

The results are from a survey conducted by Sapio Research on behalf of Banyan Security, which reached out to 1,025 IT respondents, focusing the bulk of the survey on the 410 who were aware of both VPN and ZTNA. The study shows that among that group, a full 97% reported that adopting a zero-trust model is a priority for them. Slightly over half of those aware of both VPN and ZTNA said they've begun to roll out zero-trust solutions.

ZTNA is a term Gartner started championing in 2019 to describe in broad strokes a range of products and services that create logical access boundaries around applications or sets of applications using a combination of identity- and context-based factors. The firm predicted at the time that by next year, 2023, approximately 60% of enterprises will start phasing out their VPNs in favor or ZTNA.

"VPNs are just a band aid on a fundamentally broken network security model. And ultimately this has to be replaced," Neil MacDonald, vice president and distinguished analyst for Gartner, said in a recent analysis of zero-trust strategies in 2022. "We need to invert the model. Instead of connecting and then worrying about authentication, we need to authenticate first, then connect. This is where you see many of the tenets of zero-trust networking coming in."

**The Problem With VPNs**

One of the biggest problems with VPN technology is the fact that it "allows for network-level access to an enterprise," explains Deloitte's Andrew Rafla, who leads the consultancy's zero-trust offering.

In contrast, ZTNA restricts remote users' access to only the specific applications and assets they need and nothing more, says Rafla. ZTNA is one important component of a broader zero-trust architecture, he says, which also should include a centralized and federated identity store, privileged access management controls, data protection, network segmentation, device security, and telemetry and analytics.

"General cyber hygiene fundamentals should not be overlooked as well; in order to realize the true benefits of the zero-trust model, an organization should have a solid grasp on its IT asset management, configuration and vulnerability management, and data classification," Rafla says.

Given these weighty requirements to truly grab the zero-trust brass ring, it should come as no surprise that many organizations can feel overwhelmed by it all. Over two-thirds of current VPN users report in this survey that implementing a ZTNA strategy is a large to very large undertaking.

The biggest constraint for VPN-dependent organizations that keep them from transitioning to ZTNA are cost/budget constraints, which was named by 62%. Approximately 13% of them say zero trust is confusing and they don’t even know where to start.

Interestingly, though, among those who have adopted ZTNA, the implementation timeframes may not be as scary as those clinging to VPN may think. The study shows that the mean time to deployment was about 11.5 months. This may be a good lesson in the fact that an organization can and should roll out zero-trust components in a phased manner, and that ZTNA for remote access may be an accessible first step in the journey.

VPNs Persist Despite Zero-Trust Fervor

ToddyCat's Samurai and Ninja tools are designed to give attackers persistent and deep access on compromised networks, security vendor says.

A threat group that may have been among the first to exploit the ProxyLogon zero-day vulnerability in Exchange Servers last year is using a pair of dangerous and previously unseen malware tools in a cyber espionage campaign targeting military and government organizations in Europe and Asia.

Researchers at Kaspersky who first detected the group's activities this week described the tools as malware designed to enable long-term persistence on an organization's public-facing Web servers and giving attackers the ability to move laterally and penetrate deeply into compromised networks.

The malware tools have features that allow their functionality to be extended at will, but Kaspersky has been unable so far to determine the full range of their capabilities, the vendor noted.

**Attacks Targeted ProxyLogon Exchange Server Flaw**

Kaspersky is tracking the previously unknown group as "ToddyCat." In a report this week, the security vendor said the adversary's victim targeting and certain operational overlaps with at least one known Chinese threat actor suggest that members of ToddyCat are Chinese-speaking as well.

"This group targets high-profile organizations, usually government, diplomatic, military organizations, and military contractors," says Giampaolo Dedola, security researcher at Kaspersky. It may be possible that the threat actor has compromised victims in the US as well. But currently Kaspersky has no information to suggest this is indeed the case, Dedola says.

Kaspersky's analysis showed that ToddyCat's campaign began in December 2020 with attacks targeting selected Exchange Servers belonging to three organizations in Vietnam and Taiwan. The attackers used an unknown exploit to breach the Exchange Servers and deploy the popular China Chopper Web shell on the systems. They then used the Web shell to initiate a multi-stage infection chain involving custom loaders that ended with one of the new malware tools — a backdoor called "Samurai" — being deployed on the compromised system.

**Sophisticated Malware**

Samurai is a passive backdoor designed to give the attackers persistent access on Internet-facing Web servers. The backdoor works on ports 80 and 443 and is designed primarily to execute arbitrary C# code on infected systems.

"Based on our investigation, we were able to detect some of the source codes uploaded by the attacker and we know that it was used to execute arbitrary commands, download files, forward TCP packets to internal hosts," Dedola says. As one example, he points to the attacker using Samurai to communicate with internal Active Directory servers. "The ability to run arbitrary C# code allows attackers to infinitely extend the malware's capabilities," he says.

Kaspersky's research showed the attackers also used Samurai to launch "Ninja," the other previously unseen malware tool that ToddyCat is using in its attacks. Ninja is Cobalt Strike-like malware for executing post-exploitation activities on already compromised systems.

"It allows the attackers to control the remote system, manipulate the file system, manipulate processes, inject arbitrary code in other processes, forward TCP packets, and load new modules in its memory," Dedola says.

Ninja agents can be configured to act like servers. So, the adversary can use the malware to designate specific machines as internal command and control servers (C2s), thereby limiting connections to external servers and reducing the chances of being detected. This feature, combined with the TCP command forwarding functionality, gives the attackers a way to manage even those systems that are not directly connected to the Internet, Dedola says.

Between Dec. 2020 and early Feb. 2021, ToddyCat remained tightly focused on a handful of organizations in Vietnam and Taiwan. But then, for a brief period between late February and early March, the threat actor quickly escalated its attacks by targeting the ProxyLogon vulnerability to compromise organizations in multiple countries. The group's victims included organizations in Russia, UK, Slovakia, India, Iran, and Malaysia, and belonged to industries and sectors that have traditionally been of interest to China-based groups, Kaspersky said.

**A Change in Tactics**

Almost all of ToddyCat's early attacks targeted Exchange Server flaws. But starting Sept. 2021, Kaspersky observed what it described as "waves of attacks" against desktop systems involving the use of malicious loaders sent via the Telegram messaging service. It's unclear how many organizations ToddyCat has compromised, but the number is likely less than 30, Dedola says.

What makes Samurai and Ninja dangerous is the anti-forensic and anti-analysis technique incorporated into the malware, according to Kaspersky. For example. Samurai is designed to share TCP port 80 and 443 with Microsoft Exchange and cannot be detected by monitoring the ports. The malware also uses a complex loading scheme to avoid detection and maintain persistence. It addition, it uses a technique called "control-code flattening" to avoid detection by static analysis tools, Dedola says.

"The Ninja Trojan is also another modular malware, with capabilities that can be easily extended by the attacker," he tells Dark Reading, adding that the malware runs only in memory and never appears on file systems, making it harder to detect. "It is usually executed with a loader, which decrypts the payload from a third file. The file with the encrypted payload is immediately deleted by the loader."

Christopher Prewitt, CTO at Inversion6, says Kaspersky's research shows that the malware authors have gone to great lengths to hide and obfuscate their methods. While the Samurai backdoor features some relatively common features, ToddyCat's bespoke Ninja post-exploit tool appears more interesting.

"It is loaded in memory, making it much more difficult to analyze and detect," Prewitt says. "The threat actor could continue to reuse this part of their toolkit, while only swapping out or updating the initial infection point and backdoor tooling."

China-Linked ToddyCat APT Pioneers Novel Spyware

After the Raccoon Stealer Trojan disappeared, the RIG Exploit Kit seamlessly adopted Dridex for credential theft.

The cybercriminals behind the RIG Exploit Kit earlier this year traded out the credential-stealer Trojan Raccoon Stealer after its lead developer was killed in the Russian invasion of Ukraine.

According to analysts with Bitdefender, the cybercrime group behind the RIG Exploit Kit was able to quickly substitute in the tried-and-true financial Trojan Dridex, which has a range of functions, including keylogging and the ability to steal screenshots. 

"The move to Dridex was a strategic decision to save the operation," Bogdan Botezatu, director, Threat Research and Reporting at Bitdefender, tells Dark Reading. "Cybercriminals running this campaign had to move to a different option or lose the money they had already invested in renting out access to the RIG EK panel. Dridex is a powerful information-stealer that, to some extent, provides similar functionality to Raccoon. Unlike Raccoon, it is still operational and can offer 'business continuity' to the cybercriminals behind this campaign."

The RIG Exploit Kit lets cybercriminals quickly swap out payloads to avoid detection or in case of compromise, according to researchers at Bitdefender, making adaptability part of its product. 

"This once again demonstrates that threat actors are agile and quick to adapt to change," the analysts wrote in their report on the malware campaign. 

"In order to be prepared, defenders should patch the known vulnerabilities in software used across the organization and monitor for the indicators of compromise (IOCs), Botezatu counsels. "A security solution with machine-learning capabilities can detect and block the payload at various execution stages as well."

It's also worth noting that Racoon is likely to make a reappearance, Botezatu notes.

"The Raccoon group has hit a temporary stop with the death of one of its operators, but we believe the team will regroup," he says. "Usually, such groups suspend their operations when teams get arrested or when they voluntarily decide to shift to a more lucrative business. Loss of a team member is a temporary road block and we presume that they will get back online as soon as they manage to recruit a replacement."

RIG Exploit Kit Replaces Raccoon Stealer Trojan With Dridex

Experts tell teams to prepare for more regulation, platform consolidation, management scrutiny, and attackers with the ability to claim human casualties.

Security teams should prepare for what researchers say will be a challenging environment through 2023, with increased pressure from government regulators, partners, and threat actors.   

Gartner kicked off its Security & Risk Management Summit with the release of its analysts' assessments of the work ahead, which Richard Addiscott, the company's senior director analyst, discussed during his opening keynote address.

“We can’t fall into old habits and try to treat everything the same as we did in the past,” Addiscott said. “Most security and risk leaders now recognize that major disruption is only one crisis away. We can’t control it, but we can evolve our thinking, our philosophy, our program, and our architecture.”

Topping Gartner's list of eight predictions is a rise in the government regulation of consumer privacy rights and ransomware response, a widespread shift by enterprises to unify security platforms, more zero trust, and, troublingly, the prediction that by 2025 threat actors will likely have figured out how to "weaponize operational technology environments successfully to cause human casualties, the cybersecurity report said. 

The eight specific predictions are:

1.  Through 2023, government regulations requiring organizations to provide consumer privacy rights will cover 5 billion citizens and more than 70% of the global GDP.
2.  By 2025, 80% of enterprises will adopt a strategy to unify Web, cloud services, and private application access from a single vendor’s security service edge (SSE) platform.
3.  Sixty percent of organizations will embrace zero trust as a starting point for security by 2025. More than half will fail to realize the benefits.
4.  By 2025, 60% of organizations will use cybersecurity risk as a primary determinant in conducting third-party transactions and business engagements.
5.  Through 2025, 30% of nation-states will pass legislation that regulates ransomware payments, fines, and negotiations, up from less than 1% in 2021.
6.  By 2025, threat actors will have weaponized operational technology environments successfully to cause human casualties.
7.  By 2025, 70% of CEOs will mandate a culture of organizational resilience to survive coinciding threats from cybercrime, severe weather events, civil unrest, and political instabilities.
8.  By 2026, 50% of C-level executives will have performance requirements related to risk built into their employment contracts.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Gartner: Regulation, Human Costs Will Create Stormy Cybersecurity Weather Ahead

Open source is here to stay, and it's imperative that CIOs have a mature, open source engagement strategy, across consumption, contribution, and funding as a pillar of digital transformation.

Following the trio of the Log4J vulnerability and the more recent compromise of two open source libraries in the NPM ecosystem and one in Spring Core, supply chain security is weighing heavily on cyber defenders' minds. While the financial services sector has hardened its cyber defenses compared with other industries and become one of the earliest adopters of zero-trust security, institutions must continue to embrace open source technology while actively engaging in risk mitigation.

With so many foundational components of the global tech stack originating from open source code repositories like GitHub, recent exploits have heightened worries that this open ecosystem is inherently vulnerable to attack. This is especially true given the finance industry's finance industry's embrace of open source, as shown by Goldman Sachs contributing source code of several of its data modules as open source in 2020.

**Keeping Open Source Environments Protected**

First off, financial institutions must assume a more active role in the funding of open source foundations and direct-to-maintainer grants to help limit exposures from critical code dependencies, as illustrated by the Log4Shell debacle. To this end, public-private sector partnerships will be vital for financial institutions looking to harden their open source security postures. Confronting the inherent DevSecOps of the open source ecosystem requires a financial and strategic commitment from institutions willing to support the whole spectrum of open source maintainers — and not just the Apache Software Foundations of this world. Projects like the OpenSSF Alpha-Omega initiative are a great example of this approach.

Financial institutions also need to adopt a more robust software bill of materials (SBOMs), a key point highlighted in President Biden’s executive order from last June. Modern SBOMs deploy machine-readable processing, a technology that enables systems to ingest incoming structured report data, to autonomously analyze the state of SBOM readiness by organizations around the world. SBOMs can thus help financial institutions rapidly identify patterns across their industry and across borders, helping them spot critical risk issues before they metastasize into larger problems.

A table-stakes strategy for financial institutions to mitigate open source risks on the consumption side include the implementation of stronger internal license and IP controls and tools to track and monitor inbound open source projects. More granular strategic solutions start with financial institutions taking time to understand the defenders that are focused on securing the open source realm. Organizations like Mend, Sonatype, and Synk are key players in this world.

The broader sustainability of the open source ecosystem is another reason for financial institutions to assume a more hands-on role in the development of code repositories and other active-source artifacts. Institutions should consider offering secure coding training as part of their onboarding, something too often overlooked in academic curricula.

Encouraging in-house developers to contribute "sweat equity" to the ecosystem will increase the number of eyes on open source artifacts, thus enhancing the odds that financial institutions will be able to spot code vulnerabilities before they threaten a SolarWinds type of breach. This approach will effectively reduce the probability and blast radius of future vulnerabilities.

**Benefits of Open Source Outweigh the Risks**

Despite recent, worrisome supply chain attacks, financial institutions should not be deterred by these challenges. The global financial industry is now very seriously democratizing software through open source, not only as a cost reduction but as a powerful collaboration model that goes beyond code to be used to address challenges like data standardization and industrywide interoperable workflows. Open source is here to stay, and therefore it is no longer optional — it's imperative that CIOs have a mature, open source engagement strategy, across consumption, contribution, and funding as a pillar of their digital transformation endeavors.

Institutions are doing more than just implementing code that another developer has updated. Financial organizations should look to invest internal developer resources to actively contribute to code repositories. Developers should be contributing code not just in their spare time, but more appropriately, while they're on the job within the expected scope of their organizational roles.

By taking a proprietary stake in the open-innovation ecosystem, financial institutions can better mitigate vulnerabilities and exposures emanating from their tech stacks. This type of risk management also requires the articulation of companywide policies, learning, and collaboration resources throughout the firm. Naturally, financial institutions need to delegate and establish leadership roles to oversee the effort.

Whether through open source foundations or direct monetary or sweat-equity contributions to projects, financial institutions must realize the importance of professional software supply chain management. They should also understand the roles that consumers must play in securing the open source IT stack, which underpins the modern digital economy.

Why Financial Institutions Must Double Down on Open Source Investments

While there's an immediate need to improve MFA adoption, it's also critical to move to more advanced and secure passwordless frameworks, including biometrics. (Part 1 of 2)

The fact that we continue to rely on passwords this deep into the digital age is more than a bit jarring. These alphanumeric scraps, the equivalent of digital skeleton keys, once served as a valuable tool. Unfortunately, passwords are now far more trouble than they're worth. They provide little protection against identity theft, breaches, and myriad other problems.

Yet completely ditching passwords is out of the question — at least for now. While they may rank as an almost total security fail and a bane for everyone, they remain an entrenched standard. Consequently, multifactor authentication (MFA) has become a necessity, but it too presents challenges bordering on outright problems.

This is the first of a two-part series about how businesses can adopt stronger and better authentication methods. While there's an immediate need to boost MFA adoption, it's also critical to move to more advanced and secure passwordless frameworks, including those that use biometrics.

**Embarrassment of Riches**

As with every technology, an accumulation of solutions eventually becomes a new problem. Most organizations and many consumers recognize the need to move beyond password-only authentication. Yet two-factor authentication (2FA) and even many MFA techniques were never designed for today's sophisticated digital frameworks.

"When you log into six different systems during the day and each of them uses a different method ... you wind up with two-factor authentication PTSD," says Michael Engle, co-founder and chief security officer at 1Kosmos. "You spend a significant time fetching codes and launching apps."

The mix of methods — including time-based one-time password (TOTP), SMS and email 2FA, push-based 2FA, universal second factor (U2F) tokens, WebAuthn, and desktop agents — introduce an often-confusing array of options for both companies and consumers. Making matters worse, they deliver varying levels of protection, and most people aren't equipped to understand the pros and cons. For instance, widely used SMS and email codes are easily intercepted or breached when a crook has access to a device. Toolkits that facilitate man-in-the-middle attacks and other password exploits are now widely available on sites such as GitHub.

Consumer and enterprise fatigue is at a breaking point. And while significantly better MFA and passwordless systems are taking shape — Apple, Google, and Microsoft have announced they are moving to passwordless sign-ins built on the FIDO2 standard — organizations continue to struggle with adoption.

Design, usability, and functionality are all critical. There's a need to convince people to move beyond a basic password and adopt MFA, but it's also critical to deploy higher grade MFA methods while moving to passwordless. 

"This requires improved UX and education. There's a need for the process to be seamless," says Don Tait, a senior analyst at Omdia Consulting.

**Risky Business**

It's a startling and entirely disturbing fact: Despite a seemingly endless string of hacks, attacks, breaches, and breakdowns — 81% of hacking-related breaches are caused by password issues — only 29% of consumers believe that the inconvenience of 2FA is always worth the security trade-off. About 36% are willing to use 2FA in some cases, depending on the importance of the account.

The reasons for this reticence are at least partly rooted in the nature of today's online world. For better or worse, people expect Web pages to load instantaneously, and they seek access to accounts without any latency — even when dozens of APIs and servers around the world are required for a transaction. Remarkably, one study conducted by Microsoft found that the average person only has an attention span of approximately eight seconds.

Yet it's also clear that MFA frameworks can be a big hassle. Oftentimes, it's necessary to request a text code or pull out a phone and open an authenticator app from Google or Microsoft and type in a code. Meanwhile, physical tokens, such as YubiKey, offer stellar security — but they can be difficult to set up and use.

MFA participation is ticking up due to the pandemic and ominous warnings about the risks of relying on a password only; Okta found that MFA adoption rose by about 80% during the early stages of the pandemic. However, attacks are escalating and becoming more sophisticated. The net result is a relative move backward.

"There are too many companies giving too little thought to how to implement more advanced MFA and passwordless systems," says Jasson Casey, CTO for authentication vendor Beyond Identity. "You can't build a security architecture without considering design and usability. As the level of friction goes up, participation goes down."

These issues unfold in several ways. Design elements may hide MFA options or deliver confusing instructions for how to set it up. They sometimes provide confusing or ominous warnings that frighten users, or a site or service doesn't communicate the value of using MFA. Frequently, users don't see any compelling reason to adopt this additional layer of security.

"People turn to digital services because they're looking for ease of use and convenience," says Kalev Rundu, senior product manager at authentication firm Veriff. MFA must not be any different. It must fit seamlessly with the broader digital interaction and deliver a clear advantage or other forms of authentication.

**Designs on Security**

Gaining buy-in is critical. Researchers from the Max Planck Institute for Security and Privacy; the University of California, San Diego; and Facebook found that one of the keys to convincing people to turn on MFA is to present the decision as a personal empowerment choice. This might include a message like, "You can increase your protection against account hacking" or "Protect your account, pages and friends."

When researchers tested this personal responsibility approach with accompanying buttons on Facebook, it led to an uptick in MFA adoption by 33% among 622,419 participants. When users viewed a message about the advantages of being protected, they were 28% more likely to adopt MFA. On the other hand, the corporate responsibility button didn't prompt any change in behavior.

Another technique that boosts adoption revolves around an incentive or a reward — an approach that has already gained traction within gaming platforms like Fortnight and World of Warcraft. In 2019, a group of researchers from the University of Bonn and Leibniz University Hannover in Germany found that even a small incentive, such as an upgraded avatar or another small gift, can push numbers up.

Colors, placement, and design elements also matter. Delivering the request at the right moment — without interrupting the flow of an interaction or transaction — is crucial. 

"It must be so easy that doing it for the first time has nearly no friction," 1Kosmos' Engle says. QR codes and push-to-app authentications can help, especially when a user can authorize the sign-in from a separate authorized device.

Still, none of these approaches are seamless — and they aren't bulletproof. The future of MFA and full passwordless systems lies in biometrics, FIDO2, and emerging systems that not only authenticate to an account on a device, but also verify a person's identity. 

"A new era of authentication is emerging," Omdia's Tait says.

_In part 2, Dark Reading takes a look at the rapidly evolving passwordless space and what companies need to do to stamp out passwords once and for all._

Evolving Beyond the Password: It's Time to Up the Ante

The BRATA Android banking Trojan is evolving into a persistent threat with a new phishing technique and event-logging capabilities.

An Android-based banking Trojan known as BRATA (short for Brazilian RAT Android) has evolved to incorporate new phishing techniques and capabilities to acquire GPS, overlay, SMS, and device management permissions.  

The Italian mobile security company Cleafy reported in a blog post this week that these changes align with an advanced persistent threat (APT) pattern of activity.

"Threat actors behind BRATA now target a specific financial institution at a time, and change their focus only once the targeted victim starts to implement consistent countermeasures against them," the blog post explained. "Then, they move away from the spotlight, to come out with a different target and strategies of infections."

The new variant, which is targeting the EU region by posing as specific bank applications, can also now perform event logging through its ability to sideload a second-stage piece of malware from its command-and-control (C2) server.

**Ability to Bypass MFA**

The threat actors operating the new malware variant (BRATA.A) are also expanding their capabilities to include a methodology for potentially bypassing SMS-based multifactor authentication (MFA).

The updated phishing technique can mimic a targeted bank's login page, part of the group's strategy to acquire personal information to be used later for social-engineering purposes.

"Once installed, the pattern of the attack is similar to other SMS stealers," according to the blog post. "This consists in the malicious app asking the user to change the default messaging app with the malicious one to intercept all incoming messages."

Credential harvesting is common in banking Trojans and stealer malware, but bypassing MFA is a bit more complicated.

"This functionality, along with BRATA's ability to remain undetected for prolonged periods of time, could potentially classify the threat actors as an APT," says Nicole Hoffman, senior cyber threat intelligence analyst at Digital Shadows.

**BRATA Actors Thinking About Future Development**

From the perspective of John Bambenek, principal threat hunter at Netenrich, the ability to request additional permissions on the device indicates what the attackers are thinking as far as future development.

"Not all the new features are actively collecting and transmitting data to the attacker, but future updates can change that," he says. "The actors are spending real effort to make sure they can maximize their success. Banks are constantly evolving, so attackers must do so also."

He adds that because mobile malware is typically still just an app, consumers can protect themselves by only installing apps from approved app stores and be wary when apps are asking for banking credentials.

"Financial institutions need to invest in behavioral analytics to detect stolen credential use against their online presence to prevent fraud against their consumers," Bambenek says.

In a statement provided to Dark Reading, the Cleafy Threat Intelligence team notes BRATA's evolution suggests the threat actors plan to diversify their business model, and consequently its income.

Cleafy's hypothesis is that BRATA is sold as malware-as-a-service (MaaS) to different groups, since the firm is tracking many variants of this malware hitting different countries across the globe.

"It has been observed that they started refactoring part of the malware, in order to tailor it according to the requests of their customers," the statement reads.

**Evolution of a Trojan**

In January, Cleafy discovered the group behind BRATA manipulating Android's factory reset to prevent victims from discovering or reporting and preventing illicit wire transfers. At that point, the malware campaigns were targeting Italian banks.

During the last year, BRATA was delivered through sideloading techniques, not through the official Google Play Store.

Cleafy recommends users pay particular attention to downloading apps from untrusted websites or whenever SMS is required to install an application.

"However, considering the Android 13 restriction for sideloaded apps, we do not exclude that in the future BRATA will be also delivered through official stores, like other famous malware have been trying to do in recent months (e.g. Sharkbot, Teabot etc.)," the statement continues.

Kaspersky first discovered BRATA in 2019 when it was simply spyware and targeted at users in Brazil.

BRATA Android Malware Evolves Into an APT

Zero trust isn’t just about authentication. Organizations can combine identity data with business awareness to address issues such as insider threat.

Zero trust is growing in popularity in enterprise security because not trusting users by default works really well to reduce risk. However, people start having unrealistic expectations when they conflate reducing risk with eliminating risk, says Nabil Zoldjalali, VP of technology innovation at Darktrace. There is a subtle difference between the two that security teams can’t overlook.  

“I can eliminate risk entirely if I have absolute no trust,” Zoldjalali says. What’s more realistic – and attainable – is to try to lower the amount of default trust to as close to zero as possible. Zero trust should be treated as “an ideal end-state,” he adds.

As long as people have access to applications, tools, and different pieces of software, there’s always going to be a level of inherent risk. The idea behind zero-trust architecture is to set up context-based access for each identity so that users only see and access the applications that are relevant to them.

Context-aware access takes into account different factors. A user logging in may see only three applications when logging in as opposed to all the applications belonging to the organization. That list may change depending on time, especially if there are certain times or dates when the user is not expected to use that application. Or a user logging in from a different location would also get a different level of access.

**Zero Trust Requires Business Visibility**

Zero trust makes sense for security practitioners because they focus on attacker behavior and all the way things can go wrong, Zoldjalali says. But focusing on the attacker too much can make it easy to forget to think about what is being protected. 

“We’re saying, ‘I don’t want to inherently trust anyone in my business because if something goes wrong, I want to lower the blast radius that’s associated to it,’ and that’s meaningful to us,” he says. “But it sounds funny to a nonsecurity person when we say, ‘Listen, the company doesn’t trust anyone.’”

For zero trust to really work, both approaches – lowering trust and developing a strong understanding and awareness of the business – are critical. Having that business awareness and wall-to-wall visibility gives security teams the context necessary for zero trust. It also allows them to verify that the zero-trust architecture is working as planned. For instance, if the organization’s rules for conditional access aren’t working when they should be, it would be hard for security teams to even know that is the case if they don’t understand the business, Zoldjalali says.

**Zero Trust Beyond Authentication**

The beauty of zero trust is that its effects go beyond authentication. Security teams can combine identity data with information about what happened in the environment _after_ authentication to detect and actually stop attacks, Zoldjalali says. Security teams can look at incidents and trace digital activity back to see what the authentication prompt looked like and how the user was identified. Based on that information, security staff can make changes to the group policy or adjust permissions.

Darktrace’s self-learning artificial intelligence (AI) learns the business so that it knows what activities would be considered part of normal operations, Zoldjalali explains. Because the AI technology looks for deviations from the norm, it doesn’t need to know what historic attacks looked like or understand what kind of attacks are currently ongoing. It just looks for something that is different. 

“With zero trust, we allow people to do what they normally do,” he says. The AI assesses significant deviations from the person’s normal behavior to determine whether there is a threat to the business. If there is, the AI takes action to address the threat.

This mindset is extremely useful when considering the insider threat. 

“Insiders don’t just wake up one morning and say, ‘Today I’m going to be a big threat to the business.’ There’s usually some kind of context and back story,” Zoldjalali says. There may be a specific incident that acts as a trigger or a pattern of issues that contributes to a sense of unhappiness. 

So at that point, the user action – such as an act of sabotage or data theft – looks “very, very different from how they normally behave,” he says. The user may be logging in at unusual hours, using different devices, going down different folder paths, or downloading more data than usual.

“Having an approach that’s fundamentally based on understanding the business is one of the best ways to have accurate anomaly detection,” Zoldjalali says. And with early detection, security teams can adjust context-based access policies to block the user’s activities.

“When you combine different approaches, that's where you start getting closer and closer to an ideal state \[for zero trust\]," he adds.

Reducing Risk With Zero Trust

Deep-dive study unearthed security flaws that could allow remote code execution, file manipulation, and malicious firmware uploads, among other badness.

A new analysis of data from multiple sources has uncovered a total of 56 vulnerabilities in OT products from 10 vendors, including notable ones such as Honeywell, Siemens, and Emerson.

Many of the vulnerabilities are the result of device vendors not including basic security mechanisms, such as authentication and encryption, in their technologies. Often they exist in older products that asset owners are continuing to use even though more secure options are available. Significantly, the vulnerabilities are present in products that have gone through some sort of auditing process and were certified as being safe for OT networks, a new study by Forescout found.

Researchers from Forescout’s Vedere Labs discovered the vulnerabilities from data they gathered via open source intelligence, Shodan search-engine queries, and customer networks. The vulnerabilities exist in widely used products and protocols in a range of critical infrastructure sectors, such as oil and gas, chemical, nuclear, and power generation. The security vendor released a report Tuesday highlighting the main findings from its study.

The vulnerabilities — collectively labeled “OT: Icefall” — stemmed from four primary reasons: insecure engineering protocols, weak cryptography or broken authentication mechanisms, insecure firmware updates, and native functions that enabled remote code execution. The bugs enabled a variety of malicious activity, including remote code execution, denial-of-service attacks, file and configuration manipulation, authentication bypass, and credential theft. Affected devices included programmable logic controllers, remote terminal units, engineering workstations, distribute control systems, and one supervisory control and data acquisition (SCADA) system.

**Insecure by Design**

The flaws were not introduced by programming and coding errors, says Daniel dos Santos, head of security research at Forescout. Rather, the technologies are vulnerable to attack because they are insecure by design, Santos says. They often lack critical controls like those needed to authenticate users and actions, encrypt data, and verify whether firmware updates and software are signed and verified. When these mechanisms are present, they are often weak and easily hacked or seriously undermined by other issues, like the presence of hard-coded and plaintext credentials on the device, insufficient randomness and broken crypto, or features that allow arbitrary file writes, he says.

“While it’s a semantic difference and ends up with the same vulnerabilities, it’s not so much they are 'insecure by design' as they are designed without security as a consideration,” says Mike Parkin, senior technical engineer at Vulcan Cyber. “Stronger security has been baked into newer OT equipment, but there is still a lot of kit out there where it just wasn’t a consideration." 

In many cases OT technology was designed with the idea that it would be isolated, protected from outside access, and not exposed to anything but its operational environment. “Unfortunately, the real world wasn’t quite so cleanly defined,” he says.

Foresight found numerous instances of vulnerabilities tied to poor design. For instance, 38% of the vulnerabilities that Forescout discovered allowed for credential compromise, and 21% gave attackers a way to introduce poisoned firmware into the environment. Fourteen percent of the flaws stemmed from native functionality — such as logic downloads, firmware updates, and memory read/write operations — that gave attackers a way to execute malicious code remotely on OT systems. 

For example, none of the affected systems supported logic signing, 62% accepted firmware downloads via Ethernet, and 51% authenticated such downloads. Nine of the 56 flaws that Forescout discovered were related to unauthenticated protocols.

**(Not) Certifiably Secure  
**

Disturbingly, nearly three-quarters — 74% — of the vulnerable product families had some sort of certification regarding their suitability for use in critical OT environments. Examples of such certifications included ISASecure Component Security Assurance, ISASecure System Security Assurance (SSA), GE Achilles Communications Certification, and ANSSI Certification de Sécurité de Premier Niveau. 

The fact that vulnerable products were certified as compliant with these standards suggests product evaluations were likely limited in scope, were too focused on functional testing, or were hobbled by opaque security definitions, Forescout said.

The presence of vulnerabilities stemming from insecure design in OT devices and protocols is troubling because of the growing attacker interest in these environments, Santos says. He points to ICS- and OT- specific malware such as Industroyer, Triton and Incontroller as evidence of the increasingly sophisticated capabilities that attackers have begun to deploy in attacking ICS and OT facilities. 

“There is still this lingering notion that attackers don’t understand the environment or proprietary OT technology,” Santos says. 

That is simply not true, he says. Nation-state actors and even well-resourced ransomware groups have demonstrated their ability to access OT environments. Detailed information on OT environments is also available in the public domain and equipment for testing out attacks are easily available in markets for used technology products, he notes.

“OT/ICS and IoT environments are becoming the preferred targets by cybercriminals, for many reasons,” says Bud Broomhead, CEO at Viakoo. 

Among them is the growing use of vulnerable open source components — such as Log4j — in OT/ICS environments and the fact that the systems are often managed outside the IT department. 

“Often OT/ICS teams lack the IT skills to maintain complete cyber hygiene” and are focused on operational issues instead, Broomhead says. As a result, there is little oversight over patching practices and password management. OT/ICS devices are often also not visible to IT, or sometimes to the organizations managing them. 

Another issue is that devices are often used well past the manufacturer's support time frame. 

“Many OT/ICS devices are in operation past the time the manufacturer is supporting patches or updates,” Broomhead says. “Security solutions used for IT systems do not work for OT/ISC environments. OT/ICS devices do not accept agents, and therefore organizations must implement solutions, such as for patching, certificate management, and password rotations specifically designed for OT/ISC environments.”

Parkin also urges organizations to pay attention to the fundamental security practices such as keeping patches up to date and implementing proper network segmentation and isolation to keep OT and ICS environments away from public access. 

“The management and control platforms should have proper isolation and authentication, including multi-factor authentication, and there should be some kind of traffic monitoring in place to make sure \[OT\] is only being accessed by authorized users from authorized locations,” he says.

Source

DARKReading