New: Attic MDR with IVON
Attic MDR is now available as a Sentinel add-on. Incoming Sentinel and Defender alerts pass through a triage pipeline that classifies them, and IVON, our agentic investigation layer, writes the analysis that ends up in your ticket. Every outcome of the pipeline is a check, so findings arrive in the portal alongside your configuration checks and detection rules.
- Layer 1 classifies alerts, layer 2 puts everything without a safe automatic answer in front of an analyst, and every outcome has its own check with an explanation for the customer.
- The MDR consent step in onboarding activates IVON for a tenant. The step is optional and does not block the scheduling of checks.
- Operators steer the pipeline through configurations: LLM provider and consent, Defender licence level, writeback, investigation budget and lifecycle status.
If you switch IVON on for a tenant, the old Sentinel alert processing for that tenant is switched off automatically. IVON takes over those alerts, so an alert is not processed twice.
New: Reporting and usage in the portal
Until now, reports could only be requested from IVON. They are now in the portal itself, both in the renewed partner portal and in the customer portal. You open a report in the browser or download it as a PDF, and you no longer have to forward anything for it.
Every report is attached to the incident it comes from. From an incident you reach the matching report and the other way round, so that when a customer asks a question you do not have to work out which report belonged to which incident.
The dashboard also shows per tenant how much incident handling has been used from the contracted capacity. You therefore see where usage is building up as you go, instead of only afterwards.
If you want to process the reports in your own tooling, you can do so through two new APIs for the IVON integration: one for reports and one for Sentinel.
Changed: app-based onboarding is the default
For a new onboarding, app-based is now set as the default. Onboarding through your GDAP relationship remains available as a choice. Nothing changes for existing tenants.
New: Automated remediations from alerts
Detection rules can now propose a containment action on the alert itself. Six new remediations join the existing account and mail rule actions, for revoking sessions, isolating endpoints and cleaning up persistence.
Added
- CHK-3000: MDR Capability Discovery
- CHK-3020: MDR L2 Analysis, High Severity, No Auto-Remediation
- CHK-3021: MDR L2 Analysis, Cross-Service Correlation
- CHK-3022: MDR L2 Analysis, Unknown Pattern
- CHK-3023: MDR L2 Analysis, Medium Severity, No Auto-Remediation
- CHK-3024: MDR L2 Analysis, Low Severity, No Auto-Remediation
- CHK-3026: Mimikatz Detected
- CHK-3027: BloodHound Detected
- CHK-3028: Impacket Detected
- CHK-3029: Webshell Detected
- CHK-3030: Ransomware Family Detected
- CHK-3031: Hacktool Detected
- CHK-3032: Potentially Unwanted Application Detected
- CHK-3033: Commodity Malware Detected, split off from ransomware so that droppers and stealers are no longer reported as ransomware
- CHK-3034: Entra ID Protection Risk Detection, read directly from Graph now that Defender XDR no longer forwards risk detections at Medium and Low level
- CHK-3035: MDR Finding, safety net for findings without a check of their own
- RULE-1166: Automated device code sign-in, device code sign-ins that are completed by a script instead of by a browser
- RULE-1167: Device registered after device code sign-in, the usual persistence step after a phished token
- FIX-1156: Enable Report Suspicious Activity, automated fix through Graph alongside the manual instructions
- FIX-9003: Reset password and revoke sessions
- FIX-9005: Revoke sign-in sessions
- FIX-9006: Run Defender antivirus scan
- FIX-9007: Isolate Defender machine
- FIX-9008: Remove authentication method
- FIX-9009: Disable device
Improved
- CHK-1003: Mailbox auditing settings correct and FIX-1003 now follow the updated CIS benchmark and require MailItemsAccessed and Send, the actions that record what an attacker read during a mailbox compromise. Tickets are considerably shorter and no longer grow along with the size of the tenant
- CHK-1328: MFA enabled for admins recognises custom authentication strengths
- CHK-1921: MFA for all users forced by conditional access policies recognises custom authentication strengths
- CHK-1137: Admin without MFA puts emergency access accounts on the whitelist
- CHK-1189: Admins excluded from MFA CA policies excludes our own emergency access account
- CHK-1186: MFA Registration Overview recognises the QR code PIN authentication method
- CHK-1147: Password Protection enabled and FIX-1147 have a settings-only mode that checks the configuration without changing the list of banned passwords
- CHK-1049: Outbound spam filter forwarding policy enabled shows the actual policy data instead of a generic text
- CHK-1420: Protection Alert Notifications and FIX-1420 have been made more robust, with a limit of five changes per run and a notification when that limit is reached
- RULE-1164: Device code flow sign in on Tier0 account respects the whitelist for device code applications, so an approved application on an administrator account can be silenced without switching the rule off. The ticket shows exactly which entry you need to add
Fixed
- CHK-1176: RogueAppsDetected raised an incorrect ticket in every tenant after the external rogue apps feed was moved. The URL has been corrected, and a built-in list takes over when the feed is unreachable or unusable, instead of the check reporting a clean result without having scanned anything
- Detection rule panels showed text from an alert that had already been resolved, most clearly with the log stoppage rules, which reported at the same time that there were no problems and that no logs were coming in. Forty rule descriptions now follow the current alert status
- CHK-1003: got stuck on mailboxes that had never been configured, missed audit actions because of a substring comparison, and the fix stopped at the first mailbox that refused a change instead of continuing with the rest of the tenant
- CHK-1049: mailboxes that were on the whitelist under a different alias were not recognised
- RULE-1131, RULE-1140, RULE-1141 and RULE-1142: role assignments were divided incorrectly across the PIM and non-PIM rules, which caused some assignments to be reported twice
- RULE-1162: Owner added to Subscription now reports only owners at subscription level, instead of every role assignment within the subscription
- FIX-9001: mail rule targets are read in more robustly and the verification now reports the actual result
- FIX-1420 ran into a timeout in production because redirect discovery failed on PowerShell 7 and all traffic went to an endpoint that hangs