**BOSTON** **–** **April** **20,** **2023** **–** Bitsight, a leader in managing and monitoring cyber risk, today unveiled its expansion into a broader category of integrated cyber risk management. As the category creator and global leader in the cybersecurity ratings industry, Bitsight’s enhanced strategy will deliver new capabilities to empower security professionals and business leaders to more effectively and holistically manage cyber risk. The announcement includes large-scale distribution of risk data and insights through Moody’s/BVD’s Orbis, a new Third-Party Vulnerability Detection & Response solution, and more predictive cyber risk ratings that help mitigate cyber risk and make CISOs and risk professionals’ jobs easier.

Bitsight’s integrated solutions address the needs of CISOs and risk leaders, whose roles have become more challenging in recent years with digital transformation, supply chain risk, and expanded attack surfaces. “As the cyber threat landscape worsens and the global regulatory landscape demands more nimble and thorough risk management, Bitsight has evolved to stay ahead of our customers’ needs. Business leaders, risk leaders and boards are turning to us as an integrated solution to manage risk and build trust across their ecosystem,” said Bitsight CEO Steve Harvey.

Furthermore, comprehensive cyber risk management is also essential to good corporate governance, reaffirmed by the recently released White House national cyber strategy, pending SEC regulations on cybersecurity disclosure, and cybersecurity requirements emerging throughout Europe and Asia. Harvey noted, “Our strategic shift to become an integrated cyber risk management leader means we’re able to provide customers and governments with the industry’s most impactful data, services and tools to confidently navigate the uncertain cyber landscape.”

**Accelerated Partnership with Moody's Corporation**

Newly-added integrations with Moody’s will deliver expanded insights for enterprises and assist with holistic cyber risk management. In October 2021, Moody's Corporation invested $250 million in Bitsight, and the two companies announced a landmark partnership agreement. Through this partnership, Bitsight became the primary cyber risk analytics provider across Moody’s suite of integrated risk assessment offerings.

Bitsight data is now accessible by nearly 2,000 global credit analysts within Moody’s Investors Service. These analysts are leveraging Bitsight to better understand the relative cyber risk of issuers, engage issuers on cybersecurity risk, and publish research on the intersection of cyber risk and credit risk. Additionally, Bitsight ratings data is now also integrated within Moody’s Analytics' BVD Orbis platform, enabling non-technical risk managers to easily consider cyber risk factors in counterparty risk analysis.

“The rise of cyberattacks and ransomware has created an imperative for business leaders and boards to assess and quantify their cyber risk,” said Moody’s Analytics President Stephen Tulenko. “Bitsight is our trusted partner in helping leaders to better understand, measure, and navigate the cyber risk landscape with confidence.”

Through these integrations, Bitsight and Moody’s insights may be used together in powerful combinations for applications such as Know-Your-Customer, supply chain management, insurance underwriting, and credit risk assessment.

**New Third-Party Vulnerability Detection & Response Application**

To further its cyber risk management capabilities, Bitsight has enhanced its Third-Party Vulnerability Detection tool to include a Response workflow. Zero-day attacks and other vulnerabilities are increasingly common, and most companies are struggling to properly manage third-party exposure to critical vulnerabilities quickly, effectively, and at scale. With Vulnerability Detection & Response, cybersecurity teams can now access the most important vulnerability data and effectively prioritize vendor outreach with built-in questionnaires while tracking vendor response progress in real time. This release is another innovative application showcasing Bitsight’s continued commitment to helping customers better monitor, manage, and mitigate vulnerabilities across their third-party ecosystems.

**More Predictive Cyber Risk Ratings – Bitsight’s Ratings Algorithm Update**

Bitsight has launched a new ratings algorithm, with several key enhancements, most notably modifying the weights of several risk vectors based on independent research and insight into how those risk vectors correlate to real life cyber events. As a part of delivering an integrated cyber risk management solution, Bitsight remains committed to investing in and producing actionable cybersecurity ratings that have the strongest correlation in the industry to the likelihood of a cyber incident. “Cybersecurity ratings remain a critical tool in cybersecurity and risk leaders’ arsenals, while the pressures and demands to address cyber risk have significantly expanded,” said Harvey.

As attacks on organizations intensify and business leaders demand greater strategic support to address risk, Bitsight’s mission to build trust in the digital economy has extended well beyond cyber risk ratings. “Risk leaders globally spend every day working against a relentless and growing problem of cyber risk uncertainty,” said Harvey. “And as waves of digital transformation continue to disrupt cybersecurity stability, we are committed to supporting our current and future customers with a broad and unified cyber risk management solution that helps them navigate with greater confidence.”

Supporting Resources

*   Learn more about our partnership with Moody’s Corporation here
*   Learn more about Third-Party Vulnerability Detection & Response here
*   Learn more about the Rating Algorithm Update here

**About Bitsight**  
Bitsight is a global cyber risk management leader transforming how organizations manage exposure, performance, and risk for themselves and their third parties. Companies rely on Bitsight to prioritize their cybersecurity investments, build greater trust within their ecosystem, and reduce their chances of financial loss. Built on over a decade of market-leading innovation, its integrated solutions deliver value across enterprise security performance, digital supply chains, cyber insurance, and data analysis.

Bitsight Expands into Integrated Cyber-Risk Management

