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 screenshot
AtomLdr.dll's Import Address TablePayloadBuilder.exe, to encrypt demon[111].bin - a Havoc payload file
AtomLdr.dll using rundll32.exe
CMLoot was created to easily find interesting files stored on System Center Configuration Manager (SCCM/CM) SMB shares. The shares are used for distributing software to Windows clients in Windows enterprise environments and can contains scripts/configuration files with passwords, certificates (pfx), etc. Most SCCM deployments are configured to allow all users to read the files on the shares, sometimes it is limited to computer accounts.
The Content Library of SCCM/CM have a "complex" (annoying) file structure which CMLoot will untangle for you: https://techcommunity.microsoft.com/t5/configuration-manager-archive/understanding-the-configuration-manager-content-library/ba-p/273349
Essentially the DataLib folder contains .INI files, the .INI file are named the original filename + .INI. The .INI file contains a hash of the file, and the file itself is stored in the FileLib in format of <folder name: 4 first chars of the hash>\fullhash.
It is possible to apply Access control to packages in CM. This however only protects the folder for the file descriptor (DataLib), not the actual file itself. CMLoot will during inventory record any package that it can't access (Access denied) to the file _noaccess.txt. Invoke-CMLootHunt can then use this file to enumerate the actual files that the access control is trying to protect.
Windows Defender for Endpoint (EDR) or other security mechanisms might trigger because the script parses a lot of files over SMB.
Find CM servers by searching for them in Active Directory or by fetching this reqistry key on a workstation with System Center installed:
(Get-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\SMS\DP -Name ManagementPoints).ManagementPoints
There may be multiple CM servers deployed and they can contain different files so be sure to find all of them.
Then you need to create an inventory file which is just a text file containing references to file descriptors (.INI). The following command will parse all .INI files on the SCCM server to create a list of files available.
PS> Invoke-CMLootInventory -SCCMHost sccm01.domain.local -Outfile sccmfiles.txt
Then use the inventory file created above to download files of interest:
Select files using GridView (Milage may vary with large inventory files):
PS> Invoke-CMLootDownload -InventoryFile .\sccmfiles.txt -GridSelect
Download a single file, by coping a line in the inventory text:
PS> Invoke-CMLootDownload -SingleFile \\sccm\SCCMContentLib$\DataLib\SC100001.1\x86\MigApp.xml
Download all files with a certain file extension:
PS> Invoke-CMLootDownload -InventoryFile .\sccmfiles.txt -Extension ps1
Files will by default download to CMLootOut in the folder from which you execute the script, can be changed with -OutFolder parameter. Files are saved in the format of (folder: filext)\(first 4 chars of hash>_original filename).
Hunt for files that CMLootInventory found inaccessible:
Invoke-CMLootHunt -SCCMHost sccm -NoAccessFile sccmfiles_noaccess.txt
Bulk extract MSI files:
Invoke-CMLootExtract -Path .\CMLootOut\msi
Run inventory, scanning available files:
Select files using GridSelect:
Hunt "inaccessible" files and MSI extract:
Tomas Rzepka / WithSecure
