I've been doing iOS security assessments professionally for about 15 years — banking apps, fintech, enterprise platforms. Over that time, certain patterns keep showing up in production App Store binaries. Figured it's worth sharing what I see most frequently, since many iOS developers seem genuinely unaware these issues exist.
What keeps showing up:
The most common finding is hardcoded secrets in the binary — API keys, backend URLs, authentication tokens sitting right there in plaintext strings. Developers assume compilation somehow obscures these. It doesn't. Extracting them is trivial with standard tooling.
Insecure local data storage is a close second. UserDefaults for sensitive data, unprotected Core Data databases, plist files with session tokens. On a jailbroken device (or via backup extraction on a non-jailbroken one), all of this is readable.
Weak or misconfigured encryption comes third. I regularly find apps that import CryptoKit or CommonCrypto but use ECB mode, hardcoded IVs, or derive keys from predictable inputs. The encryption is technically present but functionally useless.
Then there's the network layer: disabled ATS exceptions, certificate pinning that's implemented but trivially bypassable, and HTTP endpoints mixed with HTTPS.
Methodology:
Most of this comes from static analysis — no runtime instrumentation needed. Download the IPA, unpack, run string extraction, inspect the Mach-O binary, check plist configurations, review embedded frameworks. You'd be surprised how much is visible before you even launch the app.
I've built custom tooling for this over the years that automates the initial triage across ~47 check categories. Happy to discuss methodology or specific techniques in comments.
I've also been running a monthly live session ("iOS App Autopsy") where I walk through this process on real apps — follow the link if interested.
For those who don't know: NaClCON is a new, intentionally small (300 person cap) conference focused on hacker history and culture, not zero-days or AI hype. Beach venue, open bars, CTF, the whole deal. $495 all-in.
The speaker list is a who's-who of people who built the scene:
Speakers:
Lee Felsenstein — Homebrew Computer Club OG, designer of the Osborne 1 (the first mass-produced portable computer)
Chris Wysopal (Weld Pond) — L0pht Heavy Industries, testified before the Senate in 1998 that they could take down the internet in 30 minutes, co-founder of Veracode
G. Mark Hardy — 40+ years in cybersecurity, talking "A Hacker Looks at 50"
Richard Thieme — Author/speaker who's keynoted DEF CON 27 times, covering the human impacts of tech since the early internet days
Brian Harden (noid) — Helped build the LA 2600 scene, DC206, and DEF CON itself. Now farms and writes about himself in third person
Izaac Falken — 2600 Magazine / Off The Hook, 30 years in professional security
Mei Danowski — Natto Thoughts, speaking on ancient Chinese strategy and the birth of China's early hacker culture
Josh Corman — "I Am The Cavalry" founder, CISA COVID task force, currently working on UnDisruptable27
Casey John Ellis — Bugcrowd founder, co-founder of disclose.io, White House, DoD, and DHS security advisor
Jericho — 33+ years in the scene, speaking on life in an early 90s hacker group
Andrew Brandt — Threat researcher (Sophos, Symantec), demoing early hacking tools on obsolete hardware
Johnny Shaieb: IBM X-Force Red, speaking on the history of vulnerability databases
B.K. DeLong (McIntyre) — Attrition.org, the team that manually archived 15,000+ web defacements in the late 90s
Jamie Arlen — 30+ years, Securosis, Liquidmatrix; "an epic career of doing all the wrong things and somehow still being right"
Heidi and Bruce Potter — Developers of Turngate and founders of ShmoonCon
Dustin Heywood (EvilMog) — IBM X-Force, Team Hashcat, multi-time Hacker Jeopardy World Champion
Fireside chats include noid doing DEF CON war stories and Edison Carter on old-school phone phreaking in the 80s/90s and a grog filled night with the dread pirate Hackbeer'd.
A couple things worth knowing before you register:
The conference hotel (Courtyard by Marriott Carolina Beach Oceanfront) has a room block at $139/night (roughly 70% off the peak beach-season rates) so book through naclcon.com/hotel or use group code NACC. Block expires May 1st so don't sit on it.
P.S. If the tickets are too large a hurtle for you, DM me and I'll see what I can do to get you a discount code.
Hi everyone, I’m a Cybersecurity student at HFU in Germany and recently submitted a vulnerability to the Google VRP regarding the Google Password Manager on Android (tested on Pixel 8, Android 16).
The Issue: When you view a cleartext password in the app and minimize it, the app fails to apply FLAG_SECURE or blur the background. When opening the "Recent Apps" (Task Switcher), the cleartext password is fully visible in the preview, even though the app actively overlays a "Enter your screen lock" biometric prompt in the foreground. It basically renders its own secondary biometric lock completely useless.
Google's Response: Google closed the report as Won't Fix (Intended Behavior). Their threat model assumes that if an attacker has physical access to an unlocked device, it's game over.
The BSI Discrepancy: What makes this interesting is that the German Federal Office for Information Security (BSI) recently published a study on Password Managers. In their Threat Model A02 ("Attacker has temporary access to the unlocked device"), they explicitly mandate that sensitive content MUST be protected from background snapshots/screenshots. So while Google says this is intended, national security guidelines classify this as a vulnerability. (For comparison: The iOS built-in password manager instantly blurs the screen when losing focus).
What are your thoughts on this? Should password managers protect against shoulder surfing via the Task Switcher, or is Google right to rely solely on the OS lockscreen?
I have built an open source CLI tool to help conduct DNS related audits. Let me explain the rationale and the roadmap.
So I have worked in DevSecOps for the past few years and at 3 different companies I have built som variation of this to handle issues raised by SOC tools and to help to do basic black box pentesting. After doing it the 3rd time I decided I should take a stab at open source and build it properly myself.
What it offers is CAA, DMARC, DKIM, SPF, MX, DNSSEC and some header audits (basic ones like HSTS and CSP). Output can be done via rich terminal, JSON, Markdown and SARIF and baked into it is an “sdk” layer which would allow you to develop internal tools on top whilst getting access to the fully typed Python objects.
The next step is honestly inspired by a BS scare tactic email sent to the non-technical CEO and founder of a start up I was at where the sales person made false claims about the posture of our DMARC in order to trick the CEO into a sales call. Personally, I’m quite passionate about security and I believe in a world of cat-and-mouse security (where the cats are the hackers / exploiters), tools that help with basic security should be free. This leads us to the next phase, a dockerised app to conduct the audits based on your configuration at regular intervals with alerting through the appropriate channels.
I would appreciate anybody who took a look, gave it a go and provided any feedback (or anybody who wants to help contribute!). This is my first go at open source and building a tool like this so really any feedback is appreciated. Docs can additionally be found at https://dnsight.github.io/dnsight/
With the news of Hundreds of orgs being compromised daily, I saw a really cool red team tool that trains for this exact scenario. Have you guys used this new white hat tool? Thinking about ditching KB4 and even using this for our red teams for access.
AI coding tools are being shipped fast. In too many cases, basic security is not keeping up.
In our latest research, we found the same sandbox trust-boundary failure pattern across tools from Anthropic, Google, and OpenAI. Anthropic fixed and engaged quickly (CVE-2026-25725). Google did not ship a fix by disclosure. OpenAI closed the report as informational and did not address the core architectural issue.
That gap in response says a lot about vendor security posture.
We benchmarked Opus 4.6's ability to find simple C vulns and found that the model flags about 1 in 4 flaws -- with a very high false positive rate and lots of inconsistency from run to run. Techniques like judge agents and requiring the model to justify its results improve the results to some extent, but they're still not great.
Nicholas Carlini (Anthropic research scientist) used Claude Code and a 12-line bash script to find hundreds of remotely exploitable Linux kernel vulnerabilities — including one introduced in 2003 and undiscovered for 23 years. He's holding most of them unreported. His words: "I'm not going to send the Linux kernel maintainers potential slop." The bottleneck isn't finding bugs anymore. It's validating them fast enough. Here's the part that matters for defenders: That validation constraint only binds researchers following responsible disclosure. An attacker running the identical script has zero validation requirement — they probe directly from unverified findings. The asymmetry is structural, not technical. It's baked into how responsible disclosure works.
And the framework was already failing before AI arrived:
32% of vulnerabilities exploited on or before CVE issuance
Median exploitation window: 5.0 days (down from 8.5)
AI can generate working CVE exploits in ~10 minutes at ~$1 per exploit
130+ new CVEs weaponised daily at scale
We ran this problem through four structured Crucible analysis passes and produced a white paper. The conclusion: responsible disclosure needs a named replacement framework — Post-Exploitation Response Coordination — which accepts that exploitation will happen before validation and rebuilds around detection, response, and recovery speed instead.
A new investigation, dubbed BrowserGate, claims that LinkedIn (Microsoft) is quietly running hidden JavaScript on linkedin.com that probes users’ browsers for installed extensions - over 6,000 of them, all without consent and transmits that data back to LinkedIn & third parties. Researchers argue this isn’t just passive fingerprinting because users are logged in with real names, employers & roles, the data can be tied directly to identifiable people and used to infer sensitive info like job‑search status, political/religious interests, health‑related tools, or corporate tooling usage.
The report also highlights potential GDPR and privacy‑law issues, and the detections reportedly include both competitor tools and personal‑interest extensions. LinkedIn has not publicly refuted the core claim. More details with technical details, sources etc in the linked article.
Built an automated npm package scanner that uses heuristic scoring + LLM analysis to flag malicious packages in real time. Ran it for 24 hours against ~2000 recent npm registry changes and found 21 malicious packages across 11 campaigns.
Four novel attack vectors documented:
LLM API MITM (T1557): makecoder@2.0.72 overwrites ~/.claude/ via postinstall, reconfigures Claude Code client to proxy all API calls through attacker server. Application-layer MITM on AI assistant conversations.
Encrypted skill distribution (T1027, T1105): skillvault@0.1.14 fetches encrypted payloads from private API, decrypts locally, installs as persistent Claude Code skills. Server-side swappable without npm update.
AI agent as RAT (T1219, T1036.005): keystonewm/tsunami-code ship functional coding assistant CLIs routing all interactions through attacker's ngrok tunnel. Exploits AI tool trust model where users grant full filesystem access voluntarily.
Redis CONFIG SET + raw disk read via postinstall (T1190, T1006): 6 fake Strapi plugins use Redis to write shell payloads to 7 directories, dd if=/dev/sda1 to extract credentials bypassing file permissions, Docker overlay traversal for container escape.
All IOCs, decoded payloads, and MITRE mappings on the site. None of the 21 packages were flagged by any public scanner at time of discovery.
My write up around a research project I've been doing in my spare time around investigating the security of AWS CodeConnections. This post covers the techniques I used to hook a CodeBuild job to monitor the requests the CodeBuild bootstrapping makes before user code is run. Using this information I then also show the endpoints I found that can be used to retrieve the raw GitHub App token or BitBucket JWT App token CodeConnections uses which tends to be very privileged in a lot of environments, granting far more access than to just the single repository where the CodeBuild job is being run.
CVE-2026-33579 is actively exploitable and hits hard.
What happened: The /pair approve command doesn't check who is approving. So someone with basic pairing access (the lowest permission tier) can approve themselves for admin. That's it. Full instance takeover, no secondary exploit needed. CVSS 8.6 HIGH.
Why this matters right now:
Patch dropped March 29, NVD listing March 31. Two-day window for the vulns to spread before anyone saw it on NVD
135k+ OpenClaw instances are publicly exposed
63% of those run zero authentication. Meaning the "low privilege required" in the CVE = literally anyone on the internet can request pairing access and start the exploit chain
The attack is trivial:
Connect to an unauthenticated OpenClaw instance → get pairing access (no credentials needed)
Register a fake device asking for operator.admin scope
Approve your own request with /pair approve [request-id]
System grants admin because it never checks if you are authorized to grant admin
You now control the entire instance — all data, all connected services, all credentials
Takes maybe 30 seconds once you know the gap exists.
What you need to do:
Check your version: openclaw --version. If it's anything before 2026.3.28, stop what you're doing
A massive data breach (allegedly) has occurred at Adobe. Carried out by a threat actor calling themselves "Mr. Raccoon", the claims are that over 13M support ticket details have been leaked along with details of over 15,000 employees. Additionally, they have access to their microsoft SharePoint instance and also to make matters worse, Adobe's HackerOne account. Adobe is yet to comment on this matter.
I've written a scanner for XPI browser extension files which analyzes a browser extension for malicious content. It will print everything that is suspicious or could be used for something malicious so that you will know if and where you can begin with your malware analysis. Example output of a Firefox malware extension (which is live on firefox extensions store)
I have written the above script, and I ran it against 15~ random extensions from the store with less than 10K downloads, and it didn't take me more than 10 minutes to find the malware extension above.
I've also completely reverse engineered the extension to find out exactly what it does, and written an article about it where I walk you through the code and exploitation process steb-by-step, showing all the techniques used to hide from the verification processes in the extension store, breaking out of the sandbox and stealing credentials with a full Command and control server controlling it.
The malware code is very sophisticated. The payload never touches the DOM. It never appears in network DevTools as a suspicious request. It is stored in extension localStorage where casual inspection won't find it. But my scanner will catch it.
Techniques used:
Steganographic Payload in PNG Icon
Unicode Low-Byte Encoding Trick
Decoded Payload: The C2 String Table
72-Hour Sleeper with Random Sampling
C2 Beacon via Another PNG File
Dynamic `declarativeNetRequest` Rule Injection
Affiliate Commission Hijacking
Content Script Privilege Escalation Bridge
Arbitrary URL Redirect on Any Domain
CSP Erasure
Full deep dive analysis with code examples in link above. The extension discussed is live as of today.
── CRITICAL ────────────────────────────────────────────────────────── [CRITICAL] [PNG_APPENDED] icon/logo.png: 1902 bytes appended after PNG IEND (entropy=5.63) — classic stego carrier CODE: b'ncige\x1f\xe3\xbd\xa9\x18\xe3\xa1\x84\xe1\xa1\xa1\x18\xe3\xa1\xb9\x1f\xe3\xbd\xb3\x1c\xe3\xb0\xba\x1b\xe5\xac\xa0\r\n\… ── HIGH ────────────────────────────────────────────────────────────── [HIGH ] [CLASS_STORAGE_OVERLAP] js/content.js: String literal '7yfuf2' appears both as a JS string in this file and as an HTML class attribute in index.html — likely used as a covert stego marker or out-of-band key CODE: class='7yfuf2' in index.html [HIGH ] [CLASS_STORAGE_OVERLAP] js/content.js: String literal 'ncige' appears both as a JS string in this file and as an HTML class attribute in index.html — likely used as a covert stego marker or out-of-band key CODE: class='ncige' in index.html [HIGH ] [JS_OBFUSCATION] js/content.js:380 atob() — decoding base64 at runtime (possible payload decode) CODE: '); fileTip = atob(contentPool[screenValues]).replace(image Context: if (contentPool && contentPool[screenValues]) { var image$1 = new RegExp(pageArr.buffer$1[37], 'g'); fileTip = atob(contentPool[screenValues]).replace(image$1, ''); dataExt = JSON.parse(fileTip); screenValues = dataExt.map [HIGH ] [JS_OBFUSCATION] js/content.js:719 atob() — decoding base64 at runtime (possible payload decode) CODE: return dataExt ? atob(atob(this)) : btoa(this).replace(/=/g, " Context: function reContentAll(dataExt) { return dataExt ? atob(atob(this)) : btoa(this).replace(/=/g, ""); };
Login
/r/netsec - Information Security News & Discussion
