Cryptocurrency investment companies are the target of a developing threat cluster that uses Telegram groups to seek out potential victims.
Microsoft's Security Threat Intelligence Center (MSTIC) is tracking the activity under the name DEV-0139, and builds upon a recent report from Volexity that attributed the same set of attacks to North Korea's Lazarus Group.
"DEV-0139 joined Telegram groups

Cryptocurrency / Threat Intelligence

Cryptocurrency investment companies are the target of a developing threat cluster that uses Telegram groups to seek out potential victims.

Microsoft's Security Threat Intelligence Center (MSTIC) is tracking the activity under the name **DEV-0139**, and builds upon a recent report from Volexity that attributed the same set of attacks to North Korea's Lazarus Group.

"DEV-0139 joined Telegram groups used to facilitate communication between VIP clients and cryptocurrency exchange platforms and identified their target from among the members," the tech giant said.

The adversary subsequently impersonated another cryptocurrency investment company and invited the victim to join a different Telegram chat group under the pretext of asking for feedback on the trading fee structure used by exchange platforms across VIP tiers.

It's worth pointing out that the VIP program is designed to reward high-volume traders with exclusive trading fee incentives and discounts based on the 30-day trading volume.

This attack chain notably dovetails with Volexity's analysis of an October 2022 campaign, wherein the threat actor pivoted from using MSI installer files to a weaponized Microsoft Excel document displaying the supposed cryptocurrency coin rates.

Microsoft described the document as containing likely accurate data to increase the likelihood of success of the campaign, suggesting that DEV-0139 is well versed in the inner workings of the crypto industry.

The malware-laced Excel file, for its part, is tasked with executing a malicious macro that's used to stealthily drop and execute a second Excel worksheet, which, in turn, includes a macro that downloads a PNG image file hosted on OpenDrive.

This image file contains three executables, each of which is used to launch the next-stage payload, ultimately paving the way for a backdoor that lets the threat actor remotely access the infected system.

Furthermore, the fee structure spreadsheet is password-protected in a bid to convince the target into enabling macros, thereby initiating malicious actions. A metadata analysis of the file shows that it was created on October 14, 2022 by a user named Wolf.

DEV-0139 has also been linked to an alternative attack sequence in which an MSI package for a fake application named "CryptoDashboardV2" is delivered in place of a malicious Excel document to deploy the same implant.

The backdoor mainly enables remote access to the host by gathering information from the targeted system and connecting to a command-and-control (C2) server to receive additional commands.

"The cryptocurrency market remains a field of interest for threat actors," Microsoft said. "Targeted users are identified through trusted channels to increase the chance of success."

In recent years, Telegram has not only witnessed widespread adoption in the cryptocurrency industry, but also been co-opted by threat actors looking to discuss zero-day vulnerabilities, offer stolen data, and market their services through the popular messaging platform.

"With users losing confidence in the anonymity offered by forums, illicit marketplaces are increasingly turning to Telegram," Positive Technologies disclosed in a new study of 323 public Telegram channels and groups with over one million subscribers in total.

"The number of unique cyberattacks is constantly growing, and the market for cybercriminal services is expanding and moving into ordinary social media and messaging apps, thereby significantly lowering the entry threshold for cybercriminals."

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Microsoft Alerts Cryptocurrency Industry of Targeted Cyber Attacks

If compiling a software bill of materials seems daunting, attack surface management tools can provide many of the benefits.

A software bill of materials (SBOM) is an important tool enterprise defenders can use to track the impact of software security bugs, manage sane patch management, and protect the integrity of the software supply chain as a whole. Scores of industry leaders say so. The Office of the President of the United States says so.

So why are they not widely used yet? What are software vendors worried about? Do they know something that we don't?

In a recent CISO Forum in Whitehall, London, many CISOs felt that the challenges and speed of change in application security, particularly in a cloud-enabled environment, had left them a little nonplussed and challenged to change their architectural models and thinking to become fully cloud native. In particular, there was a reluctance to let go of legacy control methods such as IP-based access lists and endpoint-based security controls.

**Hesitant to Set Off the SBOM**

There are several interesting possibilities that may be driving the tendency to delay providing SBOMs.

The first is **ignorance of their own supply chain**. It's possible that the vendors don't actually know the origin of some of their software. It is common practice in large development teams and long, complex projects to effectively "black box" entire sections of code.

If that is the case, the fact that the organization may not fully know the origins of its software raises a myriad of concerns. It could indicate anything from bad version tracking to the existence of potentially indispensable employees that hold the fate of the entire company in their coding hands. It's completely understandable that such a company would hesitate to release SBOMs for its products.

Another scenario that might make a company leery of SBOMs is **if the product is almost entirely an assembly of other products**. It's the reality of modern software development that programs are the result of custom code cobbled together with third-party libraries and components. If the company has written a very low percentage of its own code, then the SBOM could essentially become a recipe card for someone else to clone the product.

But the likely scenario is that software firms may **see no upside, only potential downside** to releasing SBOMs. Currently there's very little market pressure on releasing SBOMs for their product lines. They may have created one for internal use, but there is no real push to make them public. The main concern voiced by CISOs is that while an SBOM may improve visibility, it provides little impetus towards remediation and no liability for fixing software flaws — leaving the problem squarely in the lap of the end user, the CISO.

**Getting Past the SBOM**

It's unlikely that the industry or the purchasing public will be able to generate the market pressure required to force every major player to release an SBOM for all their products. In May 2021, the US government issued an executive order to improve the nation's cybersecurity that explicitly called for SBOMs as a control measure for the software supply chain. The EU government, for its part, has planned a Cyber Resilience proposal to echo and support the requirements of the US order.

If the main purpose of an SBOM is patch management and vulnerability attribution, there is a secondary layer of monitoring and protection that cybersecurity personnel should be looking at: attack surface management (ASM).

While it would be slightly easier for enterprise security teams to know that the software they use contain packages X, Y, and Z, that isn't the only way to manage application security. By tracking the security advisory history of these software suites, we can estimate the most likely attack vectors that they can fall victim to.

