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 finds the routes an attacker could take through the directory, checks them against the firewall, and names the change that cuts 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.

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 EDR 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, matched to their on-premises accounts.

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
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.
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.
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.
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

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.

The MagenX Assets page: what the last sweep met (new, returned, present) and did not meet (not asked, off network, missing, gone), and a table with one row per device showing its name, current address, risk, endpoint agent, last logged-in user, operating system, maker, model and class. — The Assets page keeps one row per device across every sweep. Each row says what the device is, where it is now, whether an endpoint agent covers it, and who last logged in.

An expanded MagenX finding for passwords left in Group Policy Preferences files: why it matters, the MITRE technique, the remediation, the governance actions, and the evidence table naming each policy, the file, the account whose password it holds and when it last changed. — 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.

Each module page also lists the datasets it read, where each came from, and whether every read finished. A short list of findings always comes with proof that the reads behind it completed. Beside the standard score sits a second one that weighs how reachable a finding is, what privilege it leads to and how many objects it touches.

The MagenX follow-up page: a due-date change waiting for approval, a completed task waiting for confirmation, and the list of follow-ups with the finding, the person or group it is assigned to, the action, the due date, the status and the latest comment. — Follow-ups: who owns it, what kind of work it is, when it is due, and where it has got to.

Follow-up flow

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
2 days ago
Medium
New computer joinedLEGACYAPP02, created by a user account rather than a build service
2 days ago
Medium
Delegation addedwrite access granted on an OU that holds privileged accounts
4 days ago
Resolved
Unconstrained delegation removedcloses the follow-up raised on the previous scan
5 days ago
Low
Host stopped answeringDENVER07, last seen on the previous scan
6 days ago

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

Deploy it on one server inside your network.

One installer and one Windows Server virtual machine on hardware you control assess the whole estate from the inside, including networks with no route to the internet.

One installer

A single installer sets up the whole platform on one Windows Server. Upgrades keep your data, your licence and your history.

Read-only collection

MagenX reads your directory, network and firewalls and changes nothing in them. Active discovery is a separate step you switch on when you want it.

Works on an isolated network

Air-gapped estates are fully supported. The licence works offline, and every layer except Microsoft Entra ID is read from inside your network.

Your team, signed in

Single sign-on through SAML and role-based access, so every analyst, engineer and manager signs in with the account they already have and sees what their role allows.

Works with your ticketing and SOC tools

Send findings and follow-ups to Jira, ServiceNow, Microsoft Sentinel, Splunk, a webhook or a REST endpoint you define, and assignment mail through Microsoft 365. Turn on only the ones you use.

An assistant that explains

Ask the console about your scans in plain language, or have any finding explained. A local model does the explaining, sees only what the signed-in person's role allows, and the verdict itself always comes from MagenX's rules.

A scanner on every site

Download an agent from the console and install it at a branch. It enrols, takes its settings, and scans the subnets and domains it is closest to, so one scan covers every site. Agents update only when an administrator says so, and roll back if an update fails.

On a schedule

Nightly, weekly or twice daily. Every scheduled scan also produces the change report, so you see what moved since the last one.

Licensing

Every licence runs the whole platform, priced per identity.

The domains set the scope. The price follows the enabled accounts in Active Directory and Entra ID, a number you can check yourself.

Single domain

One Active Directory domain

Priced by its identities, billed annually.

Active Directory and Entra ID
Network and firewall policy
Asset discovery
Reports and change history
Follow-ups and integrations
Cross-domain correlation (not included)
Three or more domains (not included)

Get started

Two domains

Two domains, read in one pass

Priced by the identities across both, billed annually.