Overview

SonicWall Capture Labs threat research team became aware of a fully unauthenticated server-side template injection vulnerability within CrushFTP, assessed its impact, and developed mitigation measures. CrushFTP is an enterprise file transfer tool. Such tools have seen increased attention from attackers over the last several years. This vulnerability, CVE-2024-4040, has a CVSS score of 10.0 and has been reported to be exploited in the wild by CISA.  A PoC and vulnerability scanner script has been released on GitHub, making it relatively easy for attackers to leverage. Shodan indicates around 5,200 instances of exposure on the internet at the time of writing. CrushFTP has released an update to fix this vulnerability and anyone using this software should update to version 11.1 or newer.

Technical Overview

CrushFTP is designed to provide an anonymous or unprivileged session token for any unauthenticated request to any page with a “/WebInterface” prefix. This session token can then be used to access other API endpoints. The vulnerability exists due to an accessible endpoint – ServerSessionAJAX – that allows these tokens to access its API features. The ServerSessionAJAX API functions as a server-side templating engine by performing variable replacements. This API is susceptible to a server-side template injection vulnerability within the writeResponse function. If an attacker manages to insert data enclosed within %% or {} symbols in the argument, the server will execute and render the attacker-specified template. This results in arbitrary file read as root, authentication bypass for administrator account access, and can lead to theft of all files stored on the instance. To perform our analysis, we installed CrushFTP version 10.6 using a docker container hosted on docker hub.

Triggering the Vulnerability

In order to leverage and trigger this vulnerability, an attacker must first obtain an unprivileged session token by sending a basic GET request to any endpoint in “/WebInterface,” as seen in Figure 1.

Figure 1: Obtaining a session token

Using a session token, the attacker can attempt to access resources that should only be accessed by a fully authenticated account, such as an API implemented by ServerSessionAJAX. In Figure 2, we are trying to access an API feature we shouldn’t have permission to access — the zip function. Upon trying to access, an error appears instead of the expected “access denied” message.

Figure 2: Indication of unauthenticated access to API

Through this unauthenticated API, we can send legitimate template commands to obtain information about the server, which will be returned in the response. The code allows an extensive list of legitimate commands to be sent into the request. Figure 3 shows a small subset of the list from the code, including one that returns the working directory of where the application is running, which is crucial for exploitation.

Figure 3: change_vars_to_values_static function

Attempting to access this command via an unauthenticated request, as seen in Figure 4, proves an attacker can effectively leverage the SSTI. Notice that the working directory is returned in the server’s response when the “working_dir” template is provided.

Figure 4: Successful template injection

Exploitation

To exploit this vulnerability, an attacker can use this access to obtain an administrator login or session token. By examining the possible templates that can be leveraged within the “change_vars_to_values” function, we run across “INCLUDE” tags among many others, as seen in Figure 5.

Figure 5: Injectable Tags

As demonstrated in Figure 4, it is easy to obtain the working directory of the application. Within the application’s main directory, a file named sessions.obj contains all of the session data for the instance, including session tokens.  If an administrator is logged into the application, their token will be in this file. An attacker can exploit the SSTI vulnerability using <INCLUDE>, as seen in Figure 6, to have the file’s contents returned in the response.

Figure 6: SSTI using <INCLUDE>

Within the response, it is easy to locate a list of assigned session tokens. In Figure 7, the administrator token is highlighted in yellow. While an attacker may not know which token is dedicated to the administrator, trial and error will eventually allow them to utilize the correct token.

Figure 7: Output of SSTI including the sessions.obj file

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:

• IPS:4396 CrushFTP Server-Side Template Injection
• IPS:4400 CrushFTP Server-Side Template Injection 2
• IPS:4402 CrushFTP Server-Side Template Injection 3

Remediation Recommendations

CrushFTP has released an update to fix this vulnerability, and anyone using this software is advised to update to version 11.1 or newer.

Relevant Links

• https://www.crushftp.com/crush11wiki/Wiki.jsp?page=Update
• https://hub.docker.com/r/netlah/crushftp/tags
• https://www.cve.org/CVERecord?id=CVE-2024-4040
• https://github.com/airbus-cert/CVE-2024-4040/blob/main/README.md
• https://attackerkb.com/topics/20oYjlmfXa/cve-2024-4040/rapid7-analysis
• https://www.shodan.io/search?query=html%3A%22%2FWebInterface%2FResources%2Fjs%2Flogin.js%22

 

