Microsoft is continuing to develop solutions against the malware attack on its Office365 and Azure products. The malicious actor they coined FoggyWeb, is built on the NOBELUM codebase to create malicious sets of code that can draw from significant operational resources, including custom-built malware and tools, to attack systems and obtain credentials. The code creates a backdoor to Microsoft security and and employs multiple tactics including attaching to multiple DLL's. Once compromised an attacker pursues credential theft with the objective of gaining admin-level access to Active Directory Federation Services (AD FS) servers.

Once NOBELIUM obtains credentials and successfully compromises a server, the actor relies on that access to maintain persistence and deepen its infiltration using sophisticated malware and tools using FoggyWeb to remotely exfiltrate the configuration database of compromised AD FS servers, decrypted token-signing certificate and token-decryption certificates, as well as downloading and executing additional components.

Microsoft recommends that if you think you are compromised you should immediately:

1. Audit your on-premises and cloud infrastructure, including configuration, per-user and per-app settings, forwarding rules, and other changes the actor might have made to maintain their access
2. Remove user and app access, review configurations for each, and re-issue new, strong credentials following documented industry best practices.
3. Use a hardware security module (HSM) as described in securing AD FS servers to prevent the exfiltration of secrets by FoggyWeb.

We think you should do this anyway to be on the safe side.

Microsoft has implemented checks and balances into their security defender products and we recommend that you use these rather than third party applications from third party virus vendors. These vulnerabilities are not yet well understood by the third party vendors who are lagging behind Microsoft fixes and investigations.

Technical analysis Courtesy: Ramin Nafisi - Microsoft Threat Intelligence Center can be read here: https://www.microsoft.com/security/blog/2021/09/27/foggyweb-targeted-nobelium-malware-leads-to-persistent-backdoor/

Indicators of compromise (IOCs) For IT professionals you can test for compromise by checking the indicators below:

Type	Threat Name	Threat Type	Indicator
MD5	FoggyWeb	Loader	5d5a1b4fafaf0451151d552d8eeb73ec
SHA-1	FoggyWeb	Loader	c896ece073dd01191cbc1d462bc2f47161828a83
SHA-256	FoggyWeb	Loader	231b5517b583de102cde59630c3bf938155d17037162f663874e4662af2481b1
MD5	FoggyWeb	Backdoor (encrypted)	9ff9401315d0f7258a9fcde0cfdef02b
SHA-1	FoggyWeb	Backdoor (encrypted)	4597431f26424cb814c917168fa8d74d01ab7cd1
SHA-256	FoggyWeb	Backdoor (encrypted)	da0be762bb785085d36aec80ef1697e25fb15414514768b3bcaf798dd9c9b169
MD5	FoggyWeb	Backdoor (encrypted)	e9671d294ce41fe6dbb9637dc0157a88
SHA-1	FoggyWeb	Backdoor (encrypted)	85cfeccbb48fd9f498d24711c66e458e0a80cc90
SHA-256	FoggyWeb	Backdoor (encrypted)	568392bd815de9b677788addfc4fa4b0a5847464b9208d2093a8623bbecd81e6

Mitigations

While Microsoft continues to work on solutions and monitor the threat, the following actions are recommended:

• Customers should review their AD FS Server configuration and implement changes to secure these systems from attacks - https://docs.microsoft.com/windows-server/identity/ad-fs/deployment/best-practices-securing-ad-fs

• We strongly recommend for organizations to harden and secure AD FS deployments through the following best practices:

• Ensure only Active Directory Admins and AD FS Admins have admin rights to the AD FS system.

