This is default featured slide 1 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 2 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 3 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured slide 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Log4JShell Used to Swarm VMware Servers with Miners, Backdoors

 

Description

What researchers are calling a “horde” of miner bots and backdoors are using the Log4Shell bug to take over vulnerable VMware Horizon servers, with threat actors still actively waging some attacks.

On Tuesday, Sophos reported that the remote code execution (RCE) Log4j vulnerability in the ubiquitous Java logging library is under active attack, “particularly among cryptocurrency mining bots.” Besides cryptominers, attackers are also prying open Log4Shell to deliver backdoors that Sophos believes are initial access brokers (IABs) that could lay the groundwork for later ransomware infections.

History of Log4Shell Nightmare-ware

The Log4j flaw was discovered in December, vigorously attacked within hours of its discovery and subsequently dubbed Log4Shell. Sophos’s findings about VMware Horizon servers being besieged by threat actors leveraging the bug is in keeping with what’s been happening since then: In fact, cyberattacks increased 50 percent YoY in 2021, peaking in December, due to a frenzy of Log4j exploits.

With millions of Log4j-targeted attacks clocking in per hour since the flaw’s discovery, within just a few weeks, there was a record-breaking peak of 925 cyberattacks per week per organization, globally, as Check Point Research (CPR) reported in early January.

Log4Shell has been a nightmare for organizations to hunt down and remediate, given that the flaw affected hundreds of software products, “making it difficult for some organizations to assess their exposure,” noted Sophos researchers Gabor Szappanos and Sean Gallagher in Tuesday’s report. In other words, some outfits don’t necessarily know if they’re vulnerable.

Why Attackers Have Zeroed in on Horizon

In particular, those attacks have included ones targeting vulnerable VMware Horizon servers: a platform that serves up virtual desktops and apps across the hybrid cloud. These servers have been important tools in organizations’ arsenals over the past few years, given that the pandemic triggered the necessity to provide work-from-home tools, the researchers pointed out.

Although VMware released patched versions of Horizon earlier this month – on March 8 – many organizations may not have been able to deploy the patched version or apply workarounds, if they even know that they’re vulnerable to begin with.

“Attempts to compromise Horizon servers are among the more targeted exploits of Log4Shell vulnerabilities because of their nature,” Sophos said.

Even those organizations that have applied the patches or workarounds may have been already compromised in other ways, given the backdoors and reverse-shell activity Sophos has tracked, the researchers cautioned.

In late December and January, VMWare’s Horizon servers with Log4Shell vulnerabilities came under Cobalt Strike attack, as flagged by researchers at Huntress. Other attacks included those that installed web shells.

Those attacks used the Lightweight Directory Access Protocol (LDAP) resource call of Log4j to retrieve a malicious Java class file that modified existing, legitimate Java code, injecting a web shell into the VM Blast Secure Gateway service and thereby granting attackers remote access and code execution. Sophos has seen these attacks show up in customer telemetry since the beginning of January, the researchers said.

The attacks against Horizon servers grew throughout January. Beyond attempts to deploy cryptocurrency-mining malware, other attacks were potentially designed either to grant threat actors initial access or to infect targets with ransomware, Sophos said. Such attacks have continued into this month: the security firm shared a bar chart, shown below, that shows the ebb and flow of the attacks that have bled into mid-March.

VMware Horizon server attacks since the beginning of January. Source: Sophos.

“The largest wave of Log4J attacks aimed at Horizon that we have detected began January 19, and is still ongoing,” the researchers said.

But this wave hasn’t relied on the use of one of cybercrooks’ favorite tools, Cobalt Strike: a commercial penetration-testing tool that can be used to deploy beacons on systems in order to simulate attacks and test network defenses.

Rather, “the cryptominer installer script is directly executed from the Apache Tomcat component of the Horizon server,” Sophos said, with the most frequently used server in the campaigns being 80.71.158.96.

The Payloads

Sophos found a slew of miners being dumped on targeted Horizon servers, including z0Miner, the JavaX miner and at least two variants – the Jin and Mimu cryptocurrency miner bots – of the XMRig commercial cryptominer,. Speaking of which, Uptycs reported in January that cryptojackers had figured out how to inject XMRig into VMware’s vSphere services, undetected. For its part, back in September 2021, Trend Micro found that z0Miner operators were exploiting the Atlassian Confluence RCE (CVE-2021-26084) for cryptojacking attacks.