Overview

The SonicWall Capture Labs threat research team has been regularly sharing information about malware targeting Android devices. We’ve encountered similar RAT samples before, but this one includes extra commands and phishing attacks designed to harvest credentials.

This malware uses famous Android app icons to mislead users and trick victims into installing the malicious app on their devices. This malicious app uses any of the following icons:

 

Figure 1: The app icon used by the malware.

Figure 2: Installed malicious app

Infection Cycle

After the malicious app is installed on the victim’s device, it prompts the victim to enable two permissions:

• Accessibility Service
• Device Admin Permission

By requesting these permissions, the malicious app aims to gain control over the victim’s device, potentially allowing it to carry out harmful actions or steal sensitive information without the user’s awareness or consent.

Figure 3: Prompt for accessibility permission

Figure 4: Device admin activation

The malicious app establishes a connection with the Command-and-Control server to receive instructions and execute specific tasks accordingly.

Here are some of the commands received from the malware’s Command-and-Control (C&C) server:

Command	Description
dmpsms	Read Messages
dmpcall	Read Call logs
dmpcon	Device Contact list
getpackages	Installed package name
changewall	Change device wallpaper
toasttext	Notification data
opweb	Open URLs on web browser for phishing
vibratedev	Vibrate device
sendsms	Send messages
tont	Turn on the camera flashlight
tofft	Turn off the camera flashlight

 

The resource file contains the URL of the C&C server, but it was not active during the analysis.

Figure 5: C&C server

Here you see it receiving commands from the C&C server to access a specific URL in the browser to harvest credentials.

Figure 6: Browser to open specific URL

Some malicious HTML files related to well-known Android applications are in the ‘asset\website’ folder, as shown in the figure below:

Figure 7: Fraudulent HTML Pages

Figure 8: Instances of fraudulent HTML page -1.

Figure 9: Instances of fraudulent HTML page -2.

In these HTML files, the attacker prompts the victim to enter their user ID and password into the input fields.

Figure 10: Retrieves user input

After taking credentials using JavaScript, it collects and shares all the user information to the ‘showTt’ function.

Figure 11: Collect user credential

It retrieves all phone numbers stored on the victim’s device.

Figure 12: Fetching contact List

It attempts to change the device’s wallpaper to a specific resource if the ‘str’ parameter matches the decrypted value, such as 0, 1, or 2.

Figure 13: Changing the Device Wallpaper

It retrieves information about installed apps on the victim’s device.

Figure 14: Collecting installed package info

The below code snippet utilizes the “CameraManager” to toggle the flashlight of the victim’s device’s camera to either on or off.

Figure 15: Camera flashlight on-off

It sends a message to a number based on input received from the C&C server.

Figure 16: Sending a message from the victim’s device

We also noticed that certain malicious files have been recently uploaded to malware-sharing platforms like VirusTotal.

Figure 17: Latest sample found on VT

SonicWall Protections

SonicWall Capture Labs provides protection against this threat via SonicWall Capture ATP w/RTDMI.

Indicators of Compromise (IOCs)

0cc5cf33350853cdd219d56902e5b97eb699c975a40d24e0e211a1015948a13d

37074eb92d3cfe4e2c51f1b96a6adf33ed6093e4caa34aa2fa1b9affe288a509

3df7c8074b6b1ab35db387b5cb9ea9c6fc2f23667d1a191787aabfbf2fb23173

6eb33f00d5e626bfd54889558c6d031c6cac8f180d3b0e39fbfa2c501b65f564

9b366eeeffd6c9b726299bc3cf96b2e673572971555719be9b9e4dcaad895162

a28e99cb8e79d4c2d19ccfda338d43f74bd1daa214f5add54c298b2bcfaac9c3

d09f2df6dc6f27a9df6e0e0995b91a5189622b1e53992474b2791bbd679f6987

d8413287ac20dabcf38bc2b5ecd65a37584d8066a364eede77c715ec63b7e0f1

ecf941c1cc85ee576f0d4ef761135d3e924dec67bc3f0051a43015924c53bfbb

f10072b712d1eed0f7e2290b47d39212918f3e1fd4deef00bf42ea3fe9809c41