A bug in how Google Cloud Platform handles OAuth tokens opened the door to Trojan apps that could access anything in users' personal or business Google Drives, Photos, Gmail, and more.

A security vulnerability in Google's Cloud Platform (GCP) could have allowed cyberattackers to hide an unremovable, malicious application inside a victim's Google account, dooming the account to a state of permanent, undetectable infection.

The bug, dubbed "GhostToken," was discovered and reported by Astrix Security researchers. According to an analysis released by the team on April 20, the malicious app could have paved the way for a startling array of nefarious activity, including reading the victim's Gmail account, accessing files in Google Drive and Google Photos, viewing the Google calendar, and tracking locations via Google Maps.

Armed with that information, attackers could craft extremely convincing impersonation and phishing attacks, or even place the person in physical danger.

"In even worse cases … attackers may be able to delete files from Google Drive, write emails from the victim's Gmail account to perform social engineering attacks, \[exfiltrate\] sensitive data from Google Calendar, Photos, or Docs, and more," researchers wrote in the posting.

**An App That 'Ghosts' the Victim**

The Google Cloud Platform is built to host any of thousands of applications for end users, which, like other app ecosystems, have an official store where they can be easily downloaded — in this case, the Google Marketplace — along with third-party markets. Once authorized for download by the user, the application receives a token in the background, granting access to the installer's Google account based on the permissions that the app asks for.

Using the GhostToken vulnerability, cyberattackers can craft a malicious application that they can plant in one of the app stores, masquerading as a legitimate utility or service. But once downloaded, the app will hide itself from the victim's Google account application management page.

For the user, it basically disappears.

"Since this is the only place Google users can see their applications and revoke their access, the exploit makes the malicious app unremovable from the Google account," according to the analysis. "The attacker on the other hand, as they please, can unhide their application and use the token to access the victim's account, and then quickly hide the application again to restore its unremovable state. In other words, the attacker holds a 'ghost' token to the victim's account."

Idan Gour, researcher at Astrix, says that the flaw could have had far-reaching consequences for both businesses and individuals, and that it serves as a wake-up call to remember just how much access cloud apps have into our lives, and the danger that shadow IT can have for enterprises. 

"This specific vulnerability allowed cyberattackers on one side to have access to organizational GCP environments, but on the other side, to people's personal Google Photos and their email accounts," he says. "It's worth remembering that these different services that we use every day for everything are actually prone to these kinds \[of\] challenges, and it's all about how we use it and, on the other side, how we secure it."

**Tracking Down a Phantom**

While details are scant, the technical issue generally arose from the way Google processes OAuth clients when they're decommissioned, the researchers said. Third-party OAuth clients are often integrated into apps to allow them to log users in more easily by making use of existing authentication with other trusted users. A common example is the "log in with Facebook" offered by many websites. 

As far as how it could be exploited, it starts with the fact that every application offered to Google users in the Google Marketplace (or other websites) is associated with a single GCP "project" that hosts it. If the owner of the GCP project (usually the developer) deletes it, it enters what Astrix refers to as "a limbo-like, pending deletion state," and it "stays that way for 30 days until it's fully purged and deleted."

These pending-deletion projects can be completely restored at the owner's whim from a dedicated page made for that purpose. However, for end users, the app immediately disappears from the "apps with access to your account" management page.

Thus, the attack scenario goes like this:

*   A victim authorizes a seemingly legitimate (but, in reality, evil) OAuth application. In the background, the attacker receives a token for the victim's Google account.
*   The attackers delete the project associated with the authorized OAuth application, which enters a pending deletion state — the application becomes hidden and unremovable from the victim's perspective.
*   Whenever the attackers wish to get access to the victim's data they restore the project, get a new access token, and use it to access the victim's data.
*   The attackers then immediately re-hide the application from the victim.
*   To maintain persistence, the attack loop must be executed periodically before the pending-deletion project is purged.

"During Step 2 of the attack loop, the access re-appears in the 'Apps with access to your account' page, which means the victim may technically remove the application's access in this time window," the researchers explained. "However, it's a very limited time frame which lasts until the attacker executes Step 1 of the attack loop again."

**Eternal Battle of Usability & Security**

Gour notes that the vulnerability was an unusual one because it related to a core feature that was, ostensibly, behaving as it should: Giving developers flexibility without bogging down end users with notes on apps they can no longer use.

"Normally when we talk about vulnerabilities, these are things that are broken that you can just patch and continue on," he explains. "But in this case, it was actually a core feature of GCP and how you create projects in GCP. It's actually nice to be able to revert to things that you did in the past, that you didn't mean to erase. But on the other hand, with a little bit of creativity, and a very straightforward approach, it could be turned into something that can completely break the way that identity and access management is done by an external third party that was integrated to this environment (OAuth)."

And indeed, the bug speaks to the ongoing push-pull between usability and security that's felt within all parts of an enterprise environment, Gour notes.

"The implications for cloud security, especially as it touches organizations and the private information of so many people nowadays, is that yes, sometimes it gets in the way of productivity or personal mobility, and is that what we want?" he says. "You have to be thinking of these things from the design phase and evaluate features for the balance between value to the user and security. It's much, much, much, easier to do before everything is implemented and hundreds or thousands of people are using it."

**Banishing the Ghost: Mitigation & a Patch**