Sophos also found several backdoors, including several legitimate testing tools. One such was implants of Sliver: a tool used by red teams and penetration testers to emulate adversarial tactics. Sliver showed up as a precursor to the Jin miner in all the cases where Sophos was able to investigate further, leading the researchers to suspect that it’s actually the payload. Either that, or maybe the actor behind Sliver might be a ransomware gang, the researchers hypothesized, given that the same servers deploying Sliver also hosted files to deliver the Atera agent as a payload.

Atera is another common, legitimate remote monitoring and management tool. However, the threat actors aren’t attacking existing Atera installations, per se, the researchers said. Rather, “they install their own Atera agents in order to use the Atera cloud management infrastructure to deploy additional payloads in the future,” they explained.

Sophos also found the legitimate Splashtop Streamer remote-access tool being downloaded and installed on infected systems, “probably as an automated task for the new clients.”

As well, there were several PowerShell-based reverse shells in the payload mix that had been dropped by the Log4Shell exploits.

Two Types of Reverse Shells

Sophos found two types of reverse shell: one, a shorter script that opens a socket connection to a remote server and executes the received buffer, which is supposed to be a PowerShell command.

They also found a larger variant of a reverse shell: one that can reflectively load a Windows binary, with the loader as an encrypted and base64 encoded blob, as depicted below:

Base64 encoded blob. Source: Sophos.

Sophos telemetry showed that while z0Miner, JavaX and some other payloads were downloaded directly by the web shells that had been used for initial compromise, the Jin bots were tied to use of Sliver and used the same wallets as Mimo, “suggesting these three malware were used by the same actor,” Sophos said. Researchers believe that Jin is, in fact, “simply a rebranded version of Mimo.”

Loads of New Malware Loaders

New malware loaders are springing up like dandelions in the spring. Besides the ones covered by Sophos in Tuesday’s report, security researchers at Symantec today also published a technical report on a new malware loader tracked as Verblecon that’s escaped detection due to the polymorphic nature of its code.

Verblecon has likewise been seen in attacks that install cryptocurrency miners on compromised machines.

Saryu Nayyar, CEO and founder of Gurucul, told Threatpost that in order to fight the legitimate assessment tools being used to breach organizations, it’s also “critical” to employ sophisticated technologies – namely, self-training machine learning and behavioral models – to sniff out exploitation of exposed vulnerabilities as well as to detect the remote surveillance done by attackers with tools such as Cobalt Strike, et al.

“Current [extended detection and response, or XDR] and traditional [security information and event management, or SIEM] solutions, even with claims of User Entity Behavior Analytics rooted in known patterns and rule-based artificial intelligence, are unable to adapt to these methods,” she told Threatpost via email. “Organizations need to invest in solutions that employ transparent non rule-based machine learning models to more rapidly identify new attacks.”

Chris Olson, CEO of digital safety platform The Media Trust, told Threatpost on Tuesday that polymorphic techniques “are just another way to hide malicious intentions, along with checks for security tools and live environments.”

This attack provides another example of how the risks of Web 2.0 are being replicated in Web 3.0, he said via email.

“Today’s embryonic beginnings of Web 3.0 are eerily reminiscent of the Web as it existed in the 1990s, showing sporadic signs of vulnerability that may well foreshadow a future era of cyber chaos,” Olson said.

To prevent that from happening, we must learn from our past mistakes, he warned. “Today’s digital ecosystem is riddled with threats because Web 2.0 was not designed for cybersecurity from the outset. Untrusted third parties were allowed to proliferate, leading to phishing attacks, malicious advertising, rampant data privacy abuse and other threats that are hard to fix in the present. With Web 3.0, we have a chance to account for potential attack vectors by design – otherwise, the same issues will replicate themselves with greater potency than ever.”

Muhstik Botnet Targeting Redis Servers Using Recently Disclosed Vulnerability

 

Description

Muhstik, a botnet infamous for propagating via web application exploits, has been observed targeting Redis servers using a recently disclosed vulnerability in the database system.

The vulnerability relates to CVE-2022-0543, a Lua sandbox escape flaw in the open-source, in-memory, key-value data store that could be abused to achieve remote code execution on the underlying machine. The vulnerability is rated 10 out of 10 for severity.

“Due to a packaging issue, a remote attacker with the ability to execute arbitrary Lua scripts could possibly escape the Lua sandbox and execute arbitrary code on the host,” Ubuntu noted in an advisory released last month.

