LONDON, Nov. 2, 2023 /PRNewswire/ -- Arqit Quantum Inc. (NASDAQ: ARQQ) (NASDAQ: ARQQW) (Arqit), a leader in quantum-safe encryption, and DETASAD, a leading provider of telecommunications and Technology Solutions in the Kingdom of Saudi Arabia, today announced that Arqit's Sovereign Symmetric Key Agreement Platform will be launched in the Kingdom of Saudi Arabia by DETASAD this month.

DETASAD, a market leader in data center and cloud services, cybersecurity and intelligence infrastructure solutions proudly announces expanding its cutting-edge partnership with Arqit, a global leader in quantum-safe cybersecurity. Together, the team is currently building a fully data-sovereign stack integrating Arqit's groundbreaking Symmetric Key Agreement solution, a technology that integrates seamlessly into existing networks to create trusted connections and secure communication links for any networked device, cloud machine or application. Secure against current and future forms of attack on encryption including from a quantum computer, the platform enhances security, resilience and the dynamic management of today's networks.

This collaborative endeavour will not only drive the development of Saudi-specific solutions atop this platform but will also pioneer a local R&D partnership. The ultimate vision is to translate locally created solutions into products for both the Saudi market and the global export market, further bolstering the Kingdom's Vision 2030 alongside supporting the UK Government's National Cyber Strategy. DETASAD are looking forward to making this unique proposition available to their customers commercially in the next few weeks and are happy to demonstrate the capabilities protecting their customer's businesses.

Under this innovative alliance, DETASAD and Arqit are planning to integrate Arqit technology into DETASAD's MadeinSaudi Smart Capacity Management to deliver state-of-the-art, locally-developed cybersecurity to every endpoint - be it satellite or any other platform within the DETASAD edge cloud.

"From this month, customers in the Kingdom of Saudi Arabia and across the region will be able to benefit from enhanced security and resilience against cyber attacks, delivered by DETASAD using Arqit's unique Symmetric Key Agreement Platform" said David Williams, Arqit Founder, Chairman and CEO. "With the increasing threat and proliferation of connected devices, Arqit's crypto agile technology offers governments and enterprises the ability to immediately benefit from higher standards of network data and information assurance, sustainable into the quantum era."

"At DETASAD, we are excited to embark on this transformative journey with Arqit," said Felix Wass, President & CEO. "Our partnership is more than just a technological alliance we are setting out to revolutionize with a fully data-sovereign Symmetric Key Agreement Platform. We are not only bringing technology to the Kingdom of Saudi Arabia but will complement it and build a MadeInSaudi portfolio for the global markets."

"I am delighted to welcome this important announcement" said Juliette Wilcox, the UK Government's Cyber Security Ambassador. "Companies such as Arqit are leading the way in demonstrating how the UK's cyber expertise can enhance cyber capabilities across Saudi Arabia, helping to further strengthen security across the Kingdom's cyberspace."

Notes to Editors

The announcement was made at the British Embassy in Riyadh, Wednesday 31 October, at an event hosted by Juliette Wilcox, the UK Government's Cyber Security Ambassador, ahead of the start of the Global Cybersecurity Forum. Arqit Founder, Chairman and CEO David Williams and DETASAD President and CEO Felix Wass were both in attendance.

In June 2023, Arqit and DETASAD announced a Strategic Teaming Agreementto collaborate on creating sovereign security solutions and services (Arqit, Arqit and DETASAD announce Strategic Teaming Agreement, 12 June 2023, link).

About Arqit

Arqit supplies a unique Symmetric Key Agreement Platform-as-a-Service which makes the communications links of any networked device, cloud machine or data at rest secure against both current and future forms of attack on encryption even from a quantum computer. Arqit's Symmetric Key Agreement Platform delivers a lightweight software agent that allows devices to create encryption keys locally in partnership with any number of other devices. The keys are computationally secure and operate over zero trust networks. It can create limitless volumes of keys with any group size and refresh rate and can regulate the secure entrance and exit of a device in a group. The agent is lightweight and will thus run on the smallest of end point devices. The Product sits within a growing portfolio of granted patents but also works in a standards compliant manner which does not oblige customers to make a disruptive rip and replace of their technology. Arqit was recently awarded the Innovation in Cyber award at the UK National Cyber Awards and Cyber Security Software Company of the Year Award at the UK Cyber Security Awards. http://www.arqit.uk

About DETASAD

DETASAD is a Pioneer Solutions Provider of Technology Solutions & Services in the Middle East region since 1982 The company delivers cutting-edge solutions and innovative services to a diverse customer base, including government entities, enterprises, and consumers. DETASAD consider as Saudi National entity achieved the regulator (NCA) highest score at ECC "100%" and the CCC "93.55%" also DETASAD offers a comprehensive range of offering solutions, including Satellite, Cloud, Connectivity, Intelligent Infrastructure, Information Security, Data Center, AI & IoT Solutions. For more information, visit http://www.detasad.com.

Media relations enquiries:

