Invoke-IR/ACE

start.sh not building the dockerfiles

voilaviola opened this issue · 11 comments

voilaviola commented

Hi,
I'm testing ACE on a CentOS7 VM hosted on ESXi. I deployed ACE with the following process:

  1. Install docker and necessary dependencies with yum install
  2. Install docker-compose and run docker
  3. Install nginx
  4. Install ACE:
    image
  5. In ace.env: change WEBSERVER_IP with the ip of my CentOS VM
  6. ./start.sh

I've encountered a connection problem when trying to access ACE web interface from my windows PC which is in the same subnetwork with CentOS. By browsering to https://IP_OF_CentOS, I'm getting the error 113: no route to host in "docker-compose logs".
I've added a firewall rule in CentOS "
image
", bus it wasn't of help.

Another issue I found is that line 203 in start.sh (docker-compose build) is not building dockerfiles in containers, for example it cannot copy nginx.conf to the nginx directory as supposed. A not-so-good solution I found is to launch docker build for every dockerfile. I believe it is a issue of docker itself, please refer to: docker/compose#3148

Please tell me if I've missed some important deploying step, because there are things that I'm not sure about, such as the right WEBSERVICE_IP and the subnet docker0.

Thanks in advance,

jaredcatkinson commented

This is good feedback. I have only tested the start.sh script on Ubuntu 14.04, so I don't know the exact fix for the firewall issue. Did you start the actual web service on a Windows machine? The nginx docker image (running on Linux) is forwarding all requests to the web service which should be running on Windows (the IP of the Windows system should be the WEBSERVICE_IP).

You are right that the docker build command doesn't do anything since the docker-compose.yml file is referencing the prebuilt images hosted on docker hub. It would probably be find to just remove that line.

jaredcatkinson commented

I've been working on a video to show how to setup ACE given the current configuration. I plan on adding a narration next week, but in the mean time it might help you with the setup, so I posted it on YouTube https://youtu.be/opDVhghrE0A.

jaredcatkinson commented

The WEBSERVICE_IP environment variable should be set to the Windows host, not the Linux Docker host. There may be things we can do in the future that would remove the need for the Windows host, but the amount of effort for that is quite large, so it hasn't made it onto my list yet.

voilaviola commented

Hi Jared,
Thanks a lot for the video, it is really helpful. I'll test the configuration and let you know my updates.
I agree that it would be perfect to remove the windows host part, since for example the windows host on which we manipulate might be an adm PC of a client, and we cannot deploy PS scripts on it.

jaredcatkinson commented

Good point. In general, I've operated under the assumption that you control the machines that ACE is running on. I think this is the best option since you are using ACE to audit an environment, so you generally don't want to do the auditing from the subject itself. That being said, I am also a consultant and understand that the best case is not always an option.

Regarding the scripts that you use, there are some kind of weird rules for how you output your results. I've attached a simple test script that will help you validate that everything is working as expected. Generally speaking, the output must be in a hashtable and all values must be a basic type (think string, int, etc.). This is to support running scripts on PSv2 where the ConvertTo-Json function doesn't exist. We are using the .NET Json Serializer, but it doesn't understand how to deal with custom data types.
Get-ProcessTest.txt
^ Github apparently doesn't like to attache .ps1 files, so I renamed it as .txt. It is intended to be a PowerShell script or .ps1.

voilaviola commented

Hi Jared,
Thanks again for the script. I followed the instructions in your video, and got ACE up and running(I assume:) ). However, you might have missed the import cmdlet part so from 2:14 of the video ($cred = New-AceCredential @settings -Credential tester), it doesn't work.
Here's a solution I found, not sure whether it's correct or not:

  1. Copy https://github.com/Invoke-IR/ACE/tree/master/ACE-Management/PS-ACE to my local ACE folder
  2. Add the PS-ACE folder to PSModulePath
  3. import-module /PS-ACE
    Now I've got cmdlets running. But I'm not able to access to http://localhost:5000 by browser, and my AceWebService.dll seems to have error reports:
    image
    image

At 2:37 (Start-AceDiscovery @settings -CredentialId $cred.id -ComputerName 192.168.92.179), I suppose the 92.179 is a PC to investigate? so I guess the $cred might be the username of this PC, or a domain adm.
Could you please also give an example of Get-SOHostData.ps1 that you used in 3:01?

Thanks in advance,

jaredcatkinson commented

Good point on loading the module! I will include that in the video.

You should be able to access the web service on port 80 just browse to http://localhost:5000/index.html. You can also access it through the Linux machine on port 443 (this would be proxied through the Nginx image).

Yes, 179 is the endpoint you wish to scan. This can be a hostname (presuming DNS) or IP Address.

I’m away from my computer right now, but I will post a link to Get-SOHostData when I return. What script did you use?

voilaviola commented

Hi Jared,
Thanks for your response! I've launched the web service and I got this page from the Windows host:
capture
Is this correct? I also got the RabbitMQ interface from Linux host.
I haven't yet test any script, because the endpoint I want to scan is a Linux. I suppose it should be a python script?

zippydude commented

It seems like Start-AceScript.ps1 and the sample scripts have a lot of the same features, for instance they both collect the FQDN of the system and several other host attributes in the exact same fashion. It also looks like there's some debug code left at the bottom of all the sample scripts as well with a hardcoded Thumbprint and Uri.

I'm able to get tasks to be distributed through WinRM, but it seems like the second stage script chokes no matter what changes I make, or how I modify the sample scripts or the Start-AceScript wrappe scriptr. Any chance you can upload the Get-SOHostData.ps1 file to demonstrate how these collection scripts are supposed to be structured?

jaredcatkinson commented

Hey @voilaviola, it looks like you have things set up correctly. Most of our testing has been focused on Windows with a bit of Proof of Concept work on MacOS. In theory, it should work similarly on Linux with a python script. I'd be interested in hearing about your experience with that.

jaredcatkinson commented

@WeeSeekMeeSeeks, the Get-SOHostData.ps1 script can be found here: https://gist.github.com/jaredcatkinson/d889aaa3355f5e37cf1653f5b849da31

Let me take a look at the scripts this evening and make sure the latest version is in the repo.