According to telemetry data gathered by Juniper Threat Labs, the attacks leveraging the new flaw are said to have commenced on March 11, 2022, leading to the retrieval of a malicious shell script (“russia.sh”) from a remote server, which is then utilized to fetch and execute the botnet binaries from another server.

First documented by Chinese security firm Netlab 360, Muhstik is known to be active since March 2018 and is monetized for carrying out coin mining activities and staging distributed denial-of-service (DDoS) attacks.

Capable of self-propagating on Linux and IoT devices like GPON home router, DD-WRT router, and Tomato routers, Muhstik has been spotted weaponizing a number of flaws over the years –

  • CVE-2017-10271 (CVSS score: 7.5) – An input validation vulnerability in the Oracle WebLogic Server component of Oracle Fusion Middleware
  • CVE-2018-7600 (CVSS score: 9.8) – Drupal remote code execution vulnerability
  • CVE-2019-2725 (CVSS score: 9.8) – Oracle WebLogic Server remote code execution vulnerability
  • CVE-2021-26084 (CVSS score: 9.8) – An OGNL (Object-Graph Navigation Language) injection flaw in Atlassian Confluence, and
  • CVE-2021-44228 (CVSS score: 10.0) – Apache Log4j remote code execution vulnerability (aka Log4Shell)

“This bot connects to an IRC server to receive commands which include the following: download files, shell commands, flood attacks, [and] SSH brute force,” Juniper Threat Labs researchers said in a report published last week.

In light of active exploitation of the critical security flaw, users are highly recommended to move quickly to patch their Redis services to the latest version.

CVE-2022-0847: Arbitrary File Overwrite Vulnerability in Linux Kernel

 

Description

CVEDisclosureAttackerKBIVM ContentPatching UrgencyBlog’s Last Update
CVE-2022-0847Original disclosureAttackerKBMarch 10, 2022When practicalMarch 10, 2022 3:21 PM EST

CVE-2022-0847: Arbitrary File Overwrite Vulnerability in Linux Kernel

On March 7, 2022, CM4all security researcher Max Kellermann published technical details on CVE-2022-0847, an arbitrary file overwrite vulnerability in versions 5.8+ of the Linux kernel. Nicknamed “Dirty Pipe,” the vulnerability arises from incorrect Unix pipe handling, where unprivileged processes can corrupt read-only files. Successful exploitation allows local attackers to escalate privileges by modifying or overwriting typically inaccessible files — potentially including root passwords and SUID binaries.

CVE-2022-0847 affects Linux kernel versions since 5.8. Read Rapid7’s full technical analysis of the vulnerability in AttackerKB, including PoC and patch analysis.

While CVSS is not yet available, CVE-2022-0847 will likely carry a “High” severity rating rather than a “Critical” one given the authentication requirement. Multiple public exploits are available, including a proof of concept from the original disclosure and a Metasploit module. We are not aware of any reports of exploitation in the wild as of March 9, 2022.

This is a “patch, but no need to panic” situation. With that said, a few factors make this bug stand out a bit more than the average local privilege escalation (LPE) vuln. First and foremost, this is a simple attack to execute once initial access has been obtained, and it offers adversaries broad avenues for privileged operations after sensitive files (like root passwords) have been modified. Security researchers have also demonstrated that in some cases, public exploit code can be used to escape containers in that files modified inside the container also get modified on the host. Finally, the lingering specter of Log4Shell means that there may be a higher chance that attackers already have local access required to execute a privilege escalation attack on Linux systems.

Updates to Linux distributions have been trickling out. Organizations should apply the latest patches as soon as they are available and reboot systems.

Rapid7 customers

The March 10 content release for InsightVM and Nexpose includes checks for CVE-2022-0847 for Debian, Ubuntu, and SUSE. Coverage for Amazon Linux, Red Hat Linux, and CentOS Linux is available in the March 11 content update.

NEVER MISS A BLOG

InsightVM Scan Engine: Understanding MAC Address Discovery

 

Description

InsightVM Scan Engine: Understanding MAC Address Discovery

Written in collaboration with Jimmy Cancilla

When scanning an asset, one key piece of data that the InsightVM Scan Engine collects is the MAC address of the network interface used during the connection. The MAC address is one of several attributes used by the Security Console to perform asset correlation. As a result of the volatile nature of IP addresses, identifying assets using the MAC address can provide increased reliability when integrating scan results. In some cases, the MAC address can be used as a rudimentary means of fingerprinting an asset. Several manufacturers will use the same first 3 bytes when assigning a MAC address to a device (for example, several CISCO SYSTEMS, INC devices use 00000C as the MAC address prefix).

