Add new Yandex module: Yandex Browser DPAPI credential extraction

[pavelpashka1]

Description

• Adds a new yandex module that extracts saved passwords from Yandex Browser by decrypting DPAPI-protected encryption keys and the Ya Passman Data database

• Default mode decrypts the authenticated user's passwords; two extended modes allow attacking other users:

  • LSASS mode: dumps lsass via lsassy to obtain credentials for users with active sessions (domain + local)
  • BACKUPKEY mode: uses the DPAPI Domain Backup Key to decrypt any domain user's masterkeys (requires DA)

• Yandex Browser uses a custom encryption layer on top of Chromium's standard DPAPI scheme, which is not covered by existing modules or --dpapi

This PR was created with the assistance of AI Claude Code (Opus 4.6). The AI was used for code review, refactoring to match NetExec coding conventions. The core logic was developed and tested manually on real targets.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Deprecation of feature or functionality
• This change requires a documentation update
• This requires a third party update (such as Impacket, Dploot, lsassy, etc)
• This PR was created with the assistance of AI (list what type of assistance, tool(s)/model(s) in the description)

Setup guide for the review

Lab GOAD, host - CASTELBLACK with Yandex Browser and saved passwords without using a master password, DC - Winterfell

Screenshots:

Module --dpapi:

Module yandex default usage:

Module yandex via lsass dump :

Module yandex via backupkey dump:

Module yandex via backupkey file:

Checklist:

