Apple M1 chip | Breaking Cybersecurity News | The Hacker News

A Mac malware campaign targeting Xcode developers has been retooled to add support for Apple's new M1 chips and expand its features to steal confidential information from cryptocurrency apps. XCSSET came into the spotlight in  August 2020  after it was found to spread via modified Xcode IDE projects, which, upon the building, were configured to execute the payload. The malware repackages payload modules to imitate legitimate Mac apps, which are ultimately responsible for infecting local Xcode projects and injecting the main payload to execute when the compromised project builds. XCSSET modules come with the capabilities to steal credentials, capture screenshots, inject malicious JavaScript into websites, plunder user data from different apps, and even encrypt files for a ransom.  Then in March 2021, Kaspersky researchers  uncovered  XCSSET samples compiled for the new Apple M1 chips, suggesting that the malware campaign was not only ongoing but also that ad...

One of the first malware samples tailored to run natively on Apple's M1 chips has been discovered, suggesting a new development that indicates that bad actors have begun adapting malicious software to target the company's latest generation of Macs powered by its own processors. While the transition to Apple silicon has necessitated developers to build new versions of their apps to ensure better performance and compatibility, malware authors are now undertaking similar steps to build malware that are capable of executing natively on Apple's new M1 systems, according to macOS Security researcher Patrick Wardle. Wardle detailed a Safari adware extension called GoSearch22 that was originally written to run on Intel x86 chips but has since been ported to run on ARM-based M1 chips. The rogue extension, which is a variant of the Pirrit advertising malware, was first seen in the wild on November 23, 2020, according to a sample  uploaded  to VirusTotal on December 27. "Tod...

Serverless environments, leveraging services such as AWS Lambda, offer incredible benefits in terms of scalability, efficiency, and reduced operational overhead. However, securing these environments is extremely challenging. The core of current serverless security practices often revolves around two key components: log monitoring and static analysis of code or system configuration. But here is the issue with that: 1. Logs Only Tell Part of the Story Logs can track external-facing activities, but they don't provide visibility into the internal execution of functions. For example, if an attacker injects malicious code into a serverless function that doesn't interact with external resources (e.g., external APIs or databases), traditional log-based tools will not detect this intrusion. The attacker may execute unauthorized processes, manipulate files, or escalate privileges—all without triggering log events. 2. Static Misconfiguration Detection is Incomplete Static tools that check ...