Security assessment on your own hardware

See what an attacker can reach.

MagenX assesses the infrastructure you already run: Active Directory, the firewall, the network and your cloud identity. It turns what it reads into the routes an attacker could actually take, ranked, with the one change that closes the most of them.

Active Directory Users, groups, GPOs, delegation, Kerberos and the ACLs that quietly grant privilege.
Firewall FortiGate policy read through FortiManager and evaluated the way FortiOS evaluates it, so exposure is measured rather than assumed.
Network Every host that answers, including the ones no team owns and the ones nobody patches.
Cloud identity Entra ID roles, conditional access and the hybrid accounts that bridge both sides.

The platform

Four layers, read separately and correlated into one graph.

Each layer is read with credentials you already have. Everything they find flows into the correlation engine, which is the only part that can tell you a medium finding is actually your fastest route to Domain Admin.

ACTIVE DIRECTORY Privilege, and every path to it NETWORK What is out there, and what nobody owns FIREWALL · FORTIGATE Whether anything can reach it CLOUD IDENTITY The same people, on the other side CORRELATION joins them on shared identities and addresses ATTACK GRAPH every route that actually resolves CROWN JEWELS and everything that can reach them CHANGE HISTORY what moved since the last scan
Each layer is read on its own. The correlation joins them on the identities and addresses they share, which is where a medium finding turns out to be the first step of a route.

Active Directory

Delegation, nested groups, certificate templates and the ACLs that quietly re-grant themselves.

AdminSDHolder · cPassword · Domain Root ACLs · Kerberoasting

Network

Where things actually are, which of them nobody owns or patches, and whether each one is carrying an agent.

Ghost Hosts · Shadow IT · EOL Systems · EDR Coverage · Unmanaged Subnets

Firewall FortiGate

FortiGate policy, read through FortiManager and evaluated the way FortiOS evaluates it: first match in sequence order on the interface pair, address objects and VIPs included. The destination's own host firewall is consulted as the last hop.

Any-Any Rules · Shadowed Policy · VIP Exposure · WAF Bypass · DMZ to LAN

Cloud identity

Entra ID roles and the hybrid accounts that bridge both sides, merged before correlation.

Global Admins · MFA Gaps · Stale Guests · Hybrid Identity

Correlation

A low finding, four steps from Domain Admin.

Every step below is an ordinary finding. Three of them would be triaged as low or medium on their own. Read in order they are one route, and a list of findings cannot show the order.

LOW MEDIUM HIGH CRITICAL SMBv1 reachable · policy 118 GenericWrite by SRV-APP-04$ sIDHistory write · T1134.005 WKSTN-1042 foothold · user VLAN SRV-APP-04 Server 2012 R2 · end of life a.reyes user object in OU=Finance Domain Admins membership unchanged cut this edge → the route stops resolving host or account unsupported or stale privileged target the edge to cut
  1. Low

    SMBv1 on a server nobody owns

    A 2012 R2 box still answering SMBv1 on an unmanaged subnet. Out of support, out of the asset register, and reachable from the user VLAN because one firewall rule was written broadly.

  2. Medium

    Its machine account can write to AD

    An old delegation left that machine account write access to attributes on a set of user objects. Nobody remembers granting it; nothing has removed it.

  3. High

    Writable attributes include SID History

    Write access to sIDHistory means an account can be handed the security identifier of a privileged group without ever joining it. Membership reports stay clean. The token does not.

  4. Critical

    Domain Admin, without a membership change

    The account now authenticates with Domain Admin rights. No group was modified, so nothing in a membership audit fires. MagenX flags the route, names the single edge that breaks it, and tells you which one to cut.

Asset discovery

The machines nobody told you about.

MagenX compares what actually answers on the network against what Active Directory, the endpoint consoles, DNS and the DHCP servers believe exists, and keeps one row per device across sweeps, so a laptop on a new lease is not a new machine and a stranger at a server's address is. The gap between those two lists is where the trouble lives: hosts that were never joined, hosts that were joined and forgotten, hosts whose account was disabled while the machine kept running, and hosts on something nobody has patched in a decade.

Discovery sweep

NOT IN AD DISABLED STALE MANAGED UNMANAGED HOST FOUND hostLAB-SRV-02 osWindows Server 2008 R2 addr10.20.40.62 siteBranch-Austin · lab rack adno directory record wanpublished :3389
Distance from the centre is distance from being managed. The sweep lights each host as it reaches it; when it reaches one with no owner, it reads whatever the host will tell it.

  • 412 joined and current

    LAPS in place, patched, seen on the network this week

  • 37 joined but stale

    In the directory, but no logon in 90 days, or no LAPS password at all

  • 6 disabled, still answering

    Disabled in the directory, but the machine is still answering. Nobody switched it off

  • 9 answering, not in AD

    Never joined, or removed from the directory and left running

Found on the last sweep

LAB-SRV-02

Operating system
Windows Server 2008 R2, end of life since 2020
Directory record
None. It answers, but Active Directory has never heard of it.
Site
Branch-Austin, on 10.20.40.0/24, the lab subnet, owned by no team in the asset register. The firewall places it, because Active Directory cannot: with no object and no site mapping for that subnet, the directory has nothing to place.
Reachable from
The internet. A firewall VIP publishes 3389 to it, on a rule written for a project that finished.
Seen before
Third sweep at this address, with the same self-issued certificate each time, so it is the same device and not a replacement.
Endpoint agent
None. The console lists nothing at this address, and a name-only match is refused.

