Obtaining reports in the past was a manual task which had to be performed every time you wanted to pull data. Many of you (most of you?) have asked us to allow for automated reporting in Office 365. Did you catch how I used the words, “in the past,” in the first sentence?

Well, I’m happy to say that automated reporting in Office 365 has arrived and is now available in your tenant. Reports can be scheduled for delivery either on a weekly or monthly basis.

Rather than start this article with an appetizer, I’m going to switch things up and dive right into the meat and potatoes. Very soon, if not already, you will see two new entries to your Spam Filter in Exchange Online Protection, Allow Lists & Block Lists. As suggested by the name, this is a new way to manage allow and block lists within EOP. These new entries certainly don’t replace using Transport Rules to manage allow and block lists, but instead offer a simpler alternative.

Welcome to the second episode in our Support Hot Topics for Exchange Online Protection series. I’m joined in this episode by my co-worker, Jason, and we discuss Exchange Online Protection strategies, including two transport rules, that can help reduce the threat of zero-day malware.

This is a new series of articles for this blog that were inspired by Mark Russinovich’s Case of the Unexplained series. Each article will tell the story of an Exchange Online scenario that initially made no sense. I’ll then progress through the troubleshooting steps and eventually end up with the root cause. I have a couple of hopes here.

1. If you have experienced the same or similar issue, you can jump right to the root cause without needing to troubleshoot yourself.
   
   
2. You can learn more about Exchange Online from seeing how I approach solving a problem as I’ll be detailing not only what I did, but why I did it.

When you are navigating or making changes in the Exchange Online portal, PowerShell is being executed in the background. Using the Command Logger, you can see exactly what that these background PowerShell command looks like! This tool is a great way to learn PowerShell and can give you a head start in your own scripting.

Exchange 2010 offered ways to view the Exchange shell to see what was happening in the background when changes were made. This feature disappeared in Exchange 2013, but reappeared in Exchange 2013 SP1. The Command Logger is now also present in both Exchange Online and Exchange Online Protection.

Data Loss Prevention (DLP) is a technology that can detect and prevent sensitive information types from being sent outside of an organization. DLP rules will often need tweaking, and this goes hand in hand with troubleshooting false positive detections. We recently published new TechNet documentation that will make this troubleshooting DLP much easier!

I recently worked with an organization who had a single Exchange Online mailbox become compromised. The mailbox credentials were stolen, and the attacker used them to send mail directly from the mailbox. This organization was going through a security analysis of the compromise and wanted to obtain the IP(s) that connected to this mailbox to send the outbound mail. No problem.

We are happy to announce that Common Attachment Blocking (CAB) is coming to EOP.

In the not so distant future, administrators will have the ability to easily block certain file types coming in through email by checking a box! This will eliminate any chance for error that creating a file block through an Exchange Transport Rule often introduces.

The following article was written by Irol Melisa Pinto who is a Technical Advisor for Exchange Online Protection in Microsoft.

Hello EOP Admin’s out there! I am writing this article in the simplest form for a basic level of understanding. We recently worked with a couple of Tenant Admins concerned about the results seen in the SMPT test done through https://testconnectivity.microsoft.com (also known as the Microsoft Remote Connectivity Analyzer tool) and thought of just clearing some air around this topic through this blog.

The test in question here is the Inbound SMTP Email test and the results it returns when run against an Exchange Online mailbox.

The test results show the following.

So here I see a statement saying, “The open relay test message was delivered successfully to admin@testexchangeconnectivity.com.

Next I see a link saying “Tell me more about this issue and how to resolve it” which redirects to the article Open Relay Detected which states the following:

The Microsoft Exchange Analyzer tool attempts to send a test message using a recipient address that does not belong to the Exchange organization. If this operation succeeds, then the SMTP Server operates as an open relay and the following message is returned from the test.

"Open relay test message delivered successfully to Admin@TestExchangeConnectivity.com"

