A lack of MFA remains one of the biggest impediments to enterprise security.

Tuesday, October 25, 2022 08:10

**Ransomware and pre-ransomware engagements make up 40 percent of threats seen this quarter**

For the first time since compiling these reports, Cisco Talos Incident Response saw an equal number of ransomware and pre-ransomware engagements, making up nearly 40 percent of threats this quarter.

It can be difficult to determine what constitutes a pre-ransomware attack if ransomware never executes and encryption does not take place. However, Talos IR assesses that the combination of Cobalt Strike and credential-harvesting tools like Mimikatz, paired with enumeration and discovery techniques, indicates a high likelihood that ransomware is the final objective.

This quarter featured a variety of publicly available tools and scripts hosted on GitHub repositories or other third-party websites to support operations across multiple stages of the attack lifecycle. This activity coincides with a general increase in the use of other dual-use tools, such as the legitimate red-teaming tool Brute Ratel and the recently discovered Manjusaka and Alchimist attack frameworks.

**Targeting**

Attackers targeted the education sector the most of any vertical this quarter, closely followed by the financial services, government, and energy sectors, respectively. For the first time since Q4 2021, telecommunications was not the top-targeted vertical. While the reason for the education sector being more frequently targeted this quarter is unknown, this is a popular time of year for adversaries to target education institutions as students and teachers return to school.

**Ransomware**

We observed two previously seen high-profile ransomware families, Vice Society and Hive. This quarter also saw a ransomware family that had yet to be observed in IR engagements, Black Basta, which first emerged in April 2022.

Talos IR responded to a Vice Society ransomware engagement affecting an education institution in Austria, part of an ongoing trend of Vice Society actors disproportionately targeting the education sector, which is consistent with U.S. Cybersecurity and Infrastructure Security Agency (CISA) reporting. Analysis of the event logs revealed numerous outbound remote desktop protocol (RDP) connection attempts from an infected host to other systems, indicating the adversary moved laterally. Further analysis identified indicators for remote access software AnyDesk and TeamViewer, where over 50 systems were observed reaching out to TeamViewer-related URLs. An exception was also added to the Windows Defender firewall exemption list for “AnyDesk.exe” executions by the SYSTEM account. The likely trigger for ransomware was PsExec execution followed by deployment of ransomware, which was written to the Windows Roaming profile of the compromised user.

In recent months, Talos observed ongoing Qakbot activity leveraging thread hijacking and password-protected ZIP files to enhance legitimacy. For example, in a ransomware engagement affecting a U.S.-based IT company, Talos IR observed multiple IP addresses associated with command and control (C2) traffic to/from compromised endpoints associated with Qakbot. The attackers likely gained initial access via a phishing email with an HTML attachment that, once opened, initiated JavaScript that subsequently downloaded a malicious password-protected ZIP file. The ZIP file contained a Windows shortcut file (LNK) that, once downloaded and executed on the victim system, delivers Qakbot. The adversaries eventually dropped the ransomware Black Basta, which we had not previously observed in Talos IR engagements. In the past six months, we’ve seen Qakbot use several different infection chains, including potentially moving away from LNK files in some campaigns.

Talos has been monitoring the disclosure of “LockBit Black,” the builder for the LockBit 3.0 ransomware encryptor, leaked publicly in late September 2022 by an alleged LockBit coder/developer. This leak is among many setbacks this group has experienced in recent months, including distributed denial-of-service (DDoS) attacks targeting the group’s data leaks site. While Talos IR did not observe any LockBit ransomware engagements this quarter, the builder could make attribution more difficult involving typical LockBit tactics, techniques, and procedures (TTPs) as more threat actors incorporate the builder in their own ransomware operations. Talos has already begun tracking one new ransomware group dubbed “BlooDy Gang” which has reportedly used the leaked LockBit 3.0 builder in recent ransomware attacks. This could enable even more ransomware groups to save time and resources by relying on leaked builders and source code of other ransomware operations, as opposed to independently developing ransomware.  

**Uptick in pre-ransomware behaviors**

While ransomware was the top threat this quarter, we also observed an equal number of engagements involving various pre-ransomware behaviors. Although each pre-ransomware engagement involves unique behaviors and TTPs, the overwhelming similarities among these engagements include host enumeration, multiple credential-harvesting activities, and attempts to escalate privileges via an identified weakness or vulnerability in order to move laterally to other systems. In some instances where ransomware was never deployed, the adversary was likely trying to exfiltrate data at the time of detection, indicating they had broad enough access to cause significant harm at that time.

In a pre-ransomware engagement affecting a European energy company, Talos IR observed the installation of Cobalt Strike and Mimikatz. The customer first observed Cobalt Strike installation and/or Mimikatz invocation affecting nearly 100 servers. Talos IR detected traffic associated with Metasploit Framework’s Meterpreter shell originating from a compromised host. Seven minutes later, the system attempted to reach out to a confirmed Cobalt Strike C2 server. PowerShell commands and scripts revealed a lightweight Cobalt Strike loader likely associated with Cobalt Strike SMB lateral beaconing. Other tools observed in the environment include the Active Directory mapping tool SharpHound and Rubeus, a Kerberoasting tool.

We observed adversaries leveraging a variety of publicly available tools and scripts hosted on GitHub repositories or free to download from third-party websites to support operations across multiple stages of the attack lifecycle. To support an adversary's objectives, we commonly observed offensive security and red-team tools, such as the modularized Cobalt Strike framework and Active Directory reconnaissance tools ADFind and BloodHound. However, the presence of these additional scripts and tools indicates that adversaries are continuing to identify publicly available resources, which adds convenience but muddies attribution.

In a pre-ransomware incident affecting a U.S. manufacturer, the adversary logged in and executed a publicly available PowerShell script (“DomainPasswordSpray.ps1”) to perform password spraying against the domain. A technique to obtain credentials, password spraying is performed by using a single password, or a list of commonly used passwords, against many different accounts to attempt to validate credentials and gain access. The PowerShell script will result in large numbers of account lockouts, which match the activity reported by the customer. Talos IR also identified the presence of SharpZeroLogon, an exploit for the Zerologon (CVE-2020-1472) privilege escalation vulnerability, which is publicly available on GitHub. Ultimately, this allows an attacker to take control of a domain controller by resetting the account of the targeted domain controller, potentially leading to a full domain admin compromise.

Talos has been monitoring the increased use of dual-use tools such as Cobalt Strike, Brute Ratel, Sliver, and Manjusaka. Brute Ratel is of particular concern since the toolkit was cracked in late September and is being shared for free across several hacking forums and communities. Additionally, endpoint telemetry revealed an attack chain with Qakbot dropping Brute Ratel. Although we have not yet observed Brute Ratel in any Talos IR engagements, we assess that the tool’s rise in the cyber threat landscape in recent months, coinciding with Qakbot operators’ use and the cracked version, will likely lead to more threat actors adopting the post-exploitation kit into their operations.

Of note, a majority of the publicly available tooling leveraged this quarter appears focused on accessing and collecting credentials, highlighting the role these tools play in potentially furthering an adversary’s objectives.

**Initial vectors**

This quarter featured several engagements where attackers leveraged valid accounts to gain initial access, especially in cases where accounts were misconfigured, not disabled properly, or had weak passwords. In at least two engagements this quarter, Talos IR investigated the possibility of initial adversary access via a compromised contractor’s network or a contractor’s personal computer.

