The ICS Perimeter – A Line in the Sand

Hey all,

This is going to be a non-technical post, so if you’re looking for some sort of tool or walkthrough this post probably isn’t for you. I’m going to make an argument that the perimeter for Industrial Control Systems (ICS) is one of if not the most important security control. I understand that some might see this as antiquated way of thinking and are probably calling me a dinosaur. My response is to read below and that I think of myself more as a crustacean from the Proterozoic era looking for about tree-fiddy.

I have the opportunity to do offensive and defensive work for Critical Infrastructure. Critical Infrastructure (Utilities, Generation, Transmission, O&G, etc.) is an interesting industry from a cybersecurity standpoint. In the Enterprise space, cybersecurity is often viewed as risk mitigation. For example, our organization makes $1B dollars, the consequences of a cyber-incident is ABC, our threats are XYZ; therefore, we’re going to spend $1M dollars. Just like in the Enterprise space, Critical Infrastructure sites vastly vary in size and revenue. I’ve seen sites with one person handling all IT administration and cybersecurity to sites with large fully financed security teams. Regardless of size, staffing, and solutions implemented; Critical Infrastructure usually has one thing in common – the extreme consequence of a security incident can result in loss of life.

What is my point? Resources for cybersecurity at Critical Infrastructure can be limited while the consequences are severe. Why is that important? Well I imagine it could be overwhelming trying to secure Critical Infrastructure. Also, the next thing I’m going to say might ruffle some feathers so I wanted to give a bit of context.

The Industrial Control Systems (ICS) perimeter is one of the most important security controls when it comes to Critical Infrastructure … I can hear your collective moan from here. You say – “Nearly every security professional has adopted the ‘assume breach’ mantra, you’re taking us back years!”, my reply is to finish this paragraph. I understand why one needs to assume breach in the Enterprise space. The internet is a cesspool with exploits flying around, nasty emails, C2 traffic, etc. Enterprise infosec has to deal with thousands of end users reaching out to the internet downloading junk and having junk land in their inboxes each with an itchy trigger finger. Your perimeter will be breached and it will be breached often. However, what if I told you, that in order to breach your perimeter you had to come through one of five endpoints, welcome to Critical Infrastructure networks.


Continue reading “The ICS Perimeter – A Line in the Sand”

Schtasks without Schtasks.exe via Reflective DLL

Hey all,

I’m back from Vegas and trying to work off all those late nights and delicious beers. Before I get down to business, I want to talk about the training I attended at Black Hat. My colleague and I had the opportunity to attend SpecterOps’ Red Team Ops training and it was absolutely fantastic. I doubt any the SpecterOps crew will read my humble blog, but if for some reason you find yourself here – thank you, it was terrific.

Windows services get a lot of attention. There is a reason why PSExec is a mainstay when laterally moving – it works, it’s stable, and it brings you in on a privileged session; however, it’s noisy. So I put together a reflective DLL which accomplishes the same thing but using scheduled tasks instead, while not calling schtasks.exe. It’s a similar level of noisy, but in my opinion it’s less likely to attract attention and it’s an alternative option.

I think there are quite a few potential applications for this code. Lateral movement is one. Including persistence in your custom foothold payload without calling schtasks.exe might be another. Using it to start a SYSTEM session could also be a use case.

The code includes a reflective DLL and an Aggressor script. The Aggressor script takes care of uploading the binary and calling the DLL. The DLL creates, executes, and deletes the scheduled task. Everything is pretty commented so if you’re adverse to writing a binary you could execute a one-liner instead. **NOTE** The Aggressor script or DLL will not clean up the binary, that is on you.


You can find the code at


Once again, this is skeleton code and has the following limitations:

  • Use an IP address for remote targets and for local targets
  • If running against a local target you’ll need to be in a high integrity context