Posts on Security, Cloud, DevOps, Citrix, VMware and others.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.
SUMMARY: How real-time power flow optimization at the edge is helping data centers and the electrical grid handle surging AI energy demands more efficiently. By unlocking hidden capacity and dynamically managing power systems, we explain how existing infrastructure can support significantly more compute without massive new buildouts.
Our "Security Onion for Analysts and Threat Hunters" class will be running virtually August 25, 2026 through August 28, 2026. Use the following code before June 1, 2026 to get 10% off!
Security teams often present MTTR as an internal KPI. Leadership sees it differently: every hour a threat dwells inside the environment is an hour of potential data exfiltration, service disruption, regulatory exposure, and brand damage.
The root cause of slow MTTR is almost never "not enough analysts." It is almost always the same structural problem: threat intelligence that exists outside the workflow. Feeds that require manual lookup. Reports that live in a shared drive. Enrichment that happens in a separate tab. Every handoff costs minutes; over the course of a workday, those minutes become hours.
Mature SOCs have collapsed those handoffs. Their intelligence is embedded in the workflow itself at the exact moment a decision needs to be made. Below are the five places where separation matters most.
1. Detection: Catching Threats Before They Become Incidents
In many SOCs, detection begins only when an alert fires. By that point, the attacker may already have a foothold, persistence, or worse.
Mature SOCs shift this dynamic by extending their visibility beyond internal signals. With ANY.RUN Threat Intelligence Feeds, they continuously ingest fresh indicators from real-world attacks and match them against their own telemetry. This means suspicious infrastructure can be flagged even before it triggers traditional alerts.
The effect is subtle but powerful. Detection moves upstream. Instead of reacting to confirmed incidents, teams start catching activity in its early stages, when containment is faster and far less expensive.
TI Feeds: data sources and benefits
From a business perspective, this is where risk is quietly reduced. The earlier a threat is identified, the less opportunity it has to evolve into a costly breach.
2. Triage: Turning Uncertainty into Instant Clarity
If detection is about seeing, triage is about deciding. And this is where many SOCs lose momentum.
In less mature environments, triage often turns into a mini-investigation. Analysts pivot between tools, search for context, and escalate alerts “just in case.” The process becomes cautious, slow, and expensive in terms of human effort.
Mature SOCs compress this step dramatically. Using ANY.RUN Threat Intelligence Lookup, they enrich indicators instantly, pulling in behavioral context from real malware executions. Instead of guessing whether something is malicious, analysts immediately understand what it does and how serious it is. Decisions become faster, escalations more precise, and Tier 1 analysts handle far more on their own. For example, just look up a suspicious domain spotted in your perimeter and find out instantly that it belongs to MacSync stealer infrastructure:
Domain lookup with a quick “malicious” verdict and IOCs
What further accelerates this process is the AI-powered search inside TI Lookup. Instead of relying on precise syntax, complex filters, or deep familiarity with query parameters, analysts can describe what they are looking for and get it translated into structured queries, removing a layer of friction that traditionally slows down investigations.
This doesn’t just make experts faster; it makes less experienced analysts far more effective. The barrier to advanced search capabilities drops, and the time spent figuring out how to search is replaced by focusing on what the results mean. Decisions become faster, escalations more precise, and Tier 1 analysts handle far more on their own.
For the business, this translates into efficiency that doesn’t require additional hiring. The SOC simply becomes more capable with the same resources.
3. Investigation: From Fragmented Clues to a Coherent Story
Investigation is where time can stretch the most. In many SOCs, it’s a process of stitching together fragments: logs from one system, reputation checks from another, behavioral guesses built on limited data.
This fragmentation is expensive. Not just in minutes, but in cognitive load.
Mature SOCs reduce that complexity by anchoring investigations in context-rich intelligence. With ANY.RUN’s threat intelligence ecosystem: indicators are not just labels. They are connected to real execution data, attack chains, and observable behaviors.
Instead of reconstructing what might have happened, analysts can see what did happen. The investigation becomes less about searching and more about understanding.
This shift shortens analysis time and raises the overall quality of decisions. It also allows less experienced analysts to operate with greater confidence, which is often an overlooked advantage.
From a business standpoint, faster and clearer investigations mean reduced dwell time, which directly limits the scale of potential damage.
Built on real-time data from over 15,000 organizations and 600,000 analysts detonating live malware and phishing samples every day, this behavioral intelligence connects raw IOCs to actual attack execution, TTPs, and artifacts. The result? MTTR drops dramatically because context is instant, automation is accurate, and decisions are confident.
4. Response: Acting at the Speed of Confidence
Even when a threat is identified, response can lag. Manual steps, inconsistent playbooks, and delays between decision and action all stretch MTTR.
Mature SOCs treat response as something that should happen almost automatically once a threat is confirmed. By integrating ANY.RUN Threat Intelligence Feeds into SIEM and SOAR platforms, which ensure that known malicious indicators trigger immediate actions such as blocking or isolation.
TI Feeds integrations and connectors
There is a certain elegance to this. The system reacts not with hesitation, but with certainty. The time between “we know this is bad” and “it’s contained” shrinks to seconds.
For the business, this is where operational impact is minimized. Faster containment reduces downtime, protects critical assets, and keeps disruptions from cascading across systems.
5. Threat Hunting & Prevention: Learning Before It Hurts Again
The final difference between mature and less mature SOCs lies in what happens between incidents.
Reactive teams move from alert to alert, often encountering variations of the same attack without realizing it. There is little time or structure for proactive work.
Mature SOCs deliberately carve out that space. With ANY.RUN Threat Reports and continuously updated intelligence feeds, they track emerging campaigns, understand attacker techniques, and adapt their defenses in advance.
Over time, this creates a compounding effect. The SOC doesn’t just respond faster. It encounters fewer incidents to begin with.
From a business perspective, this is where cybersecurity starts to feel less like firefighting and more like risk management. Fewer surprises, fewer disruptions, and a stronger overall security posture.
Where the Time Really Goes
What becomes clear across all five areas is that delays rarely come from a single dramatic failure. They come from small, repeated inefficiencies. A missing piece of context here, an extra lookup there, a delayed decision somewhere in between.
Individually, these moments seem minor. Together, they stretch MTTR far beyond what it should be.
Mature SOCs solve this not by speeding up people, but by redesigning how information flows. When ANY.RUN’s threat intelligence, incorporating TI Feeds, TI Lookup, and Threat Reports, is integrated into daily workflows; the need to search, verify, and cross-check is dramatically reduced. The work changes in nature. Analysts spend less time chasing data and more time making decisions.
Boost your SOC to maturity with behavioral threat intelligence. Cut MTTR & protect revenue.
For leadership, the implications are straightforward but significant.
Improving MTTR is not just a technical goal. It is a business lever. Faster detection and response reduce the likelihood of major incidents, limit operational disruption, and improve the return on existing security investments.
ANY.RUN Threat Intelligence supports this across every stage of SOC operations:
It brings earlier visibility into threats;
It accelerates decision-making during triage;
It simplifies investigations with real behavioral context;
It enables faster, automated response;
It strengthens proactive defense through continuous insight.
The result is not just a faster SOC, but a more resilient organization.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
from The Hacker News https://ift.tt/Pz4h5DC
via IFTTT
In 2025, attackers increasingly targeted weaknesses in multi-factor authentication (MFA) workflows, and phishing attacks leveraged valid, compromised credentials to launch lures from trusted accounts. The trends focused entirely on trust, or the lack thereof, in everyday business operations.
Phishing
In 2025, phishing attacks were used for initial access in 40% of incidents, maintaining their prevalence. Attackers ramped up cascaded phishing campaigns, where attackers leveraged the trust of the initial compromised account to create specialized phishing attempts, within the network and out of it, aimed at trusted partners and third parties.
Email composition trends
The content of phishing emails changed somewhat. Transitioning away from spam offers, they took the form of workflow-style emails — IT, travel, and other everyday business tasks that look familiar to employees and executives. Travel and logistics lures in particular surged, while political lures dropped off. Internal expensing and travel emails, even when legitimate, are often repetitive and come from disparate sources with changeable formats or poorly-rendered templates, leading to a lowered guard toward spotting malicious intent. Attackers were likely aiming to steal credentials, payment information, or MFA tokens via fake single sign-on (SSO) pages.
In reviews of thousands of blocked-email keywords, 60% contained subject lines with "request," "invoice," "fwd," "report," and similar. IT-focused phishing keywords turned more technical, to words like "tampering," "domain," "configuration," "token," and others, showing that attackers were making plays toward IT and security workflows.
Attackers also abused Microsoft 365 Direct Send to capitalize on internal email trust. Direct Send is the method by which networked devices like printers and scanners deliver documents to users. The messages appear to be sent and received by the same email address. These internal messages do not receive the same scrutiny that external emails do, from employees or automated email filters. Direct Send allowed attackers to spoof internal email addresses and deliver highly convincing lures from inside the organization, without compromising real accounts, to target key attack services and deliver high-impact damage.
MFA and identity attacks
Identity and access management (IAM) applications have grown popular with organizations hoping to consolidate user privileges. Unfortunately, it has also grown in popularity with attackers. Nearly a third of 2025 MFA spray attacks targeted IAM, turning the tools companies used to maintain access control into a point of failure. Device compromise surged by 178%, largely driven by voice phishing designed to trick administrators into registering malicious devices.
MFA spray and device compromise
MFA attack strategy changed by sector. A successful attack could glean SSO tokens and give adversaries the ability to change user roles and credentials, or even the MFA policies themselves. Attackers increasingly exploited authentication workflows to gain and maintain access.
Spray attacks were deployed against networks with predictable identity behavior, while diverse, unmanaged, or high-turnover device ecosystems proved weaker to device compromise attacks.
Notably, higher education was the most targeted device compromise sector. Several factors could contribute to the trend:
· Large, public-facing directories for targeted phishing
Higher education was a very unfavorable target for MFA spray attacks, however. Passwords and MFA are also highly varied and segmented, and most universities have strong login portal policies, enforced lockouts, and login attempt limits.
Guidance for defenders
As always, prioritize based on your own environment.
Organizations should keep in mind that living-off-the-land binaries (LOLBins) and open-source and dual-use tools, which are not inherently malicious, are key to further exploitation. Blocking external IPs from using a feature, enabling Microsoft’s newer “Reject Direct Send” control, tightening SPF/DMARC enforcement, and treating “internal-looking” emails with the same scrutiny as inbound mail are currently the most effective defenses.
Likewise, MFA attack protection should be tailored to the style of environment and sector.
MFA spray attacks work well on stable, scaled identity controls. Counter these attacks with strong lockout policies, good password hygiene, and conditional access.
Device compromise works best on variable networks where devices change over fast and MFA use is spotty. Work on establishing better device hardening and management, session controls, and strict phishing-resistant MFA with enrollment governance. Solutions such as Cisco Duo provide controls for phishing-resistant MFA, device trust, and secure enrollment, helping reduce risk from phishing and identity-based attacks. Solutions such as Cisco Duo provide controls for phishing-resistant MFA, device trust, and secure enrollment, helping reduce risk from phishing and identity-based attacks.
This blog only scratched the surface on 2025 threat trends. See the full Year in Review report for a detailed explanation of Microsoft 365 Direct Send and how it was used for attacks, infographic breakdowns of MFA spray vs. device compromise attacks, the full list of targeted tools and sectors by percentage, and more.
from Cisco Talos Blog https://ift.tt/y1pU4tK
via IFTTT
Hey folks, if you’ve been around the virtualization and IT admin scene for a while, you know how much of a hassle it can be to juggle bootable media for system installations, troubleshooting, or lab setups.
USB drives get lost, DVDs are ancient history, and manually mounting ISOs every time you need to spin up a new VM or bare-metal machine?
If you prefer more stationary setup with PXE boot, which makes more sense for home lab or small business. That’s where tools like iVentoy come in – a game-changer for anyone managing networks, deployments, or even home labs.
IVentoy boot menu – screenshot from the lab
In this post, I’ll dive deep into what iVentoy is, how it works technically, why it’s incredibly useful for IT administrators, and some hands-on tips to get you started. We’ll cover use cases, pros, cons, and even comparisons to other tools.
For those new here, I’m all about practical IT solutions, especially in virtualization environments like VMware ESXi, vSphere, and general sysadmin tasks. I’ve covered everything from ESXi upgrades to backup strategies in past posts, and iVentoy fits right into that wheelhouse. It’s not just another boot tool; it’s an enhanced PXE server that lets you boot and install operating systems over the network without breaking a sweat.
What is iVentoy? A Technical Overview
iVentoy is essentially an open-source, enhanced Preboot Execution Environment (PXE) server designed to boot ISO files directly over a local area network (LAN). Developed by the same folks behind Ventoy – that popular multiboot USB creator – iVentoy takes the concept to the network level. Released around 2023, it’s built to handle modern hardware and software demands, supporting x86 Legacy BIOS, IA32 UEFI, x86_64 UEFI, and even ARM64 UEFI modes simultaneously. This cross-architecture support is huge for mixed environments, where you might have older servers rubbing shoulders with ARM-based devices like Raspberry Pis or newer edge computing hardware.
At its core, iVentoy acts as a lightweight server that serves bootable ISOs to client machines via PXE. PXE itself is a client-server protocol that allows computers to boot from a network interface before loading an OS from local storage. It relies on DHCP for IP assignment, TFTP for initial boot file transfer, and often HTTP or other protocols for larger file delivery.
Traditional PXE setups, like those in Windows Deployment Services (WDS) or open-source alternatives like FOG Project, require extracting ISO contents, setting up boot images, and configuring complex menus. iVentoy simplifies this dramatically: You drop your ISO files into a directory, start the server, and clients can PXE-boot straight into a menu to select and boot the ISO – no extraction needed.
Technically, iVentoy uses a combination of built-in DHCP, TFTP, and HTTP servers. When a client boots via PXE, it broadcasts a DHCP discover packet. iVentoy’s DHCP server responds with an IP address and points the client to the TFTP server for the bootloader (like iPXE or GRUB). From there, the client pulls the ISO list via HTTP and mounts the selected ISO as a virtual drive using iSCSI-like injection for seamless booting. This “injection” feature is particularly clever for Windows setups: It handles WinPE and install.wim files by injecting necessary drivers and certificates on the fly, ensuring compatibility even with secure boot environments.
As of the latest stable versions (around 1.0.x in 2024), iVentoy supports over 110 OS types, including Windows (from XP to 11/Server editions), Linux distros (Ubuntu, Fedora, CentOS, etc.), VMware products (ESXi installers), and specialty tools like Clonezilla, MemTest86, or antivirus rescue disks. It even handles auto-installation scripts via plugins, making it scriptable for unattended deployments.
Why iVentoy is a Must-Have for IT Admins
Now, let’s get to the meat: Why should you, as an IT admin, care about iVentoy? In short, it saves time, reduces hardware dependencies, and scales effortlessly. Imagine you’re managing a data center with dozens of servers, or a corporate network with hundreds of workstations. Traditional methods mean carrying around USB sticks or setting up dedicated deployment servers with heavy configs. iVentoy turns any Windows or Linux machine into a portable PXE server in minutes.
First off, centralized management. All your ISOs live in one place on the server. Need to update a Windows ISO with the latest patches? Just replace the file – no need to recreate boot media. This is gold for compliance-heavy environments where you need version control on deployment images. In virtualization labs (think VMware Workstation or vSphere), you can PXE-boot VMs over the network, avoiding the tedium of attaching ISOs to each virtual machine individually.
Second, mass deployment capabilities. iVentoy allows simultaneous booting and installation on multiple clients. Unlike basic PXE, it’s optimized for high-throughput scenarios. For example, in a school lab or enterprise refresh cycle, you can image 50 machines at once without bandwidth bottlenecks, thanks to its efficient HTTP-based file serving. It supports multicast if your network gear allows it, further reducing load.
Third, troubleshooting and recovery. IT admins spend half their lives fixing broken systems. With iVentoy, boot into diagnostic tools like Hiren’s BootCD or SystemRescueCD over the network. No more hunting for that one USB with the right tool. In remote sites, as long as there’s LAN access, you can push recovery ISOs without physical intervention – perfect for branch offices or edge locations.
From a security standpoint, iVentoy offers password protection for the boot menu and ISO access, preventing unauthorized boots. It also logs client interactions, helping with auditing. And since it’s open-source (hosted on GitHub), you can audit the code yourself or contribute fixes.
Password protect the ISOs for unauthorized access
But let’s talk numbers: In a typical setup, booting a 5GB Windows ISO over Gigabit Ethernet takes under 5 minutes to load into RAM, versus 10-15 minutes from USB (depending on drive speed). For admins handling fleets, this adds up to hours saved weekly.
Installing iVentoy: Step-by-Step Guide
Getting iVentoy up and running is refreshingly simple – no massive dependencies or configs. Here’s how to do it on Windows or Linux. I’ll assume you’re on a machine with admin rights and a wired NIC for stability.
On Windows:
Download the latest release from the official GitHub repo (ventoy/PXE). Grab the Win64 or Win32 ZIP based on your system.
Extract the archive to a folder, say C:\iVentoy.
Run iventoy_64.exe (or 32-bit version) as administrator. This launches the core service.
The app will auto-open a web browser to http://127.0.0.1:26000 – that’s your management interface.
In the web UI, go to “Configuration” > “Network” and select your server’s IP. Set up a DHCP pool (e.g., 192.168.1.100-200) if you’re not using an existing DHCP server.
Click the green “Start” button to fire up the PXE service.
View from the console
For auto-start, run iventoy_64.exe -R from an elevated command prompt.
On Linux:
Download the Linux TAR.GZ from GitHub.
Extract it: tar -xvf iventoy-x.x.x-linux.tar.gz
Navigate to the folder and run sudo bash iventoy.sh start.
Configure network settings as above, then start the service.
You can see which systems will boot which image in the Device List
Pro tip: If your network has an existing DHCP server (like a router), disable iVentoy’s DHCP and configure your DHCP to point to iVentoy’s IP for boot options (next-server and boot-file-name: /iventoy/pxeboot.efi for UEFI).
Once running, copy your ISOs to the /iso directory in the iVentoy folder. Filenames can’t have spaces or non-ASCII chars – rename if needed. Refresh the web UI, and they’ll appear in the boot menu.
Use WinSCP utility for convenience to transfer your ISOs to Linux
Configuring iVentoy for Advanced UseOut of the box, iVentoy is plug-and-play, but for IT admins, the real power is in customization.
Boot Menu Customization: Edit theme.json for custom backgrounds, fonts, or menu layouts. Add subfolders in /iso for organization (e.g., /iso/Windows, /iso/Linux).
Injection Mode: For Windows, enable wimboot injection to handle large WIM files efficiently. This mounts the install.wim as a RAM disk, speeding up installs.
Password Protection: Set global or per-ISO passwords in the web UI to secure sensitive images.
Protect the whole boot menu with a password
Plugins: iVentoy supports Ventoy plugins for auto-install (e.g., JSON configs for unattended Windows setup with product keys, partitions, and drivers).
Network Optimization: Tune HTTP timeouts or enable HTTPS for secure environments. For WAN use, pair with VPN tunnels, though it’s LAN-optimized.
Logging and Monitoring: Check /log directory for client boot logs. Integrate with tools like Splunk for enterprise monitoring.
Real-World Use Cases for IT Admins
Let’s get practical. Here’s how iVentoy shines in daily admin life.
OS Deployment in Enterprises: Say you’re rolling out Windows 11 to 200 desktops. Drop the ISO in iVentoy, configure an unattended answer file, and PXE-boot batches of machines. No MDT or SCCM needed for small scales.
Virtualization Labs: In vSphere, boot ESXi installers over network for quick host provisioning. Or test Linux VMs without ISO attachments – just PXE to iVentoy.
Disaster Recovery: Keep rescue ISOs ready. Boot a failed server into Clonezilla for imaging, or DBAN for secure wipes, all remotely.
Edge Computing: For IoT or remote sites with ARM devices, iVentoy’s ARM64 support lets you push custom Linux images without on-site visits.
Testing and Development: DevOps teams can boot custom kernels or distros for CI/CD pipelines, integrating iVentoy with tools like Ansible for automated provisioning.
Advantages Over Traditional Methods
Compared to WDS: iVentoy is portable, no AD integration required, and handles non-Windows OSes natively.
Vs. FOG Project: Simpler setup, no database needed, but FOG wins for imaging features.
Vs. netboot.xyz: iVentoy uses local ISOs for offline use; netboot pulls from the internet, which is risky in air-gapped networks.
Pros:
Free, cross-platform, lightweight (under 100MB), active development.
Limitations and Workarounds
No tool is perfect. iVentoy requires a decent network (at least 100Mbps for usability). Large ISOs (10GB+) can be slow on wireless. Filename restrictions are annoying – script renames. Early versions had cert issues (e.g., injecting obscure drivers), but patches fixed that by 2024. No native multicast, but you can layer it with udpcast.
For limitations, test in your env – UEFI secure boot might need tweaks.
Security Concerns
This Reddit post you linked to from May 2025 raises concerns about iVentoy potentially injecting a “malicious” certificate and driver during Windows installations via PXE boot.
After digging into this, including the original GitHub issue it stems from, developer responses, and follow-up discussions, I think the claim is overstated and largely a misunderstanding of how iVentoy handles Windows Preinstallation Environment (WinPE) booting – though it’s not without some valid security hygiene questions.
Let me break it down step by step, based on what’s been reported and addressed since then.
Background on the Issue
The core allegation comes from an analysis of iVentoy version 1.0.20 (released around early 2025). When using iVentoy to PXE-boot and install Windows, it loads a driver called httpdisk.sys in the WinPE phase. This is an open-source component (from the httpdisk project) that allows mounting remote disk images over HTTP, which is essential for network-based ISO booting without local media.
To make this driver load properly in WinPE (especially under restrictions like driver signing), iVentoy included and installed a self-signed Extended Validation (EV) certificate named “JemmyLoveJenny EV Root CA0” as a trusted root cert in the registry during the boot process.
This setup triggered red flags:
VirusTotal scans on extracted files from the iVentoy archive (like wintool.tar.xz and vtoypxe64.exe) showed detections from multiple antivirus engines, labeling it as potentially malicious due to the certificate injection.
The technique resembles exploits used by threat actors, like adding fake root certs to bypass Windows policies and load unsigned or malicious kernel drivers (e.g., as seen in some ransomware or APT campaigns).
No prior documentation explained this behavior clearly, leading to suspicions of a backdoor or hidden malware.
The Reddit thread and related posts (like on Hacker News) amplified this, with users speculating about supply-chain risks, especially since Ventoy (iVentoy’s sibling project) is widely trusted for USB multiboot tools.
Some even drew parallels to past incidents where open-source tools were compromised.
Developer’s Response and FixesThe iVentoy developer (longpanda, who’s also behind Ventoy) addressed this directly in the GitHub issue shortly after it was raised in May 2025.
Key points from their explanation:
The certificate and driver are only active in the ephemeral WinPE RAM environment during installation – they’re not persisted to the final installed Windows system on disk.
It’s a necessary workaround for WinPE’s driver loading restrictions, not a malicious injection. Without it, network-mounted ISOs for Windows wouldn’t boot reliably.
The cert name (“JemmyLoveJenny”) is quirky but not inherently suspicious—it’s just a placeholder self-signed one, not tied to any known malicious actors.
By version 1.0.21 (released soon after the issue surfaced), they made changes:
Switched from the self-signed EV cert to WDKTestCert (a standard test signature from Microsoft’s Windows Driver Kit), which is less alarming and better suited for development/testing environments.
Added explicit documentation to the project wiki explaining the httpdisk.sys role, the cert usage, and how it differentiates from Ventoy (which doesn’t do this for USB booting).
Emphasized that iVentoy is fully open-source, so users can audit the code themselves.
Follow-up discussions on Reddit (e.g., in /r/sysadmin and /r/msp) largely concluded it’s a “non-issue” after the dev’s clarifications, with many admins continuing to use it in controlled environments.
No widespread reports of actual exploitation or malware tied to this emerged in the months following, and as of early 2026, the GitHub repo remains active with no new security flags on this topic.
My Take on It
Overall, I don’t think this is evidence of iVentoy being outright malicious or compromised—it’s more a case of poor initial documentation and an unconventional workaround that set off justified paranoia in security-conscious communities. Tools like iVentoy operate in sensitive areas (kernel drivers, cert stores, network booting), so any opacity can look bad, especially when AVs flag it.
The “JemmyLoveJenny” cert name doesn’t help optics – it’s meme-y but echoes tactics from real threats, like fake CAs in phishing kits.
That said, the developer’s quick response, code updates, and transparency post-issue are positive signs. Since it’s open-source, you can build from source or inspect the binaries yourself to verify. If you’re an IT admin using iVentoy:
Stick to versions 1.0.21 or later to avoid the old cert behavior.
Run it in isolated networks or VMs for testing.
Always scan downloads with VirusTotal and compare hashes against official releases.
If cert injection bothers you, alternatives like FOG Project or even built-in WDS might be safer for enterprise deployments, though they lack iVentoy’s ISO simplicity.
Final Words
iVentoy is a powerhouse for IT admins tired of media management. It’s technical yet accessible, scaling from home labs to enterprises. If you’re in virtualization or sysadmin, give it a spin – download from GitHub and try it yourself.
from StarWind Blog https://ift.tt/wqU63jn
via IFTTT
Cybersecurity researchers have discovered a vulnerability in Google's agentic integrated development environment (IDE), Antigravity, that could be exploited to achieve code execution.
The flaw, since patched, combines Antigravity's permitted file-creation capabilities with an insufficient input sanitization in Antigravity's native file-searching tool, find_by_name, to bypass the program's Strict Mode, a restrictive security configuration that limits network access, prevents out-of-workspace writes, and ensures all commands are being run within a sandbox context.
"By injecting the -X (exec-batch) flag through the Pattern parameter [in the find_by_name tool], an attacker can force fd to execute arbitrary binaries against workspace files," Pillar Security researcher Dan Lisichkin said in an analysis.
"Combined with Antigravity's ability to create files as a permitted action, this enables a full attack chain: stage a malicious script, then trigger it through a seemingly legitimate search, all without additional user interaction once the prompt injection lands."
The attack takes advantage of the fact that the find_by_name tool call is executed before any of the constraints associated with Strict Mode are enforced and is instead interpreted as a native tool invocation, leading to arbitrary code execution. While the Pattern parameter is designed to accept a filename search pattern to trigger a file and directory search using fd through find_by_name, it's undermined by a lack of strict validation, passing the input directly to the underlying fd command.
An attacker could, therefore, leverage this behavior to stage a malicious file and inject malicious commands into the Pattern parameter to trigger the execution of the payload.
"The critical flag here is -X (exec-batch). When passed to fd, this flag executes a specified binary against each matched file," Pillar explained. "By crafting a Pattern value of -Xsh, an attacker causes fd to pass matched files to sh for execution as shell scripts."
Alternatively, the attack can be initiated via an indirect prompt injection without having to compromise a user's account. In this approach, an unsuspecting user pulls a seemingly harmless file from an untrusted source that contains hidden attacker-controlled comments instructing the artificial intelligence (AI) agent to stage and trigger the exploit.
Following responsible disclosure on January 7, 2026, Google addressed the shortcoming as of February 28.
"Tools designed for constrained operations become attack vectors when their inputs are not strictly validated," Lisichkin said. "The trust model underpinning security assumptions, that a human will catch something suspicious, does not hold when autonomous agents follow instructions from external content."
The findings coincide with the discovery of a number of now-patched security flaws in various AI-powered tools -
Anthropic Claude Code Security Review, Google Gemini CLI Action, and GitHub Copilot Agent have been found vulnerable to prompt injection via GitHub comments, allowing an attacker to turn pull request (PR) titles, issue bodies, and issue comments into attack vectors for API key and token theft. The prompt injection attack has been codenamed Comment and Control, as it weaponizes an AI agent's elevated access and its ability to process untrusted user input to execute malicious instructions.
"The pattern likely applies to any AI agent that ingests untrusted GitHub data and has access to execution tools in the same runtime as production secrets -- and beyond GitHub Actions, to any agent that processes untrusted input with access to tools and secrets: Slack bots, Jira agents, email agents, deployment automation," security researcher Aonan Guan said. "The injection surface changes, but the pattern is the same."
Another vulnerability in Claude Code, discovered by Cisco, is capable of poisoning the coding agent's memory and maintaining persistence across every project and every session, even after a system reboot. The attack essentially utilizes a software supply chain attack as an initial access vector to launch a malicious payload that can tamper with the model's memory files for malicious purposes (e.g., framing insecure practices as necessary architectural requirements) and appends a shell alias to the user's shell configuration.
AI code editor Cursor has been found susceptible to a critical living-off-the-land (LotL) vulnerability chain dubbed NomShub that makes it possible for a malicious repository to clandestinely hijack a developer's machine by leveraging a mix of indirect prompt injection, a command parser sandbox escape via shell builtins like export and cd, and Cursor's built-in remote tunnel, granting the attacker persistent, undetected shell access simply upon opening the repository in the IDE.
Once persistent access is obtained, the attacker can connect to the machine without triggering the prompt injection again or raising any security alerts. Because Cursor is a legitimate binary that's signed and notarized, the adversary has unfettered access to the underlying host, gaining full file system access and command execution capabilities.
"A human attacker would need to chain together multiple exploits and maintain persistent access," Straiker researchers Karpagarajan Vikkii and Amanda Rousseau said. "The AI agent does this autonomously, following the injected instructions as if they were legitimate development tasks."
A novel attack called ToolJack has been found to allow a local attacker to manipulate an AI agent's perception of its environment and corrupts the tool's ground truth to produce unintended downstream effects, including poisoned data, fabricated business intelligence, and bogus recommendations.
"Where MCP Tool Shadowing poisons tool descriptions to influence agent behavior across servers and ConfusedPilot contaminates a RAG retrieval pool, ToolJack operates as a real-time infrastructure attack on the communication conduit itself," Preamble researcher Jeremy McHugh said. "It does not wait for the agent to organically encounter poisoned data. It synthesizes a fabricated reality mid-execution, demonstrating that compromising the protocol boundary yields control over the agent's entire perception."
Severe indirect prompt injection vulnerabilities have been identified in Microsoft Copilot Studio (aka ShareLeak or CVE-2026-21520, CVSS score: 7.5) and Salesforce Agentforce (aka PipeLeak) that could enable attackers to exfiltrate sensitive data through an external SharePoint form or a simple lead from a form submission, respectively.
"The attack exploits the lack of input sanitization and inadequate separation between system instructions and user-supplied data," Capsule Security researcher Bar Kaduri said about CVE-2026-21520. PipeLeak is similar to ForcedLeak in that the system processes public-facing lead form inputs as trusted instructions, thus allowing an attacker to embed malicious prompts that override the agent's intended behavior.
A trio of vulnerabilities have been identified in Claude that, when chained together in an attack codenamed Claudy Day, allow an attacker to silently hijack a user's chat session and exfiltrate sensitive data with a single click. The attack pipeline requires no additional integrations, tools, or Model Context Protocol (MCP) servers.
The attack works by embedding hidden instructions in a crafted Claude URL ("claude[.]ai/new?q=..."), encapsulating it in an open redirect on claude[.]com to make it appear legitimate, and then running it as a benign-looking Google ad that, when clicked, triggers the attack by silently redirecting the victim to the crafted "claude[.]ai/new?q=..." URL containing the invisible prompt injection.
"Combined with Google Ads, which validates URLs by hostname, this allowed an attacker to place a search ad displaying a trusted claude.com URL that, when clicked, silently redirected the victim to the injection URL. Not a phishing email. A Google search result, indistinguishable from the real thing," Oasis Security said.
In research published last week, Manifold Security also revealed how a Claude-powered GitHub Actions workflow ("claude-code-action") can be tricked into approving and merging a pull request containing malicious code with just two Git configuration commands by spoofing a trusted developer's identity.
At its core, the attack entails setting Git's user.name and user.email properties to those of a well-known developer (in this case, AI researcher Andrej Karpathy). This metadata trickery becomes a problem when an AI system treats it as a signal of trust. An attacker could exploit this unverified metadata to deceive the AI agent into executing unintended actions.
"On the first submission, Claude flagged the PR for manual review, noting that author reputation alone wasn't sufficient justification," researchers Ax Sharma and Oleksandr Yaremchuk said. "Reopening and resubmitting the same PR led to its approval. The AI overrode its own better judgment on retry. This non-determinism is the point. You cannot build a security control on a system that changes its mind."
from The Hacker News https://ift.tt/4DvStsm
via IFTTT
As macOS adoption grows among developers and DevOps, it has become a high value target; however, native "living-off-the-land" (LOTL) techniques for the platform remain significantly under-documented compared to Windows.
Adversaries can bypass security controls by repurposing native features like Remote Application Scripting (RAS) for remote execution and abusing Spotlight metadata (Finder comments) to stage payloads in a way that evades static file analysis.
Attackers can move toolkits and establish persistence using built-in protocols such as SMB, Netcat, Git, TFTP, and SNMP operating entirely outside the visibility of standard SSH-based telemetry.
Defenders should shift from static file scanning to monitoring process lineage, inter-process communication (IPC) anomalies, and enforcing strict MDM policies to disable unnecessary administrative services.
As macOS adoption in the enterprise reaches record highs, with over 45 percent of organizations now utilizing the platform, the traditional "security through obscurity" narrative surrounding the OS has been rendered obsolete. Mac endpoints, once relegated to creative departments, are now the primary workstations for developers, DevOps engineers, and system administrators. Consequently, these machines have become high-value targets that serve as gateways to source code repositories, cloud infrastructure, and sensitive production credentials.
Despite this shift, macOS-native lateral movement and execution tradecraft remain significantly understudied compared to their Windows counterparts. This research was conducted to address this critical knowledge gap. Through a systematic validation of native macOS protocols and system binaries, it is demonstrated how adversaries can “live off the land” (LOTL) by repurposing legitimate administrative tools. By weaponizing native primitives, such as Remote Application Scripting (RAS) and Spotlight metadata, intentional OS security features can be bypassed to transform standard system functions into robust mechanisms for arbitrary code execution and fleet-wide orchestration.
macOS is no longer a niche operating system. According to the Stack Overflow 2024 Developer Survey, a third of professional developers use macOS as their primary platform. These machines represent high-value pivot points, often holding source code repositories, cloud credentials, and SSH keys to production infrastructure.
Despite this trend, the MITRE ATT&CK framework documents far fewer techniques for macOS than for Windows, and recent industry reports indicate that macOS environments prevent significantly fewer attacks than their Windows or Linux counterparts. To address this disparity, community-driven resources such as LOOBins (living-off-the-orchard binaries) have emerged to catalog native macOS binaries that can be repurposed for malicious activity. This research aims to further close that gap by systematically enumerating the native pathways available for both movement and execution.
Establishing a remote shell is the first step in any post-exploitation chain. While SSH is the standard, native macOS features provide several alternatives that can bypass traditional monitoring.
Remote Application Scripting as a Software Deployment Tool (T1072)
Remote Application Scripting (formerly known as Remote Apple Events or RAE) was introduced to extend the capabilities of the AppleScript Inter-Process Communication (IPC) framework across a network. By utilizing the Electronic Program-to-Program Communication (“eppc”) protocol, administrative tasks and application automation can be performed on remote macOS systems. This mechanism allows a controller machine to send high-level commands to a target machine, which are then processed by the “AppleEventsD” daemon.
The Open Scripting Architecture (OSA) is utilized as the standardized framework for this inter-application communication and automation on macOS. Through the exchange of Apple Events, this architecture enables scripts to programmatically interact with the operating system and installed applications, providing the functional foundation for the “osascript” utility.
Traditionally, RAE is viewed as a lateral movement vector; however, this research demonstrates that it can also be utilized as a standalone Software Deployment Tool for Execution (T1072).
Adversaries attempting to use RAE for complex payloads often encounter Apple’s intentional security features, specifically the -10016 Handler Error. This restriction prevents the “System Events” application from executing remote shell commands via do shell script, even when RAE is globally enabled.
Figure 2. The -10016 Handler Error in remote application scripting.
To bypass this, a methodology was developed that treats “Terminal.app” as an execution proxy. Unlike “System Events”, “Terminal.app” is designed for shell interaction and accepts remote “do script” commands. To ensure payload integrity and bypass AppleScript parsing limitations (such as the -2741 syntax error), Base64 transport encoding is utilized. This transforms multi-line scripts into flat, alphanumeric strings that are decoded and executed in a two-stage process:
Deployment: A single RAE command instructs the remote “Terminal.app” to decode the Base64 string into a temporary path and apply chmod +x.
Invocation: A second RAE command explicitly invokes the script via "bash”, ensuring a proper shell context.
Figure 3. Terminal.app as an execution proxy for Base64 payloads.
Remote Application Scripting for Lateral Movement (T1021.005)
While RAE can be weaponized for execution, its primary function remains the facilitation of inter-process communication (IPC) across a network. In a lateral movement context, RAE is utilized to control remote applications by targeting the “eppc://” URI. This allows for the remote manipulation of the file system or the retrieval of sensitive environmental data without the need for a traditional interactive shell.
For example, the command in Figure 4 can be used to remotely query the Finder for a list of mounted volumes on a target machine, providing an adversary with immediate insight into the victim's network shares and external storage:
Figure 4. Remotely querying mounted volumes via RAE.
Because these actions are performed via Apple Events rather than standard shell commands, they often bypass security telemetry that focuses exclusively on process execution trees, making RAE a discreet and effective vector for lateral movement.
AppleScript execution via SSH
AppleScript is macOS's built-in scripting language for automation. While RAE is a viable application control mechanism, Apple security controls prevent RAE from launching applications; they must already be running. Additionally, RAE must be enabled on the target. To circumvent these obstacles, osascript can be invoked directly over SSH.
Passing osascript the system info command over SSH returns critical environmental details:
Figure 5. Retrieving system information via osascript over SSH.
For arbitrary command execution, AppleScript's do shell script handler can be invoked over SSH. In the following example, do shell script is used to write a file to the target:
Figure 6. Arbitrary file creation using do shell script over SSH.
While SSH alone can accomplish shell tasks, osascript provides access to graphical user interfact (GUI) automation and Finder manipulation through Apple Events IPC rather than spawning shell processes. This creates a significant telemetry gap, as most endpoint detection tooling has less visibility into IPC-driven actions than standard shell process trees.
socat remote shell
socat (SOcket CAT) is a command line utility for establishing bidirectional data streams between two endpoints. It supports a wide range of socket types including TCP, UDP, Unix domain sockets, and pseudo terminals (pty).
In a lateral movement context, socat can establish an interactive shell on a target without relying on SSH. The target runs a listener that binds a login shell to a TCP port with pty allocation, and the attacker connects to it from a remote machine.
On the target, the listener spawns an interactive bash session for each incoming connection with pty forwarding:
Figure 7. Establishing a listener with PTY forwarding on the target.
From the attacking machine, connecting to the listener provides a fully interactive terminal:
Figure 8. Attacker connection to the socat listener.
On the target, the reuseaddr,fork options allow multiple connections and reuse of the port, while pty,stderr on the exec gives the connecting client a proper terminal with stderr output. On the sender side, raw,echo=0,icanon=0 puts the local terminal into raw mode so that control characters and signals pass through to the remote shell correctly.
SSH is the de facto mechanism for gaining remote shell access on remote hosts, and as a result, it is where most detection engineering efforts are focused. socat achieves the same outcome, fully interactive terminal access, but operatesentirely outside the SSH ecosystem. There are no sshd logs, PAM authentication events, or “authorized_keys” to manage, which means detection pipelines built around SSH telemetry would not catch this activity.
Covert data transfer: Finder metadata abuse
A notable constraint of RAE is its inability to write file contents directly. To work around this, we can abuse the Finder Comment (“kMDItemFinderComment”) field, which is stored as Spotlight metadata.
Writing payloads to Finder Comments
A notable constraint of RAE is its inability to write file contents directly. To circumvent this, threat actors can abuse the Finder Comment field (“kMDItemFinderComment”) — a component of Spotlight metadata stored as an extended attribute. By storing a payload within metadata rather than the file's data fork, they can bypass traditional file-based security scanners and static analysis tools, which typically focus on executable code and script contents.
Because Finder is scriptable over RAE, the comment of a file on a remote machine can be set via the “eppc://” protocol. By Base64 encoding a payload locally, a multi-line script can be stored within this single string field. The make new file command handles the creation of the target file, ensuring that no pre-existing file is required:
Figure 9. Setting Finder comments via RAE for payload staging.
The payload resides entirely within the Spotlight metadata, a location that remains largely unexamined by standard endpoint detection and response (EDR) solutions. This creates a stealthy staging area where malicious code can persist on the disk without triggering alerts associated with suspicious file contents.
Extraction and execution
On the target, extraction and execution is a single line. mdls reads the comment, base64 -D decodes it, and the result is piped to “bash”:
Figure 10. Extraction and execution of metadata-stored payloads.
Persistence via LaunchAgent
This approach can be paired with a LaunchAgent for persistence. A plist in “~/Library/LaunchAgents” that executes the extraction chain at user login allows the payload to run automatically.
Our initial attempt using mdls inside the LaunchAgent failed because Spotlight may not be fully initialized when LaunchAgents fire. The fix was to replace mdls with osascript calling Finder directly to read the comment:
Figure 11. Persistence via LaunchAgent and Finder metadata.
Talos confirmed this successfully executes the payload at login. It is worth noting that macOS prompts the user to approve the bash execution at login, which is a visible indicator of background activity. The plist contains no payload, only a reference to metadata, so static analysis of the LaunchAgent would not reveal the malicious content.
Lateral Tool Transfer techniques
Once attackers achieve execution, they must move their toolkit across the environment. Several native protocols were validated for tool transfer (T1570).
Standard protocols: SCP and SFTP
SCP (Secure Copy Protocol) and SFTP (SSH File Transfer Protocol) are the most straightforward methods, operating over SSH and available out-of-the-box on any macOS system with Remote Login enabled.
Figure 12. SCP file transfer syntax.Figure 13. SFTP file transfer syntax.
SMB-based transfer
Server Message Block (SMB) is a network file sharing protocol commonly associated with Windows environments, but macOS includes native support for both SMB client and server functionality. In a lateral movement context, an attacker can mount a remote SMB share and access its contents as if they were local files.
This method of setting up an SMB share on the victim requires SSH access. The following command creates a shared directory, loads the SMB daemon, and creates the share.
Figure 14. Configuring a native SMB share on macOS.
With the share created, the next step is mounting it from the attacker machine. Attempting this action with the mount command failed due to an authentication error.
Figure 15. Authentication error encountered during SMB mount.
To resolve this issue, GUI access to the victim machine was required. On the victim machine, navigate to System Settings > General > Sharing > File Sharing > Options. Located here is the option to store the user's account password on the computer. Even though this is labeled as "Windows File Sharing", it was required to properly authenticate the user when using the mount utility.
However, this entire GUI dependency can be avoided by using osascript to mount the share instead of mount:
Figure 16. Mounting SMB shares via osascript.
This mounts the share to “/Volumes/share” without requiring the GUI configuration step. With the share mounted, any file copied into the mount directory appears on the victim immediately.
Netcat-based transfer
nc (netcat) is a well-known general-purpose networking utility that ships with macOS. It can be utilized to open arbitrary TCP and UDP connections, listen on ports, and pass data between them.
The simplest pattern involves piping commands directly into a netcat listener. On the target, a listener is established that pipes incoming data directly to sh:
Figure 17. Netcat listener established on victim machine.
From the attacking machine, a command is then echoed into nc targeting the victim's IP and port:
Figure 18. Command execution via Netcat (attacker side).Figure 19. Command execution via Netcat (victim side).
The attacker sends the curl google.com command over the wire, which is caught by the victim's listener and executed by sh. The resulting output confirms successful execution on the target.
Netcat can also facilitate file transfers through several different methods. An attacker could invoke a fetch to a remote system where a script or payload is hosted, or start a simple HTTP server on their own machine to perform ad hoc tool transfer.
Figure 20. Serving files via netcat (Attacker Terminal 1).Figure 21. Initiating file transfer via Netcat (Attacker Terminal 2).
Git-based transfer
git is a version control system ubiquitous in software development. Its prevalence on developer machines and reliance on SSH as a transport make git push a practical file transfer mechanism. The technique requires initializing a repository on the target and setting receive.denyCurrentBranch updateInstead. By default, git refuses pushes to a branch that is currently checked out on the remote. This setting overrides that behavior and updates the working tree on push, landing files on disk the moment the operation completes.
First, a receiving repository is initialized on the target over SSH:
Figure 22. Initializing a Git repository on the target.
On the attacker, a local repository is created with the payload, and the remote is pointed at the target:
Figure 23. Pushing payloads to the target via Git.
After the push, “script.sh” exists on the target at “~/repos/project/script.sh”. Additional file transfers only require adding new files, committing, and pushing again. Because git operates over SSH, the transfer is encrypted and uses the same authentication established for command execution.
TFTP (Standard and unprivileged)
TFTP (Trivial File Transfer Protocol) is a lightweight, unauthenticated file transfer protocol that operates over UDP. macOS includes both a TFTP server and client. The server is not active by default but can be started through launchd.
With root access on the target, the system's built-in TFTP plist activates the server in a single command:
Figure 24. Activating the native TFTP server.
This serves “/private/tftpboot” on the standard TFTP port (UDP 69). The TFTP system plist does not provide the -w flag to the tftpd process. Without it, the server only allows writes to files that already exist. A placeholder file must be created on the target for each file being transferred:
Figure 25. Creating a placeholder file for TFTP transfer.
From the attacker, the payload is pushed to the target:
Figure 26. Pushing payload to target via TFTP.
In a post-exploitation scenario without root access, tftpd can still be deployed by loading a user-created plist from “/tmp” on a non-standard port. This variant passes the tftpd -w flag, which allows write requests to create new files, removing the placeholder requirement.
Figure 27. Non-root TFTP server deployment.
SNMP trap-based transfer
SNMP (Simple Network Management Protocol) is used for monitoring and managing network devices. SNMP traps are unsolicited notifications sent from agents to a management station over UDP port 162. The trap payload can carry arbitrary string data under custom OIDs, which can be repurposed as a data transfer channel. macOS ships with the necessary net-snmp tools: snmptrap (“/usr/bin/snmptrap”) on the sender and snmptrapd (“/usr/sbin/snmptrapd”) on the receiver.
The approach works by Base64 encoding a file, splitting it into fixed-size chunks, and sending each chunk as an SNMP trap payload under a custom OID in the private enterprise space (“1[.]3[.]6[.]1[.]4[.]1[.]99999”). A trap handler on the receiving end reassembles the chunks and decodes the file. The protocol uses three message types: “FILENAME” signals the start of a transfer, “DATA” carries a Base64 chunk, and “END” triggers reassembly.
On the receiver, a trap handler processes incoming traps:
Figure 28. SNMP trap handler logic.
The snmptrapd daemon is then configured on the target to route all incoming traps to the handler and started in the foreground:
Figure 29. Configuring the snmptrapd daemon.
On the sender, a script handles the encoding, chunking, and transmission. Each chunk is sent as a separate SNMP trap with a short delay between sends to avoid overwhelming the receiver:
Figure 30. Script for SNMP chunking and transmission.
The sender initiates the transfer:
Figure 31. Initiating data transfer via SNMP traps.
The target receives the transfer:
Figure 32. Successful payload reassembly on target.
The matching MD5 hashes confirm the file was transferred and reassembled intact.
Socat file transfer
The socat shell established in the above "socat remote shell” section can also serve as a file transfer channel. Because the listener provides a fully interactive bash session, file contents can be written to the remote host by injecting a heredoc through the connection. This means socat alone handles both remote command execution and tool transfer without requiring any additional services or listeners.
With the socat listener running on the target, the attacker delivers a file by piping a heredoc-wrapped cat command through a socat connection:
Figure 33. File delivery via socat heredoc injection.
Detection and defensive considerations
Defending against LOTL techniques requires a shift from simple network alerts to granular process and metadata analysis.
Network indicators
Inbound TCP traffic on port 3031 (the “eppc” port) and unusual SNMP/TFTP traffic on internal LAN segments should be monitored for potential unauthorized activity.
Endpoint indicators (EVM)
Through mapping to the Open Cybersecurity Schema Framework (OCSF), an open-source effort to deliver a simplified and vendor-agnostic taxonomy for security telemetry, high-fidelity signatures for these behaviors were identified:
Suspiciouslineage: Process trees following the pattern launchd -> AppleEventsD -> Terminal -> sh/bash.
Metadatamonitoring: Frequent or unusual calls to mdls or writes to “com.apple.metadata:kMDItemFinderComment”.
Commandlineanomalies:base64 --decode commands originating from GUI applications or osascript executions containing “of machine "eppc://..."” arguments.
Native security controls and hardening recommendations
Several built-in macOS security mechanisms can be configured to mitigate the risks associated with native primitive abuse:
Transparency, Consent, and Control (TCC)restrictions: The "Automation" category within TCC is designed to regulate inter-application communication. By enforcing strict TCC policies via Mobile Device Management (MDM), unauthorized Apple Events between applications — such as a script attempting to control “Terminal.app” or “Finder” — can be blocked.
MDM Policy Enforcement: RAE and Remote Login (SSH) should be disabled by default across the fleet. These services can be managed and restricted using MDM configuration profiles (e.g., the “com.apple.RemoteAppleEvents”payload) to ensure they are only active on authorized administrative hosts.
Servicehardening: Unnecessary network-facing services, such as tftpd and snmpd, should be explicitly disabled. The removal of these launchd plists from “/System/Library/LaunchDaemons” (where permitted by System Integrity Protection) or the use of launchctl disable commands prevents their use as ad-hoc data transfer channels.
Applicationfirewalland Stealth Mode: The built-in macOS application firewall should be enabled and configured in "Stealth Mode." This configuration ensures the device does not respond to unsolicited ICMP or connection attempts on common ports, reducing the visibility of the endpoint during internal reconnaissance.
Conclusion
The research presented in this article underscores a fundamental reality of modern endpoint security. The same primitives designed for administrative convenience and system automation are often the most potent tools in an adversary's arsenal. By moving beyond traditional exploit-based attacks and instead LOTL, attackers can operate within the noise of legitimate system activity.
From the weaponization of the “eppc” protocol to the creative abuse of Spotlight metadata and SNMP traps, it is clear that the macOS attack surface is both vast and nuanced. These techniques demonstrate that even within a "walled garden" ecosystem, native pathways for movement and execution remain accessible to those who understand the underlying architecture.
For defenders, the primary takeaway is that visibility remains the most effective deterrent. By shifting focus from static file analysis to the monitoring of process lineage, inter-process communication, and metadata anomalies, these "bad Apples" can be identified and neutralized. As macOS continues its expansion into the enterprise core, the documentation and detection of these native techniques must remain a priority for the security community.
from Cisco Talos Blog https://ift.tt/aSlLHph
via IFTTT
