Post cover image

October 19, 2026

ConnectWise Cloud Backup Incident And M365 Tenant Compromise

Note: Create your free account in SOCFortress Signals (https://signals.socfortress.co/) for:

By SOCFortress

15 min read

  • Global intelligence
  • Security advisories, search & filters
  • Microsoft Patch Tuesday & CISA KEV views
  • Threat actor, malware & IOC views
  • Source references, visualizations & timeline
  • Account registration & MFA

Intro

Recent security disclosures detail an active cybersecurity incident involving unauthorized access to ConnectWise application identities, specifically impacting Cloud Backup environments previously known as SkyKick. Threat actors have exploited stolen application credentials to compromise downstream Microsoft 365 tenants, prompting ConnectWise to temporarily suspend affected services like Cloud Management and SaaS Security as part of its containment response. Security analysts have observed targeted waves of malicious sign-ins across multiple organizations, highlighting the critical need for administrators to audit Entra ID permissions, review authentication logs, and secure workload identities. In response, ConnectWise and managed security providers have released technical remediation guides urging partners to preserve forensic evidence, disable compromised connections, and implement robust hardening measures.

Forensic investigations conducted by Huntress and ConnectWise revealed that the threat actor executed a multi-stage attack campaign. Across the broader ecosystem, approximately 1,000 Entra ID tenants experienced authentication attempts from the primary malicious IP address (144.172.64.128), with 300 tenants recording successful authentications. Notably, in tenants where local service principals were absent, authentication succeeded at the identity boundary but failed to yield resource access. On October 15, 2026, the threat actor escalated to a second, highly targeted wave targeting 16 specific high-value tenants across the policy, national security, trade, and critical minerals sectors. This targeted wave deployed a dual-sweep methodology: an automated sweep targeting Graph tokens via SkyKick applications between 09:25:04 and 12:35:50 UTC, followed by a manual post-exploitation sweep between 13:54:39 and 14:20:24 UTC targeting Exchange Online, SharePoint Online, Teams, Azure Resource Manager (ARM), Entra ID, and Office 365 Management APIs. Confirmed active abuse of the Teams application identity (24205314-2b89-4e07-a2a4-579e898a5640) occurred in at least one customer tenant.

[Threat Actor Post-Exploitation Lifecycle]
Vendor Credential Stolen
   │
   ├──> Bypasses User MFA / Passwords (OAuth 2.0 Token Grant)
   │
   ├──> Phase 1: Automated Broad Reconnaissance Sweep (Oct 15, 09:25–12:35 UTC)
   │      └── Scans ~1,000 Tenants -> 300 Authenticating Tenants (Graph API)
   │
   ├──> Phase 2: Targeted Post-Exploitation Sweep (Oct 15, 13:54–14:20 UTC)
   │      └── Scans 16 High-Value Sector Tenants (Exchange, Teams, ARM, Entra)
   │
   └──> Phase 3: Secondary Persistence Planting (T1098.001 / T1098.003)
          ├── Plants Rogue Secrets/Certificates on Service Principals
          ├── Elevates Directory Roles (e.g., Global Administrator)
          └── Configures Hidden Mailbox Inbox / Transport Rules

Crucially, vendor-side certificate revocation alone does not neutralize local tenant persistence. Once initial access is achieved, threat actors frequently deploy secondary persistence mechanisms (MITRE ATT&CK T1098.001: Account Manipulation — Additional Credentials). Leveraging the stolen application's broad scope, attackers add client secrets or public certificates to other trusted service principals, assign elevated directory roles (such as Global Administrator), grant unauthorized OAuth 2.0 admin consent, or inject hidden mailbox forwarding rules. Even after ConnectWise disabled the primary application identities and revoked certificates on October 17 at 07:00 UTC, secondary backdoor credentials planted prior to vendor containment remain fully active. Furthermore, due to deep architectural integrations between services, ConnectWise proactively suspended SaaS Security and Cloud Management alongside Cloud Backup, even though the primary identity breach originated strictly within the Cloud Backup/SkyKick identity pipeline. ConnectWise observed no successful threat activity in vendor-monitored environments following October 17 at 05:00 UTC; however, vendor monitoring cannot observe downstream tenant persistence.

Incident Timeline & Discovery Window

Initial Vendor Discovery: October 14, 2026.
Observed Activity Window: October 13–19, 2026.
Targeted Wave: October 15, 2026 (Broad sweep: 09:25–12:35 UTC; Manual sweep: 13:54–14:20 UTC; Last sign-in: 14:20 UTC).
Vendor Containment: October 17, 2026, at 07:00 UTC.
Vendor Baseline Marker: No threat activity observed in vendor-monitored infrastructure since October 17 at 05:00 UTC.

Primary Threat Vectors & Methods

Stolen application credentials/certificates; service principal sign-in flows; automated/scripted OAuth token harvesting; manual post-exploitation sweeps across Graph, Exchange Online, Teams, SharePoint, ARM, Entra ID, and Office 365 Management APIs; OAuth 2.0 consent abuse; secondary credential planting.

Key Indicators of Compromise (IPs)

144.172.64.128 (Primary address linked to initial sweeps and targeted waves)
144.172.64.99 (Secondary address identified via downstream partner monitoring)
144.172.64.60 (Secondary address identified via downstream partner monitoring)

Observed Scripting / User-Agents

Python-urllib/3.12
python-requests/2.31
curl

Vendor Mitigations Implemented

Global disablement of 7 application identities; complete certificate revocation across Cloud Backup connections; proactive suspension of Cloud Backup, SaaS Security, and Cloud Management platforms.

Understanding these high-level threat mechanics and technical indicators enables response teams to systematically identify and catalog the specific application identities present within managed customer environments.

Identification and Inventory of Compromised Vendor Application Identities

Accurate identity mapping is the foundational prerequisite for effective cloud containment. In a multi-tenant cloud infrastructure, incident response teams must locate and audit the exact service principal instances deployed in each client tenant. Attempting to identify target applications based solely on display names introduces severe operational risk; display names in Entra ID are malleable, non-unique, and frequently altered during software rebranding or legacy upgrades. For instance, legacy installations of ConnectWise Cloud Backup often retain historical "SkyKick" or "SkyKick Cloud Manager" display names in the portal interface. Relying on display strings can cause responders to miss active instances or target incorrect application registrations, leaving active threat paths open.

The matrix below catalogs the seven ConnectWise application identities disabled during the incident. Response teams must query Entra ID directories matching strictly on the immutable Application Client ID:

None

When executing tenant identification protocols, response teams must inspect both active and dormant connections across all managed environments. Administrators must record two distinct identifiers for every matched instance: the globally uniform Application Client ID and the tenant-specific local Object ID (which uniquely identifies the local service principal object instantiated within that specific directory).

Once target application identities and local Object IDs are cataloged across all managed client tenants, response teams must execute immediate tenant-level containment protocols to enforce administrative lockdowns.

Immediate Tenant Containment & Administrative Lockdown

A critical operational distinction exists between vendor-side certificate revocation and local customer-tenant administrative containment. When a vendor revokes application certificates or suspends cloud management platforms, it prevents new authentication requests initiated through the vendor's centralized infrastructure. However, vendor-side actions do not modify local directory configurations, revoke local permission grants, or clear unexpired session tokens inside individual customer Entra ID tenants. Immediate administrative containment within each local client directory is mandatory to enforce hard security boundaries.

Administrators executing containment in Microsoft Entra ID (https://entra.microsoft.com/) must possess the Application Administrator or Cloud Application Administrator role and execute the following step-by-step directive:

  1. Authenticate to the Microsoft Entra admin center using an authorized account and record the target Microsoft 365 Tenant ID.
  2. Navigate to Entra ID \rightarrow Enterprise applications \rightarrow All applications.
  3. In the search filter, input the exact Application Client ID for each of the seven identified application identities (e.g., 506e08f9-6e9a-4da4-942b-a099a03644ae).
  4. Select the matching enterprise application, navigate to Properties in the left navigation pane, toggle Enabled for users to sign-in? to No, and click Save.
  5. Document the saved state, Application Client ID, local Object ID, performing administrator identity, and precise UTC timestamp. Repeat this verification across all seven target Application IDs.
[Tenant Containment & Isolation Protocol]
1. ConnectWise Admin Center (https://entra.microsoft.com/)
2. Verify Role: Application Administrator or Cloud Application Administrator
3. Query: Enterprise Applications -> Filter by exact Application Client ID
4. Action: Properties -> Toggle "Enabled for users to sign-in?" to NO -> Save
5. Audit Record: Log Application ID | Local Object ID | Admin UPN | UTC Timestamp

CRITICAL FORENSIC WARNING: DO NOT DELETE APPLICATION REGISTRATIONS Prematurely deleting enterprise application registrations or local service principals destroys local configuration metadata, consent records, key identifiers, and Object ID associations required for forensic reconstruction. Disabling sign-ins (Enabled for users to sign-in? = No) enforces immediate containment while fully preserving audit trails and configuration metadata.

Administrators must evaluate the operational limitations of sign-in disablement: toggling Enabled for users to sign-in? to No blocks new authentication attempts, but it does not automatically invalidate previously issued OAuth access tokens that remain unexpired. Nor does disablement remove secondary persistence mechanisms—such as planted client secrets on other service principals, elevated directory role assignments, or malicious mailbox forwarding rules—established prior to containment.

With administrative sign-in restrictions enforced, response teams must systematically pivot to preserving volatile forensic evidence and audit logs across all affected directories.

Forensic Evidence Collection & Audit Log Preservation

Preserving digital evidence prior to initiating remediation is vital to establishing an accurate timeline and scope of unauthorized activity. Cloud audit logs are volatile; log retention periods dictated by cloud identity providers strictly bound the time window available for forensic capture. Executing remediation commands without securing raw log archives risks overwriting evidence required to prove or disprove data exfiltration and secondary persistence.

Responders must assign team members holding the Security Reader or Audit Log Reader role to execute log collection commands across multi-layered cloud logging sources:

  • Entra ID Directory Audit Logs: Navigate to Monitoring & health \rightarrow Audit logs in the Entra admin center. Filter log coverage to encompass the incident timeline (October 13, 2026, through present) and export raw records as JSON. For large environments, split export queries into smaller date ranges to prevent API response truncation.
  • Entra ID Sign-in Logs: Access Monitoring & health \rightarrow Sign-in logs. Export four separate, complete JSON datasets covering each specific sign-in category:
  1. Interactive user sign-ins
  2. Non-interactive user sign-ins
  3. Service principal sign-ins (Essential for tracing non-human identity abuse)
  4. Managed identity sign-ins
  • Microsoft Purview Unified Audit Records: Access Microsoft Purview \rightarrow Audit. Run unified audit log extractions covering all available Microsoft 365 services across the investigation timeline, ensuring coverage for Exchange Online, Teams, SharePoint, and directory management events. Preserve existing SIEM streams, Azure Blob storage archives, or Graph API log exports.

The matrix below outlines forensic capability limitations and log retention constraints imposed by Microsoft Entra ID license tiers:

None

If log coverage contains gaps or records have expired, responders must explicitly document these analytical limitations in the formal investigation record. A clean log search resulting from missing or expired log history cannot confirm the absence of threat actor activity.

With raw forensic log archives secured, responders can safely initiate deep-dive threat hunting workflows to identify unauthorized access and secondary persistence.

Threat Hunting & Forensic Investigation Workflow

Executing a successful cloud forensic investigation requires a systematic methodology spanning Entra ID, Azure Resource Manager (ARM), Exchange Online, and core Microsoft 365 workloads. Incident response teams must systematically evaluate six distinct investigation domains to expose primary threat activity and secondary persistence.

Sign-in Log & IP Scoping Analysis

Responders must scope sign-in log queries from October 13, 2026, through the present time. Where Entra ID P1/P2 licensing permits, extend log queries back to October 1, 2026, to establish baseline operational behavior. All queries and exports must be logged using explicit UTC timestamps.

Inspect Service Principal Sign-ins by filtering specifically for the seven target Application Client IDs, and search all sign-in categories for the confirmed malicious source IP addresses:

  • 144.172.64.128 (Primary malicious address used in broad reconnaissance and targeted waves)
  • 144.172.64.99 (Secondary address identified via downstream partner monitoring)
  • 144.172.64.60 (Secondary address identified via downstream partner monitoring)

Evaluate observed authentication events against expected vendor operational baselines using the following reference matrix:

Indicator / Authentication Context

Technical Context & Forensic Interpretation

IP Addresses: 144.172.64.128
144.172.64.99
144.172.64.60

Published Malicious Indicators: Any matching authentication event represents confirmed threat actor interaction. Investigate event outcomes (Success vs. Failure), target resource identifiers, and correlation IDs immediately.

User-Agents: Python-urllib/3.12
python-requests/2.31
curl

Scripting Client Context: Indicates automated or manual command-line post-exploitation sweeps. Compare timestamps and target endpoints against authorized administrative script logs.

User-Agents / Egress: kiota-dotnet
Azure private IPv6 ranges

Expected Vendor Baseline: Typical egress indicators for legitimate vendor service traffic. However, user-agent string spoofing is trivial; matching these strings alone does not prove an event was authorized.

Directory Audit Event Investigation

Navigate to Monitoring & health \rightarrow Audit logs and perform targeted queries across key administrative categories for events occurring between October 13, 2026, and the present. Analyze both the initiator and target of every event:

  • ApplicationManagement: Search for Update application - Certificates and secrets management, Add service principal credentials, Add application, Add service principal, Add owner to application, Add owner to service principal, Add app role assignment to service principal, Add delegated permission grant, and Consent to application.
  • RoleManagement: Audit Add member to role events, focusing on high-privilege roles, as well as changes to eligible role assignments in Entra Privileged Identity Management (PIM).
  • Policy: Search for modifications to Conditional Access policies (Update policy, Add policy, Delete policy) and changes to trusted or named locations.
  • UserManagement: Audit the creation of new directory user accounts, unexpected administrative password resets, and changes to registered authentication methods.

For every identified audit event, record the Initiator identity, Target Resource, Operation Outcome, UTC Timestamp, User Agent, and Correlation ID.

Application Credentials & Federation Trust Audit

Attackers possessing application permissions frequently plant long-lived client secrets or federated credentials on secondary applications to maintain backdoor access (MITRE ATT&CK T1098.001).

  1. Navigate to Entra ID \rightarrow App registrations \rightarrow All applications. Select each locally registered application and inspect Certificates & secrets.
  2. Audit all active client secrets, public key certificates, and federated identity credentials. Compare key descriptions, start dates, and validity periods against authorized change control records. Note that valid start/end dates do not reveal when a key was added — cross-reference key creation against Add service principal credentials directory audit events.
  3. For enterprise applications (service principals) owned by third parties where secrets are not visible in the UI portal, responders must query credential metadata via the Microsoft Graph API or Microsoft Graph PowerShell SDK.
  4. When an unauthorized service principal secret is identified, an administrator with the Application Administrator role must remove the credential. Responders can execute the Graph API removePassword operation targeting the local Object ID and specific credential keyId:
POST /servicePrincipals/{local-object-id}/removePassword
Content-Type: application/json{
  "keyId": "00000000-0000-0000-0000-000000000000"
}

Alternatively, administrators can execute the Microsoft Graph PowerShell SDK cmdlet:

# Remove unauthorized client secret from a local Service Principal
Remove-MgServicePrincipalPassword -ServicePrincipalId "<Local-Object-ID>" -KeyId "<Credential-KeyID>"

Responders must assign administrators holding the Privileged Role Administrator role to verify that threat actors have not elevated service principal privileges or altered tenant governance:

  • Open Roles and administrators and review active and eligible assignments for high-privilege directory roles: Global Administrator, Privileged Role Administrator, Privileged Authentication Administrator, Application Administrator, Cloud Application Administrator, Exchange Administrator, and SharePoint Administrator.
  • Match local Object IDs associated with all role assignments. Correlate any application role additions with directory audit logs.
  • Inspect Enterprise Applications for newly granted administrative consent (Consent to application) or elevated Graph API permissions (e.g., Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory) representing OAuth 2.0 consent abuse.
  • Audit Application Ownership: Verify that no unauthorized user accounts or service principals have been added as Owners of existing app registrations.

Conditional Access & Workload Identity Scope Assessment

Evaluate all Conditional Access (CA) policies in Protection \rightarrow Conditional Access \rightarrow Policies for unauthorized modifications, newly added exclusions, or modified named locations.

Responders must understand a critical architectural limitation of Conditional Access: standard CA policies apply strictly to user authentication flows and do not govern application-only (service principal) access tokens. Furthermore, while Conditional Access for Workload Identities provides location and risk controls for non-human identities, it only applies to single-tenant service principals registered directly within the local directory. It does not restrict or govern third-party, multi-tenant SaaS applications (such as the compromised vendor applications). Disabling local service principal sign-in remains the primary mandatory control.

Exchange Online & Mailbox Persistence Hunting

When threat actors obtain Exchange Online management permissions, they frequently establish hidden mail routing or forwarding rules to exfiltrate data continuously (MITRE ATT&CK T1098.003: Account Manipulation — Additional Email Delegate Permissions). An administrator holding the Exchange Administrator role must execute the following checks:

  • Execute Purview Unified Audit searches across the investigation timeline targeting Exchange administrative operations: New-InboxRule, Set-InboxRule, Set-Mailbox, Add-MailboxPermission, Add-RecipientPermission, New-TransportRule, and Set-TransportRule.
  • Audit Exchange Mail Flow Rules in the Exchange Admin Center (Mail flow \rightarrow Rules) for external forwarding rules or unexpected blind carbon copy (BCC) conditions.
  • Connect to Exchange Online PowerShell and run queries to inspect all mailboxes for forwarding, auto-deletion, or hidden inbox rules:
# Deep Exchange Online Inbox Rule Inspection Script
Get-Mailbox -ResultSize Unlimited | ForEach-Object {
    Get-InboxRule -Mailbox $_.UserPrincipalName -IncludeHidden | Where-Object {
        $_.ForwardTo -ne $null -or
        $_.ForwardAsAttachmentTo -ne $null -or
        $_.RedirectTo -ne $null -or
        $_.DeleteMessage -eq $true -or
        $_.MoveToFolder -ne $null
    } | Select-Mailbox, Name, Enabled, ForwardTo, RedirectTo, DeleteMessage, MoveToFolder
}
  • Audit mailbox permissions for unauthorized FullAccess, SendAs, or SendOnBehalf grants.
  • Where Microsoft 365 E5 or advanced audit licensing is present, query MailItemsAccessed audit records to evaluate which specific mailboxes and message items were accessed or bound by the compromised application identity.

Systematically auditing these six control areas ensures that all primary and secondary persistence mechanisms are exposed, setting the stage for complete remediation.

Remediation & Persistence Eradication Protocol

Remediation must be executed systematically. Simply replacing a primary vendor credential or re-enabling services without eradicating secondary backdoor mechanisms leaves the tenant vulnerable to immediate re-compromise.

Responders must execute and document the following structured remediation checklist across every managed tenant prior to considering the environment clean:

  • [ ] Eradicate Unauthorized Application Credentials (MITRE ATT&CK T1098.001):
  • [ ] Execute Microsoft Graph API removePassword POST operations or Remove-MgServicePrincipalPassword PowerShell cmdlets to strip all unauthorized client secrets from service principals.
  • [ ] Remove unauthorized public key certificates and federated credential trusts from all App Registrations.
  • [ ] Strip Elevated Directory Roles & Permissions:
  • [ ] Remove unauthorized application service principals from high-privilege directory roles (Global Administrator, Application Administrator, etc.) using Privileged Role Administrator rights.
  • [ ] Revoke unauthorized OAuth 2.0 admin consent grants and elevated Graph API permissions.
  • [ ] Remove unauthorized users or service principals assigned to Application Ownership roles.
  • [ ] Purge Mailbox & Mail Flow Persistence (MITRE ATT&CK T1098.003):
  • [ ] Delete unauthorized Exchange Transport Rules and mail flow redirect configurations via Exchange Admin Center.
  • [ ] Remove unauthorized FullAccess, SendAs, and SendOnBehalf delegated mailbox permissions.
  • [ ] Purge all malicious, auto-deleting, or hidden inbox rules via Exchange Online PowerShell (Remove-InboxRule).
  • [ ] Re-baseline Access & Security Policies:
  • [ ] Revert unauthorized modifications made to Conditional Access policies, policy exclusions, and Named Locations.
  • [ ] Terminate active user sessions (Revoke-MgUserSignInSession) and reset credentials for any user identity modified or leveraged during suspicious activity.

Preventive Hardening Guidelines

To build strategic resilience against cloud application identity compromises, MSPs must implement structural hardening controls in Entra ID:

  1. Implement Application Management Policies: Enforce Entra ID application management policies that restrict or block the creation of self-signed client secrets on app registrations and cap maximum credential lifetimes (e.g., limiting secret duration to 6 or 12 months).
  2. Enforce Least-Privilege RBAC Assignment: Strictly limit the assignment of Application Administrator and Cloud Application Administrator directory roles. Users holding these roles can add client secrets to existing applications and grant permissions, making them high-value targets for privilege escalation.
  3. Deploy Identity Protection for Workload Identities: Where licensed, deploy Microsoft Entra ID Protection for Workload Identities. This service continuously monitors service principal sign-in behaviors, flagging anomalous source locations, suspicious user-agents, and offline risk indicators associated with non-human identities.

With persistence eradicated and preventive hardening controls established, response teams can transition to multi-tenant operational coordination and vendor reporting protocols.

Multi-Tenant Operational Management, Communications, and Restoration Protocol

Managing an application identity compromise across a multi-tenant MSP estate presents complex operational coordination challenges. Security teams must maintain precise communication across internal engineering groups, end-customer stakeholders, and external channel partners.

Reseller & Customer Coordination Mandate

When an MSP manages client tenants under reseller, distributor, or cloud marketplace arrangements, administrative authority is frequently distributed across multiple organizations. The MSP must establish protocols to ensure technical advisories, containment steps, and tenant audit directives reach the specific primary administrator responsible for each client environment. If the MSP does not possess direct administrative rights over a downstream tenant, responders must immediately coordinate with the client's designated internal IT staff or co-managed security provider to confirm that containment and identity reviews are executed without delay.

Vendor Escalation & Incident Reporting Protocol

If responders detect confirmed indicators of compromise, unauthorized service principal credentials, or suspicious authentication events involving vendor application identities, they must escalate the findings to the vendor security team immediately.

  • Reporting Destination: Email findings directly to SecurityPartnerSupport@ConnectWise.com.
  • Mandatory Technical Metadata: Every incident escalation report must contain the following discrete data fields:
  1. Affected Microsoft 365 Tenant ID.
  2. Affected Application Client ID and local service principal Object ID.
  3. Exact UTC Timestamps (including explicit timezone designators).
  4. Specific Event IDs and Correlation IDs associated with audit and sign-in entries.
  5. A detailed narrative description of the observed suspicious activity.
  • Security Exclusions & Data Protection Mandate: Under no circumstances should escalation emails contain sensitive credentials. Strictly forbid the transmission of user passwords, private keys, client secret values, active access tokens, or sensitive Personally Identifiable Information (PII).

Safe Service Restoration & Backup Gap Quantification Workflow

Restoring backup and management services following a vendor-level suspension requires a controlled operational workflow:

[Safe Service Restoration Workflow]
1. Verify Clean Forensic State (Complete 6-domain audit; verify zero secondary IoCs)
2. Quantify Backup Protection Gap (Calculate unbacked-up delta window Oct 17 -> Present)
3. Await Formal Vendor Authorization (Verify Trust Center clearance & official instructions)
4. Execute Reconnection / Reauthorization (Follow vendor re-consent & linking steps)
5. Validate Workloads & Reschedule Jobs (Trigger manual snapshots; confirm job completion)
  1. Forensic Baseline Verification: Confirm that deep-dive threat hunting checklists are fully completed and verified clean across all managed customer tenants. Ensure no unauthorized secrets, roles, or mailbox rules remain.
  2. Quantify Backup Protection Gap: Calculate the exact "backup protection gap" — the unbacked-up delta window between the October 17 service suspension and final service restoration. Prioritize high-risk, business-critical workloads (e.g., executive mailboxes, legal repositories, core SharePoint sites) for immediate manual baseline snapshots upon service reconnect.
  3. Await Formal Vendor Authorization: Do not attempt to re-enable disabled enterprise applications or reconnect backup services until ConnectWise officially issues formal restoration instructions via their official Trust Center (https://www.connectwise.com/company/trust/advisories).
  4. Execute Authorized Reconnection Steps: Follow official vendor reauthorization procedures. If required, re-establish application consent grants and tenant connections using fresh, newly issued application credentials.
  5. Workload Operational Validation: Upon re-establishing service connections, immediately verify that protected client workloads (Exchange, Teams, SharePoint, OneDrive) are actively communicating and validate that scheduled backup jobs execute and complete successfully.

Need Help?

The functionality discussed in this post, and so much more, are available via the SOCFortress platform. Let SOCFortress help you and your team keep your infrastructure secure.

SOCFortress Signals: https://signals.socfortress.co/

Website: https://www.socfortress.co/

Contact Us: https://www.socfortress.co/contact_form.html