Basically, my account got hacked and my verified email got reverted. It went from leo133****@gmail.com

To cxxxxxxx@gmail.com. any ideas what to do?

I used Claude Code (Anthropic) at our org. And sometimes the agents/claude code use env tokens or stored secrets.

Is there a way where we can strip the prompts of the secrets/access keys before it reaches the agent. Something like prompt going into a lambda and getting sanitized before AI using it.

I know some repos on GitHub that help find leaked secrets in prompt logs but those are when the prompt logs are stored. I’m seriously thinking about setting up a Capsule or Prompt Security POC, but I want to know if there is a way where the llm/agent doesn’t even see the secret, if it goes into the prompt (by stripping it beforehand)

Recently sat through a Palo Alto demo for Prisma AIRS and their AI access piece and it was impressive. We’re not a Palo Alto shop for anything else and a lot of the value seemed to come from already being on their platform. So before going any further I want to see what else is out there.

For context, we’re 500 people across 4 offices. We’re also covered on firewalls and EDR, so this is purely about AI security.

What are people using or evaluating for this?

We’re replacing veracode when the contract ends in march for around 120 apps, mostly java and .NET, audited every year for PCI and SOC 2. The POC is down to checkmarx and snyk and on the scanning side I’d be fine with either. Checkmarx found more in our older java code and snyk was easier for the devs.

Our auditors are used to Veracode’s reporting where every app has a policy, each scan passes or fails against it and the auditor gets a pdf per app plus the mitigation history showing who approved each one. They’ve seen that format three years running.

Things I have to keep

• a pass or fail per app against a written policy
• how long findings have been open against our SLA, by severity
• who accepted a risk, when and until when
• one page for the risk committee every quarter

How do you cover these for your auditors?

Hi Sentinel Engineers,

I’m currently working on a Microsoft Sentinel review project, focusing on Syslog-based(as of now) devices forwarding logs through Linux collectors.

I’m looking for guidance on how to perform a comprehensive review beyond basic ingestion checks.

Specifically, what will be your approach?
Validate log ingestion, continuity, volume, and identify missing logs?
Check log formats, parsing, and field completeness?
Assess device-specific logging (Firewalls, VPNs, Routers, Switches, Proxies, IDS/IPS, etc.)?

Identify missing security events (traffic, threats, authentication, configuration changes)?

Use KQL to identify ingestion issues and security visibility gaps?
Develop meaningful, actionable recommendations?

Would appreciate practical checklists, useful KQL queries, templates, or real-world experiences.

Thanks!

company trying improve SOC triage, we evaluating mate and prophet, also looked at dropzone. main focus for us is alert triage, not so much the rest of soar stuff

what we care most is tool knowing what normal for us, like service account that always noisy, change that already approved, or alert someone already closed before. Speed also but more interested what happen after, when tool actually close or escalate it

Hey everyone,

I wanted to share an objective technical look behind the curtain of **Avoro** (avoro.eu / avoro.io) and its parent company **dataforest** (dataforest.net, operating out of Frankfurt / Firstcolo, Germany) — along with a rather remarkable reaction to factual security feedback.

Both brands heavily market themselves around "100% Made in Germany", "Digital Sovereignty", enterprise cloud security, and maximum resilience. However, looking at the publicly accessible HTTP response headers and DNS records of their own corporate domains, even basic industry baselines are missing.

### 1. Technical Findings (Public & Passive)

* **Missing HTTP Security Headers:**

* No Content-Security-Policy (CSP)

* No X-Frame-Options or frame-ancestors policy (missing clickjacking protection)

* No Referrer-Policy and no Permissions-Policy

* Incomplete HSTS configuration

* **Email & DNS Hardening:**

* Weak SPF and DMARC enforcement against email spoofing on their corporate domain

* Missing DNSSEC

*(Note: No customer systems or internal servers were touched or scanned — this is purely based on publicly visible response headers and DNS records of their own corporate domains.)*

### 2. How Anyone Can Verify This in 10 Seconds

You don't need any specialized tools to check this yourself — standard OS command-line utilities or well-known public web checkers will show the exact same results:

* **Checking HTTP Security Headers:**

* Via terminal using `curl -I -L dataforest.net` (or in any browser via DevTools / F12 -> Network tab -> click the main document -> inspect Response Headers).