The combination of these vulnerabilities compiled from every piece of software that a company uses makes up an organization's attack surface. What ASM tries to do is intelligently categorize these weaknesses and automate the discovery, remediation, and continuous monitoring of new threats.

It's like tying together a vulnerability advisory service with an enterprise software management solution. The way that the ASM does this varies from product to product, but generally some amount of machine learning is involved. That way predictive models can be built so that when certain zero-day exploits are discovered, you will know how likely they are to apply to your attack surface even if you don't have a detailed SBOM from every vendor.

A good ASM has the additional benefit of treating ducks like ducks. You know: If it looks like a duck and quacks like a duck, it doesn't really matter if someone else labeled it as a swan instead. The ASM only cares about results. If a company insists that it's using the Open Dynamics Engine, but for some mysterious reason it falls victim to all the same vulnerabilities as the PhysX engine, ASM will completely ignore labels and suggest the fixes that actually fit the situation and not the ones that correspond to the names.

Even if the movement toward mainstream adoption of SBOM continues to be slow, security professionals have a strong alternative with ASM. It's also worth noting that ASM will complement any SBOM-based software governance with a dynamic risk mitigation system.

Instead of adopting and deploying something locally to cover your vulnerability discovery and monitoring needs, another alternative is to embrace an agentless security model that can monitor extended asset attack surfaces. The device intelligence firm Armis, for example, does this with a fully cloud-native approach. Think of it as an ASM solution that covers IoT devices, cloud instances, and edge networking setups, as well as traditional on-premises.

Such a model presents a different, more global way of looking at asset intelligence that might be more attractive to large enterprise operations. Smaller operations, however, would likely want to save their money for a good ASM and rely on extra vigilance for their extended network devices.

ASM Can Fill Gaps While Working to Implement SBOM

There's no quick fix after decades of underinvestment, but the process has started. Cybersecurity grants, mandatory reporting protocols, and beefed-up authentication requirements are being put in place.

Securing critical infrastructure is complicated because of the vast network of facilities and management systems. Threats targeting this sector can have dire consequences, and when attacks do happen, they're often accompanied by a media storm. This generates interest among concerned citizens, which prompts a reaction from politicians, who are spurred into action to ensure the necessary cyber protections are implemented to calm the concerned citizens — the electorate.

The 2021 ransomware attack on Colonial Pipeline, which caused long lines at gas stations, followed this very timeline and served as a much-needed wake-up call to protect critical infrastructure services against cyberattacks. The attack prompted action at the highest levels of US government, causing the president to expedite an executive order aimed at strengthening US cybersecurity defenses. The executive order, in brief, requires disclosure of incidents, creates a federal playbook for incidents, mandates cybersecurity upgrades, creates a review board, and, importantly, encourages an ethos of cyber-intelligence sharing between government agencies and the private sector.

**Wake-Up Call**

The emphasis on cybersecurity due to the increased threats to critical infrastructure — including cybercriminals attempting to monetize their efforts, terrorism, and the conflict in Ukraine — is unprecedented. In the current budget proposal, the Cybersecurity and Infrastructure Security Agency (CISA) will receive $2.93 billion, $417.1 million more than it requested. There are numerous grants available to critical infrastructure organizations to assist funding the much-needed improvements to cybersecurity; in April 2022, CISA and FEMA began rolling out the first $1 billion from the Rescue Act to help state and local entities improve cybersecurity. Testifying before the House Homeland Security Subcommittee, Jen Easterly, director of the CISA, used the cyberattack on the Oldsmar, Fla., water utility plant as an example of an attack on critical infrastructure to justify the original request.

Enormous would be an underestimate of the task of upgrading the cybersecurity of water supply and wastewater systems in the US. According to American Water, there are 53,000 water supply and sanitation providers in the US. The Environmental Protection Agency (EPA) calculates this differently, and lists 148,000 public water systems (not companies).

If, like me, you live in a rural community, the company supplying your water is likely a small local business providing a critical infrastructure service. On Feb. 5, 2021, the water treatment system servicing Oldsmar City suffered a cyber incident: A poorly secured remote-access solution based on TeamViewer was accessed by a perpetrator, who adjusted the amount of sodium hydroxide in the water from 100 parts per million to 11,000 parts per million. Fortunately, a city water plant operator noticed the increase and reversed it, stopping the attack and the potential poisoning of thousands of people. It was later disclosed that the system accessed wasn't protected by two-factor authentication and was protected by a weak, shared password. There really is no excuse.

The Wall Street Journal's CIO Journal suggests that technology spending as a percentage of revenue in banking and securities is around 7%, and in construction and manufacturing just 2%. Given that water supply is a critical infrastructure service and has been specifically called out as needing cybersecurity investment, it is reasonable to expect spending on IT, including cybersecurity, to be at the higher of these two levels. A report by Deloitte breaks this number out for cybersecurity spending, which they estimate to be 10.9%.

**The $2.5 Billion Scope of the Problem**

What does this mean in a rural water system company, without shaming any particular company? I will use a real-life example without naming the company. Company X has a total revenue budget of $12.4 million per year, with an operating cost for computer services of $211,000 for the same period. There are some costs for IT-related items that may be outside of the operating budget and are attributed to capital spending. For the fiscal year 2021–22, the only item that could have cybersecurity element is a $50,000 cost for SCADA/telemetry/electrical control replacement.

This equates to IT spending (listed as computer services) of 1.7%, and even allowing that 50% of the capital expenditure item is cybersecurity, which is unlikely, this becomes 1.9%. Using the earlier mentioned cybersecurity estimate of 10.9%, the spending on cybersecurity is just under $22,000 per year, for an organization with $12.4 million in revenue. In a sector under continual threat, it's not unreasonable to expect spending to replicate that of financial organizations, which, in this instance, would equate to an IT spending of $868,000, with cybersecurity accounting for just under $94,000 per year.

The water sector does benefit from federal assistance, and the EPA has requested $25 million in fiscal year 2023 for a new grant program to advance cybersecurity infrastructure capacity and protections within the water sector. If you do raw math on this and distribute it among the 54,000 organizations, it equates to less than $500 each. There may be other funding and grants available, but the point isn't the numbers, it’s the magnitude of the problem. To fund each water supply organization $50,000 for cybersecurity, a more realistic number, a budget of $2.5 billion would need to be set aside.

