Backups answer "can we restore?" They do not answer "should we restore now?"

In a large environment, the difficult part is deciding whether the initial access path is closed, privileged identities have been contained, recovery infrastructure is trustworthy, and restored systems will not immediately reconnect to affected dependencies.

You never get perfect certainty. At some point, the business has to choose between more downtime and a higher chance of restoring into an unsafe state.

What evidence do you require before reconnecting a restored system to production?

Started with a phishing report. A user clicked through a consent prompt for a "PDF converter" and granted it Mail.Read. We revoked it, fine, and then I made the mistake of looking at the rest.

Dumped every delegated grant with Graph PowerShell and filtered for Mail. 61 apps. Some obvious ones like the CRM integration and the e-signature tool. Then a scheduling app nobody admits to using, two AI note takers, an email tracker from a vendor that apparently went under in 2023, and a bunch of publisher names I couldnt place.

User consent was never actually off. Someone switched on the admin consent workflow about 18 months ago and everyone assumed that closed it. It does not, its a separate setting. So everything is just there. No owner, no ticket, no record of why.

And the grants dont expire on their own. Anything still holding a refresh token could be reading mail right now and I'd only know by going app by app through the sign-in logs.

Security also has axonius connected to entra, and the same 61 show up there with the users who consented to each, so at least the two lists agree. neither one tells me which apps matter.

Plan for this week is boring. Export the list, sort by permission, email every user who consented and ask if they still use it. Anything without an answer by friday gets disabled.

been looking into Sygnia and Kroll for incident response but haven't found much feedback from people who have actually worked with them.

mostly curious about response times how they handle incidents and whether they are worth the cost

anyone here used Sygnia? would appreciate anyy feedback

A threat intelligence researcher (@TheM3gatr0n) found an active, custom-built attack platform called Cairn on a Hong Kong-registered VPS. It is not a simple script or toolkit — it is a full autonomous orchestration system driven by an LLM (DeepSeek v4.1-flash).
The operator supplies a target and a goal (e.g., obtain a webshell or RCE). The AI then handles the rest: it spins up a dedicated Kali Linux Docker container per victim, reviews a fact-graph of prior attempts, selects the next action, executes it, records the outcome, and continues across sessions with almost no human involvement.
Over roughly 13 days it logged ~230,000 AI-dispatched events and ~18,000 active exploitation attempts against 85+ targets. It heavily focused on Magento/e-commerce systems and demonstrated adaptive behavior by tracking failures and writing structured summaries of what worked or was blocked. Access to the model was maintained via a subscription rotation service.
This is one of the clearer public examples of an LLM being used for real, ongoing autonomous offensive operations rather than one-off experiments.

https://x.com/them3gatr0n/status/2110406318976848132?s=46&t=oXrX4_YhCRl53cYhwA-HsA

i went into the red team run expecting the response filter to settle this class of issue. i didn’t think following the shared retrieval cache path would change the conclusion once the final answer was suppressed. 20000 test prompts later, that confidence is gone. we found 25 collisions because the cache key used document ID and query hash but left out workspace ID. requests from different workspaces resolved to the same entry, tenant isolation had already failed at lookup time. thin comfort.

so the 25 cases looked less alarming in the response report than they did in the retrieval trace. 21 hit a later authorization check before context assembly and stopped there. the other 4 followed a path where foreign document text entered model context before the final response was suppressed. the late check caught most collisions. as an authorization boundary it left too much dependent on call order.

the response level checks marked all 25 as contained because they only graded what left the system. that hid the sequence inside the request. the model had already received foreign document text in 4 cases and a later generation step could use it before suppression. context exposure happened even when the final message stayed empty. the red team dataset made that visible  and I don’t trust response level safety checks alone anymore.

anyway, the 21 blocked cases made the aggregate result look safer than the trace data supported. the 4 exposed cases only showed up  when I followed each cache lookup into the retrieved payload. the next span showed that text inside model input. the authorization span ran later and the final message stayed suppressed. all 4 exposed contexts came from valid cache hits rather than malformed requests

SPF and DKIM authenticate domains, and DMARC checks if the domain in the From address lines up with either one of those. The DMARC standard, RFC 9989, published in May 2026, lists display name attacks as out of scope.

This means a malicious human resources layoff notice from a domain an attacker owns and set up properly passes all three of those existing security measures. In December 2025, Check Point tracked 9,394 phishing emails sent through Google's own Application Integration service that passed them the same way.

**Turn on the External tag in Outlook.** If your own DMARC record says p=none, then mail pretending to be your domain is not being stopped by DMARC. Read your DMARC reports, then raise p= to quarantine, along with sp= and np= if the record has them.

A layoff notice comes from human resources, names your company and announces an organizational restructuring, with a button begging the reader to click for the details. Your user then clicks that button before they look at the sender address. You can't blame them. The urgency is doing the trick.

Not only that, it also passes SPF, DKIM and DMARC, which makes it feel like it should say something about the sender. It does not.