A computer that is running Microsoft Exchange 2000 Server, Exchange Server 2003 or Exchange Server 2007 can be configured as a mail relay, which is not recommended.

An Exchange computer that is configured as an open mail relay may be used to send unsolicited commercial e-mail, also known as spam. If other mail servers identify your Exchange computer as an unsolicited commercial e-mail server, then your Exchange computer may be added to block lists.

Oh boy! With this, the thought that immediately comes to our mind is – is EOP relay safe? How is EOP safe if it is now shown as an Open Relay which was not the case earlier? To understand further I did a little more research on this.

First, I did a domain look up for testexchangeconnectivity.com and it points to IP 157.56.138.170

Now if I check who owns this IP, I see that it is owned by Microsoft!
http://www.senderbase.org/lookup/?search_string=157.56.138.170

The DNS record for testexchangeconnectivity.com points to IP 157.56.138.170 which is Microsoft owned. We do know that testexchangeconnectivity.com is Microsoft owned public test tool. Don’t we know that already? :) So the above results were expected.

Next I checked this article Office 365 URLs and IP address ranges which includes 157.56.0.0/16 under Exchange Online IPv4 Addresses.

Next I used this tool - http://ipconvertertools.com/cidr2ipranges and I see the following:

The IP that testexchangeconnectivity.com used is actually a part of the O365 addresses.

Once again to quickly summarize our findings so far, the DNS record for testexchangeconnectivity.com points to 157.56.138.170 which is a Microsoft IP -> the same IP Address is also a part of Exchange Online pool of IP ranges.

The reason that the Remote Connectivity Analyzer SMTP test shows EOP as an Open Relay, is because it’s sending IP is trusted and seen as internal by EOP. This is why EOP accepts mail from this tool and will route it out to a third party.

As I am sure you know, EOP is not an open relay (and yes we Microsoft confirm that once again). EOP is an Auth-based relay. It follows a set of rules to confirm if an email can be accepted by EOP. Attribution happens in the envelope:

1. First is the Cert, if that matches an inbound connector, we accept the email.
2. Next is the IP, (from the EHLO) if that matches inbound connector, we accept the email.
3. Last is the RCPT TO: if that matches a domain in accepted domains, we accept the email.

In this case both the sending IP and the receiving IP both are part of Exchange Online IPv4 services and based on the above criteria mentioned, we really don’t need any further explanation. 

To reiterate, EOP is not an Open Relay. I do see that this Remote Connectivity Analyzer test has created a bit of confusion and we are working on fixing this incorrect test results.

Irol Melisa Pinto
Technical Advisor for Exchange Online Protection

There are some problems that you just can’t solve without getting a network capture with tools like Microsoft Network Monitor (superseded by Microsoft Message Analyzer), Microsoft Message Analyzer, or Wireshark. If I had a tag line, it would be, “When in doubt, run Wireshark.” When a problem makes no sense, or you have run out of ideas, you know it’s time for a network trace.

A network trace contains great information, but there is always way more information than we need. In this article I’m going to look at the most common Wireshark filters that I use when I’m troubleshooting mail flow with a network trace. In a previous life I used Wireshark to troubleshoot problems with video streaming, SOAP over HTTP, and server communications, which is why it is my go to tool for network captures.

The following article was written by Irol Melisa Pinto who is a Technical Advisor for Exchange Online Protection in Microsoft.

Hello folks! In this article my main focus is to show how we can leverage RSS feeds to help keep us updated. There is no shortage of website resources out there and browsing to various sites can feel like a chore, especially if there have been no updates since the last time you visited. This is where RSS feeds can help.

Exchange Server 2016 was released this morning and is now available for download. The Exchange Team posted an excellent article about the release which I highly recommend checking out. The following video shows some of the new features included in this release.

(Please visit the site to view this video)

For those running Exchange on-premises, enjoy 2016!

