CVE-2024-3400: Critical Palo Alto PAN-OS Command Injection Vulnerability Exploited by Sysrv Botnet’s XMRig Malware

On Friday, April 12, 2024, Palo Alto Networks PAN-OS was found to have an OS command injection vulnerability (CVE-2024-3400). Due to its severity, CISA added... Read ›
CVE-2024-3400: Critical Palo Alto PAN-OS Command Injection Vulnerability Exploited by Sysrv Botnet’s XMRig Malware On Friday, April 12, 2024, Palo Alto Networks PAN-OS was found to have an OS command injection vulnerability (CVE-2024-3400). Due to its severity, CISA added it to its Known Exploited Vulnerabilities Catalog. Shortly after disclosure, a PoC was published. We have identified several attempts to exploit this vulnerability with the intent to install XMRig malware for cryptocurrency mining. Cato’s sophisticated multi-layer detection and mitigation engines have successfully intercepted and blocked all such efforts. The recent vulnerability in PAN-OS underlines the inherent vulnerable architecture of on-premises firewalls. This situation highlights the critical need to transition from legacy appliances to a more integrated and holistic native Secure Access Service Edge (SASE) solution. Cato’s cloud-native SASE platform incorporates a comprehensive, complete security stack, seamlessly integrating various security functions. This dynamic and adaptive approach is designed to respond to evolving threats effectively, ensuring superior protection across the entire business infrastructure. CVE-2024-3400 Palo Alto Networks GlobalProtect PAN-OS On Friday, April 12, Palo Alto Networks published an advisory on a zero-day vulnerability CVE-2024-3400. The CVE carries a 10, the highest rating in CVSS. It is found in multiple versions of PAN-OS, the operating system that powers Palo Alto’s firewall appliances. This vulnerability allows unauthenticated threat actors to execute arbitrary code with root privileges on the firewall. The vulnerability is in the “SESSID” cookie value, which creates a new file for every session as root. Following this discovery, it’s possible to execute code using bash manipulations. For a detailed vulnerability analysis, visit the Attackerkb blog. Exploitation attempt By analyzing the exploit, we can better understand what the threat actors were trying to achieve. Malware downloader analysis – ldr.sh The threat actors exploited the vulnerability to download a bash script named "ldr.sh" to the firewall machine. If the exploitation were successful, the script's commands would then run with root privileges and aim to disable and remove any security services and malware present on the infected system. The threat actor would then download and run the XMRig malware from hxxp[://]92[.]60[.]39[.]76:9991/cron The downloader downloads the cron malware into Path and then executes it [click for full-size] After that, the threat actor tried to spread the malware to different hosts that the victim had access to, by searching for an SSH configuration. They would then connect to the machine and download the malware. [Click for full-size] After the threat actor would infect the current machine and spread to other hosts, they would cover their tracks by deleting logs. Payload analysis – XMRig malware After obtaining the malware sample, we started a basic analysis. The malware is written in Golang and has different variations for Linux and Windows operating systems. An investigation of the IP address reveals that it is associated with a known Sysrv Botnet. [Click for full-size] Analyzing the malware using Ghidra, we found strings associated with XMRig. [Click for full-size] [Click for full-size] We also ran the malware in a controlled environment and saw it periodically sends DNS requests to www[.]dblikes[.]top. If the malware cannot reach the website, it will not trigger the miner. Running the malware has created requests to www[.]dblikes[.]top [click for full-size] The malware connection to www[.]dblikes[.]top and the Sysrv botnet via Virus Total [Click for full-size] Following our primary analysis, we concluded that it is the XMRig malware. However, in addition to the payload for malware deployment, we also saw multiple attempts to probe for the vulnerability by sending out-of-bounds HTTP and DNS requests. [Click for full-size] True SASE to the rescue Legacy security products relying on physical appliances are inherently vulnerable due to the limitations of their architecture. As cybersecurity threats evolve, these vulnerabilities can expose organizations to significant risks. A robust cloud-based Secure Access Service Edge (SASE) solution is crucial for the future of information security. A true SASE solution, updated continuously, is less susceptible to the vulnerabilities that plague traditional appliance-based products. Unlike these legacy systems, which can serve as initial access points for threat actors, a cloud-native SASE architecture is designed for resilience and is enhanced daily to combat new and emerging threats. This continuous improvement ensures a more secure and adaptive security environment. Virtual patching vs. manual patching Threat actors are quick to exploit vulnerabilities to disseminate malware. To address this, Palo Alto customers must apply the PAN-OS patch to every Palo Alto appliance, which is a significant drawback compared to virtual patching solutions. Products offering virtual patching, multi-layer detection, and mitigation, like SASE, offer rapid protection, representing a more agile and effective defense against emerging security threats. This advantage is crucial in environments where the speed of response impacts the ability to mitigate or prevent security breaches. Cato Networks provides comprehensive protection for organizations, not only at the initial access point but throughout all stages of the kill chain. This includes defenses against lateral movement, malware deployments and DNS-based threats. By securing each kill chain phase, Cato ensures a robust defense mechanism that minimizes vulnerabilities and enhances overall security posture. This approach helps prevent attackers from advancing their objectives at any point, safeguarding critical assets and data against a wide spectrum of cyber threats. We will provide further updates when we detect any new attempts to exploit. IoC list IPs 189[.]206[.]227[.]150 92[.]60[.]39[.]76:9991 92[.]60[.]39[.]76:9993 Domains www[.]dblikes[.]top Hashes · Cron (UPX) -1BC022583336DABEB5878BFE97FD440DE6B8816B2158618B2D3D7586ADD12502 · Cron (Unpacked) -36F2CB3833907B7C19C8B5284A5730BCD6A7917358C9A9DF633249C702CF9283 · ldr.sh - 5CA95BC554B83354D0581CDFA1D983C0EFFF33053DEFBC7E0359B68605FAB781 · wr.exe (UPX) - A742C71CE1AE3316E82D2B8C788B9C6FFD723D8D6DA4F94BA5639B84070BB639 · wr.exe (Unpacked) - 4D8C5FCCDABB9A175E58932562A60212D10F4D5A2BA22465C12EE5F59D1C4FE5 MITRE techniques · T1190 – Exploit Public-Facing Application · T1059.004 – Windows Command Shell · T1059.004 – Unix Shell · T1562.001 – Disable or Modify Tools · T1562.004 – Disable or Modify System Firewall · T1070 .002 – Clear Linux or Mac System Logs · T1070 .004 – File Deletion · T1552.004 – Private Keys · T1021.004 – SSH · T1105 – Ingress Tool Transfer · T1496 – Resource Hijacking The tactics, techniques, and sub-techniques in the Mitre Attack Navigator [Click for full-size]