Earlier this month, Google rolled out a global patch, fixing the issue by making sure that apps in a pending deletion state are still visible in a user's app management screen. However, Astrix researchers warned that while they aren't aware of active exploitation, Google Workspace administrators should look for applications that may have attacked users before the patch was initiated on April 7.

This can be done in two ways, the researchers said:

1.  Looking for applications whose client ID is the same as the 'displayText' field and removing their access if they prove to be malicious;
2.  Or inspecting the OAuth log events in the "Audit and Investigation" feature of Google Workspace for token activity of any such apps.

'GhostToken' Opens Google Accounts to Permanent Infection

The new Security Legal Research Fund and Hacking Policy Council are aimed at protecting "good faith" security researchers from legal threats and giving them a voice in policy discussions.

Security researchers who report vulnerabilities run the risk of either being slapped with legal sanctions to suppress disclosure or getting caught up in a legal battle punishing them for finding the flaws in the first place.

Even though the US Department of Justice announced last year that it won't prosecute cybersecurity researchers engaged in "good faith" vulnerability research and disclosure for violating the Computer Fraud and Abuse Act (CFAA), researchers still risk criminal and civil actions from states, foreign governments, and corporations. The nonprofit Center for Cybersecurity Policy & Law is pushing back with two coordinated initiatives – the Hacking Policy Council and the Security Legal Research Fund – to protect individuals who discover vulnerabilities that could potentially harm users if exploited.

The formation of the Hacking Policy Council and Security Legal Defense Fund underscores how critical it is to identify and disclose vulnerabilities to prevent malicious actors from gaining access to software, infrastructure, and data, says Futurum Research senior analyst Krista Macomber.

"The intention is to create a climate that encourages collaboration and information sharing and protects folks working diligently to expose potential threats," Macomber says.

The Hacking Policy Council plans to advocate and lobby for better vulnerability disclosure regulations and removing outdated laws. Founding member organizations include Google, Bugcrowd, HackerOne, Intel, Intigriti, and Luta Security. The Security Legal Research Fund, as of now, will provide only funding.

"The defense fund does not plan to provide direct legal representation to researchers at this time," said Harley Geiger, an attorney with Venable and coordinator of the two new groups, during the press conference announcing the two initiatives. "Instead, it will help provide funding to individuals who are facing legal threats due to good faith security research and vulnerability disclosure."

**Plight of Ethical Hackers**

James Dempsey, one of the Security Legal Research Fund's board members and a lecturer at the University of California at Berkeley Law and Stanford University, noted that independent researchers have long faced legal jeopardy for their efforts. For example, Dempsey pointed to a well-known case in 2008 when a judge issued an injunction that prevented a team of MIT students from presenting at the DEF CON security conference about vulnerabilities they discovered in Massachusetts Bay Transit Authority's fare card system.

Dempsey pointed to a more recent case in 2021 when Missouri Governor Mike Parson threatened to prosecute reporters at the St. Louis Post-Dispatch after the newspaper published an article exposing vulnerabilities on a state agency's website. But Missouri prosecutors ultimately declined to file charges.

"To get that letter on the letterhead threatening legal action can be very intimidating, and that's what we want to help people overcome," Dempsey said.

"This issue has so much impact that I think it really merits a group that is tightly focused on this issue and can bring that expertise to policymakers to help them make more informed policy," said Charley Snyder, Google's head of security policy.

The Hacking Policy Council will initially work to lobby for changes in laws and regulations in the US and, ultimately, worldwide. Luta Security founder and CEO Katie Moussouris emphasized that many regulations are outdated.

"Right now we have a lot of regulations that were, frankly, written in a different era when there was not a nuanced understanding of the hand-in-hand relationship between vulnerability discovery and malicious hacking prevention," she said.

Complicating matters is the global disparity in regulations and policies, which sometimes require disclosure to a government, either in tandem or before notifying affected users and the public, Moussouris noted. A provision in the Cyber Resilience Act, proposed by the European Commission, would require anyone in the EU discovering a vulnerability to disclose it within 24 hours.

"As written, it will be as effective for security as GDPR was for privacy; it will have that much of an impact," Venable's Geiger said.

Adding to the complexity, Geiger noted that the current definition doesn't distinguish between good faith security research and malicious criminals.

"There is currently no provision for making sure that the vulnerability, before it is disclosed, is patched," he said. "Part of the concern with the CRA is that you then end up EU-wide with a rolling list of software and vulnerabilities that may not yet be mitigated, shared with perhaps dozens of EU government agencies."

**Legal Aid for Security Researchers**

The Security Legal Research Fund will help good faith security researchers and penetration testers facing cease-and-desist letters, lawsuits, fines, and prosecution for disclosing vulnerabilities, said Tim Willis, head of Google's Project Zero team, during the media briefing.

"My hope in the long term for this fund is that the chilling effect that is currently felt by security researchers is reversed over time. One thing that all these parties can agree on is that users lose when things don't get fixed quickly," Willis said.

Geiger emphasized that the effort would focus on protecting ethical hackers who only use their research to protect users.

"The fund is not looking at helping good faith security researchers who are sued for something like extortion if they, in fact, committed extortion," Geiger said. "It will be for the act of good faith security research or the act of vulnerability disclosure connected with that good faith security research."

Amie Stepanovich, VP of US policy at the Future of Privacy Forum and a Security Research Legal Defense Fund board member, said each request will be considered based on the scope and merit of the case and the applicant's financial resources.