Overview

SonicWall Capture Labs threat research team has observed fileless .Net managed code injection in a native 64-bit process.  Native code or unmanaged code refers to low-level compiled code such as C/C++.  Managed code refers to code that is written to target .NET and will not work without the CLR (Microsoft .NET engine) runtime libraries. The injected code belongs to AgentTesla malware.

Technical Analysis

The initial infection vector is a Word document that the client received as an email attachment. Upon opening this document, it will ask the user to enable a VBA macro. If enabled, this VBA macro downloads a 64-bit executable from the internet and executes it.

The downloaded binary is a 64-bit, Rust-compiled binary. We are focusing on the techniques used by this binary to inject the malicious AgentTesla payload into its own process memory using CLR Hosting.

The following are details of the 64-bit downloaded executable file.

MD5 : 4521162D45EFC83FA76C4B5C0D405265

SHA256 :  F00ED06A1D402ECF760EC92F3280EF6C09E76036854ABACADCAC9311706ED97D

URL from which 64-bit executable downloaded:

https[:]//New-Coder[.]cc/Users/signed_20240329011751156[.]exe

Disabling Event Tracing for Windows (ETW)

On execution of the Rust binary, it patches the “EtwEventWrite” API from NTDLL using the NtProtectVirtualMemory, WriteProcessMemory and FlushInstructionCache APIs.

Figure 1:  After the malware patches the “EtwEventWrite” API

This 64-bit malware process downloads an encoded shellcode from the following URL which contains the AgenetTesla payload.

URL of the shellcode:

https[:]//New-Coder[.]cc/Users/shellcodeAny_20240329011339585[.]bin

Next, the malware starts the execution of the downloaded shellcode using the “EnumSystemLocalesA” API by passing the address of the shellcode to the API as the callback function argument.

Figure 2: Moved shellcode from read-write memory to executable memory and starts its execution

The shellcode parses PEB and PEB_LDR_DATA to resolve the API dynamically. It will resolve the VirtualAlloc, VirtualFree, and RtlExitUserProcess APIs using an API hashing technique.

Next, the shellcode allocates read-write memory using the “VirtualAlloc” API and moves 0x3E3C0 bytes from the shellcode to the allocated memory.  These bytes are the encoded AgentTesla payload.

Figure 3: Moved shellcode data in read-write memory and starts decryption routine

As shown in Figure 3 above, the first 4bytes (DWORD) are the size of encoded data followed by encoded data.

Next, it proceeds to decrypt the payload. The shellcode uses a customized decryption routine where it performs single-byte XOR decryption in a loop, and for every iteration, it decrypts 0x10 bytes in the payload with a 0x10-byte encryption key. In a decryption loop, every time the malware uses a different encryption key derived from a combination of XOR and arithmetic operations. It decrypts the 0x3E184 bytes of the memory buffer to get the final payload.

Figure 4: Single-byte XOR decryption

Next, the shellcode reads the DLL name array, which contains the names of DLLs that are required for the malware to perform its operation. This array is “ole32;oleaut32;wininet;mscoree;shell32”.

The shellcode parses the PEB structure to check for the presence of the above-mentioned DLLs in the loaded modules list and loads the DLL using the “LoadLibraryA” API if they are not present.

Once the required DLLs are loaded into memory, it resolves a few more APIs such as “VirtualProtect”, “SafeArrayCreate”, “CLRCreateInstance” etc., using the API Hashing technique.

AMSI Bypass Using Memory Patching

Next, the shellcode patches the “AmsiScanBuffer” and “AmsiScanString” API, as shown below.

Figure 5: “AmsiScanBuffer” API after patching

Figure 6: “AmsiScanString” API after patching

Disabling Event Tracing (2^nd time)

We have observed the second time patching in shellcode to disable Event Tracing, this might be to confirm the patching continues. It patches “EtwEventWrite” API with a single byte “0xCC” (return instruction).

Next, the shellcode starts CLR hosting.

These are the steps required to perform CLR Hosting, in order:

• Create a CLR MetaHost instance:

ICLRMetaHost* pMetaHost = NULL;

CLRCreateInstance(CLSID_CLRMetaHost, IID_ICLRMetaHost, (LPVOID*)&pMetaHost);

• Enumerate the installed runtimes:

