Tweet Get answers and solutions instantly by using VMware’s Knowledge Base (KB) articles to solve known issues. Whether you’re looking to improve your productivity, troubleshoot common issues, or simply learn something new, these most used and most viewed knowledge articles are a great place to start. Here are the top 5 most viewed KB articles … Continued
The Australian Signals Directorate’s Australian Cyber Security Centre (ACSC), U.S. Cybersecurity and Infrastructure Security Agency (CISA), and U.S. National Security Agency (NSA) are releasing this joint Cybersecurity Advisory to warn vendors, designers, and developers of web applications and organizations using web applications about insecure direct object reference (IDOR) vulnerabilities. IDOR vulnerabilities are access control vulnerabilities enabling malicious actors to modify or delete data or access sensitive data by issuing requests to a website or a web application programming interface (API) specifying the user identifier of other, valid users. These requests succeed where there is a failure to perform adequate authentication and authorization checks.
These vulnerabilities are frequently exploited by malicious actors in data breach incidents because they are common, hard to prevent outside the development process, and can be abused at scale. IDOR vulnerabilities have resulted in the compromise of personal, financial, and health information of millions of users and consumers.
ACSC, CISA, and NSA strongly encourage vendors, designers, developers, and end-user organizations to implement the recommendations found within the Mitigations section of this advisory—including the following—to reduce prevalence of IDOR flaws and protect sensitive data in their systems.
Vendors, designers, and developers of web application frameworks and web applications: Implement secure-by-design and -default principles and ensure software performs authentication and authorization checks for every request that modifies, deletes, and accesses sensitive data.
Use automated tools for code review to identify and remediate IDOR and other vulnerabilities.
Use indirect reference maps, ensuring that IDs, names, and keys are not exposed in URLs. Replace them with cryptographically strong, random values—specifically use a universally unique identifier (UUID) or a globally unique identifier (GUID).
Exercise due diligence when selecting third-party libraries or frameworks to incorporate into your application and keep all third-party frameworks and dependencies up to date.
All end-user organizations, including organizations with software-as-a-service (SaaS) models:
Use due diligence when selecting web applications. Follow best practices for supply chain risk management and only source from reputable vendors.
Apply software patches for web applications as soon as possible.
Review the available authentication and authorization checks in web applications that enable modification of data, deletion of data, or access to sensitive data.
Conduct regular, proactive vulnerability scanning and penetration testing to help ensure internet-facing web applications and network boundaries are secure.
IDOR vulnerabilities are access control vulnerabilities in web applications (and mobile phone applications [apps] using affected web API) that occur when the application or API uses an identifier (e.g., ID number, name, or key) to directly access an object (e.g., a database record) but does not properly check the authentication or authorization of the user submitting the request. Depending on the type of IDOR vulnerability, malicious actors can access sensitive data, modify or delete objects, or access functions.
Horizontal IDOR vulnerabilities occur when a user can access data that they should not be able to access at the same privilege level (e.g., other user’s data).
Vertical IDOR vulnerabilities occur when a user can access data that they should not be able to access because the data requires a higher privilege level.
Object-level IDOR vulnerabilities occur when a user can modify or delete an object that they should not be able to modify or delete.
Function-level IDOR vulnerabilities occur when a user can access a function or action that they should not be able to access.
Typically, these vulnerabilities exist because an object identifier is exposed, passed externally, or easily guessed—allowing any user to use or modify the identifier.
In body manipulation, an actor modifies the HTML form field data in the body of a POST request to impact targeted records.
In URL tampering, an actor modifies an identifier in URLs to impact targeted records.
In cookie ID manipulation, the actor modifies an identifier in a cookie to an identifier of a different user (including administrative users) in an attempt to gain access to that account.
In HTTP/JSON request tampering, an actor uses a web proxy to intercept and alter arbitrary portions of legitimate requests, including values inside JSON objects.
Impact
These vulnerabilities are common[1] and hard to prevent outside the development process since each use case is unique and cannot be mitigated with a simple library or security function. Additionally, malicious actors can detect and exploit them at scale using automated tools. These factors place end-user organizations at risk of data leaks (where information is unintentionally exposed) or large-scale data breaches (where a malicious actor obtains exposed sensitive information). Data leaks or breaches facilitated by IDOR vulnerabilities include:
An October 2021 global data leak incident where mobile phone data, including text messages, call records, photos, and geolocation from hundreds of thousands of devices was exposed by insecure “stalkerware” apps.[2] The apps collected and relayed data from the phones to the same foreign server infrastructure, which contained an IDOR vulnerability, CVE-2022-0732.[3] This led to exposure of the collected app data.[4]
A 2019 data breach incident where more than 800 million personal financial files, including bank statements, bank account numbers, and mortgage payment documents, from a U.S. Financial Services Sector organization were exposed.[5],[6]
A 2012 data breach incident where a malicious cyber actor obtained the personal data of more than 100,000 mobile device owners from a U.S. Communications Sector organization’s publicly accessible website.[7]
MITIGATIONS
Vendors and Developers
ACSC, CISA, and NSA recommend that vendors, designers, and implementors of web applications—including organizations that build and deploy software (such as HR tools) for their internal use and organizations that create open-source projects—implement the following mitigations. These mitigations may reduce prevalence of IDOR vulnerabilities in software and help ensure products are secure-by-design and -default.
Implement and inject secure-by-design and -default principles and best practices into each stage of the software development life cycle (SDLC). Particular recommended practices are defined in the National Institute of Security and Technology’s (NIST’s) Secure Software Development Framework (SSDF), SP 800-218. Lend special attention to:
Conducting code reviews [SSDF PW 7.2, RV 1.2] against peer coding standards, checking for backdoors, malicious content, or logic flaws.
ACSC, CISA, and NSA recommend using automated code analysis tools for all supported releases to identify and remediate vulnerabilities.
Following secure coding practices [SSDF PW 5.1] for web and mobile applications to ensure that they properly validate user input and generate strong user IDs.
Use indirect reference maps, such that IDs, names, and keys are not exposed in URLs. Replace them with cryptographically strong, random values—specifically use a UUID or a GUID. Note: UUIDs and GUIDs should not be used for security capabilities. See Request for Comment (RFC) 4122 for more information.
Configure applications to deny access by default and ensure the application performs authentication and authorization checks for every request to modify data, delete data, and access sensitive data. For example:
Normalize requests. There are many ways to encode and decode web inputs. Decode and normalize inputs before creating access control checkpoints. Ensure the access control system and other parts of the web application perform the same normalization.
Implement parameter verification leveraging syntactic and logical validation, such that web applications validate all inputs received with every HTTP/S request. Denying invalid requests can reduce the burden on the access control system.
Syntactic validation verifies that for each input the incoming value meets your applications’ expectations. When doing syntactic validation, verify that strings are within the minimum and maximum length required, strings do not contain unacceptable characters, numeric values are within the minimum and maximum boundaries, and the input is of the proper data type.
Logical validation adds checks to see if the input values make sense and are consistent with design intent. When doing logical validation, verify authorization checks are performed in the correct locations, are of varying pedigree, and that there is error handling of failed authentication and authorization requests.
Use CAPTCHA to limit automated invalid user requests where feasible.
Use memory-safe programming languages where possible.
Testing code to identify vulnerabilities and verify compliance with security requirements [SSDF PW 8.2].
Use automated testing tools to facilitate testing, fuzz testing tools to find issues with input handling,[8] and penetration testing to simulate how a threat actor may exploit the software. Consider using dynamic application security testing (DAST) tools to identify IDOR vulnerabilities in web applications.
Conducting role-based training [SSDF PO 2.2] for personnel responsible for secure software development.
Exercising due diligence when selecting third-party libraries or frameworks to incorporate into your application [SSDF PW 4.1].
Review and evaluate third-party components in the context of their expected use.
Verify the integrity of the product through hash or signature verification.
If provided, review component’s Software Bill of Materials (SBOM) for outdated, vulnerable, or unauthorized applications before using it.
Keep all third-party frameworks and dependencies up to date to limit vulnerability inheritance. Note: Organizations should maintain an inventory or catalog of third-party frameworks and dependencies to assist with proactive updates. Consider using tools to identify project dependencies and known vulnerabilities in third-party code. See OWASP’s Top Ten Proactive Controls 2018, C2: Leverage Security Frameworks and Libraries, for more information.
Establish a vulnerability disclosure program to verify and resolve security vulnerabilities disclosed by people who may be internal or external to the organization.
Additionally, ACSC, CISA, and NSA recommend following cybersecurity best practices in production and enterprise environments. Software developers are high-value targets because their customers deploy software on their own trusted networks. For best practices, see:
ACSC’s Essential Eight. The Essential Eight are prioritized strategies to help cybersecurity professionals mitigate cybersecurity incidents caused by various cyber threats.
CISA’s Cross-Sector Cybersecurity Performance Goals (CPGs). The CPGs, developed by CISA and NIST, are a prioritized subset of IT and OT security practices that can meaningfully reduce the likelihood and impact of known cyber risks and common tactics, techniques, and procedures. Because the CPGs are a subset of best practices, ACSC, CISA, and NSA also recommend software manufacturers implement a comprehensive information security program based on a recognized framework, such as the NIST Cybersecurity Framework (CSF).
NSA’s Top Ten Cybersecurity Mitigations. The Top Ten sets priorities for enterprise activities to counter a broad range of exploitation techniques and minimize mission impact.
All End-User Organizations
ACSC, CISA, and NSA recommend that all end-user organizations, including those with on-premises software, SaaS, IaaS, and private cloud models, implement the mitigations below to improve their cybersecurity posture.
Exercise due diligence when selecting web applications. Follow best practices for supply chain risk management and source from reputable vendors that demonstrate commitment to secure-by-design and -default principles.
Verify the integrity of the product through hash or signature verification.
If provided, review the SBOM for outdated, vulnerable, or unauthorized applications before using the product.
Apply software patches for web applications as soon as possible.
Configure the application to log and generate alerts from tamper attempts—with this information, network defenders can investigate and take appropriate follow-on actions.
Establish a baseline to efficiently identify abnormal behavior. Note: Web application error codes such as HTTP 404 and HTTP 403 are associated with common enumeration techniques.
Aggregate logs into a centralized solution (e.g., a security information and event management [SIEM] tool) to facilitate active monitoring and threat hunting.
Create, maintain, and exercise a basic cyber incident response plan (IRP) and associated communications plan. Plans should include response and notification procedures for data breach and cyber incidents. For more information, see:
CISA: Federal Government Cybersecurity Incident and Vulnerability Response Playbook (Although tailored to U.S. Federal Civilian Branch (FCEB) agencies, these playbooks provide operational procedures for planning and conducting cybersecurity incident and vulnerability response activities and detail steps for both incident and vulnerability response.)
End-User Organizations with On-Premises Software, IaaS, or Private Cloud Models
ACSC, CISA, and NSA recommend that organizations:
Conduct regular, proactive penetration testing to ensure network boundaries, as well as web applications, are secure. Prioritize web applications that are internet-facing and contain user login functionality. Such testing may be beyond the technical or financial capabilities of some organizations. Consider using a trusted third party for penetration testing to discover new attack vectors (notably prior to deployment of new or altered internet-facing services). Note: Organizations should consult with their legal counsel as appropriate to determine which systems and applications can be included in the scope of the penetration testing.
Use web application penetration testing tools to capture the user identifier sent to the web server when requesting a web page containing sensitive data and map all locations where user input is used to reference objects directly. Test with users of various privilege levels (e.g., a normal user and admin user).
Use DAST and other vulnerability scanners to detect IDOR vulnerabilities. DAST tools identify vulnerabilities in web applications with penetration tests and generate automated alerts. Note: Exercise due diligence when selecting DAST tools. Not all DAST tools can detect IDOR vulnerabilities—tools with the ability may need the environment configured in a specific way and may also need custom rules in place. Sufficient DAST tools often ingest the application API documentation to build a model of the application. While these tools can be used to detect IDOR vulnerabilities, they are not foolproof and should be used with other security testing methods to ensure comprehensive coverage.
Immediately report detected vulnerabilities to the vendor or developer. Alternatively (or if the vendor or developer fails to respond), report the vulnerability to CISA at cisa.gov/report.
Consider establishing a vulnerability disclosure program to verify, resolve, and report security vulnerabilities disclosed by people who may be internal or external to the organization.
Use a web application firewall (WAF) to filter, monitor, and block malicious HTTP/S traffic traveling to the web application.
Use a data loss prevention (DLP) tool to prevent unauthorized data from leaving the application.
ACSC, CISA, and NSA recommend that organizations with on-premises software or IaaS consider using SaaS models for their internet-facing websites.
End-User Organizations with SaaS Models
Organizations leveraging SaaS with sufficient resources may consider conducting penetration testing and using vulnerability scanners. However, such tests may interfere with service provider operations. Organizations should consult with their legal counsel as appropriate to determine what can be included in the scope of the penetration testing.
INCIDENT RESPONSE
If you or your organization are victim to a data breach or cyber incident, follow relevant cyber incident response and communications plans, as appropriate.
Australia: Australian organizations that have been impacted or require assistance in regards to a cybersecurity incident can contact ACSC via 1300 CYBER1 (1300 292 371), or by submitting a report to cyber.gov.au.
United States: U.S. organizations may report cybersecurity incidents to CISA’s 24/7 Operations Center at Report@cisa.dhs.gov, cisa.gov/report, or (888) 282-0870. When available, please include the information regarding the incident: date, time, and location of the incident; type of activity; number of people affected; type of equipment used for the activity; the name of the submitting company or organization; and a designated point of contact.
The information in this report is being provided “as is” for informational purposes only. ACSC, CISA, and NSA do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply its endorsement, recommendation, or favoring by the United States or Australian Governments, and this guidance shall not be used for advertising or product endorsement purposes.
PURPOSE
This document was developed in furtherance of the authors’ cybersecurity missions, including their responsibilities to identify and disseminate threats, and to develop and issue cybersecurity specifications and mitigations. This information may be shared broadly to reach all appropriate stakeholders.
The Cybersecurity and Infrastructure Security Agency (CISA) is releasing this Cybersecurity Advisory to warn network defenders about exploitation of CVE-2023-3519, an unauthenticated remote code execution (RCE) vulnerability affecting NetScaler (formerly Citrix) Application Delivery Controller (ADC) and NetScaler Gateway. In June 2023, threat actors exploited this vulnerability as a zero-day to drop a webshell on a critical infrastructure organization’s non-production environment NetScaler ADC appliance. The webshell enabled the actors to perform discovery on the victim’s active directory (AD) and collect and exfiltrate AD data. The actors attempted to move laterally to a domain controller but network-segmentation controls for the appliance blocked movement.
The victim organization identified the compromise and reported the activity to CISA and Citrix. Citrix released a patch for this vulnerability on July 18, 2023.
This advisory provides tactics, techniques, and procedures (TTPs) and detection methods shared with CISA by the victim. CISA encourages critical infrastructure organizations to use the detection guidance included in this advisory for help with determining system compromise. If potential compromise is detected, organizations should apply the incident response recommendations provided in this CSA. If no compromise is detected, organizations should immediately apply patches provided by Citrix.
TECHNICAL DETAILS
Note: This advisory uses the MITRE ATT&CK for Enterprise framework, version 13. See the MITRE ATT&CK Tactics and Techniques section for a table of the threat actors’ activity mapped to MITRE ATT&CK® tactics and techniques. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.
Overview
In July 2023, a critical infrastructure organization reported to CISA that threat actors may have exploited a zero-day vulnerability in NetScaler ADC to implant a webshell on their non-production NetScaler ADC appliance. Citrix confirmed that the actors exploited a zero-day vulnerability: CVE-2023-3519. Citrix released a patch on July 18, 2023.[1]
CVE-2023-3519
CVE-2023-3519 is an unauthenticated RCE vulnerability affecting the following versions of NetScaler ADC and NetScaler Gateway:[1]
NetScaler ADC and NetScaler Gateway 13.1 before 13.1-49.13
NetScaler ADC and NetScaler Gateway 13.0 before 13.0-91.13
NetScaler ADC and NetScaler Gateway version 12.1, now end of life
NetScaler ADC 13.1-FIPS before 13.1-37.159
NetScaler ADC 12.1-FIPS before 12.1-65.36
NetScaler ADC 12.1-NDcPP before 12.65.36
The affected appliance must be configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) or authentication, authorization, and auditing (AAA) virtual server for exploitation.[1]
As part of their initial exploit chain [T1190], the threat actors uploaded a TGZ file [T1105] containing a generic webshell [T1505.003], discovery script [TA0007], and setuid binary [T1548.001] on the ADC appliance and conducted SMB scanning on the subnet [T1046].
The actors used the webshell for AD enumeration [T1016] and to exfiltrate AD data [TA0010]. Specifically, the actors:
Viewed NetScaler configuration files /flash/nsconfig/keys/updated/* and /nsconfig/ns.conf [T1005]. Note: These configuration files contain an encrypted password that can be decrypted by the key stored on the ADC appliance [T1552.001].
Viewed the NetScaler decryption keys (to decrypt the AD credential from the configuration file) [T1552.004].
Used the decrypted AD credential to query the AD via ldapsearch. The actors queried for:
Used the following command to encrypt discovery data collected via openssl in “tar ball” [T1560.001]: tar -czvf - /var/tmp/all.txt | openssl des3 -salt -k <> -out /var/tmp/test.tar.gz. (A “tar ball” is a compressed and zipped file used by threat actors for collection and exfiltration.)
Exfiltrated collected data by uploading as an image file [T1036.008] to a web-accessible path [T1074]: cp /var/tmp/test.tar.gz /netscaler/ns_gui/vpn/medialogininit.png.
The actors’ other discovery activities were unsuccessful due to the critical infrastructure organization’s deployment of their NetScaler ADC appliance in a segmented environment. The actors attempted to:
Execute a subnet-wide curl command to identify what was accessible from within the network as well as potential lateral movement targets.
Verified outbound network connectivity with a ping command (ping -c 1 google.com) [T1016.001].
Executed host commands for a subnet-wide DNS lookup.
The actors also attempted to delete their artifacts [TA0005]. The actors deleted the authorization configuration file (/etc/auth.conf)—likely to prevent configured users (e.g., admin) from logging in remotely (e.g., CLI) [T1531]. To regain access to the ADC appliance, the organization would normally reboot into single use mode, which may have deleted artifacts from the device; however, the victim had an SSH key readily available that allowed them into the appliance without rebooting it.
The actors’ post-exploitation lateral movement attempts were also blocked by network-segmentation controls. The actors implanted a second webshell on the victim that they later removed. This was likely a PHP shell with proxying capability. The actors likely used this to attempt proxying SMB traffic to the DC [T1090.001] (the victim observed SMB connections where the actors attempted to use the previously decrypted AD credential to authenticate with the DC from the ADC via a virtual machine). Firewall and account restrictions (only certain internal accounts could authenticate to the DC) blocked this activity.
MITRE ATT&CK TACTICS AND TECHNIQUES
See Table 1–Table 9 for all referenced threat actor tactics and techniques in this advisory.
Table 1: Cyber Threat Actors ATT&CK Techniques for Initial Access
The threat actors attempted to execute a subnet-wide curl command to identify what was accessible from within the network as well as potential lateral movement targets. Network-segmentation controls prevented this activity.
System Network Configuration Discovery: Internet Connection Discovery
The threat actors attempted to verify outbound network connectivity with a ping command and executed host commands for a subnet-wide DNS lookup. Network-segmentation controls prevented this activity.
The threat actors exploited CVE-2023-3519 to upload a TGZ file containing a generic webshell, discovery script, and setuid binary on the ADC appliance.
DETECTION METHODS
Run the following victim-created checks on the ADC shell interface to check for signs of compromise:
Check for files newer than the last installation.
Modify the -newermt parameter with the date that corresponds to your last installation:
find /netscaler/ns_gui/ -type f -name *.php -newermt [YYYYMMDD] -exec ls -l {} ;
find /var/vpn/ -type f -newermt [YYYYMMDD] -exec ls -l {} ;
find /var/netscaler/logon/ -type f -newermt [YYYYMMDD] -exec ls -l {} ;
find /var/python/ -type f -newermt [YYYYMMDD] -exec ls -l {} ;
Check http error logs for abnormalities that may be from initial exploit:
grep '.sh' /var/log/httperror.log*
grep '.php' /var/log/httperror.log*
Check shell logs for unusual post-ex commands, for example:
Review network and firewall logs for subnet-wide scanning of HTTP/HTTPS/SMB (80/443/445) originating from the ADC.
Review DNS logs for unexpected spike in internal network computer name lookup originating from the ADC (this may indicate the threat actor resolving host post-AD enumeration of computer objects).
Review network/firewall logs for unexpected spikes in AD/LDAP/LDAPS traffic originating from the ADC (this may indicate AD/LDAP enumeration).
Review number of connections/sessions from NetScaler ADC per IP address for excessive connection attempts from a single IP (this may indicate the threat actor interacting with the webshell).
Pay attention to larger outbound transfers from the ADC over a short period of session time as it can be indicative of data exfiltration.
Review AD logs for logon activities originating from the ADC IP with the account configured for AD connection.
If logon restriction is configured for the AD account, check event 4625 where the failure reason is “User not allowed to logon at this computer.”
Review NetScaler ADC internal logs (sh.log*, bash.log*) for traces of potential malicious activity (some example keywords for grep are provided below):
database.php
ns_gui/vpn
/flash/nsconfig/keys/updated
LDAPTLS_REQCERT
ldapsearch
openssl + salt
Review NetScaler ADC internal access logs (httpaccess-vpn.log*) for 200 successful access of unknown web resources.
INCIDENT RESPONSE
If compromise is detected, organizations should:
Quarantine or take offline potentially affected hosts.
Reimage compromised hosts.
Provision new account credentials.
Collect and review artifacts such as running processes/services, unusual authentications, and recent network connections.
Report the compromise to CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870).
Follow best cybersecurity practices in your production and enterprise environments, including mandating phishing-resistant multifactor authentication (MFA) for all staff and for all services. For additional best practices, see CISA’s Cross-Sector Cybersecurity Performance Goals (CPGs). The CPGs, developed by CISA and the National Institute of Standards and Technology (NIST), are a prioritized subset of information technology (IT) and operational technology (OT) security practices that can meaningfully reduce the likelihood and impact of known cyber risks and common TTPs. Because the CPGs are a subset of best practices, CISA and ACSC also recommend software manufacturers implement a comprehensive information security program based on a recognized framework, such as the NIST Cybersecurity Framework (CSF).
As a longer-term effort, apply robust network-segmentation controls on NetScaler appliances, and other internet-facing devices.
VALIDATE SECURITY CONTROLS
In addition to applying mitigations, CISA recommends exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. CISA recommends testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.
To get started:
Select an ATT&CK technique described in this advisory (see Table 1–Table 9).
Align your security technologies against the technique.
Test your technologies against the technique.
Analyze your detection and prevention technologies’ performance.
Repeat the process for all security technologies to obtain a set of comprehensive performance data.
Tune your security program, including people, processes, and technologies, based on the data generated by this process.
CISA recommends continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.
We have recently released another preview of the TextUtility module. This module is a collection of tools that
are meant to help with working with text content.
Installing the module
You can install this module from the PowerShellGallery with PowerShellGet via:
The most recent pre-release of Microsoft.PowerShell.TextUtility
has some new exciting functionality.
The new ConvertFrom-TextTable cmdlet allows you to take tabular text
and convert it into objects.
Also, there is a way to convert some of types of those objects into something other than a string.
Using the -ConvertPropertyValue parameter will change the value of the property to a strongly typed value.
This means you can do the following:
ConvertFrom-TextTable also allows you to specify where the header line is defined, or skip lines until you get to where the data starts.
Additionally, it is possible to take the text output and explicitly create properties by defining where a column starts.
This is still in pre-release and we know that there is still work to be done.
For example, the parser will create an object out of the header/data separator.
This is a little trickier than at first it would seem.
The text is inspected and columns width is decided based on the inspected text.
These header/data separator lines help the parser understand where the columns are separated.
This means we can’t just toss them out as the text is being read.
I’m sure you’ll find more things that we can do,
and we would love to get your feedback on this new cmdlet so please give this module a try.
Please submit your feedback to the repo directly via the issues tab, here.
We are excited to announce the first release of our JSON Adapter Feedback Provider! If you are
unfamiliar with what feedback providers are, check out this blog describing them, here.
To use it you will need to import the module into your session via:
Import-Module Microsoft.PowerShell.JsonAdapter
We encourage you to include the import message in your $PROFILE so it can persistently be loaded
in every PowerShell session you start. If you have Visual Studio Code installed, type code $PROFILE to edit your profile or use your choice of editor.
What are JSON Adapters?
A JSON adapter is a script that can parse the text output of a native executable and convert it to
JSON. Once the output is in a machine readable format like JSON, you can use ConvertFrom-JSON
cmdlet to make any native executable behave like a PowerShell object. JSON adapters can be made for
any command, it is just required to use the exact name of the command as the prefix to the script.
The script will have to be named like so <name of command>-json.ps1 to be identified by the JSON
adapter utility. This script’s file location must also be added to your $env:PATH variable to be
found.
Creating a JSON Adapter
For example, say you are on a Mac and want to use the command vm_stat like a PowerShell object. If
you add the following to a file called vm_stat-json.ps1 and add the location of this file to your $env:PATH variable, the JSON Adapter feedback provider will identify it as a possible suggestion
for vm_stat.
This is what the experience looks like in the shell.
JC
JC or JSON Converter, is a command line utility that can convert text to JSON for variety of command
line tools. You can find instructions on how to install jc and a full list of supported commands
on the repo of jc. It can be a great tool to use to convert the outputs without writing a JSON
Adapter yourself. The JSON Adapter module supports using jc as a JSON Adapter if the user has it
installed. This means if you have the jc utility installed and use a command that is supported by JC, the JSON
Adapter feedback provider will suggest using JC piped to ConvertFrom-JSON.
It is important to note that not all jc supported utilities are supported. The list of supported commands is:
Additionally, you will need to use the appropriate parameters that jc requires to work properly. For
example, if you want to use jc with uname, you will need to use uname -a as that is what jc
requires to properly convert the output to JSON.
Predictive IntelliSense Support
We have also added predictive IntelliSense support for the JSON Adapter feedback provider. This
means after a JSON Adapter feedback provider is triggered, as you type the command name again,
Predictive Intellisense will suggest the feedback command to you. This is a great way to easily try
the suggestion after a JSON Adapter feedback provider is triggered.
Feedback
As this is our very first release, we know there may be issues that arise. We definitely look
forward to your feedback and suggestions! You can provide feedback on the repo for this project here.
We introduced a new experimental feature back in PowerShell v7.4.0-preview.2+ called PSFeedbackProvider. This blog outlines what this experimental feature is, how to use it and
describes different feedback providers we have already created.
Installing the PowerShell Preview and enabling Feedback Providers
You can install the latest 7.4 preview via our GitHub page here. If you are on Windows you can
download via the Microsoft store here.
Unless configured differently, the previews should have all experimental features enabled by deafult
but in case they are not enabled you can check and enable them by using the following commands:
You must restart your PowerShell session to enable experimental features.
Why have we created Feedback Providers
After we created PowerShell Predictive IntelliSense, we realized that no matter how hard we can try
to be “preventative” of errors, they will still occur. This made us think there was a better way to
give the users more feedback to their errors so they could recover quicker from them.
After prototyping and seeing how great it could work for errors, we got thinking that maybe we can
help inform and teach users better practices to the shell and thus we expanded feedback providers to
successful executions and comments.
What are Feedback Providers?
Feedback Providers are PowerShell modules that utilize the IFeedbackProvider interface to give
feedback and suggestions after the shell users have attempted to execute something. Feedback
providers can trigger upon three different interactive scenarios:
Errors
Success
Comments
This means after the user has hit enter, Feedback Providers can trigger and know what scenario the
user has faced.
Built in Feedback Provider
We have created a built in feedback provider named General. This triggers on the CommandNotFound
exception error and gives the user suggestions on what command they may have meant to type from list
of commands already installed in the users $env:PATH. Both native commands and PowerShell cmdlets
will be suggested if they are installed.
You have may seen something similar to this before in previous versions of the PSCommandNotFoundSuggestion experimental feature. We have given the UX an upgraded and turned this
into a feedback provider!
This is the old PSCommandNotFoundSuggestion experience:
This is the same feature but with the new feedback provider model:
Command-Not-Found Feedback Provider
We have created an additional feedback provider that we call the command-not-found feedback
provider. This utilizes the command-not-found utility tool that is defaulted on Ubuntu systems.
This feedback provider will trigger when the user has attempted to execute a command that is not
installed on the system but will give the user suggestions on how to install the command on their
system using apt. This is only compatible with Linux systems where the command-not-found utility
tool has been installed.
Another thing we did with this feedback provider is that we have it subscribed to the ICommandPredictor interface so that it can give it suggestions directly to PowerShell Predictive
IntelliSense. This way as you start typing a suggestion, you can more quickly accept the suggestion.
We have open sourced this feedback provider so you can take a look at how we have implemented it here. You can install this feedback provider from the PowerShell Gallery via this command:
Install-Module -Name command-not-found
Or if you are using the latest version of PSResourceGet, you can use this command:
Install-PSResource -Name command-not-found
You will need to import the module to enable the feedback provider:
Import-Module -Name command-not-found
We recommend you save this in your PowerShell $PROFILE so that it is always available to you.
What’s next with Feedback Providers?
We are still under rapid development with feedback providers so there may be changes to them in the
future! Due to the changes we are doing to the feedback provider, we will be publishing
documentation on how to create your own once we have finalized some design changes for creating the
providers.
In the meantime if you have any ideas on how we can make this experience best work for your
PowerShell workflow, please let us know in the issues tab of our PowerShell repo!
We are excited to be sharing more about feedback providers in the near future.
The Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), the Multi-State Information Sharing and Analysis Center (MS-ISAC), and the Canadian Centre for Cyber Security (CCCS) are releasing this joint Cybersecurity Advisory (CSA) in response to cyber threat actors leveraging newly identified Truebot malware variants against organizations in the United States and Canada. As recently as May 31, 2023, the authoring organizations have observed an increase in cyber threat actors using new malware variants of Truebot (also known as Silence.Downloader). Truebot is a botnet that has been used by malicious cyber groups like CL0P Ransomware Gang to collect and exfiltrate information from its target victims.
Previous Truebot malware variants were primarily delivered by cyber threat actors via malicious phishing email attachments; however, newer versions allow cyber threat actors to also gain initial access through exploiting CVE-2022-31199—(a remote code execution vulnerability in the Netwrix Auditor application), enabling deployment of the malware at scale within the compromised environment. Based on confirmation from open-source reporting and analytical findings of Truebot variants, the authoring organizations assess cyber threat actors are leveraging both phishing campaigns with malicious redirect hyperlinks and CVE-2022-31199 to deliver new Truebot malware variants.
The authoring organizations recommend hunting for the malicious activity using the guidance outlined in this CSA, as well as applying vendor patches to Netwrix Auditor (version 10.5—see Mitigations section below).[1] Any organization identifying indicators of compromise (IOCs) within their environment should urgently apply the incident responses and mitigation measures detailed in this CSA and report the intrusion to CISA or the FBI.
Note: This advisory uses the MITRE ATT&CK® for Enterprise framework, version 13. See the MITRE ATT&CK Tactics and Techniques section below for cyber threat actors’ activity mapped to MITRE ATT&CK tactics and techniques.
Initial Access and Execution
In recent months, open source reporting has detailed an increase in Truebot malware infections, particularly cyber threat actors using new tactics, techniques, and procedures (TTPs), and delivery methods.[2] Based on the nature of observed Truebot operations, the primary objective of a Truebot infection is to exfiltrate sensitive data from the compromised host(s) for financial gain [TA0010].
Phishing:
Cyber threat actors have historically used malicious phishing emails as the primary delivery method of Truebot malware, which tricks recipients into clicking a hyperlink to execute malware. Cyber threat actors have further been observed concealing email attachments (executables) as software update notifications [T1189] that appear to be legitimate [T1204.002], [T1566.002]. Following interaction with the executable, users will be redirected to a malicious web domain where script files are then executed. Note: Truebot malware can be hidden within various, legitimate file formats that are used for malicious purposes [T1036.008].[3]
Exploitation of CVE-2022-31199:
Though phishing remains a prominent delivery method, cyber threat actors have shifted tactics, exploiting, in observable manner, a remote code execution vulnerability (CVE-2022-31199) in Netwrix Auditor [T1190]—software used for on-premises and cloud-based IT system auditing. Through exploitation of this CVE, cyber threat actors gain initial access, as well as the ability to move laterally within the compromised network [T1210].
Figure 1: CVE-2022-3199 Delivery Method for Truebot
Following the successful download of the malicous file, Truebot renames itself and then loads FlawedGrace onto the host. Please see the FlawedGrace section below for more information on how this remote access tool (RAT) is used in Truebot operations.
After deployment by Truebot, FlawedGrace is able to modify registry [T1112] and print spooler programs [T1547.012] that control the order that documents are loaded to a print queue. FlawedGrace manipulates these features to both escalate privilege and establish persistence.
During FlawedGrace’s execution phase, the RAT stores encrypted payloads [T1027.009] within the registry. The tool can create scheduled tasks and inject payloads into msiexec.exe and svchost.exe, which are command processes that enable FlawedGrace to establish a command and control (C2) connection to 92.118.36[.]199, for example, as well as load dynamic link libraries (DLLs) [T1055.001] to accomplish privilege escalation.
Several hours post initial access, Truebot has been observed injecting Cobalt Strike beacons into memory [T1055] in a dormant mode for the first few hours prior to initiating additional operations. Please see the Cobalt Strike section below for more information on how this remote access tool (RAT) is used in Truebot operations.
Discovery and Defense Evasion
During the first stage of Truebot’s execution process, it checks the current version of the operating system (OS) with RtlGetVersion and processor architecture using GetNativeSystemInfo [T1082].[4] Note: This variant of Truebot malware is designed with over one gigabyte (GB) of junk code which functions to hinder detection and analysis efforts [T1027.001].
Following the initial checks for system information, Truebot has the capability to enumerate all running processes [T1057], collect sensitive local host data [T1005], and send this data to an encoded data string described below for second-stage execution. Based on IOCs in table 1, Truebot also has the ability to discover software security protocols and system time metrics, which aids in defense evasion, as well as enables synchronization with the compromised system’s internal clock to facilitate scheduling tasks [T1518.001][T1124].
Next, it uses a .JSONIP extension, (e.g., IgtyXEQuCEvAM.JSONIP), to create a thirteen character globally unique identifier (GUID)—a 128-bit text string that Truebot uses to label and organize the data it collects [T1036].
After creating the GUID, Truebot compiles and enumerates running process data into either a base64 or unique hexadecimal encoded string [T1027.001]. Truebot’s main goal is identifying the presence of security debugger tools. However, the presence of identified debugger tools does not change Truebot’s execution process—the data is compiled into a base64 encoded string for tracking and defense evasion purposes [T1082][T1622].
Data Collection and Exfiltration
Following Truebot’s enumeration of running processes and tools, the affected system’s computer and domain name [T1082][T1016], along with the newly generated GUID, are sent to a hard-coded URL in a POST request (as observed in the user-agent string). Note: A user-agent string is a customized HTTP request that includes specific device information required for interaction with web content. In this instance, cyber threat actors can redirect victims to malicious domains and further establish a C2 connection.
The POST request functions as means for establishing a C2 connection for bi-lateral communication. With this established connection, Truebot uses a second obfuscated domain to receive additional payloads [T1105], self-replicate across the environment [T1570], and/or delete files used in its operations [T1070.004]. Truebot malware has the capability to download additional malicious modules [T1105], load shell code [T1620], and deploy various tools to stealthily navigate an infected network.
Associated Delivery Vectors and Tools
Truebot has been observed in association with the following delivery vectors and tools:
Raspberry Robin (Malware)
Raspberry Robin is a wormable malware with links to other malware families and various infection methods, including installation via USB drive [T1091].[5] Raspberry Robin has evolved into one of the largest malware distribution platforms and has been observed deploying Truebot, as well as other post-compromise payloads such as IcedID and Bumblebee malware.[6] With the recent shift in Truebot delivery methods from malicious emails to the exploitation of CVE-2022-31199, a large number of Raspberry Robin infections have leveraged this exploitable CVE.[2]
FlawedGrace is a remote access tool (RAT) that can receive incoming commands [T1059] from a C2 server sent over a custom binary protocol [T1095] using port 443 to deploy additional tools [T1105].[7] Truebot malware has been observed leveraging (and dropping) FlawedGrace via phishing campaigns as an additional payload [T1566.002].[8] Note: FlawedGrace is typically deployed minutes after Truebot malware is executed.
Cobalt Strike is a popular remote access tool (RAT) that cyber threat actors have leveraged—in an observable manner—for a variety of post-exploitation means. Typically a few hours after Truebot’s execution phase, cyber threat actors have been observed deploying additional payloads containing Cobalt Strike beacons for persistence and data exfiltration purposes [T1059].[2] Cyber threat actors use Cobalt Strike to move laterally via remote service session hijacking [T1563.001][T1563.002], collecting valid credentials through LSASS memory credential dumping, or creating local admin accounts to achieve pass the hash alternate authentication [T1003.001][T1550.002].
Teleport (Tool)
Cyber threat actors have been observed using a custom data exfiltration tool, which Talos has named “Teleport.”[2] Teleport is known to evade detection during data exfiltration by using an encryption key hardcoded in the binary and a custom communication protocol [T1095] that encrypts data using advanced encryption standard (AES) and a hardcoded key [T1048][T1573.002]. Furthermore, to maintain its stealth, Teleport limits the data it collects and syncs with outbound organizational data/network traffic [T1029][T1030].
Truebot Malware Indicators of Compromise (IOCs)
Truebot IOCs from May 31, 2023, contain IOCs from cyber threat actors conducting Truebot malspam campaigns. Information is derived from a trusted third party, they observed cyber threat actors from 193.3.19[.]173 (Russia) using a compromised local account to conduct phishing campaigns on May 23, 2023 and spread malware through: https[:]//snowboardspecs[.]com/nae9v, which then promptly redirects the user to: https://www.meditimespharma[.]com/gfghthq/, which a trusted third party has linked to other trending Truebot activity.
After redirecting to https://www.meditimespharma[.]com/gfghthq/, trusted third parties have observed, the cyber threat actors using Truebot to pivot to https://corporacionhardsoft[.]com/images/2/Document_16654.exe, which is a domain associated with snowboardspecs[.]com, as well as malicious phishing campaigns in May 2023 and flagged my numerous security vendors, according to trusted third party reporting. Note: these IOCs are associated with Truebot campaigns used by Graceful Spider to deliver FlawedGrace and LummaStealer payloads in May of 2023.
The malicious file MD5 hash, 6164e9d297d29aa8682971259da06848 is associated with multiple Truebot rooted attack vectors and malware families, and was downloaded from https://corporacionhardsoft.com/images/2/Document_16654[.]exe which was flagged as malicious by numerous security vendors, and during its execution, the malware copies itself to C:IntelRuntimeBroker.exe, and based on trusted third party analysis, is linked to https://essadonio.com/538332[.]php, which is linked to 45.182.189[.]71 (Panama) and is associated with other trending Truebot malware campaigns from May 2023.
Please reference table 1 for IOCs described in the paragraph above.
See Tables 6-16 for all referenced cyber threat actor tactics and techniques for enterprise environments in this advisory. For assistance with mapping malicious cyber activity to the MITRE ATT&CK framework, see CISA and MITRE ATT&CK’s Best Practices for MITRE ATT&CK Mapping and CISA’s Decider Tool.
Cyber threat actors are exploiting Netwrix vulnerability CVE-2022-31199 for initial access with follow-on capabilities of lateral movement through remote code execution.
Truebot has the ability to discover system time metrics, which aids in enables synchronization with the compromised system’s internal clock to facilitate scheduling tasks.
Cyber threat actors blend exfiltrated data with network traffic to evade detection.
Cyber threat actors use the Teleport tool to exfiltrate data over a C2 protocol.
DETECTION METHODS
CISA and authoring organizations recommend that organizations review and implement the following detection signatures, along with: Win/malicious_confidence100% (W), Trojan:Win32/Tnega!MSR, and Trojan.Agent.Truebot.Gen, as well as YARA rules below to help detect Truebot malware.
Detection Signatures
Figure 2: Snort Signature to Detect Truebot Malware
alert tcp any any -> any any (msg:”TRUEBOT: Client HTTP Header”; sid:x; rev:1; flow:established,to_server; content:”Mozilla/112.0 (compatible|3b 20 4d 53 49 45 20 31 31 2e 30 3b 20 57 69 6e 64 6f 77 73 20 4e 54 20 31 30 2e 30 30 29|”; http_header; nocase; classtype:http-header; metadata:service http;)
YARA Rules
CISA developed the following YARA to aid in detecting the presence of Truebot Malware.
Additional YARA rules for detecting Truebot malware can be referenced from GitHub.[9]
INCIDENT RESPONSE
The following steps are recommended if organizations detect a Truebot malware infection and compromise:
Quarantine or take offline potentially affected hosts.
Collect and review artifacts such as running processes/services, unusual authentications, and recent network connections.
Provision new account credentials.
Reimage compromised host.
Report the compromise to CISA via CISA’s 24/7 Operations Center (report@cisa.gov or 888-282-0870) or contact your local FBI field office. State, local, tribal, or territorial government entities can also report to MS-ISAC (SOC@cisecurity.org or 866-787-4722).
For additional best practices, see CISA’s Cross-Sector Cybersecurity Performance Goals (CPGs). The CPGs, developed by CISA and the National Institute of Standards and Technology (NIST), are a prioritized subset of IT and OT security practices that can meaningfully reduce the likelihood and impact of known cyber risks and common TTPs. Because the CPGs are a subset of best practices, CISA and co-sealers recommend software manufacturers implement a comprehensive information security program based on a recognized framework, such as the NIST Cybersecurity Framework (CSF).
Apply patches to CVE-2022-31199
Update Netwrix Auditor to version 10.5
Reduce threat of malicious actors using remote access tools by:
Implementing application controls to manage and control execution of software, including allowlisting remote access programs.
Application controls should prevent installation and execution of portable versions of unauthorized remote access and other software. A properly configured application allowlisting solution will block any unlisted application execution. Allowlisting is important because antivirus solutions may fail to detect the execution of malicious portable executables when the files use any combination of compression, encryption, or obfuscation.
Disable command-line and scripting activities and permissions [CPG 2.N].
Restrict the use of PowerShell by using Group Policy, and only grant to specific users on a case-by-case basis. Typically, only those users or administrators who manage the network or Windows operating systems (OSs) should be permitted to use PowerShell [CPG 2.E].
Update Windows PowerShell or PowerShell Core to the latest version and uninstall all earlier PowerShell versions. Logs from Windows PowerShell prior to version 5.0 are either non-existent or do not record enough detail to aid in enterprise monitoring and incident response activities [CPG 1.E, 2.S, 2.T].
PowerShell logs contain valuable data, including historical OS and registry interaction and possible IOCs of a cyber threat actor’s PowerShell use.
Ensure PowerShell instances, using the latest version, have module, script block, and transcription logging enabled (enhanced logging).
The two logs that record PowerShell activity are the PowerShell Windows Event Log and the PowerShell Operational Log. The authoring organizations recommend turning on these two Windows Event Logs with a retention period of at least 180 days. These logs should be checked on a regular basis to confirm whether the log data has been deleted or logging has been turned off. Set the storage size permitted for both logs to as large as possible.
Configure the Windows Registry to require User Account Control (UAC) approval for any PsExec operations requiring administrator privileges to reduce the risk of lateral movement by PsExec.
Review domain controllers, servers, workstations, and active directories for new and/or unrecognized accounts [CPG 4.C].
Audit user accounts with administrative privileges and configure access controls according to the principle of least privilege (PoLP) [CPG 2.E].
Reduce the threat of credential compromise via the following:
Place domain admin accounts in the protected users’ group to prevent caching of password hashes locally.
Implement Credential Guard for Windows 10 and Server 2016 (Refer to Microsoft: Manage Windows Defender Credential Guard for more information). For Windows Server 2012R2, enable Protected Process Light for Local Security Authority (LSA).
Refrain from storing plaintext credentials in scripts.
Implement time-based access for accounts set at the admin level and higher [CPG 2.A, 2.E]. For example, the Just-in-Time (JIT) access method provisions privileged access when needed and can support enforcement of the principle of least privilege (as well as the Zero Trust model). This is a process where a network-wide policy is set in place to automatically disable admin accounts at the Active Directory (AD) level when the account is not in direct need. Individual users may submit their requests through an automated process that grants them access to a specified system for a set timeframe when they need to support the completion of a certain task.
In addition, CISA, FBI, MS-ISAC, and CCCS recommend network defenders apply the following mitigations to limit potential adversarial use of common system and network discovery techniques and to reduce the impact and risk of compromise by ransomware or data extortion actors:
Disable File and Printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
Implement a recovery plan to maintain and retain multiple copies of sensitive or proprietary data and servers in a physically separate, segmented, and secure location (e.g., hard drive, storage device, or the cloud).
Maintain offline backups of data and regularly maintain backup and restoration (daily or weekly at minimum). By instituting this practice, an organization minimizes the impact of disruption to business practices as they can retrieve their data [CPG 2.R].
Refrain from requiring password changes more frequently than once per year. Note: NIST guidance suggests favoring longer passwords instead of requiring regular and frequent password resets. Frequent password resets are more likely to result in users developing password “patterns” cyber criminals can easily decipher.
Require administrator credentials to install software.
Require phishing-resistant multifactor authentication for all services to the extent possible, particularly for webmail, virtual private networks, and accounts that access critical systems [CPG 2.H].
Keep all operating systems, software, and firmware up to date. Timely patching is one of the most efficient and cost-effective steps an organization can take to minimize its exposure to cybersecurity threats. Organizations should patch vulnerable software and hardware systems within 24 to 48 hours of vulnerability disclosure. Prioritize patching known exploited vulnerabilities in internet-facing systems [CPG 1.E].
Segment networks to prevent the spread of ransomware. Network segmentation can help prevent the spread of ransomware by controlling traffic flows between—and access to various subnetworks, restricting further lateral movement [CPG 2.F].
Identify, detect, and investigate abnormal activity and potential traversal of the indicated ransomware with a networking monitoring tool. To aid in detecting ransomware, implement a tool that logs and reports all network traffic, including lateral movement activity on a network. Endpoint detection and response (EDR) tools are particularly useful for detecting lateral connections, as they have insight into common and uncommon network connections for each host [CPG 3.A].
Install, regularly update, and enable real time detection for antivirus software on all hosts.
Consider adding an email banner to emails received from outside your organization [CPG 2.M].
Ensure all backup data is encrypted, immutable (i.e., cannot be altered or deleted), and covers the entire organization’s data infrastructure [CPG 2.K, 2.L, 2.R].
VALIDATE SECURITY CONTROLS
In addition to applying mitigations, CISA recommends exercising, testing, and validating your organization’s security program against the threat behaviors mapped to the MITRE ATT&CK for Enterprise framework in this advisory. CISA recommends testing your existing security controls inventory to assess how they perform against the ATT&CK techniques described in this advisory.
To get started:
Select an ATT&CK technique described in this advisory (see Tables 5-13).
Align your security technologies against the technique.
Test your technologies against the technique.
Analyze your detection and prevention technologies’ performance.
Repeat the process for all security technologies to obtain a set of comprehensive performance data.
Tune your security program, including people, processes, and technologies, based on the data generated by this process.
CISA recommends continually testing your security program, at scale, in a production environment to ensure optimal performance against the MITRE ATT&CK techniques identified in this advisory.
The information in this report is being provided “as is” for informational purposes only. CISA and authoring agencies do not endorse any commercial product or service, including any subjects of analysis. Any reference to specific commercial products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA, and co-sealers.
Iron Castle Systems
Manage Cookie Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.