"We are going to be targeting funds to where they're needed most," Stepanovich said. "We want to be able to help as many people as possible in as dire need as possible, and so we will be making decisions about amounts based on the case and the need and what the actual factual circumstances are."

Google is seeding the Security Legal Research Fund with an undisclosed amount, but the fund would be operated by the Center for Cybersecurity Policy & Law to ensure no one company has influence or receives favor over how the funds are used. Willis urged other companies to also contribute to the fund.

Omdia analyst Curtis Franklin believes the fund and counsel further validate and support independent researchers' role in finding vulnerabilities.

"Independent researchers are a necessary part of our security infrastructure right now, and I think it's good that this is being recognized and that these companies want to take the steps of having more formal legal recognition of that," Franklin says. "Our systems are now sufficiently complex that no one company can find all of the vulnerabilities that exist and all of the interactions that exist in their systems, either before or after they're released."

New Policy Group Wants to Improve Cybersecurity Disclosure, Support Researchers

The Open Source Security Foundation's SLSA v1.0 release is an important milestone in improving software supply chain security and providing organizations with the tools they need to protect their software.

The Open Source Security Foundation (OpenSSF) has released v1.0 of Supply-chain Levels for Software Artifacts (SLSA) with specific provisions for the software supply chain.

Modern application development teams regularly reuse code from other applications and pull code components and developer tools from myriad sources. Research from Snyk and the Linux Foundation last year found that 41% of organizations didn't have high confidence in open source software security. With supply chain attacks posing an ever-present and ever-evolving threat, both software development teams and security teams now recognize that open source components and frameworks need to be secured.

SLSA is a community-driven supply chain security standards project backed by major technology companies, such as Google, Intel, Microsoft, VMware, and IBM. SLSA focuses on increasing security rigor within the software development process. Developers can follow SLSA's guidelines to make their software supply chain more secure, and enterprises can use SLSA to make decisions about whether to trust a software package, according to the Open Source Security Foundation.

SLSA provides a common vocabulary to talk about software supply chain security; a way for developers to assess upstream dependencies by evaluating the trustworthiness of source code, builds, and container images used in the application; an actionable security checklist; and a way to measure compliance with the forthcoming Secure Software Development Framework (SSDF).

The SLSA v1.0 release divides SLSA’s level requirements into multiple tracks, each one measuring a particular aspect of software supply chain security. The new tracks will help users better understand and mitigate the risks associated with software supply chains and ultimately develop, demonstrate, and use more secure and reliable software, the OpenSSF says. SLSA v1.0 also provides more explicit guidance on how to verify provenance, along with making corresponding changes to the specification and provenance format.

The Build Track Levels 1-3, which roughly correspond to Levels 1-3 in earlier SLSA versions, describes levels of protection against tampering during or after software build. The Build Track requirements reflect the tasks required: producing artifacts, verifying build systems, and verifying artifacts. Future versions of the framework will build on requirements to address other aspects of the software delivery life cycle.

Build L1 indicates provenance, showing how the package was built; Build L2 indicates signed provenance, generated by a hosted build service; and Build L3 indicates the build service has been hardened.

The higher the level, the higher the confidence that a package can be traced back to its source and has not been tampered with, OpenSSF said.

Software supply chain security is a key component of the Biden administration's US National Cybersecurity Strategy, as it pushes software providers to assume greater responsibility for the security of their products. And recently, 10 government agencies from seven countries (Australia, Canada, Germany, the Netherlands, New Zealand, the United Kingdom, and the United States) released new guidelines, "Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default," to urge software developers to take necessary steps to ensure they are shipping products that are both secure by design and by default. That means removing default passwords, writing in safer programming languages, and establishing vulnerability disclosure programs for reporting flaws.

As part of securing the software supply chain, security teams should be engaging with developers to educate them about secure coding practices and tailoring security awareness training to include the risks surrounding the software development life cycle.

OpenSSF Adds Software Supply Chain Tracks to SLSA Framework

**DENVER****,** **April 20, 2023** **/PRNewswire/ --** Red Canary, a leader in managed detection and response, launched Red Canary Readiness, a new portfolio of offerings that gives teams a whole new way to train and prepare for incidents. Now any company can improve their incident response preparedness by empowering their security teams to practice and validate the skills, processes, and playbooks required to quickly respond to cyber and business continuity threats.

The initial Readiness product is Readiness Exercises, a first-of-its-kind continuous learning platform that combines training, tabletops, and atomic tests in one experience. With Readiness Exercises available today, cybersecurity professionals get on-demand content and expert training at their fingertips, making it easy for companies to skill up employees, no matter where they are.

**Enterprises must maintain a skilled and ready workforce to face today's top cybersecurity threats**

Adversaries are becoming faster and more efficient at distributing and scaling cyberattacks. Rather than infrequent and one-size-fits-all training, continuous learning is critical to keep pace with the evolving threat landscape.

Readiness scenarios are ripped from the headlines and informed by Red Canary's leading threat intelligence and adversary research from its Managed Detection and Response (MDR) solution, which conducts millions of investigations per year. This expertise is mapped to industry-standard frameworks, such as NIST and MITRE ATT&CK®, to ensure teams are practicing the most critical scenarios. Training can be self-guided or facilitated, ranging from 20 minutes to 2 hours, and prepares teams to face incidents involving business email compromise, ransomware, and other threats including Qbot and Raspberry Robin.

