Archive

Archive for the ‘Exchange Server’ Category

Defending Exchange servers under attack

June 24th, 2020 No comments

Securing Exchange servers is one of the most important things defenders can do to limit organizational exposure to attacks. Any threat or vulnerability impacting Exchange servers should be treated with the highest priority because these servers contain critical business data, as well as highly privileged accounts that attackers attempt to compromise to gain admin rights to the server and, consequently, complete control of the network.

If compromised, Exchange servers provide a unique environment that could allow attackers to perform various tasks using the same built-in tools or scripts that admins use for maintenance. This is exacerbated by the fact that Exchange servers have traditionally lacked antivirus solutions, network protection, the latest security updates, and proper security configuration, often intentionally, due to the misguided notion that these protections interfere with normal Exchange functions. Attackers know this, and they leverage this knowledge to gain a stable foothold on a target organization.

There are two primary ways in which Exchange servers are compromised. The first and more common scenario is attackers launching social engineering or drive-by download attacks targeting endpoints, where they steal credentials and move laterally to other endpoints in a progressive dump-escalate-move method until they gain access to an Exchange server.

The second scenario is where attackers exploit a remote code execution vulnerability affecting the underlying Internet Information Service (IIS) component of a target Exchange server. This is an attacker’s dream: directly landing on a server and, if the server has misconfigured access levels, gain system privileges.

The first scenario is more common, but we’re seeing a rise in attacks of the second variety; specifically, attacks that exploit Exchange vulnerabilities like CVE-2020-0688. The security update that fixes this vulnerability has been available for several months, but, notably, to this day, attackers find vulnerable servers to target.

In many cases, after attackers gain access to an Exchange server, what follows is the deployment of web shell into one of the many web accessible paths on the server. As we discussed in a previous blog, web shells allow attackers to steal data or perform malicious actions for further compromise.

Behavior-based detection and blocking of malicious activities on Exchange servers

Adversaries like using web shells, which are relatively small pieces of malicious code written in common programming languages, because these can be easily modified to evade traditional file-based protections. A more durable approach to detecting web shell activity involves profiling process activities originating from external-facing Exchange applications.

Behavior-based blocking and containment capabilities in Microsoft Defender ATP, which use engines that specialize in detecting threats by analyzing behavior, surface suspicious and malicious activities on Exchange servers. These detection engines are powered by cloud-based machine learning classifiers that are trained by expert-driven profiling of legitimate vs. suspicious activities in Exchange servers.

In April, multiple Exchange-specific behavior-based detections picked up unusual activity. The telemetry showed attackers operating on on-premises Exchange servers using deployed web shells. Whenever attackers interacted with the web shell, the hijacked application pool ran the command on behalf of the attacker, generating an interesting process chain. Common services, for example Outlook on the web  (formerly known as Outlook Web App or OWA) or Exchange admin center (EAC; formerly known as the  Exchange Control Panel or ECP), executing net.exe, cmd.exe, and other known living-off-the-land binaries (LOLBins) like mshta.exe is very suspicious and should be further investigated.

Figure 1. Behavior-based detections of attacker activity on Exchange servers

In this blog, we’ll share our investigation of the Exchange attacks in early April, covering multiple campaigns occurring at the same time. The data and techniques from this analysis make up an anatomy of Exchange server attacks. Notably, the attacks used multiple fileless techniques, adding another layer of complexity to detecting and resolving these threats, and demonstrating how behavior-based detections are key to protecting organizations.

Figure 2. Anatomy of an Exchange server attack

Initial access: Web shell deployment

Attackers started interacting with target Exchange servers through web shells they had deployed. Any path accessible over the internet is a potential target for web shell deployment, but in these attacks, the most common client access paths were:

  • %ProgramFiles%\Microsoft\Exchange Server\<version>\ClientAccess
  • %ProgramFiles%\Microsoft\Exchange Server\<version>\FrontEnd

The ClientAccess and FrontEnd directories provide various client access services such as Outlook on the web, EAC, and AutoDiscover, to name a few. These IIS virtual directories are automatically configured during server installation and provide authentication and proxy services for internal and external client connections.

These directories should be monitored for any new file creation. While file creation events alone cannot be treated as suspicious, correlating such events with the responsible process results in more reliable signals. Common services like OWA or ECP dropping .aspx or .ashx files in any of the said directories is highly suspicious.

In our investigation, most of these attacks used the China Chopper web shell. The attackers tried to blend the web shell script file with other .aspx files present on the system by using common file names. In many cases, hijacked servers used the ‘echo’ command to write the web shell. In other cases, certutil.exe or powershell.exe were used. Here are some examples of the China Chopper codes that were dropped in these attacks:

We also observed the attackers switching web shells or introducing two or more for various purposes. In one case, the attackers created an .ashx version of a popular, publicly available .aspx web shell, which exposes minimum functionality:

Figure 3. Microsoft Defender ATP alert for web shell

Reconnaissance

After web shell deployment, attackers typically ran an initial set of exploratory commands like whoami, ping, and net user. In most cases, the hijacked application pool services were running with system privileges, giving attackers the highest privilege.

Attackers enumerated all local groups and members on the domain to identify targets. Interestingly, in some campaigns, attackers used open-source user group enumerating tools like lg.exe instead of the built-in net.exe. Attackers also used the EternalBlue exploit and nbtstat scanner to identify vulnerable machines on the network.

Next, the attackers ran built-in Exchange Management Shell cmdlets to gain more information about the exchange environment. Attackers used these cmdlets to perform the following:

  • List all Exchange admin center virtual directories in client access services on all Mailbox servers in the network
  • Get a summary list of all the Exchange servers in the network
  • Get information on mailboxes, such as size and number of items, along with role assignments and permissions.