This is an interesting case that I recently worked on and would like to share as part of this series. An organization that uses Exchange Online Protection was receiving automated emails from a partner. These emails were arriving with empty subjects and bodies. When the partner sent the automated emails to a Hotmail.com / outlook.com address, they would also arrive with no subject or body. However, when the partner sent these emails to a Gmail account, the would arrive just fine with the subject and body intact.

In this article I walk through how I troubleshot this problem and what the final root cause was.

Looking to implement DKIM signing on mail that is outbound from Office 365? This can be enabled in Office 365 through a manual process. In this article we'll talk about what this process looks like, and why you may want to consider using DKIM to protect your domain against spoofing.

Transport rules contain an Audit setting that is often misunderstood and unchecked without realizing the implications.

Unchecking this box has quite adverse effects on future reporting and troubleshooting for the transport rule. While this may be desirable, I see a lot of organizations unchecking this box and not realizing what the impact will actually be.

The following article was written by Rob McCarthy who is a Business Program Manager for Readiness in Microsoft.

We are happy to announce that Common Attachment Blocking (CAB) is coming to EOP.

In the not so distant future, administrators will have the ability to easily block certain file types coming in through email by checking a box! This will eliminate any chance for error that creating a file block through an Exchange Transport Rule often introduces.

By default, new tenants will have CAB enabled with ten specific file types already checked. Existing tenants will see the feature, but will have to manually enable it.

Once CAB is enabled, by default, ten (10) of the most common file types will already be checked. These ten files types were chosen by our analysts as not only the most common, but often the most likely to be able to transmit malware. Common Attachment Blocking is a big step forward in catching new forms of malware without having to wait for a virus definition to be developed.

In addition to an improved strategy defending against zero-day vulnerabilities, CAB simply allows administrators to block any file they want, for any reason, in a fast, mistake free method.

Please stay tuned for release date details!

- Rob McCarthy

The following article was written by Irol Melisa Pinto who is a Technical Advisor for Exchange Online Protection in Microsoft.

Hello EOP Admin’s out there! I am writing this article in the simplest form for a basic level of understanding. We recently worked with a couple of Tenant Admins concerned about the results seen in the SMTP test done through https://testconnectivity.microsoft.com (also known as the Microsoft Remote Connectivity Analyzer tool) and thought of just clearing some air around this topic through this blog.

The test in question here is the Inbound SMTP Email test and the results it returns when run against an Exchange Online mailbox.

The test results show the following.

So here I see a statement saying, “The open relay test message was delivered successfully to admin@testexchangeconnectivity.com.

Next I see a link saying “Tell me more about this issue and how to resolve it” which redirects to the article Open Relay Detected which states the following:

The Microsoft Exchange Analyzer tool attempts to send a test message using a recipient address that does not belong to the Exchange organization. If this operation succeeds, then the SMTP Server operates as an open relay and the following message is returned from the test.

"Open relay test message delivered successfully to Admin@TestExchangeConnectivity.com"

A computer that is running Microsoft Exchange 2000 Server, Exchange Server 2003 or Exchange Server 2007 can be configured as a mail relay, which is not recommended.

An Exchange computer that is configured as an open mail relay may be used to send unsolicited commercial e-mail, also known as spam. If other mail servers identify your Exchange computer as an unsolicited commercial e-mail server, then your Exchange computer may be added to block lists.

Oh boy! With this, the thought that immediately comes to our mind is – is EOP relay safe? How is EOP safe if it is now shown as an Open Relay which was not the case earlier? To understand further I did a little more research on this.

First, I did a domain look up for testexchangeconnectivity.com and it points to IP 157.56.138.170

Now if I check who owns this IP, I see that it is owned by Microsoft!
http://www.senderbase.org/lookup/?search_string=157.56.138.170

The DNS record for testexchangeconnectivity.com points to IP 157.56.138.170 which is Microsoft owned. We do know that testexchangeconnectivity.com is Microsoft owned public test tool. Don’t we know that already? So the above results were expected.