"We have previously invested in cybersecurity training but have had mixed results. The exercises don't always relate to the threats that matter most to us, and the lessons are infrequent and don't always stick," said Michael Strong, Chief Security Officer, GCI. "This is why we are so excited about Readiness Exercises. Now our team can continuously train and benchmark our progress, learning from the Red Canary team who respond to real-world threats daily. It gives me confidence knowing that we're better prepared for the next threat that comes our way."

"Just having an incident response plan and a set of playbooks is no longer enough. That plan and those playbooks must be put to the test regularly and refined to keep up with evolving threats," wrote Jess Burn, Sr. Analyst, Forrester in an April 2022 blog post.

Readiness Exercises foster continuous learning, which drives both employee and business success through:

*   **Continuously improving your readiness:** Benchmark current skill levels against industry standards through frequent feedback and scoring. Onboard new team members and establish a culture of consistent skill improvement.
*   **Training for real-world threats:** Continuously practice and validate team preparedness against realistic scenarios based on trending adversary groups, tools, and MITRE ATT&CK® techniques.
*   **Get training, tabletops, and atomic tests in one experience:** Bring together disparate learning tools and run them in your environment to maximize their relevance and impact.

"We're excited to announce the launch of Readiness Exercises, a comprehensive solution that combines tabletop exercises, cybersecurity training, and atomic testing into a seamless, continuous learning experience," said Brian Beyer, CEO of Red Canary. "With this innovative product, we're reinventing the way organizations approach cybersecurity training and prepare for real-world threats."

**Learn more**

*   Learn more about Readiness
*   Watch the Readiness Exercises video
*   Register for the Readiness webinar

**Availability** 

Red Canary Readiness launched today, with Red Canary Readiness Exercises generally available now.

**About Red Canary**

Red Canary is a leader in managed detection and response (MDR). We serve companies of every size and industry, focusing on finding and stopping threats before they can have a negative impact. As the security ally for nearly 1,000 organizations, we provide MDR across our customers' cloud workloads, identities, SaaS applications, networks, and endpoints. For more information about Red Canary, visit: https://www.redcanary.com.

SOURCE Red Canary

Red Canary Announces Readiness

Mandiant found that North Korea's UNC4736 gained initial access on 3CX's network when an employee downloaded a weaponized but legitimately-signed app from Trading Technologies.

Turns out 3CX was not the original target in a recent supply chain compromise affecting customers of the video conferencing software maker: The attack came via a prior supply chain compromise involving Trading Technologies, a provider of high-performance trading software.

That makes the breach at 3CX one of the first known instances where an adversary used one supply chain attack to enable a second supply chain attack in an effort to try and breach multiple organizations. However, rather than being the victims of a targeted attack, 3CX and its customers appear to have become opportunistic victims for the threat actor, new research shows.

Researchers at Google Cloud's Mandiant discovered the chained attacks after 3CX hired the security vendor to investigate a March 2023 incident where a threat actor — now identified as North Koreas Lazarus group — used legitimate updates of 3CX's DesktopApp to deliver malware to downstream customers.

Multiple security vendors at the time reported observing legitimately signed Windows and Mac versions of the 3CX app landing on customer systems bundled with malicious installers. When users attempted to deploy the poisoned software, the malicious installers executed a sequence of actions that ended with an information stealer on their systems. Kaspersky later observed Lazarus actors dropping a second-stage backdoor, tracked as "Gopuram" on systems belonging to a small number of affected 3CX users.

Security researchers surmised that the North Korean threat actor — whom Mandiant tracks as UNC4736 — would have needed extensive access to 3CX's build environment to pull off the attack. 3CX officials themselves merely noted the issue likely had to do with one of the bundled libraries compiled into the desktop app.

**Fortuitous Download for the Hackers**

Mandiant's investigation into how exactly UNC4736 might have compromised the 3CX environment showed the threat actor gained initial access when a 3CX employee downloaded a financial trading package called X\_TRADER from the website of the developer, Trading Technologies.

UNC4736 actors had previously breached Trading Technologies systems, according to Mandiant, and inserted a backdoor in the X\_TRADER app's installation file. When the 3CX user downloaded the app from the Trading Technologies website, the installer triggered actions that resulted in a modular, multi-stage backdoor called "VEILEDSIGNAL" landing on the individual's system.

The malware contained multiple functions, including those for sending implant data, executing shell code, and for terminating itself. VEILEDSIGNAL also included two other components: one for injecting the command-and-control module on Chrome, Firefox, or Edge, and the other for listening to incoming communications.

Marius Fodoreanu, principal consultant at Mandiant and the lead investigator in the 3CX compromise, says it's unclear how UNC4736/Lazarus actors introduced the malicious installer for X\_TRADER.

"Mandiant is not performing an incident response for Trading Technologies, so we don't have direct visibility into the Trading Technologies' environment," he says. But Mandiant has observed evidence of compromise of the Trading Technologies environment as far back as 2021, Fodoreanu says.

**Lazarus Used Backdoor to Steal Credentials, Compromise 3CX Build Systems**

Fodoreanu says that following the initial compromise of the 3CX employee's computer in 2022, the threat actor stole the employee's corporate credentials. The attackers then used the administrative-level access and persistence that VEILEDSIGNAL provided on the system to eventually compromise 3CX's Windows and macOS build environments and insert malware into finished 3CX software packages.

