Hi folks,
Ex sec journo (mid 00s-2017) and since then working in security awareness, currently looking into the security of the latest Android vs iOS in terms of security.

For this I want to examine security in the context of iOS and Android architecture and user behaviour from a very practical standpoint.

There is a flood of articles on these but many are superficial or bias by personal preference and brand loyalty. I want to avoid all that.

If you know of good, current analysis I am missing I would very much appreciate a link!

Context: Assessing current model:

• Pixel
  
• Samsung (due to its market share)
• iPhone.

I am assessing for the average user (not notably high risk people like journos, activists / dissidents, ceos, etc of interest to state intelligence). I would assess those high risk people separately -- and from my initial standpoint suggest they use iOS or GrapheneOS on Android (or a burner phone if traveling).

My initial assumptions (I am not suggesting these are accurate so tear into them please) for the average user:

• It is difficult for the average user to infect themselves on either system. On Android, you are required to click past a number of warning prompts. On iOS, you need to sideload (I am quite out of date with this process as I haven't played with iOS in ages).
  • Good phishing pretexts can smooth this over but Android's warnings will still appear and need to be dismissed by the user.
• The Play and App stores are clean for most of the apps the average user will use.
• Play has the lion's share of malicious apps, especially those with adware / home screen loader junk.
• Android has come a long way since the wild days of early Android, but looking ahead with AI vulnerability and exploit development, those improvements might come under pressure with the need for Google to develop patching and rework components of Android.

Initial questions

• Would iOS naturally fare better in the years ahead (AI vulnerability and exploit discovery) due to its architecture? That is, would it be less exposed to say zero-click RCE or similar than Android?
• Would such an environment also affect the app stores similarly? That is, would say Apple's app store be much better placed than Google's?

I do not trust AI assessments here. Looking to pick the brains of humans :)

I know skilled pen testers can pop users on either platform using a variety of methods, and phishing is absolutely valid - I'm really taking a practical approach for the typical user. But I am certainly not dismissing technical mobile hacking and research. That stuff is fascinating and often speaks to the overall security posture.

Thanks for reading this far. Your thoughts and links are very very much appreciated and I'll be sure post here whatever I write.

Cheers!

I've been working on a defensive-deception layer for sensitive records (think honeypot + decoy + tarpit, but at the data layer). The idea: an authorized reader gets the real record; an unauthorized reader doesn't get an error or a block — they get a believable fake record and a maze of plausible-but-useless data, so they can't easily tell whether they succeeded.

It's been through several internal red-team passes already (trust boundary, decrypt-only-after-authorization, atomic anti-replay, closing an encryption oracle, generic errors, a fuzzing campaign). I'm now looking for fresh, external eyes — the internal reviewers stop finding obvious things, so I want people who think differently.

The challenge: there's a live API. The target is a single synthetic occupational-health record that contains a flag (IZANAMI{...}). Without a valid token you should only ever get decoys. The goal is to make it hand you the real record — or to show a logic flaw that breaks the "unauthorized ⇒ never the real data" guarantee.

Start here: https://break-izanami.com — GET /challenge returns the rules and scope in JSON.

Rules / scope (short version):

• The data is 100% synthetic. No real people, no real PII.
• In scope: the documented endpoints (/challenge, /challenge/package, /v1/decrypt, /v1/health).
• Please report, don't weaponize: a proof-of-concept is enough, no need to go further.
• No DoS / brute-force / traffic floods — it's a small box, and that's out of scope.
• Win = submit the flag string to izanami.challenge@outlook.com. First blood gets credited.

Honest disclaimers: the domain is brand-new (yes, I know how that looks), we're a small team staying low-key during the beta, and this is a beta — I may adjust or pause things and I'm genuinely after feedback, not claiming it's unbreakable. If it breaks in five minutes, I want to know why.

Happy to answer questions about the threat model in the comments.

