Login
V'ger is an interactive command-line application for post-exploitation of authenticated Jupyter instances with a focus on AI/ML security operations.
FreshRSS pip install vgervger --helpCurrently, vger interactive has maximum functionality, maintaining state for discovered artifacts and recurring jobs. However, most functionality is also available by-name in non-interactive format with vger <module>. List available modules with vger --help.
Once a connection is established, users drop into a nested set of menus.
The top level menu is: - Reset: Configure a different host. - Enumerate: Utilities to learn more about the host. - Exploit: Utilities to perform direct action and manipulation of the host and artifacts. - Persist: Utilities to establish persistence mechanisms. - Export: Save output to a text file. - Quit: No one likes quitters.
These menus contain the following functionality: - List modules: Identify imported modules in target notebooks to determine what libraries are available for injected code. - Inject: Execute code in the context of the selected notebook. Code can be provided in a text editor or by specifying a local .py file. Either input is processed as a string and executed in runtime of the notebook. - Backdoor: Launch a new JupyterLab instance open to 0.0.0.0, with allow-root on a user-specified port with a user-specified password. - Check History: See ipython commands recently run in the target notebook. - Run shell command: Spawn a terminal, run the command, return the output, and delete the terminal. - List dir or get file: List directories relative to the Jupyter directory. If you don't know, start with /. - Upload file: Upload file from localhost to the target. Specify paths in the same format as List dir (relative to the Jupyter directory). Provide a full path including filename and extension. - Delete file: Delete a file. Specify paths in the same format as List dir (relative to the Jupyter directory). - Find models: Find models based on common file formats. - Download models: Download discovered models. - Snoop: Monitor notebook execution and results until timeout. - Recurring jobs: Launch/Kill recurring snippets of code silently run in the target environment.
With pip install vger[ai] you'll get LLM generated summaries of notebooks in the target environment. These are meant to be rough translation for non-DS/AI folks to do quick triage of if (or which) notebooks are worth investigating further.
There was an inherent tradeoff on model size vs. ability and that's something I'll continue to tinker with, but hopefully this is helpful for some more traditional security users. I'd love to see folks start prompt injecting their notebooks ("these are not the droids you're looking for").
The full explanation what is HTML Smuggling may be found here.
The primary objective of HTML smuggling is to bypass network security controls, such as firewalls and intrusion detection systems, by disguising malicious payloads within seemingly harmless HTML and JavaScript code. By exploiting the dynamic nature of web applications, attackers can deliver malicious content to a user's browser without triggering security alerts or being detected by traditional security mechanisms. Thanks to this technique, the download of a malicious file is not displayed in any way in modern IDS solutions.
The main goal of HTMLSmuggler tool is creating an independent javascript library with embedded malicious user-defined payload. This library may be integrated into your phishing sites/email html attachments/etc. to bypass IDS and IPS system and deliver embedded payload to the target user system. An example of created javascript library may be found here.
Install yarn package manager.
Install dependencies:
yarnRead help message.
yarn build -hModify (or use my) javascript-obfuscator options in obfuscator.js, my preset is nice, but very slow.
Compile your javascript payload:
yarn build -p /path/to/payload -n file.exe -t "application/octet-stream" -cGet your payload from dist/payload.esm.js or dist/payload.umd.js. After that, it may be inserted into your page and called with download() function.
payload.esm.jsis used inimport { download } from 'payload.esm';imports (ECMAScript standart).
payload.umd.jsis used in html script SRC andrequire('payload.umd');imports (CommonJS, AMD and pure html).
A full example may be found here.
Import created script to html file (or insert it inline):
<head>
<script src="payload.umd.js"></script>
</head>Call download() function from body:
<body>
<button onclick="download()">Some phishy button</button>
</body>Happy phishing :)
A full example may be found here.
Import created script to vue file:
<script>
import { download } from './payload.esm';
</script>Call download() function:
<template>
<button @click="download()">Some phishy button</button>
</template>Happy phishing :)
Q: I have an error RangeError: Maximum call stack size exceeded, how to solve it?
A: This issue described here. To fix it, try to disable splitStrings in obfuscator.js or make smaller payload (it's recommended to use up to 2 MB payloads because of this issue).
Q: Why does my payload build so long?
A: The bigger payload you use, the longer it takes to create a JS file. To decrease time of build, try to disable splitStrings in obfuscator.js. Below is a table with estimated build times using default obfuscator.js.
| Payload size | Build time |
|---|---|
| 525 KB | 53 s |
| 1.25 MB | 8 m |
| 3.59 MB | 25 m |
A DLL Loader With Advanced Evasive Features
"Atom" function via the command line.CRC32 string hashing algorithm.AtomLdr's unhooking method looks like the following
the program Unhooking from the \KnwonDlls\ directory is not a new method to bypass user-land hooks. However, this loader tries to avoid allocating RWX memory when doing so. This was obligatory to do in KnownDllUnhook for example, where RWX permissions were needed to replace the text section of the hooked modules, and at the same time allow execution of functions within these text sections.
This was changed in this loader, where it suspends the running threads, in an attempt to block any function from being called from within the targetted text sections, thus eliminating the need of having them marked as RWX sections before unhooking, making RW permissions a possible choice.
This approach, however, created another problem; when unhooking, NtProtectVirtualMemory syscall and others were using the syscall instruction inside of ntdll.dll module, as an indirect-syscall approach. Still, as mentioned above, the unhooked modules will be marked as RW sections, making it impossible to perform indirect syscalls, because the syscall instruction that we were jumping to, can't be executed now, so we had to jump to another executable place, this is where win32u.dll was used.
win32u.dll contains some syscalls that are GUI-related functions, making it suitable to jump to instead of ntdll.dll. win32u.dll is loaded (statically), but not included in the unhooking routine, which is done to insure that win32u.dll can still execute the syscall instruction we are jumping to.
The suspended threads after that are resumed.
It is worth mentioning that this approach may not be that efficient, and can be unstable, that is due to the thread suspension trick used. However, it has been tested with multiple processes with positive results, in the meantime, if you encountered any problems, feel free to open an issue.
PayloadConfig.pc file, that contains the encrypted payload, and its encrypted key and iv.PayloadConfig.pc file will then replace this in the AtomLdr project.AtomLdr project as x64 Release.AtomLdr.dll using rundll32.exe, running Havoc payload, and capturing a screenshotAtomLdr.dll's Import Address TablePayloadBuilder.exe, to encrypt demon[111].bin - a Havoc payload fileAtomLdr.dll using rundll32.exe
