Monkey365 PowerShell Assessment for Microsoft Cloud Security

What Monkey365 Covers in Microsoft Cloud

Monkey365 addresses a specific assessment problem: reviewing configuration across Microsoft 365, Microsoft Entra ID, and Azure without manually navigating several administration portals or assembling separate Microsoft PowerShell modules. It is aimed at security professionals, consultants, administrators, and incident responders. The intended output is an assessment containing findings, supporting evidence, and remediation guidance, rather than only a raw inventory of tenant settings.

The documented service coverage includes Exchange Online, SharePoint Online, Microsoft Teams, Microsoft Purview, and Microsoft Fabric. Azure and Microsoft Entra ID are separate assessment targets, and a Microsoft 365 run can include Entra ID by setting `IncludeEntraID`. Azure Public, China, and Government cloud environments are supported according to the README.

The built-in rulesets include CIS Microsoft Azure Foundations Benchmark v6.0.0, CIS Microsoft Azure Database Services Benchmark v2.0.0, CIS Microsoft Azure Compute Services Benchmark v2.0.0, CIS Microsoft 365 Foundations Benchmark v7.0.0, and a Monkey365 ruleset for Microsoft Entra ID. A benchmark mapping connects a finding to a control, but the README explicitly warns that this mapping does not establish certification or compliance. Operators must still interpret findings against their environment and business requirements.

Collectors, Rules, and Report Data Flow

The documented processing model has three stages. Monkey365 first collects configuration data from selected cloud services. It then evaluates that data with selected rulesets. Finally, it reports findings together with evidence and remediation guidance. This separation makes the result easier to automate because collection, policy evaluation, and presentation are distinct concerns.

Collectors provide the access layer for service-specific configuration. The architecture is described as collector-based and extensible, which leaves room for additions without treating every workload as part of the central scan engine. Security rules, meanwhile, are declarative JSON files stored separately from collectors. The repository has a `rules` directory, and the documentation links to a custom checks and rulesets model. An organization-specific check can therefore be represented as configuration rather than requiring a change to the scan engine.

Authentication occurs before collection, and the services available to a scan depend on what the signed-in identity can access. The module supports interactive authentication, service principals, certificate-based authentication, and direct access-token authentication. Its runtime dependencies are bundled, so collection does not depend on Azure CLI, Az PowerShell, ExchangeOnlineManagement, or Microsoft Graph PowerShell SDK. That packaging choice does not remove Microsoft-side permission requirements. It only changes the local module dependencies.

CurrentUser Installation and First Assessment

The README directs users to install Monkey365 from the PowerShell Gallery. This first sequence installs the package for the current user and imports it into the PowerShell session. A successful import makes the module's assessment commands available to the session.

Install-Module -Name monkey365 -Scope CurrentUser
Import-Module monkey365

The documented Microsoft 365 example selects the `Microsoft365` instance, includes three workload collectors, requests account selection during sign-in, adds Microsoft Entra ID, and exports an HTML report. Running `Invoke-Monkey365` starts that assessment, but Monkey365 may prompt for sign-in when the selected authentication flow requires it.

$options = @{
    Instance       = 'Microsoft365'
    Collect        = @(
        'ExchangeOnline'
        'MicrosoftTeams'
        'SharePointOnline'
    )
    PromptBehavior = 'SelectAccount'
    IncludeEntraID = $true
    ExportTo       = 'HTML'
}

Invoke-Monkey365 @options

Readers should not expect every selected collector to return usable data without sufficient permissions. The README says available services depend on the permissions granted to the signed-in identity. Its installation guide, permissions page, and authentication overview are explicitly linked for pre-production review.

HTML, JSON, and CSV Export Choices

Monkey365 accepts one or more output formats through `-ExportTo`. The README assigns each format a distinct use. HTML is intended for interactive review of findings and evidence. JSON fits pipelines, APIs, and structured post-processing. CSV supports spreadsheet analysis and data exchange. This makes the export choice an architectural decision rather than a cosmetic preference.

HTML is the clearest option for a reviewer who needs to inspect the report with its evidence and remediation context. JSON is the better fit when another system must consume the assessment after collection. CSV is useful when findings need to enter a spreadsheet-oriented review process. The documentation also links to dedicated material on exporting results, rate limits and retries, and logging, although the excerpt does not provide their configuration examples.

The module can run on workstations or jump boxes and is described as suitable for automation pipelines and assessment environments. The top-level repository also contains a `docker/` directory, but the README excerpt does not give a Docker installation or execution command. No image name, tag, build argument, or runtime configuration should be inferred from that directory name.

Permissions, Authentication, and Cloud Boundaries

The main operational constraint is identity authorization. Monkey365 can authenticate interactively, through a service principal, with certificate-based authentication, or with a direct access token, but the identity still needs access to the services selected for collection. A syntactically valid invocation can therefore produce incomplete coverage when the account lacks the required permissions. The available service set is determined by what that identity can access.

This design creates a deliberate boundary between local installation and cloud authorization. Bundled runtime dependencies remove the need for Azure CLI, Az PowerShell, ExchangeOnlineManagement, or Microsoft Graph PowerShell SDK. They do not bypass consent, role assignment, conditional access, tenant policy, or application permissions. The README does not enumerate the minimum role set for the quick-start example, so operators must use its permissions documentation before treating the command as production-ready.

Cloud environment is another boundary. The README states support for Azure Public, China, and Government clouds, but it does not say that every collector or ruleset is equally applicable to all three. It also does not document rollback, automatic remediation, or compensation for destructive changes. Nothing in the documented assessment flow indicates that Monkey365 should be treated as an autonomous remediation system.

Alternatives and Maintenance Costs

A direct Microsoft Graph and PowerShell pipeline is a credible alternative when an organization already owns collectors, query logic, control mappings, and report processing. Monkey365 packages those activities into a self-contained assessment framework and requires the reader to configure collectors and declarative rules rather than implement the scan engine. A multi-portal manual review is another approach, but it does not naturally produce a repeatable JSON or CSV pipeline. The practical difference is workflow ownership: the custom pipeline offers control over existing code, while Monkey365 centers the work on selecting collectors and rulesets.

Monkey365 is not archived. Its last push was on 2026-09-28, and the listed releases include v1.0.0 on 2026-09-25, v0.99 on 2026-08-07, and v098.8 on 2026-08-03. These dates show recent repository and release activity. They do not establish compatibility with every Microsoft tenant, permission change, or benchmark revision.

The project uses the Apache-2.0 license. That permits use and modification under that license's terms, subject to its conditions, although this review does not provide legal advice. Upgrade work includes checking new module releases, reviewing changes to collectors and JSON rules, comparing updated CIS benchmark versions, and testing authentication and report generation in a non-production tenant. The available documentation points specifically to the `install/` and `security_checks/` documentation areas for installation and custom-check details.

Editorial conclusion

Security professionals should consider Monkey365 when they need repeatable, rule-driven assessments across several Microsoft cloud services and can provide identities with the required permissions. Organizations using an established custom Microsoft Graph pipeline may prefer to retain that approach. Before a production scan, verify the service coverage, permissions, authentication flow, report destination, and applicable CIS benchmark version.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. silverhack/monkey365 on GitHub