pMetaHost->EnumerateInstalledRuntimes(&installedRuntimes);

Enumerate through runtimes and try to locate a specific dotnet version installed on the system.

One has to use “GetVersionString” method from the ICLRRuntimeInfo interface to find the supported .NET Framework version.  This .NET Framework version string will be passed to the GetRuntime API.

• Get RuntimeInfo using “GetRuntime”:

ICLRRuntimeInfo* runtimeInfo = NULL;

pMetaHost->GetRuntime(sz_runtimeVersion, IID_ICLRRuntimeInfo, (LPVOID*)&runtimeInfo);

• Get ICorRuntimeHost interface:

ICorRuntimeHost Interface allows more control over the managed runtime from the native code, It can be retrieved using ICLRRuntimeInfo::GetInterface

ICorRuntimeHost* pCorRuntimeHost =NULL;

runtimeInfo->GetInterface(CLSID_CorRuntimeHost,IID_ICorRuntimeHost,(LPVOID*)& pCorRuntimeHost);

• Retrieve the default AppDomain for the current process:

ICorRuntimeHost interface allows retrieval of the default AppDomain for the current process.

IUnknown* appDomainThunk;

pCorRuntimeHost->GetDefaultDomain(&appDomainThunk);

_AppDomain* defaultAppDomain = NULL;

appDomainThunk->QueryInterface(IID_AppDomain, &defaultAppDomain);

• Create SafeArray:

we must create SafeArray and copy the MSIL payload to this SafeArray since we can’t provide an unmanaged byte array to the “Load_3” method which loads the assembly into the app domain.

SAFEARRAYBOUND bounds[1];

bounds[0].cElements = sizeof (rawAssemblyByteArray);

bounds[0].lLbound = 0;

SAFEARRAY* safeArray = SafeArrayCreate(VT_UI1, 1, bounds);

SafeArrayLock(safeArray);

memcpy(safeArray->pvData, rawAssemblyByteArray, sizeof (rawAssemblyByteArray));

SafeArrayUnlock(safeArray);

• Load the assembly to the AppDomain:

_AssemblyPtr  managedAssembly = NULL;

defaultAppDomain->Load_3(safeArray, &managedAssembly)

• Find an entry point to the loaded assembly:

_MethodInfoPtr  pMethodInfo = NULL;

managedAssembly->get_EntryPoint(&pMethodInfo)

• Call the entry point:

pMethodInfo->Invoke_3(VARIANT(), SafeArray_Pointer_To_Arguement , &VARIANT())

The second parameter for the “Invoke_3” function is the SafeArray pointer to the arguments that will be passed to the MSIL payload.

ShellCode Executing Managed Code from a Native Code Using CLR hosting

Next, the shellcode calls the “CLRCreateInstance” API from mscoree.dll. The CLRCreateInstance API returns the new CLR MetaHost instance which will be used by malware to prepare a runtime so it can execute the MSIL AgentTesla payload in memory.

We can see in the below figure that multiple GUIDs have been used while retrieving CLR Hosting Interfaces, for e.g., to retrieve “ICorRuntimeHost” interface, it passed “CLSID_CorRuntimeHost” ,  “IID_ICorRuntimeHost” as an argument to the “GetInterface” API.

Figure 7: GUID used while CLR hosting

Next, the shellcode retrieves the ICorRuntimeHost interface and starts the CLR.

Figure 8: Call to GetInterface API to retrieve the ICorRuntimeHost interface

Figure 9: Call start method from ICorRuntimeHost interface to start CLR

Next, the shellcode retrieves the default app domain for the current process, as shown below.

Figure 10: Retrieve the default AppDomain for the current process.

Next, the shellcode creates SafeArray using the “SafeArrayCreate“ API by passing an argument as the size of managed code which is 0x3CC00. This SafeArray does have a pointer to the buffer where malware copies the MSIL payload.

Figure 11: Create a SafeArray and copy AgentTesla payload to it

Once a SafeArray was created, it could be loaded into an AppDomain with the “Load_3” method, this “Load_3” method gives a pointer to an Assembly object.

Figure 12:  Calls “Load_3” method to load the SafeArray into AppDomain

Next, the shellcode zeros out the MSIL payload from the region where it got decrypted then it destroys the SafeArray using the “SafeArrayDestroy” API.

