In Afian Filerun 20220202 Changing the "search_tika_path" variable to a custom (and previously uploaded) jar file results in remote code execution in the context of the webserver user.

CVE-2022-30470: FileRun - Selfhosted File Manager with Sharing and Backup for Photos, Docs & More

Although organizations should perform proper risk analysis and patch as soon as practical after there's a fix for this vulnerability, defenders still have options before that's released.

On May 27, 2022, researchers from Japan-based nao\_sec identified a malicious document in a commercial malware repository, dubbed "Follina," that revealed the document employed a novel technique to achieve code execution. \[Note: Read Dark Reading's earlier coverage on Follina.\] While referencing a remote object, similar to techniques like template injection, the document retrieves the following URL:

_hXXps://www.xmlformats\[.\]com/office/word/2022/wordprocessingDrawing/RDF842l.html!_

When still active, the URL hosted content that included follow-on code to execute PowerShell via an explicit call to the application "ms-msdt":

    

MSDT is a diagnostic tool included in Windows. As shown above, MSDT can be used to parse and execute code, such as PowerShell, and can be called through parsing a malicious resource. Abuse of MSDT isn't new, as the technique previously has been documented among known "living off the land" binary (LOLBins) abuse. However, its use via a URL redirection called from Microsoft Office was previously unknown, expanding scope of potential MSDT abuse to remote mechanisms.

Since initial reporting, Microsoft issued CVE-2022-30190 to cover this remote code execution (RCE) possibility within MSDT when called through another application. While a patch for this vulnerability has not yet been released, several mitigation strategies exist (covered in greater detail below).

As of this writing, actual abuse of this technique appears to be limited, but with examples dating back to as early as April 2022. Public disclosure and researcher notes identify only a few instances of malicious use of MSDT via Microsoft Office applications. However, since public identification, multiple proofs of concept for this technique emerged, and Gigamon Applied Threat Research (ATR) anticipates that multiple threat actors will soon incorporate this technique into operations.

**Impact**

At present, the impact of CVE-2022-30190 is largely notional given lack of identified widespread use by threat actors. Once this technique is absorbed into existing actor toolkits, however, circumstances will change, with the potential for use by multiple threat actors. On initial discovery, endpoint detection and response (EDR) solutions appeared largely blind to this execution mechanism, but as of this writing that is rapidly changing across multiple vendors and products. Furthermore, as explained in guidance from Microsoft, MSDT's capability to launch items as links can be disabled via changes to the Windows Registry, removing this intrusion vector (with the potential for unforeseen or undesired consequences) until a true patch is available.

More importantly, while much initial discussion focused on the Office mechanism for triggering this issue, CVE-2022-30190 is application-agnostic in functionality, which centers on passing code to MSDT for execution. While Office represents an obvious mechanism to reach this application through delivery of a document via phishing or malicious link, any mechanism of launching MSDT will work to enable follow-on RCE such as a malicious LNK file or via the implementation of "wget" in Windows. The Office route presents just one of many potential avenues for exploitation, with other possibilities of MSDT abuse publicly documented.

For defenders and end users, the risk is therefore not just a new malicious Office delivery vector but, rather, abuse of an internal Windows component (MSDT) for code execution via multiple potential vectors. As such, certain mitigations (such as stopping all child processes from Office applications) represent only partial fixes to one aspect of the problem. To appropriately determine the scope and risk of this scenario, defenders must orient how MSDT abuse, irrespective of vector, applies to adversary operations.

**Orienting to Adversary Operations**

As documented thus far, MSDT is leveraged in early phases of adversary operations as an initial access mechanism to victim machines. As noted by other researchers, MSDT abuse via Office results in follow-on execution with the same privileges as the active user. This is helpful if victims are running as unprivileged users, but given the wealth of mechanisms available to elevate privileges in Windows environments, this limitation would appear to be easily overcome by most adversaries.

However, even if an adversary can access and elevate privileges to a victim device, this specific action represents only one, relatively early step in the overall adversary life cycle, or "kill chain." Appropriately leveraging this vulnerability still requires follow-on actions, including command and control (C2) and lateral movement activity, that present options to defenders for identifying adversary operations. Furthermore, there are precursor actions to code execution via MSDT that defenders can leverage to identify suspicious behaviors leading to exploitation.

Overall, CVE-2022-30190 represents a concern, but only one of many potential avenues available to adversaries to achieve initial code execution in victim environments. By properly understanding how adversaries employ this technique and what are necessary pre- and post-exploit actions to achieve adversary objectives, defenders can begin identifying detection, response, and hunting strategies that work against multiple potential intrusion vectors.

**Detection and Mitigation Possibilities**

1.  **Focus on patching and host-based responses.** The initial security community focus for MSDT abuse mitigation focused on patching (or the inability to do so) and host-based responses. As a host-focused exploitation mechanism, such an approach appears reasonable, and patching will be the most effective way of addressing this specific security issue. Additionally, process parent-child relationship monitoring (or outright blocking) can significantly reduce attack surface by preventing entire categories of intrusion, such as Office or MSDT spawning child processes. Specifically unregistering the URI handler for MSDT in the Windows Registry, as outlined by Microsoft and security researchers, may also temporarily address the issue.
2.  **Look for pre- and post-exploitation activity.** As noted in the previous section though, defenders should strive for detections and mitigations that can apply irrespective of specific exploits by looking at required adversary actions pre- and post-exploitation. For example, in the case of CVE-2022-30190, current delivery mechanisms focus on Office implementations. Likely future implementations will probably expand to other file formats commonly distributed via email or malicious websites, such as LNK files, self-extracting archives, and optical disk images. Identifying and increasing visibility over these distribution pathways, limiting exposure to unknown or untrusted vectors, and similar actions may thus reduce attack surface against multiple types of delivery mechanisms that can be used for payloads beyond MSDT exploitation.
3.  **Identify potential C2 or lateral movement mechanisms**. Post-exploitation, various opportunities exist for identifying C2 or lateral movement mechanisms even if initial exploitation is missed. Following initial access, threat actors will in most cases need to migrate to other areas of the network: repositories of intellectual property or sensitive information, or critical network infrastructure such as domain controllers. The actions required to do so — such as enumerating Active Directory or remote process execution — present opportunities even without host monitoring to identify adversary operations.
4.  **Identify and classify network assets.** Further actions, such as identifying and (if possible) classifying newly observed network items (IP addresses and domain names) may allow for disclosure of unique C2 items. Where appropriate asset identification is enabled, identifying odd network traffic to new, unusual remote resources can further enable defenders to catch and categorize potentially malicious activity. Identifying unusual traffic based on User Agent strings when visible — such as a PowerShell-based User Agent string retrieving an executable file based on file MIME type or extension, as seen in the initial CVE-2022-30190 example — can further enhance visibility into insecure or undesirable network behaviors.

Overall, a variety of options remain available to network defenders even if the actual exploitation of a new, potentially unknown (or "zero-day") vulnerability takes place. Understanding one's own network and its characteristics combined with sufficient visibility into network and host behaviors allows defenders to ask (and answer) questions concerning activities of interest to flag the necessary preconditions and follow-on actions adhering to vulnerability exploitation. While not necessarily easy in all cases, proper investment in resources and people will allow organizations to achieve a redundant security posture capable of catching zero-day exploitation, supply chain intrusions, or state-sponsored attacks.

**Conclusion**

Software and application vulnerabilities are a continuous and ongoing problem in the information security space. CVE-2022-30190 represents just another example of such vulnerabilities that have the potential to facilitate adversary operations. While organizations should perform proper risk analysis and patch as soon as practical once there's a fix for this vulnerability, defenders are not lost prior to release.

Instead, by understanding how adversaries leverage exploits as part of the intrusion life cycle, defenders and network owners can structure detections and defense so that they are agnostic to specific vulnerabilities. Rather than continuously chasing specific weaknesses as they appear over time, such as specific defenses around CVE-2022-30190 weaponization, defenders can structure operations to look for necessary precursors to exploit development (reconnaissance, delivery) or required follow-on actions to achieve objectives (C2, lateral movement).

In building defense and response this way — focused on core behaviors and adversary dependencies — defenders can build a more sustainable security posture that can adapt to future, yet-to-be-discovered vulnerabilities along with current, known tradecraft. Through layering behavior-based detections along with patching, signatures, and other items, defenders can achieve the requisite defense-in-depth necessary to adapt to a dynamic threat environment, without relying on single-point-of-failure defenses easily evaded by capable adversaries.

Fighting Follina: Application Vulnerabilities and Detection Possibilities

Artificial intelligence technology can detect the latest wave of Trickbot ransomware and block the attack before it causes damage.

When malware strains disappear, it is often by choice of their creators and threat actors, rather than as a result of outside efforts to shut them down. The actions governments and organizations take to combat these threats directly have often proved short-term and limited in scope — a pattern that the resurrection of Trickbot last year unfortunately demonstrated.

An effort led by Microsoft and its partners to shut down Trickbot malware was conducted in the lead-up to the 2020 US election in an attempt to reduce the risk of election tampering. In the end, 94% of Trickbot's infrastructure was effectively eliminated, massively reducing its influence in late 2020.

Despite taking such substantial losses, however, Trickbot soon saw a resurrection of incredible proportions. Rather than dying off as some hoped it might, the strain grew back at such a rate that by June 2021 it had again become the most prevalent malware in the world.

One of the numerous businesses that Trickbot targeted that month was a European public administration organization. Unaware that one of its internal domain controllers had been compromised by Trickbot, the organization happened to begin a trial of Darktrace's artificial intelligence (AI)-driven cybersecurity technology, which shined a light on the malicious attack taking place within their network.

**AI Catches an Emerging Trickbot Ransomware Attack**

Darktrace employs AI-powered behavior-based detection, which can differentiate between benign and malicious activity within an organization. When the compromised domain controller began uploading DLL files to other devices, Darktrace's technology immediately detected the activity and suggested an appropriate response. However, it was configured in "human confirmation" mode — meaning it required a human operator to confirm the action.

As it waited for the human team to approve its actions, Darktrace continued to monitor the progression of the threat. It detected the compromised domain controller uploading Trickbot over SMB to almost 300 devices across the organization, and then utilizing Windows Management Instrumentation (WMI) to execute it.

Trickbot may be old and well-documented malware, but its modular nature makes it endlessly adaptable and therefore difficult for security tools to pin down. At this stage in the attack, traditional tools within the organization's network had still failed to spot the threat. When the nature of the attack changes with every new instance and modular configuration, intelligence-based security systems will always struggle to keep up.

The difficulty of relying on OSINT to address Trickbot was demonstrated in this attack when 160 of the 280 compromised devices were detected connecting to new C2 endpoints. Microsoft and its partners had specifically targeted C2 servers in 2020, but Trickbot's turnaround in the aftermath of that action showed how quickly new servers and endpoints can be established. In this case, OSINT did not associate any of the endpoints the 160 company devices connected to with malicious activity; however, Darktrace recognized the behavior as unusual nonetheless, and issued a high-severity threat notification to the organization.

For over a month, the attackers laid low. Darktrace then detected compromised devices scanning the network and downloading suspicious executable files — most likely Ryuk ransomware payloads. With several stages of the attack now months apart, it would have been hard for a human team to piece together its full scope.

**Targeted Action Before Encryption**

With AI constantly investigating threats across the entire digital environment, however, Darktrace pieced together this attack into a distinct lifecycle and presented it to the security team. It was at this stage that the organization took notice of the threat and turned Darktrace to "autonomous" mode, enabling the AI to take action.

While the automated tool can often stop ransomware attacks at the first signs of a compromise, it can engage at any stage of an attack. Thus, when it was activated at a very late stage by this organization, it still calculated a precise and effective response.

Several malicious actions were blocked by the AI, including SMB enumeration, network scanning, and suspicious outbound connections. Because it targeted these actions rather than the overall devices, the 280 compromised devices were able to continue with their normal business operations as the attack was brought to a halt.

Now that they could no longer complete command-and-control (C2) communications or move laterally, the attackers were unable to execute Ryuk and the attack came to an end. And not a moment too soon. If the attackers had been allowed to execute the ransomware, they likely would have exfiltrated and then encrypted data from across the company. Even if a ransom is paid, ransomware victims often incur numerous other costs, including network shutdowns and remediation, as well as PR fallout.

**Staying Ahead of Malware Trends**

It's clear that Trickbot is as strong and evasive as it ever was and that relying on rules or intelligence-based tools alone is no longer an option for organizations trying to avoid falling victim. Rather than waiting for companies and governments to launch offensives against the endlessly regenerating infrastructure of attackers, organizations should take matters into their own hands and bolster their own infrastructures with AI.

By recognizing how the business usually behaves, rather than worrying about identifying the attacker, Darktrace's AI can stop completely novel threats without rules or OSINT and won't be fooled by reconfigurations and rebrands. Protecting organizations against novel attacks in this way is the surefire way to start hitting Trickbot and other threat actors where it hurts.

Neutralizing Novel Trickbot Attacks With AI

Speaking at WithSecure’s annual conference, Mikko Hyppönen discussed the threat landscape between the two nations

Speaking at WithSecure’s annual conference, Mikko Hyppönen discussed the threat landscape between the two nations

Russia is failing in its mission to shake Ukraine’s cyber resilience as the country continues to successfully thwart cyber-attacks from its oppressor.

That was the takeaway from WithSecure’s Sphere conference this week, as chief research officer Mikko Hyppönen told attendees that Putin’s regime is “largely failing”.

During the event, held in Helsinki, Finland, Mikko shared insight into the conflict between the two countries, which has now been ongoing for more than three months.

Read more of the latest security news from the Ukraine conflict

Since even before its invasion of Ukraine began on February 24, 2022, Russia has conducted a series of cyber-attacks against both the country’s internet infrastructure and other critical services in an attempt to destabilize Ukraine.

Reports of cyber activity between the two states have dwindled somewhat in recent months, Hyppönen told attendees, but not due to a lack of such attacks.

Instead, says Hyppönen, the decrease in media attention is because Ukraine is successfully thwarting Russia’s cyber assaults. After all, he says, the attacks that were not successful rarely make the news.

Hyppönen said: “They’ve been trying to do things like this over and over again, so the lack of activity in offensive cyberspace that we’ve seen over the last few months is not because Russia isn’t trying – they are trying – but we aren’t seeing more activity because Ukraine is defending \[successfully\].

BACKGROUND Microsoft report unmasks at least six Russian nation-state actors responsible for cyber-attacks against Ukraine

“Ukraine has been able to defend itself both in the real world but also in the online world. In fact, I’ll claim that Ukraine is the best country in Europe to defend its networks against governmental attacks from Russia.

“Why is that? Well, it’s because they’ve been doing it for eight years. They’ve been doing it for real, over and over again.”

**‘Russia is failing’**

According to Hyppönen, Ukraine is currently experiencing three times more attacks as it was this time last year.

“Russia is trying, but it is largely failing,” he said.

His comments come as German financial regulator BaFin warned this week (May 31) that European financial markets should be on high alert following a recent increase in cyber-attacks.

In a security notice, BaFin said that a number of distributed denial-of-service (DDoS) attacks had targeted German banks and financial services.

BaFin believes that these attacks originate from Russia, which continues to suffer economic sanctions following its invasion of Ukraine.

READ MORE Ukrainian ISP used by military disrupted by ‘powerful’ cyber-attack

It’s not just Europe that is feeling the effects of this war. US military leaders confirmed to Sky News yesterday (June 1) that it has conducted “a series of operations across the full spectrum; offensive, defensive, \[and\] information operations”.

US-based Microsoft is also, Hyppönen says, for “the first time in history is taking an active stance against the war”.

Microsoft is indeed actively disrupting attacks from Russia targeting Ukraine, notably from Russian hacking group Strontium, which the company claims is a Russian GRU-connected actor it has “tracked for years”.

Hyppönen ended his talk by encouraging greater collaboration.

“Taking a stand here is really simple, it’s really obvious. I think we all choose to stand with Ukraine. We choose to stand with democracy, and we choose to stand against evil.

“During this war, we’ve again and again seen the images from the battlefield, we’ve seen Russian tanks and trucks carry the Z symbol.

“On your computer keyboard, Ctrl+Z means undo. So what we should be doing right now is to Ctrl+Z.”

YOU MAY ALSO LIKE Government agencies in Ukraine targeted in cyber-attacks deploying MicroBackdoor malware

Insight: Russia is ‘failing’ in its mission to destabilize Ukraine’s networks after a series of thwarted cyber-attacks

The cloud instances were left open to the public Internet with no authentication, allowing attackers to wipe the data.

Cyberattackers are targeting misconfigured Elasticsearch cloud buckets exposed on the public Internet and stealing the wide-open data, then replacing it with a ransom note.

According to Secureworks Counter Threat Unit (CTU) researchers, more than 1,200 indexes have already been affected, with the attackers issuing 450 requests for Bitcoin payment in exchange for the return of the data. However, the ransom amounts are relatively low, researchers have pointed out: Taken together, all of the demands total just $280,000.

"The average ransom request was approximately $620 payable to one of two Bitcoin wallets," they noted in a Wednesday analysis. "As of this publication, both wallets are empty and do not appear to have been used to transact funds related to the ransoms."

Despite the lackluster follow-through on the part of attackers thus far, the situation highlights a serious issue: Misconfiguration of databases placed in the public cloud has reached epidemic proportions, with large numbers of enterprises mistakenly leaving storage buckets from Amazon Web Services, Google Cloud, and Microsoft Azure accessible with no authentication to read or write the data.

Often, these open instances are discovered by security researchers and locked down without incident — but system misconfigurations still drove an estimated 13% of overall malicious system breaches recorded in the recent Verizon's 2022 "Data Breach Investigations Report" (DBIR), with misconfigured cloud storage instances making up the bulk of those.

"Unsecured Elasticsearch instances are trivially easy to identify using the Shodan search engine," the CTU researchers noted. "The threat actor probably used an automated script to identify the vulnerable databases, wipe the data, and drop the ransom note."

They added, "the cost of storing data from 1,200 databases would be prohibitively expensive. It is therefore likely that the data was not backed up and that paying the ransom would not restore it."

In 2020, ESET researchers uncovered a similar attack that affected half of all exposed MongoDB instances, which were wiped and replaced with a ransom note.

12K Misconfigured Elasticsearch Buckets Ravaged by Extortionists

Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution Vulnerability.

CVE-2022-30190

Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-30127.

CVE-2022-30128

Microsoft Edge (Chromium-based) Spoofing Vulnerability.

CVE-2022-26905

Microsoft Edge (Chromium-based) Elevation of Privilege Vulnerability. This CVE ID is unique from CVE-2022-30128.

CVE-2022-30127

During an **X25519** key exchange, the client’s private is generated with [**System.Random**](https://docs.microsoft.com/en-us/dotnet/api/system.random):

```cs
var rnd = new Random();
_privateKey = new byte[MontgomeryCurve25519.PrivateKeySizeInBytes];
rnd.NextBytes(_privateKey);
```

Source: [KeyExchangeECCurve25519.cs](https://github.com/sshnet/SSH.NET/blob/bc99ada7da3f05f50d9379f2644941d91d5bf05a/src/Renci.SshNet/Security/KeyExchangeECCurve25519.cs#L51)  
Source commit: https://github.com/sshnet/SSH.NET/commit/b58a11c0da55da1f5bad46faad2e9b71b7cb35b3

[**System.Random**](https://docs.microsoft.com/en-us/dotnet/api/system.random) is not a cryptographically secure random number generator, it must therefore not be used for cryptographic purposes.

### Impact
When establishing an SSH connection to a remote host, during the X25519 key exchange, the private key is generated with
a weak random number generator whose seed can be bruteforced. This allows an attacker able to eavesdrop the
communications to decrypt them.

### Workarounds
To ensure you're not affected by this vulnerability, you can disable support for `curve25519-sha256` and `curve25519-sha256@libssh.org` key exchange algorithms by invoking the following method before a connection is established:
```cs
private static void RemoveUnsecureKEX(BaseClient client)
{
    client.ConnectionInfo.KeyExchangeAlgorithms.Remove("curve25519-sha256");
    client.ConnectionInfo.KeyExchangeAlgorithms.Remove("curve25519-sha256@libssh.org");
}
```

### Thanks

This issue was initially reported by **Siemens AG, Digital Industries**, shortly followed by @yaumn-synacktiv.

During an **X25519** key exchange, the client’s private is generated with **System.Random**:

var rnd \= new Random();
\_privateKey \= new byte\[MontgomeryCurve25519.PrivateKeySizeInBytes\];
rnd.NextBytes(\_privateKey);

Source: KeyExchangeECCurve25519.cs  
Source commit: sshnet/SSH.NET@b58a11c

**System.Random** is not a cryptographically secure random number generator, it must therefore not be used for cryptographic purposes.

**Impact**

When establishing an SSH connection to a remote host, during the X25519 key exchange, the private key is generated with  
a weak random number generator whose seed can be bruteforced. This allows an attacker able to eavesdrop the  
communications to decrypt them.

**Workarounds**

To ensure you're not affected by this vulnerability, you can disable support for curve25519-sha256 and curve25519-sha256@libssh.org key exchange algorithms by invoking the following method before a connection is established:

private static void RemoveUnsecureKEX(BaseClient client)
{
    client.ConnectionInfo.KeyExchangeAlgorithms.Remove("curve25519-sha256");
    client.ConnectionInfo.KeyExchangeAlgorithms.Remove("curve25519-sha256@libssh.org");
}

**Thanks**

This issue was initially reported by **Siemens AG, Digital Industries**, shortly followed by @yaumn-synacktiv.

**References**

*   GHSA-72p8-v4hg-v45p
*   https://nvd.nist.gov/vuln/detail/CVE-2022-29245
*   sshnet/SSH.NET@03c6d60
*   sshnet/SSH.NET@f1f273c
*   https://github.com/sshnet/SSH.NET/blob/bc99ada7da3f05f50d9379f2644941d91d5bf05a/src/Renci.SshNet/Security/KeyExchangeECCurve25519.cs#L51
*   https://github.com/sshnet/SSH.NET/releases/tag/2020.0.2

Tag

#microsoft