Scenario 2: Elevation of Privilege and Lateral Movement
Scenario. In this scenario, an attacker has managed to compromise one or more accounts in your tenancy, and is now working to increase their power. The target is usually global administrator privileges, but specific service privileges are also desirable if the targeted data is in that product. There are a few variations of the attack pattern here that can bridge cloud service interfaces and on-prem infrastructure. For example, if the initially breached account is a regular user, the attacker can either try to get that account promoted to global admin, or they can use it to steal other accounts that have, or can have, admin privileges. If your company allows multiple users to logon to the same machine, it then becomes fairly easy for the attacker to figure out how to logon to the shared machine and run a credential harvesting tool like Those creds can then be used to move laterally in the environment, further owning additional accounts until they eventually get to an account that has admin privileges. Another common pivot at this point is to simply create a new account and promote that new account to global admin, thereby giving the attacker the ability to ‘hide in plain sight’, by having an account that no one else is using, and which likely won’t be noticed unless other admins are regularly reviewing the global admin account population.
Preventing the Scenario. Since the account is still at the center of the attack pattern, the same set of protection controls are at play as with a breached account. You should be using multi-factor authentication, especially with administrator accounts or ones with access to sensitive content. Additionally, you can and should review and implement as many of the lateral movement protections described in this document: . Most of these apply to infrastructure protections for your on-prem clients, but they are key in preventing a single breached account from spilling over into multiple breached accounts. Probably the biggest and best protection you can employ is to make your global administrator community small. We typically recommend a minimum of two and a maximum of five for any size of tenant. This keeps the target area small, and makes it harder for an attacker to hide. You should also setup and operate a set of processes to regularly review the community of global admins and their activity.
Detecting the Scenario. Determining whether or not a specific account has been breached will likely rely on anomalous activity that deviates from a well-understood baseline. The good news is that there is a choke-point in this pattern. Any attacker that is trying to get global admin privileges will have to steal an existing global admin account, promote an existing account to global admin, or create a new account and promote it to global admin. Either way, the global admin role is the prize here, and you can focus your detection strategy on , and by monitoring global admin activities .
Remediating the Scenario. The stakes for the remediation for a successful elevation of privilege attack are substantially higher than they are for a single breached account. It is also much more difficult since global admin privileges grant the attacker so much power. The basics are the same, however. You need to carefully determine everything that the attacker has done both to your data, and what they have done to further entrench themselves in your tenancy. Look for new accounts, accounts that have had recent changes (such as promotion to tenant admin!), global configuration changes, and every interaction with data from the affected accounts. In most cases, once you have successfully regained control of the breached accounts, you can reverse the changes made, and then determine what, if any, communication steps you need to take if data was exfiltrated or deleted. Pay careful attention to document access control lists (ACLs), mailbox delegate permissions, mailbox forwarding rules, and mail transport rules. Enabling MFA on the affected accounts is an excellent remediation. You will also need to re-secure your infrastructure such as mobile devices and client machines. A breach involving an administrative account is very difficult to fully remediate, since and other artifacts that would indicate their interactions. You should always assume that you missed something, and that you will need to remain vigilant over the long term to rebuild confidence in the effectiveness of your remediation.
Scenario 3: Data Exfiltration
Scenario. In this scenario, an attacker has found a way to move data out of your tenancy. The data can be stolen in any number of ways, including through a breach of an account with access to the data, or through system and infrastructure attacks that give them local or system admin privileges to computers that store the data outside of Office 365. There are a variety of potential motivations here, including the theft of intellectual property, the desire to blackmail you, the intention to sell your data on the black market, or to use the data to further entrench themselves in your systems.. The data can also come in a variety of forms, which further complicates your protection strategy. Email, documents, instant messaging conversations, yammer threads, even enumerating your directory information can be useful to an attacker.
Preventing the Scenario. Strategies you can pursue to keep your data from being illicitly exfiltrated will have to be varied, and will need to focus not only on the data itself, but also on the things needed to access the data, such as accounts. Protecting your service from account breaches and elevation of privilege will be your first step in protecting your data. Next, you should pursue several methods inherent in the data itself:
- Access Control Lists. Establish standards for who should have access to specific kinds of data, and then create processes to monitor and maintain those access controls. For example, if you have sensitive financials data in a SharePoint site, ensure that the site and document libraries are restricted to only named individuals, for only the minimum privileges they need (read only, for example), and that you regularly review the access control list.
- External Sharing Policies. Prevent data leakage to external endpoints by configuring your tenancy to restrict certain types of sharing. You can, for example, configure your tenancy to not allow documents to be shared with external people at all. These can be restrictive, so look to strike a balance between your risk and your productivity.
- Least Privilege. Help frustrated users that are trying to collaborate on content. They will often grant over-broad permissions to documents and document libraries. If you have a security group that has all employees, for example, you might be tempted to grant that group permissions to your team sites just to keep it simple. Resist this urge, and take the time to only grant the required minimum privilege to the smallest group of users that you can. The end user’s frustrations will be much higher if their data gets stolen or deleted.
- Data Classification Schemes. Another key strategy you can employ is to setup and use data classification metadata, particularly with document and SharePoint-hosted data. This requires you to determine a set of risk tiers (High business impact, medium business impact, low business impact, for example), and then require sites and documents to tag data in your systems with the appropriate classification. This allows you to more easily monitor very sensitive data, as well as leverage specific technologies to further protect high business impact data.
- Data Loss Prevention. The data classification scheme above is most effective when used in combination with the DLP feature in Office 365. This technology allows you to configure rules about how to handle data moving in and out of your tenancy. It can help you prevent sensitive document content from being emailed to external parties, or prevent your users from sending social security numbers in email. See the above linked feature overview for details about how it works and how to implement it.
Detecting the Scenario. Detecting data exfiltration is also a substantial challenge because it is difficult to distinguish normal usage from abnormal usage patterns, especially since the data will most likely be accessed with an account that has the needed privileges. In addition to helping prevent exfiltration, DLP is also a great way to detect leakage.,You can also extend your account breach and elevation of privilege detection scenarios to include baselines around what kinds of data the users normally access. With those detections in place, you can employ two basic detection patterns for exfiltration:
- First, you can focus your detections on operationalized exfiltration mechanisms like mail forwarding rules or document sharing policies. You should baseline what normal looks like, then implement detections when new forwarding or transport rules are created to move mail to external senders, or if ACL’s are modified on a site to grant external parties access.
- Second, you can look for anomalous interactions with data, especially for large downloads. Attackers often like to ‘smash and grab’ large amounts of data at a time. You can build detection rules that look for multiple, or mass downloads from repositories.
Remediating the Scenario. Responding to an exfiltrated data breach is the hardest attack scenario to actually fix because in many ways the cat is already out of the bag. Once your data leaves the boundaries of your control, it is very difficult to actually regain control. Your strategy should boil down to two sets of capabilities. You need to be able to clearly identify how the exfiltration happened so that you can stop it, and you have to have a clear, well-exercised plan of how to deal with the impacts of losing control of the data. The former relies on the robust acquisition of activity data so you can determine what changes were made and when, so you can go and reverse those changes. The latter relies on your organization undertaking a process to decide how you measure the impact of data loss, and what the right steps are to manage that impact. This can be a fairly simple strategy of deciding who needs to be notified and involved in handling a data breach, and identifying what kinds of data your organization really cares about.
Scenario 4: Data Deletion
Scenario. In this scenario, an attacker actually deletes your data, usually in a way that makes recovery difficult if not impossible. Some variants of this include ransomware that encrypts your data, and then demands a payment to get the key to decrypt the data. This should amount to data deletion since a successful extraction of payment usually leads to even more targeting by the attacker. Attacker motivations for data deletion include covering the tracks of an attack, attempting to do irreparable harm to your business, or simply trying to spite you or your employees.
Preventing the Scenario. Other than the account breach, elevation of privilege, and other data protection mechanisms you should employ, the core prevention strategy should be to ensure that you have sufficient redundancies built into your data management processes to minimize the impact of the deletion. Data in Office 365 will be backed up and made redundant for maximum availability. However, it is possible for an attacker to delete data from SharePoint sites, then delete it from recycle bins, making it almost impossible to recover. Ensure that you have a process for backing up mission critical data to offline stores, and that you know (and practice!) restoring it.
Detecting the Scenario. If you have a very clearly defined set of data that is absolutely mission critical that you cannot lose under any circumstances, you should build an automated detection to alert you if it is deleted. Most organizations won’t have such clear criteria, so a fall back detection of alerting when large amounts of data are being deleted is a viable alternative. Most of the time, impactful data deletions are detected by end users within hours of its removal. Ensure your users know how and to whom to report those incidents.
Remediating the Scenario. Since the data deletion scenario is usually at the end of the kill chain, your first remediation is to ensure you can determine the scope of the breach for all the things needed to actually affect the deletion, such as the user account used, infrastructure leveraged, etc., and that you can remediate those pathways. Restoring your data will be the key step here, and it will rely on the processes established in your protection capability. Bear in mind that in many cases, users will have offline copies of documents that you can leverage to restore service. Also bear in mind that some data, such as OneNote notebooks, are usually stored in the cloud exclusively, aren’t often synced to offline sources, and are crucial to team collaboration and communication. Make sure your strategy incorporates coverage for all data types in use.
Scenario 5: Malicious Insider
Scenario. In this scenario, one of your approved users is performing illicit activities in your tenancy. These sorts of attacks can be the most damaging because the user usually knows a lot about your company already and understands very clearly how to maximize the negative impact to you and your data. Motivations for a malicious insider are as varied as can be, but typical ones include disgruntled employees looking for ways to make extra money, to make a splash on their way out of the company, or to simply spite you. The range of illicit activities that can be performed fall all along the kill chain scenarios as well. The insider might take steps to ensure long term access by building in backdoor accounts or go straight to exfiltration or deleting sensitive data. In the kill chain diagram above the malicious insider scenario spans all the other steps because the attacker can essentially shortcut their attack to any downstream step using their normal access to your tenancy. Users with administrative rights are the most dangerous.
Preventing the Scenario. As with the other scenarios in the kill chain, you will need to ensure your accounts are secure, your privileges are well managed, and that your data is well protected. Of course, the attacker in this case has usually already achieved all the required prerequisites to execute any attack, so the focus on prevention should turn to ensuring you have processes that allow you to discern motive. Make sure you have ways to identify disgruntled or unhappy employees, and ways to protect yourself from short-term vendor and contingent staff. If you think there are specific roles (such as administrators) that are susceptible to working conditions that can lead to disgruntlement, take steps to protect yourself and your data. Awareness, in these cases, is really half the battle. One quality bar you can establish is that sensitive data should require collusion by more than one employee in order for the data to be breached.
Detecting the Scenario. Your detections for this scenario are really no different than what you would put in place for the other scenarios. The core difference here is that you must assume breach, and ensure that you aren’t blind to the possibility that an attacker might be one of your own users. Basically, you don’t need a detection mechanism for a malicious insider, you need to make sure your breached account, elevation of privilege, data exfiltration, data deletion detections include malicious insider considerations.
Remediating the Scenario. Recovering from a malicious insider attack is among the more difficult exercises you will have to perform. The insider will have lots of normal activity alongside the malicious actions. Scoping the real extent of the breach is the hardest part of the remediation effort. Once you have all the illicit activity identified, the remediation actions themselves are exactly what you would do in the other threat scenarios.
Adopting cloud service technologies like Office 365 is an effective way to increase your company’s productivity, and reduce costs. When you are trying to decide if you should make the jump to the cloud, or if you are already there and are trying to address concerns about your risk, the above threat scenarios cover the majority of threat categories you will have to address. Attackers tend to follow the path of least resistance, so adopting a robust protect, detect, and recover strategy across each of these scenarios in the kill-chain will give you reasonably good answers about how much risk you are mitigating.
Post used from: https://blogs.technet.microsoft.com/office365security/addressing-your-cxos-top-five-cloud-security-concerns/