Finally, the shellcode retrieves the entry point for the assembly and calls the “Invoke_3” method to start the 32-bit MSIL AgentTesla process within the context of the 64-bit native process.

Figure 13: Starts the MSIL AgentTesla process

Figure 14: Browser folder enumerated by 64-bit process once the fileless managed code injection has been done

In Figure 14 above, it looks like the 64-bit process is enumerating the browser folder, but its AgentTesla malware started its execution within the .NET engine.

SonicWall Protections

SonicWall Capture Labs provides protection against analyzed 64-bit executable (4521162d45efc83fa76c4b5c0d405265) as GAV: MalAgent.QZ (Trojan).

This threat was also detected by SonicWall Capture ATP w/RTDMI.

The initial infection vector which is a Word document file has been detected by SonicWall Capture ATP w/RTDMI.

IOCs

Document file:

MD5 : D99020C900069E737B3F4AB8C6947375

SHA256 : A6562D8F34D4C25A94313EBBED1137514EED90B233A94A9125E087781C733B37

64-bit downloaded executable:

MD5 : 4521162D45EFC83FA76C4B5C0D405265

SHA256 : F00ED06A1D402ECF760EC92F3280EF6C09E76036854ABACADCAC9311706ED97D

Shellcode blob:

MD5 : CD485BF146E942EC6BB51351FA42B1FF

SHA256 : 02C03E2E8CA28849969AE9A8AAA7FDE8A8B918B5A29548840367F3ECAC543E2D

Injected AgentTesla Payload:

MD5 : 6999D02AA08B56EFE8B2DBBD6FDC9A78

SHA256 : 7B6867606027BFCA492F95E2197A3571D3332D59B65E1850CB20AA6854486B41

URLs used by malware:

https[:]//New-Coder[.]cc/Users/signed_20240329011751156[.]exe  (64-bit exe downloaded)

https[:]//New-Coder[.]cc/Users/shellcodeAny_20240329011339585[.]bin (shellcode downloaded)

Overview

The SonicWall Capture Labs threat research team became aware of a noteworthy vulnerability—an Unauthenticated Template Injection —in Atlassian Confluence platforms, assessed its impact and developed mitigation measures for it. Atlassian’s Confluence Server and Data Center published an advisory on this vulnerability affecting multiple Confluence releases. Confluence is a web-based corporate wiki software. Atlassian wrote Confluence in the Java programming language and it is utilized for collaboration, project management, process and quality management, and knowledge management.

This vulnerability is identified as CVE-2023-22527 and was assigned a critical CVSS score of 10.0.  Considering the sizeable user base, low attack complexity and publicly available exploit code(s) including a Metasploit module, Confluence users are strongly encouraged to upgrade their instances to the latest versions with utmost priority. According to ShadowServer, around 11,000 Atlassian Confluence instances are publicly exposed, and adversaries are scanning for vulnerable instances.

As per the advisory, the affected Confluence Data Center and Server versions are 8.0.x, 8.1.x, 8.2.x, 8.3.x, 8.4.x, and 8.5.0-8.5.3.

Technical Overview

This vulnerability allows threat actors to circumvent the authentication mechanism by sending a crafted request to the web server.

The primary condition that led to exploiting the vulnerability in Atlassian’s Confluence Server and Data Center is improper user input handling. As a result, attackers can leverage the injection of malicious templates without any authentication, leading to remote code execution. As Confluence is written in Java, OGNL expressions are associated with code. A specially crafted exploit that can inject an arbitrary OGNL object can execute Java code. When the application fails to validate and sanitize user input before using it in OGNL expressions, it may lead to an OGNL injection vulnerability. In OGNL injection attacks, nefarious actors input specially crafted strings containing OGNL expressions into user interfaces or input fields. When the application processes this input without proper validation, the injected OGNL expressions get executed within the application’s context. This can lead to various security issues, including authentication bypass, unauthorized access to sensitive data and remote code execution.

Triggering the Vulnerability