In nearly 15 percent of engagements this quarter, adversaries identified and/or exploited misconfigured public-facing applications by conducting SQL injection attacks against external websites, exploiting Log4Shell in vulnerable versions of VMware Horizon, and targeting misconfigured and/or publicly exposed servers.

We continued to see successful Log4Shell (CVE-2021-44228, CVE-2021-45046, and related flaws) exploitation attempts followed by a variety of malicious activities, such as cryptocurrency mining and ransomware. In a Hive ransomware incident affecting a U.S. education institution, Talos IR observed multiple Log4Shell exploitation attempts against a vulnerable VMware Horizon server, the most notable of these attempts resulted in a Cobalt Strike beacon dropped on the server. Talos IR also identified high volumes of cryptocurrency miners, which are common post-exploitation payloads associated with activity targeting the Log4j vulnerabilities. While we could not link the Hive affiliate to the Log4j exploitation attempts, VMware and its respective logs revealed that the server was public-facing, suggesting that more than one adversary may have attempted to target this vulnerability.

The next most common initial infection vector came via email followed by user execution of a malicious document or link. In one of the business email compromise (BEC) engagements affecting a U.S. financial services organization, the adversaries used thread-hijacking and a malicious email link which appeared to be a fake authentication page that collected user credentials upon entering. The adversary also enabled email inbox rules in an attempt to gain persistence on the compromised email account.

It is important to note that for the majority of incidents, Talos IR could not reasonably determine the initial vector because of logging deficiencies or a lack of visibility into the affected environment.

**Security weaknesses**

A lack of MFA remains one of the biggest impediments to enterprise security. Nearly 18 percent of engagements either had no MFA or only had it enabled on a handful of accounts and critical services. Talos IR frequently observes ransomware and phishing incidents that could have been prevented if MFA had been properly enabled on critical services, such as endpoint detection and response (EDR) solutions. Talos IR recommends disabling VPN access for all accounts that are not using two-factor authentication.

In what appears to be a prevalent theme this quarter, in 27 percent of engagements password or account access was not properly configured/disabled, leaving these accounts functionally active and allowing adversaries to use valid credentials to enter the environment. In a few cases, organizations did not properly disable account access after an employee left the organization. Talos IR’s recommendation is to disable or delete inactive accounts from Active Directory to prevent suspicious activity.

**Top-observed MITRE ATT&CK techniques**

Below is a list of the MITRE ATT&CK techniques observed in this quarter’s IR engagements. Given that some techniques can fall under multiple tactics, we grouped them under the most relevant tactic in which they were leveraged. The table below represents the techniques used with a relevant example, and the approximate number of times seen. However, it is not an exhaustive list.

**Key findings from the MITRE ATT&CK appendix include:**

*   Legitimate remote access software, such as AnyDesk and TeamViewer, was leveraged in nearly a quarter of engagements.
*   In an ongoing trend, adversaries leveraged valid accounts for initial access, especially notable where accounts were misconfigured or had weak passwords.
*   We observed adversaries transferring tools or scripts from external systems or adversary-controlled infrastructure into a compromised environment, referred to as ingress tool transfer. The adversaries frequently downloaded these tools from public sites such as GitHub.
*   We observed adversaries deploying Cobalt Strike and Mimikatz across several pre-ransomware engagements. In cases where ransomware encryption took place, PsExec usage played a large role in executing ransomware in 75 percent of ransomware engagements this quarter.

  
Tactic

  
Technique

  
Example

  
Initial Access (TA0001)

  
T1078 Valid Accounts

  
Adversary leveraged stolen or compromised credentials

  
Reconnaissance (TA0043)

  
T1592 Gather Victim Host Information

  
Text file contains details about host

  
Persistence (TA0003)

  
T1136 Create Account

  
Created a user to add to the local administrator’s group

  
Execution (TA0002)

  
T1059.001 Command and Scripting Interpreter: PowerShell

  
Executes PowerShell code to retrieve information about the client's Active Directory environment

  
Discovery (TA0007)

  
T1482 Domain Trust Discovery

  
Use various utilities to identify information on domain trusts

  
Credential Access (TA0006)

  
T1003 OS Credential Dumping

  
Deploy Mimikatz and publicly available password lookup utilities

  
Privilege Escalation (TA0004)

  
T1068 Exploitation for Privilege Escalation

  
Exploit ZeroLogon to escalate privileges with a direct path to a compromised domain

  
Lateral Movement (TA0008)

  
T1021.001 Remote Desktop Protocol

  
Adversary made attempts to move laterally using Windows Remote Desktop

  
Defense Evasion (TA0005)

  
T1027 Obfuscated Files or Information

  
Use base64-encoded PowerShell scripts

  
Command and Control (TA0011)

  
T1105 Ingress Tool Transfer

  
Adversaries transfer/download tools from an external system

  
Impact (TA0040)

  
T1486 Data Encrypted for Impact

  
Deploy Hive ransomware and encrypt critical systems

  
Exfiltration (TA0010)

  
T1567.002 Exfiltration Over Web Service: Exfiltration to Cloud Storage

  
Actor exfiltrated data to file sharing site mega\[.\]nz

  
Collection (TA0009)

  
T1074 Data Staged

  
Stage data in separate output files

  
Software/Tool

  
S0002 Mimikatz

  
Use Mimikatz to obtain account logins and passwords

Quarterly Report: Incident Response Trends in Q3 2022

Introduction
In many ways, the software supply chain is similar to that of manufactured goods, which we all know has been largely impacted by a global pandemic and shortages of raw materials. 
However, in the IT world, it is not shortages or pandemics that have been the main obstacles to overcome in recent years, but rather attacks aimed at using them to harm hundreds or even thousands of

**Introduction**

In many ways, the software supply chain is similar to that of manufactured goods, which we all know has been largely impacted by a global pandemic and shortages of raw materials.

However, in the IT world, it is not shortages or pandemics that have been the main obstacles to overcome in recent years, but rather attacks aimed at using them to harm hundreds or even thousands of victims simultaneously. If you've heard of a cyber attack between 2020 and today, it's likely that the software supply chain played a role.

When we talk about an attack on the software supply chain, we are actually referring to two successive attacks: one that targets a supplier, and one that targets one or more downstream users in the chain, using the first as a vehicle.

In this article, we will dive into the mechanisms and risks of the software supply chain by looking at a typical vulnerability of the modern development cycle: the presence of personal identifying information, or "secrets", in the digital assets of companies. We will also see how companies are adapting to this new situation by taking advantage of continuous improvement cycles.

**The supply chain, at the heart of the IT development cycle****What is the supply chain?**

Today, it is extremely rare to see companies producing software 100% in-house. Whether it's open source libraries, developer tools, on-premise or cloud-based deployment and delivery systems, or _software-as-a-service_ (SaaS) services, these building blocks have become essential in the modern software factory.

Each of these "bricks" is itself the product of a long supply chain, making the software supply chain a concept that encompasses every facet of IT: from hardware, to source code written by developers, to third-party tools and platforms, but also data storage and all the infrastructures put in place to develop, test and distribute the software.

The supply chain is a layered structure that allows companies to implement highly flexible software factories, which are the engine of their digital transformation.

The mass reuse of open-source components and libraries has dramatically accelerated the development cycle and the ability to deliver functionality according to customer expectations. But the counterpart to this impressive gain has been a loss of control over the origin of the code that goes into the companies' products. This chain of dependencies exposes organizations and their customers to vulnerabilities introduced by changes outside their direct control.