Arqit: [emailprotected]Gateway: [emailprotected]

Investor relations enquiries:

Arqit:[emailprotected]Gateway: [emailprotected]

Caution About Forward-Looking Statements

This communication includes forward-looking statements within the meaning of the Private Securities Litigation Reform Act of 1995. All statements, other than statements of historical facts, may be forward-looking statements. These forward-looking statements are based on Arqit's expectations and beliefs concerning future events and involve risks and uncertainties that may cause actual results to differ materially from current expectations. These factors are difficult to predict accurately and may be beyond Arqit's control. Forward-looking statements in this communication or elsewhere speak only as of the date made. New uncertainties and risks arise from time to time, and it is impossible for Arqit to predict these events or how they may affect it. Except as required by law, Arqit does not have any duty to, and does not intend to, update or revise the forward-looking statements in this communication or elsewhere after the date this communication is issued. In light of these risks and uncertainties, investors should keep in mind that results, events or developments discussed in any forward-looking statement made in this communication may not occur. Uncertainties and risk factors that could affect Arqit's future performance and cause results to differ from the forward-looking statements in this release include, but are not limited to: (i) the outcome of any legal proceedings that may be instituted against the Arqit related to the business combination, (ii) the ability to maintain the listing of Arqit's securities on a national securities exchange, (iii) changes in the competitive and regulated industries in which Arqit operates, variations in operating performance across competitors and changes in laws and regulations affecting Arqit's business, (iv) the ability to implement business plans, forecasts, and other expectations, and identify and realise additional opportunities, (v) the potential inability of Arqit to convert its pipeline into contracts or orders in backlog into revenue, (vi) the potential inability of Arqit to successfully deliver its operational technology, (vii) the risk of interruption or failure of Arqit's information technology and communications system, (viii) the enforceability of Arqit's intellectual property, and (ix) other risks and uncertainties set forth in the sections entitled "Risk Factors" and "Cautionary Note Regarding Forward-Looking Statements" in Arqit's annual report on Form 20-F (the "Form 20-F"), filed with the U.S. Securities and Exchange Commission (the "SEC") on 14 December 2022 and in subsequent filings with the SEC. While the list of factors discussed above and in the Form 20-F and other SEC filings are considered representative, no such list should be considered to be a complete statement of all potential risks and uncertainties. Unlisted factors may present significant additional obstacles to the realisation of forward-looking statements.

See the rest here:
DETASAD and Arqit announce pioneering partnership to elevate ... - PR Newswire

Microsofts BitLocker software encryption of for SSDs, which is activated by default in Windows 11 Pro, causes a massive reduction in the performance of storage drives. TomsHardware conducted extensive tests of the feature and discovered that the speed of SSDs can be reduced by up to 45 percent, depending on the application.

Thats because with software-based BitLocker encryption, the processor is constantly busy encrypting and decrypting the data on the SSD during all write and read processes, which has an impact on the performance of the system.

Many SSDs now support hardware-based encryption, in which all decryption and encryption processes are handled directly by the SSDs. Windows 11 Pro nevertheless activates BitLockers software-based encryption during installation without giving you the ability to prevent it.

Microsoft probably decided to do this because it does not have full control over the code for hardware-based encryption, as thats managed by the SSD manufacturers. A while back, there were incidents where vulnerabilities were discovered in SSD hardware encryption code that had to be fixed by the manufacturers. So Microsoft seems to prefer to rely on its own solution here.

Windows 11 Home is not affected because it does not support BitLocker encryption. Thats a shame, because Windows 11 wont be fully secure until everyone has BitLocker encryption though as this problem shows, the specifics matter.

Further reading: How to upgrade from Windows 11 Home to Pro (and why youd want to)

To find out if your SSDs are affected by the problem, open the Windows 11 Pro command line with admin rights and enter the command

manage-bde -status

This will start the BitLocker Drive Encryption: Configuration Tool, which analyses all the drives in your computer.

Under Conversion Status, you can find out whether the data on the SSD is encrypted. Under Encryption Method, Windows 11 Pro shows whether software encryption (XTS-AES) or hardware encryption (Hardware Encryption) is used.

If XTS-AES is displayed here, BitLocker software encryption is used. If Fully decrypted is displayed under Conversion status, BitLocker is switched off on the computer.

TomsHardwares tests show that users who use applications that put a lot of strain on the SSDs can expect a noticeable drop in SSD performance. Microsoft could provide a general remedy with a patch for Windows 11 Pro. It is not known whether such a patch is already in development.

If that bothers you, first ask yourself whether you needs BitLocker encryption for your full drive to begin with. This feature is especially useful for users who own a notebook provided by a company, are often on the road, and generally have higher odds that your laptop (and its sensitive data) could be stolen.

In such a case, the thief would not be able to access the data on the computer without knowing your Windows account credentials. On the other hand, it is precisely these users who are most likely to be affected by the SSD slowdown, because business admins often install Windows 11 with the default settings, and thus with the software BitLocker activated.

Michael Crider/IDG