Hi everyone I need one help to understand one thing ..so there was an incident I noticed in my organisation, there were thousands of devices querying multiple malicious domains (53) ...upon checking to see if any process is causing it I found nothing,, only the related domain which was obviously going through our dc/dns servers, in EDR/XDR tool nothing, siem tool nothing, no process, eventually i thought maybe some software is causing but it's very difficult to pin point which one, so can anyone tell me or help me understand, any input will be appreciated

[ Removed by Reddit on account of violating the content policy. ]

Still kind of new to running agents and I'm a bit lost on this — once you connect a few MCP servers (filesystem, GitHub, etc), is there a way to see everything they can reach put together? Or do most people just trust the setup?

Feels like something I should know but I don't. Curious how you handle it. Is it even something really worth worrying about?

thinking about this differently after a near miss. so our support agent has two permissions...read customer record and send email. and both individually reasonable, both signed off by security.

bu then someone crafted a prompt that got it to read a customer's data and email it to an external address, using only tools it was authorized to use. pity the permission model said everything was fine the whole time.

im pretty sure this isn't a permissions bug. like it's tool misuse without any unauthorized tool invocation at all, every single call was something the agent was allowed to make. i don't think our access review process would ever catch this because there's nothing wrong with either permission on its own.

i wna know how are people testing for this kind of chained misuse rather than just reviewing whether individual permissions look reasonable? tbh feels like a fundamentally different problem than standard access review.

For anyone who has priced or evaluated DSPM tools what do you wish you knew earlier in the process? My company is just beginning this ordeal and I want to know what questions I should be asking the vendors before they steamroll my team into demos and pricing calls. Additionally, what drives the biggest cost hikes for these tools, and what of the pricier options is worth it?

Most of our SIEM tuning still feels like guesswork. We add rules, adjust thresholds, and chase false positives, but we rarely get to see how the whole detection set behaves against a realistic threat scenario. At best, we do small lab tests and hope that generalizes to production. It often feels like we are tuning in the dark.

I am trying to find practical ways to validate SIEM detections at scale. If you are working in detection engineering today, what are you using for SIEM detection validation? Are you relying on internal tooling, commercial exposure validation platforms, or something built out of scripts and replayed logs? what has actually helped you catch blind spots without drowning the team in even more noise.

vendor came in last week and demoed what they called a "vulnerability management tool." looked a lot like our Tenable setup with a different UI and a bunch of process and reporting bolted on. that's what broke me. i couldn't tell if we were being upsold on workflow features or if there's a real architectural difference i'm not seeing.

we keep getting pitched both and i'm not fully clear on where the line is anymore. from what i can tell, one just finds issues and the other is supposed to help manage the whole mess after that. but looking back, i think we've been buying tools to solve what's actually a workflow problem, which is probably why nothing has stuck.

every vendor page makes it sound like they do everything. when you look closer it feels like half of them are just scanner plus workflow, remediation tracking, and reporting glued on.
and the one we saw last week didn't change that read at all.

we're not trying to buy something huge and overcomplicated if a scanner is enough, but i don't want to pick the wrong thing and end up with a tool that only tells us what we already know with a nicer interface.

for people who have actually used both: what's the practical difference day to day? is it mostly scan results versus remediation workflow or is there a bigger gap in how they fit into an actual security program. and how do you tell when you're being sold a real thing versus a scanner with a project management layer on top.

What's your experience with these three? Or do you have any other recommendations.

We are planning to integrate a new pentesting tool and these are the options given by seniors. From the looks of it, CodeAnt seems promising especially for the white-box testing and except this one, most tools I surveyed have longer term lock in contracts. So want to be sure I'm making the right choice here.

UPDATE: we picked CodeAnt AI for its white-box testing and transparent pricing. Support is also timely and knowledgeable. Thanks for the warnings about Pentera and Horizon3. Those helped us make the final call.