The breach at 3CX would not have happened in this instance if the employee hadn't downloaded the malicious X\_TRADER app. That means the company became a collateral and, therefore, an opportunistic victim of the North Korean group.

"If you were starting from scratch and trying to intentionally target a company like 3CX, you would not go to Trading Technologies as an initial attack vector," Fodoreanu concedes.

However, when the threat actor discovered they had snagged a high-value victim, it is likely they pressed forward more deliberately, he says.

"Yes, we believe it likely started off as \[an\] opportunistic attack," he says. "But once they figured out that they had access to a company that likely has a lot of customers, they decided to continue to move forward and compromise the environment and then compromise the software."

**3CX Not a Trading Technologies' Customer**

Interestingly, 3CX is neither a vendor nor a customer of Trading Technologies. So, it is not clear why an employee from the company would have wanted to download X\_TRADER, a spokeswoman from Trading Technologies said in an emailed statement to Dark Reading.

"Given that this only came to our attention last week, we have not had the ability to verify the assertions in Mandiant's report," the spokeswoman said. "What we do know with certainty is that 3CX is not a vendor or a customer of Trading Technologies. There is no business relationship between the two companies."

The statement went on to note that Trading Technologies discontinued the X\_TRADER app referenced in the Mandiant report in April 2020. Mandiant itself said its investigation showed, however, that the app was still available for download in 2022. "There was no reason for anyone to download the software given that TT stopped hosting, supporting, and servicing X\_TRADER after early 2020."

**Other Victims?**

Fodoreanu says there is potential that other organizations might have downloaded the poisoned X\_TRADER app during the two years it was available on Trading Technologies' website, after the company discontinued the product.

"We suspect there are a number of organizations that don't know they're compromised yet," he says. "We're hopeful that now that this information is out, it'll help accelerate the process for companies to determine that they're compromised and contain their incidents."

Meanwhile, in a separate development, security vendor Eset this week reported on a new Lazarus campaign it is currently tracking as Operation DreamJob, which it believes is linked to the 3CX attack for multiple reasons. Peter Kalnai, senior malware researcher at Eset, says the so-called "SimplexTea" Linux malware used in the DreamJob campaign shares the same C2 network infrastructure used in the 3CX attack.

The configuration of SimplexTea also bears the same name (apdl.cf) as SIMPLESEA the macOS malware reported in the 3CX attack, Kalnai says. There are also similarities in the manner in which messages are encrypted, he says.

3CX Supply Chain Attack Tied to Financial Trading App Breach

The sensitivity of the personal information involved in the breach has yet to be determined by agency officials, but it affects 256,000 consumers.

The Consumer Financial Protection Bureau (CFPB), an agency of the US government that protects consumers in the financial sector, announced that an employee committed a major breach in emailing the personal information of 256,000 consumers to a personal email account.

In briefings between lawmakers and the consumer bureau director, Rohit Chopra, the agency staff informed elected officials that they first learned of the breach on Feb. 14. Chair of the Financial Services Committee's investigation panel on the matter, Rep. Bill Huizenga, stated in a letter to Chopra that "the transfer of records could have possibly implicated more than 50 financial institutions' sensitive information" and requested a briefing before a deadline of April 25.

The employment of the individual who committed the breach has been terminated by the agency, and the person has been asked to delete the emails and provide proof of such, though the person has yet to comply with these requests.

"This unauthorized transfer of personal and confidential data is completely unacceptable. All CFPB employees are trained in their obligations under Bureau regulations and Federal law to safeguard confidential or personal information," the agency stated.

At this time, the agency has identified that the information included in the breach involves personal identifiable information (PII) of customers from seven institutions, though they are not yet sure of the degree of sensitivity of the PII and are still assessing the level of risk to the consumers involved.

"Unfortunately, this is an example of clumsy handling of sensitive data. Even if there was no ill intent by the individual concerned there are still huge risks to data privacy whether the email was encrypted, who else has access to that email account, and whether there's a strong password or MFA enabled on the personal email account," Darren James, senior product manager with Specops Software, said in an emailed statement. "The CFPB has a lesson to learn here in responsible data handling. Any training done has failed and more emphasis should be made on Cyber Aware Training in the future to prevent poor security hygiene like this instance."

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

Major US CFPB Data Breach Caused by Employee

Vulnerable MS-SQL database servers have external connections and weak account credentials, researchers warn.

The Trigona ransomware threat actors are waging a campaign against Microsoft SQL database servers because many of them have external connections and weak passwords, leaving them open targets for brute force or dictionary attacks.

These vulnerable MS-SQL servers were designated as "poorly managed" by AhnLab Security's new alert about Trigona's nefarious activities.

"If a threat actor manages to log in, control over the system will be passed to them, allowing them to install malware or execute malicious commands," the report said.

    

The Trigona ransom note. Source: AhnLabs

They're popular repeat targets too, and not just for Trigona: In one instance observed by AhnLab researchers, credentials for a breached MS-SQL server were compromised by several threat actors, leaving traces of various ransomware strains, Remcos RAT, and coinminers, the report said.Additionally, MS-SQL can be installed on both Windows SQL servers and desktop environments. 

"For example, there are cases where MS-SQL is installed alongside certain enterprise resource planning (ERP) and work-purpose solutions during their installation process," the Trigona ransomware report added. "Because of this, Windows servers and Windows desktop environments can both be targeted for MS-SQL server attacks."

