Microsoft 365

​

Getting Started

​

How our integration works

​

Integrating

​

Testing

​

Microsoft Defender for Endpoint

• EICAR test string
• Malicious command

​

Microsoft Entra ID Protect

• Anonymous IP Address
• Unfamiliar Sign-in Properties
• Atypical Travel
• Leaked Credentials

​

Errors

​

AADSTS650051

​

AADSTS650052

$> mgc service-principals create --body '"{\"appId\": \"fc780465-2017-40d4-a0c5-307022471b92\"}"'

$> mgc service-principals create --body '"{\"appId\": \"73c2949e-da2d-457a-9607-fcc665198967\"}"'

$> mgc service-principals create --body '"{\"appId\": \"05a65629-4c1b-48c1-a78b-804c4abdd4af\"}"'

access_denied: AADSTS650052: The app is trying to access a service '05a65629-4c1b-48c1-a78b-804c4abdd4af'(Microsoft Cloud App Security) that your organization '01e288fd-692b-40c7-ac92-58e47ec12340' lacks a service principal for. ...

{"appId": "YOUR_APP_ID"}

$> mgc service-principals create --body '"{\"appId\": \"YOUR_APP_ID\"}"'

​

AADSTS50097

1. Use an authorized device — Perform the OAuth connection from a device that is joined to your Azure AD domain or marked as compliant in Intune/Endpoint Manager.
2. Avoid incognito or private browsing — Private browsing sessions cannot present device credentials, which will cause this error even on an otherwise authorized device.
3. Contact your IT administrator — If you are unsure which devices are authorized, ask your IT admin to verify that the device you are using meets your organization’s Conditional Access requirements.

​

Permission Details

​

Read Access

• The majority of the listed permissions in the oAuth dialog are read only. Microsoft requires us to request them individually, so the list seems long. At a high level, we need to read:
• Security Alerts, obviously, because we need to triage these
• IOCs (indicators of compromise), because these are a form of detection
• Audit Log data, where important supplementary security telemetry lives
• Sign in logs and data, so we can perform detections and analysis
• Organization Information, which is metadata about your tenant itself, so we can ensure we are properly covering all of your organization’s security telemetry
• Directory data, so we can learn your organization, your people, their roles, and how to best triage cases or interact with them.
• Users’ profiles and authentication methods, so we can determine proper guidance for a security detection
• File profiles, for enriching files referenced in detections
• URL profiles, for enriching URLs referenced in detections
• Risk detection and information, because posture related information informs and correlates with detections
• Threat & Vulnerability management information, which informs and enriches detections
• Security Baseline Assessment data, which informs and enriches detections
• Remediation tasks, so we can know what tasks you completed and make better recommendations

​

Write Access

• Risk detections, so we can update statuses (e.g. close resolved instances or false positives)
• Security Alerts, so we can update statuses of the “ticket” portion of alerts and keep them in sync with our triage and response results
• Users’ authentication methods, so we can update MFA policies for compromised accounts as a remediation step [Roadmap Feature, which will require opt-in within our platform]
• Timeline events, so we can sync our case triage timelines with the timelines in the tickets of your detections within your Microsoft console
• All machine information, so we can add comments and metadata to machines for your administrators to see as part of response

​

Containment Access

• Enable/Disable user accounts, so that we can contain a compromised identity during a case, whether automated through user containment options or manually by clicking the contain button within our platform. The result is the Microsoft user account is disabled or enabled; this action is completely safe and reversible, either in-platform through the contain button, or directly in your preferred Microsoft user management tools.
• Revoke all sign in sessions; in the case of an identity compromise, an unauthorized threat actor can persist with the access of your compromised user, even after the user’s credentials have been reset, by leveraging long-lasting sign in session tokens & cookies. This allows us to revoke all sign-ins, which kills threat actors’ access to user accounts. This is a safe and largely reversible action, i.e. the affected user can simply authenticate again to establish new sessions. At most, this is a minor inconvenience to users, in exchange for swift and complete containment of a hostile threat actor bent on reaching a malicious objective, like BEC or ransomware.
• Run live response on a specific machine; this allows us the ability to perform additional telemetry collection, threat hunts, and thorough response actions by checking for a threat actor’s possible persistence on an endpoint in your fleet.
• Restrict code execution; this grants us the ability to instruct Microsoft Defender for Endpoint (DFE) to take actions to block malicious code that DFE detected, but did not block, within your environment by establishing a rule to prevent its execution, following our endpoint containment configuration options after we’ve confirmed the code is hostile.
• Stop and quarantine file; this allows us to instruct Microsoft Defender for Endpoint (DFE) to stop a malicious process and quarantine the malicious files associated with it, when DFE only detects, but does not outright block the threat, following our endpoint containment configuration options after we have confirmed the suspected threat is in fact malicious. Restoring quarantined files must be done manually in the Defender portal; MDE does not expose a REST API for automatic unquarantine.

​

Limiting Permissions

• Complete the oAuth dialog for the Microsoft integration to Wirespeed, accepting the permission list as presented.
• Go to Azure > Enterprise Applications > Wirespeed and remove individual permissions (e.g. write or containment access) as a hard stop beyond the layers of controls present in Wirespeed.
• Document the removed permissions, so that you can re-enable them manually, should you want to enable write/containment access later. Wirespeed will report errors when attempting certain functions, but it may not be readily apparent to us that the cause for the error is manually edited permissions.
• Alternatively, you can choose to update the Microsoft integration later, accepting all of the permissions. You can do this in Wirespeed by going to Integrations > Add Integration > Microsoft and following the same process you did originally, without removing the permissions afterwards. This will update your permissions and retain your existing Microsoft data.

​

Allow-listing Wirespeed emails

1. Go to the Microsoft Defender Portal.
2. Under the Email & Collaboration panel on the left, navigate to Policies & rules.
3. Select Threat policies.
4. Under Rules select Tenant Allow/Block Lists.
5. With Domains & addresses selected, click Add and select Allow.
6. Add wirespeed.co to the dialogue box, leaving the Remove allow entry after set to the maximum 45 day time to live.
7. Complete the form by clicking Add.