Owowa: A malicious IIS module for data theft.

- Posted in Vulnerability by

Owowa is an Microsoft web server (IIS) module currently tuned to intercept outlook web app (OWA) login requests. The exact method of how Owowa makes its way onto servers isn't yet fully known as of publishing of this post, but it is possible that it is deployed as a reconnaissance tool/sniffer during an initial attack on a network. Once it is deployed to a server it is designed to intercept login requests to the target outlook web instance and to funnel the login credentials found to whomever deployed it. This means that if your exchange server is infected, just logging into outlook to check your email can comprise your email account, give the attacker direct control of your email account, and lead to phishing campaigns by pretending to be you. Currently, Owowas targeted have reportedly been governments or government controlled entities in the asia pacific region, but that can change at any time.

Owowa currently works by monitoring HTTP requests on the infected server and responses for OWA traffic by triggering the “PreSendRequestContent” flag, this flag is suspected to be only triggered when a web application hosted by IIS is about to send content to a client application, such as an outlook client. It also verifies that the login was successful by grabbing data from authentication tokens sent as a access confirmation back to the client which contains the user login credentials, IP address and timestamp. It is suspected that the attacker can enter certain strings into the owa login pages username field on an infected server to retrieve the servers credentials log, delete said log, or use the owa login page password field to remotely execute powershell commands remotely.

The IIS "IHttpModule" is used for packet sniffing. According to Microsoft, using the string with the associated flag triggered within the IHttpModule is not recommended as it can lead to server instability/crashes. MS warning The attacker, however, is using this exploit to retrieve information despite Microsoft considering that this is not how it should be used.

Another part of the danger regarding Owowa is that without having a security regime tuned to looking for the type of traffic that Owowa sends the only real way to determine if Owowa is on your server is a manual investigation of the loaded modules in IIS. We are informed that most/all security platforms are not designed to search for vulnerabilities like Owaowa at the time of this post.

Currently talk about Owowa is just that, talk; even Kaspersky researchers, who first discovered Owowa and made its existence public, have not yet taken any protective action. In addition, there is no current discussion as to what Owaowa can be turned into, since it is a snooping tool for IIS currently tuned to steal exchange credentials, modifications to its programming likely would, and could allow it to grab any sort of data being sent to/from an IIS server. Such a vulnerability could mean that the entire IIS ecosystem is a continuous threat risk.

Part of my concern around Owowa and about how dangerous it can be, is that it has been reported that Owowa has unused empty modules within its code that could be potentially - maybe already have been - could be used to enhance its current capability.


Owowa may not yet be commonplace but the threat is significant enough that immediate action should be taken. Verification of the IIS backend, its configuration, on a regular basis. Checks should be done regularly to look for the module and remove it. It is thought that Owowa is currently a reconnaissance tool for an ongoing attack, post exploit, or information grabber for the dark web that will lead to additional exploits, phishing and scams. So proactive steps need to be implemented to assist in preventing the exploit.

Fivesys rootkit exploits Microsoft certification system

- Posted in Exploit by

Fivesys is a rootkit that has been recently discovered in the wild. A rootkit is a type of malware designed to install in the background on a target machine and are also designed to be hard to impossible to detect by normal malware scanning and remediation processes. Rootkits as a class of malware isn't new, but the viability of rootkits overall, has been reduced due to countermeasures developed to mitigate the vast majority of rootkits on the internet. The difference with this rootkit is its packaging that mimics a valid signed driver; it even has a Microsoft signed certificate.

The purpose of the Fivesys rootkit to date, is to redirect HTTP/HTTPS traffic to an attackers predefined IP addresses. The current package has a list of 300 different IPs through proxy designed to prevent blocking traffic. The package also contains a driver blacklist to prevent it being removed or overwritten with a legitimate package. It is it thought by Bitdefender, the company that made the discovery, that the primary target of Fivesys is online games, with the intent to steal game login credentials and hijack in-game transactions for payment credentials/data. As the prior statement cannot be fully verified at this time, we would like to note that re-programming of the package will likely occur resulting in Fivesys being weaponized for any number of similar attack vectors.

As I outline in my first paragraph, the major issue with Fivesys is that the creator has managed to pass the package through Microsoft's driver validation program, which we have confirmed is a fully automated signing process with no manual oversight or flag for review. This allows an actor to use the process to bypasses all of the inbuilt windows security features, leaving machines vulnerable until it is discovered.