Within the Confluence server, it was observed that actual “views” are rendered using Velocity template files. To trigger the vulnerability, an attacker sends a POST request to “/template/aui/text-inline.vm”, demonstrating that including a .vm file helps get a hands-on unauthenticated attack surface to the Confluence instance. In this scenario, findValue is an OGNL expression that accepts a crafted string in $parameters that are not sanitized properly. As seen in Figure 2, using the OGNL expression #request[‘.KEY_velocity.struts2.context’].internalGet(‘ognl’) will grant access to the class  org.apache.struts2.views.jsp.ui.OgnlTool and calls the method Ognl.findValue(String, Object) method. Furthermore, in a comparison between the unpatched Confluence instance and the patched one, there is a .vm file named text-inline.vm. Figure 1 shows the text-inline.vm file code – the one that is deprecated in patched versions of Confluence.

Figure 1: text-inline.vm

Attackers can leverage this vm file to create a payload utilizing #parameters which pass arguments to the exec method, bypassing authentication and executing system commands.

Figure 2: CVE-2023-22527 OGNL payload

A crafted POST request sent to unpatched Confluence servers leads to OGNL template injection, which results in arbitrary command execution. By changing the payload parameter value, one can execute different commands remotely.

The attack request has the command id injected in the exec() function, as shown in Figure 3. Once this crafted request is sent, the response from the server includes the user id(uid), group id (gid), and groups from the Confluence server.

Figure 3: CVE-2023-22527 attack request

Exploiting the Vulnerability

The working PoC is an exploit tool for Confluence servers vulnerable to CVE-2023-22527. It leads to RCE in vulnerable instances of Confluence data centers and servers. Using this, an attacker can execute arbitrary code on a vulnerable instance.

Figure 4: CVE-2023-22527 PoC

SonicWall Protections

To ensure SonicWall customers are prepared for any exploitation that may occur due to this vulnerability, the following signatures have been released:

• IPS: 2366 – Atlassian Confluence Data Center and Server SSTI
• IPS: 4249 – Atlassian Confluence Data Center and Server SSTI 2

Remediation Recommendations

Considering the severe consequences of this vulnerability and the trending of unauthenticated nefarious activists trying to get Confluence Data Center & Confluence Server access using the exploit in the wild, users are strongly encouraged to upgrade their instances as published in the vendor advisory.

Relevant Links

• NVD
• GitHub PoC
• Packet storm
• Atlassian Confluence Advisory
• CONFSERVER-93833
• Nuclei template
• ProjectDiscovery blog
• SANS

Overview

The SonicWall Capture Labs threat research team analyzed a malware purporting to be a Java utility. It arrives as an installer for Java Access Bridge, but ultimately installs the popular open-source cryptominer, XMRig.

Infection Cycle

The sample arrives as a Windows installer package (msi) file using the following file name:

• JavaAccessBridge-64.msi

Figure 1: Malware installer’s file properties showing Java Access Bridge

Upon execution, a typical installation window pops up.

Figure 2: Fake Java Access Bridge installation window

Meanwhile, the following files are created in these directories:

• /User/Public/Music/ContentStore.bat
• /User/Public/Music/DMIDD11.tmp (certificate file)
• /User/Public/Music/DMIDD12.tmp (certificate file)
• /User/Public/Music/DMIDD13.tmp (certificate file)
• /User/Public/Music/DMIDD14.tmp (certificate file)
• /User/Public/Videos/JavaAccessBridge-64.exe (main XMRig executable)
• /User/Public/Videos/config.json (miner config file)
• /User/Public/Videos/WinRing0x64.sys (WinRing0 driver file used by XMRig)

The Windows command prompt utility is then spawned to execute the batch file name ContentStore.bat which runs the commands seen on the screenshot below.

Figure 3: Contents of the batch file ContentStore.bat

The .tmp files created are all certificate files as shown in the screenshot below.

Figure 4: DMIDD14.tmp contains a certificate

The main cryptominer file is then executed via the command line.

Figure 5: Initial execution of JavaAccessBridge-64.exe via the command line.

XMRig is ran using the configuration in the config.json file.

Figure 6: Configuration in the config.json file

Figure 7: XMRig window running in the background

We urge our users to only use official and reputable websites as their source for software downloads. Always be vigilant and cautious when installing software programs – particularly if you are not certain of the source.

SonicWall Protections

SonicWall Capture Labs provides protection against this threat via the following signatures:

• GAV: Malagent.JAV (Trojan)
• GAV: XMRig.XMR_4 (Trojan)

This threat is also detected by SonicWall Capture ATP w/RTDMI and Capture Client endpoint solutions.