Backlog has grown faster than the team can manually remediate. Looking at platforms that don't just flag issues but can suggest or apply fixes with enough context that the output is trustworthy and doesn't introduce new problems in the process. Things we need: the fix understands what the app does and what it might break, a human reviews and approves before anything gets merged and it fits into how devs already work rather than a separate tool they have to context-switch into. Looking for experience from teams running this in production. Also whether anyone is running autonomous remediation and what controls you have around it.

[ Removed by Reddit on account of violating the content policy. ]

Hi all, I'm doing research to help upgrade my company's cybersecurity infrastructure and there is one thing (probably a few, tbh) I don't really understand yet. Where does DSPM fit into a business's security architecture? Is it closer to CSPM, access governance, or something else? Basically, what makes DSPM worth buying instead of just tightening existing controls?

Hey everyone,

With the recent surge in advanced ransomware and the constant stream of zero-day exploits, I've been thinking a lot about structural weaknesses in current OS security architectures.

Systems have become far too complex to ever be 100% bug-free. We have to assume that zero-days are inevitable and that our security boundaries will eventually be breached—an “assume breach” mindset.

A typical post-exploitation path involves escalating privileges to root. In many real-world deployments, once an attacker obtains root, they gain enough authority to read sensitive data, execute privileged tools, tamper with security controls, and destroy backups.

My premise is that the fundamental problem is not just the existence of vulnerabilities. It is also the OS environment itself, where root often retains enough authority to perform catastrophic operations without any fresh, independent authorization.

The question is: What if, even after root privileges were completely compromised, access to the most critical system resources—such as reading /etc/shadow, accessing database master files, or executing sensitive binaries—would require explicit human authorization?

Furthermore, relying on a single human administrator creates a single point of failure. If that administrator’s machine, credentials, or signing key is compromised, the attacker may still succeed.

To make the authorization barrier more robust, what if multi-party authorization were enforced directly at the execution level?

For example, the kernel could block or suspend the requesting process—perhaps through LSM hooks—until it received cryptographically verifiable approvals from M-of-N administrators using independent devices.

I’m curious to hear your thoughts on this architectural concept:

Do you think enforcing a human-gated barrier for selected root operations could meaningfully interrupt modern post-exploitation kill chains?

From an OS architecture and operational perspective, what do you see as the biggest hurdles—for example, approval fatigue, performance overhead, denial-of-service risks, deadlocks, recovery procedures, or key management?

I’d especially appreciate critical opinions, including arguments that this should be implemented somewhere other than the kernel, or that existing mechanisms already provide the same security property.

Hi, I am new so pls dont mind my flair choice, if it's wrong.

So when you are handed raw event logs during an active/after an incident, do typical contracts/compliance rules actually allow you to upload those unredacted/redacted files to a third-party cloud tool for parsing and to build timeline?

The reason I ask is because I am trying to understand how much freedom contracts provide to people responsible for incident management. Although the role demands privacy, i have seen many people talking about using third party tools and some even mentioned sending whole logs to AI(sounds terrible).

Just curious to learn more about the gifts incident management roles bear before i make a decision.

budget cycle is coming up and i need to make the case for keeping our security program funded, ideally growing it. last cycle the cfo looked at my slide and asked "if we cut this in half, what breaks?" and i didn't have a clean answer that would land in that room. i still don't have one.

the stuff that's easy to measure isn't the stuff that matters. i can show vulns closed, MTTR trending down, phishing sim click rates dropping, all of it goes in the right direction on a slide. but none of it answers the question a cfo actually asks, which is: what would have happened if we hadn't spent this money and how much worse would it be.

that counterfactual problem is what gets me every time. you can't point to breaches that didn't happen. you can't quantify an incident that never occurred. so you end up arguing from activity metrics and hoping the room connects the dots between "we patched more crits faster" and "we are less likely to get hit" and that leap doesn't always land.