Figure 4. Microsoft Defender ATP alert showing process tree for anomalous account lookups

Persistence

On misconfigured servers where they have gained the highest privileges, attackers were able to add a new user account on the server. This gave the attackers the ability to access the server without the need to deploy any remote access tools.

The attackers then added the newly created account to high-privilege groups like Administrators, Remote Desktop Users, and Enterprise Admins, practically making the attackers a domain admin with unrestricted access to any users or group in the organization.

Figure 5. Microsoft Defender ATP alert showing process tree for addition of local admin using Net commands

Credential access

Exchange servers contain the most sensitive users and groups in an organization. Gaining credentials to these accounts could virtually give attackers domain admin privileges.

In our investigation, the attackers first dumped user hashes by saving the Security Account Manager (SAM) database from the registry.

Next, the attackers used the ProcDump tool to dump the Local Security Authority Subsystem Service (LSASS) memory. The dumps were later archived and uploaded to a remote location.

In some campaigns, attackers dropped Mimikatz and tried to dump hashes from the server.

Figure 6. Microsoft Defender ATP alert on detection of Mimikatz

In environments where Mimiktaz was blocked, attackers dropped a modified version with hardcoded implementation to avoid detection. Attackers also added a wrapper written in the Go programming language to make the binary more than 5 MB. The binary used the open-source MemoryModule library to load the binary using reflective DLL injection. Thus, the payload never touched the disk and was present only in memory, achieving a fileless persistence.

The attackers also enabled ‘wdigest’ registry settings, which forced the system to use WDigest protocol for authentication, resulting in lsass.exe retaining a copy of the user’s plaintext password in memory. This change allowed the attacker to steal the actual password, not just the hash.

Another example of stealthy execution that attackers implemented was creating a wrapper binary for ProcDump and Mimikatz. When run, the tool dropped and executed the ProcDump binary to dump the LSASS memory. The memory dump was loaded inside the same binary and parsed to extract passwords, another example of reflective DLL injection where the Mimikatz binary was present only in memory.

With attacker-controlled accounts now part of Domain Admins group, the attackers performed a technique called DCSYNC attack, which abuses the Active Directory replication capability to request account information, such as the NTLM hashes of all the users’ passwords in the organization. This technique is extremely stealthy because it can be performed without running a single command on the actual domain controller.

Lateral movement

In these attacks, the attackers used several known methods to move laterally:

  • The attackers heavily abused WMI for executing tools on remote systems.

  • The attackers also used other techniques such as creating service or schedule task on remote systems.

  • In some cases, the attackers simply run commands on remote systems using PsExec.

Exchange Management Shell abuse

The Exchange Management Shell is the PowerShell interface for administrators to manage the Exchange server. As such, it exposes many critical Exchange PowerShell cmdlets to allow admins to perform various maintenance tasks, such as assigning roles and permissions, and migration, including importing and exporting mailboxes. These cmdlets are available only on Exchange servers in the Exchange Management Shell or through remote PowerShell connections to the Exchange server.

To understand suspicious invocation of the Exchange Management Shell, we need to go one step back in the process chain and analyze the responsible process. As mentioned, common application pools MSExchangeOWAAppPool or MSExchangeECPAppPool accessing the shell should be considered suspicious.

In our investigation, attackers leveraged these admin cmdlets to perform critical tasks such as exporting mailboxes or running arbitrary scripts. Attackers used different ways to load and run PowerShell cmdlets through the Exchange Management Shell.

In certain cases, attackers created a PowerShell wrapper around the commands to effectively hide behind legitimate PowerShell activity.

These cmdlets allowed the attackers to perform the following:

  • Search received email

In our investigations, attackers were primarily interested in received emails. They searched for message delivery information filtered by the event ‘Received’. The search time frame showed the attackers were initially interested in the entire log history. Later, a similar command was run with a trimmed timeline of one year.

  • Export mailbox

Attackers exported mailboxes through these four steps:

    1. Granted ApplicationImpersnation role to the attacker-controlled account. This effectively allowed the supplied account to access all mailboxes in the organization.
    2. Granted ‘Mailbox Import Export’ role to the attacker-controlled account. This role is required to be added before attempting mailbox export.
    3. Exported the mailbox with filter “Received -gt ‘01/01/2020 0:00:00’”.
    4. Removed the mailbox export request to avoid raising suspicion.

Tampering with security tools

As part of lateral movement, the attackers attempted to disable Microsoft Defender Antivirus. Attackers also disabled archive scanning to bypass detection of tools and data compressed in .zip files, as well as created exclusion for .dat extension. The attackers tried to disable automatic updates to avoid any detection by new intelligence updates. For Microsoft Defender ATP customers, tamper protection prevents such malicious and unauthorized changes to security settings.

Remote access

The next step for attackers was to create a network architecture using port forwarding tools like plink.exe, a command line connection tool like ssh. Using these tools allowed attackers to bypass network restrictions and remotely access machines through Remote Desktop Protocol (RDP). This is a very stealthy technique: attackers reused dumped credentials to access the machines through encrypted tunneling software, eliminating the need to deploy backdoors, which may have a high chance of getting detected.

Exfiltration

Finally, dumped data was compressed using the utility tool rar.exe. The compressed data mostly comprised of the extracted .pst files, along with memory dumps.

Improving defenses against Exchange server compromise

As these attacks show, Exchange servers are high-value targets. These attacks also tend to be advanced threats with highly evasive, fileless techniques. For example, at every stage in the attack chain above, the attackers abused existing tools (LOLBins) and scripts to accomplish various tasks. Even in cases where non-system binaries were introduced, they were either legitimate and signed, like plink.exe, or just a proxy for the malicious binary, for example, the modified Mimikatz where the actual malicious payload never touched the disk.

