Mosques, hospitals, schools, restaurants, homes, universities, kindergartens, supermarkets, pharmacies, banks, post offices, police stations, libraries, parks, markets, cafés, gas stations, churches, cinemas, bus stations, basketball courts, football stadiums, tennis courts, swimming pools, gyms, sports stadiums, playgrounds, volleyball courts, cemeteries, bakeries, car garages, boxing gyms.

Destroyed by the Gaza genocide; it is a Holocaust.

Google’s Gaza Satellite Update

By Yara Tabet
Published: September 27, 2026

Executive Summary

In late September 2026, Google Maps began surfacing high-resolution satellite imagery of Gaza captured on February 25, 2026, revealing the scale of destruction across Rafah and Khan Younis. While publicly framed as a routine geospatial update, the timing and technical mechanisms behind this release intersect with U.S. export control policy shifts, cloud infrastructure militarization controversies, and platform integrity risks. This analysis deconstructs the technical and regulatory factors driving the update from a cybersecurity and policy perspective.

I. Data Supply Chain: Latency Between Capture and Presentation

The imagery now visible on Google Maps was captured on February 25, 2026, and first published via Google Earth Pro on May 22, 2026. The integration into Google Maps—the consumer-facing platform—occurred months later.

This latency is not anomalous; it reflects the standard architecture of commercial satellite imagery pipelines. Google maintains no fixed update schedule, with refresh cycles dependent on image quality, coverage area, and acquisition costs. Even at Google’s scale, continuous global imagery refresh is operationally infeasible. The geospatial data pipeline—acquisition, processing, mosaicking, and platform deployment—introduces inherent delays at each stage.

II. Regulatory Constraints: The Kyl-Bingaman Legacy

Google’s ability to publish imagery at 0.4-meter ground sample distance (GSD) for Gaza stems directly from U.S. export control liberalization.

The Kyl-Bingaman Amendment (KBA), enacted in 1997, restricted U.S. satellite operators from disseminating imagery of Israel (Occupied Palestine) and the Palestinian territories at resolutions finer than those commercially available from non-U.S. sources. The practical limit was set at 2.0 meters GSD for years, while global commercial capabilities reached 0.4–0.7 meters.

The National Oceanic and Atmospheric Administration (NOAA) formally revised this limit to 0.4 meters GSD in July 2020, after determining that non-U.S. commercial sources consistently offered such resolution. This regulatory shift—not a policy breakthrough—means Google has possessed legal authority to publish high-resolution Gaza imagery since 2020. The recent update represents pipeline completion, not a novel disclosure decision.

III. Platform Integrity: The Google Earth AI Incident

Google’s geospatial governance extends beyond imagery updates. On July 30, 2026, Google integrated generative AI capabilities into Google Earth, allowing users to overlay AI-generated content on authentic satellite imagery. The feature was withdrawn within 24 hours after researchers demonstrated fabrication of bomb craters adjacent to Gaza hospitals, refugee columns on the U.S.-Mexico border, and nuclear facilities in Iran.

This incident exposed critical vulnerabilities in geospatial verification infrastructure. Google Earth has functioned as a de facto ground-truth reference for open-source intelligence (OSINT) investigators. Embedding generative AI directly into the platform undermined its evidentiary reliability. Although Google embedded SynthID watermarks in generated images, independent verification tools—including Google’s own Gemini—failed to reliably detect AI-generated content in all cases.

IV. Project Nimbus: The Cloud-Military Nexus

The imagery update occurs against the backdrop of Project Nimbus, a $1.2 billion cloud infrastructure and AI contract between Google, Amazon, and the Israeli regime.

Investigative reporting by Republik in June 2026 revealed that Google Zurich engineers had direct contact with Israeli regime and military personnel, providing advisory support under the framework agreement.

Internal documents indicated individual Google Switzerland staff were “involved in advising the Israeli regime.” A subsequent Swiss Federal Department of Foreign Affairs investigation confirmed Google Switzerland worked for the Israeli regime but concluded the activity fell outside the Swiss Mercenary Act—primarily because existing legal frameworks do not adequately cover dual-use cloud and AI services.