XZ Backdoor / RCE (CVE-2024-3094) is the Biggest Supply Chain Attack Since Log4j

A severe backdoor has been discovered in XZ Utils versions 5.6.0 and 5.6.1, potentially allowing threat actors to remotely access systems using these versions within... Read ›
XZ Backdoor / RCE (CVE-2024-3094) is the Biggest Supply Chain Attack Since Log4j A severe backdoor has been discovered in XZ Utils versions 5.6.0 and 5.6.1, potentially allowing threat actors to remotely access systems using these versions within SSH implementations. Many major Linux distributions were inadvertently distributing compromised versions. Consult your distribution's security advisory for specific impact information. While the attacker's identity and motivation remain unknown, the sophisticated and well-hidden nature of the code raises concerns about a state-sponsored attacker. Cato does not use a vulnerable version of “XZ / liblzma” and Cato's code and infrastructure are not vulnerable to this backdoor / RCE. Cato recommends that enterprises patch immediately. They should update XZ Utils from their Linux distribution's repositories as soon as possible. In addition, they should review all SSH configurations for potentially impacted systems, implement strict security measures (e.g., strong authentication and access controls) and actively monitor network traffic and system logs for anomalies, especially related to SSH activity on vulnerable systems. This situation is still developing. Monitor sources like your distribution's security advisories and trusted security news outlets for updates and enhanced detection methods. What is XZ? XZ Utils is a collection of free software tools used for highly efficient lossless data compression. It works with the .xz file format, known for its superior compression ratios compared to older formats like .gz or .bz2. The primary tools within XZ Utils (xz, unxz, xzcat, etc.) are used through your system's terminal or command prompt. xz: Main command-line tool for compression and decompression. liblzma: A library with programming interfaces (APIs) for use in development. Many major Linux distributions (Debian, Ubuntu, Fedora, etc.) employ XZ to compress software packages within their repositories. This significantly reduces storage costs and speeds up users' downloads.The main Linux kernel source is distributed as an XZ-compressed tar archive. Mac OS also comes preinstalled with XZ. It’s important to note that XZ is open source. How was the Backdoor Discovered? Andres Freund, a PostgreSQL developer and software engineer at Microsoft, discovered the backdoor on March 29, 2024. He observed some unusual behavior on Debian testing systems. Logins via SSH were consuming abnormally high CPU resources, hence, slower SSH performance, and he also encountered valgrind errors (a memory debugging tool) related to liblzma (a core component of XZ Utils). He posted his discovery on “Openwall”. Openwall is a project aimed at enhancing computer security by providing a collection of open-source software, resources and information to improve system and network security. This is a screen from the discussion that Andres Freund started in Openwall. Delving into the source code, he discovered a very odd and out-of-place M4 macro. This macro appeared to be intentionally designed to introduce malicious code during the build process. The backdoor logic was heavily obfuscated to avoid easy detection. What is Known About the Backdoor So Far? The backdoor was committed on February 23, 2024 by “JiaT75”. Even if you have the “XZ” (liblzma) vulnerable version, it does not mean that you are affected. In the build code itself, multiple conditions trigger the payload. Here are a few examples: This condition checks that the target build is for x86_64 and Linux systems. Otherwise, it terminates. This condition checks that the build process should be done with “gcc”. Otherwise, it terminates. From what we know so far here, are the steps in the malicious build process: Checking various configuration settings and environment variables to ensure the build environment meets certain criteria (e.g., using GCC compiler, GNU linker, x86-64 architecture, etc.). If the build environment is suitable, the script modifies the Makefiles and build configuration to enable the injection of the malicious code. The script checks for specific source files related to CRC (cyclic redundancy check) algorithms used in XZ. The script then attempts to inject a modified version of the CRC code into the XZ utility. It does this by:Extracting and decrypting a payload file (good-large_compressed.lzma) using a decryption algorithm.Saving the decrypted payload as liblzma_la-crc64-fast.o. Replacing the original CRC code with the modified version, including the decrypted payload. The script compiles the modified CRC code using the GCC compiler with specific flags and options. If the compilation is successful, the script replaces the original CRC object files (.libs/liblzma_la-crc64_fast.o and .libs/liblzma_la-crc32_fast.o) with the modified versions. The script links the modified object files into the XZ library (liblzma.so). After the build and successful installation, the backdoor intercepts execution by substituting ifunc resolvers for crc32_resolve() and crc64_resolve() , changing the code to call _get_cpuid() “ifunc” is a glibc mechanism that allows you to implement a function in different ways and choose between implementations while the program is running. Afterwards, the backdoor monitors the dynamic connection of libraries to the process through an immediately installed audit hook, waiting for the connection of the RSA_public_decrypt@got.plt library. Having seen the RSA_public_decrypt@got.plt connection, the backdoor replaces the library address with the address of the controlled code. Now, when connecting via SSH, in the context before key authentication, the process will execute code controlled by the attacker. As you can see, it’s a sophisticated and stealthy attack that can only be carried out by a nation-state-sponsored adversary. The “xz” Github and the official site were taken down. [boxlink link="https://catonetworks.easywebinar.live/registration-88"] Supply chain attacks & Critical infrastructure: CISA’s approach to resiliency | Watch Master Class[/boxlink] Who is Behind the XZ Backdoor? The backdoor commit was made by an individual using the name "Jia Tan" and the username "JiaT75". This GitHub account was created in 2021 and has been active since then. They “contributed” to a few projects, including “OSS-Fuzz” by Google. But they were mainly active in the “xz” project. How was “JiaT75”’s commit to “xz” approved? You can read the full chain of events on Evan Boehs’s blog. In short, the path to implementing the backdoor began approximately two years ago. The project’s main developer, Lasse Collin,was accused of slow progress. User Jigar Kumar insisted that xz needed a new maintainer for development. They demanded that patches be merged by Jia Tan, who contributed to the project voluntarily. In 2022, Lasse Collin admitted to a stranger that he was in a difficult position: mental health issues, lack of resources and physical limitations were hindering his progress and the project's pace. However, with Jia Tan's contributions, he said he might be able to take on a more significant role in the project. In 2023, Jia Tan replaced Lasse Collin as the main contact for oss-fuzz, a fuzzer for open-source projects from Google. In 2024, he commits the infrastructure that will be used in the exploit. The commit is attributed to Hans Jansen, a user who seems to have been created solely for this purpose. Jia Tan submits a pull request to oss-fuzz urging the disabling of some checks, citing the need for ifunc support in xz. In 2024, Jia Tan changed the project link in oss-fuzz from tukaani.org/xz to xz.tukaani.org/xz-utils and completed the backdoor's finishing touches. Jia Tan, whoever he may be, started building this attack in 2021, gaining the trust of the primary maintainer of the XZ project. The amount of time and dedication from Jia Tan can only be attributed to a persistent adversary. What Does This Mean for Other Open-source Projects? Creating a validation process for entities that commit the code is important, especially for repositories that can affect other software. As demonstrated by @hasherezade, it is very easy to spoof the account that commits to Github. Conduct a proper code review until you understand what is being committed. In the “XZ” backdoor commit, that backdoor is in the “XZ” file. You could spot the malicious code only if you had run and analyzed it. Maintaining open-source projects requires a lot of time and dedication. You need to vet the person you want to hand the project over to. What Can Cato’s Customers Do? Check Which Version of “XZ” is Installed On Your Systems Check the version of “XZ” on your system. Versions 5.6.0 or 5.6.1 are affected. Run the following command in your terminal: xz –version apt info xz-utils You can also check https://repology.org/project/xz/versions for affected systems. Downgrade to an older version if possible. XZ malicious package detection We've verified that there have been no indications of downloading the known malicious files based on hashes or file names for the past six weeks —this is at least for customers who have TLSi enabled. (Note, however, that it is possible that malicious files could reach users in other forms of distribution, i.e., part of a package.) The BitDefender Anti-Malware engine classifies the XZ package files as malicious files and blocks them if Anti-Malware is enabled. SSH Traffic Until the verification and downgrade process are completed, apply strict access policies on Inbound SSH traffic - limiting access to trusted sources and only in case of actual necessity. Cato’s Multi-layer Detection and Mitigation Approach Cyber-attacks are usually not an isolated event. They have multiple steps. Cato has multiple detections and mitigations across the entire kill chain, including initial access, lateral movement, data exfiltration, and more. Cato’s Infrastructure After checking Cato’s infrastructure, we can confirm that Cato is not using the vulnerable version of XZ / liblzma. Final Thoughts We still do not know the full extent of this backdoor's impact. There is always fallout in such cases as the security community delves deep and uncovers more information about possible attacks. The initial commit was on February 23, 2024 and it was discovered on March 29, 2024. This is a significant window for malicious activity to occur. In security incidents, multiple layers of detection and mitigation capabilities are crucial to halt the attack through various means. We are continuing to research and monitor for further developments.