Our recommendation to prevent Fivesys or any other rootkits from affecting your environment is to be diligent in your downloads by confirming you are on the manufacturers site. Input the url to the manufacturer manually, do not click on links, and do not use the google search to click a link to go to the download. Current exploits in AdSense and other links, advertising links to legitimate sites that are user uploaded sources, all pose a real risk to Fivesys being downloaded instead of the legitimate driver/software you are after - see our posts on the AdSense exploit. Make sure all your teams, staff and users are trained on cyber security.

FoggyWeb: Targeted NOBELIUM malware leads to persistent backdoor

- Posted in Vulnerability by

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


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.

AMD cpu security driver flawed.

- Posted in Vulnerability by

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

OMIGOD Flaw in Azure on Linux Persists Despite Microsoft Fixes

- Posted in Uncategorized by

Cybercriminals are targeting Linux-based servers running Microsoft’s Azure public cloud environment that are vulnerable to flaws after Microsoft didn’t automatically apply a patch on affected clients in its infrastructure.

Recorded Future reports that the attacks began the night of Sept. 16 after a exploit proof-of-concept was published on GitHub. It was noted that about 10 malicious bot servers have been searching the internet for vulnerable systems. In addition, Cado Security researchers in a blog post also noted a tweet from cybersecurity researcher German Fernandez, who found that the infamous DDoS Mirai botnet – known for taking advantage of insecure Internet of Things (IoT) devices – also is exploiting OMIGOD.

The flaws include CVE-2021-38647, which is a remote code execution bug, and three privileged escalation vulnerabilities: CVE-2021-8648, CVE-2021-38645 and CVE-2021-38649. Ohfeld wrote that the researchers offered a conservative estimate that thousands of Azure customers and millions of endpoints are impacted by the flaws.

“Supply chain cyber attacks have disrupted everyday life and dominated headlines this year,” he wrote. “One of the biggest challenges in preventing them is that our digital supply chain is not transparent. If you don’t know what’s hidden in the services and products you use every day, how can you manage the risk?”

OMIGOD Microsoft

Microsoft was quick to issue fixes to the four vulnerabilities in its September release of security updates, and the vulnerabilities put a spotlight on the risk to supply chains that Microsoft open-source code represents, particularly for organizations using cloud computing services since Microsoft let go its Beta testing teams and community Beta testers that used to volunteer their time.

With OMIGOD, the issue relates to the app called Open Management Infrastructure (OMI), which is embedded in many Azure services and is sponsored by Microsoft open-source OMI project in collaboration with The Open Group.

When users enable any of these popular services, OMI is silently installed on their Virtual Machine by Azure, running at the highest privileges possible. This happens without customers’ explicit consent or knowledge. Users simply click agree to log collection during setup and they have unknowingly opted in to the Microsoft application. Because Azure provides virtually no public documentation about OMI, most customers have never heard of it and are unaware that this attack surface exists in their environment.

The OMI agent operates as root (the highest privileges any users can have) and with it using a Unix socket or through an HTTP API has unlimited control. In Linux, and Unix based environments, the use of Root for any application is discouraged, and this should be the Microsoft default as well, especially when the app is exposed to internet access, but it is not the case as OMI shows. With OMI being so poorly implemented bad actors can easily gain control of the servers.

“This vulnerability can be also used by attackers to obtain initial access to a target Azure environment and then move laterally within it,” Ohfeld wrote in a technical blog. Thus, an exposed port with such access privilege's is a holy grail for malicious attackers, and with OMI, one simple exploit provides attackers with access to new targets, execute commands at the highest privileges, and possibly spread exponentially to new target machines.

Recorded Future noted that Microsoft addressed the bug by developing version of the OMI client and releasing it on GitHub, but didn’t automatically install the update on OMI clients in its infrastructure, essentially leaving tens of thousands of servers vulnerable. The company also took three days to replace the OMI client version inside its available Azure Linux VM images.

The cybersecurity firm said a query on the Shodan search engine found more than 15,600 Azure Linux servers connected to the internet, all with possible exposure, and these are just the ones known.


  1. Immediately implementing the OMI patch.
  2. Remove it if it is unneeded
  3. Check and confirm all applications exposed to the internet
  4. Scan and check all server files, access controls, ports and privilege's as well as check your user accounts and groups.

ZLoader’s Back, Abusing Google AdWords & Disabling Windows Defender

- Posted in Exploit by

A targeted campaign delivering the ZLoader banking trojan is spreading via Google AdWords, and is using a mechanism to disable all Windows Defender modules on victim machines. According to SentinelLabs, hackers are lowering rates of detection by using an infection chain for the campaign that also includes the use of a signed dropper with a backdoored version of the Windows utility wextract.exe to embed the ZLoader payload itself.

