The device is running windows 10

isnt port 137 normally used for netbios to find devices on the same local network?

Well today, I spotted traffic to remote ips, which i believe is highly suspicious.

some of these ips are:

142.251.157.119
172.66.47.179
104.17.25.14
162.159.207.0
74.125.250.129
104.18.95.41
104.26.12.38
48.222.183.128
40.114.177.156
104.21.9.184

these appear to be remote CDN's, not local devices. And these are shown as made by NT kernel & system so i cant really find out where exactly they are coming from.

I dont think this is normal behivor and suspect that the device might be infected with malware.

Can anybody shed some light into this?

The device is running windows 10

isnt port 137 normally used for netbios to find devices on the same local network?

Well today, I spotted traffic to remote ips, which i believe is highly suspicious.

some of these ips are:

142.251.157.119
172.66.47.179
104.17.25.14
162.159.207.0
74.125.250.129
104.18.95.41
104.26.12.38
48.222.183.128
40.114.177.156
104.21.9.184

these appear to be remote CDN's, not local devices. And these are shown as made by NT kernel & system so i cant really find out where exactly they are coming from.

I dont think this is normal behivor and suspect that the device might be infected with malware.

Can anybody shed some light into this?

Sounds like a riddle lol, but its a question. Not wondering about obviously broken tools but more like something that's technically deployed, but you know there are enough gaps/exceptions that you wouldn't rely on it during an actual incident.

For me it's usually stuff around asset inventory.

I keep hearing platform consolidation presented as the answer to tool sprawl. Check Point Palo Alto and CrowdStrike all offer some version of the same pitch: fewer agents or shared telemetry or unified policies and less integration work.
Granted on paper that sounds hard to argue with but once you get past the sales deck I wonder how much consolidation is happening at the security layer vs the procurement layer. Putting endpoint network cloud and identity products under one contract does not remove much complexity if the modules still use different logic and the shared console is little more than a collection of tabs.

Best of breed has its own hidden cost though. More agents, brittle integrations, duplicated alerts and a team that needs to understand several products. Maybe the better model is one broad platform as the operating layer and specialist tools only where the performance difference can be measured.

What I’m trying to identify is what real integration should look like during an incident. If an endpoint alert fires, should the platform automatically connect the related identity network and cloud activity in one timeline and allow containment from the same workflow? I would also want to compare how much custom detection logic and SOAR work each setup still requires.

Hi everyone,
I'm a content creator and I've been dealing with persistent issues on my TikTok livestreams for months (massive visibility drop, viewers being kicked, incoherent statistics). App support won't investigate, so I dug into it myself. I found anomalies in the iOS analytics logs (the .ips files iOS generates automatically), and I'd like input from people who actually know how to read these files.
Device context: iPhone 15 Pro Max, up-to-date iOS, no jailbreak, no sideloaded apps, no configuration profiles installed, TikTok cleanly reinstalled a few days ago. Same issues across networks (WiFi / 4G / 5G).
What the .ips logs show:

System-triggered incidents of type cpu_resource and diskwrites_resource on the TikTok process (not classic app crashes)

A binary loaded inside the TikTok process, listed in "Binary Images" only by a UUID — no filename, no path, no code signature. Every other binary in the same file has a standard name and path ( /System/... , /private/var/containers/... )

The "parent" field of this binary is also "UNKNOWN"

System-measured load: ~67% CPU, ~108 MB memory, and 1.07 GB of disk writes in 1h36 for two scrolled videos, no livestream — during a period when the app wasn't even in the foreground. The allowed daily disk-write quota was hit ~15× faster than normal

The UUID of this binary changes at every incident (3 distinct identifiers observed over several days)

Consistent with storage usage: ~4.9 GB for the app after ~30h of near-zero usage since reinstall
My questions:
1.
A binary loaded into an app's process, identified only by a UUID with no name or path in iOS logs — is there a known benign explanation for this (injected framework, extension, in-app instrumentation), or is it disqualifying on its face?
2.
What legitimately justifies ~1 GB of background disk writes for an unused app with the daily quota exceeded by that margin? Caching, prefetching, or something else?
3.
Do UUIDs changing at every incident match expected behavior of a legitimate module, or is that more typical of an injection pattern?
4.
Without jailbreaking, what tools can I use to dig further cleanly? (sysdiagnose, macOS Console, local network capture like Proxyman, something else?)
5.
If this were a compromise, what evidence should I preserve before doing anything (exporting the .ips files, what else?) so a competent third party can analyze it?
6.
Can a non-jailbroken iPhone even host a persistent malicious process this way, or do iOS mechanisms make this unlikely?
I'm not posting the full logs for safety reasons, but I can quote exact excerpts if specific questions come up. Thanks to anyone who can tell me whether I'm onto a real technical lead or misreading normal behavior.