When performing an authenticated scan (a scan whereby the engine has the necessary credentials to authenticate to the target), collecting the MAC address is relatively straightforward, as all operating systems provide tooling to gather this information. However, collecting the MAC address with an unauthenticated scan (a scan where no credentials are provided) is less reliable. This is due to limitations of network protocols and modern network topologies.

Breaking down IP protocols

In order to understand these limitations, it is important to first understand the fundamentals of the IP protocol suite.

The IP protocol suite can be thought of in 4 layers:

InsightVM Scan Engine: Understanding MAC Address Discovery

The MAC address is part of the bottom layer called the Link Layer. The MAC address is used by the hardware when communicating with other devices on the same network equipment. Any devices communicating at the Link layer do so without the use of routers.

On the other hand, IP addresses are part of the Network layer. IP addresses are used to communicate with devices across different networks, traversing through routers.

MAC address discovery with unauthenticated scans

This leads to the limitation in unauthenticated scans. When performing an unauthenticated scan against assets that are accessed via a router, the scan engine is only able to communicate with that asset via the Network layer. The implications of this are that the MAC address is not included in the network packets received by the scan engine. This is not a limitation or defect of the scan engine, but rather a reality of the IP protocol suite and modern network infrastructure.

To work around these limitations in the IP protocol suite, the InsightVM scan engine uses several alternative methods to attempt to collect the MAC address of assets being scanned. In general, these alternative methods attempt to authenticate to an asset over various protocols using known default credentials. As a result of this capability in the scan engine, asset results from unauthenticated scans may include the MAC address despite being scanned over a router. However, it is important to note that the success rate is dependent on whether assets are configured to allow authentication using default credentials.

****Note:SNMPv1 and SNMPv2 are more likely than most protocols to be configured with known default credentials.

Summary

The following tables outline the different methods that the scan engine will use to collect MAC addresses from targets, and whether or not authentication is required.

Windows

MethodAuthenticated or unauthenticated scan
via SMB protocolAuthenticated
via WMI protocolAuthenticated
Scan AssistantAuthenticated
SNMPv1 or SNMPv2Authenticated or unauthenticated

Note: Collecting the MAC address via SNMPv1 or SNMPv2 with an unauthenticated scan is only possible if the scan engine can authenticate using the default credentials for these protocols. However, it is not recommended that default credentials be left enabled as this poses a serious security risk.

Linux

MethodAuthenticated or unauthenticated scan
Via SSH protocolAuthenticated
Via an insecure Telnet protocolAuthenticated

Note: Running an insecure Telnet server on an asset is a serious security risk and is not recommended.
SNMPv1 or SNMPv2 | Authenticated or unauthenticated

Note: Collecting the MAC address via SNMPv1 or SNMPv2 with an unauthenticated scan is only possible if the scan engine can authenticate using the default credentials for these protocols. However, it is not recommended that default credentials be left enabled as this poses a serious security risk.

Over the years, the engineering team here at Rapid7 has partnered with dozens of security teams to identify pain points and develop solutions. The importance of collecting the MAC address for targets being scanned is well understood. As a result, the InsightVM Scan Engine has been designed to utilize a multi-pronged approach to collecting MAC addresses from assets.

[Security Nation] Matthew Kienow on Open-Source Security and the Recog Framework

 

Description

[Security Nation] Matthew Kienow on Open-Source Security and the Recog Framework

In this episode of Security Nation, Jen and Tod chat with Matthew Kienow, Senior Software Engineer at Rapid7, about open-source security – a subject he knows a thing or two about from his work on Metasploit, AttackerKB, and most recently the Recog recognition framework. They discuss the selling points and drawbacks of open source, why seeing all the code doesn’t mean you can see all the bugs, and how open-source projects like Recog make the digital world a better place.

Stick around for our Rapid Rundown, where Matthew sticks around to chat with Tod and Jen about a worrying trend in DDoS attacks that allows for amplification levels of 65x.

Matthew Kienow

[Security Nation] Matthew Kienow on Open-Source Security and the Recog Framework

