Only one in 10 enterprises will create a robust zero-trust foundation in the next three years, while more than half of attacks won't even be prevented by it, according to Gartner.

The zero-trust approach to security promises to reduce threats and make successful attacks less damaging, but companies should not expect that implementing zero-trust principles will be easy or prevent most attacks, business intelligence firm Gartner said this week.

While interest in zero-trust architectures is high, only about 1% of organizations currently have a mature program that meets the definition of zero trust. The firm also estimates that only a 10th of all organizations will create a mature zero-trust framework by 2026, and by that time, those measures will end up only blocking or minimizing the impact of about half of all attacks. 

Even so, moving from 1% to 10% is significant progress, says John Watts, vice president analyst at Gartner.

"That's a relatively large increase," he says. "\[Ten percent\] may seem low, but at the same time, right now, when we talk to clients, and we look at other industry data points, it doesn't seem like there are many large organizations you can point to that have a mature and measurable zero-trust program."

Zero-trust initiatives continue to be an aspirational goal for companies and their cybersecurity teams, with 80% of executives indicating that the strategy is a top priority and 77% increasing their budget for implementation, according to a 2022 survey published by the Cloud Security Alliance in June. A separate report published by Microsoft in 2021 found that 96% of security leaders considered zero trust critical to their success — and 76% were "in the process" of implementing a zero-trust initiative.

**Turning Zero Trust Into Action**

As companies mull their paths forward, they should recognize that getting to a comprehensive zero-trust architecture is not easy and will take time, says Christopher Hallenbeck, CISO for the Americas at Tanium, a provider of converged endpoint management.

"The process of migrating to zero trust can seem overwhelming, and it often causes paralysis," he says. "I’m surprised the \[forecasted\] number is as high as 10%. While many organizations have zero-trust aspirations, few have made holistic changes to fully embrace it."

It can also be confusing, given the widespread use of "zero trust" in the marketing of cybersecurity products and services. 

In a prior Insights report, Gartner pushed back against the overzealous use of the term. Neil MacDonald, a distinguished vice president and analyst at the firm, said that zero trust requires that the degree of trust granted to users and devices need be explicitly granted, continuously calculated, and then adapted to allow the right amount of access only for as long as necessary.

"Zero trust is a way of thinking, not a specific technology or architecture," he said. "It's really about zero implicit trust, as that's what we want to get rid of."

While the notion of removing implicit trust from enterprise computing infrastructure is a good one, the architecture is difficult and time-consuming to implement and does not solve all problems, the analyst firm stated as part of this week's post.

As such, organizations need to move to integrating zero-trust initiatives into specific pieces of their operations, Hallenbeck notes.

"You need to configure each system to bring it under zero trust and should prioritize those systems holding the most sensitive information," he says. "It all comes down to knowing what you have in order to form a plan."

**Know the Limits of Zero Trust**

Indeed, knowing the scope and limits of zero trust is critical, Gartner's Watts says. The architecture and technologies used in zero-trust implementations are good for blocking lateral movement and containing the impact of an initial breach. However, companies should not expect a zero-trust service to prevent compromises of consumer-facing systems.

Anything that's intended for consumer consumption and exposed to the Internet, where anybody can find and try to use the service, is not a candidate for zero trust and not in scope for a company's initiatives, Watts says. Attackers are already starting to bypass some identity and authentication techniques, such as last year's compromise of Rockstar Games through spear-phishing and an internal collaboration platform. They will continued to find entry points that are not controlled by zero-trust protections, or they will focus on the weakness of zero trust, he says.

The firm, in fact, predicts that by 2026, zero trust will not be able to prevent more than half of all cyberattacks.

Still, adopting zero-trust frameworks will eventually pay off, Tanium's Hallenbeck says. A company with a mature zero-trust program knows "what systems \[they\] have and where data lives," he says. In that way, even if an attacker bypasses a zero-trust protection, the organization can limit the damage by limiting the attacker's access to internal systems and data.

"We're just starting to move past this phase, from where every vendor tells you they can solve all your zero-trust problems, and into the space where organizations now are implementing more zero-trust controls," Watts says. "They're facing a reality of both good and bad, right? And it's not all good, and it's not all bad."