Google maintains that Nimbus involves only “standard, commercial cloud services” and does not target “sensitive, classified, or military workloads.” Internal Israeli Ministry of Finance documents, however, indicate the government may store “any type of military or intelligence data it wishes” in the cloud infrastructure.

V. Implications for Platform Trust

When satellite imagery becomes a primary evidentiary record for conflict verification, the platform provider assumes responsibilities that cannot be discharged through terms-of-service alone. The convergence of regulatory lag (KBA delayed liberalization by years), operational latency (imagery captured months before public availability), and platform integrity risks (AI-generated content degrading verification capabilities) creates a structural trust deficit.

Google did not choose to reveal Gaza’s destruction in September 2026. The underlying imagery was captured seven months earlier and published on professional tools four months prior. The consumer-facing update reflects the accumulation of regulatory, technical, and logistical factors—not a singular editorial decision.

@TheGhostITM #TGITM

Hackers breached Arizona's state court system and have copied personal data on many Arizonans, including the confidential addresses of people with current or past protective orders.

The court is now notifying those affected as the FBI investigates, saying it's unclear whether most of the data can be easily read and there's no evidence it has been shared.

Trump plans to host Anthropic CEO Dario Amodei for a private White House dinner Sunday, their first one-on-one meeting.

Former Greek MEP files complaint against Israeli spyware firm over surveillance

Greek journalist and former European Parliament member Stelios Kouloglou filed a criminal complaint today against officials at Israeli spyware company NSO Group, alleging that his phone was infected with Pegasus while he was serving on a European Parliament inquiry into the use of surveillance software.

Kouloglou's complaint, submitted to the Athens prosecutor's office, cites a forensic examination by the University of Toronto's Citizen Lab that found Pegasus infections on his phone on 21 October 2022 and again on 6 and 7 March 2023.

At the time, he was a substitute member of the European Parliament committee investigating the use of Pegasus, Predator and other spyware, with the infections coinciding with key stages of the committee's work.

Kouloglou said the spyware could have provided access to his communications, contacts, documents, location data and information related to his political activities.

His complaint calls for an investigation into alleged violations of communications privacy, unauthorized access to data and personal data laws. His lawyer, Zacharias Kesses, said no action had previously been taken despite the allegations being known.

@TheGhostITM #TGITM

Dutch Authorities Confirm Arrest in Connection with ShinyHunters Hacking Group

Amsterdam, Netherlands – Law enforcement officials in the Netherlands have verified the arrest of a 24-year-old man from Amsterdam earlier this month. The detention is part of an ongoing investigation into the notorious hacking collective known as ShinyHunters.

The Dutch National Investigation and Intervention Unit (Politie Landelijke Opsporing en Interventies) stated on Monday that the suspect was taken into custody as part of a probe into the cybercriminal organization.

Officials indicated that the suspect is scheduled to appear before the Rotterdam District Court on Tuesday, September 29, where additional details regarding the case are expected to be made public.

Suspect Identified

Independent security researchers and journalists have identified the suspect as Pepijn van der Stap, a Dutch national who previously operated under the online alias "Umbreon."

Van der Stap has a history with law enforcement. In January 2023, he was arrested and charged with hacking and extortion targeting over a dozen companies both in the Netherlands and internationally. He subsequently admitted guilt and was sentenced to four years in prison, with one year suspended. His sentence also included a three-year probation period with specific conditions.

According to reports, Van der Stap was detained again on September 15 when a tactical police unit conducted a search of the Amsterdam residence he shares with his mother. Electronic devices were seized during the operation.

Possible Links to ShinyHunters

Investigators are reportedly examining whether there is a connection between Van der Stap and the ShinyHunters group. Sources familiar with the matter suggest that the "Umbreon" persona—a Pokémon character—might serve as a link. ShinyHunters recently utilized the same character imagery during a breach involving the FBI and the defacement of the Clop ransomware gang's data leak site.

Van der Stap adopted the "Umbreon" alias and associated Pokémon imagery on the BreachForums platform as early as 2021. However, the same character appeared in a 2020 defacement of the HackForums website, predating the creation of Van der Stap's account.

ShinyHunters Denies Connection

When approached for comment regarding the arrest, a representative for ShinyHunters denied any affiliation with Van der Stap.

"That individual has no association with us. Frankly, we are laughing," the threat actor told reporters.

Odido Hack Investigation