If you are absolutely sure that the data on your SSD does not need to be backed up in encrypted form, then software BitLocker can be deactivated with the following command. To do this, you need to call up the command line with admin rights and enter:

manage-bde -off C:

The C: must be replaced by the drive letter of the encrypted drive if necessary. After restarting your computer, the change becomes active immediately.

It becomes more complicated if you want to switch from BitLocker software encryption to BitLocker hardware encryption under Windows 11 Pro. The first prerequisite is, of course, that the SSD in the computer supports this hardware encryption.

In the next step, however, a complete reinstallation of Windows 11 Pro is necessary. A few more things need to be taken into account. Detailed instructions on how to activate hardware encryption under Windows 11 Pro, using the Samsung 980 Pro as an example, can be found in this helpful blog post.

You dont necessarily need to encrypt your full drive, however, nor is BitLocker your only option. For more information, check out our guide on how to encrypt files in Windows.

And here you can find out how to switch from Windows 11 Home to Windows 11 Pro without any problems and why youd want to.

This article was translated from German to English and originally appeared on pcwelt.de. It originally published on October 23 but was updated with additional information.

Read more:
Default Windows 11 feature slows SSDs up to 45%: How to fix it ... - PCWorld

Key Findings

Check Point Research, in collaboration withSygnias Incident Response Team, has been tracking and responding to the activities ofScarred Manticore, an Iranian nation-state threat actor that primarily targets government and telecommunication sectors in the Middle East. Scarred Manticore, linked to the prolific Iranian actor OilRig (a.k.a APT34, EUROPIUM, Hazel Sandstorm), has persistently pursued high-profile organizations, leveraging access to systematically exfiltrate data using tailor-made tools.

In the latest campaign, the threat actor leveraged the LIONTAIL framework, a sophisticated set of custom loaders and memory resident shellcode payloads. LIONSTAILs implants utilize undocumented functionalities of the HTTP.sys driver to extract payloads from incoming HTTP traffic. Multiple observed variants of LIONTAIL-associated malware suggest Scarred Manticore generates a tailor-made implant for each compromised server, allowing the malicious activities to blend into and be undiscernible from legitimate network traffic.

We currently track this activity as Scarred Manticore, an Iranian threat actor that is most closely aligned withDEV-0861. Although the LIONTAIL framework itself appears to be unique and bears no clear code overlaps with any known malware family, other tools used in those attacks overlap with previously reported activities. Most notably, some of those were eventually linked back to historic OilRig or OilRig-affiliated clusters. However, we do not have sufficient data to properly attribute the Scarred Manticore to OilRig, even though we do believe theyre likely related.

The evolution in the tools and capabilities of Scarred Manticore demonstrates the progress the Iranian actors have undergone over the last few years. The techniques utilized in recent Scarred Manticore operations are notably more sophisticated compared to previous activities CPR has tied to Iran.

In this article, we provide a technical analysis of the latest tools and the evolution of Scarred Manticores activity over time. This report details our understanding of Scarred Manticore, most notably its novel malware framework LIONTAIL, but also provides an overview of other toolsets we believe are used by the same actor, some of which were publicly exposed in the past. This includes, but is not limited to, tools used in the intrusion into the Albanian government infrastructure, web shells observed in high-profile attacks in the Middle East, and recently reported WINTAPIX driver-based implants.

While we finalized this blog post, a technical analysis of part of this activity waspublishedby fellow researchers from Cisco Talos. While it overlaps with our findings to some extent, our report provides additional extended information, in-depth insights, and a broader retrospective regarding the threat actor behind this operation.

LIONTAIL is a malware framework that includes a set of custom shellcode loaders and memory resident shellcode payloads. One of its components is the LIONTAIL backdoor, written in C. It is a lightweight but rather sophisticated passive backdoor installed on Windows servers that enables attackers to execute commands remotely through HTTP requests. The backdoor sets up listeners for the list of URLs provided in its configuration and executes payloads from requests sent by attackers to those URLs.

The LIONTAIL backdoor components are the main implants utilized in the latest Scarred Manticore intrusions. Utilizing access from a publicly facing server, the threat actor chains a set of passive implants to access internal resources. The internal instances of the LIONTAIL backdoors weve seen so far either listen on HTTP(s), similar to the internet-facing instances, or in some cases use named pipes to facilitate remote code execution.

We observed 2 methods of backdoor installation on the compromised Windows servers: standalone executables, and DLLs loaded through search order hijacking by Windows services or legitimate processes.

When installed as a DLL, the malware exploits the absence of some DLLs on Windows Server OS distributions: the backdoor is dropped to the system folderC:windowssystem32aswlanapi.dllorwlbsctrl.dll. By default, neither of theseexist on Windows Server installations. Depending on the Windows Server version, the malicious DLL is then loaded either directly by other processes, such as Explorer.exe, or the threat actors enable specific services, disabled by default, that require those DLLs.

In the case ofwlbsctrl.dll, the DLL is loaded at the start of theIKE and AuthIP IPsec Keying Modulesservice. Forwlanapi.dll, the actors enableExtensible Authentication Protocol:

