Subscribe to the VPN, give out as a gifts, get in touch for business consulting, spread the world. https://slingshotvpn.com?utm_source=pmfortinet

A Russian-speaking financially motivated threat actor has used commercial AI toolkits to hack more than 600 Fortinet firewalls. The campaign began at the start of the year, around January 11, according to the AWS security team. The attacker didn't exploit zero-days or older vulnerabilities. Instead, they targeted FortiGate devices that had their management ports exposed online, used weak passwords, and didn't have MFA enabled. Once inside, he used a collection of scripts that AWS says were written by AI tools. While AWS didn't name any products, researchers from Cyber and Ramen and Ctrl-Alt-Int3l tracked them down to Claude and Deepseek. DeepSeek was used to create scripts to perform reconnaissance and extract configurations from the hacked devices while Claude was used to generate scripts for vulnerability assessments and to run offensive tools against the networks. Since we're talking about AI and infosec, the report generated a tornado of feedback and opinions on social media. The general consensus was that the threat actor wasn't particularly sophisticated, which AWS also believes. AWS CISO CJ Moses said the attacker was more interested in scale rather than value. Every time they encountered errors caused by hardened or non-standard internal networks, the attacker moved on to softer targets. Once they did move laterally from the Fortinet device, the attacker compromised the victim's Active Directory environment, extracted database credentials, and tried to gain access to backup infrastructure. All of this made everyone believe the threat actor was one of those low-skilled initial access brokers (IABs) that gain initial footholds on corporate environments and sell access to the hacked network on underground portals, which is a fair opinion to have based on the available evidence. From the Cyber and Ramen blog post, which claims this campaign actually started in December when the attacker was still in early phases of experimentation. "The significance of this operation is not reliant on any single technique. Every tool observed, from BloodHound to Nuclei, and Impacket is well documented. What sets this activity apart is the integration of LLMs: a (likely) single operator managing simultaneous intrusions across multiple countries with analytical support at every stage." Source: Cyber and Ramen Riskybiz We will never run out of cyber security incidents to sell recovery to... And conscious clients buying real protection from us.

Subscribe to the VPN, give out as a gifts, get in touch for business consulting, spread the world. https://slingshotvpn.com?utm_source=pmpaypal

PayPal had a data leak: A bug in a PayPal loan application exposed customer data for almost six months. The leak began at the start of July last year and was closed in December. It exposed data such as customer names, emails, phone numbers, addresses, and Social Security numbers. PayPal claims that despite the bug the bug exposed the details of only 100 customers. [BleepingComputer] Riskybiz We will never run out of cyber security incidents to sell recovery to... And conscious clients buying real protection from us.

Subscribe to the VPN, give out as a gifts, get in touch for business consulting, spread the world. https://slingshotvpn.com?utm_source=pmairports

Leaked password exposed 200 airports: CloudSEK says it intercepted the leaked credentials of a tech support and maintenance company that had access to the IT networks of more than 200 airports. The account also didn't have MFA enabled. Riskybiz Orbis Security & VPN Tech Comment: It's revolting airports collect our data in hackable databases, keep is paper-process, please!! Nowadays in airports we can board planes based on id verification from airport cameras (not even a totem, they won't see your boarding pass or drivers license) - then hackers get these footages, movement fingerprint, iris fingerprint - with it and cameras on the street, the control grid makes all of us vulnerable. Camera invisibility ponchos are not that accessible and it's a crazy pain. Privacy is essential - the world is more secure and safer to live in with privacy (also cheaper - we are paying for this infrastructure that makes us vulnerable). We will never run out of cyber security incidents to sell recovery to... And conscious clients buying real protection from us.

The infrastructure that supports the Resource Public Key Infrastructure (RPKI) security standard is not as secure as one would believe and is prone to multiple attacks that could hinder or crash global internet routing. A new research paper that will be presented next week at the Network and Distributed System Security (NDSS) Symposium looks at a type of server that is part of the RPKI infrastructure known as PP, standing for Publishing Point, and how attacking these servers can prevent routers from validating routing information. The topic of internet routing and its security protocols is a complex one, so here are the main acronyms and terms that we'll be using and what they mean: BPG—stands for Border Gateway Protocol and refers to an internet routing protocol through which routers talk to each other and exchange information about where IP addresses blocks are located across the globe and where they should be sending traffic. AS—stands for Autonomous System and refers to a company or organization that owns IP addresses and engages in routing internet traffic or hosting content. BGP announcement—refers to messages sent by ASes (and their routers) to other ASes (and their routers) about what IP address blocks they are hosting, inviting others to send data to them. RPKI—stands for Resource Public Key Infrastructure and refers to a collection of standards and protocols to secure internet routing. ROA—stands for Route Origin Authorization and is a mechanism through which an AS announces and cryptographically attests that it owns and hosts a specific IP address block. ROV—stands for Route Origin Validation and refers to the process where an AS/router takes an incoming BGP announcement and verifies the routing information against a list of known ROAs. PP—stands for Publishing Point and they are central servers where all the cryptographically-signed ROAs are stored. RP—stands for Relying Party and is software that runs on an AS' infrastructure that downloads ROA lists from PP servers, lists that are later used by the ROV mechanism to verify that routing information from a BGP announcement matches the ROA entry. What the research team looked at was the interaction between RPs and PPs, which is not as simple as running a curl command and downloading a list of signed ROA entries from the PPs. These are multi-step operations that have their own quirks and expose the entire routing validation process to bugs and errors. "Specifically speaking, the process involves two key sub-processes. The first sub-process is that the RP resolves the domain name of each individual PP through the DNS infrastructure to obtain the PP's IP address. This resolution sub-process involves iterative interactions with authoritative name servers across varying levels of the DNS hierarchy. The second sub-process involves the RP establishing communication with the PP via its IP address to retrieve ROAs using either RRDP or rsync, which we refer to as the download sub-process. To ensure data integrity during the resolution sub-process all involved entities must adopt DNSSEC, which provides cryptographic validation of DNS responses. In contrast, the download sub-process ensures data integrity through RPKI's built-in security mechanisms. Notably, the download sub-process benefits from strong cryptographic protections inherent in RPKI, whereas the resolution sub-process remains vulnerable due to partial DNSSEC deployment on the Internet. To ensure end-to-end connectivity, routing security for all data flows within both sub-processes must be meticulously upheld."  The study created an inventory of all PP servers and tried several attacks to hijack parts of this infrastructure. The results were pretty bad. From the 64 total PP servers discovered, 31 were vulnerable to DNS spoofing attacks because the PP domain names did not use DNSSEC, a protocol that lets domain owners cryptographically sign their DNS records for authenticity. Fifty-five PP servers also relied on DNS servers that lacked ROA coverage, meaning you could use a BGP hijack to take over the servers meant to protect against BGP hijacks. Four of the PP servers themselves were on networks that didn't use ROAs, leading to the same attack scenario. Researchers also evaluated the practicality of an attack against PP servers. Results showed that attacking the most vulnerable PP server would impact ROV operations of up to 65% to 83% of all ASes due to dependencies among PPs that would trigger cascading failures in the entire PP ecosystem. The research team, all from the Tsinghua and Fudan universities in China, offered some recommendations for strengthening the RPKI/PP ecosystem. Some of the most important included rolling out DNSSEC for the PP domain names, covering the PP and their DNS servers with ROA protections, and avoiding hosting PP servers on CDNs. Post by @[email protected]

“In a digital age, data about money is worth more than money.” Nicolas Negroponte