ZLoader is not new, but tis exploit addition is. It has been noted as typical a banking trojan which implements web injection to steal cookies, passwords and any sensitive information. It attacks users of financial institutions all over the world and has also been used to deliver ransomware families like Egregor and Ryuk. It also provides backdoor capabilities and acts as a generic loader to deliver other forms of malware.

ZLoader Infection Chain Starts with Google AdWords To target victims, the malware is spread from a fake Google advertisement (published through Google AdWords) for various software; the lures include Discord, Java plugins, Microsoft’s TeamViewer and Zoom.

For example, when someone Googles “Team Viewer download” a fake advert appears in AdWords (advert has already been taken down, but it does indicate that diligence is need to make sure the URL and company is correct for any downloads), an advertisement shown by Google on the search engine, that redirects the clicker to a fake TeamViewer site under the attacker’s control. From there, the user can be tricked into downloading a fake installer in a signed MSI format. Current versions have a signed timestamp of Aug. 23, but this is likely to change as it is exposed.

SentinelLabs advise that “It appears that the cybercriminals managed to obtain a valid certificate issued by Flyintellect Inc., a Software company in Brampton, Canada”; “[t]he company was registered on 29 June 2021, suggesting that the threat actor possibly registered the company for the purpose of obtaining those certificates”.

Bypassing and disabling Windows Defender check The downloaded and legitimately signed .MSI file is of course not an installer for legitimate software, but is rather the first-stage dropper for the malware. It runs an installation wizard that creates the following directory: C:Program Files (x86)Sun Technology NetworkOracle Java SE, and saves a .BAT file appropriately called “setup.bat” and then executes the built-in Windows cmd.exe function to execute that file. Users often see the flash of a cmd prompt as Microsoft often use it during windows updates, so do not suspect anything. The executed .BAT then begins stage two and downloads a second-stage dropper that initiates the third stage of infection by executing a script called “updatescript.bat”.

The third stage dropper contains logic impairment to shutdown defenses of the machine by disabling all the Windows Defender modules through the PowerShell cmdlet Set-MpPreference. It then adds exclusions, such as regsvr32, *.exe, *.dll, with the cmdlet Add-MpPreference to hide all the components of the malware from Windows Defender.