Years of underinvestment in critical infrastructure security isn't something fixable in the short term. The complexity of dealing with 53,000 organizations (around 50,000 of them rural) and attempting to bring them all to a basic level of compliance is a mammoth task. All of this comes at a time when inflation is rampant, and the cost of energy is high.

**One Possible Solution**

There is always a solution. One idea is that the IT services of water supply companies would be better serviced if they were grouped together, centralizing internal services.

If, for example, 10 companies joined together for IT and cybersecurity, there would be numerous benefits: financial, resources, communication, compliance, policy, etc. This would be similar to the way individual schools are part of a school district, with one, single governing body. This is just one solution, and I'm sure there are many options that could be pursued that could help alleviate the financial and resources burden facing the critical infrastructure sector.

What Will It Take to Secure Critical Infrastructure?

Red Hat Security Advisory 2022-8809-01 - The kernel packages contain the Linux kernel, the core of any Linux operating system. Issues addressed include an out of bounds write vulnerability.

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

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

Synopsis:          Important: kernel security and bug fix update  
Advisory ID:       RHSA-2022:8809-01  
Product:           Red Hat Enterprise Linux  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:8809  
Issue date:        2022-12-06  
CVE Names:         CVE-2022-1158 CVE-2022-2639   
=====================================================================

1. Summary:

An update for kernel is now available for Red Hat Enterprise Linux 8.6  
Extended Update Support.

Red Hat Product Security has rated this update as having a security impact  
of Important. 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 CodeReady Linux Builder EUS (v.8.6) - aarch64, ppc64le, x86_64  
Red Hat Enterprise Linux BaseOS EUS (v.8.6) - aarch64, noarch, ppc64le, s390x, x86_64

3. Description:

The kernel packages contain the Linux kernel, the core of any Linux  
operating system.

Security Fix(es):

* kernel: KVM: cmpxchg_gpte can write to pfns outside the userspace region  
(CVE-2022-1158)

* kernel: openvswitch: integer underflow leads to out-of-bounds write in  
reserve_sfa_size() (CVE-2022-2639)

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

Bug Fix(es):