Next I checked this article Office 365 URLs and IP address ranges which includes 157.56.0.0/16 under Exchange Online IPv4 Addresses.

Next I used this tool – http://ipconvertertools.com/cidr2ipranges and I see the following:

The IP that testexchangeconnectivity.com used is actually a part of the O365 addresses.

Once again to quickly summarize our findings so far, the DNS record for testexchangeconnectivity.com points to 157.56.138.170 which is a Microsoft IP -> the same IP Address is also a part of Exchange Online pool of IP ranges.

The reason that the Remote Connectivity Analyzer SMTP test shows EOP as an Open Relay, is because it’s sending IP is trusted and seen as internal by EOP. This is why EOP accepts mail from this tool and will route it out to a third party.

As I am sure you know, EOP is not an open relay (and yes we Microsoft confirm that once again). EOP is an Auth-based relay. It follows a set of rules to confirm if an email can be accepted by EOP. Attribution happens in the envelope:

1. First is the Cert, if that matches an inbound connector, we accept the email.
2. Next is the IP, (from the EHLO) if that matches inbound connector, we accept the email.
3. Last is the RCPT TO: if that matches a domain in accepted domains, we accept the email.

In this case both the sending IP and the receiving IP both are part of Exchange Online IPv4 services and based on the above criteria mentioned, we really don’t need any further explanation. 

To reiterate, EOP is not an Open Relay. I do see that this Remote Connectivity Analyzer test has created a bit of confusion and we are working on fixing this incorrect test results.

Irol Melisa Pinto
Technical Advisor for Exchange Online Protection

There are some problems that you just can’t solve without getting a network capture with tools like Microsoft Network Monitor (superseded by Microsoft Message Analyzer), Microsoft Message Analyzer, or Wireshark. If I had a tag line, it would be, “When in doubt, run Wireshark.” When a problem makes no sense, or you have run out of ideas, you know it’s time for a network capture.

A network trace contains great information, but there is always way more information than we need. In this article I’m going to look at the most common Wireshark filters that I use when I’m troubleshooting mail flow with a network trace. In a previous life I used Wireshark to troubleshoot problems with video streaming, SOAP over HTTP, and server communications, which is why it is my go to tool for network captures.

What sorts of problems require a network capture?

The following are some of the top scenarios where I will want to obtain a network capture.

• SMTP logs show one side is sending the error “500 Unrecognized command”
• Mail server cannot negotiate TLS
• Problems with DNS look ups or timeouts
• I suspect a mail server is sending a message that doesn’t conform to the SMTP RFC

SMTP protocol logs can sometimes be all we need for the above scenarios, but sometimes we will need a network capture to fully know what’s going on.

Obtaining and Using Wireshark

Wireshark is a network protocol analyzer that lets you see what’s happening on the network on a packet level. Wireshark is free to use and can be obtained at http://www.wireshark.org. During the install, you’ll be asked to install WinPcap. This is required for computers that will be taking captures. If you just want to look at capture files, and not actually capture network traffic, WinPcap isn’t required.

Once Wireshark is installed, taking a capture is easy.

1. Click the options button to verify your configuration.
   
   
   1. Ensure that Use promiscuous mode on all interfaces is selected. This will cause Wireshark to also capture traffic that isn’t explicitly destined to, or sent from, the capture machine. Also ensure that no capture filters have been enabled.
      
      
      I typically don’t’ set a filter on this screen so I can capture as much data as possible. I then rely on filters post capture to parse out unneeded data. It’s better to capture too much, than not enough and be forced to capture again.

2. Click this button to launch the capture interfaces window.
   

3. Check the box beside the interface you would like to capture on, and then click Start.
   

4. The capture pane should now start filling with the network traffic.
   

5. Replicate the problem, and once completed click the stop capturing button.
   

6. Save the capture file.

Filtering in Wireshark