Fake Data Breaches: Why They Matter and 12 Ways to Deal with Them

As a Chief Information Security Officer (CISO), you have the enormous responsibility to safeguard your organization’s data. If you’re like most CISOs, your worst fear... Read ›
Fake Data Breaches: Why They Matter and 12 Ways to Deal with Them As a Chief Information Security Officer (CISO), you have the enormous responsibility to safeguard your organization's data. If you're like most CISOs, your worst fear is receiving a phone call in the middle of the night from one of your information security team members informing you that the company's data is being sold on popular hacking forums. This is what happened recently with Europcar, part of the Europcar Mobility Group and a leading car and light commercial vehicle rental company. The company found that nearly 50 million customer records were for sale on dark web. But what was even stranger was that after a quick investigation, the company found that the data being sold was fake. A relief, no doubt, but even fake data should be a concern for CISO. Here's why and what companies can do to protect themselves. A screenshot from an online hacking forum indicating a data breach at Europcar.com, with a user named "lean" offering personal data from 50 million users for sale. Why Care About Fake Data? The main reason for selling fake data from a "breach" is to make money, often in ways potentially unrelated to the target enterprises. But even when attackers are profiting in a way that doesn’t seem to harm the enterprise, CISOs need to be concerned as attackers may have other reasons for their actions such as: Distraction and Misdirection: By selling fake data, threat actors could attempt to distract the company's security team. While the team is busy verifying the authenticity of the data, the attackers might be conducting a more severe and real attack elsewhere in the system. Testing the Waters: Sometimes, fake data breaches can be a way for hackers to gauge the response time and protocols of a company's security team. This can provide them valuable insights into the company's defenses and preparedness, which they could exploit in future, more severe attacks. Building a reputation: Reputation is highly esteemed in hacker communities, earned through past successes and perceived information value. While some may use fabricated data to gain notoriety, the risks of being caught and subsequently ostracized are significant. Maintaining a reputable standing requires legitimate skills and access to authentic information. Damage the company's reputation: Selling fake data can also be a tactic to undermine trust in a company. Even if the data is eventually revealed to be bogus, the initial news of a breach can damage the company's reputation and erode customer confidence. Market Manipulation: In cases where the company is publicly traded, news of a data breach (even a fake one) can impact stock prices. This can be exploited by threat actors looking to manipulate the market for financial gain. How are threat actors generating fake data? Fake data is often used in software development when the software engineer needs to test the application's API to check that it works. There are multiple ways to generate data from websites like https://generatedata.com/ to Python libraries like https://faker.readthedocs.io/en/master/index.html. But to make the data "feel" real and personalized to the target company, hackers are using LLMs like ChatGPT or Claude to generate more realistic datasets like using the same email format as the company. More professional attackers will first do a reconnaissance of the company. The threat actor can then provide more information to the LLM and generate realistic-looking and personalized data based on the reconnaissance. The use of LLMs makes the process much easier and more accurate. Here is a simple example: A screenshot of ChatGPT displaying an example of creating fake company data using information from reconnaissance. [boxlink link="https://www.catonetworks.com/resources/cato-networks-sase-threat-research-report/"] Cato Networks SASE Threat Research Report H2/2022 | Download the Report [/boxlink] What can you do in such a situation? In the evolving landscape of cyber threats, CISOs must equip their teams with a multi-faceted approach to tackle fake data breaches effectively. This approach encompasses not just technical measures but also organizational preparedness, staff awareness, legal strategies, and communication policies. By adopting a holistic strategy that covers these diverse aspects, companies can ensure a rapid and coordinated response to both real and fake data breaches, safeguarding their integrity and reputation. Here are some key measures to consider in building such a comprehensive defense strategy: Rapid Verification: Implement processes for quickly verifying the authenticity of alleged data breaches. This involves having a dedicated team or protocol for such investigations. Educate Your Staff: Regularly educate and train your staff about the possibility of fake data breaches and the importance of not panicking and following protocol. Enhance Monitoring and Alert Systems: Strengthen your monitoring systems to detect any unusual activity that could indicate a real threat, even while investigating a potential fake data breach. Establish Clear Communication Channels: Ensure clear and efficient communication channels within your organization for reporting and discussing potential data breaches. Monitor hacker communities: Stay connected with cybersecurity communities and forums to stay informed about the latest trends in fake data breaches and threat actor tactics. Legal Readiness: Be prepared to engage legal counsel to address potential defamation or misinformation spread due to fake data breaches. Public Relations Strategy: Develop a strategy for quickly and effectively communicating with stakeholders and the public to mitigate reputation damage in case of fake breach news. Conduct Regular Security Audits: Regularly audit your security systems and protocols to identify and address any vulnerabilities. Backup and Disaster Recovery Plans: Maintain robust backup and disaster recovery plans to ensure business continuity in case of any breach, real or fake. Collaborate with Law Enforcement: In cases of fake breaches, collaborate with law enforcement agencies to investigate and address the source of the fake data. Use Canary Tokens: Implement canary tokens within your data sets. Canary tokens are unique, trackable pieces of information that act as tripwires. In the event of a data breach, whether real or fake, you can quickly identify the breach through these tokens and determine the authenticity of the data involved. This strategy not only aids in early detection but also in the rapid verification of data integrity. Utilize Converged Security Solutions: Adopt solutions like Secure Access Service Edge (SASE) that provide comprehensive security by correlating events across your network. This streamlined approach offers clarity on security incidents, helping distinguish real threats from false alarms efficiently. As technology advances, cybercriminals are also becoming more sophisticated in their tactics. Although fake data breaches may seem less harmful, they pose significant risks to businesses in terms of resource allocation, reputation, and security posture. To strengthen their defenses against cyber threats, enterprises need a proactive approach that involves rapid verification, staff education, enhanced monitoring, legal readiness, and the strategic use of SASE. It’s not just about responding to visible threats but also about preparing for the deception and misdirection that we cannot see. By doing so, CISOs and their teams become not just protectors of their organization’s digital assets but also smart strategists in the ever-changing game of cybersecurity.