sc.exe config Eaphost start=autosc.exe start Eaphost

In instances where LIONTAIL is deployed as an executable, a noteworthy characteristic observed in some is the attempt to disguise the executable asCyvera Console, a component of Cortex XDR.

The malware starts by performing a one-byte XOR decryption of a structure containing the malware configuration, which is represented with the following structure:

The fieldlisten_urlsdefines particularURL prefixesto which the malware listens for incoming requests.

All of the samples URL lists include the http://+:80/Temporary_Listen_Addresses/URL prefix, a defaultWCF URL reservationthat allows any user to receive messages from this URL. Other samples include multiple URLs on ports 80, 443, and 444 (on Exchange servers) mimicking existing services, such as:https://+:443/autodiscover/autodiscovers/ https://+:443/ews/exchanges/ https://+:444/ews/ews/

Many LIONTAIL samples contain tailor-made configurations, which add multiple other custom URLs that match existing web folders on the compromised server. As the URLs for the existing folders are already taken by the actual IIS service, the generated payloads contain additional random dictionary words in the path. These ensure the malware communication blends into legitimate traffic, helping to make it more inconspicuous.

Thehostelement of all prefixes in the configuration consists of a single plus sign (+), a strong wildcard that matches all possible host names. A strong wildcard is useful when an application needs to serve requests addressed to one or more relative URLs, regardless of how those requests arrive on the machine or what site (host or IP address) they specify in their Host headers.

To understand how the malware configures listeners on those prefixes and how the approach changes with time, we pause for a short introduction to the Windows HTTP stack.

A port-sharing mechanism, which allows multiple HTTP services to share the same TCP port and IP address, was introduced in Windows Server 2003. This mechanism is encapsulated withinHTTP.sys, a kernel-mode driver that assumes the responsibility of processing HTTP requests, listens to incoming HTTP requests, and directs them to the relevant user-mode processes or services for further handling.

On top of the driver layer, Windows provides theHTTP Server API,a user-mode component that provides the interface for interacting with HTTP.sys. In addition, the Internet Information Services(IIS) under the hood relies on HTTP API to interact with the HTTP.sys driver. In a similar fashion, theHttpListenerclass within the .NET framework is a simple wrapper around the HTTP Server API.

The process of receiving and processing requests for specific URL prefixes by an application (or, in our case, malware) can be outlined as follows:

After extracting the configuration, the malware uses the same one-byte XOR to decrypt a shellcode responsible for establishing the C&C communication channel by listening to the provided URL prefixes list. While the concept of passive backdoors on web-facing Windows servers is not new and wasobservedin the wild hijacking the same Windows DLLwblsctrl.dllas early as 2019 (by Chinese-linkedOperation ShadowHammer), the LIONTAIL developers elevated their approach. Instead of using the HTTP API, the malware uses IOCTLs to interact directly with the underlying HTTP.sys driver. This approach is stealthier as it doesnt involve IIS or HTTP API, which are usually closely monitored by security solutions, but is not a straightforward task given that the IOCTLs for HTTP.sys are undocumented and require additional research efforts by the threat actors.

First, the shellcode registers the URL prefixes with HTTP.sys using the following IOCTLs:

After registering the URL prefixes, the backdoor initiates a loop responsible for handling the incoming requests. The loop continues until it gets the request from a URL equal to theend_stringprovided in the backdoors configuration.

The backdoor receives requests from HTTP.sys using 0x124036 UlReceiveHttpRequestIoctlIOCTL.

Depending on the version of the compromised server, the body of the request is received using 0x12403B UlReceiveEntityBodyIoctlor (if higher than 20348) 0x12403A UlReceiveEntityBodyFastIo. It is then base64-decoded and decrypted by XORing the whole data with the first byte of the data. This is a common method of encryption observed in multiple malware families, including but not limited to DEV-0861s web-deployedReverse proxy.

The decrypted payload has the following structure:

The malware creates a new thread and runs the shellcode in memory. For some reason, it uses shellcode_output and shellcode_output_sizein the request message as pointers to the respective data in memory.

To encrypt the response, the malware chooses a random byte, XOR-encodes the data using it as a key, prepends the key to the result, and then base64-encodes the entire result before sending it back to the C&C server using the IOCTL 0x12403F UlSendHttpResponseIoctl.

In addition to PE implant, Scarred Manticore uses a web shell-based version of the LIONTAIL shellcode loader. The web shell is obfuscated in a similar manner to other Scarred Manticore .NET payloads and web shells.

The web shell gets requests with 2 parameters:

Both parameters are encrypted the same way as other communication: XOR with the first byte followed by base64 encoding.

The structure of shellcodes and of arguments sent to the web shell-based shellcode loader is identical to those used in the LIONTAIL backdoor, which suggests that the artifacts observed are part of a bigger framework that allows the dynamic building of loaders and payloads depending on the actors access and needs.