Once a network capture has been obtained we will need to filter out information that isn’t relevant to our investigation. On my non-production mail server, a 5 second capture can result in thousands of captured packets which is overwhelming to look at. With the right filter, I can reduce this to less than 50 packets which will contain a single message hand off.

Once you have entered a filter in Wireshark, ensure you click Apply to see the filtered results.

Filtering by SMTP traffic (port 25)

Assuming traffic is over port 25, there are two ways of doing this. We can type either of the following into the Filter text field.

• SMTP
• tcp.port == 25

I recommend using tcp.port == 25 and not SMTP. The reason being, is that SMTP will only give you SMTP packets. Whereas using tcp.port == 25 will give you the SMTP packets, along with the TCP packets containing SYN, ACK, FIN, and SSL handshakes, which are important to see in a trace.

Using SMTP as the filter I see the following. This message was not sent using TLS so I can see all the communications in the clear.

I see the SMTP communication, but none of the TCP communication that deals with handshakes, re-transmit requests, SSL setup, and other items on the network layer. This may or not be ok. I prefer to see these items so I’ll instead filter by port.

Using tcp.port == 25 as the filter I see the following.

Sometimes there’s a problem with the initial three-way handshake or negotiating TLS, and these are the reasons I like to filter by port 25 and not by SMTP.

Let’s look at a message sent over TLS. Filtering using SMTP shows me the following.

There’s really nothing here because 99% of the communications were sent over TLS which is classified as TCP and not SMTP by Wireshark.

If we instead filter on port 25 we can see additional information like the three-way handshake and the TLS negotiation. We can see the TLS version used, the cipher suite, and the certificate name that was passed. This is especially important to see when troubleshooting a TLS negotiation problem.

Unless you have a particular reason to filter on SMTP, I would recommend using tcp.port == 25 instead.

Filtering by IP address

Let’s say we want to view SMTP traffic to or from a particular IP. Use the following.

ip.addr == 1.1.1.1 and tcp.port == 25

Filtering by DNS requests

Sometimes mail delivery fails because the DNS request performed by the mail server wasn’t successful. To view these results, enter the following in the Filter field.

DNS

In this example, I can quickly see the MX lookup for outlook.com was successful.Click the screenshot for a larger view.

Row 1: Mail server performs a DNS query on outlook.com
Row 2: DNS server returns the MX address for outlook.com
Row 3: Mail server queries the first MX address with the lowest priority. Mx3.hotmail.com
Row 4: DNS server returns the IPs associated with mx3.hotmail.com.

Filter out duplicate rows

Sometimes we need to obtain a capture from a network device like a router. These captures often have duplicate rows present. You’ll see an entry for a packet that enters the router, and then see it again when it leaves the router. For one of my cases, here’s what a capture looked like from a router when I filtered on port 25.

Yuck! I want to filter out the retransmissions and the duplicate ACKs. To do this, I’m going to use the following filter.

tcp.port == 25 and not tcp.analysis.retransmission and not tcp.analysis.duplicate_ack

With this filter in place, the capture is much easier to read.

Filter on a specific conversation

Often you’ll want to filter based on a particular conversation. When a TCP conversation is spun up, the server sending the request will generate a random port. In Wireshark, you can search on the Info column to find a name that would identify the conversation. For example, lets search on the recipient for a message that was not sent using TLS.

In Wireshark, hit CTRL-F, select String, and search for the address.

Once the packet is found, use the bottom pane in Wireshark to determine the ports used.

I can now filter on this TCP Port pair to see this conversation.

There's also another way to isolate a particular conversation, Follow TCP/UDP Stream.

Follow a TCP/UDP Stream

I have one last tip that goes along with the above conversation filter, and is a better way to see only a single conversation. Find a packet that you are interested in, right click, and select Follow TCP Stream.

Wireshark will auto create a filter and apply it (typically it will be something like tcp.stream eq 7). In addition, you’ll see a new window which will show a different view of the conversation. For example, here’s what I see when I follow the TCP stream for a message that was sent not using TLS.