AhnLab Security noted Trigona is a relatively new ransomware group, first observed last October.

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

Trigona Ransomware Trolling for 'Poorly Managed' MS-SQL Servers

Today's LLMs pose too many trust and security risks.

_The Berryville Institute of Machine Learning (BIML) recently attended_ _Calypso AI’s Accelerate AI 2023_ _conference in Washington, DC. The meeting included practitioners from both government and industry, regulators, and academics. I participated in a very timely panel entitled "Emerging Risks and Opportunities of LLMs in the NATSEC and Beyond." That panel spurred this article._

_None of the content in this column was created by an LLM._

Large language models (LLMs) are a kind of machine learning system that has taken the world by storm. ChaptGPT (aka GPT-3.5), an LLM produced and fielded by OpenAI, is one of the most pervasive and popular of the many generative AI models for text. Other generative models include the image generators Dall-E, Midjourney, and Stable Diffusion, and the code generator Copilot.

LLMs and other generative tools present incredible opportunities for applications, and the rush to field such systems is in full gallop. LLMs have the potential to be lots of fun, solve hard problems in science, help with the thorny problems of knowledge management, create interesting content, and most importantly in my view, move the world a little closer to artificial general intelligence (AGI) and a theory of representation that produces massive cognitive science breakthroughs.

But using today's nascent LLMs — and any generative AI tools — comes with real risks.

**Of Parrots and Pollution**

LLMs are trained on massive corpuses of information (300 billion words, mostly scraped from the Internet) and use auto-association to predict the next word in a sentence. As such, most scientists agree that LLMs do not really "understand" anything or do any real thinking. Rather, they are "stochastic parrots," as some researchers call them. LLMs still do generate impressive streams of text, in context, and in an often useful and deeply surprising manner.

Feedback loops are an important class of problem in all kinds of ML models (and one that BIML introduced several years ago as “\[raw:8:looping\]”). Here is what we said at the time:

_Model confounded by subtle feedback loops. If data output from the model are later used as input back into the same model, what happens? Note that this is rumored to have happened to Google translate in the early days when translations of pages made by the machine were used to train the machine itself. Hilarity ensued. To this day, Google restricts some translated search results through its own policies_.

Imagine what will happen when a majority of what can be easily scraped from the Internet is generated by AI models of dubious quality, and then these LLMs start to eat their own tails. Talk about information pollution.

Some AI researchers and information security professionals are already deeply worried about information pollution today, but an infinite spewing information pollution pipeline sounds bad.

**Mansplaining-as-a-Service**

LLMs are very good B.S. artists. These models regularly express incorrect opinions and alternative facts with great confidence, and often make up information to justify their answers in a conversation (including pretend scientific references). Imagine what happens when average knowledge as scraped from the Internet — which includes lots of wrong things — is used to create new content.

The ultimate "reply guy" is not who we need writing news stories for us in the future. Facts actually do matter.

**Mirroring Broken Security**

LLMs are often trained on data that is biased in many ways. Sexist, racist, xenophobic, and misogynistic systems can and will be modeled from data sets originally collected when society was less progressive. Bias is a serious issue in LLMs, and one that operational Band-Aids are unlikely to fix.

**Trusting Deepfakes**

Deepfakes are a side effect of generative AI that has been discussed for some time. Fakes or spoofing are always a risk in security, but the capacity to make higher-quality fakes that are easy to believe is here. There are some obvious worst-case scenarios: moving markets, causing wars, inflaming cultural divides, and so on. Careful where that video came from.

**Automating Everything**

Generative models like LLMs have the capacity to replace lots of jobs, including low-level white collar jobs. Millions of people get plenty of satisfaction out of their jobs, but what if all of those jobs are willy-nilly replaced by ML systems that are cheaper to operate? We already see this with some writing content-creation jobs in local sports stories and marketing copy, for example. Should LLMs be writing our articles? Should they be practicing law? How about doing medical diagnosis?

**Using a Tool for Evil**