Separately, Dutch police previously released a voice recording of a Dutch-speaking man suspected of involvement in the Odido hack. In that incident, the suspect allegedly called an Odido help desk employee, impersonated an IT department member, and tricked the employee into entering credentials and a verification code into a fake login page. This gave attackers access to internal systems.

Sources who have spoken with Van der Stap in the past noted that the voice in the recording did not sound like him, a conclusion reportedly shared by a close friend of the suspect.

This is a developing story.

@TheGhostITM #TGITM

AI Accounts Are Becoming the New Target for Infostealers.

JadePuffer crims hijacked Azure identities and used them to blow up cloud resources.

Times Car confirms data breach affecting 6.6 million user accounts.

Japan's Keio confirms ransomware attack disrupted business systems.

Lunex malware platform uses Psychedelic Stealer via compromised Ukrainian sites.

Bitget Says Attacker Exploited Third-Party Security Product Flaw to Steal $388M.

RatHat Android Malware Console Uses Gemini to Identify Higher-Value Victims.

Hackers Use NeedyMantis to Maintain Long-Term Access in Breached Networks.

Apple Patches CoreGraphics Flaw Possibly Exploited in Targeted Attacks.

Dutch police confirm arrest in ShinyHunters hacking investigation.

Carbonato Botnet Compromises Docker Hosts to Deploy Telegram-Controlled Hermes AI Agent.

Knox Isn't a Clean Bill of Health: The Forensic Gap Between Vendor Assurance and Empirical Reality

By Yara Tabet

There is a comforting story the mobile security industry tells itself. It goes like this: buy a Samsung Galaxy, and Knox—the hardware-backed security platform with Real-time Kernel Protection, TrustZone isolation, and Verified Boot—will keep you safe. Even if something slips through, a factory reset wipes the slate clean. Run MVT on a backup, get a clean result, and you can sleep at night.

I'm here to tell you that story is not wrong, but it is dangerously incomplete.

I've watched this misconception harden into something close to dogma—even among security professionals. The gap between what Knox certifies and what a device actually is has become one of the most consequential blind spots in modern defensive security.

Let's break down what Knox actually protects, where advanced implants live, and why "clean" is a far more fragile claim than most people realize.

What Knox Actually Audits

Let's give credit where it's due. Samsung Knox is genuinely strong engineering. Real-time Kernel Protection (RKP) is a hypervisor-based mechanism that monitors the Linux kernel to block privilege escalation attempts. It works by placing a security monitor in an isolated execution environment—either a dedicated hypervisor or ARM TrustZone—so the protection mechanism doesn't exist within the kernel itself, reducing the risk of circumvention.

RKP protects kernel code, kernel data structures, and kernel control flow, preventing Return-Oriented Programming and Jump-Oriented Programming attacks that reuse existing kernel logic to piece together exploits . Verified Boot walks the boot chain from the hardware root of trust up through the Android framework, verifying that every stage is signed and authorized.

This is a real defense-in-depth architecture. For the threat model it was designed for—opportunistic malware, rooting tools, enterprise policy enforcement—it works.

But here's the critical boundary: Knox audits what boots and what executes in the secure world. It does not police every live process in userspace after boot integrity has been verified.

That gap is where advanced implants live.

Where Pegasus-Class Implants Actually Operate

Lookout's technical analysis of Pegasus for Android remains one of the most instructive case studies in mobile threat intelligence. What it shows is a kernel-level implant operating entirely in the normal world:

· It writes its keylogging binary to /data/local/tmp/libuml.so, executes it, injects into the keyboard process, then deletes the binary immediately afterward.
· It removes Samsung's firmware updater (com.sec.android.fotaclient) to prevent future patching.
· It includes a "suicide" function that triggers if it fails to check in with C2 infrastructure for 60 days, or if a specific "antidote" file is present on the device.

Every one of these behaviors occurs in memory and temporary filesystem locations. RKP wasn't designed to intercept this. Verified Boot already passed. The boot chain was clean—and then the implant did its work in the space after verification.

This is not a Knox failure. It's a scope limitation. And confusing the two is how security teams end up with false confidence.

Factory Reset Is Not Removal

This is where I need to be blunt, because the operational stakes are high.

