Thursday, November 29, 2018

AWS EC2 instance userData

In the effort to get me blogging again I'll be doing a few short posts to get the juices flowing (hopefully).

Today I learned about the userData instance attribute for AWS EC2.

In general I thought metadata was only things you can hit from WITHIN the instance via the metadata url:

However, if you read the link above there is an option to add metadata at boot time. 

You can also use instance metadata to access user data that you specified when launching your instance. For example, you can specify parameters for configuring your instance, or attach a simple script. 

That's interesting right?!?!  so if you have some AWS creds the easiest way to check for this (after you enumerate instance IDs) is with the aws cli.

$ aws ec2 describe-instance-attribute --attribute userData --instance-id i-0XXXXXXXX

An error occurred (InvalidInstanceID.NotFound) when calling the DescribeInstanceAttribute operation: The instance ID 'i-0XXXXXXXX' does not exist

ah crap, you need the region...

$ aws ec2 describe-instance-attribute --attribute userData --instance-id i-0XXXXXXXX --region us-west-1
    "InstanceId": "i-0XXXXXXXX",
    "UserData": {
        "Value": "bm90IHRvZGF5IElTSVMgOi0p"}

anyway that can get tedious especially if the org has a ton of things running.  This is precisely the reason @cktricky and I built weirdAAL.  Surely no one would be sticking creds into things at boot time via shell scripts :-)

The module loops trough all the regions and any instances it finds and queries for the userData attribute.  Hurray for automation.

That module is in the current version of weirdAAL. Enjoy.


Thursday, February 8, 2018

Dark Side Ops I & 2 Review

Dark Side Ops I 

 A really good overview of the class is here

I enjoyed the class. This was actually my second time taking the class and it wasn't nearly as overwhelming the 2nd time :-)

 I’ll try not to cover what is in Raphael’s article as it is still applicable and I am assuming you read it before continuing on.

I really enjoyed the VisualStudio time and building Slingshot and Throwback myself along with getting a taste for extending the  implant by adding the keylogger, mimikatz, and hashdump modules.

Windows API developers may be able to greatly extend slingshot but I don't think I have enough WinAPI kung fu to do it and there wasn’t enough setup around the “how” to consistently do it either unless you have a strong windows API background. However, one of the labs consisted of adding load and run powershell functionality which allows you to make use of the plethora of powershell code out there.

There was also a great lab where we learned how to pivot through a compromised SOHO router and the technique could also be extended for VPS or cloud providers.

Cons of the class.

The visual studio piece can get overwhelming but it definitely gives you a big taste of (Windows) implant development.  The class material are getting slightly dated in some cases.  A refresh might be helpful.  More Throwback usage & development would be fun (even as optional labs).


Lab one was getting a fresh copy of slingshot back up and running and then setting up some additional code to do a powershell web cradle to get our slingshot implant up and running on a remote host. Similar to how metasploit web delivery does things.

Lab 2 was doing some devops to set up servers, OpenVPN to tunnel traffic, and adding HTTPS to our slingshot codebase.

Lab 3 was some Initial activity labs (HTA and chrome plugin exploitation)

Lab 4 was tweaking our HTA to defeat some common detections and protections. We also worked on code to do sandbox evasions as it’s becoming more common for automated sandbox solutions to be tied to mail gateways or  just for people doing response.

Lab 5 whitelist bypassing

Lab 6 was doing some profiling via powershell and using slingshot to be able to do checks on the host

Labs 7-9 building a kernel rootkit

Lab 10 persistence via COM Hijacking and hiding our custom DLL in the registry and Lab 11 was privilege escalation via custom service.

Final Thoughts

I enjoyed the four days and felt like I learned a lot. So the TLDR is that I recommend taking the class(es).

I think the set of courses are having a bit of an identity crisis mostly due to the 2 day
format and would be a much better class as a 5 day.  It is heavy development focused meaning you
spend a lot of time in Visual Studio tweaking C code. The “operations” piece  of the course definitely
suffers a bit due to all the dev time. There was minimal talk around lateral movement and the whole
thing is entirely Windows focused so no Linux and no OSX.  A suggestion to fix the “ops” piece
would be to have a Dark Side Ops - Dev and Dark Side Ops - Operator courses where the dev one
is solely deving your implant and the Operator course would be solely using the implant you dev’d
(or was provided to you).  The Silent Break team definitely knows their stuff and a longer class
format or switch up would allow them to showcase that more efficiently.