During our research, we also found loaders that have a similar internal structure to the LIONTAIL samples. Instead of listening on URL prefixes, this version gets its payloads from a named pipe and likely is designated to be installed on internal servers with no access to the public web. The configuration of the malware is a bit different:

The main shellcode starts withconvertingthe string security descriptor"D:(A;;FA;;;WD)into a valid, functional security descriptor. As the string starts with D, it indicates a DACL (discretionary access control list)entry, which typically has the following format:entry_type:inheritance_flags(ACE_type; ACE_flags; rights; object_GUID; inherit_object_GUID; account_SID). In this case, the security descriptor allows (A) File All Access (FA) to everyone (WD).

The security descriptor is then used tocreatea named pipe based on the values provided in the configuration. In the samples we observed, the name of the pipe used is\.pipetest-pipe.

Its noteworthy that, unlike the HTTP version, the malware doesnt employ any more advanced techniques for connecting to the named pipe, reading from it, and writing to it. Instead, it relies on standardkernel32.dllAPIs such asCreateNamedPipe, andReadFileWriteFile.

The communication of named pipes-based LIONTAIL is identical to the HTTP version, with the same encryption mechanism and the same structure of the payload which runs as a shellcode in memory.

After the LIONTAIL loader decrypts the payload and its argument received from the attackers C&C server, it starts with parsing the argument. It is a structure that describes a type of payload for the shellcode to execute and it is built differently depending on the type of payload:

The argument for the API execution has the following structure:

To make things more complicated, Scarred Manticore wraps the final payload in nested shellcodes. For example, one of the shellcodes received from the attackers runs another almost identical shellcode, which in turn runs a final shellcode responsible for machine fingerprinting.

The data gathered by this payload is collected by running specific Windows APIs or enumerating the registry keys, and includes these components:

The final structure, which contains all the gathered information, also has a place for error codes for the threat actor to use to figure out why some of the APIs they use dont work as expected:

In addition to using LIONTAIL, Scarred Manticore was observed leveraging other custom components.

On some of the compromised exchange servers, the actors deployed LIONHEAD, a tiny web forwarder. LIONHEAD is also installed as a service using the same phantom DLL hijacking technique as LIONTAIL and utilizes similar mechanisms to forward the traffic directly to Exchange Web Services (EWS) endpoints.

LIONHEADs configuration is different from LIONTAIL:

The backdoor registers thelisten_urlsprefixes in the same way as LIONTAIL and listens for requests. For each request, the backdoor copies the content type, cookie, and body and forwards it to the/:specified in the configuration. Next, the backdoor gets a response fromforward_serverand sends it back to the URL that received the original request.

This forwarder might be used to bypass the restrictions on external connections to EWS, hide the real consumer of EWS data being external, and consequently conceal data exfiltration.

Scarred Manticore deploys multiple web shells, including those previouslyattributedindirectly to OilRig. Some of these web shells stand out due to their obfuscations, naming conventions and artifacts. The web shells retain class and method obfuscation and a similar string encryption algorithm (XOR with one byte, the key is derived from the first byte or from the first 2 bytes) to many other web shells and .NET-based tools used by Scarred Manticore in their attacks over the past few years.

One of those shells is a heavily obfuscated and slightly modified version of an open-source XML/XSL transform web shell,Xsl Exec Shell. This web shell also contains two obfuscated functions that return the string ~/1.aspx. These functions are never called and likely are remnants from other versions, as we observed them in tools used previously by Scarred Manticore, such as FOXSHELL, which is discussed later:

Based on our visibility into the latest wave of attacks that utilize LIONTAIL, the observed victims are located across the Middle East region, including Saudi Arabia, the United Arab Emirates, Jordan, Kuwait, Oman, Iraq, and Israel. The majority of the impacted entities belong togovernment,telecommunications, military, andfinancialsectors, as well as IT services providers. However, we also observed the infection on the Exchange servers belonging to a regional affiliate of a global non-profit humanitarian network.

The geographic region and the targeted profile are aligned with Iranian interests and in line with the typical victim profile that MOIS-affiliated clusters usually target in espionage operations.

Previously, DEV-0861, a cluster we believed aligns with Scarred Manticore, was publiclyexposedfor the initial access to and data exfiltration from the Albanian government networks, as well as email exfiltration from multiple organizations in the Middle Eastern countries such as Kuwait, Saudi Arabia, Turkey, UAE, and Jordan.

Since at least 2019, Scarred Manticore deployed unique tools on compromised Internet-facing Windows servers in the Middle East region. During these years, their toolset went through significant development. It began as open-source-based web-deployed proxies and over time evolved to become a diverse and powerful toolset that utilizes both custom-written and open-source components.

One of the earliest samples related to the threat actors activity is based on a web shell fromTunna, an open-source tool designed to tunnel any TCP communication over HTTP. The Tunna web shell allows to connect from the outside to any service on the remote host, including those that are blocked on the firewall, as all the external communication to the web shell is done via HTTP. The IP and the port of the remote host are sent to the web shell in the configuration stage, and in many cases, Tunna is mostly used to proxy RDP connections.