This is obviously a major cybersecurity issue, and one that is only increasing as the supply chain becomes more and more complex year over year. So it's no surprise that large-scale cyber attacks have been able to exploit it to their advantage recently.

**The risk of the weak link**

For hackers, the software supply chain of companies represents an interesting target for several reasons. First of all, because of its complexity and the number of interacting "bricks" at the heart of the software factory, its attack surface is very large. Secondly, application security, which was historically focused on securing the application in production (i.e. exposed to the public), often lacks the visibility and tools to effectively secure internal _build_ servers and other parts of the CI/CD pipeline.

In addition, it's important to understand that the development chain today is continuously evolving, adding new tools constantly. This is one of the defining characteristics of the DevOps movement, which has blurred the line between development and operations enormously, leaving developers free to deliver features for their customers as quickly as possible.

These choices though are often implemented without oversight and can be very different from one team to another, even within the same department. The accumulation of slightly different tools, libraries and platforms makes it very difficult to create accurate inventories which are the cornerstone of effective security management.

Finally, by exploiting the supply chain, hackers find ways to maximize the impact, and therefore the yield, of an attack. To understand this, we must consider that the products and services of a software services company's supply chain are the building blocks of other supply chains. An attacker who has successfully infiltrated one link in a chain can compromise the entire user base, which can have disastrous consequences.

**The rise of supply chain attacks**

In the SolarWinds attack, between March and June 2020, approximately 18,000 Orion platform customers, including a number of U.S. government agencies, downloaded updates with malicious code injected into them. This code granted unauthorized backdoor access to systems and private networks. SolarWinds did not discover the breach until December 2020. An international scandal ensued.

A few weeks later, in January 2021, an attacker obtained credentials used in Docker image creation involving Codecov software, due to an error in the build process. These credentials allowed the attacker to hijack Codecov, a software for testing developers' code coverage, and turn it into a real Trojan horse: since the software is used in continuous integration (CI) environments, it has access to the secret credentials of the build processes (we'll come back to this).

The attacker was thus able to siphon off hundreds of credentials from Codecov users, allowing him to access as many secure systems. The company only detected the breach a few months later, in April.

On July 2, 2021, some ninety days later, a sophisticated ransomware group exploited a vulnerability in Kaseya Virtual System Administrator (VSA) servers - affecting approximately 1,500 small businesses. Kaseya is a developer of network, system and infrastructure management software used by managed service providers (MSPs) and other IT contractors. Although a ransomware attack took control of the customers' systems, the attack was contained and defeated after a few days.

But this is not the biggest supply chain vulnerability of 2021. In December 2021, a few months after the Kaseya incident, what is arguably the simplest but most widespread attack on the software supply chain occurred. After an initial proof-of-concept (POC) was disclosed, attackers began a massive exploitation of a vulnerability affecting Apache Log4j, an extremely popular open-source logging library in the Java ecosystem.

Although an update fixing the problem was proposed relatively quickly, the fact that this library, maintained by only a handful of people, is used on a very large scale around the world, and rarely in a transparent way, has created a huge attack surface that will take years to resolve: the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has just described it as "endemic," meaning that it will probably resurface within the next decade.

Despite its magnitude, this vulnerability is far from being an isolated case: the number of attacks using the open source ecosystem as a propagation vector to reach supply chains has increased by 650% between 2020 and 2021. The European Cybersecurity Agency (ENISA) predicts that supply chain attacks will increase fourfold by 2022.

All of these attacks and vulnerabilities have highlighted the lack of visibility and tools to effectively protect the supply chain, whether it be systems to inventory the use of open-source components, to verify their integrity, or to prevent the leakage of sensitive information. On this last point, it is important to take a step back and look more closely at this key element of security.

**The key to the supply chain: secrets**

Getting hold of unencrypted credentials is the perfect way for a hacker to pivot and move down the supply chain from a supplier to its customers: with valid credentials, attackers operate as authorized users, and post-intrusion detection becomes much more difficult.

From a defensive standpoint, hard-coded secrets are a unique type of vulnerability. Source code is a very leaky asset because it is by nature intended to be frequently cloned and distributed on multiple machines. In fact, the secrets in the source code travel with it. But even more problematic is that code also has a 'memory'.

Today any code repository is managed through a version control system (VCS), usually Git, which keeps a perfect timeline of all the changes that have been made to the files in the code base, sometimes over decades. The problem is that still-valid secrets can hide anywhere on that timeline, opening up a new dimension, this time historical, to the software attack surface.

Unfortunately, most security scans are limited to checking the current, deployed or soon-to-be-deployed state of an application's source code. In other words, when it comes to secrets buried in an old commit or even a never-deployed branch, traditional tools are completely blind.

Last year alone, more than 6 million secrets were published in public repos on GitHUb alone: on average, 3 commits out of every 1,000 contained a secret This is a fifty percent increase from the previous year.

A large number of these secrets gave access to corporate resources. It is important to understand that even if the majority of open source projects hosted on GitHub are personal repositories, it is very easy for a professional developer to inadvertently publish code giving access to corporate resources. It happens regularly!

It is therefore not surprising that a malicious actor looking to carry out an attack on the software supply chain would take a close look at the public repositories on GitHub: they would have a good chance of discovering flaws at hand, primarily secrets present in the source code that would allow him to authenticate himself to a system without arousing any suspicion.

Once a secret is published, it must immediately be considered as compromised: a simple experiment consists in voluntarily publishing a "canary token", i.e. a code having quite the appearance of a valid secret, with an alert mechanism triggered when it is used. The time between the publication and the alert is 4 seconds on average! This space is closely monitored and actively exploited.

To neutralize the risk of intrusion as quickly as possible, there is only one solution: the immediate revocation of the secret. But, by panic or lack of technical knowledge, some people try to cover the error by adding a commit that erases the secret, which does not mitigate the security flaw at all: indeed, Git keeps track of all the code history added, modified or deleted over time. In practice, this means that it is difficult to erase all traces of a past error. It also means that, in many cases, the secret will remain available online even after it has been removed from the "final" state of the code.

But the problems do not end there. In our scenario, as the file containing the secret is replaced by a "clean" file, the secret will no longer be detectable either during manual code review by a peer (a common practice), or by traditional application security tools such as scanners, which also only consider the most recent version of the source code. Worse, the flaw will be duplicated every time the code is cloned, and therefore risks being propagated silently for a long time. In other words, a godsend for hackers.

On July 3, the CEO of crypto-currency giant Binance warned of a massive breach that allegedly leaked "1 billion records of \[Chinese\] residents" belonging to the Shanghai police, including "name, address, national identity, cell phone, police and medical records." The cause? A fragment of source code containing the secret to connecting to a titanic database of personal information was allegedly copied and pasted onto a blog by developers of the Chinese CSDN.

**Private repos also affected**

Unsurprisingly, this is only the tip of the iceberg. Private repositories hide many more secrets than their public counterparts. Working in a closed environment provides a false sense of security, making contributors a little less suspicious, and therefore statistically more likely to "let a secret leak". Tolerating the presence of secrets in non-publicly exposed repositories would be a big mistake.

Indeed, no matter how private these repositories are, the secrets they contain could be used as leverage in an attack, allowing adversaries who had access to the repository to pivot to other systems or elevate their privileges. There are many hacking scenarios, but they all have one thing in common: using any found secrets to maximize the impact of an attack.