• Reduce local Administrators’ group membership on all AD FS servers.
• Require all cloud admins to use multi-factor authentication (MFA).
• Ensure minimal administration capability via agents.
• Limit on-network access via host firewall.
• Ensure AD FS Admins use Admin Workstations to protect their credentials.
• Place AD FS server computer objects in a top-level OU that doesn’t also host other servers.
• Ensure that all GPOs that apply to AD FS servers apply only to them and not to any other servers. This limits potential privilege escalation through GPO modification.
• Ensure that the installed certificates are protected against theft. Don’t store these on a share on the network and set a calendar reminder to ensure they get renewed before expiring (expired certificate breaks federation auth). Additionally, we recommend protecting signing keys or certificates in a hardware security module (HSM) attached to AD FS.
• Set logging to the highest level and send the AD FS (and security) logs to a SIEM to correlate with AD authentication as well as Azure AD (or similar).
• Remove unnecessary protocols and Windows features.
• Use a long (>25 characters) and complex password for the AD FS service account. We recommend using a Group Managed Service Account (gMSA) as the service account, as it removes the need for managing the service account password over time by managing it automatically.
• Update to the latest AD FS version for security and logging improvements (as always, test first).
• When federated with Azure AD follow the best practices for securing and monitoring the AD FS trust with Azure AD.

The ZeroPeril team discovered an issue with the AMD Platform Security Processor (PSP) which results in a vulnerability that opens memory allocation to exploitation. The purpose of the PSP chip is to manage the internal security of the CPU, and all internal components in a hardware driver approach that operates to control and distribute communication between the components and the CPU. The vulnerability occurs within the PSP's allocations to memory space (the systems' RAM). The team confirmed that an attacker may be able to send a request to the driver to allocate memory. If the request is for an amount of memory that is smaller than the set minimum allocation size within windows, the process will be allocated the minimum allocation. An example of what I mean by the prior statement is, if say, the memory request is for 10 bytes of memory space, and the minimum allocation size allowed by windows is 2048 bytes (2KB) then the memory request will be filled with the full 2KB of memory, when all was requested was 10 bytes.

So what does that prior assessment mean? It means that an attacker can scavenge through idle memory space, this is possible because Microsoft doesn't have a cleanup process for unallocated memory. Such memory may have been used previously for other task(s). Unallocated memory can and does store files from previously run tasks, thus leaving whatever leftover memory contents is present, available to be accessed by any other actor. This could be anything from documents accessed through an office suite, to login credentials stored in an application instance, such as credentials used for banking in a web browser.

Our recommendation is to patch as soon as possible for affected devices as AMD has released a patch named. This can be done by confirming Microsoft update has updated the AMD Chipset Driver to version 3.08.17.735.

BadAlloc is the name for a related group of RTOS (Real Time Operating System) vulnerabilities that target 25 platforms, with 23 related vulnerabilities. The result of the vulnerability being exploited varies based upon the target device/platform, but can vary from high hardware usage, limiting the operations of said affected device, to device firmware crashes and reboots. The vulnerability exploits a flaw in memory allocation within the device to achieve the above fault.

The error occurs in a range of IoT and ROT devices as well as Blackberry devices used in maritime and other government operations. A remote attacker could exploit CVE-2021-22156 to cause a denial-of-service condition or execute arbitrary code on affected devices, and in our review on the dark web, has been linked to malware designed to connect additional CPU power to bitcoin mining.

The issue was discovered in April 2021, but many devices still remain unpatched after the August 17 report at Cert USA. Many of the devices unpatched have mitigation responses that recommend to isolate the unit from the internet or simply take it offline until a patch is released or it is replaced.

Cert USA states:

• Apply available vendor updates.
• Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
• Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
• When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available.
• Also recognize VPN is only as secure as its connected devices.

We would add:

1. Replace the device if possible
2. IoT devices with this vulnerability have been linked to exploit attacks for bitcoin malware, and care should be taken to reset the device to factory defaults once secured to be absolutely sure the system is clean.

This discovery has been credited by CISA to David Atch, Omri Ben Bassat, and Tamir Ariel from Microsoft Section 52.

Here is a listing of the affected operating systems and their status:

Amazon FreeRTOS, Version 10.4.1 Update available

Apache Nuttx OS, Version 9.1.0 Update available