The web shell used by the threat actor has the internal versionTunna v1.1g(only version 1.1a is available on Github). The most significant change from the open-source version is the encryption of requests and responses by XORing the data with the pre-defined stringszEncryptionKeyand appending the constant stringK_SUFFIXat the end:

Over time, the code was refactored and lost its resemblance to Tunna. We track this and all further versions as FOXSHELL.

The biggest changes resulted from organizing multiple entities into classes using an objective-oriented approach. The following class structure persists in most of the FOXSHELL versions:

All the functionality responsible for encrypting the traffic moved to a separateEncryptionModuleclass. This class loads a .NET DLL embedded in a base64-encoded string inside the body of FOXSHELL and invokes itsencryptanddecryptmethods:

The embedded encryption modules name isXORO.dll, and its classEncryption.XOROimplements decrypt and encrypt methods the same way as the Tunna-based web shell, using the same hardcoded values:

All requests to the web shell are also encapsulated within a class calledPackage, which handles differentPackageTypes: Data, Config, OK, Dispose, or Error. The PackageType is defined by the first byte of the package, and depending on the type of Package, the web shell parses the package and applies the configuration (opens a new socket to the remote machine specified in the configuration and applies a new EncryptionDll if provided), or disposes of the existing socket, or proxies the connection if the package is type Data:

This version of the web shell is still unobfuscated, and its internal version is specified in the code:

The web shell also contains the default EncryptionDll embedded inside. The modules name isBase64.dll, and the encryption class, which is misspelled asBsae64, exposes the encrypt and decrypt methods. However, both are just simple base64 encoding:

Although this simple encoding could be done in the code of the web shell itself, the existence of other embedded DLLs, such asXORO.dll(described previously), and the ability to provide yet another EncryptionDll on the configuration stage, implies that the attackers prefer to control which specific type of encryption they want to use by default in certain environments.

Other changes in this version are the renaming of the PackageTypeConfigtoRDPconfig, andConfigPackagetoRDPConfigPackage, indicating the actors are focused on proxying RDP connections. The code of these classes remains the same:

Finally, another condition in the code handles the case of the web shell receiving a non-empty parameterWV-RESET,which calls a function to shut down the proxy socket and sends anOKresponse back to the attackers:

The versions that were described above, targeted entities in Middle Eastern countries, such as Saudi Arabia, Qatar, and the United Arab Emirates. This version, in addition to being leveraged against Middle Eastern governmental entities, was part of theattackagainst the Albanian government in May 2021. Through the exploitation of an Internet-facing Microsoft SharePoint server, the actors deployedClientBin.aspxon the compromised server to proxy external connections and thus facilitate lateral movement throughout the victims environment.

The details of the samples may vary but in all of them, the FOXHELL is compiled as DLL and embedded inside the base web shell in base64. The compiled DLL is loaded withSystem.Reflection.Assembly.Load, and then theProcessRequestmethod from it is invoked. The DLL is written in .NET and has the name patternApp_Web_.dll, which indicates an ASP.NET dynamically compiled DLL.

TheApp_Web*DLL is affected by the class and method obfuscation, and all the strings are encrypted with a combination of Base64, XOR with the first byte, and AES:

When the web shell is compiled into DLL, it contains the initialization stub, which ensures that the web shell listens on the correct URI. In this case, the initialization happens in the following piece of code:

Or, after deobfuscation:

This initialization sets the FOXSHELL to listen to the requests on the relative path~/1.aspx, which we observed as an unused artifact in other web shells related to attacks involving LIONTAIL.

Internally, the DLL has the same 1.5 version of FOXSHELL, which includes theWV-RESETparameter to stop the proxy and the same defaultBsae64Encryption DLL as in previous versions.

Since mid-2020, in addition to the FOXSHELL as a means to proxy the traffic, we also observed a rather sophisticated standalone passive backdoor, written in .NET and meant to be deployed on IIS servers. It is obfuscated with similar techniques as FOXSHELL and masquerades asSystem.Drawing.Design.dll. The SDD backdoor was previouslyanalyzedby a Saudi researcher but was never attributed to a specific threat actor or campaign.

C&C Communication

The SSD backdoor sets up C&C communication through an HTTP listener on the infected machine. It is achieved using two classes:

ServerManager is used to extract the sites hosted by the IIS server and build the HashSet of URL prefixes to listen on:

In this specific case, the only relative URI configured in the malware sample is Temporary_Listen_Addresses. The malware then uses the HttpListener class to start listening on the specified URL prefixes:

C&C command execution

The backdoor has several capabilities: execute commands usingcmd.exe, upload and download files, execute processes with specified arguments, and run additional .NET assemblies.

First, if the POST request body contains data, the malware parses it and handles the message as one of the 4 commands it supports. Otherwise, if the request contains a parameterVet, the malware simply decodes its value from base64 and executes it withcmd /c. If none of these is true, then the malware handles the heartbeat mechanism: if the request URL contains the stringwOxhuoSBgpGcnLQZxipain lowercase, then the malware sends backUsEPTIkCRUwarKZfRnyjcG13DFAalong with a200 OKresponse.