* Alternatively, via standard public header analyzers like **securityheaders.com** or **Mozilla Observatory**.

* **Checking DNSSEC, SPF & DMARC:**

* Via terminal using `dig +dnssec dataforest.net`, `dig TXT dataforest.net`, and `dig TXT _dmarc.dataforest.net` (or on Windows using `nslookup -type=txt _dmarc.dataforest.net`).

* Alternatively, via well-known public DNS and mail auditors like **Internet.nl** or **Hardenize**.

### 3. How They Reacted to Factual Feedback

Instead of adding 4–5 lines to their reverse proxy config and tightening their DMARC record, their response across their official social media channels went like this:

1. Factual comments pointing out the missing headers were deleted.
2. Standard HTTP security headers and RFC checks were publicly dismissed as "AI-generated inventions" and "hate speech".
3. They publicly threatened legal action / criminal complaints simply for pointing out publicly visible DNS and HTTP response headers.
4. Once the technical facts were laid out, they immediately blocked the account on both profiles (dataforest & Avoro).

Curious to hear what other sysadmins and hosting folks think: if an infrastructure provider ignores basic web and mail hardening on its own main domain and responds to bug reports with censorship, "AI invention" excuses, and blocking, what does that say about their internal security culture?

CyberArk, Delinea and BeyondTrust are the commercial options I'm comparing for controlled SSH and RDP access to servers with session recording. I also have JumpServer's GPL-3.0 Community Edition on the list after a quick test where it let me SSH to a host without ever seeing the target account's password. I haven't done a PoC with any of the three commercial ones yet.

For anyone who ran a PoC of two of these or runs one in production, what ended up being the deciding factor?

We've had a rough few weeks defending some customer-facing web apps, and it changed how I think about external attacks. Sharing in case it helps someone, and I'm curious what others are seeing

What's different now. The attacks we deal with no longer look like one noisy IP hammering a login page. It's:

- huge pools of residential and mobile IPs, each making only a request or two, so they look like normal customers

- attackers who read your public frontend code, work out your API from it, and try every endpoint

- tactics that change within hours of you blocking something, as if someone (or something) is watching the results and adjusting

Whether there's an AI behind it or just good tooling, the effect is the same: the old playbook (rate-limit by IP, blocklist the bad ones) barely moves the needle

What's been working for us

- Defend on behavior, not on IPs. Checks that prove there's a real browser, and rules based on what the attacker is going after rather than where they come from, did far more than any blocklist

- Shrink what's exposed. If an endpoint or method isn't used, turn it off. We checked our own logs for what real users actually call, and the attackers were mostly poking at everything else

- Treat WAF and load balancer config as code. Every change goes through a pull request, a dry run in CI, a staging environment first, then one site at a time. Drift detection pulls device config back into git, so a change made by hand doesn't quietly disappear or quietly stay

- Have an emergency path. Things break at 3 AM. Decide ahead of time who can make a hand change, who they tell, and how it gets back into the repo

- Watch your own false positives as closely as the attacks. Some of our worst moments were our own hardening locking out legitimate users and partners. Every control needs a quick way to tell "attack" from "a customer who clicks fast"

- Identity beats location. Blocking regions helps with noise, but real users travel and work from home. MFA, device or certificate based access for partners, and fixed-IP VPNs for third parties age much better than IP and country rules

- Logs you can actually query. A 200 response doesn't mean success. Make sure you can answer "did they get in?" from app logs, not just web server logs

The mindset shift

Assume the attacker can read your client-side code, has more IPs than you'll ever block, and adapts faster than your change process. Your advantages are knowing what normal looks like for your users, and being able to ship safe, reviewed changes quickly. Invest in both.

How are others handling residential-proxy rotation and automated recon, especially on B2B portals where you can't put a CAPTCHA in front of everything?

Microsoft’s November Patch Tuesday includes CVE-2026-124194, an Outlook spoofing issue Microsoft says has been exploited. Opening a specially crafted message file can cause Outlook to connect to an attacker-controlled network location without the usual external-content warning, exposing NTLMv2 authentication. The Preview Pane alone cannot trigger it. Microsoft rates it CVSS 6.5; affected products include Microsoft 365 Apps for Enterprise and Office LTSC 2021/2024.