Keeping these servers safe from these advanced attacks is of utmost importance. Here are steps that organizations can take to ensure they don’t fall victim to Exchange server compromise.

  1. Apply the latest security updates

Identify and remediate vulnerabilities or misconfigurations in Exchange servers. Deploy the latest security updates, especially for server components like Exchange, as soon as they become available. Specifically, check that the patches for CVE-2020-0688 is in place. Use threat and vulnerability management to audit these servers regularly for vulnerabilities, misconfigurations, and suspicious activity.

  1. Keep antivirus and other protections enabled

It’s critical to protect Exchange servers with antivirus software and other security solutions like firewall protection and MFA. Turn on cloud-delivered protection and automatic sample submission to use artificial intelligence and machine learning to quickly identify and stop new and unknown threats. Use attack surface reduction rules to automatically block behaviors like credential theft and suspicious use of PsExec and WMI. Turn on tamper protection features to prevent attackers from stopping security services.

If you are worried that these security controls will affect performance or disrupt operations, engage with IT pros to help determine the true impact of these settings. Security teams and IT pros should collaborate on applying mitigations and appropriate settings.

  1. Review sensitive roles and groups

Review highly privileged groups like Administrators, Remote Desktop Users, and Enterprise Admins. Attackers add accounts to these groups to gain foothold on a server. Regularly review these groups for suspicious additions or removal. To identify Exchange-specific anomalies, review the list of users in sensitive roles such as mailbox import export and Organization Management using the Get-ManagementRoleAssignment cmdlet in Exchange PowerShell.

  1. Restrict access

Practice the principle of least-privilege and maintain credential hygiene. Avoid the use of domain-wide, admin-level service accounts. Enforce strong randomized, just-in-time local administrator passwords and Enable MFA. Use tools like LAPS.

Place access control list (ACL) restrictions on ECP and other virtual directories in IIS. Don’t expose the ECP directory to the web if it isn’t necessary and to anyone in the company who doesn’t need to access it. Apply similar restrictions to other application pools.

  1. Prioritize alerts

Pay attention to and immediately investigate alerts indicating suspicious activities on Exchange servers. Catching attacks in the exploratory phase, the period in which attackers spend several days exploring the environment after gaining access, is key. Common application pools like ‘MSExchangeOWAAppPool’ or ‘MSExchangeECPAppPool’ are commonly hijacked by attackers through web shell deployment. Prioritize alerts related to processes such as net.exe, cmd.exe, and mshta.exe originating from these pools or w3wp.exe in general.

Behavior-based blocking and containment capabilities in Microsoft Defender Advanced Threat Protection stop many of the malicious activities we described in this blog. Behavior-based blocking and containment stops advanced attacks in their tracks by detecting and halting malicious processes and behaviors.

 

 

Figure 7. Microsoft Defender ATP alerts on blocked behaviors

In addition, Microsoft Defender ATP’s endpoint detection and response (EDR) sensors provide visibility into other suspicious and malicious activities on Exchange servers, which are raised as alerts. The new alert page presents data in an investigation-driven approach meant to empower SecOps teams to easily investigate and take actions.

Figure 8. Microsoft Defender ATP alert and process tree

If these alerts are immediately prioritized, security operations teams can better mitigate attacks and prevent further damage. Beyond resolving these alerts in the shortest possible time, however, organizations should focus on investigating the end-to-end attack chain and trace the vulnerability, misconfiguration, or other weakness in the infrastructure that allowed the attack to occur.

Microsoft Defender ATP is a component of the broader Microsoft Threat Protection (MTP), which provides comprehensive visibility into advanced attacks by combining the capabilities of Office 365 ATP, Azure ATP, Microsoft Cloud App Security, and Microsoft Defender ATP. Through the incidents view, MTP provides a consolidated picture of related attack evidence that shows the complete attack story, empowering SecOps teams to thoroughly investigate attacks.

In addition, MTP’s visibility into malicious artifacts and behavior empowers security operations teams to proactively hunt for threats on Exchange servers. For example, MTP can be connected to Azure Sentinel to enable web shell threat hunting.

Through built-in intelligence and automation, Microsoft Threat Protection coordinates protection, detection, and response across endpoints, identity, data, and apps. Learn more.

 

Hardik Suri

Microsoft Defender ATP Research Team

 

MITRE ATT&CK techniques

Initial access

Execution

Persistence

Privilege escalation

Defense evasion

Credential access

Discovery

Lateral movement

Collection

Command and control

Exfiltration

 

The post Defending Exchange servers under attack appeared first on Microsoft Security.

BRANCHCACHE for Exchange 2010 OAB Download How-To:

BRANCHCACHE for Exchange 2010 OAB Download How-To:

Requirements for BranchCache

Following is a list of operating systems that support BranchCache content server or BranchCache client computer functionality. To successfully deploy BranchCache in a test lab environment, you must use operating systems that support BranchCache.


General Requirements to Server and Client

Server and Clients must be able to communicate to each other. Clients must be in the same Subnet (otherwise Discovery of Cached Content will not work). All Machines must be able to resolvable in DNS or WINS.


Operating systems for BranchCache client computer functionality

To perform the steps in this guide, you must have three physical or virtual client computers that are running one of the following operating systems:

  • Windows® 7 Enterprise
  • Windows® 7 Ultimate

Operating systems for BranchCache content server functionality

To perform the steps in this guide, you must have one physical or virtual server computer to be used as a BranchCache content Web server that is running one of the Windows Server® 2008 R2 family of operating systems, with the following exceptions:

  • In Windows Server® 2008 R2 Enterprise Core Install with Hyper-V, BranchCache is not supported.
  • In Windows Server® 2008 R2 Datacenter Core Install with Hyper-V, BranchCache is not supported.