The data from the POST request is encrypted using Base64 and simple XOR-based encryption:

After decrypting the data of the message, the malware parses it according to the following order:

The possible commands, as named by the threat actors, include:

The response data is built the same way as the request (returns command type, command name, and output) and then encrypted with the same XOR-based algorithm as the request.

Recently, Fortinetrevealeda wave of attacks against Middle Eastern targets (mostly Saudi Arabia, but also Jordan, Qatar, and the United Arab Emirates) that involve kernel mode drivers that the researchers named WINTAPIX. Although the exact infection chain to install the drivers is unknown, they target only IIS servers as they use the IIS ServerManager object. The high-level execution flow is the following:

The final payload is obfuscated with a commercial obfuscator in addition to already familiar class, method, and string obfuscations, and it combines the functionality of the SDD backdoor and FOXSHELL proxy. To achieve both, it listens on two sets of URL prefixes, using ServerManager and HTTPListener similarly to the SSD backdoor.

The FOXSHELL version used within the driver payload is set to1.7. The main enhancement introduced in this version is the Event Log bypass using a known technique of suspending EventLog Service threads. The default EncryptionDll hardcoded in the driver is the same Bsae64.dll, and the core proxy structure remains largely unaltered when compared to FOXSHELL version 1.5.

As an extensive analysis of the WINTAPIX driver and its versionSRVNET2was already provided, here we only highlight the main overlaps between those and other discussed tools that strengthen their affiliation:

LIONTAIL framework components share similar obfuscation and string artifacts with FOXSHELL, SDD backdoor, and WINTAPIX drivers. Currently, we are not aware of any other threat actors utilizing these tools, and we attribute them all to Scarred Manticore based on multiple code overlaps and shared victimology.

For the last few years, Scarred Manticore has been observed carrying out multiple stealthy operations in Middle Eastern countries, including gaining access to telecommunications and government organizations in the region, and maintaining and leveraging this access for months to systematically exfiltrate data from the victims systems. Examining the history of their activities, it becomes evident how far the threat actor has come in improving their attacks and enhancing their approach which relies on passive implants.

While LIONTAIL represents a logical progression in the evolution of FOXSHELL and still bears some distinctive characteristics that allow us to attribute attacks involving LIONTAIL to Scarred Manticore, it stands out from other observed variants. The LIONTAIL framework does not use common, usually monitored methods for implementing listeners: it no longer depends on Internet Information Services (IIS), its modules, or any other options and libraries provided by the .NET framework to manage IIS programmatically. Instead, it utilizes the lowest level of Windows HTTP Stack by interacting directly with the HTTP.sys driver. In addition, it apparently allows the threat actors to customize the implants, their configuration parameters, and loaders file delivery type. All those have enhanced the stealth ability of the implants, enabling them to evade detection for an extended period.

We expect that Scarred Manticore operations will persist and may spread into other regions as per Iranian long-term interests. While most of the recent activity of Scarred Manticore is primarily focused on maintaining covert access and data extraction, the troubling example of the attack on the Albanian government networks serves as a reminder that nation-state actors may collaborate and share access with their counterparts in intelligence agencies.

Check Point Customers remain protected against attacks detailed in this report, while using IPS, Check PointHarmony Endpoint and Threat Emulation.

IPS:

Backdoor.WIN32.Liontail.A/B

Threat Emulation:

APT.Wins.Liontail.C/D

See original here:
From Albania to the Middle East: The Scarred Manticore is Listening ... - Check Point Research

The European Telecommunications Standards Institute (ETSI) may open source the proprietary encryption algorithms used to secure emergency radio communications after a public backlash over security flaws found this summer.

"The ETSI Technical Committee in charge of TETRA algorithms is discussing whether to make them public," Claire Boyer, a spokesperson for the European standards body, told The Register.

The committee will discuss the issue at its next meeting on October 26, she said, adding: "If the consensus is not reached, it will go to a vote."

TETRA is the Terrestrial Trunked Radio protocol, which is used in Europe, the UK, and other countries to secure radio communications used by government agencies, law enforcement, military and emergency services organizations.

In July, a Netherlands security biz uncovered five vulnerabilities in TETRA, two deemed critical, that could allow criminals to decrypt communications, including in real-time, to inject messages, deanonymize users, or set the session key to zero for uplink interception.

The Midnight Blue researchers dubbed the bugs, which affected all TETRA networks, TETRA:BURST. The team waited one and a half years, as opposed to the usual six-month disclosure period, to make the flaws public because of the sensitive nature of emergency comms, and the complexity of fixing the issues.

At the time ETSI downplayed the flaws, which it said had been fixed last October, and noted that "it's not aware of any active exploitation of operational networks."

It did, however, face criticism from the security community over its response to the vulnerabilities and the proprietary nature of the encryption algorithms, which makes it more difficult for proper pentesting of the emergency network system..

