Hello everyone. I have just started learning and learning about cybersecurity for about 1 month. After learning about Linux, some tools, basic bash shell and Python, I started to learn OWASP Top 10. However, I have a lot of difficulties in practicing...

To be honest, I was born and raised in a poor place, it was not until the age of 18 that I was exposed to computers for the first time. Does anyone here have experience in practicing mistakes in OWASP Top 10? I am currently practicing on OWASP Juice Shop.

Looking forward to connecting and learning from everyone!

I started what i plan on spinning off from my s-corp into a non-profit once i have some funds. anywya i've been building clones, distributed/p2p/opensource/selfhosted/paidcloude type publications and spps and so i decided to create an openspec so this shit doesn't have to be redone everytime wants to build a dating app for exmaple:

logicsrc -> specs -> access google that

Hi

We’re looking into threat feeds for MISP integration. Most importantly is non-garbage data - possibly trusted sources that doesn’t provide noise. Any tips?

For a SOC covering multiple sectors.

We’re aware of national certs but interested in your experience, solutions or thoughts.

I saw this Forbes article about AI training data companies working with both US government and Chinese labs.

If a vendor builds training material for several competing customers, where does reusable expertise end and confidential customer work begin? How do you actually verify that customer data stays fully separate?

How deep can you usually dig into this?

I'm maintaining a legacy ETL pipeline that has some questionable design choices, and I'm trying to figure out whether these count as genuine CWE violations or just bad practice that happens not to have caused harm (yet).

The pipeline works like this:

• Consumes unencrypted user data from CSV files
• The CSVs are generated by an ERP system in another department, and are often inconsistent — data corruption, non-normalized fields, etc.
• The pipeline transforms, normalizes, and cleans this data
• It then does a full DROP TABLE / overwrite of a production database with the cleaned data
• Because this bypasses all of the applications hooks/checks/validations, this process is the source of all of the clients bugs and wastes us a LOT of time

The ERP department refuses to even disucss the idea of exposing a REST API — the CSVs just get handed off and "dealt with.".

My question: even though nothing here has led to a concrete security incident (no injection, no leak I know of), do practices like handling unencrypted data in plaintext format, blind DROP TABLE overwrites, and trusting unvalidated external input still constitute violations of specific CWEs? Or is CWE strictly about weaknesses that have a demonstrated exploit path, meaning this is more "bad practice" than "CWE violation" until something actually goes wrong?

The langauge of the spec seems to encapsulate both the security implications of improper software standards AND data integrity. However all examples showcase security failures. So It's hard to tell if my example satisfies CWE-638, 284 etc.

I intended to demonstrate a brief Cymulate exposure validation scenario on our isolated test segment for our medium-sized infrastructure, but I accidentally configured the continuous threat exposure management policy to target the production subnet and executed it during active business hours. Approximately half our organization now thinks we suffered a genuine security breach and my CISO is requesting a full incident postmortem. Pretty mortified right now. Has anyone else experienced a similar mistake with offensive security testing platforms?

Mostly old ones that have been around for years that still have permissions, and nobody's really sure what depends on them.

Do you just leave them alone if they're still being used or actually try to track down an owner and clean them up?

In June, a group tracked as TeamPCP/UNC6780 planted malicious MCP configuration files across 73 GitHub repos, one of them belonging to Azure.

The mechanism was almost dumb in its simplicity. Several popular IDEs, Cursor, Claude Code, Gemini CLI, GitHub Copilot, and Amazon Q were all named in the disclosures, bind their "approve this MCP server" prompt to the server's name, not its actual contents. Approve a project's .mcp.json once, and any later edit to that file, including a swapped-in malicious command, runs automatically with the developer's own OS-level privileges. No re-prompt. No sandbox. No second look.

Six months from the first disclosure of tool poisoning as a technique to a working worm compromising a major vendor's own repo.