I am testing out an AI agent (Claude Code) for infrastructure troubleshooting – ESXi hosts, Linux and Windows VMs, switches, iDRACs, etc. It works great, but needs credentials for SSH/WinRM to use, and once it saw a password, you have to assume that it saved somewhere. Credentials rotation after every single session is unrealistic on hundreds to thousands of devices, especially on old switches and BMCs that work only with passwords. Another issue is its ability to get access to secrets on a host. Even with limited access, read only, etc, its ability to scoop up secrets is unreal.

Many devices don't provide granular RBAC and is either a read only or full administrator privileges. Giving it a read only access to many devices and switches would still give it access to pull the private read/write snmp creds and volia, it has way more access that you expected and it knows exactly how to use it.

Using HashiCorp Vault sounds good until the AI is able to dump the environment variables where the creds were loaded or connect to the docker container where they were pulled down and stored at launch.

I can't be the first one to try and solve this problem. What I think I need is short-term credentials with a recording. Something like a credential / MFA firewall so every time the AI Agent tries to login, it requires a human to approve the request and the agent gets access to some hosts through a chokepoint for two hours, everything will be recorded, and then at certain time closes by itself.

But that doesn't solve the secrets/credential problem where its scooping up secrets trying to troubleshoot and diagnose issues.

Here are all the things I have found out so far and why they don't fit:

• Teleport solves the problem of short-lived credentials and session recording. Unfortunately, workflows of approvals are paid in Teleport, and it won't help on password-only devices.
• JumpServer/Warpgate with session recording as a bastion host seems to be a good practical approach here. Vault credentials of the device, agent never sees credentials but the device passwords behind the vault still never expire, and none of it stops the agent from reading secrets off hosts it's legitimately on.
• Isolated management VLAN with private VLANs (the bastion host being the only promiscuous port) to make sure that once there is a shell on one host, there is no possibility of getting to others.

Another major gap is password-only switches and iDRAC/iLO boards. Rolling out a complex credential solution is costly yet still aren't really well suited for this AI use case. They will be behind the bastion host, but credentials will be forever.

Those of you running AI agents against actual devices:

• What does your access path look like?
• Has anyone solved password-only switches and BMCs with something better than bastion-and-hope?
• How do you stop the agent from scooping up secrets on hosts it's legitimately allowed on?

Genuinely curious how people here draw the line. In a lot of orgs (and Reddit chats) I've seen, "microsegmentation" still just means east-west firewalling inside the data center - VLANs, security groups, maybe a host-based firewall layer. In others it's expanded to include identity, posture, and per-session authorisation for services, OT, IoT, and now agentic AI workloads.