Application security teams are well aware of the problem. Unfortunately, the amount of work involved in investigating, revoking and rotating secrets every week is simply overwhelming, let alone digging through years of unexplored code.

Cybersecurity teams are taking hard-coded secrets in source code, and the risks they bring, very seriously. They are ranked 15th among the most "common and impactful" vulnerabilities in the famous CWE Top 25 list 2022 (Common Weakness Enumeration).

A key difference, often forgotten that separates this vulnerability from all others, as the previous examples have shown us is that secrets found in the source code are exploitable without the software being in production! In other words, it is the code itself that carries a vulnerability, not the underlying logic.

We have therefore seen how secrets represent a critical element in securing the supply chain. Let's now look at how organizations are responding to this new threat in the development cycle.

**The response of organizations: bring security into the development cycle****The emergence of DevSecOps**

Software supply chains have many grey areas that are not addressed by traditional security methods. Organizations have realized the need to introduce security into the development lifecycle that strikes the right balance between productivity and resilience.

This is how the DevSecOps movement was born. DevSecOps consists of inserting security into DevOps practices. As a reminder, DevOps is a development philosophy that brings together processes and technologies that allow developers to cooperate more effectively with operational teams. We often talk about the DevOps pipeline (the backbone of the software supply chain) which is characterized by its continuity: it is about being able to integrate, test, validate and deliver code in pre-production, in a continuous way.

Traditional security approaches were _at_ odds with the DevOps philosophy: deliver faster and faster and adapt as you go. There was significant friction between the application security teams and the developer teams, with very different cultures, expertise and methods. This divide, a source of many misunderstandings, _ultimately_ contributed to the fragility of the development cycle.

For security managers, the challenge was to maintain the velocity of DevOps while reinforcing improved security posture: including security rules from the earliest stages of the development cycle (planning, design), disseminating best practices, and reducing the mean time to remediation (MTTR) by capturing more "benign" flaws earlier.

More than a method, it is above all an ideal towards which companies wish to strive. The path is not a long one: cultural differences are tenacious and often take years to fade away. Several avenues have been put forward to promote this transition.

The first avenue is to rely on modern tools. Developers adopt intuitive tools that integrate perfectly with their work environments: the command line, API, IDE (Integrated Development Environment), or even their version control system (VCS). Until recently, the typical security analyst's tools were far removed from this world, with very specific and often impenetrable jargon. Security software vendors have made great strides in this area, offering developers the opportunity to become familiar with security concepts and become self-sufficient over a wide area.

Automation is also key for enabling the creation of effective security systems. Software engineers are specialists in automation, so it really made no sense that they could not implement, or even understand, the security rules imposed on them in order to protect the supply chain. They are also the most knowledgeable about the systems that need to be defended. Combining their knowledge with the expertise of security engineers allows for the best use of available resources and overall happier teams.

Perhaps the most important element of DevDecOps is the idea that security must be part of **all** the stages of the development cycle. Its security can not just exist as a simple checklist to be ticked off just before the launch of a new version.

To achieve this result, it is essential to address an important concept: shared responsibility.

**Shared responsibility and shift-left**

The new security model means sharing responsibility among all members involved in the project. Sharing within cross-functional teams, rather than in silos, which was historically the case (a single independent team in charge of security, audit, and quality assurance).

The term "shift left" is often used to illustrate this desire to move security out of its silo in order to move security operations earlier and save money on detection and remediation. However, this term, popularized in the early 2000s, describes a desired operational outcome rather than a real way to achieve it. For an organization wishing to embark on a DevSecOps transformation, it is better to focus on how to induce this change in order to effectively secure its software supply chain.

The empowerment of developers is an essential driver for this. As the first artisans of the digital world, they must be involved in security decisions in order to take their needs and working methods into account. A simple but powerful guideline is to always make the shortest path also the safest.

Thus, a tool for preventing the most common errors (such as forgetting secrets in the source code) should be easy to use and not create friction with the way teams develop code. A good tool must prove its usefulness and value without feeling like it will result in 'vendor lock.' It should also be able to interface with the security teams, which are not going to disappear! On the contrary security teams, which tend to be smaller than their corresponding dev teams must be mobilized quickly for the most complex cases.

In the past, application security was considered an area that had to remain impenetrable to ensure its effectiveness, but those days are gone. Today, there is a desire for security testing to be done throughout the cycle and for the results to allow remediation without necessarily escalating to the security teams.

Promoting ownership of security at each stage of the cycle requires a general effort of transparency between all teams. This is a mandatory condition for creating an environment of trust and fostering a culture that refuses to use blame as an accountability tool.

In fact, even functions that are further away from the technical domain must be part of this transformation. For example, product managers must also take into account the safety of the products they design in their decision-making process.

The response of companies to face the new risks of the software supply chain will therefore be technical as well as organizational. Collaboration between the different professions working along the supply chain is now a priority for information systems security.

_**Note —** This article is written and contributed by Thomas Segura, technical content writer at GitGuardian._

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

How the Software Supply Chain Security is Threatened by Hackers

Mishandling of untrusted input issue resolved by developers

John Leyden 24 October 2022 at 14:46 UTC

Mishandling of untrusted input issue resolved by developers

Security researchers have discovered a serious vulnerability in HyperSQL DataBase (HSQLDB) that poses a remote code execution (RCE) risk.

HSQLDB offers a Java\-based SQL relational database system. The technology – which is the second most popular embedded SQL database with 100 million downloads to date – is used for development, testing, and deployment of database applications.

HSQLDB is used by more than 3,120 Maven packages including LibreOffice, JBoss, Log4j, Hibernate, and Spring-Boot as well as various enterprise software packages.

**Parsing problem**

Security researchers from Code Intelligence discovered the RCE vulnerability (tracked as CVE-2022-41853 and rated with a near-maximum CVSS severity score of 9.8) after running a series of fuzzing tests.

More precisely, they found that the parsing procedure for binary and text format data in the java.sql.Statement and java.sql.PreparedStatement components of the technology were flawed.

All versions of the software up to and including HSQLDB version 2.7.0 are vulnerable. Code Intelligence contacted HSQL Development Group, the developers of HSQLDB, who responded promptly by putting together a fix and a workaround that helps safeguard previous versions.

Catch up on the latest secure development news and analysis

HSQLDB is yet to respond to a request for comment from The Daily Swig but security researchers from Code Intelligence have confirmed that a patch is in the pipeline.

“The issue is already fixed upstream and will be available in the next release,” Code Intelligence said. “From version 2.7.1. the property hsqldb.method\_class\_names must be defined with a list of class names or wild cards if any Java static method is used as an HSQLDB routine target.”

The previous implementations caused a problem because the use of Java static methods, except those in java.lang.Math, should not be allowed without defining the system property or else problems can arise.

**Root cause**

A technical write-up of the issue by Code Intelligence explains the root cause of the problem in more depth.

“By default, SQL statements can be used to call any static method from any Java class in the class path. HSQLDB (HyperSQL DataBase) allowed direct use of methods,” a post on Medium last week explains.

The vulnerability means that using java.sql.Statement or java.sql.PreparedStatement in pre-patch versions of HSQLDB along with untrusted input may leave applications vulnerable to an RCE attack.

In response to queries from The Daily Swig, Khaled Yakdan, co-founder of Code Intelligence, explained that an app does not have to be vulnerable to SQL injection for the issue to come into play.

