Mac OSX Mojave .plist format conversion

[culdesac]

Hi

I am trying to convert a AdminUserRecoveryInfo.plist file into a hash, its taken from a Mojave OSX folder from an encrypted disk. but it seems previous tools like ml2hashcat and plist2hashcat does not work.

the file looks like this (I have masked user info and hashes with random XXXX

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>XXXX</key>
    <dict>
        <key>AuthenticationAuthority</key>
        <array>
            <string>;ShadowHash;HASHLIST:&lt;SALTED-SHA512-PBKDF2,SRP-RFC5054-4096-SHA512-PBKDF2&gt;</string>
            <string>;Kerberosv5;;XXXXXX@LKDC:SHA1.XXXX82E9D842B7B9A20D15C5F19A3E7B22351192;LKDC:SHA1.XXXX82E9D842B7B9A20D15C5F19A3E7B22351192;</string>
            <string>;SecureToken;</string>
        </array>
        <key>GeneratedUID</key>
        <string>A3B3D4F5-XXXX-4F23-8425-187C8BD2579F</string>
        <key>RealName</key>
        <string>XXXX</string>
    </dict>
</dict>
</plist>

Is it possible to convert it to a hashcat format?

thanks for help

[philsmd]

never heard about this "AuthenticationAuthority" format, hashcat officially only supports this: https://hashcat.net/forum/thread-8368-po...l#pid44680 and the itunes backups plist files.

We would need to do some more investigation to see what algorithm is behind this and would need to have some example hashes (with passwords) etc

[Banaanhangwagen]

Can you elaborate on what you are trying to do?

The file AdminUserRecoveryInfo.plist is found in /Volumes/Preboot/[UUID]/var/db, and it's not the correct file in order to extract the login-hash.
The hash you want to crack - at least i think that you want that - is stored in the [USER].plist file. You can find it in this path: /var/db/dslocal/nodes/Default/users/

[culdesac]

Karamba:That is not the case anymore. I have tried this on several new Mojave systems and the new hash version is the one above. Ps. yes, i am trying to extract the hash to recover the lost password 

Phil, if you need a separate AdminUserRecoveryInfo.plist and the two other files that are stored in the same folder CryptoUserInfo.plist and secureaccesstoken.plist in Preboot/UUID/var/db I am more than happy to supply these in order to have this hash included in hashcat future releases

The file contains the user account with a new format of hash.

I can make a file with a simple login/pw like root/root or test/test123 for login/pw

This is for both APFS systems that are encrypted and non-encrypted. The encrypted wont let you login as single user. But its possbile to extract the files by running a custom made linux and disable the read access to extract them

[philsmd]

if I understood this correctly you can access the file when mounting the file system with a different operating system ?!

I think we can't do anything about that. You can't just use a totally different file because you can't access the file needed.

My little research shows that macOS 10.14 introduced SIP (System Integrity Protection, https://apple.stackexchange.com/question...ds-located) and it seems that this system "just hides" some files.

It seems that the command

Code:

csrutil disable

is able to disable SIP in Recovery mode.

Did I understand this correctly ? are you able to access the file with SIP turned off and/or using another system (maybe not macOS) to mount these disks ?

[Banaanhangwagen]

I am confused by your explanation, culdesac. Would it be possible that you are mixing things up?
I have macOS 10.14.5 installed and the known technique to recover the user-hash is perfectly working. You just need the [user].plist file and this script for example link

The files you are referring to are not needed in order to extract the user-hash.

Can you explain what your steps are in order to extract the user-hash (which is not working for you)?
How do you proceed in your setup? Do you work with an image that you mount, or do you use a LiveUSB?
Since Mojave, Apple activated by default Filevault2 on macOS filesystem. How do you deal with this?

[culdesac]

the system is locked apfs encrypted volume, with the login lost password.

in order to get the plist, you need to boot the mac with a liveusb and mount the drive manually

you can only mount three volumes without the root/admin password to the encrypted volume, and those /var/db folders does not include the user.plist file, its only available if the volume is not encrypted or if you have at least one valid login.

[Banaanhangwagen]

I think I understand what you mean know.

You need to crack the Filevault2 encryption first. See this post.
Once you got it, you can mount the MacintoshHD partition without issues, and you'll have access to all the files.

It does not make sense to crack the user-logon afterwards, because in 99,9% of the cases it will be the same as the Filevault2 password.

[laxstor]

culdesac I was just wondering this myself.. no way for me to get the plist via /var/db/... as that returns not permitted or permission denied.

But.. in a Mac Mojave terminal as an authenticated user you can run 

Code:

dscl . read /Users/<user>/ AuthenticationAuthority

which returns something like:

Code:

AuthenticationAuthority: ;ShadowHash;HASHLIST:<SALTED-SHA512-PBKDF2,SRP-RFC5054-4096-SHA512-PBKDF2> ;Kerberosv5;;<user>@LKDC:SHA1.XXXXXXXXXD1BXXXXXX8BBB8AB086XXXXXXXXXXXX;LKDC:SHA1.XXXXXXXXXXXX3086898BBB8AB086XXXXXXXXXXXX; ;SecureToken;

At this point I'm a bit stuck, been looking through both hashcat and JTR docs/forums and haven't found a way to use this information for cracking.

[Banaanhangwagen]

culdesac I was just wondering this myself.. no way for me to get the plist via /var/db/... as that returns not permitted or permission denied.

Work with sudo in the terminal, and you won't have this problem.
Alternativly, you can change the permissions of the denied folders/files by right-click > Get Info > Permissions and putting it into Read Only.

At this point I'm a bit stuck, been looking through both hashcat and JTR docs/forums and haven't found a way to use this information for cracking.

...because it is - till further notice - not needed.