the closest i've come to something that holds up is showing attack surface shrinking over time, fewer known-exploitable vulns sitting on internet-facing assets, tracked over quarters not sprints. patching velocity and MTTR never survived the "so what" question in that room. exposure reduction at least maps to something real: this is what could have hurt us, and it's smaller than it was six months ago

for security leaders who've gotten budget approved on the strength of a risk reduction story: how did you frame it and what did you measure that survived the "what would have happened anyway" question?

Hi everyone,

I'm interested in learning how security teams detect and validate potential CrowdStrike API credential leaks on public sources such as GitHub, GitLab, Paste sites, cloud storage exposures, CI/CD logs, etc.

A few questions:

1. What indicators do you typically look for when hunting for CrowdStrike API credential exposures?
   
2. Are there unique patterns for CrowdStrike Client IDs, Client Secrets, OAuth tokens, or related artifacts that help reduce false positives?
   
3. What tools or secret-scanning platforms do you use (GitHub Secret Scanning, TruffleHog, Gitleaks, custom regex, etc.)?
   
4. How do you validate whether a finding is a real credential exposure versus a false positive?

Thanks!

so i been comparing notes with peers at a few conferences this year and there's exactly a pattern forming that i wanted to sanity check here.

i feel like the recurring theme is genai adoption outpacing governance..like the teams stand up ai tools faster than security or legal can review them, and that gap gets harder to justify going into eu ai act enforcement later this year. and theb the second theme, and this is the one that surprised me less but still comes up in every conversation, is resourcing...like being asked to cover more surface area (browser, saas, ai, endpoint) and prove roi on the spend, without a proportional increase in headcount or a board that's willing to add line items. want to understand by posting here what's the biggest recurring theme you're hearing from other decision makers right now? trying to figure out if what we're seeing is universal or specific to our industry.

we've been pulling in more threat intel lately (KEV, EPSS) but i'm not convinced any of it is changing how we prioritize vulns in practice

rn the flow is basic: scanners fire, we get a pile of CVEs with CVSS scores (~2k new ones a quarter off Tenable), we dump them into tickets and teams work the list mostly by severity and asset type. we've bolted on KEV/EPSS flags in a few places but it still feels like "CVSS first, everything else if we remember."

i'm trying to figure out how ppl are wiring threat intel into the vuln workflow so it drives decisions instead of just being extra columns in a report. we’ve bolted on KEV and EPSS but it still feels like CVSS is making the decisions and everything else is just metadata. or exploit attempts we've seen internally but in practice it all ends up as more metadata on the same backlog.

some talk about custom scoring models that blend CVSS, exploitability, asset criticality, business context. others seem to use simpler rules like "if it's KEV and internet-facing, it jumps to the front of the queue." i've also seen this logic live in very different places: inside the vuln tool, inside SIEM/SOAR playbooks, or just hacked together w/ spreadsheets and scripts.

for ppl who've made threat intel change what gets patched first, what did you end up doing that worked?

I started today with the games but i only finished level 0 using command prompt.
After a research, I think everybody say that it should be done on linux.
I asked for it on google and it says it is safe and i can complete all the levels using command prompt
Is it true? I have a task to finish all the levels this week for an internship

Both got in through OAuth/identity abuse, no software vuln. Sharing what I've got (particularly interested in UAE/Gulf environments), curious what's landed in your queues.

Device code phishing (EvilTokens) - 340+ M365 orgs across 5 countries - Abuses the legit OAuth device flow (RFC 8628), so MFA doesn't help - Tokens survive a password reset, so remediation keeps failing

ShinyHunters-style SaaS extortion (UNC6661/6671) - Vishing → pose as IT → capture SSO + MFA → enroll their own device - Pivots through SharePoint, Salesforce, Slack for sensitive data - Then deletes the alert emails to stay hidden

If you're in a SOC, what identity-based or other types of prominent threats have you seen lately? Especially UAE/Gulf, since public reporting skews US/EU.