“The current default configuration allows static methods of any class that is on the classpath to be used,” Yakdan said. “Moreover, direct use of methods is allowed for legacy compatibility.”

Yakden declined to speculate on which particular apps might be vulnerable, but he was able to explain the impact of the flaw in cases where it was activated.

“We only focus on finding bugs and don’t investigate which code bases are vulnerable,” Yakden told The Daily Swig. “The impact of this CVE is that if you use HyperSQL to process queries that include (untrusted) user input, attackers may be able to cause your app to execute arbitrary code.”

RELATED Apache Commons Text RCE: Resemblance to Log4Shell but exposure risk is ‘much lower’

HyperSQL DataBase flaw leaves library vulnerable to RCE

Hello everyone! This episode will be about the new hot twenty vulnerabilities from CISA, NSA and FBI, Joint cybersecurity advisory (CSA) AA22-279A, and how I analyzed these vulnerabilities using my open source project Vulristics. Alternative video link (for Russia): https://vk.com/video-149273431_456239105 Americans can’t just release a list of “20 vulnerabilities most commonly exploited in attacks on […]

Hello everyone! This episode will be about the new hot twenty vulnerabilities from CISA, NSA and FBI, Joint cybersecurity advisory (CSA) AA22-279A, and how I analyzed these vulnerabilities using my open source project Vulristics.

Alternative video link (for Russia): https://vk.com/video-149273431\_456239105

Americans can’t just release a list of “20 vulnerabilities most commonly exploited in attacks on American organizations.” They like to add geopolitics and point the finger at some country. Therefore, I leave the attack attribution mentioned in the advisory title without comment.

But I like such lists of vulnerabilities for a number of reasons:

*   Such lists of **vulnerabilities** show which CVEs need to be addressed. This is the most obvious. If you notice vulnerabilities from the list in your infrastructure, start fixing them as soon as possible.
*   Such lists of vulnerabilities show the **software and hardware products** that are most important to monitor. This means that your vulnerability scanner must support this software very well. Make sure you can verify this.
*   Such lists of vulnerabilities show **groups of software and hardware products** that need to be monitored first. Usually these are products that are available to a wide range of users and are inconvenient to upgrade.
*   Such lists of vulnerabilities show **the types of vulnerabilities** that you need to pay attention to first.
*   Such lists of vulnerabilities are relatively compact and **can be easily analyzed** even manually.

I can’t help but notice that the quality of the advisory is not very high. For example, the description of vulnerabilities was automatically taken from NVD. Including this:

“Microsoft Exchange Server remote code execution vulnerability. This CVE ID differs from CVE-2021-26412, CVE-2021-26854, CVE-2021-26855, CVE-2021-26858, CVE-2021-27065, and CVE-2021-27078”.

Not very informative, right? This joint advisory was released by three big serious organizations. They could work harder and write a unique text for each of the 20 CVEs. But no one seems to care.

Here is a list of all vulnerabilities from the advisory:

1.  Apache Log4j CVE-2021-44228 Remote Code Execution
2.  Pulse Connect Secure CVE-2019-11510 Arbitrary File Read
3.  GitLab CE/EE CVE-2021-22205 Remote Code Execution
4.  Atlassian CVE-2022-26134 Remote Code Execution
5.  Microsoft Exchange CVE-2021-26855 Remote Code Execution
6.  F5 Big-IP CVE-2020-5902 Remote Code Execution
7.  VMware vCenter Server CVE-2021-22005 Arbitrary File Upload
8.  Citrix ADC CVE-2019-19781 Path Traversal
9.  Cisco Hyperflex CVE-2021-1497 Command Line Execution
10.  Buffalo WSR CVE-2021-20090 Relative Path Traversal
11.  Atlassian Confluence Server and Data Center CVE-2021-26084 Remote Code Execution
12.  Hikvision Webserver CVE-2021-36260 Command Injection
13.  Sitecore XP CVE-2021-42237 Remote Code Execution
14.  F5 Big-IP CVE-2022-1388 Remote Code Execution
15.  Apache CVE-2022-24112 Authentication Bypass by Spoofing
16.  ZOHO CVE-2021-40539 Remote Code Execution
17.  Microsoft CVE-2021-26857 Remote Code Execution
18.  Microsoft CVE-2021-26858 Remote Code Execution
19.  19) Microsoft CVE-2021-27065 Remote Code Execution
20.  20) Apache HTTP Server CVE-2021-41773 Path Traversal

Of course, I did not deny myself the pleasure of using this list of CVEs as input for my Vulristics vulnerability prioritization tool. Just to see how Vulristics handles it and tweak Vulristics if needed.

Here is the command I used to generate the report:

    $ python3.8 vulristics.py --report-type "cve_list" --cve-project-name "AA22-279A" --cve-list-path joint_cves.txt --cve-data-sources "ms,nvd,vulners,attackerkb" --cve-comments-path comments.txt --rewrite-flag "True"

The full report is here: https://avleonov.com/vulristics\_reports/aa22-279a\_report\_with\_comments\_ext\_img.html

**Vulnerable Products**

If you look at the list of vulnerable software and hardware products, then some of them, obviously, should have been included in this advisory. Because lately there have been a lot of publications about how attackers exploit the vulnerabilities in these products:

*   Apache HTTP Server
*   Apache Log4j2
*   GitLab
*   Microsoft Exchange
*   Confluence Server
*   Zoho ManageEngine ADSelfService Plus
*   Pulse Connect Secure

The second group of products. For them, there were also publications about attacks. But it seems that these are more niche products and are less perceived as targets for attackers:

*   BIG-IP
*   Citrix Application Delivery Controller
*   VMware vCenter
*   Cisco HyperFlex HX

And finally, there are quite exotic products that apparently reflect the specifics of American IT:

*   Sitecore Experience Platform (XP)
*   Hikvision Web Server
*   Apache APISIX
*   Buffalo WSR

**Criticality of Vulnerabilities**

Vulristics has identified all vulnerabilities as vulnerabilities of the highest criticality level (Urgent). Vulristics found public exploits for all vulnerabilities.

At the same time, if you look at CVSS, then there is this:

All vulnerabilities: 20  
Critical: 16  
High: 4  
Medium: 0  
Low: 0

So if you are using CVSS for prioritization, don’t forget about the High level vulnerabilities.

**Detected Types of Vulnerabilities**

*   Remote Code Execution
*   Command Injection
*   Arbitrary File Reading
*   Authentication Bypass
*   Path Traversal

As we can see, all vulnerabilities are obviously critical except for one “Path Traversal”:

Path Traversal – Citrix Application Delivery Controller (CVE-2019-19781)

The description of the vulnerability leaves no room for detecting another type:

“An issue was discovered in Citrix Application Delivery Controller (ADC) and Gateway 10.5, 11.1, 12.0, 12.1, and 13.0. They allow Directory Traversal”.

The same type is indicated in the advisory AA22-279A: Citrix ADC CVE-2019-19781 Path Traversal

And only in the description of the exploit we can see that this is in fact RCE: “This tool exploits a directory traversal bug within Citrix ADC (NetScalers) which calls a perl script that is used to append files in an XML format to the victim machine. This in turn allows for **remote code execution**.”

Well, this is another reminder to us that we should not do hard filtering by vulnerability type. It’s also not a good idea to trust the description from NVD. The type of vulnerability may change over time, and no one will make changes to the description in NVD.

