Massive Ransomware Campaign Targeting Unpatched Vmware ESXi Servers

From SINGCERT ( dated 04 Feb 2023

There are reports of an ongoing ransomware campaign actively exploiting a vulnerability (CVE-2021-21974) in unpatched VMware ESXi servers.

Successful exploitation of the vulnerability could allow an attacker to perform remote code execution by triggering the heap-overflow issue in OpenSLP service.

The following versions of the products are affected by the aforementioned vulnerability:

•             ESXi versions 7.x earlier than ESXi70U1c-17325551

•             ESXi versions 6.7.x earlier than ESXi670-202102401-SG

•             ESXi versions 6.5.x earlier than ESXi650-202102101-SG

Users and administrators of affected product versions are advised to upgrade to the latest versions immediately. As a precaution, a full system scan should also be performed to detect any signs of compromise. Users and administrators are also advised to assess if the ransomware campaign-targeted port 427 can be disabled without disrupting operations.

Users and administrators may also wish to configure their firewall rules to block any connections to the following IP addresses purportedly carrying out the attacks:

  • 104.152.52[.]55
  • 193.163.125[.]138
  • 43.130.10[.]173
  • 104.152.52[.]0/24

More information can be found at


Are Quantum Computers about to Break Online Privacy?

An interesting article from Scientific American. Accorfing to the article

A team of researchers in China has unveiled a technique that—theoretically—could crack the most common methods used to ensure digital privacy, using a rudimentary quantum computer.

The technique worked in a small-scale demonstration, the researchers report, but other specialists are sceptical that the procedure could be scaled up to beat ordinary computers at the task. Still, they warn that the paper, posted late last month on the arXiv repository, is a reminder of the vulnerability of online privacy.

Are Quantum Computers about to Break Online Privacy?

How to disable CBC Mode Ciphers in RHEL 8 or Rocky Linux 8

This writeup is reference from The Geek Diary

Edit /etc/sysconfig/sshd and uncomment CRYPTO_POLICY line:


Edit /etc/ssh/sshd_config file. Add Ciphers, MACs and KexAlgorithms have been added


After making changes to the configuration file, you may want to do a sanity check on the configuration file

# sshd -t

Restart sshd services

# systemctl restart sshd

To test if weak CBC Ciphers are enabled

$ ssh -vv -oCiphers=3des-cbc,aes128-cbc,aes192-cbc,aes256-cbc [youruserid@IP of your Server]


Using SSLScan to determine supported cipers

SSLScan queries SSL services to determine the ciphers that are supported. This is a very useful tool if you wish to

SSLScan is designed to be easy, lean and fast. The output includes preferred ciphers of the SSL service, and the certificate and is in text and XML formats.

The Project Site and Installation can be found at

I was checking my Windows Server,

$ sslscan --rdp x.x.x.x
Version: 2.0.15-static
OpenSSL 1.1.1t-dev  xx XXX xxxx

Connected to x.x.x.x

Testing SSL server x.x.x.x on port 3389 using SNI name x.x.x.x

SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   disabled
TLSv1.1   disabled
TLSv1.2   enabled
TLSv1.3   disabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Session renegotiation not supported

  TLS Compression:
Compression disabled

TLSv1.2 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve 25519 DHE 253

You may want to scan by port level

$ sslscan x.x.x.x:8444

High-Severity Zero-Day Bug in Google Chrome

This article is taken from Singapore Computer Emergency Response Team (SINGCERT) titled High-Severity Zero-Day Bug in Google Chrome

Google has released Chrome 99.0.4844.84 for Windows, Mac, Linux and Chrome 99.0.4844.88 for Android users to address a high-severity zero-day bug (CVE-2022-1096)The vulnerability is a Type Confusion in V8 JavaScript engine exploit, and is reported to exist in the wild. V8 is Chrome’s component that is responsible for processing JavaScript code.

Type confusion refers to coding bugs during which an application initialises data execution operations using input of a specific “type” but is tricked into treating the input as a different “type”. This leads to logical errors in the application’s memory, which may allow an attacker to run unrestricted malicious codes inside an application.

No further technical details about the bug have been published by Google.

Google Chrome users on Windows, Mac and Linux are advised to upgrade to Chrome 99.0.4844.84 immediately by going into Chrome menu > Help > About Google Chrome, while Android users may refer to the Google Play Store for Chrome 99 (99.0.4844.88) version.

High-Severity Zero-Day Bug in Google Chrome

Apache Log4j Zero-Day Vulnerability

Taken from

What is Apache Log4j Zero-Day Vulnerability?

Apache Log4j has a serious unauthenticated Remote Code Execution (RCE) vulnerability which was just disclosed. The exploit code for this has also been released, and the vulnerability is actively exploited in the wild. By crafting a special string that is passed to the application/service log via Log4j, attackers can execute arbitrary code loaded from remote servers. This can potentially lead to a complete compromise of the server.

What versions are vulnerable?

Any software using Apache Log4j (as a component) version between 2.0 and 2.14.1, inclusive.

What do I need to do?

A. Servers running custom Java application/services

  1. If your Log4j version is vulnerable, install the latest patched version log4j-2.15.0-rc2 available on GitHub at

B. Servers running Commercial off-the-shelf (COTS) products

  1. Plese refer to for a list of advisories from the major vendors and follow the advisory.

How can I check if I have been hacked/compromised?

Check your applications’ log files for strings resembling “jndi:ldap”.

For more information