Here we are seeing the raw SMTP commands that the mail server sent for this message. This view can sometimes be easier to view than the packet capture window for a particular conversation.  Of course it won’t look this nice for messages sent over TLS. 

Summary

The key to analyzing packet captures is to remove as much of the irrelevant data as you can. Although reading the relevant data can be hard, the first step is to filter out what you don’t need.

Do you have tips for reading or filtering packet captures? Leave them in the comments!

The following article was written by Irol Melisa Pinto who is a Technical Advisor for Exchange Online Protection in Microsoft.

Hello folks! In this article my main focus is to show how we can leverage RSS (Rich Site Summary / Really Simple Syndication) feeds to help keep us updated. There is no shortage of website resources out there and browsing to various sites can feel like a chore, especially if there have been no updates since the last time you visited. This is where RSS feeds can help.

I recently worked with an organization that was not aware that Office 365 was disabling support for RC4 ciphers. This information was posted on the Office Blogs website, but unless you go to that blog often, you wouldn’t have known about this change. An easy way to follow news on our blogs is to leverage the RSS feeds that they publish. In this article I’ll show how to use the RSS reader in the Outlook desktop client to easily follow RSS feeds.

Subscribing to the Office Blogs RSS feed with the Outlook desktop client

In the steps below I’ll be using the Outlook desktop client to subscribe to an RSS feed showing Exchange news posted to the Office Blogs page. If you use a different RSS reader, you can follow these steps to the point where we obtain the URL of the RSS feed, which you can then plug into your RSS reader of choice.

1. Browse to https://blogs.office.com/.

2. Click on “What Products do you use?”
   1. Select the Office products you are interested in. I selected Exchange.
   2. Click on Apply Filters.
      
3. Now click on RSS.
   
4. Now Copy the link Displayed in the address bar. The link in this example that you need to copy is https://blogs.office.com/feed/?filter-product=exchange.
   

5. Now go to your Outlook desktop client, right click on the RSS Feeds folder, and select Add a New RSS Feed.
   

6. A new window will popup asking if you want to trust this link.Once complete, click OK on this window, and then click Yes on the window below.
   
   1. Click Advanced. Add details like Feed Name, and you may want to make changes to the Downloads sections.
      

7. Once complete, click OK on this window, and then click Yes on the window below.

I can now easily follow the Exchange updates that are posted to the Office Blogs page without ever leaving my Outlook desktop client (or RSS reader of choice).

Repeat the above steps for any other sites you are interested in following which also publish an RSS feed. The best part is you can sort updates of each link in a separate folder.

Other Microsoft sites that publish RSS feeds

First and foremost, I highly recommend subscribing to the RSS feed of this blog! The feed can be found on the right hand side under Options, RSS for posts.

Secondly, I would recommend you subscribe to the Service Health feed in the Office 365 Portal. When you first log into the portal, click View details and history under Current health.

Once the next screen loads, the RSS feed can be found in the upper right hand corner of the page.

And for my third pick, want an easy way to be alerted when we change IP ranges associated with Exchange Online? There’s an RSS feed for that! Check out Office 365 URLs and IP address ranges.

In addition to the above, the following are other Microsoft sites that publish RSS feeds.

1. Terry Zink: Security Talk
2. Exchange Team Blog
3. Office Mechanics
4. MSDN Blogs
5. TechNet Blogs
6. TechNet
7. Office 365 Support Community

Hoping this was helpful! Thanks for reading

Irol Pinto
Technical Advisor for Exchange Online Protection

Exchange Server 2016 was released this morning and is now available for download. The Exchange Team posted an excellent article about the release which I highly recommend checking out. The following video shows some of the new features included in this release.

[View:https://youtu.be/sZsh7SH0dM4:0:0]

For those running Exchange on-premises, enjoy 2016!