Companies Struggle With Zero Trust as Attackers Adapt to Get Around It

Red Hat Security Advisory 2023-0408-01 - OpenShift Virtualization is Red Hat's virtualization solution designed for Red Hat OpenShift Container Platform. Issues addressed include denial of service and out of bounds read vulnerabilities.

Red Hat Security Advisory 2023-0408-01

Red Hat Security Advisory 2023-0275-01 - OpenStack Networking is a virtual network service for OpenStack. Just as OpenStack Compute provides an API to dynamically request and configure virtual servers, OpenStack Networking provides an API to dynamically request and configure virtual networks. These networks connect 'interfaces' from other OpenStack services. The OpenStack Networking API supports extensions to provide advanced network capabilities.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

====================================================================                     
Red Hat Security Advisory

Synopsis:          Moderate: Red Hat OpenStack Platform 17.0 (openstack-neutron) security update  
Advisory ID:       RHSA-2023:0275-01  
Product:           Red Hat OpenStack Platform  
Advisory URL:      https://access.redhat.com/errata/RHSA-2023:0275  
Issue date:        2023-01-25  
CVE Names:         CVE-2022-3277  
====================================================================  
1. Summary:

An update for openstack-neutron is now available for Red Hat OpenStack  
Platform 17.0 (Wallaby).

Red Hat Product Security has rated this update as having a security impact  
of Moderate. A Common Vulnerability Scoring System (CVSS) base score, which  
gives a detailed severity rating, is available for each vulnerability from  
the CVE link(s) in the References section.

2. Relevant releases/architectures:

Red Hat OpenStack Platform 17.0 - noarch

3. Description:

OpenStack Networking (neutron) is a virtual network service for OpenStack.  
Just as OpenStack Compute (nova) provides an API to dynamically request and  
configure virtual servers, OpenStack Networking provides an API to  
dynamically request and configure virtual networks. These networks connect  
'interfaces' from other OpenStack services (e.g. virtual NICs from Compute  
VMs).  The OpenStack Networking API supports extensions to provide advanced  
network capabilities (e.g. QoS, ACLs, network monitoring, etc.)

Security Fix(es):

* unrestricted creation of security groups (CVE-2022-3277)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page listed in the References section.

4. Solution:

For details on how to apply this update, which includes the changes  
described in this advisory, refer to:

https://access.redhat.com/articles/11258