Necessary Installation and Configuration Steps for Content-Server:

In our Lab Environment the Content Server should deliver the Exchange OAB. In this case the
existing CAS-Server is responsible for the Content we want to get, so the CAS-Server will be our Content-server. As prerequisite for CAS the IIS-Server is in place so we don’t need to change anything at this point.

The first neccassary Step is to install the Branchcache Feature from Roles and Features.

After this is done install the B.I.T.S. feature with IIS Extension Subfeature.

At the Server this should be the needed configuration Steps.

Additionaly to verify the functionality you can use Perfmon to Monitor the Branchcache related traffic information.

 Configure BranchCache performance counters on the content server
 

  1. 1.   On CAS with Branchcache installed, click Start, click Search programs and files, and type perfmon. In Search results, in Programs, click perfmon.exe. Windows Performance Monitor opens.
  2. 2.   In Monitoring Tools click Performance Monitor to view the Performance Monitor graph. To change the performance monitor graph to report view, click the graph toolbar icon that displays an arrow to reveal the drop-down list, and then click Report.
  3. 3.   To add BranchCache counters, click the graph toolbar icon that is a green plus sign (+). The Add Counters dialog box opens. In the left pane, scroll to BranchCache Kernel Mode, and click to expand the list of BranchCache Kernel Mode counters. Click Client Cache Miss Bytes, hold down the Ctrl key, and then click Server Cache Miss Bytes, Hash Bytes, and Projected Server Bytes Without Caching.
  4. 4.   Click Add, and then click OK.

  Perfmon Content-Server with working Branchcache

 

 To reset the Branchcache functionallity and the performance counters on the content server use:

 

        Netsh branchcache reset

 

 After the Branchcache reset the Perfmon Counters are reset as well.

 Client computer configuration: 
 Neccessary Installation and Configuration Steps for Client Computers to enable BranchCache distributed cache mode using network shell commands

 

1.   On the BranchCache client computer that you want to configure, click Start, click Search programs and files, and then type command. In search results, under Programs, right-click Command Prompt, and then click Run as Administrator. The command prompt opens with the elevated privileges that are required to run netsh commands.

2.   Run the following command: netsh branchcache set service mode=DISTRIBUTED

Suggestion:

Running the netsh branchcache set service command both configures the client computer for distributed cache mode and automatically configures the client computer firewall with the following inbound exceptions for distributed cache mode: TCP port 80 and UDP port 3702.

3.   To verify that BranchCache distributed cache mode is correctly configured on the client computer, run the following command: netsh branchcache show status. The BranchCache Service Status is displayed in the command prompt window with the following values: Service Mode: Distributed Caching; Serve peers on battery power: Disabled; and Current Status= Running.

  

To configure BranchCache performance counters on the Client Computers
 

4.   On Client with Branchcache installed, click Start, click Search programs and files, and type perfmon. In Search results, in Programs, click perfmon.exe. Windows Performance Monitor opens.

5.   In Monitoring Tools click Performance Monitor to view the Performance Monitor graph. To change the performance monitor graph to report view, click the graph toolbar icon that displays an arrow to reveal the drop-down list, and then click Report.

6.   To add BranchCache counters, click the graph toolbar icon that is a green plus sign (+). The Add Counters dialog box opens. In the left pane, scroll to BranchCache, and select all underlying counters.

7.   Click Add, and then click OK.

 

  First Windows 7 Client got Data from Server                                                                                              Other Windows 7 Clients got Hashes from Server but Data from Cache of First Client

                                      

 

To reset the Branchcache functionallity and the performance counters on the Client machines use:

 

      netsh branchcache reset

 

and after that

 

       netsh branchcache set service mode=DISTRIBUTED

These are the steps to make OAB Download over Branchcache possible.

Please let us know about how you use email security solutions in your workplace

December 6th, 2010 No comments

Hello everyone,

The Microsoft Forefront team is currently conducting a survey and would like to hear your opinions about email security, especially how you use email security solutions in your organization. We would appreciate it if you would take the time to respond to this survey.  This information will help us improve Forefront Protection for Exchange.

Please consider taking a few minutes at this time to complete the survey. This survey should take about 10 -15 minutes to complete.

 

To participate, please click here.

 

Carolyn Liu
Senior Program Manager, Forefront Server Protection

Please let us know about how you use email security solutions in your workplace

December 6th, 2010 Comments off

Hello everyone,

The Microsoft Forefront team is currently conducting a survey and would like to hear your opinions about email security, especially how you use email security solutions in your organization. We would appreciate it if you would take the time to respond to this survey.  This information will help us improve Forefront Protection for Exchange.

Please consider taking a few minutes at this time to complete the survey. This survey should take about 10 -15 minutes to complete.

 

To participate, please click here.

 

Carolyn Liu
Senior Program Manager, Forefront Server Protection

Please let us know about how you use email security solutions in your workplace

December 6th, 2010 No comments

Hello everyone,

The Microsoft Forefront team is currently conducting a survey and would like to hear your opinions about email security, especially how you use email security solutions in your organization. We would appreciate it if you would take the time to respond to this survey.  This information will help us improve Forefront Protection for Exchange.

Please consider taking a few minutes at this time to complete the survey. This survey should take about 10 -15 minutes to complete.

 

To participate, please click here.

 

Carolyn Liu
Senior Program Manager, Forefront Server Protection

Please let us know about how you use email security solutions in your workplace

December 6th, 2010 No comments

Hello everyone,

The Microsoft Forefront team is currently conducting a survey and would like to hear your opinions about email security, especially how you use email security solutions in your organization. We would appreciate it if you would take the time to respond to this survey.  This information will help us improve Forefront Protection for Exchange.