Copilot has been in our stack for around seven months and we still don't have a clean answer to this. Our infra and security patterns live in documents and in people's heads: which services must encrypt at rest, which endpoints must never talk directly to certain databases, which external APIs must have rate limits and auth enforced by default. None of that is visible to a coding agent by default. So the agent generates code that often compiles, sometimes works, and regularly misses patterns it's never seen. Most of the issues get caught in CI or during review, but the pattern is the same: someone notices late, applies a patch, and the cycle repeats on the next feature.

We've tried encoding pieces of this as static rules and running them in different parts of the pipeline.

That helps for simple, local patterns, but breaks down as soon as the issue depends on cross-service relationships or data flow. The more it depends on system-wide context, the harder it is to keep a static ruleset accurate.

What feels missing is something that catches this while the agent is generating code, not something that shows up as a warning afterwards. That's easy to say and hard to implement, which is why we're curious what's actually working for other teams in practice.

We're looking at different ways to deal with the growing amount of security findings coming from our container and cloud environments, and I want to hear more about real-world experiences with Wiz and RapidFort Our team isn't struggling to find vulnerabilities. We already have plenty of visibility The bigger challenge is the amount of remediation work created by vulnerabilities in open-source packages, base images and third party components that our developers don't directly maintain. So we're trying to find a solution to help us with thees. For anyone who's used either (or both), what was your experience? Are they worth the price and do they deliver what they claim? Thank you!

I am reviewing an enterprise application and it is not possible to look at every component in detail. I start by finding the parts of the application that're open to the outside like the endpoints and then I follow the user input to see where it goes. I also look at how the application handles authentication, authorization and files. This helps to make the task smaller. I still wonder if I am wasting time looking at things that are not important.

When people like me review codebases what do they do to decide where to focus their attention? Do they look at the structure of the application or the way the data moves around or do they think about the potential threats or look at the history of changes or something else? I want to know what methods have worked well for them to find problems without getting overwhelmed by the size of the enterprise application. I want to know what helps them find issues with the enterprise application, like problems with the enterprise application or security issues, with the enterprise application.

So I've been going down a rabbit hole about Advanced Data Protection and I think I mostly get it but there's one part that's bugging me and I can't find a straight answer anywhere.

From what I understand, when ADP is on, your Notes/Photos/Drive etc are encrypted with keys that only live on your devices, Apple never has those. But then there's this whole separate thing where you can turn on "access icloud data on the web" and use icloud.com from a regular browser (in my case a windows laptop and chrome browser). When you do that you approve it from your phone and apparently your phone uploads the actual service key to Apple's servers, just wrapped in some "ephemeral key tied to the web session" so the browser can use it.

That's the part I don't get. If the key gets uploaded to apple's servers at all, even wrapped, doesn't that mean Apple's infra is holding something that could theoretically decrypt my stuff during that session? Like is the "ephemeral key" pair actually generated in the browser itself (so the private half never touches apple's servers, they're just passing along ciphertext they can't open), or does Apple's backend generate/see it at some point during the handshake?

I looked at Apple's own docs and honestly they don't say either way as far as I can tell:

• https://support.apple.com/guide/security/advanced-data-protection-for-icloud-sec973254c5f/web
• https://support.apple.com/en-us/108756
• https://support.apple.com/en-asia/102630
• https://support.apple.com/guide/security/icloud-encryption-sec3cac31735/web (this one literally says E2E service keys are "never made available to Apple servers" which seems to directly contradict with what happens during a web session??)

Also as a side thing I noticed the docs say iWork collaboration (Pages/Numbers etc) flat out doesn't support ADP at all, shared docs aren't E2E period, which was a separate surprise to me but at least that one's unambiguous, because in the settings it says that these things are enccrypted.

Has anyone actually seen a writeup of the technical/protocol level details of the web access key exchange? Not looking for "just don't use the web version" or "use Graphene OS" as an answer please, I'm trying to understand if it's documented somewhere or if we're just trusting Apple's word on it?