| https://twitter.com/LawrenceAbrams |
@GossiTheDog And we were told that they were running a vulnerable version with a public CVE that does not have a public PoC exploit.
I could not verify that though.
Maybe we should all file breach reports against Musk like Kevin Couture did:
If you're an Apple user and I spoof your phone number in a call to the legitimate Apple Customer Support line (800-275-2273), I can force Apple to send you a system level "Apple Account Confirmation" prompt to all of your signed-in devices.
This approach is commonly used by a prolific voice phishing group to convince targets they really are in a support call with an Apple representative.
Today's deep dive into this weird world was made possible in part by a series of live phishing videos, tutorials and other secrets shared by an insider that show in unprecedented detail how these voice phishing scams can be so convincing.
Please share this story widely, because I learned a ton reporting this and frankly the various methods used by these groups to dox and target people are really slick.
From the story: "Besieged by scammers seeking to phish user accounts over the telephone, Apple and Google frequently caution that they will never reach out unbidden to users this way. However, new details about the internal operations of a prolific voice phishing gang show the group routinely abuses legitimate services at Apple and Google to force a variety of outbound communications to their users, including emails, automated phone calls and system-level messages sent to all signed-in devices."
https://krebsonsecurity.com/2025/01/a-day-in-the-life-of-a-prolific-voice-phishing-crew/
Full Rapid7 analysis of #Cleo CVE-2024-55956 now available c/o @stephenfewer. It's neither a patch bypass of CVE-2024-50623 nor part of a chain after all — totally new bug, different exploitation strategies across the two issues (though the same endpoint gets used either way).
I'm not sure it's been mentioned much yet that Cleo evidently released IOCs related to CVE-2024-50623 in October 2024, implying the older bug's been exploited for a minute. Would sure be helpful to know more about who was doing that exploiting, particularly now that Cl0p has claimed credit for last week's attack.
https://attackerkb.com/topics/geR0H8dgrE/cve-2024-55956/rapid7-analysis
@GossiTheDog Thanks...I think I got hung up the word "register," as there are Registered and Unregistered devices.
Looks like default variable allows FortiGate devices to register as an "Unregistered" (unauthenticated) device, but they can still be used to exploit the API auth bypass once connected.
I spent too much time reading FortiManager docs last night ... 🤯
@GossiTheDog Kevin, you sure that FortiGate devices are able to register by default?
From what I understand the allow_register variable is disabled by default, and when enabled, needs to be coupled with the register_passwd to set a password used during registration.
Also, I am told that the "localhost" devices are appearing under the Unregistered devices tab.
Fortinet publicly disclosed today a critical FortiManager API vulnerability, tracked as CVE-2024-47575, that was exploited in zero-day attacks to steal sensitive files containing configurations, IP addresses, and credentials for managed devices.
Eric Geller
Dissent Doe 
BrianKrebs
Caitlin Condon
BleepingComputer