Generative AI can create some fun stuff. If you haven’t played with ChapGPT, you should give it a shot. I haven’t had this much fun with new technology since I got my first Apple \]\[+ in 1981, or since Java applets came out in 1995.

But the power of generative AI can be used for evil as well. For example, what if we put ML to the task of designing a novel virus with the propagation capability of COVID and the delayed onset parameters of rabies? Or how about the task of creating a plant with pollen that is also a neurotoxin. If I can think up these dastardly things in my kitchen, what happens when a real evil person starts brainstorming with ML?

Tools have no intrinsic morality or ethics. And for the record, the idea of "protecting prompts" is a pretend solution akin to protecting supercomputer access with command-line filtering.

**Holding Information in a Broken Cup**

Data moats are a thing now. That’s because if an ML model (with the help of humans) can get to your data and learn how to profitably parrot what you do by training on your data, it will. This leads to multiple risks best solved by carefully protecting your data sets instead of cramming them unto an ML model and fielding the model to the general public. In the gold rush world of ML, the gold is data.

Protecting data is harder than it sounds. Think how the government's current information classification system can't always protect classified information. Clearly, protecting sensitive and confidential information is already a huge challenge, so imagine what happens when we intentionally train up our ML systems on confidential information and set them out into the world.

Extraction and transfer attacks exist today, so be careful what you pour in your ML cup.

**What Should We Do About LLM Risk?**

So should we put some kind of magic moratorium on ML research for a few months as some technologists have self-servingly suggested? No, that's just silly. What we need to do is recognize these risks and face them directly.

The good news is that an entire industry is being built around securing ML systems, which I call machine learning security or MLsec. Check out what these new hot startups are building to control ML risk — but do so with a skeptical and well-informed eye.

Expert Insight: Dangers of Using Large Language Models Before They Are Baked

Overcoming the limitations of consumer MFA with a new flavor of passwordless.

Twitter recently disabled SMS-based two-factor authentication (2FA) except for Twitter Blue subscribers. While the intended results may be cost-savings and boosting the number of subscribers, the decision is likely to have unintended security consequences. Even some tech-savvy people who know and care about security find Twitter's 2FA alternatives awkward enough to delay until they are forced into it, so Twitter's new policy will likely result in fewer accounts using 2FA. Educating users about how to set up authenticator apps and security keys is one solution. But that's analogous to building a faster horse.

Fundamentally, the enterprise 2FA playbook cannot be applied to consumer scenarios in equal measure because consumers can vote with their feet. Any added step will send them galloping into the arms of the competition. Thus, the Twitter news should be a call for disruption, and for solutions that protect consumer identities without introducing friction. I believe that technology is passkeys when available uniformly across the digital landscape.

**The State of Consumer MFA**

It’s broadly accepted that any multifactor authentication (MFA) is better than no MFA (I’ll use MFA here to mean authenticating your identity with two or more factors). MFA solutions prevent bad actors from accessing resources using only a victim's primary credentials. Our CISO once observed that MFA and adaptive authentication would have prevented 95% of the breaches she has seen.

But not all MFA is created equal. Some factors are weaker than others, particularly against targeted attacks. Security questions, SMS, voice, and email-based one-time passwords are considered low-assurance factors. All these factors are vulnerable to phishing. Attackers can bypass weaker factors by "guessing" the authenticator code; intercepting the code-containing SMS; or creating "alert fatigue" by bombarding the user with messages until they complete the MFA challenge.

**MFA Bypass Attacks**

Recent research found more than 113 million MFA bypass (registration required) attempts against consumer and SaaS applications over a 90-day period, representing the highest baseline level of attacks of any year on record. Given what we know about weaker factors, you'd be forgiven for thinking Twitter's decision to disable text-based authentication is a good one. But as with most things in identity, there is more complexity that meets the eye, particularly when we look at MFA adoption issues.

**The Trouble With MFA Adoption**

The challenge of getting users to sign up for any form of MFA lies in the technology's origin story. Passwords predate modern online services by thousands of years (just think about "Open, Sesame" in "Ali Baba and the 40 Thieves"). Two-factor authentication entered the picture much later as a way for enterprises and governments to protect their internal systems with something you know (password) and something you have (device, code, or security key).

Technologies developed in an enterprise context have historically prioritized security. The administrator has the power to enforce security measures across the employee base to protect the company's interests. When organizations try to use the same playbook with consumers, they fail, because consumers can vote with their feet. And the impact can quickly become existential.

So, what about authenticator apps? For us in the industry, this might look like the obvious technical alternative to SMS-based methods. But few end users are this digitally savvy. The more likely result of forcing something like an authenticator app or security key at scale is that people just won't use it.

**Phishing-Resistant Authentication**

The transition to phishing-resistant factors offers one potential solution to consumer MFA woes. FIDO and WebAuthn rely on public key cryptography and biometrics to significantly improve both security and the user experience. When using public key cryptography, there are no codes or secrets to be stolen. Users go through a biometric check on their device to unlock access to their private key, which is way faster than entering an SMS code. There are nuances in how biometric data is validated that can make a big difference for data privacy and security.

**The Passkeys Opportunity**

Despite exciting progress toward more secure and usable factors, the best MFA mechanism for consumers really isn't MFA at all — it's passkeys. Passkeys are a FIDO authenticator with the advantage of being backed up to the cloud, so if you lose your device or buy a new one, all you must do is sign into your iCloud or Google Play account to recover your passkeys. Passkeys use public key cryptography and device biometrics, making them resistant to many known attacks, and are easy for the user.

Should passkeys have been used on Twitter? Absolutely, but they may not have been a clear option at the time. Supporting something new is always expensive from the engineering perspective. If passkeys had been an option, the experience for the user might have looked something like this:

1.  The user signs into Twitter on their mobile device with username and password;
2.  They are asked if they would like to use a passkey to authenticate next time; and
3.  The user receives a biometric prompt from then on without needing to install anything. They can even go to their Mac and open Twitter in Safari, and the passkey will be automatically synced to that device.

Offering passkey authentication currently requires some reworking, but it's easier and more cost-effective than SMS. Unfortunately, passkeys are not yet uniformly distributed. Apple added support early on, followed by Android and Chrome. Windows currently supports passkeys on a single device.

Whenever you're asking people to change, you need to take concrete steps to make the transition easier. In the case of Twitter, that would be explaining to users what they can do to change their second factor, to avoid them dropping MFA entirely. This would be an amazing passkey adoption opportunity if the industry were ready. We're already in a fantastic position to encourage people to use this flavor of passwordless. What comes next is making it easier for developers to implement the necessary changes in their apps and websites. A future with fewer passwords may not be so far away after all.

Source

DARKReading