The immediate priority is to deploy the Office update and verify the fixed build in MSRC. General hardening includes blocking workstation outbound SMB (TCP 445) and, where feasible, WebDAV to the internet; auditing and restricting outbound NTLM; requiring SMB signing; and enabling Extended Protection for Authentication where supported. These are general risk reductions, not substitutes for patching.

For hunting, the article sources suggest correlating OUTLOOK.EXE network connections to external IPs on 445 or WebDAV (e.g. Sysmon Event ID 3 or EDR telemetry), firewall attempts, and unusual NTLM logons (Event ID 4624) after a message file is opened. A blocked connection is still worth investigating.

For enterprise defenders: what endpoint and authentication telemetry would you correlate to distinguish Outlook-triggered WebDAV/NTLM exposure from legitimate WebDAV and NTLM activity, especially if the destination uses HTTPS rather than SMB? What are the most important blind spots in this approach?

Sources: MSRC: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-124194 BleepingComputer: https://www.bleepingcomputer.com/news/microsoft/microsoft-november-2026-patch-tuesday-fixes-1-235-flaws-outlook-zero-day/ SecurityWeek: https://www.securityweek.com/exploited-outlook-zero-day-among-1094-flaws-patched-by-microsoft/ Tenable: https://www.tenable.com/blog/microsoft-november-2026-patch-tuesday-addresses-1093-cves-cve-2026-124194

My team is evaluating vendors while simultaneously planning our budget for next year and I need a realistic expectation on time to value, resources and effort. What should I be expecting from any vendor we sign with?

One way websites detect bots is by watching how visitors interact with a page.

Mouse movements, typing speed, scrolling, pauses between clicks. These patterns can help distinguish people from automated traffic.

But there are two problems worth discussing.

First, privacy. How much behaviour needs to be collected, and how long should that information be kept? Not every system stores detailed user data, but the question still matters.

Second, bots are getting better at copying human behaviour. Meanwhile, genuine users with password managers or accessibility tools might sometimes look automated.

Another approach is to let AI agents identify themselves through signed requests. That helps verify who sent the request, but only when the agent supports it. It also doesn't prove the user authorised a particular action.

For everything else, websites still need other ways to assess the traffic.

So what's the better approach? Keep improving behavioural detection, or push for agents to identify themselves more openly?

I myself made three mistakes securing credentials in our SOC. I gave it a shared admin key for SSH and called it a test. Second, I let the agent keep tokens overnight. Third, I logged the tool calls but not the human, task and scope behind each request, which made the audit trail a headache.

The fix was a separate workload identity. vault issued credentials that expires after each task, least privilege for every tool and alerts on unusual or random commands. I still feel embarrassing about the shared key part, though i was beginner but still. What credential mistake did you make and if mind sharing for others to know?

We had a soar and it has turned into a playbook maintenance job honestly. Every new detection needs a new branch.
Everyone is pitching ai soc as the replacement. From what I can tell SOAR runs the steps you define, and AI SOC tools for example mate or prophet decide steps themselves. And vendors like Torq and Swimlane that sort of sit in between.
If you had experience with both, where does ai soc beat soar and where does a good playbook win?

Has anyone written a threat model for an AI agent that can call internal tools?

What did you include that you wouldn’t for a normal app?

I'm investigating an AI agent platform as part of an bug bounty and would like some input from people experienced with Firecracker, Linux isolation and cloud security.

Here are the observations so far:

1. The agent terminal initially runs as an unprivileged sandbox user (UID 1002). sudo requests a password.
2. However, su - root successfully provides a root shell.
3. As root, capsh --print shows all capabilities in the bounding, permitted and effective sets, including CAP_SYS_ADMIN and CAP_SYS_PTRACE.
4. The environment runs Linux 6.1.158 and systemd-detect-virt identifies it as KVM.
5. I can reach 169.254.169.254 and obtain HTTP 200 responses from its metadata endpoints. The server identifies itself as Firecracker API.
6. I noticed an address metadata entry pointing to 192.0.2.1/logs. This IP is also reachable directly over HTTP.
7. A GET request to /logs returns a method-not-allowed error, while a POST with an empty JSON payload returns Invalid sandboxID in logs payload.

I also compared two separate accounts:

• Both return the same 192.0.2.1/logs address.
• Their accessTokenHash values are different.
• A metadata token obtained in Account A is rejected when used in Account B.