* x86/intel: processors require energy_perf_bias setting (BZ#2102103)

* System crashes due to list_add double add at  
iwl_mvm_mac_wake_tx_queue+0x71 (BZ#2112264)

* Fix SCHED_WARN_ON deadlock (BZ#2125422)

* Starting VMs on a KVM-host with EL8.6-kernel sometimes produces timejumps  
into the future for other already running guest-VMs [rhel.8] (BZ#2125671)

* RHEL8.4 - zfcp: fix missing auto port scan and thus missing target ports  
(BZ#2127850)

* vfio zero page mappings fail after 2M instances (BZ#2128516)

* The kernel needs to offer a way to reseed the Crypto DRBG and atomically  
extract random numbers from it (BZ#2129728)

* ice: Driver Update up to 5.19 (BZ#2130993)

* virtio-net: support XDP when not more queues (BZ#2131740)

* VMs hang after migration (BZ#2131756)

* Update NVME subsystem with bug fixes and minor changes (BZ#2132555)

* [HPE BUG] Premature swapping with swappiness=0 while there’s still plenty  
of pagecache to be reclaimed. (BZ#2133831)

* nf_conntrack causing nfs to stall (BZ#2134089)

* Fix issue that enables STABLE_WRITES by default and causes performance  
regressions (BZ#2135814)

* [ice] Intel E810 PTP clock glitching (BZ#2136037)

* ice: arp replies not making it to switch (BZ#2136043)

* [ice]configure link-down-on-close on and change interface mtu to 9000,the  
interface can't up (BZ#2136217)

* ice: dump additional CSRs for Tx hang debugging (BZ#2136514)

* crypto/testmgr.c should not list dh, ecdh as .fips_allowed = 1  
(BZ#2136525)

* FIPS module identification via name and version (BZ#2136540)

* FIPS self-tests for RSA pkcs7 signature verification (BZ#2137316)

* After upgrading to ocp4.11.1, our dpdk application using vlan strip  
offload is not working (BZ#2138158)

* WARNING: CPU: 0 PID: 9637 at kernel/time/hrtimer.c:1309  
hrtimer_start_range_ns+0x35d/0x400 (BZ#2138954)

* [DELL EMC 8.6-RT BUG] System is not booting into RT Kernel with perc12.  
(BZ#2139217)

* Cannot trigger kernel dump using NMI on SNO node running PAO and RT  
kernel (BZ#2139581)

* Laser bias information can't be shown by ethtool on rhel8.6 (BZ#2139638)

* Nested KVM is not working on RHEL 8.6 with hardware error 0x7  
(BZ#2140144)

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

The system must be rebooted for this update to take effect.

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

2069793 - CVE-2022-1158 kernel: KVM: cmpxchg_gpte can write to pfns outside the userspace region  
2084479 - CVE-2022-2639 kernel: openvswitch: integer underflow leads to out-of-bounds write in reserve_sfa_size()

6. Package List:

Red Hat Enterprise Linux BaseOS EUS (v.8.6):

Source:  
kernel-4.18.0-372.36.1.el8_6.src.rpm

aarch64:  
bpftool-4.18.0-372.36.1.el8_6.aarch64.rpm  
bpftool-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-core-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-cross-headers-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debug-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debug-core-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debug-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debug-devel-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debug-modules-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debug-modules-extra-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debuginfo-common-aarch64-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-devel-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-headers-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-modules-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-modules-extra-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-tools-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-tools-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-tools-libs-4.18.0-372.36.1.el8_6.aarch64.rpm  
perf-4.18.0-372.36.1.el8_6.aarch64.rpm  
perf-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm  
python3-perf-4.18.0-372.36.1.el8_6.aarch64.rpm  
python3-perf-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm

noarch:  
kernel-abi-stablelists-4.18.0-372.36.1.el8_6.noarch.rpm  
kernel-doc-4.18.0-372.36.1.el8_6.noarch.rpm

ppc64le:  
bpftool-4.18.0-372.36.1.el8_6.ppc64le.rpm  
bpftool-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-core-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-cross-headers-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debug-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debug-core-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debug-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debug-devel-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debug-modules-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debug-modules-extra-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debuginfo-common-ppc64le-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-devel-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-headers-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-modules-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-modules-extra-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-tools-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-tools-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-tools-libs-4.18.0-372.36.1.el8_6.ppc64le.rpm  
perf-4.18.0-372.36.1.el8_6.ppc64le.rpm  
perf-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm  
python3-perf-4.18.0-372.36.1.el8_6.ppc64le.rpm  
python3-perf-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm

s390x:  
bpftool-4.18.0-372.36.1.el8_6.s390x.rpm  
bpftool-debuginfo-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-core-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-cross-headers-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-debug-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-debug-core-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-debug-debuginfo-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-debug-devel-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-debug-modules-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-debug-modules-extra-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-debuginfo-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-debuginfo-common-s390x-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-devel-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-headers-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-modules-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-modules-extra-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-tools-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-tools-debuginfo-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-zfcpdump-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-zfcpdump-core-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-zfcpdump-debuginfo-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-zfcpdump-devel-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-zfcpdump-modules-4.18.0-372.36.1.el8_6.s390x.rpm  
kernel-zfcpdump-modules-extra-4.18.0-372.36.1.el8_6.s390x.rpm  
perf-4.18.0-372.36.1.el8_6.s390x.rpm  
perf-debuginfo-4.18.0-372.36.1.el8_6.s390x.rpm  
python3-perf-4.18.0-372.36.1.el8_6.s390x.rpm  
python3-perf-debuginfo-4.18.0-372.36.1.el8_6.s390x.rpm

x86_64:  
bpftool-4.18.0-372.36.1.el8_6.x86_64.rpm  
bpftool-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-core-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-cross-headers-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debug-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debug-core-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debug-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debug-devel-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debug-modules-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debug-modules-extra-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debuginfo-common-x86_64-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-devel-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-headers-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-modules-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-modules-extra-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-tools-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-tools-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-tools-libs-4.18.0-372.36.1.el8_6.x86_64.rpm  
perf-4.18.0-372.36.1.el8_6.x86_64.rpm  
perf-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm  
python3-perf-4.18.0-372.36.1.el8_6.x86_64.rpm  
python3-perf-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm

Red Hat CodeReady Linux Builder EUS (v.8.6):

aarch64:  
bpftool-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debug-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-debuginfo-common-aarch64-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-tools-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm  
kernel-tools-libs-devel-4.18.0-372.36.1.el8_6.aarch64.rpm  
perf-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm  
python3-perf-debuginfo-4.18.0-372.36.1.el8_6.aarch64.rpm

ppc64le:  
bpftool-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debug-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-debuginfo-common-ppc64le-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-tools-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm  
kernel-tools-libs-devel-4.18.0-372.36.1.el8_6.ppc64le.rpm  
perf-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm  
python3-perf-debuginfo-4.18.0-372.36.1.el8_6.ppc64le.rpm

x86_64:  
bpftool-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debug-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-debuginfo-common-x86_64-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-tools-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm  
kernel-tools-libs-devel-4.18.0-372.36.1.el8_6.x86_64.rpm  
perf-debuginfo-4.18.0-372.36.1.el8_6.x86_64.rpm  
python3-perf-debuginfo-4.18.0-372.36.1.el8_6.x86_64.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-1158  
https://access.redhat.com/security/cve/CVE-2022-2639  
https://access.redhat.com/security/updates/classification/#important

8. Contact:

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

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

iQIVAwUBY487zdzjgjWX9erEAQjEAQ/9EQTsnAHyVlEVQ08iCd0RdZ1vLUr0P+oE  
N6krR4vXBkgdKc3A+I96Ak6M4HywsWhN837xIoa6l2OdaVhhjB28KawcgxeRNaD1  
RuVL8MxMSt6ySf6nDNVirdvRMdQNGRLkAsWcDOlKOj1hTm+KKKJhueARR0L/pbY1  
lk0Pi8HpL6YDbzw7+rmLONxA8o1nLeExAbm1oyi7gYXa/1j0W1fZWL8rABs4AiTV  
hF058uUfVSJ4pyDBqmIH8NojXPirkH5GkgrJ9B1yhgzMbB/sNq8XWnbWTHqBUmA0  
wG9e/2lhcQbWtUBidpgeK+mKZPrMdkLYKV8Kxedvi7+dPeFhULuxcQlzYGh2p0bs  
CqaDMnjzy0kLbneShZKYV0EmS8AyQBxVBBjgx1zSXEFExRnIOBl4uixXnMqlFtSn  
Oxh4TYezIf0dNW+mLI+px+Ej/LESDKwjWJtBmS47RCdeAFo5R7ntkRzUmrHsvxZT  
tZt962uZKlrke2DqDdHMYc0AmFvG+v+Lvf9GRe9Lg/OPPsdMnbxt2CxTBrhct7LL  
6wVNrw3TMve7W3k9ARzmR/xGHxozQ8HOTbfMSOBZbz4ppqzVQI92IkSzGfQVMM0e  
ERmVVMR/fymyPKk+HI/BzSAwXjbymD7qMD4HGqVLAZ+9VEfFWLGDIOJyyxjhvy0K  
6SkDuUnTzgM=  
=ZN/9  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-8809-01

Global security technology provider with 20+ years of experience embraces the next evolution of its business with refreshed brand and invigorated leadership.

**MELVILLE, NY, Dec. 6, 2022 —** Intellicene, a provider of intelligent software platforms that empower organizations to better understand and respond to mission-critical events, today announced the close of its acquisition by Volaris Group and the launch of its new brand. Previously known as Cognyte Situational Intelligence Solutions (SIS), the new Intellicene embodies a strategic new direction and an ambition to being a global security intelligence leader of choice.Led by veteran security executive Alan Stoddard, Intellicene incorporates former SIS employees and assets, including the Symphia suite of technologies. The new name and strategic direction also introduces “The Age of Intelligence” which showcases Intellicene’s mission to transform security management from a reactive endeavor to a proactive process that is highly effective, data-driven, and measurable.

The launch of Intellicene follows an incredibly successful year, which saw the company strengthen its presence with new customer wins. Volaris’ buy-and hold philosophy provides stability, shared best practices and a global footprint that can create new opportunities for Intellicene.Sitting at the nexus of awareness, insight, and action, Intellicene delivers integrated, intelligent software platforms that help leaders better understand and respond to critical situations across their organizations. The company has provided intelligent security management platforms to a wide variety of mission-critical, global businesses for more than 20 years since its formation under Verint Systems in 2002.

“We are excited for Intellicene to enter this next chapter and together with Volaris see compelling opportunities to accelerate our growth trajectory and enhance customer focus,” said CEO Alan Stoddard. “With the strong support of our new owners, we are well positioned to capitalize on the many opportunities before us, and we see tremendous potential to expand our reach into new markets and drive new innovations and capabilities.”

Intellicene is focused on ensuring stakeholders have the right tools to help protect operations, assets, and people. With extensive expertise in the security and IT realms, the company and its team has helped ensure the safety of well-regarded brands by developing solutions that help leaders better understand and respond to critical situations. Its Symphia software platform connects to and correlates data from virtually any device, system, or software, providing the real-time awareness and actionable insights needed to identify potential threats and respond effectively.

“We’re pleased to complete this acquisition and support Alan and the management team in building their vision for Intellicene,” said Carl Bruce, Volaris Group. “We see this market as holding tremendous opportunity, and under our ownership, Intellicene is well positioned for future growth.”

Stoddard brings significant experience in leading global organizations and has more than 12 years of experience in the security industry. In addition to Stoddard, the senior leadership team includes Uri Shaffer, Vice President of Sales for EMEA and APAC; Craig Levin, Chief Financial Officer; Yosi Rahamim, Vice President of Research and Development; Mike Howanitz, Vice President of Sales and Business Operations; Joey Caluori, Vice President of Operations; Eran Wachman, Vice President of Product Management; Tracy Markum, Vice President of Sales for the Americas; and Jeffrey Lewis, Chief Marketing Officer.

**About Intellicene**

Intellicene sits at the nexus of awareness, insight, and action. Our mission is to help organizations worldwide harmonize security, business continuity, and risk management to protect what matters most. By delivering integrated, intelligent software platforms that help you better understand and respond to mission-critical events, Intellicene empowers you to manage the most complex security and business operations efficiently. From mobile applications and AI-driven analytics to infinitely scalable software and intelligent devices, we’re building advanced technology that raises the bar and makes the world safer. For more information, visit intellicene.com.

**About Volaris Group**

Volaris acquires, strengthens, and grows vertical market technology companies. As an Operating Group of Constellation Software Inc., Volaris is all about strengthening businesses within the markets they compete and enabling them to grow – whether that growth comes through organic measures such as new initiatives and product development, day-to-day business, or through complementary acquisitions. Learn more at volarisgroup.com.

Intellicene Brand Launches After Completion of Acquisition by Volaris Group

Hackers with ties to the Iranian government have been linked to an ongoing social engineering and credential phishing campaign directed against human rights activists, journalists, researchers, academics, diplomats, and politicians working in the Middle East.
At least 20 individuals are believed to have been targeted, Human Rights Watch (HRW) said in a report published Monday, attributing the

Privacy / Threat Intelligence

Hackers with ties to the Iranian government have been linked to an ongoing social engineering and credential phishing campaign directed against human rights activists, journalists, researchers, academics, diplomats, and politicians working in the Middle East.

At least 20 individuals are believed to have been targeted, Human Rights Watch (HRW) said in a report published Monday, attributing the malicious activity to an adversarial collective tracked as APT42, which is known to share overlaps with Charming Kitten (aka APT35 or Phosphorus).

The campaign resulted in the compromise of email and other sensitive data belonging to three of the targets. This included a correspondent for a major U.S. newspaper, a women's rights defender based in the Gulf region, and Nicholas Noe, a Lebanon-based advocacy consultant for Refugees International.

The digital break-in entailed gaining access to their emails, cloud storage, calendars, and contacts, as well as exfiltrating the entire data associated with their Google accounts in the form of archive files through Google Takeout.

"Iran's state-backed hackers are aggressively using sophisticated social engineering and credential harvesting tactics to access sensitive information and contacts held by Middle East-focused researchers and civil society groups," Abir Ghattas, information security director at Human Rights Watch, said.

The infection chain commences with the targets receiving suspicious messages on WhatsApp under the pretext of inviting them to a conference and luring the victims into clicking a rogue URL that captured their Microsoft, Google, and Yahoo! login credentials.

These phishing pages are also capable of orchestrating adversary-in-the-middle (AiTM) attacks, thereby making it possible to breach accounts that are secured by two-factor authentication (2FA) other than a hardware security key.

15 of the targeted high-profile individuals are confirmed to have received the same WhatsApp messages between September 15 and November 25, 2022, the international non-governmental organization said.

HRW further pointed out inadequacies in Google's security protections, as the victims of the phishing attack "did not realize their Gmail accounts had been compromised or a Google Takeout had been initiated, in part because the security warnings under Google's account activity do not push or display any permanent notification in a user's inbox or send a push message to the Gmail app on their phone."

The option to request data from Google Takeout lines up with a .NET-based program called HYPERSCRAPE that was first documented by Google's Threat Analysis Group (TAG) earlier this August, although HRW said it could not confirm if the tool was indeed employed in this specific incident.

The attribution to APT42 is based on overlaps in the source code of the phishing page with that of another spoofed registration page that, in turn, was associated to a credential theft attack mounted by an Iran-nexus actor (aka TAG-56) against an unnamed U.S. think tank.

"The threat activity is highly likely indicative of a broader campaign that makes use of URL shorteners to direct victims to malicious pages where credentials are stolen," Recorded Future disclosed late last month. "This tradecraft is common among Iran-nexus advanced persistent threat (APT) groups like APT42 and Phosphorus."

What's more, the same code has been connected to another domain utilized as part of a social engineering attack attributed to the Charming Kitten group and disrupted by Google TAG in October 2021.

It's worth pointing out that despite APT35 and APT42's links to Iran's Islamic Revolutionary Guard Corps (IRGC), the latter is geared more towards individuals and entities for "domestic politics, foreign policy, and regime stability purposes," per Mandiant.

"In a Middle East region rife with surveillance threats for activists, it's essential for digital security researchers to not only publish and promote findings, but also prioritize the protection of the region's embattled activists, journalists, and civil society leaders," Ghattas said.

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Iranian State Hackers Targeting Key Figures in Activism, Journalism, and Politics

Organizations can best defend themselves on the cyber battlefield by adopting a military-style defense.

Data leaks, breaches, and cyberattacks are becoming the norm, spawning discussions on how organizations can effectively defend themselves against an ever-evolving threat landscape. With the modern battlefield extending to cyberspace and adversaries adopting military-style tactics, today's defenders see analogies from the military sector as increasingly relevant.

**An Introduction to the OODA Loop**

The OODA loop was introduced by US military strategist and Air Force Col. John Boyd in the mid–20th century. The idea is to create a framework where decisions could be made quickly, using the latest contextual information, helping defenders outpace and out-innovate their opponents.

The loop consists of four phases: Observe, Orient, Decide, and Act. It refers to an iterative decision-making process through which entities observe evolving information, contextualize it, decide on next steps, implement an action plan, and adapt a strategy based on observations and results obtained.

**How Can the OODA Loop Benefit Cybersecurity Teams?**

While the OODA loop was originally developed as a strategy for fighter pilots to use in dogfights (a rapidly evolving environment where stakes are extremely high), a number of litigation, law enforcement, and military organizations have been using OODA successfully for years.

With technology undergoing a massive transformation over the past decade, it's become nearly impossible to monitor and track such a vast ecosystem of infrastructure, users, and applications. All in all, the stakes couldn't be higher for security teams, and since cybersecurity operations have a lot to learn from a real battlefield, the OODA loop is now witnessing an increased amount of attention from the security industry.

The OODA model is applicable to both defenders and incident responders. From a defender's perspective, OODA can be used by security teams for day-to-day operations such as monitoring security events, assessing potential risks, and conducting threat-hunting exercises. From an incident responder's perspective, OODA can help identify, investigate, and respond to potential security issues in a way that recovery can be expedited and damages can be minimized.

**How Can Cybersecurity Teams Leverage the OODA Model Effectively?**

The OODA loop alone doesn't lead to effective cybersecurity. For the model to truly be successful, organizations must ideally be able to "observe" all activity across infrastructure, users, and applications, "orient" themselves with the right contextual information so they can make the right security decisions, and finally, have a "just-in-time" cybersecurity system that can help implement controls in real-time and across the entire ecosystem.

If your organization is looking to implement the OODA model effectively, it must consider deploying a single-pass cloud engine, a converged software stack based on SD-WAN that secures all traffic based on identities — including routing, decryption, deep-packet inspection, and security policy enforcement decisions — known to be native to secure access service edge (SASE). Here are three reasons why:

**1\. End-to-End Visibility Is Key to Observation and Orientation**

Gaining insight into what's happening on the entire attack surface requires a holistic security system that provides end-to-end visibility of all network and security activity. Standard security and threat intelligence services today are siloed and do not communicate well with each other. Security teams therefore lack the right data to implement sound security decisions. On the other hand, as part of the SASE architecture, the single-pass engine ingests all network flows, including Web and cloud traffic, devices, users, applications, systems, and even the Internet of Things (IoT). Since all information flows through a single system, security teams can "observe" end-to-end flows, "orient" themselves with the right context (such as identity, device, network, application, or data), and "decide" on actionable next steps.

**2\. Rapid Decision-Making Requires Just-in-Time Situational Awareness**

When organizations encounter security incidents, time is of the essence. But for dynamic and effective security decisions, security teams require just-in-time situational awareness on infrastructure activity, user behavior, and data movement, etc., as well as contextual information like applications, user identities, locations, and time. Such information is needed to reduce the time taken from observation to action and is critical in incident response scenarios. Not to mention, legacy security tools are fragmented and usually don't provide the full picture needed in rapid OODA looping and crisis situations. With single-pass processing, all services are delivered within the architecture and therefore, security teams benefit from contextual single-pane-of-glass information, which helps them "act" (the last stage of the loop) and respond to a crisis more efficiently and minimize potential damages.

**3\. Real-Time Actions Need a Comprehensive and Ubiquitous Security Backbone**

Attack vectors and threat surfaces evolve so rapidly that security teams must evolve and adapt their defenses according to the observations they make across the industry or their own environment. Cyberattacks, breaches, and vulnerabilities come unannounced at any point in time, which is why security teams need a robust infrastructure that enables them to have seamless control over the entire IT environment at any sudden moment. With SASE, because networking and security management are combined in one place and can be applied to any user or application from anywhere, it's easier to manage security controls and apply patches to applications or devices that do not have an official patch yet (using virtual patches).

It's probably safe to say that the more cybersecurity professionals practice OODA in their everyday decision-making, the more proficient they will become and the faster they will operate. That said, one of the fundamental pillars of the OODA Loop is having an end-to-end security system that provides the right security data, in the right context, at the right time, and with the right levels of controls. This is where SASE and its single-pass cloud engine comes into play in securing the infrastructures of the future.

Applying the OODA Loop to Cybersecurity and Secure Access Service Edge

Victims include at least 15 healthcare organizations, one Fortune 500 company, and other organizations in multiple countries, security vendor says.

Russia-affiliated threat actors have compromised systems belonging to multiple organizations in the US, the UK, France, and other countries and are using them to launch attacks against targets in Ukraine.

Among those whose networks the threat actors have hijacked are at least 15 healthcare organizations, one Fortune 500 company, and one dam-monitoring system, according to a study by threat intelligence and cyber-deception company Lupovis published Dec. 6.

"Russian criminals are rerouting through their networks to launch cyberattacks on Ukrainian \[organizations\], which effectively means they are using these organizations to carry out their dirty work," Lupovis warned in its report.

Lupovis recently deployed a set of decoy documents, Web portals, and SSH services on the Internet as part of an effort to study Russian threat activity targeting Ukrainian entities. The goal was to find out the extent to which Russia's war in Ukraine had spilled over into the cyber realm, like many predicted it would.

**Ukraine-Themed Decoys**

The company designed the decoys in a manner as to entice Russian actors looking to compromise Ukrainian targets. For instance, Lupovis labeled decoy documents with names related to Ukrainian government officials and the country's Critical National Infrastructure, and its decoy websites spoofed Ukrainian government and political sites. The decoy documents contained information that adversaries would consider useful, such as usernames, passwords, and addresses to purportedly critical assets and databases on the decoy websites. The company deliberately leaked some of these fake documents in key Dark Web forums.

Lupovis managed to attract three types of adversaries to its decoy sites. One set comprised of opportunistic attackers, or those constantly scanning the Internet for exploitable CVEs and systems. This was a category of threat actor that Lupovis ignored for the purposes of its study. The second category of adversary was comprised of threat actors who landed directly on the decoy sites without following the breadcrumbs that Lupovis had planted on the Dark Web forums. The third set of threat actors were mostly Russia-based adversaries who took the bait, extracted information from the decoy documents, and used it to attack the decoy websites.

In all, between 50 and 60 attackers landed on each of the two decoy sites Lupovis has set up — some of them just minutes after the sites went live. Once on the sites, the attackers carried out a variety of malicious activities, including SQL injection attacks, remote file inclusion tactics, and Docker exploitation attempts. In many cases, threat actors on the decoy sites attempted to make them part of bigger DDoS botnets or to use them to launch attacks against other Ukrainian websites.

The largest group of attackers were independent actors, says Xavier Bellekens, CEO of Lupovis. They often appeared to be acting alone and were part of communities on Telegram, he says. "Some actors were more advanced in their techniques, tactics, and procedures. However, we haven’t yet been able to correlate them against known Russian APTs." 

The primary motivations in many of these attacks appeared to be information stealing, disruption, and using the decoy websites to launch attacks against other Ukrainian targets, he notes.

**Going After Healthcare**

One of the most disconcerting aspects that researchers at Lupovis observed was the number of attacks on its decoys from other, previously compromised websites and systems belonging to healthcare organizations and entities in other industry sectors, from multiple countries. 

Bellekens says Lupovis was unable to identify the specific groups that were carrying out these attacks, or if any of them were previously known Russian advanced persistent threat groups. "We identified them as Russian if they used scripts containing Cyrillic, tried to access Russian websites, \[or\] looked for specific information in Cyrillic," he says. "A large number of these adversaries tried to exploit the decoys further to launch attacks against Ukrainian entities."

Lupovis' findings suggests that fears earlier this year about Russian cyberattacks in Ukraine impacting organizations in other countries were correct. "Russian cyberattacks have skyrocketed and any country or business that has allied with Ukraine, or opposed the war, has become a target," according to the report.

Concerns over such attacks prompted the US Cybersecurity and Infrastructure Security Agency (CISA) to issue an advisory earlier this year urging both government and private organizations to assume a Shields Up posture for detecting and responding to attacks from Russian cyber groups. The advisory followed remarks by President Joe Biden regarding the US government's willingness to respond in kind to any attempt by Russia to attack the US in cyberspace or through other asymmetric means.

Russian Actors Use Compromised Healthcare Networks Against Ukrainian Orgs

Organizations of all sizes can now protect their cloud-native applications easily and cost-effectively across containers and all other cloud assets.

**RIDGEFIELD PARK, N.J., Dec. 6, 2022 (GLOBE NEWSWIRE) —** AlgoSec, a global cybersecurity leader in securing application connectivity, announced today that it has acquired Prevasio, a SaaS cloud-native application protection platform (CNAPP) that includes an agentless cloud security posture management (CSPM) platform, anti-malware scan, vulnerability assessment and dynamic analysis for containers.

As applications rapidly migrate to the Cloud, security teams are being flooded with alerts. These teams are struggling to detect and prioritize risks through Cloud providers’ native security controls, especially in multi-cloud environments. Furthermore, security teams are hard-pressed to find solutions that meet their budgetary restrictions.

To answer this need, AlgoSec will offer the Prevasio solution at aggressive pricing to new customers, as well as the existing 1,800 blue chip enterprise organizations they currently serve, allowing them to reduce their cloud security costs.

Prevasio’s user-friendly, cost-effective SaaS solution is designed for hardening security posture across all cloud assets, including containers. The solution provides increased visibility into security issues and compliance gaps, enabling the cloud operations and security teams to prioritize risks and comply with CIS benchmarks.

Prevasio customers have successfully reduced administration time and achieved operational cost reductions, even across small teams, within days of operationalization.

Leveraging patented technology developed by Stanford Research Institute International® (SRI), one of the world’s largest research institutes and the developer of SIRI and many other leading technologies, Prevasio’s key capabilities include:

*   Analysis of all assets across AWS, Azure, and Google Cloud, offering a unified view in a single pane of glass
*   Prioritized risk according to CIS benchmarks, HIPPA and PCI regulations
*   Blazing fast static- and dynamic- agentless vulnerability scanning of containers
*   Assessment and detection of cybersecurity threats
*   Instantaneous connection to AWS, Azure, or Google Cloud accounts without installation or deployment

Furthermore, AlgoSec will incorporate SRI artificial intelligence (AI) capabilities into the Prevasio solution.

“Applications are the lifeblood of organizations. As such, our customers have an urgent need to effectively secure the connectivity of those applications across cloud and hybrid estates to avoid unpleasant surprises. With Prevasio, organizations can now confidently secure their cloud-native applications to increase organizational agility and harden security posture,” said Yuval Baron, AlgoSec CEO.

**About AlgoSec** 

AlgoSec, a global cybersecurity leader, empowers organizations to secure application connectivity by automating connectivity flows and security policy, anywhere.  The AlgoSec platform enables the world’s most complex organizations to gain visibility, reduce risk, achieve compliance at the application-level and process changes at zero-touch across the hybrid network. AlgoSec’s patented application-centric view of the hybrid network enables business owners, application owners, and information security professionals to talk the same language, so organizations can deliver business applications faster while achieving a heightened security posture.  Over 1,800 of the world’s leading organizations trust AlgoSec to help secure their most critical workloads across public cloud, private cloud, containers, and on-premises networks. 

**About Prevasio**

Prevasio, an AlgoSec company, helps organizations of all sizes protect their cloud-native applications across containers and all other cloud assets.

Prevasio’s agentless cloud-native application protection platform (CNAPP) provides increased visibility into security and compliance gaps, enabling the cloud operations and security teams to prioritize risks and ensure compliance with internet security benchmarks.

Acquired by AlgoSec in 2022, Prevasio combines cloud-native security with SRI International’s proprietary AI capabilities and AlgoSec’s expertise in securing 1,800 of the world’s most complex organizations.

AlgoSec Acquires Prevasio To Disrupt Agentless Cloud Security Market

Threat actors can weaponize code within AI technology to gain initial network access, move laterally, deploy malware, steal data, or even poison an organization's supply chain.

Threat actors can hijack machine learning (ML) models that power artificial intelligence (AI) to deploy malware and move laterally across enterprise networks, researchers have found. These models, which often are publicly available, serve as a new launchpad for a range of attacks that also can poison an organization's supply chain — and enterprises need to prepare.

Researchers from HiddenLayer's SAI Team have developed a proof-of-concept (POC) attack that demonstrates how a threat actor can use ML models — the decision-making system at the core of almost every modern AI-powered solution — to infiltrate enterprise networks, they revealed in a blog post published Dec. 6. The research is attributed to HiddenLayer's Tom Bonner, senior director of adversarial threat research; Marta Janus, principal adversarial threat researcher; and Eoin Wickens, senior adversarial threat researcher.

A recent report from CompTIA found that more than 86% of CEOs surveyed said their respective companies were using ML as a mainstream technology in 2021. Indeed, solutions as broad and varied as self-driving cars, robots, medical equipment, missile-guidance systems, chatbots, digital assistants, facial-recognition systems, and online recommendation systems rely on ML to function.  
Because of the complexity of deploying these models and the limited IT resources of most companies, organizations often use open source model-sharing repositories in their deployment of ML models, which is where the problem lies, the researchers said.  

"Such repositories often lack comprehensive security controls, which ultimately passes the risk on to the end user — and attackers are counting on it," they wrote in the post.

Anyone that uses pretrained machine learning models obtained from untrusted sources or public model repositories is potentially at risk from the type of attack researchers demonstrated, Marta Janus, principal adversarial ML researcher at HiddenLayer, tells Dark Reading. 

"Moreover, companies and individuals that rely on trusted third-party models can also be exposed to supply chain attacks, in which the supplied model has been hijacked," she says.

**An Advanced Attack Vector**

Researchers demonstrated how such an attack would work in a POC focused on the PyTorch open source framework, showing also how it could be broadened to target other popular ML libraries, such as TensorFlow, scikit-learn, and Keras. 

Specifically, researchers embedded a ransomware executable into the model's weights and biases using a technique akin to steganography; that is, they replaced the least significant bits of each float in one of the model's neural layers, Janus says.

Next, to decode the binary and execute it, the team used a flaw in PyTorch/pickle serialization format that allows for the loading of arbitrary Python modules and execute methods. They did this by injecting a a small Python script at the beginning of one of the model's files, preceded by an instruction for executing the scrip, Janus says.

"The script itself rebuilds the payload from the tensor and injects it into memory, without dropping it to the disk," she says. "The hijacked model is still functional and its accuracy is not visibly affected by any of these modifications."

The resulting weaponized model evades current detection from antivirus and endpoint detection and response (EDR) solutions while suffering only a very insignificant loss in efficacy, the researchers said. Indeed, the current, most popular anti-malware solutions provide little or no support in scanning for ML-based threats, they said.

In the demo, researchers deployed a 64-bit sample of the Quantum ransomware on a Windows 10 system, but noted that any bespoke payload can be distributed in this way and tailored to target different operating systems, such as Windows, Linux, and Mac, as well as other architectures, such as x86/64.

**The Risk for the Enterprise**

For an attacker to take advantage of ML models to target organizations, they first must obtain a copy of the model they want to hijack, which, in the case of publicly available models, is as simple as downloading it from a website or extracting it from an application using it. 

"In one of the possible scenarios, an attacker could gain access to a public model repository (such as Hugging Face or TensorFlow Hub) and replace a legitimate benign model with its Trojanized version that will execute the embedded ransomware," Janus explains. "For as long as the breach remains undetected, everyone who downloads the trojanized model and loads it on a local machine will get ransomed."

An attacker could also use this method to conduct a supply chain attack by hijacking a service provider’s supply chain to distribute a Trojanized model to all service subscribers, she adds. "The hijacked model could provide a foothold for further lateral movement and enable the adversaries to exfiltrate sensitive data or deploy further malware," Janus says.

The business implications for an enterprise vary, but can be severe, the researchers said. They range from initial compromise of a network and subsequent lateral movement to deployment of ransomware, spyware, or other types of malware. Attackers can steal data and intellectual property, launch denial-of-service attacks, or even, as mentioned, compromise an entire supply chain.

**Mitigations and Recommendations**

The research is a warning for any organization using pretrained ML models downloaded from the Internet or provided by a third party to treat them "just like any untrusted software," Janus says. 

Such models should be scanned for malicious code — although currently there are few products that offer this feature — as well as undergo thorough evaluation in a secure environment before being executed on a physical machine or put into production, she tells us.

Moreover, anyone who produces machine learning models should use secure storage formats — for example, formats that don’t allow for code execution — and cryptographically sign all their models so they cannot be tampered with without breaking the signature. 

"Cryptographic signing can assure model integrity in the same way as it does for software," Janus says.

Overall, the researchers said undertaking a security posture of understanding risk, addressing blind spots, and identifying areas of improvement in terms of any ML models deployed in an enterprise also can help mitigate an attack from this vector.

Tag

#intel