Matthew Kienow is a software engineer and security researcher. Matthew is currently responsible for the Recog recognition framework project at Rapid7 and previously worked on the AttackerKB project, as well as Metasploit’s MSF 5 APIs. He has also designed, built, and successfully deployed many secure software solutions; however, often he enjoys breaking them instead. He has presented his research at various security conferences including DerbyCon, Hack In Paris, and CarolinaCon. His research has been cited by CSO, Threatpost, and SC Magazine.

Show notes

Interview links

Rapid Rundown links

Like the show? Want to keep Jen and Tod in the podcasting business? Feel free to rate and review with your favorite podcast purveyor, like Apple Podcasts.

InsightAppSec GitHub Integration Keeps Risky Code From Reaching Production

 

Description

InsightAppSec GitHub Integration Keeps Risky Code From Reaching Production

We’ve all been there. The software development life cycle (SDLC) is moving at a mile a minute. Developers are writing code, updating features, and all the while attempting to keep everything introduced into production as safe and secure as possible. GitHub Actions are essential to automation and allow you to build, test, and deploy your code right from GitHub, faster than ever.

But it comes with risks.

How can you be sure your running applications aren’t vulnerable to exploitation? How will we know it’s problematic before it gets into production? Can we realistically perform kick-off, test, and provide feedback to development not using automation?

Secure apps through automation

A DevSecOps mindset is needed, with security baked into the SDLC — and now, GitHub Actions makes this easier than ever. This new integration — offered completely free to InsightAppSec customers — allows security and development teams to automate dynamic application security testing (DAST) as part of the CI/CD build pipeline workflow. For example, you can easily configure the integration to scan your team’s work for vulnerabilities, and if high-severity vulnerabilities are found, you can have it notify and/or block risky code before it reaches production environments.

Here’s how it works:

InsightAppSec GitHub Integration Keeps Risky Code From Reaching Production

All this happens automatically, so your team isn’t spending time finding and communicating application risk — they’re focusing on building a great application security program.

That’s not where the benefits end, however.

****1)********It helps integrate DevOps into the Security workflow:**** In order to help build a Dev SecOps mindset across teams, this integration allows DevOps and Security teams to work together earlier in the lifecycle, improving cross-team outcomes and making your organization safer.

****2)********Automate DAST as part of your CI/CD workflow:**** This integration fits in seamlessly with what you’re already doing, and automatically provides the vulnerability information your teams need to stay aware of risk and keep unsafe code out of your prod environments.

****3) Quick and easy setup:**** Simply add the IAS Scan steps to your build pipeline as defined in the insightappsec-scan-github-action repo (assuming you have valid Github and InsightAppSec licenses).

And it is all for free. We’re continuously working to make InsightAppSec the easiest and most powerful security platform for your web applications and teaming with Github will supercharge your development lifecycle in the safest way possible, automatically.

Ukraine-Russia Cyber Warzone Splits Cyber Underground

 

Description

The Russia-Ukraine cyber warzone has split the Conti ransomware gang into warring factions, leading to a Ukrainian member spilling 60,000 of the group’s internal chat messages online.

On Monday, vx-underground – an internet collection of malware source code, samples and papers that’s generally considered to be a benign entity – shared on Twitter a message from a Conti member saying that “This is a friendly heads-up that the Conti gang has just lost all their sh•t.”

The gang has also, apparently, lost a cache of chat data: the first dump of what the poster promised would be multiple, “very interesting” leaks coming from Conti’s Jabber/XMPP server.

“F•ck the Russian government, Glory to Ukraine!” the Conti member, who’s reportedly believed to be Ukrainian, proclaimed. Threatpost advises caution about clicking on any links provided in social media messages: They are, after all, provided by a ransomware group and should be treated with kid gloves.

Conti ransomware group previously put out a message siding with the Russian government.

Today a Conti member has begun leaking data with the message “Fuck the Russian government, Glory to Ukraine!”

You can download the leaked Conti data here: https://t.co/BDzHQU5mgw pic.twitter.com/AL7BXnihza

— vx-underground (@vxunderground) February 27, 2022

Cisco Talos’ Azim Khodjibaev said on Sunday verified that the dump does in fact contain conversations between affiliates, administrators and admins, rendered on Jabber instant-messaging accounts.

looks like the #conti leaks of 2022 are indeed chat logs from jabber accounts between affiliates, administrators and admins. Rejoice CTI analysts and data scientists, it is in json form! #busymonday pic.twitter.com/DiyqNoymsD

— Azim Khodjibaev (@AShukuhi) February 27, 2022

