T1505.003 Server Software Component: Web Shells

[McBeer89]

This TRR covers file-based web shells executed through IIS handler mappings on Windows.

[sludgework]

I'm not kidding when I say this.... GREAT first stab at this. The concepts get into the weeds and lots of moving parts and configurable technologies that you seem to have scoped very nicely.

I would request reviewing a few core concepts that I think either need more detail, or maybe are misleading as written.

Also, I haven't reviewed the DDMs yet for accuracy as I didn't know if implementing any of my requested changes would cause them to be updated as well. I will re-review when you update your version and look at the DDMs then.

Nice work!

[sludgework]

A table lends itself to adding line after line easily. We don't want to fall into the slippery slope of defining too many out-of-scope items (ie Linux, Apache, Commodore 64, Game Boy Color, Samsung refrigerators).

Lets keep this section to discussing what IS in the document and for important omissions (like ASP.NET Core) we can add it into the paragraph.

[McBeer89]

Understood! I was back and forth on the table, on one hand I felt it was easier to read but I see what you're saying. I also see why I can take off the Fileless/memory and non-windows stuff from the exclusions. It's kind of obvious being how different they are. I'll make a correction and try again.

[sludgework]

Suggested change

	All HTTP/HTTPS traffic destined for IIS passes through HTTP.sys, a kernel-mode
	driver that listens on configured ports (typically 80 and 443). HTTP.sys
	handles connection management, caching, and request routing. When a request
	requires application code, HTTP.sys routes it to the appropriate application
	pool based on site bindings. The Windows Process Activation Service
	(WAS) mediates between HTTP.sys and the worker process, managing application
	pool lifecycle and process activation. HTTP.sys and WAS operate at the kernel
	and system service level respectively, below the reach of most telemetry
	sources.
	All HTTP/HTTPS traffic destined for IIS passes through `HTTP.sys`, a kernel-mode
	driver that listens on configured ports (typically 80 and 443). `HTTP.sys`
	handles connection management, caching, and request routing. When a request
	requires application code, `HTTP.sys` routes it to the appropriate application
	pool based on site bindings. The Windows Process Activation Service
	(WAS) mediates between `HTTP.sys` and the worker process, managing application
	pool lifecycle and process activation. `HTTP.sys` and WAS operate at the kernel
	and system service level respectively, below the reach of most telemetry
	sources.

Adding backticks around filenames for readability

[sludgework]

Suggested change

	`IIS AppPool\DefaultAppPool`). Administrators sometimes configure pools to use
	`IIS AppPool\DefaultAppPool`). Administrators are able to configure pools to use

Removing the ambiguous sometimes verbiage

[sludgework]

Is there a source for this claim about "rarely" spawning command interpreters? May not be needed but just curious

[McBeer89]

Yeah that's basically hearsay. I probably read that it doesn't normally happen but that could not be true for any given environment. I'll remove it.

[dumpst3rfir3]

Well maybe it doesn't need to be removed? I'll defer to the other people here who are smarter than I am, but it might be a detection consideration? I could see it varying in different environments, but it might be worth investigating in your own env. how often IIS web apps are spawning command interpreters, etc.

[sludgework]

You claim:

while these are in-process operations, they do not map to Procedure B.

If procedure B is Web Shell with In-Process Execution. can you elaborate why it does not map?

[McBeer89]

Oh my lordy. I've re-read this specific thing like 6 times. I'm still not fully sure understand it. I THINK it's because #include and #echo can't execute code, they only do a specific thing and can't perform calls, executions, or queries outside of read or output a server variable for #include and #echo respectively, also there is no scripting engine running these. So basically it never hits the "execute code" part of the procedures because there's no code to execute. If it mapped to Proc B, the attacker code would be executed by a scripting engine.

SO I think maybe I just wasn't clear enough. I'll rewrite this and see what you think then.

https://learn.microsoft.com/en-us/iis/configuration/system.webserver/serversideinclude

[sludgework]

You are bringing up ASP.NET Core, but you listed this as specifically out-of-scope in the beginning of the document. Make up your mind! Pick one and stay consistent. I would recommend leaving it out-of-scope as you are correct in the scope above that ASP.NET Core uses a different execution model altogether

[sludgework]

Your say all three Procedure C variants have the same general prerequisite:

all three variants require writing a web.config to a web-accessible directory.

That's technically true, but it glosses over the fact that the custom handler mapping variant has a stricter write location requirement than the other two. The inline handler variant and pre-compiled DLL variant can work from a subdirectory web.config (assuming system.webServer/handlers is unlocked or the attacker uses system.web/httpHandlers (see the Integrated mode topic I raised earlier)). The custom handler mapping variant requires the application root.

If a Red Team operator had to implement this procedure, it would help if they could differentiate the write location prerequisite across the three variants. Specifically, calling out that the custom handler mapping variant requires application-root-level web.config access, not just any web-accessible directory.

[dumpst3rfir3]

Great work! Lots of great details. I didn't have too much to add to what has been said, and I saw that @sludgework had a lot of feedback on the procedures, so I didn't review those yet (I'll wait for the updated version). Looking forward to the revised draft!

[dumpst3rfir3]

Very nit-picky comment here, but maybe it's worth clarifying that it's included, but not enabled, by default in Win Server?

[McBeer89]

Nit-picky is what refines these things, right? That's a fair point, thanks!

[dumpst3rfir3]

Well maybe it doesn't need to be removed? I'll defer to the other people here who are smarter than I am, but it might be a detection consideration? I could see it varying in different environments, but it might be worth investigating in your own env. how often IIS web apps are spawning command interpreters, etc.

[mjwhitta]

This is really nice! I have some little things, most of which are unicode related, but I will let @vanvleeta be the decision maker on unicode in TRRs.

[McBeer89]

Okay! Thank you everyone! I appreciate the feedback. I think I have addressed everything. Looking forward to more review.