Please consider taking a few minutes at this time to complete the survey. This survey should take about 10 -15 minutes to complete.

 

To participate, please click here.

 

Carolyn Liu
Senior Program Manager, Forefront Server Protection

How to link existing AD accounts to the correct organization in a Microsoft Exchange Server 2010 SP1 multi-tenant environment

With Microsoft Exchange Server 2010 SP1 there is a built-in multi-tenant support feature available that replaces many features of HMC. A good overview about the features, limitations, installation and configuration is available at Technet article:

Multi-Tenant Support

http://technet.microsoft.com/en-us/library/ff923272.aspx 

The hosting solution available for Exchange 2010 SP1 includes most of the features and functionality available in Exchange 2010 SP1 Enterprise deployments, but also includes features and functionality that will allow you to create and manage tenant organizations. Microsoft Exchange Server 2010 SP1 will form part of the suite of multi-tenant capable products that will replace the Hosted Messaging and Collaboration 4.5 solution. 

The account provisioning rollout of new Accounts and new mailboxes works via the new-mailbox cmd:
============================================================================

New-Mailbox -Database “Mailbox Database name” -Name “name” -LinkedDomainController “DCName” -LinkedMasterAccount domain\name -UserPrincipalName name@domain.com linkedCredential:(Get-Credential domain\Administrator) -Organization “tenant or organization name” 

The new-mailbox procedure only covers the creation of new accounts and new mailboxes by assigning the appropriate tenant for the particular AD Account.

The –Organization switch is responsible to match the correct tenant. In many customer environments, migrating to Exchange 2010, there already exist the AD accounts that need to be linked to a new mailbox in the appropriate tenant.

To match an existing AD account to a new mailbox we need the Enable-mailbox cmd. Unfortunately the Enable-mailbox cmd syntax options do not include the –Organization option.

This way we cannot connect an existing AD account to a new mailbox in the appropriate tenant.

Solution:
=======   

If you want to enable an existing AD user for a mailbox at a specific organization, you can still use Enable-Mailbox cmdlet. There is some extra work to stamp a few attributes correctly in the AD user before running the cmdlet (here as a sample domain name.test.microsoft.com):

===========================================================================

1. msExchCU: CN=Configuration, CN=<tenant name>, CN=ConfigurationUnits,CN=Microsoft Exchange, CN=Services, CN=Configuration, DC=name  DC=test, DC=microsoft, DC=com
2. msExchOURoot: OU=<tenant name>, OU=Microsoft Exchange Hosted Organizations, DC=name  DC=test, DC=microsoft, DC=com
3. userPrincipalName: Usually it is <user name>@<tenant domain name> 

After stamping these attributes the Enable-mailbox cmd automatically links the AD accounts to a mailbox in the appropriate tenant or organization.

Hotfix Rollup 3 for Antigen 9 for Exchange Service Pack 2 is Now Available

August 27th, 2010 No comments

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2!

 

On August 27th 2010 Microsoft shipped Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2.

 

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:
http://support.microsoft.com/kb/2302001

  •  Description of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2: 

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

 

 

Regards,

Robert McCarthy
Microsoft Security

Hotfix Rollup 3 for Antigen 9 for Exchange Service Pack 2 is Now Available

August 27th, 2010 No comments

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2!

 

On August 27th 2010 Microsoft shipped Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2.

 

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:
http://support.microsoft.com/kb/2302001

  •  Description of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2: 

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

 

 

Regards,

Robert McCarthy
Microsoft Security

Hotfix Rollup 3 for Antigen 9 for Exchange Service Pack 2 is Now Available

August 27th, 2010 No comments

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2!

 

On August 27th 2010 Microsoft shipped Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2.

 

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:
http://support.microsoft.com/kb/2302001

  •  Description of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2: 

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

 

 

Regards,

Robert McCarthy
Microsoft Security

Hotfix Rollup 3 for Antigen 9 for Exchange Service Pack 2 is Now Available

August 27th, 2010 Comments off

On behalf of the Forefront Server Security team at Microsoft, I am pleased to announce the release of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2!

 

On August 27th 2010 Microsoft shipped Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2.

 

For a complete list of the new features and fixes included in this rollup along with directions for download, please see the following Knowledge Base article:
http://support.microsoft.com/kb/2302001

  •  Description of Hotfix Rollup 3 for Antigen 9 for Exchange, Service Pack 2: 

As the installer runs, server service restarts may be necessary so please plan accordingly when applying this Hotfix Rollup. 

 

 

Regards,

Robert McCarthy
Microsoft Security

Updates to the Forefront Server Protection documentation in the TechNet library (August 2010)

August 5th, 2010 Comments off

Hi, my name is Scott Floman, and I’m a technical writer in the Forefront Server Protection group. Every few months or so, we update our existing “legacy” documentation on our TechNet Web site, and this post is to make you aware of our recent August 2010 update. (p.s. By “legacy” content I mean products that are already supported in production environments, such as Forefront Protection 2010 for Exchange Server (FPE), Forefront Protection 2010 for SharePoint (FPSP), and our Forefront Server Security Version 10 and Antigen Version 9 products).

 

Some of the topics we added or provided updated information about are:

 

·         FPE capacity planning: http://technet.microsoft.com/en-us/library/ff921060.aspx

·         Supported operating systems and Exchange Server versions: http://technet.microsoft.com/en-us/library/ff921059.aspx

·         Best practices for configuring FPE operations: http://technet.microsoft.com/en-us/library/ff716689.aspx

·         Managing performance and health. We added recommended resolutions for when your health monitors are not green (“healthy”).

·         FPE: http://technet.microsoft.com/en-us/library/ee358897.aspx