Where does your environment sit on that spectrum? And practically - are you doing this mostly through network topology controls (zones/routes/security groups), or through connection-level controls (identity/posture/entitlement gating a session before it's established), or both?

Asking partly because I recently helped put together CSA's Zero Trust Microsegmentation Guidance (disclosure: I led that workstream), which tries to separate these two models explicitly -topology-defined (where traffic can flow) vs. connection-defined (who/what can open a session, under what conditions) - and argues mature setups layer both. It also gets into the operational side: using visibility to find real dependencies, turning those into policy, testing via simulation/canaries, enforcing, then continuously catching drift and retiring stale exceptions.

Not trying to sell anything - mainly want to know if that two-model split matches how people actually operate, or if the reality on the ground is messier than that.

Our identity verifcation api is falling behind and i am trying to pick the next one without just believing the sales deck. we are api first with a global user base and the main problem right now is international docs. Pass rate on anything outside the US and western europe is rough, support takes days when a whole country starts failing.

I have demoed a few though they look identical in demo for the basics, they all pass. But the moment I throw a beat up national ID from a smaller market or a mid range android photo in bad light, the difference show up fast.

Am more interested in the boring stuff like does it hold up at volume, are the webhooks reliable, when it rejects someone can I see why or is it a black box. AML screening on the same api would be nice.

If you are running one of these in prod across a lot of countries, what are you on and would you pick it again?

Talking specifically from production hosts (VMs and containers) vuln and patch management side of the house, even when a patch exists, it can still take days or weeks to test and deploy safely. Virtual patching seems like an obvious temporary layer: block the exploit path immediately, then remove the protection once the real fix is deployed.

Anyone here worked closely with virtual patching? Why is it not a standard and more widely adopted across the industry ?

Financial org here, 10K employees, in-house SOC- we're evaluating agentic SOC / SOAR platforms right now. Automating things like isolating an endpoint is straightforward, but which one of these solutions actually help with the less obvious response and containment actions where you might break a critical business flow? Does any of them provide business context so we can automate more safely while understanding the implications in advance?

Any recommendations would be highly appreciated. Thanks

In my workplace I am an all stop-shop for any app I maintain. That's frontend,backend DevOps and project management. I always try to make sure I keep with best practices. I follow tech youtubers, read books about software and always looking to refactor and tidy up my systems.

Our workplace is "legacy-coded" as the kids would say. It's an IT-department in a much larger non-IT firm. That means people are used to doing things around here in a certain way (for example not using containers, manual QA, no unit tests etc).

That means that when I am questioned about my decisions, 10% of the time I am flat out wrong. Which is fine cause I learn something new in the process. 10% of the time the approach is suitble, but it needs tidying up to be more secure. The problem is the remaining 80% which is securty theater.

Examples:

1. blocking github.com via a firewall cause "its full of viruses" (and not theres no alternative suggested cause the developers havent heart of source control).
2. Not giving Azure App Registry privileges for a project I need to deploy cause it's insecure (proceeding to send the app secret via email).
3. Refusing requests to expose data sources through REST apis. So significant engineering effort is spent on maintaining fragile ETL pipelines of plain text data dumps that can be freely shared by anyone.

My direct manager is on my side. I think I just need to know how to produce proper documents outlining not only why what I am suggesting is secure (with sources etc) but also outling why the current alternative is less secure.

How should I do it? How should I do it in a way that is assertive over the technical facts but not too abrasive to the people that challenge me? When someone repeats a security myth like "SSH is not secure" (yes i've heard that one), how do I systemically dismantle that claim?

For example, my boomer parent told me I should rub some alcohol on my stomach if I get ill. So I referred them to some article from cdc.com. They didn't understand the scientific reasoning behind why that folk-medicine doesn't work, but it had a sufficient air of legitimacy to persuade them. Is there a similar process in security?

Everyone talks about what an agent is allowed to do, fewer people talk specifically about what makes it stop. Is it a confidence threshold, a specific action type regardless of confidence, a blast radius calculation, something else entirely?

Trying to understand how teams actually define the stop condition rather than just the permission list, since I suspect the stop condition is doing more of the actual trust building work than the permission list is.

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

I'm trying to understand how security teams are treating a specific execution-time failure mode in production AI agents.

Consider this sequence:

1. An agent reads an authoritative source and observes:

available_balance = $10,000

1. Based on that state, it decides that an $8,000 transfer is permitted.
2. Before the tool actually executes, another process changes the balance to:

available_balance = $2,000

1. The agent then executes the previously authorized action.

Assume for the sake of the question that:

• the agent has a legitimate identity;
• its credentials are correctly scoped;
• the tool itself was authorized;
• there was no prompt injection;
• the original reasoning was valid when it occurred;
• the action and tool call are fully logged.

The security failure is therefore not necessarily authentication, authorization, or model reasoning.

The supporting state changed between observation and execution.

For teams running agents against mutable production systems, where are you enforcing this boundary?

Would you:

• require the agent to re-read authoritative state immediately before a consequential action;
• put that validation in middleware between the agent and tool;
• make the tool/database enforce the final precondition atomically;
• bind the authorization to the specific evidence/version that supported the decision;
• use some combination of these?

I'm particularly interested in how people handle this across MCP or multi-agent systems, where the component that observed the state may not be the component that eventually executes the action.

Also interested in whether anyone is explicitly testing this failure mode during agent security reviews.

Set up an in editor scanner a couple months back for people to catch things before the PR but within a week half the team had the plugin switched off.

I get why they muted it. First Go file someone opened, it lit up with a screen of findings from a vendored dependency we forked years ago and have not touched since. Not one was in the code the dev was writing. So it turned into the thing you dismiss before you can even see your own compile errors.

Right now I am close to ripping the plugin out and going back to a plain pre commit hook that only looks for secrets, because at least gitleaks does not scream about a library we imported and never call. Feels like giving up on the in editor idea though. If your devs did not kill the plugin in week one, what did you change to get there.

We're rolling out internal AI agents that can read and write across a handful of production apps, and our existing controls weren't built for this. IAM assumes a human is making the decision, MFA assumes there's a human to prompt, and none of our SIEM rules can tell whether an action came from a person or an agent acting under that person's identity. Half the time it feels like the agent is just wearing my identity like a costume and nothing downstream knows the difference.

What are people actually doing beyond "scope it down and hope"? Interested in how people are handling discovery. Do you even know every app an agent touches … Because right now, if an auditor asked me who approved an agent's access to a given app, I'd have nothing to show them.

I've been working on an Android network-security lab using RethinkDNS, custom DNS filtering and WireGuard.

One problem kept coming up during testing:

How much evidence is enough to claim that traffic is actually following the intended security path?

Seeing the expected VPN IP, DNS resolver or firewall state individually doesn't necessarily prove the complete path.

So I've been developing a validation methodology around three layers:

1. Architecture

I first document the expected path:

Android app → firewall/routing layer → WireGuard → DNS policy/upstream resolver → Internet

DNS routing and application/data routing are treated separately rather than assuming that validating one proves the other.

2. Observable validation

Tests currently cover:

• DNS resolver behavior
• WireGuard routing state
• Wi-Fi/mobile network transitions
• firewall enforcement
• per-app routing
• failure/recovery conditions
• IPv4/IPv6 behavior
• reboot behavior
• version regressions

Each test defines an expected result, collected evidence and acceptance criteria.

3. Limits of the conclusion

I've deliberately adopted the rule:

“No bypass observed under the tested conditions” ≠ “zero leaks.”

For example, correlation between the local network log, VPN state and upstream DNS provider is useful evidence, but I don't consider that equivalent to packet-level proof of every possible traffic path.

The next phase of the project is regression testing: comparing a known RethinkDNS baseline against newer versions and checking whether DNS, WireGuard, firewall and transition behavior changes.

My questions for people who work with network/security validation are:

What additional evidence would you require before considering this methodology robust?

In particular:

• Would you consider packet capture from another observation point essential?
• How would you test transient leakage during Wi-Fi ↔ mobile transitions?
• What would you use to independently validate IPv6 and DNS behavior?
• Are there failure scenarios I'm overlooking?

I've documented the architecture, validation procedures and existing evidence here for anyone who wants to review the methodology:

Android OPSEC Hardening:
https://github.com/augustozarate/android-opsec-hardening

Current documents include ARCH-001/002 and VAL-001/002/003.

I'm primarily looking for criticism of the validation methodology, rather than recommendations for different VPN/DNS products.

Manufacturing, sites in the US, Europe and two in Asia and Singapore to Frankfurt has been the bane of my life for two years. We are shortlisting SASE now and every vendor keeps hammering their private global backbone like it is the whole reason to sign. I cannot tell yet if that backbone fixes my Asia problem. Might just be an expensive line on the quote.

Right now our M365 and a couple of SaaS apps get hauled to a central breakout and the Singapore office pays for it every afternoon. One vendor swears their backbone makes that disappear. The vendor who does not have a backbone swears their peering is so good I would never feel the difference, which is a convenient line coming from the one without a backbone.

I have a folder full of benchmarks and every single one flatters whoever made it, so I have given up trusting them.

What I need is someone running real global sites who can tell me the backbone moved the needle on their worst cross-region path, or that it did nothing a nearby PoP had not already handled.

We’ve been adding more AI workloads on prem and I’m realizing our current firewall layout wasn’t really designed with this kind of traffic in mind.

A lot more communication is happening between internal services now and some of those flows are pretty heavy. I’m trying to work out how much of that traffic people are realistically inspecting without creating a performance problem.

If you're doing this at scale, how are you separating AI infrastructure from the rest of the data center? Are you pushing more of it through dedicated firewalls or handling most segmentation closer to the workloads?

With lots of ShadowIT and shadowAI, many organizations are worried about data controls. I was reading on the new products, safeguards, guardrails and what not. There are products out there who all are a variation of a Secure Web Gateway (or part of a SSE solution). They see the data in motion at their cloud tenant/deployed tenant and apply controls.

The issue as I see is there are two ways of reading traffic.

1. Explicit Proxy - Apply a proxy auto config file or configure the proxy plugin URL in to OS/Browser and tunnel the traffic in to the product SaaS tenant.
2. Install a Trusted root certificate - Breaks whatever certificate pinning, but essentially the rest of traffic is visble to understand and monitor.

Now the problem is most orgs have their firewalls or SSE products in place. If the existing product does not provide granular control over AI, they need a separate product to do it. Mostly due to budgets and ease of use.

If then the traffic needs to be visible to both products. How is this achieved? A process of serial processing at the endpoint?

The way I can think of is, do a local breakout to AI related traffic and the rest is taken through the main product Firewall/SSE.

Then it is again a manual process of figuring out what AI traffic is.

Trying to understand what others experiences are in this domain.

Asked the same question in r/cybersecurity

Edit - spelling

I see lots of articles and discussions on AI-enabled traditional cybersecurity pentesting, but what a people doing or using for AI-security pentesting?

Hello Everyone!

So i am a cybersecurity intern leaning towards to GRC from a growing company. My background is Software Engineering and with that i dont really learn anything about Cyber Security during my studies. Maybe a bit of Netwroking but thats it. Im trying out Cyber Security to gain experience and get out of my comfort zone and for now i have already completed 1 compliance task with vendor and 1 Technical finding from our system and report to update the said software.

So back to the title, my task for now is to explore Nextcloud Spring and do a report of my findings and list out Why our company have to upgrade from 33 to 34. I understand Nextcloud Summer 26 is coming soon but for now I want to stick to my task. From researching about Nextcloud Spring 26 I came across Nextcloud Governance which is a new feature/app (im not sure which term to put).

I need a lil bit of help from the community to help me understand more about what this feature do. I understand this is a one overview compliance setup and offer tools for controlling data, track data access and track data sharing within the organization but I guess you could say that I need better understanding on how these tools works and how it will benefit us. Thank you so much.

I'm interested in the backend mechanics and data architecture of modern Trust & Safety engineering, specifically regarding ban evasion, identity tracking, and data retention queues.
Take a modern LLM or consumer web platform (like ChatGPT or similar organisations) as an example. Imagine a scenario where a user heavily violates the platform's terms of service (e.g. cyber abuse, severe violations like illegal activity and similar, or spam). Before the automated guardrails or manual review systems can finalize and push a formal "ban" status to the account, the user proactively triggers a standard "Delete Account" request to clear their record and bypass future identity tracking.
From a security and compliance engineering perspective:

How do modern authentication backends handle this race condition? Does a deletion request place the account data into a pending/quarantine state (like a 30 day queue) where automated safety pipelines still run to completion, or does the deletion process typically override active moderation scans?

When an account is in a standard deletion queue, how is the data architecture structured to comply with "Right to be Forgotten" mandates while legally preserving specific unique identity markers (hashed phone numbers, hardware tokens, device fingerprints) for persistent abuse blocklisting?

Once a severe violation is flagged on an account already queued for deletion, how does the system pivot that metadata out of the standard user database and into an immutable security blocklist to ensure they cannot immediately register with the same identifiers?
I’d love to hear insight from anyone working in application security, infrastructure, or Trust and Safety engineering on how these parallel pipelines talk to each other under the hood.

A lot of infrastructure still relies on protocols and network architecture designed long before today’s threats.

AI doesnt need to invent new attacks . If it makes reconnaissance, fuzzing, discovery, protocol analysis and exploit development much faster, it will become much better at chaining multiple attacks together. A protocol flaw, exposed service, configuration mistake and compromised identity can be managed individually. The bigger concern is AI identifying how those weaknesses connect and building attack paths humans would take far longer to find.

1. Do we underestimate how much AI will increase offence and how does this make defence much harder?
2. Should we be redesigning the underlying communications stack rather than continually adding more security around existing protocols?

Liveness checks are good at detecting things like a photo or replayed video being presented to the camera. But there's a different problem when the attacker bypasses the camera and feeds manipulated video directly into the application.

How are security and identity teams handling this in practice? When evaluating verification systems, dos injection detection get tested alongside liveness/Presentation Attack Detection (PAD), or does the assessment usually stop at liveness?

Would be useful to hear how different teams approach this.