RURansom is the name of a new strain of malware called a wiper, which shares some characteristics with ransomware but is designed to be destructive immediately, rather than demand a ransom for decryption. This means that if any wiper malware gets onto a system, data loss is assured.

RURansom surfaced on the internet as early as March 1st 2022. There has been no mention yet of an attack vector. Deliver of the payload to the victim network and devices is not yet fully known. It is likely though, that standard deployment method would apply; such as email attachments, hyperlinks, Java exploits, and others generally accepted vectors. It is known that the malware uses a geolocation string to verify that the target network as it is currently focused on Russia. Below is the code for the geolocation scripting in a screenshot for reference.

Once the malware is executed on a target machine, it first attempts to run as admin; if it fails, it attempts to run in an elevated permissions mode using the following PowerShell command:

cmd.exe /c powershell stART-PRoceSS Assembly.GetExecutingAssembly().Location  -veRB rUnAS

Drives connected as Local, removable and/or network drives on the victim PC are scanned and then added to the encryption process leaving all files with a randomized on a per file basis with a unique AES cipher. No decrypt key is generated, and .Bak files are deleted upon detection in this phase, making this a pure malicious malware. The malware file then renames itself as Россия-Украина_Война-Обновление.doc.exe (Russia-Ukraine_War-Update.doc.exe) and then proceeds to attack any other systems connected to the initial victims device or network. Below is the code example used to generate the AES cipher for the encryption:

Thoughts and Recommendations

While RURansom on the surface appears to be localized, we suspect it is only time before its application is more wide spread. As RURansom becomes more well known in its design, it is only a matter of time, we think before, another attacker changes the target geodata, among other changes, and launches teh malware more global.

It is prudent that standard recommendations for social engineering, ransomware protection, and other cyber security should apply. Social engineering training should be part of an organizations employee training regimen, and this malware attack form should be added to the list of things to watch for.

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

Recommendations

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

Recommendations

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.

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:

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.

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

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

Recommendations

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.

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:

:UACPrompt
  echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%getadmin.vbs"
  set params = %*:"="
  echo UAC.ShellExecute "cmd.exe", "/c %~s0 %params%", "", "runas", 1 >> "%temp%getadmin.vbs"
"%temp%getadmin.vbs"
  del "%temp%getadmin.vbs"
  exit /B

3. 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):

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemEnableLUA

4. 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/

Recommendations

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?

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

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

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

Recommendations

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.