ARM CMSIS-RTOS2, versions prior to 2.1.3 Update in progress

ARM Mbed OS, Version 6.3.0 Update available

ARM mbed-ualloc, Version 1.3.0 no longer supported and no fix will be issued

BlackBerry QNX SDP Versions 6.5.0 SP1 and earlier Update available

BlackBerry QNX OS for Safety Versions 1.0.1 and earlier safety products compliant with IEC 61508 and/or ISO 26262 Update available

BlackBerry QNX OS for Medical Versions 1.1 and earlier safety products compliant with IEC 62304 Update available

Cesanta Software Mongoose OS, v2.17.0 Update available

eCosCentric eCosPro RTOS, Versions 2.0.1 through 4.5.3 Update available

Google Cloud IoT Device SDK, Version 1.0.2 Update available

Media Tek LinkIt SDK, versions prior to 4.6.1 Vendor will directly provide the fix, fix not available for free users

Micrium OS, Versions 5.10.1 and prior Update available

Micrium uC/OS: uC/LIB Versions 1.38.xx, Version 1.39.00 Update available

NXP MCUXpresso SDK, versions prior to 2.8.2 Update available

NXP MQX, Versions 5.1 and prior Update available

Redhat newlib, versions prior to 4.0.0 Update available

RIOT OS, Version 2020.01.1 Update available

Samsung Tizen RT RTOS, versions prior 3.0.GBB Update available

TencentOS-tiny, Version 3.1.0 Update available

Texas Instruments CC32XX, versions prior to 4.40.00.07 Update available

Texas Instruments SimpleLink MSP432E4XX Update available

Texas Instruments SimpleLink-CC13XX, versions prior to 4.40.00 Update available

Texas Instruments SimpleLink-CC26XX, versions prior to 4.40.00 Update available

Texas Instruments SimpleLink-CC32XX, versions prior to 4.10.03 Update available

Texas Instruments SimpleLink MSP432E4 No update currently planned

Uclibc-NG, versions prior to 1.0.36 Update available

Windriver VxWorks, prior to 7.0 Update in progress

Zephyr Project RTOS, versions prior to 2.5 Update available

HAProxy is a free to use server load balancing application or software addon. JFrog Security reported on September 7 2021, that a vulnerability in an Integer Overflow existed in versions 2.0 through 2.5 in the htx_add_header() and htx_add_trailer() due to a missing length check on the header name that makes it possible for an attacker to bypass all configured http-request HAProxy ACLs, and possibly other ACLs, to conduct an HTTP Request Smuggling attack. This attack allows an adversary to “smuggle” HTTP requests to the backend server, without the proxy server being aware of it.

The smuggled requests have various impacts, depending on HAProxy’s configuration and the backend web server configuration. It is reported that the execution of the vulnerability can or may:

• Bypass security controls, including any ACLs defined in HAProxy
• Gain unauthorized access to sensitive data
• Execute unauthorized commands or modifying data
• Hijack user sessions
• Exploit a reflected XSS vulnerability without user interaction

HTTP Request smuggling is based on interfering with the processing of HTTP requests between the frontend (i.e. HAProxy on a router) and the backend (being the server hosting the destination). An attacker typically exploits this technique by sending a specially crafted request that includes an additional request in its body. During a successful attack, the inner request is smuggled through the frontend, that considers it as only the request’s body, but in fact consist of an additional function hidden to the HAproxy frontend and is executed as a normal request by the backend.

In most cases, the smuggling technique is done by supplying both the Content-Length and Transfer-Encoding headers with contradicting lengths in the same request and aiming for parsing inconsistencies between the frontend and backend servers. In the original authors case, however, the attack was made possible by utilizing an integer overflow vulnerability that allowed reaching an unexpected state in HAProxy while parsing an HTTP request – specifically – in the logic that deals with Content-Length headers.