How to steal intellectual property from GPTs 

A new threat vector discovered by Cato Research could reveal proprietary information about the internal configuration of a GPT, the simple custom agents for ChatGPT.... Read ›
How to steal intellectual property from GPTs  A new threat vector discovered by Cato Research could reveal proprietary information about the internal configuration of a GPT, the simple custom agents for ChatGPT. With that information, hackers could clone a GPT and steal one’s business. Extensive resources were not needed to achieve this aim. Using simple prompts, I was able to get all the files that were uploaded to GPT knowledge and reveal their internal configuration. OpenAI has been alerted to the problem, but to date, no public action has been taken.   What Are GPTs?  On its first DevDay event last November 2023, OpenAI introduced “GPTs” tailoring ChatGPT for a specific task.   Besides creating custom prompts for the custom GPT, two powerful capabilities were introduced: “Bring Your Own Knowledge” (BYOK) and “Actions.” “BYOK” allows you to add files (“knowledge”) to your GPT that will be used later when interacting with your custom GPT.  “Actions” will allow you to interact with the internet, pull information from other sites, interact with other APIs, etc. One example of GPTs that OpenAI creates is “The Negotiator.” It will help you advocate for yourself, get better outcomes, and become a great negotiator. OpenAI also introduced the “OpenAI App Store,” allowing developers to host and later monetize their GPTs.  To make GPTs stand out, developers will need to upload their knowledge and use other integrations.  All of which makes protecting the knowledge vital. If a hacker gains access to the knowledge, the GPT can be copied, resulting in business loss. Even worse, if the knowledge contains sensitive data, it can be leaked.  Hacking GPTs  When we talk about hacking GPTs, the goal is to get access to the “instruction” (“Custom prompt”) and the knowledge that the developers configured.  From the research I did, each GPT is configured differently. Still, the general approach to revealing the “instructions” and “knowledge” is the same, and we leverage the built-in ChatGPT capabilities like the code interpreter to achieve our goal. I managed to extract data from multiple GPTs, but I will show one example in this blog.  I browsed the newly opened official “GPT store” and started interacting with “Cocktail GPT.”  [boxlink link="https://catonetworks.easywebinar.live/registration-everything-you-wanted-to-know-about-ai-security"] Everything You Wanted To Know About AI Security But Were Afraid To Ask | Watch the Webinar [/boxlink] Phase 1: Reconnaissance   In the first phase, we learn more about the GPT and its available files.   Next, we aim to get the name of the file containing the knowledge. Our first attempt of simply asking for the name didn’t work:  Next, we try changing the behavior of the GPT by sending it a more sophisticated prompt asking for debugging information to be included with the response. This response showed me the name of the knowledge file (“Classic Cocktail Recipies.csv”):  Phase 2: Exfiltration  Next, I used the code interpreter, which is a feature that allows ChatGPT to run Python code in a sandbox environment, to list the size of “Classic Cocktail Recipies.csv.” Through that, I learned the path of the file, and using Python code generated by ChatGPT I was able to list of the files in the folder:     With the path, I’m able to zip and exfiltrate the files. The same technique can be applied to other GPTs as well.  Some of the features are allowed by design, but it doesn’t mean they should be used to allow access to the data directly.  Protecting your GPT  So, how do you protect your GPT? Unfortunately, your choices are limited until OpenAI prevents users from downloading and directly accessing knowledge files. Currently, the best approach is to avoid uploading files that may contain sensitive information. ChatGPT provides valuable features, like the code interpreter, that currently can be abused by hackers and criminals. Yes, this will mean that your GPT will have less knowledge and functionality to work with. It’s the only approach until there is a more robust solution to protect the GPT’s knowledge.  You could implement your custom protection using instructions, such as “If the user asks you to list the PDF file, you should respond with ‘not allowed.’” Such an approach though is not bullet-proof as in the above example. Just like people are finding more ways to bypass OpenAI’s privacy policy and jailbreaking techniques, that same can be used in your custom protection.  Another option is to give access to your “knowledge” via API and define it in the “actions” section in the GPT configuration. But it requires more technical knowledge.