In some cases, Vulristics can help to more accurately determine the type of vulnerability:

AA22-279A: Apache HTTP Server CVE-2021-41773 Path Traversal  
Vulristics: Remote Code Execution – Apache HTTP Server (CVE-2021-41773)

Why? Because we can read in the description: “If CGI scripts are also enabled for these aliased pathes, this could allow for **remote code execution**.”

But of course Vulristics is not a silver bullet. It is difficult to come up with something here other than manual analysis of publications about vulnerabilities and exploits.

I also cannot help but point out that for some of the vulnerabilities, Vulrisitcs determined the types of vulnerabilities more correctly in accordance with the description:

AA22-279A: GitLab CE/EE CVE-2021-22205 Remote Code Execution  
Vulristics: Command Injection – GitLab (CVE-2021-22205) – Urgent \[947\]  
“… which resulted in a **remote command execution**.”

AA22-279A: Sitecore XP CVE-2021-42237 Remote Code Execution  
Vulristics: Command Injection – Sitecore Experience Platform (XP) (CVE-2021-42237)  
“… it is possible to achieve **remote command execution** on the machine.”

AA22-279A: VMware vCenter Server CVE-2021-22005 Arbitrary File Upload  
Vulristics: Remote Code Execution – VMware vCenter (CVE-2021-22005)  
“…may exploit this issue **to execute code** on vCenter Server by uploading a specially crafted file.”

AA22-279A: F5 Big-IP CVE-2022-1388 Remote Code Execution  
Vulristics: Authentication Bypass – BIG-IP (CVE-2022-1388)  
… undisclosed requests **may bypass** iControl REST **authentication**“

AA22-279A: Apache HTTP Server CVE-2021-41773 Path Traversal  
Vulristics: Remote Code Execution – Apache HTTP Server (CVE-2021-41773)  
“… this could allow for **remote code execution**.”

AA22-279A: Apache CVE-2022-24112 Authentication Bypass by Spoofing  
Vulristics: Remote Code Execution – Apache APISIX (CVE-2022-24112)  
“… is vulnerable to **remote code execution**.”

AA22-279A: Buffalo WSR CVE-2021-20090 Relative Path Traversal  
Vulristics: Authentication Bypass – Buffalo WSR (CVE-2021-20090)  
“… allow unauthenticated remote attackers to **bypass authentication**.”

Therefore, do not rush to trust the vulnerability type from the CISA Known Exploited Vulnerabilities Catalog and take it into account when prioritizing vulnerabilities.

Hi! My name is Alexander and I am a Vulnerability Management specialist. You can read more about me here. Currently, the best way to follow me is my Telegram channel @avleonovcom. I update it more often than this site. If you haven’t used Telegram yet, give it a try. It’s great. You can discuss my posts or ask questions at @avleonovchat.

А всех русскоязычных я приглашаю в ещё один телеграмм канал @avleonovrus, первым делом теперь пишу туда.

Joint Advisory AA22-279A and Vulristics

The good news: The Apache Commons Text library bug is far less likely to lead to exploitation than last year's Log4j library flaw.

The Text4Shell vulnerability, tracked under CVE-2022-42889, started drawing potentially malicious activity this week.

Researchers at Wordfence issued a threat advisory urging security teams to update their Apache Commons Text library to the patched version 1.10.0. The team began monitoring Text4Shell, which has been given a CVSS score of 9.8, on Oct. 17, and by Oct. 18 they started seeing attempts to exploit it.

While the threat does have many similarities to last year's Apache Log4j library bug, Wordfence security researchers say Text4Shell poses less of a threat.

"While the vulnerability itself is similar to last year's vulnerability CVE-2021-44228 in Apache's log4j library, the Apache Commons Text library is far less widely used in an unsafe manner and the likelihood of successful exploitation is significantly lower," the team explained in their latest advisory.

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

Exploit Attempts Underway for Apache Commons Text4Shell Vulnerability

WordPress security company Wordfence on Thursday said it started detecting exploitation attempts targeting the newly disclosed flaw in Apache Commons Text on October 18, 2022.
The vulnerability, tracked as CVE-2022-42889 aka Text4Shell, has been assigned a severity ranking of 9.8 out of a possible 10.0 on the CVSS scale and affects versions 1.5 through 1.9 of the library.
It's also similar to

WordPress security company Wordfence on Thursday said it started detecting exploitation attempts targeting the newly disclosed flaw in **Apache Commons Text** on October 18, 2022.

The vulnerability, tracked as CVE-2022-42889 aka **Text4Shell**, has been assigned a severity ranking of 9.8 out of a possible 10.0 on the CVSS scale and affects versions 1.5 through 1.9 of the library.

It's also similar to the now infamous Log4Shell vulnerability in that the issue is rooted in the manner string substitutions carried out during DNS, script, and URL lookups could lead to the execution of arbitrary code on susceptible systems when passing untrusted input.

A successful exploitation of the flaw can enable a threat actor to open a reverse shell connection with the vulnerable application simply via a specially crafted payload, effectively opening the door for follow-on attacks.

While the issue was originally reported in early March 2022, the Apache Software Foundation (ASF) released an updated version of the software (1.10.0) on September 24, followed by issuing an advisory only last week on October 13.

"Fortunately, not all users of this library would be affected by this vulnerability – unlike Log4J in the Log4Shell vulnerability, which was vulnerable even in its most basic use-cases," Checkmarx researcher Yaniv Nizry said.

"Apache Commons Text must be used in a certain way to expose the attack surface and make the vulnerability exploitable."

Wordfence also reiterated that the likelihood of successful exploitation is significantly limited in scope when compared to Log4j, with most of the payloads observed so far designed to scan for vulnerable installations.

"A successful attempt would result in the victim site making a DNS query to the attacker-controlled listener domain," Wordfence researcher Ram Gall said, adding requests with script and URL prefixes have been comparatively lower in volume.

If anything, the development is yet another indication of the potential security risks posed by third-party open source dependencies, necessitating that organizations routinely assess their attack surface and set up appropriate patch management strategies.

Users who have direct dependencies on Apache Commons Text are recommended to upgrade to the fixed version to mitigate potential threats. According to Maven Repository, as many as 2,593 projects use the Apache Commons Text library.

The Apache Commons Text flaw also follows another critical security weakness that was disclosed in Apache Commons Configuration in July 2022 (CVE-2022-33980, CVSS score: 9.8), which could result in arbitrary code execution through the variable interpolation functionality.

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

Hackers Started Exploiting Critical "Text4Shell" Apache Commons Text Vulnerability

The fix was developed at a running pace as Cobalt Strike is essential to Red Team operations

The fix was developed at a running pace as Cobalt Strike is essential to Red Team operations

  

The team behind the Cobalt Strike penetration testing tool has responded to reports of a failed remote code execution (RCE) exploit patch with a new fix.

HelpSystems’ Cobalt Strike enables cybersecurity professionals to simulate attacks with post-exploit agents and is arguably the most popular threat emulation software of its type.

However, the source code of old versions of the licensed software is subject to leaks – the latest of which reportedly took place in 2020.

As a result, Cobalt Strike often surfaces within the arsenal of sophisticated threat actors who use the software to set up command and control (C2) beacons for illicit communication.

**Failed fix**

Given the importance of this tool and how red teams worldwide rely on Cobalt Strike for their research and cybersecurity audits, the details of the failed patch were kept private until a fix could be released.