Once completed, stage four is executed with the download of the .EXE from URL (hxxxURL://pornofilmspremium.com/tim.exe) which is saved and executed through the Windows explorer.exe function.

At this point the attacker is able to break the parent/child correlation often used by endpoint detection and response (EDRs). As the The tim.exe binary is actually a backdoored version of the legitimate Windows utility wextract.exe but with the hackers additional code, hackers can now legitimately execute the malicious batch file with the name “tim.bat” that runs a short script to download the final ZLoader DLL payload, with the name tim.dll. This final payload is executed using the legitimate Windows function regsvr32, which allows the attackers to proxy the execution of the DLL through a signed binary by Microsoft and execute the functions to exploit the machine.

Tim.bat also downloads another script, called “nsudo.bat” to perform multiple operations to elevate privileges on the system and impair defenses as follows:

  1. It checks if the current context of execution is privileged by verifying the access to the SYSTEM hive.
  2. It implements an auto elevation VBScript that aims to run an elevated process in order to make system changes.

The snippet of the script in charge of the UACPrompt feature is as follows:

  echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%getadmin.vbs"
  set params = %*:"="
  echo UAC.ShellExecute "cmd.exe", "/c %~s0 %params%", "", "runas", 1 >> "%temp%getadmin.vbs"
  del "%temp%getadmin.vbs"
  exit /B
  1. Once the elevation occurs, the script is run with elevated privileges to perform the steps of disabling Windows Defender on a persistent basis by making sure that the “WinDefend” service is deleted at the next boot through the utility NSudo, and completely disables Microsoft’s User Account Control (UAC) security.

The nsudo.bat script also completely disables UAC by setting the following registry key to 0 (zero):


  1. After executing these functions it forces a system restart, so that the changes take place and users are unaware.

The purpose of the exploits is to tie the machine into the botnet for bitcoin mining and other operations including DDos attack's as the following extract of DDos URL's show:

@https://commerzbank.de @https://.de//entry* @https://.de/banking-/portal?* @https://.de/banking-/portal;* @https://.de/portal/portal @https://.de/privatkunden/ @https://.deabmelden* @https://.de/de/home @https://.de/en/home @https://.de/fi/home @https://banking.sparda.de @https://banking.sparda- @https://banking.sparda.de/wps/loggedout.jsp @https://meine.deutsche-bank.de/trxm/db* @https://banking.berliner-bank.de/trxm* @https://meine.norisbank.de/trxm/noris @https://targobank.de @https://banking4.anz.com/IBAU/BANKAWAY @https://banking.westpac.com.au/ @https://www1.my.commbank.com.au/netbank/Portfolio/Home/ @https://ibanking.stgeorge.com.au/ibank/ @https://ibanking.banksa.com.au/ibank/ @https://ibanking.bankofmelbourne.com.au/ibank/ @https://online.macquarie.com.au/ @https://ob.cua.com.au/ib/ @https://banking.bendigobank.com.au/banking @https://internetbanking.suncorpbank.com.au/ @https://www.ing.com.au/securebanking/ @https://ib.nab.com.au/ @https://online.beyondbank.com.au/ @https://ib.greater.com.au @www.independentreserve.com @www.coinspot.com.au

Google advise that if you come across any advert that redirects you should report it via the following:

https://support.google.com/google-ads/contact/vio_other_aw_policy https://safebrowsing.google.com/safebrowsing/report_phish/


  1. At all time use an adblocker software to aid in disruption of this exploit.

I realize Google will not be happy about this, but until the system is fixed from such exploits, it is better to be safe. Google should consider formal verification, not just address location verification for advertisers. Perhaps verifying and monitoring advertising URLS may also be something they should consider?

  1. Do not click on ads. Manually go to the advertisers company rather than clicking on the advert.

Again Google will be unhappy as this is their revenue source. But until its fixed, and confirmed safe, AdWords is currently just another tool in the hackers toolbox

  1. Verify the domain name and download link before clicking on a URL. Don't assume it is correct.

Spook.js - Attacking Google Chrome's Strict Site Isolation via Speculative Execution and Type Confusion

- Posted in Exploit by

What is it? Spook.js is a new transient execution side channel attack which targets the Chrome web browser. We show that despite Google's attempts to mitigate Spectre by deploying Strict Site Isolation, information extraction via malicious JavaScript code is still possible in some cases.

In more detail, Spook.js is a fresh side channel attack that works on modern hardware to overcome Google Chrome/Chromium based browsers Site Isolation Protections. The purpose of the aforementioned protections is to prevent each browser tab from being able to see each others memory/storage allocation.

The reason that this is an issue is for example if you are doing something sensitive in one tab, like managing your bank account online, and a separate tab and/or windows you have a different site open that is infected with the spook.js vulnerability. the infected page can potentially read the information from the other tab, such as your banking page.

More specifically, an attacker-controlled webpage can know which other pages from the same websites a user is currently browsing, retrieve sensitive information from these pages, and even recover login credentials (e.g., username and password), especially when they are autofilled. Further the attacker can retrieve data from Chrome extensions (such as credential managers) if a user installs/executes a malicious extension (say when accessing a website with the exploit active).

Spook.js Example code Spook.js Demo 1 - Attacking Credential Managers

The underlying vulnerability spook.js exploits though is a previously revealed and currently unresolved hardware issue with all modern CPUs dating back at least 10-15 years ago or so. All CPUs come with a task scheduler that attempts to predict what tasks to run when. if manipulated, said task scheduler can be exploited by using timed attacks on the scheduler to determine what's in memory at the time of the attack.

While this sounds scary, it just means that when browsing sites of a sensitive nature it should be the only tab open on the PC on any chromium browser as long as the sensitive site is open.

This affects all forms of chromium browsers: MS Edge, Opera, Chrome, and others using the chromium code.

Current protection may exist in: Firefox, however, great caution should be used as further testing is on going to confirm, as the advanced settings show mitigation not a fix. So we recommend that the same recommendations below should be used in Firefox also.

Web developers can protect their sites against this exploit, but it is unclear as to when everyone will update the code, and there is no way to confirm if it has been done, so it is best to protect rathe than risk.

The exploit exist on both desktop and mobile devices, so you are not protected just by using your phone.


Be sure your browser is fully patched. Then follow these rules when using any browser.

  1. Close all browsers to a clean start (as chrome stays active in the background if not fully closed, this is a must) when using anything that requires login information to your sensitive data (office file systems, banking, etc).
  2. Do not open any other tab or browser while working in the risk sensitive environment
  3. Close the browser when finished and start a fresh browser for research (being sure to close it if you need to access secure resources).
  4. Disable autofill, and remove all autofill usernames and passwords.

"BadAlloc" RTOS Integer overflow vulnerability

- Posted in Vulnerability by

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 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

Are Bitcoin miners really malware for dark web?

- Posted in Exploit by

With the loss of business due to Covid-19, cryptocurrency has had a resurgence in uptake. Offers of better mining, and group mining from legitimate organizations have seen small business jump on the opportunity to increase revenue through currency mining. Unfortunately, this has also seen an increase in activity for exploits though the mining software.

History to new activity In the past the threat was confined to crypto hijacking. Sending a malware application to the unsuspecting user, and then installing, unaware to the user, an application that would start mining - commonly called cryptojacking. This prompted increases in malware protection and protection policies, that saw the problem move to more sophisticated means through social engineering and so on.

However, with the increase in unemployed workers and business loss due to covid-19, personal computers started to be assigned to the task of crypto mining to try and get people out of difficult spots. This increase in activity did not go unnoticed, and dark web actors turned their minds to exploiting these new users through their own uptake of mining software. This was great news to the hackers, as they no longer needed to force the malware or exploits as users voluntarily downloaded it through legitimate actors.

Industry Knowledge Before I explain how it is important to note that the exploit being deployed is known in the core code, and it appears that it has been unfixed as it allows Bitcoin to increased profits, or so some of the actors who exploit the code explain. They claim that they do this to bring awareness as bitcoin is ignoring their statements to them of how it exist and what it does.

The exploit So how does it work? Its very simple really, a user engaging in mining, signs up to a group management site and downloads a software mining application so that they can mine cryptocurrency in the group, or cloud pool - a pool they add from the machines they have, or friends and do on (cudominer is one as an example). The installed mining application reports to the sever and starts the mining process for the group based on the parameters and hardware set in the management site. Simple so far, the miner then goes off and starts mining and the user can see the hashes being generated and the approximate bitcoin currency they should earn in the month.

The exploit works in a two fold manner. First it allows the dark web to see your miners IP and add it to the botnet network. An attacker can then inject set of code to exploit your machine to process mining for other users not in your group, but are reported as your group in the form of a fee, which is then record to bitcoin as a legitimate fee. This fee is delivered to the botnet manager application available for purchase on the dark web by the actor setting-up the exploit.

Exploit purchase

The second issue relates to the code continuing even after closing the application. A user may close the miner, and think, right now I can do something else and leave it be. Unknown to the user, the miner may be turned on remotely by the exploiter and grab bitcoin from your machine/pool, and you will never know as it stays under the radar by not using 100% of the processor, it only becomes noticeable when using another application needing high resources, such as gaming, as it begins to slowdown or periodically freeze. Harder to notice on higher end gaming hardware due to the speed of allocating resources as calculations which appears more as latency than cpu/gpu load. What's worse, is you pay the power bill, they get 100% of the unseen transactions. The management software never sees it occurring, but the bitcoin is calculated to the exploited application and sent to the actor exploiting the flaw which is calculated off through bitcoin as legitimate due to the setup pool design.

The software is successful because you, the installer, have approved it to bypass your defenses (Windows defender etc) at install as it reports legitimately as a signed MS application from a legitimate company who is also likely to be unaware of the exploit as it is part of the core code working as intended.

Testing We actively tested the issue above after discovering websites on the dark web that advertised the exploits for use.

In our tests we saw as follows: 1 Active exploit to a large pool of devices that allowed for the collection of 2.5 bitcoin, undermining the value of bitcoin currency. 2 Active exploit of the miner application in Windows 10 that could not be closed in the task manager. 3 On reboot, the exploited miners became active again, meaning the miner code had been lodged into the startup code of the OS.

We also express additional concerns arise as to weather this exploit could be used for other malicious purposes?

We notified cudominer of our discovery, with no response, and we have confirmed that the calculations are short the sums we calculated for load and mining allocation compared to the reported sum in cudominer manager.

Recommendations Uninstall immediately.

To uninstall 1. Reconfigure your miners default setting manually by disconnecting from the pools default, and disable startup. Check the miner manager is disabled in your startup tab under task manager. Then uninstall the software and check to confirm that the antimalware settings have been removed. Reboot and test again. 2. Reset of the antimalware back to default is also recommended, it is easier to re approve apps than have the exploit active.

If you must run If you must run the code, and we understand why you might need too, place the code on a computer that only operates this code, and make sure it is firewalled from your main network. When you have finished the mining for the period you allocated, physically shutdown and turn off the machine until you need it next.

Remember that the code exploit sends money to the botnet for any form of criminal activity, and to date Anon has advised over 100million in bitcoin has been generated to date, so run these miner managers is not recommended until this exploit is fixed.

HAProxy Integer overflow exploit

- Posted in Vulnerability by

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.

HA Proxy exploit

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.

Page 1 of 2