The conversations date back 13 months, from Jan. 29, 2021 to yesterday, Feb. 27 2022.

The first dump contains 339 JSON files, with each file representing a full day’s log. Cybersecurity firm IntelligenceX has posted the spilled conversations here. Many of the messages are written in a Cyrillic-scripted language that appears, at least according to Google translate, to be Russian.

The Perhaps-Less-Than-100% Russian Conti

Conti, a Russia-based extortionist gang, is considered to be as ruthless as it is sophisticated: It was the first professional-grade ransomware group to weaponize Log4j2.

On Friday, Conti sided with Russia, pledging “full support” for President Vladimir Putin’s invasion of Ukraine.

“WARNING,” Conti blared on its blog, threatening to use its “full capacity” to retaliate in the face of “Western warmongers attempt to target critical infrastructure in Russia or any Russian-speaking region of the world.”

Conti blog pledge to support Russia’s invasion of Ukraine. Source: Conti blog.

Cyberattacks Coming at and From Russia

The split-Conti story is just one of a myriad of cybersecurity headlines coming out of the siege of Ukraine. Some other events in the cyberwar that are rocking the security world:

Russia appears to deploy digital defenses after DDoS attacks

Anonymous Declares ‘Cyberwar’ on Russia and Pledges Support for Ukraine

Anonymous breached the internal network of Belarusian railways

Ukraine: Volunteer IT Army is going to hit tens of Russian targets from this list

Richard Fleeman, vice president of penetration testing ops at cybersecurity advisory services provider Coalfire, told Threatpost on Monday that collective groups such as Anonymous claim to be hacktivists, meaning they don’t attack for personal gain, but rather that they seek to spread their ideology and wage cyberwarfare against those that don’t align.

“These kinds of activities ebb and flow based on geopolitical events or collective objectives of these groups,” he said. This isn’t new, but they’ll likely escalate “amidst the global chaos to target various countries, government agencies, and corporations.”

“These groups thrive on sentiment and will likely continue to build momentum based on their objectives,” Fleeman observed.

The muddle of war can also obscure false flag or false information campaigns that target, influence or mislead others, he said. “This can be accomplished in a variety of ways, for example, China compromising Russian technology and targeting other nations through the compromised infrastructure to hide the origins of their attacks or embedding Russian language or terms into source code of malware would aid in the hiding [of] the true origin.”

He urged that situational awareness be elevated and that security teams “be vigilant, remain alert, and leverage their security mechanisms in place to identify threats and mitigate them in a fluid manner.”

The Lure of War to Cyber Actors

Casey Ellis, founder and CTO at crowdsourced cybersecurity provider Bugcrowd, told Threatpost on Monday that the bloodless nature of cyber combat makes it tough to predict who’ll enter this conflict and how.

“The fact that a lot of unrelated but concerned actors have entered the conflict is unsurprising,” he noted via email. “Anonymous, for example, is well-known for having a principled position on topics and then acting or retaliating via the Internet.”

His primary concern: “the relative difficulty of attribution in cyberattacks, as well as the possibility of incorrect attribution or even an intentional false flag operation escalating the conflict internationally.”

Russia will likely avoid provoking the United States “until it’s tactically or strategically advantageous for them to do so, which we all hope we can avoid,” he noted. Last week, the White House denied considering plans to launch massive cyberattacks against Russia in order to cut off its ability to pursue its military aggression – denials made in spite of NBC News quoting multiple sources to the contrary.

“Having said that, the backdrop of conflict and the openness of the Internet provide greater than normal levels of’”aircover’ and background noise for cybercriminals, as well as other nation-states looking to plant a false flag,” Ellis said.

John Bambenek, principal threat hunter at digital IT and security operations company Netenrich, told Threatpost via email that it’s the wild west out there: Traditional actors are using sabotage and DDoS related to military objectives, he observed, while others “will use the fog of war (quite literally) to take advantage. No one has to commit front line infantry if they want to take advantage anymore,” he said.

Expect a pig pile, he predicted: “Usually for conflicts in that region, other non-state regional actors will engage, either due to patriotism or opportunism. Now that more nations are developing this capability, more are coming to play. And there is no better training ground for nation-state actors than playing in an active warzone.”

What does that mean for security teams in the United States and other western countries? It depends on what the West does, he said. “If we get involved militarily, then the scope of attacks will increase to those nations as well. If it is targeted sanctions, likely attacks will focus on those in the chain of enforcement.”