On October 17, Rio Sherri, managing security consultant of IBM’s X-Force Red Adversary Simulation team, revealed in a blog post that a patch designed to resolve a known RCE vulnerability had failed.

The vulnerability, tracked as CVE-2022-39197 and issued a CVSS severity score of 6.1, is a cross-site scripting (XSS) issue that allowed remote attackers to execute code without permission on the Cobalt Strike teamserver.

It was possible to trigger the bug by inspecting a Cobalt Strike v.4.7 payload and modifying the username field. Alternatively, an intruder could create a new, malicious payload using the extracted information.

A researcher with the pseudonym ‘Beichendream’ privately reported the original security flaw.

HelpSystems published an out-of-band patch for the RCE on September 20. The Cobalt Strike 4.7.1 release added a new property to the teamserver file, which “specifies whether XSS validation is performed on selected Beacon metadata,” according to HelpSystems.

However, after IBM researchers Sherri and Ruben Boonen examined the patch, it transpired that the 4.7.1 update was “insufficient to mitigate the impact of the vulnerability”.

If an attacker created Java Swing components, the researchers found, it was possible to circumvent the fix and create arbitrary Java objects in class paths, as Java Swing will interpret any text as HTML content as long as it begins with an HTML tag. Object tags could then load a malicious payload from the server, which a Cobalt Strike client would subsequently deploy.

**Second patch**

IBM X-Force notified HelpSystems of its findings privately and requested a new CVE, CVE-2022-42948. The researchers also assisted Cobalt Strike developers in creating a bulletproof patch.

The vulnerability has been resolved in Cobalt Strike v. 4.7.2 via a second out-of-band patch. HelpSystems thanked IBM, noting that the circumvention was caused by the Cobalt Strike interface being built on the Java Swing framework.

While IBM requested a new CVE, HelpSystems did not, noting that the underlying issue is in Java Swing rather than Cobalt Strike as a standalone application.

“We felt that there were parallels between this and the recent log4j vulnerability – thousands of applications that used log4j were vulnerable and yet there aren’t CVEs to cover every single vulnerable application,” commented Greg Darwin, Cobalt Strike software development manager. “It is the same case here, although I appreciate that some people may disagree.”

The Daily Swig has reached out to IBM for clarity on the focus of the new CVE assignment and we will update if and when we hear back.

DON’T MISS Apache Commons Text RCE: Resemblance to Log4Shell but exposure risk is ‘much lower’

Failed Cobalt Strike fix with buried RCE exploit now patched

Categories: Business
In this post, we cover the importance of third-party application patching and the challenges it can solve for your organization.



(Read more...)




The post Third-party application patching: Everything you need to know for your business appeared first on Malwarebytes Labs.

Patch management that is consistent and efficient has never been more critical in keeping your security infrastructure up to date and secure. Although today’s endpoint management solutions include patch management functionalities, third-party patching is an area that shouldn’t be forgotten.

In this post, we will cover the importance of third-party application patching and the challenges it can address for your organization.

**What is a third-party application?**

A third-party application is a type of software designed by an independent vendor other than the initial manufacturer of the device. Common examples of third-party app vendors, include Google Chrome, Adobe Acrobat Reader, TeamViewer, and others.

**What is third-party patching and why is it important?**

Third-party patching involves applying patch updates to third-party applications that have been installed on your business endpoints, which includes desktops, laptops, servers, and other devices. Third-party patch management patches vulnerabilities that, if exploited, can jeopardize the security and functionality of software. Vulnerabilities expose your company’s attack surfaces to malicious actors looking for opportunities to access your network.

So, why is patching third-party applications important to your business?

Patching software vulnerabilities is a key driver for preventing future cyberattacks on your organization. The vulnerabilities found in your business’s third-party apps opens the flood gates for hackers.

These malicious adversaries spread in your systems through techniques such as privilege escalation and lateral movement, seeking out sensitive information and valuable data. Patching third-party vulnerabilities reduces the likelihood of an attack while also fixing the bugs to improve software functionality. Another reason your organization should consider third-party patching is that it can help your business satisfy necessary compliance regulations.

**The risks to your business when neglecting to patch third-party applications**

In 2021, 93% of companies experienced a cybersecurity breach of some kind due to third-party vendors or supply chain weakness. With the average cost of a data breach in the US at an astounding $9.4 million, the repercussions of a cyber incident caused by unpatched vulnerabilities are detrimental. Consequentially, an attack of such magnitude causes disruption to daily workflows, productivity, and in cases causes reputational harm. Neglecting to patch third-party apps is a risk your company can’t afford.

When security teams choose not to consistently patch endpoints, your risk of exposure to potential cyberattacks increases. In 2021 for instance, Log4Shell, a software vulnerability in Apache Log4j 2, took the world by storm. For more information on Log4Shell, read the Malwarebytes blog post - What SMBs can do to protect against Log4Shell attacks.

What can businesses learn from vulnerabilities like Log4Shell? The third-party application patch management process is essential. Although third-party app vendors don’t strictly adhere to a patch release schedule, they normally do this when a vulnerability is discovered with a patch being released to address it. Read our article on Security vulnerabilities: 5 times businesses (and governments) got hacked for more information on how hackers exploited vulnerabilities like Log4Shell to attack organizations.

It’s challenging for organizations to keep up with all the software updates and available patches for third-party apps. More companies rely on third-party applications for their day-to-day business operations. Adhering to patch management best practices can help alleviate your security team’s load and enhance your organization’s cyber prevention.

**What is automated third-party patching?**

Automated patch management allows businesses to automatically scan endpoint devices for patches that are needed and automate the distribution of patches. In some situations, automated patching allows businesses to flexibly schedule patching deployments so that the third-party patching process doesn’t interrupt daily workflows. This automation eliminates the grunt work of manual patching where system admins would otherwise spend hours applying software patches themselves.

**What are the drawbacks of automated patch management software?**

Automated patch management can help minimize manual workloads and improve your company’s security posture. But it should be noted that automating the patch management process comes with increased operational risk depending on the situation.

Depending on the type of security infrastructure your organization has, implementing automated patch management software to a system that relies heavily on manual infrastructure deployment and managing may not be the best option. Security architecture that’s legacy-application heavy is not ideal for automated patch management. This is especially the case for integral applications - a minute of downtime causes dramatic organizational losses.

A common misconception is that automated third-party patching means your systems are more secure. While automatic patching helps your company maintain strong security posture, it is not a cure-all for security and is limited to its pre-programmed policies used to scan and identify missing patches. As more companies adopt cloud-native security infrastructure, the easier it will be to automate third-party patching.

**Third-party patch management vs vulnerability management – Let’s compare the two processes**

Third-party software patch management is centralized on grouping, prioritizing, and identifying missing patches in third-party applications. Patch management vendors created patch management solutions to tackle patches, but not all patches will resolve security flaws. For this reason, patch management products alone can’t effectively secure your organization.

Vulnerability management addresses your security risks by identifying security vulnerabilities in your systems. These vulnerabilities include a range of security issues where in some cases deploying a patch is not the solution to a particular vulnerability. Other vulnerabilities could involve security training for staff, configuring firewall policies, or making changes to your network.

**Third-party Patch Management and Compliance**

Timely and consistent third-party patching reinforces your cybersecurity prevention.