On its own this is an inventory gap. Crossed with the firewall read it becomes the cheapest way into the estate: an unpatched box, on a network nobody watches, that the internet can open a session to.

An expanded MagenX finding for Kerberoastable service accounts: the risk explanation and its exposure path, the MITRE technique, a remediation paragraph, and the evidence table listing six service accounts with their SPNs, password age, privilege flags and last password set date.
One finding, expanded: why it matters, the MITRE technique, the fix, and every object behind the number.

Findings and follow-up

Every finding gets an owner, a date and a closing condition.

Every finding carries its evidence, its technique and a fix you can read first, and a link of its own that survives the next scan. Then it gets an owner, a date and a closing condition, so the list shrinks between scans instead of being re-read at the next one. Every host has one page, with every layer's answer about it and the first moves an attacker would try.

The MagenX follow-up page: five tasks, each showing the finding, the group and person it is assigned to, whether it is a fix, a review or a removal, its due date, and whether it is still open or done.
Follow-ups: who owns it, what kind of work it is, when it is due, and where it has got to.

Follow-up flow

MAGENX reads, scores, verifies THE OWNER a person or a group 1 · RAISED 2 · ASSIGNED 3 · FIXED 4 · SCANNED 5 · STATUS 6 · CLOSED still present, so it stays on the follow-up Finding raised evidence and MITRE Owner & Due Date mailed on assignment Fixed by the owner Next scan runs on your schedule Finding status fixed, or still present Closed verified, it is fixed
Raising a finding puts it on someone's follow-up. It closes when the next scan finds the object fixed. While it is still present, the task stays on the list.

Evidence

Every object behind the number, sorted as the collector saw it.

Owners and dates

A person or a group, a due date only an administrator can move, and one mail on assignment.

Remediation

The owner fixes the object in the estate. MagenX reads the result; it does not make the change.

Closing condition

Gone from the next scan closes it, and so does the setting that raised it changing. Still present and it stays open, with a count of how many of its objects did clear.

Change reports

What changed, when, and who did it.

Scheduled scans build an append-only change history. It rides the scans you already run, so the granularity of your history is simply how often you scan, with nothing extra to deploy.

Change history example, between two scheduled scans
  • High
    Added to Domain Adminssvc_orchestrator, not present in the previous scan
  • Medium
    New computer joinedLEGACYAPP02, created by a user account rather than a build service
  • Medium
    Delegation addedwrite access granted on an OU that holds privileged accounts
  • Resolved
    Unconstrained delegation removedcloses the follow-up raised on the previous scan
  • Low
    Host stopped answeringDENVER07, last seen on the previous scan

Reviewed and it stays reviewed

Mark a change as reviewed and it stays marked, keyed to the change itself rather than to a row number that the next scan will renumber.

Who the directory recorded

For a computer join the directory records the creator, so the report names them. Where the directory does not record an actor, the report says so instead of guessing.

Between two scans

A change is known to have happened between two scans. The report presents it that way, because claiming a timestamp the source never recorded would be a lie with a clock on it.

Retention you set

Change events keep for as long as you say, a year by default or forever, independently of how long you keep whole scans.

Deployment

Your estate never leaves the building.

One installer, one database and one service, running on hardware you control. That is the only arrangement under which some of our customers are permitted to be assessed at all.

One installer

A single signed executable installs the API, the worker, the schema and the dashboard. Upgrades preserve your data, your licence and your history.

Read-only collection

Collectors read. They do not write, disable, reset or quarantine any object. Active discovery is a separate step and remains disabled unless it is enabled explicitly.

Key custody

Keys are wrapped to the machine and backed by the TPM where one is available.

Identity provider

SAML single sign-on scoped to your email domains, role-based access control, and an audit record of every action taken and every message sent.

No egress required

Air-gapped installation is a supported configuration. Licences verify offline, on the machine, and nothing is sent anywhere unless you configure it.

Integrations, outbound only

A webhook, Microsoft Sentinel, Splunk, Jira and ServiceNow, each off until you enable it. MagenX sends and never listens, and a ticket it opens is never updated by it afterwards.

A model that explains, and never decides

Every verdict is computed from collected facts. A local model, if you run one, explains the verdict it is handed and cites only the evidence it was given. A citation that is not in the evidence is dropped, and a disagreement is shown as a note that is never applied.

On a schedule

Nightly, weekly or twice daily. Change reports are produced from the scans already scheduled, so the resolution of the history matches the scan interval.

Licensing

Every licence runs the whole platform. The only variable is how many domains it reads.

Every licence installs on your own hardware, runs every module and withholds nothing. The only difference between them is how much of the estate they read.

Single domain

one Active Directory domain

  • Active Directory, network, firewall and cloud identity
  • Correlation, attack simulation and crown jewels
  • Asset discovery, follow-ups and reports
  • One estate score, and every finding behind it
Get a demo

Two domains

two domains, read in one pass

  • Everything in Single domain, across both
  • Cross-domain correlation: one principal, not two
  • Trust paths and routes that cross the boundary
  • Per-domain scores as well as an estate score
Get a demo

Multiple domains

a forest, or several

  • Everything in Two domains, across all of them
  • Every domain merged into one graph
  • Attack simulation at estate scale
  • Priced as one estate, not per licence
Get a demo

Get a demo

Request a demonstration.

The details provided are used solely to arrange the demonstration.