Module 1.3: Management Layers: MDM, Profiles, EDR, and Policy

Operator outcome

You can separate the management layers on a corporate Mac before touching any one of them in depth. By the end of this module you will know whether the host appears enrolled, where managed preferences live, which launchd jobs look enterprise-controlled, whether System Extensions are present, and which later phase should receive the deeper work.

This is a foundation module. You are not abusing profiles, editing helpers, changing EDR state, or installing anything here. You are building the map.

Scenario

The Mac you landed on is not a standalone workstation. It is part of a control plane. That control plane may include MDM enrollment, local configuration profiles, managed preferences, launchd jobs, login items, security agents, System Extensions, Gatekeeper policy, and TCC decisions.

Students get lost when they treat those as one thing called "management." They are not one thing. Profiles can set policy. Managed preferences can land as readable files. LaunchDaemons can enforce local state. System Extensions can monitor or filter activity. TCC controls privacy grants. Gatekeeper controls assessment decisions. EDR records its own view.

The operator move is to name the layers first. Once the layers are named, later phases can test each one with evidence.

Module setup

Run this from the browser terminal on your primary Mac. The EVIDENCE directory is created by this setup block under /private/tmp; it is your temporary workspace for this module, not a preloaded course file. The course uses /private/tmp because the domain shell may not have a normal writable home directory.

EVIDENCE="/private/tmp/MRTE-management-layers"
mkdir -p "$EVIDENCE"
date -u +%Y-%m-%dT%H:%M:%SZ | tee "$EVIDENCE/start-time.txt"

Map the management layers

Enrollment and profile state

Start with enrollment. If the host is enrolled, MDM may be able to deliver profiles, restrictions, PPPC grants, certificates, VPN settings, security extensions, and application configuration.

{
  profiles status -type enrollment 2>/dev/null || true
  profiles list 2>/dev/null | head -120 || true
} | tee "$EVIDENCE/profile-state.txt"

Read this as posture, not as impact. Enrollment tells you a management channel exists. It does not tell you that a useful misconfiguration exists. Phase 3 handles profile-driven local policy and helper paths. Phase 6 handles PPPC and TCC trust.

Managed preferences

Managed preferences are often the easiest local artifact to read because they are files on disk.

{
  ls -la /Library/Managed\\ Preferences 2>/dev/null || true
  find /Library/Managed\\ Preferences -maxdepth 2 -type f 2>/dev/null | sort | head -80
} | tee "$EVIDENCE/managed-preferences.txt"

If the directory contains enterprise domains, record the names. Do not assume every key is dangerous. The first question is simpler: which local files carry policy that root-side tooling might later consume?

Launchd and helper surface

Enterprise tooling on macOS usually persists through launchd. At foundation level, capture the inventory and look for vendor or internal names.

{
  ls -la /Library/LaunchDaemons | head -120
  launchctl print system 2>/dev/null | grep -Ei "mdm|manage|profile|edr|sensor|protect|security|corp|agent" | head -120 || true
} | tee "$EVIDENCE/launchd-management.txt"

This does not establish abuse. It tells you where the enforcement layer might be. Phase 3 tests profile and helper trust paths. Phase 5 measures EDR behavior.

System Extensions and security agents

System Extensions are a strong hint that endpoint security, network filtering, content filtering, or enterprise control software is present.

{
  systemextensionsctl list 2>/dev/null || true
  ps aux | grep -Ei "edr|sensor|protect|defender|security|filter|extension" | grep -v grep | head -80 || true
} | tee "$EVIDENCE/security-extensions.txt"

For MRTE, this output tells you whether the host has security tooling worth measuring. Do not infer bypass from presence or absence. Phase 5 handles the sensor model, YARA, file integrity, process lineage, and ES pressure.

Gatekeeper, quarantine, and trust posture

Gatekeeper and quarantine affect how files are assessed when they arrive and run. Capture the top-level posture only.

{
  spctl --status 2>/dev/null || true
  defaults read com.apple.LaunchServices LSQuarantine 2>/dev/null || true
} | tee "$EVIDENCE/trust-posture.txt"

The deeper work belongs in Phase 7. Here you only need to know whether trust controls appear enabled and worth measuring later.

TCC and privacy trust pointers

Do not dump private user databases here. Foundation only confirms that TCC is part of the posture and that the later phase has a reason to exist.

{
  ls -la /Library/Application\\ Support/com.apple.TCC 2>/dev/null || true
  ps aux | grep tccd | grep -v grep || true
} | tee "$EVIDENCE/tcc-pointers.txt"

TCC is not an obstacle you guess around. It is a database and policy system you read carefully in Phase 6.

Sensor view

Read the training sensor report for this baseline window.

/usr/local/macseccorp/bin/corpedr-report --since "$EVIDENCE/start-time.txt" | tee "$EVIDENCE/corpedr-report.txt"

If the report is quiet, record that. If it is noisy, record that too. Either outcome is useful because it tells you what the range sensor saw while you performed read-only management discovery.

Operator decision

At the end of this module, do not write "MDM is vulnerable" or "EDR was bypassed." Write the map:

• Enrollment state observed or not observed.
• Managed preference domains present or absent.
• LaunchDaemons and helper names worth deeper review.
• System Extensions and security agents present or absent.
• Gatekeeper and quarantine posture captured.
• TCC storage and daemon presence confirmed.
• Sensor output for the read-only discovery window.

Then route the work:

• Profiles and helper abuse: Phase 3.
• EDR visibility and pressure: Phase 5.
• TCC and PPPC: Phase 6.
• Gatekeeper and enterprise trust: Phase 7.
• Network controls and proxy posture: Phase 9.

Evidence checklist

• start-time.txt
• profile-state.txt
• managed-preferences.txt
• launchd-management.txt
• security-extensions.txt
• trust-posture.txt
• tcc-pointers.txt
• corpedr-report.txt

Cleanup

This module changes no system configuration. If this was a practice run, remove the evidence directory after review.

rm -rf /private/tmp/MRTE-management-layers

Claim boundary

This module establishes the visible management and security layers from an unprivileged session under tested lab conditions. It does not validate exploitability, privilege escalation, EDR bypass, PPPC grants, TCC access, Gatekeeper bypass, or network egress. Those claims require the dedicated phases that follow.