An important enabler condition that makes this class of attacks possible is that when the frontend server forwards HTTP requests to the backend, it uses the same established TCP connection instead of wasting time on opening and closing sockets. The requests are sent "back to back" and it is up to the backend server to decide where a request ends and the next one begins.

In our testing, the function can be protected against if the parse then reaches a server properly configured. However, where the server is a direct connection, ie no properly configured Apache or NGNIX, a direct Microsoft server port, then the execution is still possible.

As advised by HAProxy, the best solution is to upgrade to version 2.0.25, 2.2.17, 2.3.14 or 2.4.4 CVE-2021-40346, which provides a patch for such activity by adding size checks for the name and value lengths.

However, for security reasons HTTP traffic should by default be redirected to HTTPS, even if that needs to be done on the end server. This redirect will assist to remove the hidden execution where the patch above cannot be applied.

Recommendations If HAproxy cannot be immediately upgraded, HAProxy should have port 80 added as a https-redirect to rule "scheme https", or in the alternative, when accessing the end server, Apache or NGNIX redirect to HTTPS.

Where HAproxy cannot be upgraded at all, and a Https redirect is also not possible, due to say, vender firmware, the end server should be removed from HAProxy and the port dedicated in its connection to the end server until the hardware containing the firmware can be replaced. Even if this means web redetecting for clients.

An organization named EXPMON discovered an Office 365/2019 vulnerability on September 5th 2021. The vulnerability lies within MSHTML, which is the Microsoft Internet Explorer browser engine. The vulnerability itself is a Remote code execution (RCE) attack, allowing the attacker to remotely install malware on the target machine.

Source tweet

The exploit is performed by an attacker sending a user a modified .docx file. Said file will contain a script upon opening the document that will use the IE MSHTML engine to open the url programmed into the scripting in the .docx file.

Microsoft has recommended disabling scripts and active X execution, but we are not convinced this is enough due to the base IE11 code being left in the OS. Despite Microsoft not carrying over the IE coding from legacy Edge when they switched to the new Chromium based Edge browser, having legacy IE11 code within the OS still makes execution possible and we recommend removing the base IE11. This is, however, not a guarantee as Microsoft has not confirmed if the IE11 code exist in other parts of the OS, so the following prevention recommendations should always be followed:

Recommendation Internet Explorer 11, even if not showing on your computer, is likely still installed as a background app on your machine as Microsoft has maintained it for compatibility, it is recommended to remove it. You can do this by searching for windows features in the windows search bar. Uncheck the Internet Explorer 11 checkbox to remove "Internet Explorer" and IE11 code. Your PC should request a reboot, click reboot when prompted.

See walkthrough video here

If your business still requires use of Internet Explorer 11 for any reason, contact the developer of the program you are using to ask them to update their codebase to support modern web browsing.

It is important to remember that attachments are often insecure, and even if you have removed the above code, we continue to recommend not opening attachments unless you are absolutely sure of the source; and even then, only once you have confirmed that the source did send it.

The preferred approach is to use a sharing system such as our On The move server https://c-justice.com/odrsoftware.html available to all types of business, as one example; or other secure option instead of using attachments.

Bluetooth Classic (BT) protocol is a widely used wireless protocol in laptops, handheld devices, and audio devices. In the past few years, Bluetooth has come under scrutiny due to the discovery of several critical vulnerabilities. In this report, the authors disclose BrakTooth, a family of new security vulnerabilities in commercial BT stacks that range from denial of service (DoS) via firmware crashes and deadlocks in commodity hardware to arbitrary code execution (ACE) in certain IoTs.

As of the report date, 16 different vulnerabilities, which impact billions of devices that rely on Bluetooth Classic (BT) for communication have been uncovered. According to an academic paper from the University of Singapore, the bugs are found in the closed commercial BT stack used by at least 1,400 embedded chip components, that can lead to a host of attack types – mainly denial of service (DoS) via firmware crashes (the term “brak” is actually Norwegian for “crash”). One of the bugs can also lead to arbitrary code execution (ACE).