5. Bugs fixed (https://bugzilla.redhat.com/):

2119137 - [ovn] two subnets with the same cidr can be connected to one router  
2120409 - [RHOS-17] Parent port remains DOWN after live migration with trunk port and OVN  
2121098 - [PerfCI][OVN RAFT][17.0] BrowbeatPlugin.router_subnet_create_delete fails randomly with 504 Gateway Time-out  
2122128 - neutron revision_number does not bump on network update  
2125061 - [OVN][DVR][VLAN] some FIP's are unreachable  
2125159 - Neutron Designate DNS integration ? use case #3 ?Ports are published directly in the external DNS service? fails  
2127230 - Neutron server doesn't start  
2128923 - TRY_AGAIN messages can flood neutron logs  
2129193 - CVE-2022-3277 openstack-neutron: unrestricted creation of security groups  
2132152 - Neutron server may hang during startup  
2132228 - [OVS][DVR] Tobiko test DvrRouterNamespaceTest  
2132405 - [rhos 17.0] OVN transaction could not be completed due to a race condition  
2144564 - After a minor update, connectiviy issues between a new instance and metadata.

6. Package List:

Red Hat OpenStack Platform 17.0:

Source:  
openstack-neutron-18.4.1-0.20221128170741.5258354.el9ost.src.rpm

noarch:  
openstack-neutron-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
openstack-neutron-common-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
openstack-neutron-linuxbridge-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
openstack-neutron-macvtap-agent-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
openstack-neutron-metering-agent-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
openstack-neutron-ml2-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
openstack-neutron-openvswitch-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
openstack-neutron-ovn-metadata-agent-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
openstack-neutron-ovn-migration-tool-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
openstack-neutron-rpc-server-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
openstack-neutron-sriov-nic-agent-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm  
python3-neutron-18.4.1-0.20221128170741.5258354.el9ost.noarch.rpm

These packages are GPG signed by Red Hat for security.  Our key and  
details on how to verify the signature are available from  
https://access.redhat.com/security/team/key/

7. References:

https://access.redhat.com/security/cve/CVE-2022-3277  
https://access.redhat.com/security/updates/classification/#moderate

8. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2023 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBY9FaMNzjgjWX9erEAQhm+w//etROTusye3RCqUbTq6oZWbTr7k5BmNgI  
V/iawT+2yQecJ9noQnyU3vzj/dd9BLqYVueVNyDrn11UzjelWh8G3FOeItXzosMz  
30QjbHM3ioPQdgFcWvAQfWcmla8WZkpMkztDmg6AxSEfurBzioA2yXs7vg15ILg2  
BSU6E3VZVz9M66bRm3mkoP68gO23nnjpZKy3MSrCYmirB7F/WzckrNVcZxWEyN9J  
SEQKX34U5C7OJZQbWXn6MlbmwJphDwLsr2OJ8vGtNxLfebCB6ggmBzPoIhCgw2WX  
2ocqR2hNLxnNV8saOrl30qgRJpU8ZJdpsBovDEPijQiloau8MDYWzDn7FMG2xoan  
QXrilenPQs1L2GTxalf+i1LPSfpaTvUMymxXwP9gIcBenoDgNCF0r9t6MuBqeKQG  
4DZhhK7IpP9QlKZcHP5viwnBa4ToaX67HPZaPbDTrNOX3YjAReQMFnieK7e2CT2j  
Z0xrbJt4JiTnXo0htX4ufu0VAr6zWGksKt0mfXQGJQ4cqRNpL49PmOLimFhehlB5  
xhMbnY9Tcm1LrGqnraliu1Ao0a7SFReYIcK++OsWqTilAJNB8B6vIlAkNTQFL/oM  
5HWUxEw67rTDAT11Kd/ji+zcBCcTK4kqVFj9XvPvsURBKL8zOlltteX8AXJiMZPp  
m6Ev0FOghtA=wfuZ  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2023-0275-01

Your smartphone or wearable could help you out in a truly dangerous situation. Here are some options to consider.

The Best Personal Safety Devices, Apps, and Alarms (2023)

Categories: Business
In this article, we’ll arm you with five facts about Vice Society so you can get the upper-hand against this persistent education sector threat.



(Read more...)




The post 5 facts about Vice Society, the ransomware group wreaking havoc on the education sector appeared first on Malwarebytes Labs.

Move over Lockbit, there's a new ransomware-as-a-service (RaaS) player in town attacking the education sector—and its name is Vice Society.

Vice Society is believed to be a Russian-based intrusion, exfiltration, and extortion group. And their ideal prey? You guessed it: universities, colleges, and K-12 schools. The Federal Bureau of Investigation (FBI) has even released a joint Cybersecurity Advisory (CSA) after observing that Vice Society has disproportionately targeted the education sector. 

But with knowledge comes power. The more the education sector knows about Vice Society, the better prepared they get to defend against them. 

In this article, we’ll arm you with five facts about Vice Society so you can get the upper-hand against this persistent threat.

**1\. In 2022 they were far and away the biggest attackers on the education sector**

If you’re a regular reader of our monthly ransomware review, you know that the education sector has gotten plenty of attention from ransomware gangs in the last year, to say the least.

It wasn't until Vice Society, however, that we saw a gang taking their love for the sector to a whole new level. 

Like many other ransomware gangs, Vice Society is known to steal information from victims' networks before encryption for the purposes of double extortion—threatening to publish the data on the dark web unless you pay up the ransom they demand.

A few of the institutions published on their leak site last year include De Montfort School, Cincinnati State, and one that made national headlines in September: Los Angeles Unified, the second largest school district in the US.

_Around 40% of the victims shared on the Vice Society leak site are educational institutions, a large proportion compared to other gangs._

**2\. And they have shown no signs of slowing down in 2023**

As of January 2023, Vice Society has already published the data of six schools on their leak site. That’s more than any other RaaS gang so far this year.

_The Vice Society leak site_

**3\. They leverage living off the land techniques to sneak past detection**

Living off the land (LOTL) attacks are when threat actors use legitimate tools for malicious purposes, which effectively allows them to hide in plain sight as they carry out their attack.

Vice Society actors leverage one such legitimate tool, Windows Management Instrumentation (WMI), as a means of living off the land to execute malicious commands. WMI allows administrators to manage and monitor various aspects of a computer, such as hardware and software, from a remote location.

See where we’re going with this?

Vice Society and other adversaries can use WMI to gain access to a system and then execute malicious code, install malware, or steal sensitive information.

That means you won’t be able to detect them using traditional signature-based detection mechanisms—hash values, IOCs and signatures do not detect living off the land attacks. Instead, you’ll need to turn to an Endpoint Protection Platform (EPP) that uses a combination of machine learning, behavioral analysis, and sandboxing.

**4\. We know how they get initial access to networks**

So we know what Vice Society is doing once they’re in school networks and how to detect it. But how can we stop them from entering in the first place?

Using a combination of data from Unit 42 and the Cybersecurity Advisory (CSA) posted on CISA.org, we can paint a pretty good picture of how Vice Society is getting initial access to their targets.

Vice Society is not reinventing the wheel: these threat actors are using familiar techniques such as phishing, compromised credentials, and exploits to establish a foothold in victim networks.

_Three ways Vice Society is known to get initial access (with MITRE IDs)_

Our advice is as old as time, but always worth reiterating:

*   **Address phishing** with employee training, web-based protection, and DNS filtering
*   **Address compromised accounts** by removing dormant accounts, enforcing the principle of least privilege, and having strict password policies.
*   **Address exploits** by maintaining regular vulnerability assessment and patching, preferably using an automated tool.

**5\. It seems like they’re open to negotiating their initial ransoms**

First things first, the FBI recommends never paying the ransom to attackers.

There’s a good argument for not paying too: doing so encourages more attacks and there’s no guarantee you’ll get your data back either way. There is no honor among thieves, after all.

But sometimes not paying is easier said than done. Paying the ransom might be the only option left for some organizations for various reasons.

_A Vice Society ransom note._

We know that Vice Society isn’t the most aggressive gang when it comes to their ransom demands. The difference between their initial demands and final demands could be as large as 60% after negotiations take place.

**Getting the upper-hand against RaaS gangs**

Vice Society is currently the most severe RaaS threat to the education sector. Still, to say ransomware attacks on schools is a Vice Society problem purely is missing the forest for the trees.

We don’t want to say launching ransomware on K-12 schools, colleges, and universities is as easy as taking candy from a baby, but unfortunately that’s how many RaaS gangs see it. The reality is that tight budgets of many educational institutions force them to struggle with outdated equipment and limited staff, making them an easy target for cybercriminals. 

We recommend the education sector follow a few best practices to prevent (and recover) from ransomware attacks from every angle. That includes: 

*   **Make an emergency plan** sooner, rather than later.
*   **Endpoint Protection** that uses a layered approach with multi-vector detection and prevention techniques to stop ransomware early-on.
*   **Ransomware rollback options** that should store changes to data files on the system in a local cache for 72 hours (no ransomware actually exceeds 24 hours), which can be used to help revert changes caused by ransomware.

In our Ransomware Emergency Kit, you'll find more tips your educational organization needs to defend against RaaS gangs. 

Get the Ransomware Emergency Kit

5 facts about Vice Society, the ransomware group wreaking havoc on the education sector

Two common attacks against on-premises Kerberos authentication servers — known as Pass the Ticket and Silver Ticket — can be used against Microsoft's Azure AD Kerberos, a security firms says.

Microsoft's Azure AD Kerberos service, a cloud-based identity and access management (IAM) service based on Kerberos authentication, can be attacked using techniques similar to those used by attackers against on-premises Kerberos servers.

Kerberos is a widely used protocol used to authenticate users and devices via symmetric key cryptography and a key distribution center; it enables modern authentication mechanisms such as single sign-on (SSO). Because Kerberos authentication is a standard security measure for many enterprises, attackers have frequently tried to compromise or bypass the authentication servers using identity attacks that spoof legitimate users.

In the on-premises world, a pair of common identity attacks are the Pass the Ticket and Silver Ticket approaches, which allow an attacker to use stolen credentials or mint their own credentials, respectively, and authenticate with enterprise services. Both techniques continue to work to some degree against the cloud versions of Kerberos authentication servers, according to cybersecurity services firm Silverfort, which dubbed the cloud-based iterations of the attacks the Bounce the Ticket and Silver Iodide threats.

"Identity attacks that have existed for some time are still a risk as organizations move into the cloud," says Dor Segal, senior security researcher at the firm. "Azure AD Kerberos is a new implementation but not a new protocol. Security teams need to be aware of this fact and put appropriate mitigations in place."

The fact that variants of the two attacks still work in the cloud show that moving security infrastructure to the cloud has little impact on the threat, Segal says.

"The issues outlined could impact anyone using the new Azure AD Kerberos protocol," he says. "While Azure AD Kerberos is still in initial stages of adoption, as with anything released by Microsoft, the scale of usage will increase. In the past, this type of lateral movement was an issue affecting the on-premises enterprise network. These \[new\] attacks break this perimeter."

Microsoft added Kerberos functionality to its Azure Active Directory service last August, and attackers are sure to follow, Silverfort argued in a research report issued Jan. 25. After all, IAM systems have become linchpins for many companies' zero-trust security efforts, with Microsoft Active Directory, for example, a target of attacks in nine out of 10 incidents. In addition, Kerberos is a frequent target of attackers, who often go after "tickets" — i.e., encrypted authentication credentials or tokens, used by the Kerberos protocol as proof that a client or device has authenticated to the server. 

A successful attempt to duplicate a ticket gains attackers access to protected resources for a limited time, generally on the order of hours, allowing them to move around a corporate network or use SSO services like email that might be protected by the Kerberos credential.

**Bouncing & Silver Tickets**

In the first attack, dubbed a Bounce the Ticket attack, an attacker who has compromised one user's system and who steals a Kerberos ticket from the machine's memory can then then use the secret key to gain access to cloud workloads. This attack bears similarities to the on-premises Pass the Ticket attack on Kerberos authentication services and gives the attack the ability to "access cloud-based resources that rely on Azure AD Kerberos," according to Silverfort's research.   

    

The Bounce the Ticket attack flow. Source: Silverfort

In the second attack, dubbed a Silver Iodide attack, an attacker who gains access to one user's Azure AD account can connect to a specific service — in the example given by Silverfort, the Azure Files cloud sharing service — after finding a "security gap" in the service. The security weakness, which Silverfort did not describe, can be used to create a new server ticket to access or manipulate information. The technique, which resembles the Silver Ticket attack against on-premises Kerberos servers, could be used against other cloud services as well, as long as attackers can find ways around specific controls, Silverfort stated. 

**No Fix Ahead**

Overall, the two issues represent ways an attacker — who has compromised either a system on the network or an Azure AD account — could recover Kerberos tickets and reuse those secrets to extend access to other infrastructure. 

Silverfort disclosed the issues to Microsoft, and while the company is aware of the weaknesses, it does not plan to fix them, because they are not "traditional" vulnerabilities, Segal says. Microsoft also confirmed that the company does not consider them vulnerabilities. 

"This technique is not a vulnerability, and to be used successfully a potential attacker would need elevated or administrative rights that grant access to the storage account data," a Microsoft spokesperson tells Dark Reading. "We recommend customers regularly review their role definitions that include 'listkeys' permissions, and enable software that prevents attackers from stealing credentials, such as Credential Guard."  

Silverfort's Segal acknowledges that to fix the issues, the Kerberos protocol would have to be redesigned, and that is unlikely.

"Fixing a weakness in any implementation of Kerberos is not as straightforward as patching a traditional software vulnerability because it would require re-engineering the entire protocol," he says. "This would be a significant undertaking which would take a large amount of resource and impact the compatibility of legacy applications using Kerberos."

Companies can make it harder to exploit any security weakness in their cloud-based Kerberos infrastructure, however. Organizations should review any changes to the Azure Access Control service and monitor updates to the permissions. Reducing the number of systems authorized to hold some of the more critical cloud-based credentials — such as the Ticket-Granting Ticket (TGT) — will harden an enterprise's infrastructure to Bounce the Ticket attacks, Silverfort stated in its report.

Microsoft Azure-Based Kerberos Attacks Crack Open Cloud Accounts

Encrypted backups for several GoTo remote work tools were exfiltrated from LastPass, along with encryption keys.

The GoTo remote work tool software platform has confirmed that encrypted backups for several of its tools, including Central, Pro, join.me, Hamachi, and RemotelyAnywhere, were exfiltrated, along with some encryption keys, in last November's compromise of the LastPass cloud-based password keeper.

The compromised GoTo data could include usernames, salted and hashed passwords, some multifactor authentication (MFA) settings, product settings, and licensing information, according to the company's recent disclosure.

Impacted customers will be contacted by GoTo directly, and all affected users will have their passwords and MFA settings reset, according to a post from GoTo CEO Paddy Srinivasan, which included details on the breach.

"In addition, we are migrating their accounts onto an enhanced identity management platform, which will provide additional security with more robust authentication and login-based security options," Srinivasan added.

Last December, LastPass confirmed the theft of customer data — a follow-on cyberattack from the previous August, when the LastPass source code was stolen.

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

GoTo Encrypted Backups Stolen in LastPass Breach

Don't make perfect the enemy of good in vulnerability management. Context is key — prioritize vulnerabilities that are actually exploitable. Act quickly if the vulnerability is on a potential attack path to a critical asset.

The widespread vulnerability that first appeared in Apache Log4j in 2021 will continue to be exploited, potentially even in worse ways than we've seen to date. The more worrisome aspect of these threats is that there's a good chance they'll continue to be exploited months or years into the future.

The Department of Homeland Security's Cyber Safety Review board debuted in 2021, and in 2022 released its inaugural safety report (PDF). In it, the board called Log4j an "endemic vulnerability," chiefly because there isn't a comprehensive "customer list" for Log4j, making keeping up with vulnerabilities a near-impossible task. One federal Cabinet department even spent 33,000 hours on its Log4j response.

And many organizations and security solutions on the market fail to identify the difference between exploitability and vulnerability — leaving an opportunity for attackers to carry out malicious activity.

**Exploitability vs. Vulnerability**

One of the key issues with cybersecurity today is understanding the difference between vulnerabilities and their severity. When it comes to measuring exploitability versus a vulnerability, there's a big difference between whether a security threat is exploitable within your business or if it's just "vulnerable" and cannot hinder the business or reach a critical asset. Security teams spend too much time not understanding the difference between the two and fix each vulnerability as it comes, instead of prioritizing those that are exploitable.

Every company has thousands of common vulnerabilities and exposures (CVEs), many of which score high on the Common Vulnerability Scoring System (CVSS), so it's impossible to fix them all. To combat this, the hope is that risk-based vulnerability management (RBVM) tools will make prioritization easier by clarifying what is exploitable.

However, security prioritization approaches that combine CVSS scores with RBVM threat intel don't provide optimal results. Even after filtering and looking just at what is exploitable in the wild, security teams still have too much to handle because the list is long and unmanageable. And just because a CVE doesn't have an exploit today doesn't mean that it won't have one next week.

In response, companies have been adding predictive risk AI, which can help users understand if a CVE might be exploited in the future. This still isn't enough and leads to too many issues to fix. Thousands of vulnerabilities will still show to have an exploit, but many will have other sets of conditions that have to be met to actually exploit the problem.

For example, with Log4j, the following parameters need to be identified:

*   Does the vulnerable Log4j library exist?
*   Is it loaded by a running Java application?
*   Is the JNDI lookup enabled?
*   Is Java listening to remote connections, and is there a connection for other machines?

If the conditions and parameters aren't met, the vulnerability isn't critical and shouldn't be prioritized. And even if a vulnerability could be exploitable on a machine, so what? Is that machine extremely critical, or maybe it isn't connected to any critical or sensitive assets?

It's also possible the machine isn't important yet it can enable an attacker to continue toward critical assets in stealthier ways. In other words, context is key — is this vulnerability on a potential attack path to the critical asset? Is it enough to cut off a vulnerability at a chokepoint (an intersection of multiple attack paths) to stop the attack path from reaching a critical asset?

Security teams hate vulnerability processes and their solutions, because there are more and more vulnerabilities — nobody can ever fully wipe the slate clean. But if they can focus on what can create _damage_ to a critical asset, they can have a better understanding of where to start.

**Combating Log4j Vulnerabilities**

The good news is that proper vulnerability management can help reduce and fix the exposure to Log4j-centric attacks by identifying where the risk of potential exploitation exists.

Vulnerability management is an important aspect of cybersecurity and is necessary for ensuring the security and integrity of systems and data. However, it's not a perfect process and vulnerabilities can still be present in systems despite best efforts to identify and mitigate them. It's important to regularly review and update vulnerability management processes and strategies to ensure that they are effective and that vulnerabilities are being addressed in a timely manner.

The focus of vulnerability management should not only be on the vulnerabilities themselves, but also on the potential risk of exploitation. It is important to identify the points where an attacker may have gained access to the network, as well as the paths they may take to compromise critical assets. The most efficient and cost-effective way to mitigate the risks of a particular vulnerability is to identify the connections between vulnerabilities, misconfigurations, and user behavior that could be exploited by an attacker, and to proactively address these issues before the vulnerability is exploited. This can help to disrupt the attack and prevent damage to the system.

You should also do the following:

*   **Patch:** Identify all your products that are vulnerable to Log4j. This can be done manually or by using open source scanners. If a relevant patch is released for one of your vulnerable products, patch the system ASAP.
*   **Workaround:** On Log4j versions 2.10.0 and above, in the Java CMD line, set the following: log4j2.formatMsgNoLookups=true
*   **Block:** If possible, add a rule to your Web application firewall to block: "jndi:"

Perfect security is an unachievable feat, so there's no sense making perfect the enemy of good. Instead, focus on prioritizing and locking down potential attack paths that continuously improve security posture. Identifying and being realistic about what actually is vulnerable versus what is exploitable can help do this, since it will allow the ability to strategically funnel resources toward critical areas that matter the most.

Log4j Vulnerabilities Are Here to Stay — Are You Prepared?

The DPRK has turned crypto scams into big business to replenish its depleted state coffers.

The blockchain industry hemorrhaged money last year, with the global market for cryptocurrencies plummeting 63%. But investors didn't only lose money to half-baked coins and overhyped NFTs.

In a report published today, researchers from Proofpoint detailed how North Korean state-backed hackers managed to siphon more than $1 billion dollars in cryptocurrencies and other blockchain assets in the 2022 calendar year (all the more impressive considering how depressed those assets had become).

Proofpoint attributed the success of the TA444 group and related clusters — variously referred to as APT38, Bluenoroff, BlackAlicanto, Stardust Chollima, and Copernicium — to their startup-like approach.

Hallmarks, the researchers said, include "rapid iteration, testing products on the fly, and failing forward." The group regularly experiments with new methods of intrusion, and has cycled through different and better malware in recent years.

"While we do not know if the group has ping-pong tables or kegs of some overrated IPA in its workspace," the authors wrote, "TA444 does mirror the startup culture in its devotion to the dollar and to the grind."

**TA444's Evolving Threat**

There's an element of "move fast and break things" to TA444.

In recent years, the group has iterated on their social engineering tactics many times over. Sometimes it sent private messages from hijacked LinkedIn accounts of representatives from legitimate companies, other times it abused email marketing tools in order to circumvent spam filters. It has engaged with victims in English, but also Japanese, Polish, and Spanish.

In one oddball case, it email-blasted organizations across the US healthcare, education, finance, and government sectors, using barebones, typo-laden phishing lures. At best, their lures made reference to specific brand names in the industry, sometimes promising salary increases or job opportunities, but the efforts here were mainly rudimentary.

Where other cybercrime groups may focus on perfecting social lures and delivery mechanisms, researchers explained that malware creation is where TA444 really distinguishes itself.

Their collection of post-exploitation backdoors has included the msoRAT credential stealer, the SWIFT money laundering framework DYEPACK, and various passive backdoors and virtual "listeners" for receiving and processing data from target machines.

"This suggests that there is an embedded, or at least a devoted, malware development element alongside TA444 operators," according to the report.

**North Korea: The OG Crypto Bro**

To supplement its maladroit command economy, the government of North Korea has long used hackers for fundraising, targeting wherever a financial opportunity happens to lie. That includes everything from retailers in the United States to the SWIFT banking system, and, in one notorious case, the entire world.

Because cryptocurrency companies offer few safeguards against theft, transactions are generally irreversible, and parties to those transactions are difficult to identify, the industry is rife with financially motivated cybercrime. North Korea has been dipping into this well for years, with campaigns against startups, botnets that mine coins, and ransomware campaigns soliciting crypto payments.

Last year, though, the scale of the theft reached a new level. Blockchain research firm Chainalysis assessed that the country stole nearly $400 million dollars in cryptocurrency and blockchain assets in 2021. In 2022, they surpassed that figure with a single attack — against a blockchain gaming company called SkyMavis — estimated to be worth over $600 million at the time. Add in other attacks throughout the calendar year, and their total haul reaches 10 figures.

"While we may poke fun at its broad campaigns and ease of clustering," the researchers warned, "TA444 is an astute and capable adversary."

Proofpoint's report noted that monitoring for MSHTA, VBS, Powershell, and other scripting-language execution from new processes or files can help detect TA444 activity. It also recommended using best practices for a defense-in-depth approach to combat TA444 intrusions: Using network security monitoring tools, using robust logging practices, a good endpoint solution, and an email monitoring appliance, in addition to training the workforce to be aware of heist activity that stems from contact on WhatsApp or LinkedIn. 

"Additionally, given the credential phishing campaign activity we observed, enabling MFA authentication on all externally accessible service would help limit the impact of credentials eventually getting stolen," the researchers said via email.

North Korea's Top APT Swindled $1B From Crypto Investors in 2022

By Deeba Ahmed
GoTo-owned LastPass revealed that hackers stole customers' encrypted data in a November 2022 data breach.
This is a post from HackRead.com Read the original post: GoTo’s LastPass Breach: Encrypted Customer Data Taken

The data breach of the LastPass password manager keeps haunting its parent company, GoTo, and its customers.

Software and remote collaboration firm GoTo, which owns LastPass, has confirmed that during the security breach that occurred in November 2022, hackers stole some customers’ encrypted data and LastPass password vaults.

**Detailed Analysis**

LastPass, LastPass, previously called LogMeIn, has shared new findings about the security breach that hit the company on November 30, 2022. GoTo has previously confirmed that unusual activity was noticed in its cloud storage service and development environment.

It now claims that some of its enterprise products may be impacted by the hack. This includes exposure of encrypted customer backups, which are emergency recovery data copies, for Central, Pro, join.me, Hamachi, and RemotelyAnywhere.

Moreover, GoTo stated that this was possible because an encryption key used to secure the data for some customers was stolen in the November 2022 data breach.

**How Did The Breach Occur?**

The November data breach was directly caused by another breach in August, wherein an unauthorized entity gained access to customer data stored on a third-party cloud storage service shared by GoTo and LastPass.

Using the information stolen in August, attackers accessed another LastPass database in November and captured customer data. In that breach, GoTo had become the victim of a security breach in which unknown cybercriminals targeted their shared cloud-storage service.

**Stolen Data Details**

Earlier, the company stated that stolen data included names, billing addresses, emails, IP addresses, and phone numbers and that unencrypted credit card data wasn’t accessed.

However, now it revealed that the encrypted data of customers was exposed and product-related data including account usernames, a portion of MFA (multi-factor authentication) settings, salted/hashed passwords, and some product settings and licensing data was exposed.

According to Paddy Srinivasan, GoTo’s CEO, Rescue and GoToMyPC’s encrypted databases weren’t compromised and only a small subset of their customers’ MFA settings was impacted.

Moreover, Srinivasan claims in their blog post that there’s no evidence that any other GoTo products were impacted by the theft. GoTo didn’t reveal how many customers were affected, but the company is notifying impacted customers.

**_MORE LASTPASS HACKING NEWS_**

1.  LastPass hacked; security compromised for good
2.  “Unique” Vulnerability Found in LastPass Manager
3.  Error prompted LastPass to send false breach alerts

Tag

#mac