·         FPSP: http://technet.microsoft.com/en-us/library/ee358924.aspx

·         Submitting malware to Microsoft for analysis. The documentation was revised because customers are advised to use the Microsoft Malware Protection Center Portal to submit malware for analysis.

·         FPE: http://technet.microsoft.com/en-us/library/dd639384.aspx

·         FPSP: http://technet.microsoft.com/en-us/library/dd639465.aspx

·         Maximizing FPSP scan engine performance: http://technet.microsoft.com/en-us/library/ff729711.aspx

 

These are just some of the updates we made. We also made smaller-scale updates in many areas, for example we updated the Forefront Server Security Management Console (FSSMC) system requirements, the FPSP Performance Monitor topic, and the FPE cluster documentation.

In addition, the Table Of Contents (TOC) on TechNet has recently undergone a reorganization, and we are also continuing to seek out ways to optimize search results so that our customers can more easily find the information that they are looking for. 

Also, our team has been busy in creating videos that we hope you will find useful in learning about our products. Here are some recent FPE videos: 

 

So, that’s that, I just wanted to say a few words about our latest TechNet update, the TechNet TOC reorg, and our increased use of the video format. Please used the feedback feature on TechNet, because we do attempt to address all feedback received.

 

Also, another good resource for information is the Forefront Server Security Forum (http://social.technet.microsoft.com/Forums/en-us/category/forefront) where you can read and answer questions about our products. A passport account is needed to access the Forum.

There are other Microsoft forums, blogs, and online technology sites that might prove useful as well; for more information, read this blog article:

http://blogs.technet.com/fss/archive/2009/03/10/other-blogs-and-content-of-interest-for-fss-users.aspx

 

Finally, I want to call your attention to the TechNet wiki, which you can access at the following URL: http://social.technet.microsoft.com/wiki/

 

This is a new community where Forefront employees and customers can post technical articles and interact with one another, much like how wikipedia works. We’re excited about the possibilities of this wiki, which we feel will be a great resource of information, so please stop by and check it out. I recently posted the following wiki articles which I hope will help customers configure our products in multi-server environments (there are also videos for these topics if you want to see a visual demonstration):

Again, thanks for your time, and feel free to e-mail me with any feedback.


Scott Floman
scfloman@microsoft.com

Manually updating engines and definitions in Forefront Protection 2010 for Exchange Server and SharePoint

July 30th, 2010 Comments off

Hello,

 

We get quite a few calls from administrators who ask if they can manually update their Forefront Protection 2010 for Exchange Server (FPE) and Forefront Protection 2010 for SharePoint scan engines.

 Well, the short answer is yes, but the long answer is a bit longer, so in order to provide guidance to those of you who wish to manually update the FPE/FPSP scan engines and definitions as part of your Forefront Protection defense strategies, Microsoft has provided a comprehensive set of instructions via the following Knowledge Base article:

 http://support.microsoft.com/kb/2292741

 So, whatever your reason for not using automatic updating, you can follow the steps outlined in the KB to manually update Forefront Protection’s scan engines.

 Included in the KB is a sample PowerShell script that you can customize to synch with your specific network parameters and adjust to your environmental needs.

 Regards,

Robert McCarthy

Support Engineer – Microsoft Security

Winmail.dat received with a Lotus Notes Client

When an Exchange based email organization sends out an email to a non Exchange based organization (Lotus Notes or other systems for example web mailers) it could happen, that a non mapi client receives an empty email with a winmail.dat file attachment.

The client is unable to open the winmail.dat file and so the email is useless for him.

The reason for this is, that the Microsoft internal TNEF alias RTF (Rich Text Format) was sent out of the Exchange organization. There are different places and settings which have an influence, which you may need to check:


1. Domain level (Exchange server settings):

 

a) Exchange 2003

 In the ESM (Exchange System Manager) go to, Global Settings, Internet Message Format, select the domain. Default domain is “*” but please configure an extra entry for the external SMTP domain for example dominodomain.com.

If you open the property of the domain and go to advanced, there is a setting “Exchange richt-text format”. You can set it to “Always use”, “Never use” and to “Determined by individual user settings”.

Please set it to never use

 

 

b) For Exchange 2007:

Powershell:

Set-remotedomain domainname tnefenabled $false

In the GUI:

Open the Exchange management console, Organization, Hub Transport, Remote Domains, Domain name:

Please set it to never use.

 

   

2. Recipient level

 

Another place where you can configure RTF is at the recipient level.  

a) AD contact

If you got an active directory based contact you can set it to be a non mapi recipient:

 

 

Please uncheck the „Use Mapi rich text format) box

Note: For an AD contact there is one additional setting which may need to be set:

InternetEncoding: 1310720

See KB 924240 for more details.

KB 924240        The email message attached with winmail.dat when you send a mail from Exchange to Lotus Notes through a SMTP connector

http://support.microsoft.com/default.aspx?scid=kb;EN-US;924240 

b) For Exchange 2007:

Open the Exchange management console, Recipient Configuration, Mail Contact:

 

 

c) The same is true for a personal contact created in Outlook:

 

  

d) Even for a one off addresses this can be set. If you enter the smtp address in the to line for example john.doe@domain.com then do a check names, double click on the email address in the to line,

and you will see the same box as before:

 

 

3) Other important Outlook settings:

 

a) Message Format :

Tools, Options, Mail Format, Message Format (Compose in this message format):

Plain Text, Rich Text, HTML

 

 

b) Internet Format:

Tools, Options, Mail Format, Internet Format, Outlook Rich Text options:

When sending Outlook Rich Text messages to Internet recipients, use this format:

       Convert to Plain Text format

       Convert to HTML format