Security author Kim Zetter broke the story that ETSI was discussing making the TETRA algorithms public. She also quoted Matthew Green, a Johns Hopkins University cryptographer and professor, who said keeping algorithms secret is a dated idea that makes problems worse.

"This whole idea of secret encryption algorithms is crazy, old-fashioned stuff. It's very 1960s and 1970s and quaint," he said. "If you're not publishing [intentionally] weak algorithms, I don't know why you would keep the algorithms secret."

Zetter indicated that ETSI's recent security failures may have changed some members' minds about removing the cloak of secrecy around the technology. ETSI disclosed that intruders had exploited a vulnerability to breach its members-only portal and steal a database containing personal information.

It didn't provide any additional information about the flaw used to break into the portal, but noted "ETSI has fixed the vulnerability."

The disclosure also included a statement from ETSI Director-General Luis Jorge Romero, who said: "Transparency is at the root of ETSI, in our governance and technical work."

It looks like the real test of this will come later this month when the TETRA algorithms go to a vote.

Read this article:
Europe mulls open sourcing TETRA emergency services' encryption algorithms - The Register

When it comes to keeping sensitive data safe, email encryption is a necessity. But it doesnt have to be a necessary evil.

Too many employees and IT experts have experienced the pain of trying to use a needlessly complicated email encryption solution. Theres the endless steps, the hard-to-navigate portals, and the time-consuming processes that add up to a frustrating experience for most.

If this is the experience youve come to expect, Webroot Email Encryption powered by Zix is here to surprise you. Webroot simplifies, streamlines, and secures the encryption process making email security easier than ever.

The recipient process has historically been one of the biggest pain points for email encryption software customers. Its often complicated and cumbersome, filled with portals, secret passwords, and extra steps. It shouldnt be that difficult just to read an email, and now it doesnt have to be.

Webroot Email Encryption drastically simplifies the email recipient process. When both the sender and the recipient are Webroot clients, the software will encrypt the outgoing email from one customer, and send it to the recipient completely transparently regardless of the email content. No portal, no passwords, no extra steps just a blue bar at the top of the email confirming it was sent securely. From there, the recipient can reply to the email exactly as they would a regular email.

Even without transparent delivery, Webroots Email Encryption makes the recipient process intuitive for non-Webroot clients. The recipient secure email portal is designed for non-technical people to be able to access, read, and reply to encrypted emails easily.

Security tools only work when people use them, and even with the best IT policies in place, its difficult to stop employees from sending sensitive information without encryption. While many organizations have increased their employee training amid an increased threat landscape, training only goes so far.

Exposing sensitive information isnt just an organizational problem, its also a regulatory one. The Health Insurance Portability and Accountability Act (HIPAA) requires that all patient data is kept secure and private. With traditional email encryption solutions, this burden falls on employees every time. For healthcare organizations, this is an added layer of complication on top of an often hectic landscape for employees.

Thankfully, Webroots Email Encryption offers automatic encryption, removing the burden from employees of having to remember to encrypt sensitive emails every time they send one. Webroot Email Encryption provides out-of-the-box automatic policies for HIPAA, Social Security numbers, and financial information. When a policy is triggered whether the sender has elected to encrypt the email or not emails can be encrypted, blocked or quarantined.

The result? Any email containing sensitive information is automatically encrypted, saving both employees and the organization at large from the threat of a security breach.

Email encryption is just one piece of the cybersecurity puzzle. Every organization has a unique set of security needs, and a threat could severely affect operations at any time.

Thats why its important to ensure your email encryption solution comes along with purpose-built add-ons and can also seamlessly integrate with other security solutions. Webroot Email Encryption can be easily integrated and is also part of a larger network of threat protection that keeps your organization safe.

OpenText Cybersecurity brings together a number of product families (Webroot, Carbonite and Zix) that can be brought in to improve and enhance the overall user experience. These capabilities include:

Single Sign-On with SAML 2.0Allows a user to login to their Webroot Secure Message Portal with their own credentials theyve already created through the customers website. Without having to login again, users click a link to be taken directly to their secure inbox. This feature is implemented in using SAML 2.0, which authorizes user access to web services across organizations.

Webroot Email Threat Protection email encryption provides multilayered filtering for both inbound and outbound emails that lets the right emails through while blocking malicious threats such as phishing, ransomware, impersonation, business email compromise (BEC) and spam. It also offers attachment quarantine, link protections, message retraction, and a round-the-clock live threat analyst team.

Seeing how simple email encryption can be is surprising, we know. And weve only just scratched the surface. If you want to learn more about how OpenText Cybersecurity can help make email surprisingly secure and simple, you canrequest a demo here.

Guest blog courtesy of OpenText Cybersecurity. Author Olivia Pramas is director of Channel Marketing for OpenText. Read more OpenText news and blogs here. Regularly contributedguest blogsare part of MSSP Alertssponsorship program.

Go here to read the rest:
How Easy is Email Encryption? You'd Be Surprised - MSSP Alert