The team analyzed 13 pieces of BT hardware from 11 vendors; so far, there have been 20 CVEs assigned across them; with four vulnerabilities pending CVE assignments from Intel and Qualcomm. Some of the bugs are patched, others are in the process of being patched; but, researchers said in the paper, “it is highly probable that many other products (beyond the ≈1400 entries observed in Bluetooth listing) are affected by BrakTooth,” including BT system-on-chips (SoCs), BT modules or additional BT end products.

Potentially, billions of devices could be affected worldwide. BrakTooth report by Asset Group

Figure 1: An Illustration of the BT connection procedure. FHS stands for Frequency Hopping Synchronization, ID stands for Identity, LMP stands for Link Manager Protocol and ACL stands for Asynchronous Connection Less.

Figure 2: An Illustration of BrakTooth attack scenario

Figure 2 showcases the generic scenario in which BrakTooth attacks are performed. The attacker only requires (1) a cheap ESP32 development kit (ESP-WROVER-KIT [37]) with a custom (non-compliant) LMP firmware and (2) a PC to run the PoC tool. The PoC tool communicates with the ESP32 board via serial port (/dev/ttyUSB1) and launches the attacks according to the specified target BDAddress () and exploit name parameter ().

Furthermore, the PoC tool logs over-the-air (OTA) packets and checks the health of the target by getting a paging timeout (no response) or alternatively getting status directly from the target via a serial port, ssh connection, etc.

Researchers successfully forced ESP32 into erasing data housed in devices’ non-volatile random-access memory (NVRAM), which retains data without applied power. They were also able to disable both BT and Wi-Fi on the device; and most concerningly, control the general-purpose input/output (GPIO) of the device if the attacker knows addresses to attached functions-controlling actuators. GPIO is used to communicate the ON/OFF signals received from connected switches, or the digital readings received from connected sensors, to the CPU.

“This has serious implications if such an attack is applied to Bluetooth-enabled smart home products,” the researchers warned.

Second form of atatck - Laptops and devices The second attack scenario can lead to DoS in laptops and smartphones. Researchers were able to achieve this using gear containing Intel AX200 SoCs and Qualcomm WCN3990 SoCs.

One of the DoS bugs (CVE-2021-34147) exists because of a failure in the SoC to free resources upon receiving an invalid LMP_timing_accuracy_response from a connected BT device (i.e., a “slave,” according to the paper:

“The attacker can exhaust the SoC by (a) paging, (b) sending the malformed packet, and (c) disconnecting without sending LMP_detach,” researchers wrote. “These steps are repeated with a different BT address (i.e., BDAddress) until the SoC is exhausted from accepting new connections. On exhaustion, the SoC fails to recover itself and disrupts current active connections, triggering firmware crashes sporadically.”

The researchers were able to forcibly disconnect slave BT devices from Windows and Linux laptops, and cause BT headset disruptions on Pocophone F1 and Oppo Reno 5G smartphones.

A third possible attack - Audio attacks A third attack scenario was discovered while probing various BT speakers (specifically the Mi Portable Bluetooth Speaker – MDZ-36-DB, BT Headphone and BT Audio Modules) and an unbranded BT audio receiver.

They all are variously subject to a series of bugs (CVE-2021-31609 andCVE-2021-31612, failures when sending oversized LMP packets; CVE-2021-31613, truncated packets; CVE-2021-31611, starting procedures out-of-order; and CVE-2021-28135, CVE-2021-28155 and CVE-2021-31717, feature response flooding).

Successful exploits can “freeze” devices, requiring the user to manually turn on unresponsive devices afterwards. For the Xiaomi MDZ-36-DBs and JBL TUNE 500BTs, this can be done while the user is actively playing music, researchers noted.

“Although issues were found in SoCs targeted to audio products, the BT implementation can be reused in a number of SoCs destined to different BT products,” they added.

These are just a few of the possible exploit scenarios.