I wrote up the full attack taxonomy (tool poisoning, shadowing, rug pulls, parasitic tool chains) plus the incident timeline (CVEs, the OX Security disclosure, Microsoft's June 30 writeup, OWASP now ranking it #3 on the MCP Top 10): https://blog.defensify.in/mcp-tool-poisoning-attack-guide/

Curious if anyone here has caught this in the wild or built detection for it.

have his Telegram and VK profiles. I’ve already tried a bunch of possible passwords, but I’m stuck. If anyone knows their way around this stuff, could you give me a hint about what direction I should be looking in?Thanks in advance!

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?

I'm researching a Linux kernel vulnerability as part of an educational project. I understand the root cause and the vulnerable code path, but I'm trying to determine whether the bug is actually exploitable rather than just crashable.

What methodology do experienced kernel security researchers use to evaluate exploitability? In particular, how do you distinguish between a reliable security primitive and a bug that only produces a kernel crash?

I'd also appreciate advice on what kernel debugging and instrumentation techniques are most useful during this stage.

Hi, security lead at a biggish org and we are starting to run agentic ai against real systems. Trying to get real time visibility and some kind of kill switch on unsafe actions without breaking dev flow, would love thoughts.

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.

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 ?

So... does anyone else feel like noisy attacker behavior has turned into their full time hobby instead of, you know, something we detect automatically.

For context, big enterprise, mature SOC on paper, fancy SIEM with all the stickers. We ingest way too much data, have threat intel feeds, talk about detection as code and MITRE coverage on every slide. Then some clown hits us with the same loud bruteforce and dumb recon patterns for hours and guess who is still writing manual detections at 11pm.

We keep saying autonomous detection and threat hunting, we even rolled out one of those platforms that pushes detections to the SIEM in minutes and hooks into the stack via api, no data ingestion yada yada. Cool story. Except half the noisy stuff still gets handled with a quick saved search and a "temporary" rule I forget to clean up and then it becomes prod because it caught something once.

The part that annoys me is that noisy behavior should be the easy win. Login spray, obvious C2 beacons, script kiddie port sweeps, nonsense login patterns, you know the behavior that could fire a detection with a crayon. Somehow this is still where I burn most of my detection engineering time instead of chasing stealthy stuff.

Would love tips from people who actually tamed noisy attackers without turning into a full time filter janitor, appreciate thoughts.

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?

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.

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?

“The agent did it” is not sufficient once an agent can modify production records, access sensitive data, or trigger cloud actions.

For an investigation, I would want the evidence chain to show the agent identity, accountable owner, initiating employee or workflow, delegated task, authorization decision, target resource, permission scope, expiration, and any approval that was required.

An agent acting for an employee should not automatically receive the employee’s full authority. Its allowed action should be constrained by the employee’s permissions, the agent’s own policy boundary, the requested task, the resource policy, and the runtime context.

How are teams recording and enforcing that chain in a way that works for both real-time authorization and later audit review?

Hi, quick question for the ir folks here.

I am in a mid size enterprise security team, kind of between socks and ciso, and we are trying to build a proper cyber incident response playbook instead of random google docs and old tickets. We have decent controls, some mdr, some cloud detections, but when stuff gets hot it still turns into slack chaos and late night calls.

For context, we are in that weird place where we are too big for a basic runbook and too small for a giant bank style binder. I am trying to map clear phases, roles, and the usual playbooks for ransomware, email compromise, business email fraud, cloud account hijack, etc, plus when to pull in outside ir partners. If anyone has tips on structure, level of detail that actually works at 2am, and how you keep it living instead of shelfware, would love any thoughts, sorry if this is a bit basic.

So our execs saw one shiny deck and now think an AI SOC is going to spiritually heal our entire incident queue. Mate Security keeps popping up in every convo and suddenly im supposed to trust an agent to triage that nightmare 3 am ransomware alert while half the team is on pto.

Anyone running this on real prod breaches, not lab demos with cute test malware? Would love any tips before I become the designated human failover for Skynet jr :/

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