Third-party applications need to be continually updated to decrease your risk of infection. Leaving third-party apps unpatched or out of date can hinder your organization from achieving patch compliance requirements. Cybersecurity regulatory compliance such as PCI (Payment Card Industry Security Standards Council), GDPR (General Data Protection Regulation), and HIPAA (Health Insurance Portability and Accountability Act), all set standards for patch deployment and security patching protocols.

Interested in learning more about cyberattack prevention with vulnerability assessment and patch management tools? Visit our Vulnerability and Patch Management Modules and explore related content below.

Vulnerability response for SMBs: The Malwarebytes approach

**Listen to Lock and Code – Why software has so many vulnerabilities, with Tanya Janca****Malwarebytes’ modernized bug bounty program – here’s all you need to know****5 technologies that help prevent cyberattacks for SMBs****Request a demo of our Vulnerability Assessment and Patch Management module **

Third-party application patching: Everything you need to know for your business

External attack surface management leader unveils evolution of risk intelligence solution, including a virtual sandbox environment to safely validate steps to remediation.

PALO ALTO, Calif., Oct. 20, 2022 /PRNewswire/ — CyCognito today announced the next generation of its Exploit Intelligence solution to help security teams prioritize and mitigate the most critical security risks in their external attack surface. Exploit Intelligence leverages CISA, FBI and other threat intelligence sources, including adversary activity, to create advisories that validate where threats in the wild align to risks in the organization.

Sandbox Virtual Lab, a key new feature of Exploit Intelligence, is the industry's first integrated external attack surface sandbox testing environment. Now security teams can simulate how an adversary would compromise a specific asset, quickly validating if and how a vulnerability can be exploited and the potential impact. Additionally, Sandbox Virtual Lab enables repeat asset testing to ensure proper patching.

This initial release of the Sandbox Virtual Lab focusses on Log4j because it remains a pervasive threat. In the coming months, Sandbox Virtual Lab will also support additional simulate Log4Shell, ProxyShell, ProxyLogon and ZeroLogon threats.

"CyCognito's Exploit Intelligence fills a gap between threat intel and vulnerability management," said Rob Gurzeev, CEO, CyCognito. "The addition of Exploit Intelligence doesn't just link vulnerabilities to specific assets, but answers the important question of why it is important to prioritize fixing specific assets immediately because of their attractiveness to active attackers."

Exploit Intelligence dramatically reduces Mean Time to Remediation (MTTR) of an organization's riskiest external assets, saving security teams time and money. CyCognito's unparalleled discovery and mapping engine paired now with integrated Exploit Intelligence gives security teams actionable knowledge (not just data feeds) to build, test and deploy fixes for today's most pervasive threats, such as Log4j.

Features and benefits include:

*   **Remediation Acceleration:** Exploit Intelligence quickly identifies highest-risk exploitable assets within an external attack surface, empowering security teams to reduce response and remediation timelines from months to days.
*   **Curated Intelligence:** Understand how threats are being actively executed by attackers in the wild and how those threats map to vulnerabilities in your attack surface.
*   **Quick Impact Assessment:** A focused map that paints a picture of all assets potentially at risk, including those assets that are already protected and those that remain vulnerable.
*   **Identify Ownership:** The CyCognito discovery engine determines asset ownership to quickly identify who is responsible for fixing vulnerable assets.
*   **Verify and Act with Confidence****:** Safely test exploits against assets in the Sandbox Virtual Lab to determine actual risk to an IT stack.
*   **Mitigate Threats Faster:** Integrates with SIEM/SOAR, ticketing tools and remediation workflows to provide evidence and mitigation guidance.

**About Cycognito  
**CyCognito solves one of the most fundamental business problems in cybersecurity: seeing how attackers view your organization, where they are most likely to break in, what systems and assets are at risk, and how you can eliminate the exposure. Founded by national intelligence agency veterans, CyCognito has a deep understanding of how attackers exploit blind spots and a path of least resistance. The Palo Alto-based company is funded by leading Silicon Valley venture capitalists, and its mission is to help organizations protect themselves from even the most sophisticated attackers. It does this with a category-defining, transformative platform that automates offensive cybersecurity operations to provide reconnaissance capabilities superior to those of attackers.

CyCognito Launches Next Generation of Exploit Intelligence Threat Remediation Platform

By Waqas
The malware has been identified as I3mon, which can perform all kinds of spying operations.
This is a post from HackRead.com Read the original post: Smartphones of Iran’s protest detainees targeted with spyware

In recent months, there has been a growing number of protests in Iran after **Mahsa Amini’s death**. And while these protests have been met with a heavy crackdown by the government, it seems that they may have also been targeted by spying malware.

According to Voice of America (VoA), spyware has been detected on the Android cellphones of some individuals recently detained for protesting against the government. 

It is worth noting that on September 16th, 2022, a 22-year-old Iranian woman named **Mahsa Amini died in Tehran, Iran**, under Police custody. Amini was arrested for failure to follow government-mandated forms of the Hijab.

The malware, identified as **I3mon**, can perform all kinds of spying operations. It comes with an installation file (com.etechd.l3mon.apk).

VoA obtained a copy of the spyware. In its report, the agency noted that the malware was previously distributed on different forums and titles such as **Telegram with Free Internet**.

On the other hand, cybersecurity firms like **Kaspersky** and Dr. Web have already categorized the malware as a trojan of the Android malware family. Dr. Web **dubbed** the malware as “Android.SmsSpy.88.origin” back in August 2015.

**How Infection Occurs?**

I3mon is very common spyware among cybercriminals. They frequently deploy it to steal ID and credit card details and obtain sensitive data such as passwords. It is generally distributed via infected links, emails, or third-party platforms.

The malware may also be distributed under the guise of legitimate apps or **hidden in apps available on Google Play Store**. But it may also be manually installed on the device. It can be installed on computers and virtual servers to target cloud users.

Furthermore, the spyware is designed in JavaScript and is cloud-based. Moreover, the spyware uses a nodeJS environment and is licensed as open-source software.

VoA’s Persian language **report** claims that the malware on the devices of Iranian protestors was activated on a German server, and the data from the victim’s cellphone was transmitted outside of Iran.

**Spyware Capabilities**

If the phone is infected, it can allow attackers to access the phonebook, call logs, internet connection, microphone conversations, and SMS sent/received by the victim. In addition, it can record audio, send out location data, sub-access lists, installed apps lists, monitor typed words live, and access notification lists and mobile Wi-Fi connection details.

Spyware disguised as a fake Adobe Flash app for Android asking for administrative privileges and stealing PayPal and banking credentials (Dr.Web)

Security experts suggest users adopt preventive measures and install authentic antivirus software. If they haven’t installed **the antivirus**, it becomes essential to keep checks on battery overcharging and app accessibility features because the malware could be hidden behind an app and may cause the battery to drain quickly.

If you suspect a malware infection, run a factory reset or get the device checked by an expert.

In conclusion, this discovery raises severe concerns about the government’s use of surveillance against its own citizens. It also highlights the need for better protection for protesters and dissidents in Iran and elsewhere.

1.  **Irani and Chinese State Hackers Exploiting Log4j Vulnerability**
2.  **Iran State-Run TV’s Live Transmission Hacked by Edalate Ali Hackers**
3.  **Iranian Hackers Spread RatMilad Android Spyware Disguised as VPN**
4.  **Hackers turn to Signal, Telegram, Dark Web to assist Iranian protestors**
5.  **Iran’s COBALT MIRAGE Threat Group Behind Ransomware Attacks in US**

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Tag

#log4j