–    Convert to Rich Text format

 

 

4. Outlook overwriting the Exchange settings:

 

329454 Outlook 2002 message format overrides Exchange server message format

http://support.microsoft.com/default.aspx?scid=kb;EN-US;329454

HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook\Options\Mail DWORD:
DisableInetOverride Value: 1

When the registry key is set to a non-zero number, the message format does not override the Internet Message Format that is specified by Exchange.

The key DisableInetOverride still exists in Outlook 2003, 2007 and 2010.

 

5. NK2 cache

 

If you have Outlook clients where it sometimes work and sometimes not please delete
the name cache files from the outlook clients (delete username.NK2 file(s))

 

6. More to read:

 

821750 How to configure Internet e-mail message formats at the user and the domain levels in Exchange Server 2003

http://support.microsoft.com/default.aspx?scid=kb;EN-US;821750

290809 How e-mail message formats affect Internet e-mail messages in Outlook

http://support.microsoft.com/default.aspx?scid=kb;EN-US;290809

 

Messages sent from Exchange 2007 to Non-Exchange Recipients through an Exchange 2003 Connector are NDRed by the first Hub/Transport Server

In a mixed Exchange 2007/2003 environment with a Connector to a Non-Exchange System on an Exchange 2003 Server you cannot send messages from Exchange 2007 to a recipient in the Non-Exchange System if the following two conditions are true:


1) the Connector contains an Address Space with an underscore (“_”) in it, like in the following example:


  


2) one part of the address of the final recipient (for example, the “Domain”-part) matches this Address Space.


In this case, the sender of the message will receive a Non Delivery Report from the first Exchange 2007 Hub/Transport-Server and the message will not be routed to the recipient.


The Non Delivery Report contains the following error-information:


 #550 5.4.4 ROUTING.NoNextHop; unable to route


This error is returned despite the fact, that the Scope of the Connector is set to “Entire organization” and the Address Space is visible in the Routing Log Viewer in Exchange 2007.


Please note, that this issue can occur in conjunction with all EDK-Gateways for Exchange 2003 and hence is not limited to the Lotus Notes Connector for Exchange 2003.


You can work around the problem by re-defining the Address Space in question so, that the underscore is eliminated from it and replaced by a wildcard. One possible solution for the example above would be, to replace “abcd_ef” by “abcd*”. As soon as this change has been replicated to Exchange 2007, the problem is resolved and messages can be sent from Exchange 2007 to the desired destination.

How to control routing from your own routing agent

With the release of Microsoft Exchange Server 2007 Service Pack 1 you can programmatically override the default routing for message recipients on a per-recipient basis. This can be done by using the SetRoutingOverride method on the recipient for which you want to override the default routing.


Let’s assume that you have an Exchange 2007 server with just one send connector “Internet Connector”” using DNS for the address space *. With this configuration all messages leaving the organization will use this connector. Let’s further assume that you want to route messages from certain senders to a smarthost instead of using DNS. This can be done as follows:


– Create an additional send connector “Smarthost Connector” pointing to the smarthost
– Specify a non-existing domain (e.g. nexthopdomain.com) as address space of the new connector
– Write, install and enable a routing agent which registers for the OnResolvedMessage event and overwrites the default routing for the recipient.


The sample agent of this article shows you how to route messages from administrator@contoso.com over the new connector, the routing for all other sender’s won’t be changed. 


1.) Create a C# project (dll/library type) 


2.) Copy the following DLLs from the C:\Program Files\Microsoft\Exchange Server\Public directory of an Exchange 2007 server to the debug directory of your new C# project:
     a. Microsoft.Exchange.Data.Common.dll
     b. Microsoft.Exchange.Data.Transport.dll


3.) Add references to the two DLLs to the C# project using the Visual Studio solution explorer


4.) Add the following code to your project:


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;


using Microsoft.Exchange.Data.Transport;
using Microsoft.Exchange.Data.Transport.Email;
using Microsoft.Exchange.Data.Transport.Smtp;
using Microsoft.Exchange.Data.Transport.Routing;
using Microsoft.Exchange.Data.Common;



namespace RoutingAgentOverride
{
    public class SampleRoutingAgentFactory : RoutingAgentFactory
    {
        public override RoutingAgent CreateAgent(SmtpServer server)
        {
            RoutingAgent myAgent = new ownRoutingAgent();


            return myAgent;
        }
    }
}
public class ownRoutingAgent : RoutingAgent
{
    public ownRoutingAgent()
    {
        //subscribe to different events
        base.OnResolvedMessage += new ResolvedMessageEventHandler(ownRoutingAgent_OnResolvedMessage);
    }


    void ownRoutingAgent_OnResolvedMessage(ResolvedMessageEventSource source, QueuedMessageEventArgs e)
    {
        try
        {
            // For testing purposes we do not only check the sender address but the subject line as well
            // If the subject contains the substring “REDIR” then the default routing is overwritten.
            //
            // Instead of hard-coding the sender you could also perform an LDAP-query, read the information
            // from a text file, etc.
            //
            if (e.MailItem.FromAddress.ToString() == “administrator@contoso.com
                && e.MailItem.Message.Subject.Contains(“REDIR”))
            {


                // Here we set the address space we want to use for the next hop. Note that this doesn’t change the recipient address.
                // Setting the routing domain to “nexthopdomain.com” only means that the routing engine chooses a suitable connector
                // for nexthopdomain.com instead of using the recpient’s domain.


                RoutingDomain myRoutingOverride = new RoutingDomain(“nexthopdomain.com”); 
                                                                                         
                foreach (EnvelopeRecipient recp in e.MailItem.Recipients)
                {
                    recp.SetRoutingOverride(myRoutingOverride);


                }


            }
        }


        catch // (Exception except)
        {


        }
    }


}