The DMARC standard, RFC 9989, which replaced RFC 7489 in May 2026, says it outright: "Such attacks, known as display name attacks, are out of scope for DMARC." An attacker who registers a domain, publishes SPF, signs with DKIM and sets a DMARC record passes all three of those, and yet the display name can still say HR Department. Nothing is broken. That is, unfortunately, the design. DMARC's job is to stop someone else sending as your exact domain, and it does that job.

Once again, our trust is being abused, and this isn't theoretical. Check Point's December case ran for 14 days against about 3,200 customers, every message sent from [noreply-application-integration@google.com](mailto:noreply-application-integration@google.com) through the Send Email task in Google Cloud's Application Integration. Each one passed SPF, DKIM and DMARC because Google really did send it. Google has said it blocked that abuse. But that isn't the actual solution.

And listen, your own DMARC record matters for the cheaper version of the same lure, the one that puts your real domain in the From line. The DMARC standard defines p=none as the domain owner offering no expression of preference. Microsoft's guidance treats this as the testing stage. Start at p=none and read the aggregate reports, the summaries that participating mail providers send back, usually daily, showing which servers sent mail as your domain and whether it passed. Then move to quarantine, and then reject. The standard tells everyone to start at none. In our experience it gets set during a mail gateway or sender rollout so nothing legitimate is blocked on day one. Too often it gets set and forgotten. EasyDMARC's 2026 count has more than half of the domains with a DMARC record still sitting at none. It needs a second review once the rollout settles.

**Turn on the External tag in Outlook.** In Exchange Online PowerShell, run Set-ExternalInOutlook -Enabled $true. Microsoft notes that if a mail flow rule already adds external text to subject lines, you should disable that rule first to avoid tagging twice. It blocks nothing. But an HR notice carrying an External label is a lot easier for your user to take note of and question.

**Read your own DMARC record today.** Run nslookup -type=txt _dmarc.yourdomain.com and read the p= value, plus sp= and np= if the record has them. Without sp= or np=, p= also covers any subdomain that has no DMARC record of its own. If any of them says none, go through the aggregate reports until every service that legitimately sends as you is passing, then move each one to quarantine and later reject. Skipping the reports is how you quarantine your own payroll provider.

**Hand your staff a single rule.** If an HR email asks you to sign in, close it and open your HR portal yourself.

**Passing DMARC proves the domain, but nothing more. Tag external mail and get your own domain off p=none. It is worth the time.**

Edit: the record check now covers sp= and np=, and the p=none section carries its source. Thanks to the commenter who flagged it.

The most motivated attackers of age verification aren't fraud rings but 14-year-olds who want to get into something and have to through the age check. Examples:

1) "Enter your date of birth" / "I am over 18" button
It is called self-declaration. Regulators have started saying this in writing: Ireland's media regulator called self-declaration alone inadequate when it opened its investigation into X this month.

2) Upload an ID
That can be easily beaten by borrowing a parent's ID, or buying a generated one. There are sites that sell a matching AI-generated face, document and "liveness" video for a few dollars. And if you're a US platform, how many Papua New Guinea passports do your reviewers see in a year?

3) Face age estimation on camera
Early on, teens discovered that drawing a moustache with a marker (!!!) was enough to be read as an adult. Now there are real-time face filters that add a few years which is all you need. On the other end, adults on GLP-1s with good skincare look a decade younger than they are, so the error goes both ways.

My take is that each method checks something that is cheap to fake or borrow (a claim, a document, an appearance). The next generation of age checks will have to measure something that's physically attached to the person and hard to perform.

The obvious candidate is sitting right there and almost nobody analyses it: the voice. A 14-year-old can draw a moustache, but they can't lengthen their vocal tract. Voice changer apps shift pitch, which is the thing a human listener notices. A machine looking at the waveform reads the instrument, not the note. And "record dad saying something" runs into challenge-response: you have to say random words you didn't know in advance, and pre-recorded audio looks very different from live sound in a room.

Happy to discuss it!

Keeping Windows devices updated is one of the basic steps in protecting a business from security risks. But when an organization manages many computers, installing and tracking updates can become difficult.

Here is a simple approach to Windows patch management.

1. Check which devices need updates

Start by checking which Windows devices are missing security updates. Include laptops, desktops, and other managed endpoints.

2. Prioritize security patches

Not every update has the same level of risk. Focus first on critical security issues and vulnerabilities that could affect your environment.

3. Test before deploying

Test updates on a small group of devices before rolling them out to everyone. This can help identify problems with applications or system settings.

4. Automate patch deployment

Automating updates can reduce manual work. It also helps ensure that devices receive patches on schedule.

5. Monitor patch status

Check which devices updated successfully and which failed or are still waiting for updates. Keep a process for following up on devices that remain unpatched.

6. Don't forget third-party apps

Windows updates are only part of the process. Browsers, PDF readers, and other business applications also need regular security updates.

Final thoughts

Good Windows patch management is about more than installing updates. It requires a clear process for finding missing patches, deploying updates safely, and checking that devices are protected.