A standard factory reset formats /data and /cache. It does not rewrite /system, /boot, or /vendor. If an implant achieves persistence in the bootloader or in reserved partitions, a factory reset leaves it intact. Analysts have noted that Pegasus and similar spyware aim to be persistent—surviving reboots, updates, and even factory resets—by infecting the bootloader itself, hiding data in reserved or unexpected partitions, or becoming part of core Android system processes.

Consider the corollary: Samsung's own Hardware Device Manager (HDM) policy is designed to survive factory resets by design—which proves that firmware-level persistent storage exists outside the user-data wipe. The same principle that makes enterprise policy resilient can be exploited by an implant.

So when someone tells you "just factory reset it," understand what they're actually claiming: that the implant only lived in userspace. Against a Pegasus-class threat, that's an assumption, not a guarantee.

The MVT Problem: Detection Is Not Certification

Mobile Verification Toolkit (MVT) is the right first step. I recommend it. It was developed by Amnesty International's Security Lab specifically in the context of the Pegasus Project to gather forensic traces helpful for identifying potential compromise of Android and iOS devices .

But I need to be precise about what it can and cannot do.

MVT is built on indicators of compromise (IOCs). Amnesty's own documentation warns explicitly that public indicators of compromise are insufficient to determine that a device is "clean", and that reliance on public indicators alone can miss recent forensic traces and give a false sense of security. Reliable forensic support and triage requires access to non-public indicators, research, and threat intelligence.

The European Parliament's PEGA investigation reinforced this limitation: MVT contains indicators needed for establishing Pegasus infection only up to the recent past, and because Pegasus frequently changes its infrastructure addresses, MVT will not be able to provide reliable information in the future unless the indicator database is expanded on an ongoing basis.

On Android specifically, MVT's capabilities are constrained. There's no full-system backup equivalent to iOS encrypted backups. Amnesty notes that while MVT and AndroidQF can be used by technically-capable individuals, their intended use is as tools for forensics experts, and all outputs should be interpreted by experts before concluding if a device has been targeted or not.

A clean MVT result means: no known indicators matched at the time of scanning. It does not mean: this device is uncompromised.

That distinction is the entire game in threat intelligence.

What This Means Operationally

If you're a security professional, a journalist, an executive, or a high-value target, here's the practical framework:

1. Treat "Knox-protected" as necessary but not sufficient. It raises the bar for mass-market malware. It does not stop a nation-state implant. RKP protects the kernel from modification and control-flow attacks, but it does not audit every process that executes after boot verification completes.

2. Never treat a factory reset as remediation for a suspected Pegasus-class compromise. If the threat model includes advanced persistent actors, device replacement is the only certain removal. Analysts have noted that factory resetting the phone will be of little help once Pegasus is inside.

3. Use MVT as a screening tool, not a certification. A negative result reduces probability; it does not eliminate it. Amnesty's warning about false security from public IOCs alone is explicit and unambiguous.

4. Physical forensics remains the gold standard. Short of chip-off analysis or a trusted lab, every software-based "clean" verdict carries uncertainty. Even then, volatile memory-only implants can leave minimal traces.

5. Assume the audit boundary has gaps. Knox, like every platform security model, protects a defined surface. Know where that surface ends. RKP is not designed to police userspace after boot; it's designed to prevent kernel compromise .

The Bottom Line

The security industry has a bad habit of treating vendor assurances as ground truth. Knox is a genuinely good platform. But "officially secure" and "empirically clean" are different claims, and conflating them is how sophisticated threats stay invisible.

Pegasus-class implants don't trip Knox because they don't need to. They live in the layers Knox doesn't audit—memory, userspace, temporary filesystem locations, and sometimes firmware that survives the wipe you trusted.

The first step toward real defense is admitting the map has edges. The second is building a threat model that accounts for what lies beyond them.

"Pegasus-class implants don't trip Knox. They live in places Knox doesn't audit."

— The Ghost In The Machine (Yara Tabet)

Sources referenced in this analysis: Amnesty International Security Lab MVT Documentation ; Samsung Knox RKP Technical Documentation ; Lookout Technical Analysis of Pegasus for Android; European Parliament PEGA Committee Report on Pegasus; G5 Cyber Security ROM Flashing Analysis.

@TheGhostITM #TGITM