Microsoft has announced significant restrictions on email sending capabilities for organizations using default onmicrosoft.com domains, implementing a throttling system that limits external email delivery to 100 recipients per organization every 24 hours. 

The policy change, announced through the Exchange Team Blog, aims to prevent spam abuse while encouraging organizations to migrate to custom domains for improved email deliverability and brand representation.

Key Takeaways
1. Microsoft limits onmicrosoft.com domains to 100 external emails daily.
2. Targets cybercriminals exploiting new tenants, protecting shared domain reputation.
3. Organizations must purchase custom domains, rollout phases through June 2026.

Email Throttling Imposed

Microsoft’s new policy specifically targets MOERA (Microsoft Online Email Routing Address) domains, which are automatically assigned when organizations create new Microsoft 365 tenants. 

These default domains, such as contoso.onmicrosoft.com, have become attractive targets for cybercriminals who exploit newly created tenants to send spam bursts before detection systems can intervene.

The throttling mechanism will trigger NDR (Non-Delivery Report) messages with error code 550 5.7.236 when organizations exceed the 100 external recipient limit within the rolling 24-hour window. 

Internal messaging remains unaffected, and the restriction applies only to external recipients after any distribution list expansions are calculated. 

This technical implementation ensures that legitimate testing and internal communications continue uninterrupted while preventing large-scale spam operations.

The shared reputation model of onmicrosoft domains has created significant deliverability challenges for legitimate users. 

Because all organizations share variations of the same domain namespace, malicious activity from one tenant can negatively impact email deliverability for all other users on the platform.

Phased Rollout Timeline 

Microsoft has established a structured rollout schedule beginning with trial tenants on October 15, 2025, and progressing through different organization sizes based on Exchange seat counts. 

The implementation will conclude with tenants having over 10,001 seats by June 1, 2026. Organizations with fewer than three seats will face restrictions starting December 1, 2025, followed by progressively larger organizations through the first half of 2026.

Technical migration involves several critical steps including purchasing custom domains through authorized registrars, configuring DNS validation, and updating primary SMTP addresses on all mailboxes. 

Organizations must also address specific scenarios where MOERA domains might be inadvertently used, including Sender Rewriting Scheme (SRS) configurations, Microsoft Bookings notifications, and various Microsoft 365 service integrations.

Administrators can analyze current MOERA email traffic using the Message Trace feature in Exchange Admin Center with wildcard sender addresses to identify potential impacts before the restrictions take effect. 

Organizations are strongly advised to begin migration planning immediately, as the throttling limits will significantly impact any business operations currently dependent on MOERA domains for external communications.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.

The post Microsoft to Limit Onmicrosoft Domain Usage for Sending Emails appeared first on Cyber Security News.

A method to silently exfiltrate Windows secrets and credentials, evading detection from most Endpoint Detection and Response (EDR) solutions.

This technique allows attackers who have gained an initial foothold on a Windows machine to harvest credentials for lateral movement across a network without triggering common security alerts.

How Windows Manages Secrets

The Local Security Authority (LSA), running within the lsass.exe process, is the core Windows component responsible for managing sensitive information. The LSA uses two in-memory databases that correspond to on-disk registry hives:

• SAM database: Manages user, group, and alias objects and corresponds to the SAM registry hive. It stores user credentials, but there is no direct API to retrieve them in plaintext.
• Security database: Manages policy, trusted-domain, account, and secret objects, corresponding to the SECURITY registry hive. This database holds LSA secrets, such as cached domain credentials and machine keys.

While these databases can be managed through RPC interfaces (MS-SAMR and MS-LSAD), they do not offer a simple way to decrypt stored secrets. To access the credentials and secrets, direct interaction with the SAM and SECURITY registry hives is necessary.

These hives are protected by Discretionary Access Control Lists (DACLs) that restrict access to accounts with SYSTEM privileges. The sensitive data within them, such as user credentials and machine keys, is encrypted.

Decrypting this information requires additional values from the SYSTEM hive to reconstruct the decryption key.

Attackers commonly use various local and remote techniques to harvest credentials, but modern security tools detect most well-known methods.

Interacting with the lsass.exe process memory, for example, is a high-risk activity that is heavily monitored by EDRs and Windows Defender, often resulting in immediate alerts.

EDR solutions primarily rely on kernel-mode callback routines to monitor system activity. By using functions like CmRegisterCallbackEx, an EDR’s driver can register to be notified by the Windows kernel of specific events, such as registry access.

When a process attempts to read a sensitive key, like HKLM\SAM or HKLM\SECURITY, the kernel notifies the EDR, which can then block the operation or raise an alert. To manage performance, EDRs typically monitor a select list of high-risk API calls and registry paths, rather than every single system operation.

A New Method for Silent Exfiltration

According to researcher Sud0Ru, who uncovered this technique, a new, two-pronged approach allows attackers to bypass these defenses by leveraging lesser-known Windows internals.

This method avoids creating on-disk backups of registry hives and does not require SYSTEM-level privileges, operating within the context of a local administrator.

1. Bypassing Access Controls with NtOpenKeyEx: The first step involves using the undocumented native API NtOpenKeyEx. By calling this function with the REG_OPTION_BACKUP_RESTORE flag and enabling the SeBackupPrivilege (available to administrators), an attacker can bypass the standard ACL checks on protected registry keys. This provides direct read access to the SAM and SECURITY hives without needing to be the SYSTEM user.
2. Evading Detection with RegQueryMultipleValuesW: Once access is gained, the next challenge is to read the data without triggering EDR alerts. Most EDRs monitor common API calls used for reading registry values, such as RegQueryValueExW. This new technique instead uses RegQueryMultipleValuesW, an API that retrieves data for a list of value names associated with a registry key. Because this function is used less frequently, many EDR vendors have not included it in their monitoring rules. By using this API to read a single value at a time, attackers can extract the encrypted secrets from the SAM and SECURITY hives without being detected.

This combined strategy allows the entire operation to occur in memory, leaving no on-disk artifacts and avoiding API calls that would typically flag malicious activity.

The result is a silent and effective method for harvesting credentials. While decrypting the exfiltrated data is a separate process, this collection technique demonstrates that even mature defensive systems can be circumvented by leveraging overlooked, legitimate functionalities within the operating system itself.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.

The post Hackers Can Exfiltrate Windows Secrets and Credentials Silently by Evading EDR Detection appeared first on Cyber Security News.