A pattern that shows up in routine reviews of cloud roles: every single permission looks reasonable on its own, which is exactly why the chain can sit there unnoticed.

A typical one: a low-privilege account that can assume a service account nobody has looked at in months. That service account can assume a role created for a migration, and that role can read a data store full of customer information. So the whole path runs three hops from somewhere low to somewhere that really matters.

The uncomfortable part is that breaking it isn't obvious, because you can cut any of the three hops and the others still look fine. This is where attack-path tools like Orca make sense: it maps chains like this across the cloud estate and shows which hop actually exposes the sensitive data, so you're not guessing which one to cut first.

Security sees the risk. Engineering owns the fix.

we're a 9 person msp, about 40 clients, mostly 20 to 150 seat businesses. dental offices, a couple law firms, a manufacturer, some nonprofits. our tier 1 queue has been eating my two L1 guys alive for a year and i couldnt justify a third hire

last year we tried one of those AI helpdesk add ons that plugs into your PSA. it was fine at sorting tickets and suggesting fixes but my guys still had to go do every single one, so it didnt really move the needle

we'd also heard about the AI stuff ninjaone and connectwise have been adding and a couple people in our peer group were looking at those. but we've been on atera for RMM for years so when robin came out i figured id try it before looking anywhere else. big plus was the atera agent was already on every machine so there was nothing new to roll out to clients. been running it 60 days now and couldnt find many write ups from people actually running it day to day, so here's ours

setup

most of the time was us deciding what we wanted it to handle on its own vs what needs a human ok. we went client by client over about 2 weeks and ended up with:

workstations: fully autonomous for most stuff

servers: approval required for anything beyond diagnostics

the 2 law firms: approval required on everything for the first month bc their managing partner is paranoid (fair)

what it handled

password resets and lockouts, outlook profile issues, teams cache stuff, printer queues, mapped drive problems, disk space on laptops. the thing that surprised me was how it handles stuff that comes back. one of the dental offices had a laptop that kept running out of space. it figured out the imaging software was dumping temp exports and never cleaning them up, dealt with that, then checked again to make sure the fix held before closing it with notes. our old scripts would have cleared temp files and called it done

what we adjusted

we started with really strict approval rules bc we were nervous, so early on a lot of stuff came to us for an ok that we were totally fine with. loosened them as we got comfortable, pretty easy to change per client

numbers (ours, not theirs)

tier 1 tickets my L1s touch went from roughly 180 a week to about 60

one of my L1s is now doing onboarding projects full time which we were always behind on

clients noticed. the dental office manager emailed to ask what changed bc her stuff "just gets fixed now" not trying to sell anyone, genuinely curious if others running AI technicians are seeing similar stuff or if we got lucky with our client mix. happy to answer questions if anyone's on the fence

We are evaluating two AI governance platforms for about 3k people and demos look almost the same. Both end on a dashboard of AI tools with risk scores. The difference is where the list tools comes from.

One builds the inventory from a registry each department fills in and maps everything to the EU AI Act and ISO 42001. The other finds tools on its own through OAuth grants, SSO logs and email and you approve or block them from there.

We tested the second one on our tenant for two weeks. Our own registry listed 31 AI tools and it found 118, including a meeting notetaker that had calendar access for most of the sales team.

Legal prefers the registry one because it produces the paperwork. Security prefers the discovery one because its lists matches what people are using. The board want an inventory it can rely on before the high-risk rules take effect in DEC next yr.

For those who run an AI governance platform for six months or longer at a company this size, how accurate was your inventory by then? Firsthand experiences welcome, good or bad.

Five years ago third party risk management at our company meant checking that vendors had insurance and weren't on a sanctions list. Now the scope includes cybersecurity posture, USG compliance, labor practices, environmental regulations, data privacy, business continuity planning, and I think someone just added AI governance to the list.

Each new category came with its own set of requirements. Cyber risk has its own framework and questionnaires. ESG compliance requires understanding sustainability standards most of our team has never worked with. Labor practices require assessment methodologies our procurement people aren't trained on. Environmental has its own regulatory landscape and every category seems to require a different tool, different expertise, and different assessment cadence. Risk categories keep multiplying, the team doesn't grow and can't go deep on all of them but leadership wants everything covered

Their main worry is agents being talked into "authorized-looking" actions. The framing that stood out: the main risk isn't the model making a mistake; it's an attacker instructing the agent to do something that looks authorized. Their approach is defense in depth: monitoring, auditing, guardrails, and a kill switch to shut down a misbehaving model.

Also in the piece: TII's CEO says an agent you can't monitor in real time "is malware that got access to your machine," and that non-human agents need clear identities. Kaspersky describes "living off local agents," where attackers use an agent already on the machine to find valuable data.

Source: www.khaleejtimes.com/business/tech/ai-agents-tricked-accessing-sensitive-government-data-cybersecurity

For those running agents in production: do your agents have their own identities and least-privilege scopes, or do they inherit a user's or service account's permissions? And who owns the kill switch?