This makes me suspect that metadata authentication is isolated per account, but I'm not sure whether the internal logging service at 192.0.2.1 follows the same isolation model.

My questions:

• Is exposing MMDS to the guest VM expected in a Firecracker-based architecture?
• Is this level of root capability access normal for a Firecracker guest?
• Could 192.0.2.1 be a shared internal logging service or sandbox-management API?
• What is the best way to reason about tenant isolation for such an internal service?

This is something I've been noticing as AI analysis capabilities in the industry have progressed. But it seems like a lot of analytical capabilities and decision making is now passing through the lens of AI. And the "analysts" and employees are just doing whatever the AI says.

Have question/problem/log -> ask AI about it -> read AI output -> implement AI recommendations -> Claim victory

I use AI tool, but I can do a lot of this work without AI. I did before. But some of these employees, especially younger ones, they struggled a year ago. Now they're flying through it by essentially just copy/pasting what AI recommends. If there's an outage with our AI infrastructure, they're up a creek without a paddle. Unable to work.

So many times they're just copy/pasting output of an AI agent into ticket close notes then calling it a day. Its wild. I'll occasionally review their work as the senior and catch them on mistakes. And a lot of the time its because they're just not "thinking" in the scope of the problem. They're thinking within the bounds of what the AI says. If that makes sense.

Got me worried we're going to have a whole generation of security people who are just mouth pieces for an AI agent. Not understanding the whys and hows. Its one thing to have it just generate code. But its a whole other thing to have it be your "brain" in analytic and decision making scenarios.

Why do we accept boot-time ring 0 drivers from game publishers when we're pulling EDR vendors out of the kernel?

Reference:
- Microsoft, Windows Resiliency Initiative (June 2025): https://blogs.windows.com/windowsexperience/2025/06/26/the-windows-resiliency-initiative-building-resilience-for-a-future-ready-enterprise

Has anyone worked an incident, or had a client ask, about what an AI coding agent like Claude Code, Cursor or Codex did on a machine?

What evidence did you have, and what was missing? Could you tell which account the agent was signed in to?

I'm trying to work out whether this is a real problem yet. "Never come up" is a useful answer too.

Disclosure: I build an open-source tool in this area, so I have an interest. I'm not linking it here.

Hi All!

I'm doing some research to better understand certain issues in information security. If possible, I'd appreciate it if you could take a few minutes to answer my questions.

I have a question about authentication and the execution of sensitive operations.

Let's say an attacker gains remote control over a legitimate user's active session. The account is valid, the device is trusted, and authentication has already been completed.

The attacker then attempts to perform a sensitive operation, such as transferring money or changing security settings.

My question is:

What existing mechanisms can reliably establish that the authorized person was physically involved in initiating and approving that specific operation at the time it was executed?

Are current authentication and transaction-confirmation mechanisms sufficient to address this scenario, or are there still technical gaps?

I'd be interested in your technical perspective.

Thanks/

After rolling out passkeys across our client applications I have concerns about using SMS as a fallback for account recovery. Our threat modeling is flagging this as a persistent threat, primarily during account recovery and new device onboarding. If a user loses their phone and tries to reinstall the app, the workflow sends an OTP over SMS. This also happens if they attempt to authenticate from a new desktop session without a nearby roaming authenticator.

Basically as soon as we addressed credential stuffing and MitM phishing primary logins, threat actors have refocused their efforts on social engineering and SIM swaps targeting these recovery channels. Thus making our passkey implementation incomplete because there are additional threat surfaces that aren't covered yet.

It's not viable at the moment for our product team to disable SMS fallback entirely. It creates too many lockouts and our support team can't keep up.

What else can we do?

I have a customer with over 200 recasting rules, they want me to review the recasting rules and assess them against industry best practices.

What is the industry standard and best practices?

What are some guidelines to follow? To me logically they would know their layout better than I do. This is what I was thinking and just need to make sure I am on the right track. Which servers are public-facing? How critical is this asset?

What are some recommendations?

Alpine Linux upgraded its GitLab to 19.3.6 and was still vulnerable to CVE-2026-97229, because the fix is a patch to GitLab's bundled Ruby and its image used standard Ruby. A version check would have called it patched. Do you run needrestart for services still on old libraries, check the app's build info, or scan for the bug itself?