Another M365 email outage... seriously just Google it... there are even multiple websites that monitor and tell you there is an outage but there is nothing you can do about it… or is there?
Whether it is email, Azure, Teams or? What can you do?
Better question yet… now, what are your employees doing while they wait? Well… are they using a personal email account to send business information? That is even scarier.
Does this all sound too familiar?
The good news is you CAN do something about it.
Here is where Mimecast has a brilliant solution. It keeps users email working during on-premise or cloud outages!! Like a back-up parachute, should the primary not open… you don't have to free fall, you can pull the secondary cord and simply glide to safety.
So, let's say the Microsoft M365 service goes down. First off, rather than having you guess if there is a disruption and possibly obtaining confusing information from Microsoft Admin Center, Mimecast provides outage/disruption detection.
Through the ‘heartbeat' approach Mimecast monitors for high latency and failed deliveries. If a problem is detected, based on thresholds, Mimecast will trigger an alert to admins via SMS or secondary email. From there the admin can kick off a continuity event which allows end-users to keep working through Outlook, webmail portal or mobile applications.
With Mimecast, your end-users will have no idea there is a problem. They can continue to send and receive email as if there was no failure. So, they just keep working. Once your primary email service comes back online. Mimecast will sync up with them, and the world keeps turning.
And, coolest part in my opinion, if Mimecast is also your security and archive solution, having am outage that requires a continuity assist from Mimecast doesn't alter your security and archive capabilities in the slightest. You are still just as protected and compliant. No need for your users to seek an alternate, Shadow IT solution.J. Peter Bruzzese - “Conversational Microsoft 365 Cyber Resilience”
Join the many SynerComm customers who have added M365 Resiliency to their Enterprise Email environment. For a deeper discussion, follow along below.
As the business world reacts to the current health crisis, companies are offering remote access to any role that can work from home. Taking a cue from the changing environment, cyber-criminals are already taking advantage. Already (03/15/2020) the US Health and Human Services Department suffered a cyber-attack with the intention of distributing false information.
Here are some recommendations on continuing to practice good information security hygiene as more of the access moves outside of the physical office.
The need to immediately increase remote access capabilities is here, much sooner than a lot of companies were prepared for. But just as it is not prudent to take shortcuts to meet a deadline from your boss, now is not the time to sacrifice security for expedience or convenience. We have already seen examples of people sharing links to private company meetings via social media sites, virtually opening the meeting to anyone who happens upon the link. It is essential that these users who now have new methods of access, understand and protect that access. The bad guys are actively looking to prey upon those who are unprepared.
Palo Alto Networks firewalls have the ability to create security policies and generate logs based on users and groups, and not just IP addresses. This functionality is called User-ID.
User-ID™ enables you to map IP addresses to users on your network using a variety of techniques. The methods include using agents, monitoring domain controller event logs, monitoring terminal servers, monitoring non-AD authentication servers and syslog servers, and even through captive portals (that prompt the user for login). In addition to its use in policies, logging access and threats by user can be invaluable in incident response and forensics. To take full advantage of this feature, it is ideal to map as many IP addresses to users as possible.
With all these great methods to map users to IP addresses, we often miss many systems. They include non-domain joined systems, Linux/Unix systems that don’t centrally authenticate, and potentially many other devices (phones, cameras, etc.). Palo Alto has yet another feature for mapping users, but one that comes with great risk.
To identify mappings for IP addresses that the agent didn’t map, the firewall can probe and interrogate devices. The intention is to only probe systems connected to trusted internal zones, but a misconfigured zone could even allow sending probes out to the internet. Taking that misconfiguration aside, client probing is still a significant security risk. By default, Palo Alto agents send out a request every 20 minutes to all IP addresses that were recently logged but not mapped to a user. It does this assuming that the IP belongs to a Windows system and it uses a WMI probe to log into the unmapped system.
SynerComm believes that a large number of PAN
customers have enabled WMI and/or NetBIOS Client Probing within the User-ID
settings. Our AssureIT penetration
testing team is regularly detecting this on internal pentests. SynerComm
recommends disabling Client Probing in the User-ID Agent setup due to the risk.
Many networking and network security devices use Microsoft WMI probing to interrogate Windows hosts for things like collecting user information. For authentication purposes, a WMI probe contains the username and hashed password of the service account being used. When a domain account is used, an NTLMv1 or NTLMv2 authentication process takes place. It has come to our attention that our penetesters are finding Palo Alto firewalls that are using insecure User-ID methods. Specifically, those that are using WMI and NetBIOS probes to attempt user identification. This allows an attacker to obtain the service account’s username, domain name, and the password hash (more likely the hashed challenge/nonce). Because the service account requires privileges, this becomes a serious security exposure that could be easily abused.
An October 30, 2019 Palo Alto Advisory “Best Practices for Securing User-ID Deployments” recommends ensuring that User-ID is only enabled on internal/trust zones, and applying the principal of least privilege for the service account. Again though, SynerComm recommends also disabling WMI probing completely.
(By: Brian Judd, VP Information Assurance)
In a perfect world, we could trust that every device on our internal network is owned, managed, and monitored by our company and our staff. That includes having full trust that no systems are already compromised, and that no intruder or insider could place a rogue device on our network. Because this is rarely, if ever the case, it’s a stretch to think that it’s safe to share valid domain credentials with any device connected to an internal network.
Using well-known penetration testing tools like responder.py, it is trivial to setup a SMB server that that can listen for and respond to NTLM authentication requests. When good OPSEC isn’t a factor, responder.py also includes abilities to respond to LLMNR and NetBIOS broadcasts to poison other local systems into authenticating to its listening SMB server. It then stores the username and the hashed challenge (nonce) from the authentication messages. Depending on the strength of the password, these captured “hashes” could be cracked and the account could be used to log into other systems.
While all of that sounds scary, it isn’t the concern of this article. If configured to use “Client Probing”, Palo Alto firewalls and their User-ID agents make WMI and NetBIOS connections to map unknown IP addresses to their logged in user. Also, because WMI is IP based, it’s possible to probe any reachable (retable) network/system. To be effective, User-ID almost always uses a domain service account so that it can access any domain member system. An attacker with the ability to run responder.py on an internal network is likely to receive authentication requests from Palo Alto User-ID agents without any need for noisy poisoning attacks. By default, the agent probes every 20 minutes and anytime a new log is written to the firewall without user identification.
OK, let’s make this a bit worse… What if we didn’t need to crack the service account’s password? What if we could just relay the agent’s authentication request to another system and trick it into authenticating the attacker instead? Again, this is trivial and easy using well-known tools like ntlmrelayx.py or MultiRelay.py. Even worse, these tools are not exploits, this is how NTLM authentication was designed to work. If the relayed account’s privilege is sufficient, ntlmrelayx.py will even dump the system’s stored hashes from the SAM database, or execute shell code.
Oh, remember earlier when I mentioned that Palo Alto’s agent probes anytime a new log is written by an unmapped IP address? Using this “feature”, we can script something as simple as a DNS lookup or wget request to generate access logs on the firewall and trigger a User-ID authentication request. With a little time, these logins could be relayed to log into every other system on the network. Considering that older Palo Alto documentation was vague with regards to the necessary service account privileges, it is common to find them as members of highly privileged groups including Domain Administrators. To an attacker, this could be game, set, match in just a few minutes.
Specify included and excluded networks when configuring User-ID
The include and exclude lists available on the User-ID
Agent, as well as agentless User-ID, can be used to limit the scope of User-ID.
Typically, administrators are only concerned with the portion of IP
address space used in their organization. By explicitly specifying
networks or preferably a host address /32, to be included with or excluded from User-ID,
we can help to ensure that only trusted and company-owned assets are probed,
and that no unwanted mappings will be created unexpectedly. See above image.
Disable WMI and NetBIOS Client Probing
WMI, or Windows Management Instrumentation, is a mechanism that can be used to actively probe managed Windows systems to learn IP-user mappings. Because WMI probing trusts data reported back from the endpoint, it is not a recommended method of obtaining User-ID information in a high security network. In environments containing relatively static IP-user mappings, such as those found in common office environments with fixed workstations, active WMI probing is not needed. Roaming and other mobile clients can be easily identified even when moving between addresses by integrating User-ID using Syslog or the XML API and can capture IP-user mappings from platforms other than Windows as well.
On sensitive and high security networks, WMI probing increases the overall attack surface, and administrators are recommended to disable WMI probing and instead rely upon User-ID mappings obtained from more isolated and trusted sources, such as domain controllers.
If you are using the User-ID Agent to parse AD security event logs, syslog messages, or the XML API to obtain User-ID mappings, then WMI probing should be disabled. Captive portal can be used as a fallback mechanism to re-authenticate users where security event log data may be stale.
Use a dedicated service account for User-ID services with the minimal permissions necessary
User-ID deployments can be hardened by only including the minimum set of permissions necessary for the service to function properly. This includes DCOM Users, Event Log Readers, and Server Operators. If the User-ID service account were to be compromised by an attacker, having administrative and other unnecessary privileges creates significant risk. Domain Admin and Enterprise Admin privileges are not required to read security event logs and consequently should not be granted.
Deny interactive logon for the User-ID service account
While the User-ID service account does require certain
permissions in order to read and parse Active Directory security event logs, it
does not require the ability to log on to servers or domain systems
interactively. This privilege can be restricted using Group Policies, or
by using a Managed Service Account with User-ID (See Microsoft TechNet for more
information on configuring Group Policies and Managed Service Accounts.)
If the User-ID service account were to be compromised by a malicious user, the impact
could be reduced by denying interactive logons.
Deny remote access for the User-ID service account
Typically, service accounts should not be members of any security groups that are used to grant remote access. If the User-ID service account credentials were to be compromised, this would prevent the attacker from using the account to gain access to your network from the outside using a VPN.
Configure egress filtering
Prevent any unwanted traffic (including potentially unwanted User-ID Agent traffic) from leaving your protected networks out to the Internet by implementing egress filtering on perimeter firewalls
For more information on setting up and configuring User-ID see the following:
User-ID, PAN-OS Administrator's Guide
Getting Started: User-ID
Create User Groups for Access to Whitelist Applications, Internet Gateway Best Practice Security Policy
User-ID Resource List on Configuring and Troubleshooting