5.) Compile the DLL


6.) Copy the DLL to the HT server


7.) Install the transport agent using the Exchange Management Shell:
     Install-TransportAgent “OwnTestAgent” -TransportAgentFactory “RoutingAgentOverride.SampleRoutingAgentFactory” -AssemblyPath “Path to DLL”


8.) Enable the transport agent using the Exchange Management Shell:
     Enable-TransportAgent “OwnTestAgent”


9.) IMPORTANT: Exit Powershell
10. IMPORTANT: Restart the MSExchangeTransport service


11.) Verify that the agent was successfully enabled / registered by running Get-Transportagent


Tips:



  • To live debug the dll you need to attach to edgetransport.exe.

  • To recompile after a change


    • detach from edgetransport

    • stop the transport service (otherwise Visual studio won’t be able to overwrite the file)
      (only if you registered the dll from the \debug folder)

  • Sometimes messages remain in the outbox until the mail submission service is restarted

Proxying CAS HTTP Cross Forest availability requests

Some of you may want to configure Cross Forest availability with your CAS Servers, but don’t necessarily want to open additional paths through your firewalls or networks for the CAS Servers to be able to talk directly with one another.


 


In this case, if you have an HTTP Web Proxy (obviously we like to use ISA Server), you can configure the CAS Server to use this to proxy it’s SOAP requests for Free Busy and Autodiscover to the other forest.


 


Locate the following folders (actual path may vary if you changed the default install path of Exchange):


 


..\Program Files\Microsoft\Exchange Server\ClientAccess\exchweb\ews


..\Program Files\Microsoft\Exchange Server\ClientAccess\Autodiscover


 


You will find a web.config file in each of these, to which you will need to add the following section (to clarify, it is best placed directly after /<system.web>):


 


    <system.net>
        <defaultProxy>
            <proxy
                usesystemdefault = “false”
                proxyaddress = “http://proxyserver/
                bypassonlocal = “true”
            />
            <bypasslist>
                <add address=”http://[a-z]+/.contoso/.com$” />
            </bypasslist>
        </defaultProxy>
    </system.net>


 

For more information, check out the following MSDN article: http://msdn.microsoft.com/en-us/library/5w91x7a7.aspx

 


Important parameters are:


 


Usesystemdefault -> set to false to be able to specify our own proxy settings


Proxyaddress -> Your HTTP Proxy (ISA Server)


Bypassonlocal -> This setting is important if you have more than 1 CAS Server internally, and if your Proxy Server can not proxy internal HTTP requests.


Bypasslist -> The list of addresses which should be bypassed as local addresses.


 


Following the changes in the web.config files, you should perform an IISRESET.


 


You CAS Server will now use your HTTP Proxy for HTTP requests such as Cross Forest Free busy lookups, Cross Forest Autodiscover etc.


If you did not configure bypass lists, it will be using the HTTP Proxy for all requests.


 


Please note that this is only for HTTPWebRequests (http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.aspx) that the CAS Server initiates (such as those SOAP Free Busy requests to other servers) rather than responses to OWA Clients.

Error “404 Not Found” when using PFDavAdmin against Exchange 2007

 

Sometimes when using PFDavAdmin to view folder properties with Exchange 2007 you may see the following error in the tool:


 


The remote server returned an error: (404) Not Found


 


If you look at the IIS logs on the target machine, you will see the error was “404.11”.


This is due to enhanced security settings that can be set in IIS, and are set by default in IIS7 (Windows 2008).


 


The solution is described in the following article:


 


942076  Error message when you visit a Web site that is hosted on IIS 7.0: “HTTP Error 404.11 – URL_DOUBLE_ESCAPED”


http://support.microsoft.com/default.aspx?scid=kb;EN-US;942076


 


I found that the change in settings only worked after I had used APPCMD in the following way (on my W2K8 MBX server):


Under the following folder:


 


%windir%\system32\inetsrv


 


Run:


 


Appcmd set config “Default Web Site” /section:system.webServer/Security/requestFiltering -allowDoubleEscaping:True


 


If you are still having problems, seeing different errors in the IIS logs, or see different symptoms, you probably have a different issue.

Microsoft Exchange Web Services Managed API 1.0 Beta released

Yesterday the Exchange DEV Team announced the Release of the EWS Managed API Beta. Some basic documentation is available at the the MSDN Site for the Microsoft Exchange Web Services Managed API 1.0 Beta SDK April 2009. The main object of the API is the ExchangeService. In the Getting started section You can see a basic code example for sending an email. In the future we will hopefully see some more samples and interesting results for working with the new API. David Claux has written an introductory article for the classes and methods.

Currently I work on a customer workshop for an Introduction to Exchange Web Services and IT operational aspects (Troubleshooting, monitoring and the like) of them. So I thought, that the below very short and loose linklist can be benefitial (links open in new window):

 







  1. The Vista EWS Gadget (Download Link) – You can see Your inbox, calendar, tasks and read them.




  2. The Exchange Developer Center (You can use this as a starting link)


  3. The Exchange DEV Team Blog, already mentioned before (This is an alternative starting point.) 


  4. The book “Inside Microsoft Exchange 2007 Web Services” about EWS, which is currently probably the book about EWS


  5. Glens Exchange DEV Blog – Glen has written a helper class DLL EWSUTIL, which You can reference in Powershell for various things – Glen has samples for OWA modification, contacts, finding unused mailboxes, postings to Twitter etc. – go and have a look)


  6. MVP Henning Krauses blog (Henning maintains a project for simplyfying Exchange Push Notifications, where You get informed about what is going on in a folder and recently wrote a lot about EWS with interesting samples) .

Enjoy !