• I have ran Ruff against my changes (poetry: poetry run ruff check ., use --fix to automatically fix what it can)
• I have added or updated the tests/e2e_commands.txt file if necessary (new modules or features are required to be added to the e2e tests)
• If reliant on changes of third party dependencies, such as Impacket, dploot, lsassy, etc, I have linked the relevant PRs in those projects
• I have linked relevant sources that describes the added technique (blog posts, documentation, etc)
• I have performed a self-review of my own code (not an AI review)
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (PR here: https://github.com/Pennyw0rth/NetExec-Wiki)

[NeffIsBack]

Hi and thanks for the PR.

Unfortunately, this is duplicate to #814. Besides, this is also duplicate to the lsassy module and dpapi decryption/key recovery etc should be done with dploot.

[pavelpashka1]

Hi and thanks for the PR.

Unfortunately, this is duplicate to #814. Besides, this is also duplicate to the lsassy module and dpapi decryption/key recovery etc should be done with dploot.

Hello, thank you! @NeffIsBack

I saw this PR. Unfortunately, it is not working and has limited functionality.
Using lsassy here is necessary to extend the ability to retrieve passwords of other users (the module you are referring to does not have this functionality).

Also, dploot worked poorly and unstably, so it was decided to use impacket instead. Since impacket is already listed as a dependency of netexec, I don't see any contradiction here.

[NeffIsBack]

Hi and thanks for the PR.
Unfortunately, this is duplicate to #814. Besides, this is also duplicate to the lsassy module and dpapi decryption/key recovery etc should be done with dploot.

Hello, thank you! @NeffIsBack

I saw this PR. Unfortunately, it is not working and has limited functionality. Using lsassy here is necessary to extend the ability to retrieve passwords of other users (the module you are referring to does not have this functionality).

What exactly does not work? It doesn't export any credentials from yandex?

Lsassy is caught be pretty much any AV out there and would add another layer of abstraction that need to work in order to extract anything. You could still execute lsassy on its own and then use the dumped credentials for looting the target.

Also, dploot worked poorly and unstably, so it was decided to use impacket instead. Since impacket is already listed as a dependency of netexec, I don't see any contradiction here.

What exactly was poor and unstable? So far we are using dploot a lot in NetExec and that would be an easy way to abstract the dpapi decryption and master key collection etc. If there are bugs we should rather fix them instead of implementing everything manually.

[pavelpashka1]

Hi and thanks for the PR.
Unfortunately, this is duplicate to #814. Besides, this is also duplicate to the lsassy module and dpapi decryption/key recovery etc should be done with dploot.

Hello, thank you! @NeffIsBack
I saw this PR. Unfortunately, it is not working and has limited functionality. Using lsassy here is necessary to extend the ability to retrieve passwords of other users (the module you are referring to does not have this functionality).

What exactly does not work? It doesn't export any credentials from yandex?

Lsassy is caught be pretty much any AV out there and would add another layer of abstraction that need to work in order to extract anything. You could still execute lsassy on its own and then use the dumped credentials for looting the target.

Also, dploot worked poorly and unstably, so it was decided to use impacket instead. Since impacket is already listed as a dependency of netexec, I don't see any contradiction here.

What exactly was poor and unstable? So far we are using dploot a lot in NetExec and that would be an easy way to abstract the dpapi decryption and master key collection etc. If there are bugs we should rather fix them instead of implementing everything manually.

@NeffIsBack thanks for the feedback!
Regarding #814: When I tested that module, it failed with errors that appeared to be related to code structure/compatibility issues with the current NetExec codebase.
Beyond that, the core issue is that it doesn't handle the Ya Passman encryption layer that Yandex Browser applies on top of the standard Chromium DPAPI scheme — which is why it can't actually decrypt saved passwords.

Regarding lsassy and AV:
Agreed, lsassy is detected by most AVs. However, this is an optional mode, not the default behavior — the module works without lsassy out of the box. The LSASS and BACKUPKEY modes exist to unlock the ability to extract credentials of other users on the system, which is a fundamentally different capability. And in practice, not all infrastructures have properly configured AV — real-world engagements confirm this regularly.

Regarding dploot:
If using dploot instead of impacket's DPAPI implementation is a hard requirement for the project, I'm open to reworking the module to use it.

[Dfte]

Hi! Honestly I'd say that yes, it's better to implement that into dploot because it does all that DPAPI related stuffs you need to decrypt stored passwords. We try having dedicated tools for specific actions (dploot, lsassy). Those allow us not having to hack NXC's code too much and offload the work we have to do :)

[pavelpashka1]

@Dfte @NeffIsBack Hi!
I refactored the code to depend on dptool and completely removed dpapi.py from Impacket.
I tested it in the lab — everything still works!

[pavelpashka1]

@NeffIsBack @Dfte
Hello! Please take a look at my revised code and share your verdicts

[NeffIsBack]

Hi, we do see your pings, we most often don't have the time to responds immediately :)

So, I still don't see the reason why we should also execute lsassy and I also don't see why this is not duplicate to #814. From what I can tell it is pretty much the same or at least very similar code.

[pavelpashka1]

@NeffIsBack
Hello,
As I mentioned earlier, using the lsassy module in this case significantly extends its functionality. By dumping hashes in SHA-1 format extracted from the lsass process, it becomes possible to decrypt passwords stored in other users’ browsers. Most importantly, running lsassy in this case is an optional feature and is not used by default.
The PR you are referring to does not provide such flexible and powerful functionality, and the code itself is not working. Here is an example of the error that occurs when using that module:

[-] Failed loading module at /root/.local/share/pipx/venvs/netexec/lib/python3.13/site-packages/nxc/modules/yandexpr814.py: type object 'NXCModule' has no attribute 'category'

I kindly ask you to carefully read the module description again, specifically the LSASS mode and BACKUPKEY mode, which are optional but very important.

[NeffIsBack]

So for some reason #814 was closed so we will go forward with this PR. However, running lsassy should not be part of this module. It is already a standalone module and will pretty much eliminate this module for pentesting since any modern AV will detect lsassy.

[NeffIsBack]

Actually, I wonder if we shouldn't just integrate this into dploot and use all of its existing automation (e.g. retrieving the backup key, decrypting blobs etc.) since this is classic dpapi decryption stuff. Thoughts @zblurx?

[zblurx]

Actually, I wonder if we shouldn't just integrate this into dploot and use all of its existing automation (e.g. retrieving the backup key, decrypting blobs etc.) since this is classic dpapi decryption stuff. Thoughts @zblurx?

I agree. Also I'm currently preparing a new big release for dploot (coming soon) with multi protocol support (smb, wmi, winrm eventually). This would allow Yandex triage to be implemented over multiple network protocol at the same time.

[NeffIsBack]

Actually, I wonder if we shouldn't just integrate this into dploot and use all of its existing automation (e.g. retrieving the backup key, decrypting blobs etc.) since this is classic dpapi decryption stuff. Thoughts @zblurx?

I agree. Also I'm currently preparing a new big release for dploot (coming soon) with multi protocol support (smb, wmi, winrm eventually). This would allow Yandex triage to be implemented over multiple network protocol at the same time.

Nice ok!

[pavelpashka1]

@NeffIsBack @Dfte @zblurx

Not a duplicate / not covered by --dpapi.
dploot's BrowserTriage only handles Chrome/Edge/Brave. Yandex stores passwords in a different format (Ya Passman Data) with an extra encryption layer on top of the standard Chromium scheme, so --dpapi simply can't decrypt Yandex passwords today. That custom Yandex layer is the only thing this module implements.

On lsassy.
It's off by default and optional. It's useful when you have local admin on the host but no DA / no domain backup key: dumping lsass yields creds for other users with active sessions (domain and local), which lets us decrypt those users' masterkeys and read their Yandex passwords too. If you'd rather not bundle lsassy here, I can drop it and keep the PR scoped to the default + backupkey paths.

Re #814:
it doesn't run — it fails to load with 'NXCModule' has no attribute 'category' — and only covers the default-user case.

So I just want to align on what you'd like from me to get this into main: do you want the full module as-is, the module minus lsassy, or only the Yandex decryption part folded in somewhere else? Happy to refactor whichever way you prefer.

[AndreySolod]

Hello.
I accidentally found this PR, and I’d like to note the following point: in fact, Yandex Browser stores passwords in exactly the same way as Chrome, Edge, etc. It’s just that the password storage is called "Ya Passman Data". Try modifying dploot so that it retrieves passwords not only from the standard paths but also from Ya Passman Data.
I implemented this in my private fork of DonPAPI, and everything worked for me. So it seems to me that in this case there’s too much unnecessary code.

[NeffIsBack]

I accidentally found this PR, and I’d like to note the following point: in fact, Yandex Browser stores passwords in exactly the same way as Chrome, Edge, etc. It’s just that the password storage is called "Ya Passman Data". Try modifying dploot so that it retrieves passwords not only from the standard paths but also from Ya Passman Data.

Yeah since it is simply dpapi this will directly be integrated into dploot and extracted with the same run as chrome etc. since we can use the existing infrastructure of dploot instead of having to do this manually. E.g. with that we have permanently stored backup keys that can be retrieved from the nxcdb, all the crypto operations etc. See zblurx/dploot#47