Hacking Articles Tips Tricks Videos Tutorials
468 subscribers
65.8K photos
15 videos
157 files
132K links
Exploit
Pentesting
Hacking
Red Team
Blue Team
Kali Linux
Bug Bounty
Black Hat
Cyber security etc

@Hacking_Video
@Hacking_attack
Download Telegram
prepareDebug = create helpful information for debugging
x86 or x64 = compile for 32-bit or 64-bit runtime only
lcid = location ID for the compiled executable. Current user culture if not specified
STA or MTA = 'Single Thread Apartment' or 'Multi Thread Apartment' mode
noConsole = the resulting executable will be a Windows Forms app without a console window
UNICODEEncoding = encode output as UNICODE in console mode
credentialGUI = use GUI for prompting credentials in console mode
iconFile = icon file name for the compiled executable
title = title information (displayed in details tab of Windows Explorer's properties dialog)
description = description info rmation (not displayed, but embedded in executable)
company = company information (not displayed, but embedded in executable)
product = product information (displayed in details tab of Windows Explorer's properties dialog)
copyright = copyright information (displayed in details tab of Windows Explorer's properties dialog)
trademark = trademark information (displayed in details tab of Windows Explorer's properties dialog)
version = version information (displayed in details tab of Windows Explorer's properties dialog)
configFile = write config file (.exe.config)
noOutput = the resulting executable will generate no standard output (includes verbose and information channel)
noError = the resulting executable will generate no error output (includes warning and debug channel)
noVisualStyles = disable visual styles for a generated windows GUI application (only with -noConsole)
requireAdmin = if UAC is enabled, compiled executable run only in elevated context (UAC dialog appears if required)
supportOS = use functions of newest Windows versions (execute [Environment]::OSVersion to see the difference)
virtualize = application virtualization is activated (forcing x86 runtime)
longPaths = enable long paths ( > 260 characters) if enabled on OS (works only with Windows 10)
A generated executable has the following reserved parameters: Extracts the powerShell script inside the executable and saves it as FILENAME. The script will not be executed. -wait At the end of the script execution it writes "Hit any key to exit..." and waits for a key to be pressed. -end All following options will be passed to the script inside the executable. All preceding options are used by the executable itself and will not be passed to the script. '>-debug Forces the executable to be debugged. It calls "System.Diagnostics.Debugger.Launch()".
-extract: Extracts the powerShell script inside the executable and saves it as FILENAME.
The script will not be executed.
-wait At the end of the script execution it writes "Hit any key to exit..." and waits for a key to be pressed.
-end All following options will be passed to the script inside the executable.
All preceding options are used by the executable itself and will not be passed to the script.

Remarks

List of cmdlets not implemented:
The basic input/output commands had to be rewritten in C# for PS2EXE. Not implemented are Write-Progress in console mode (too much work) and Start-Transcript/Stop-Transcript (no proper reference implementation by Microsoft).
GUI mode output formatting:
Per default in powershell outputs of commandlets are formatted line per line (as an array of strings). When your command generates 10 lines of output and you use GUI output, 10 message boxes will appear each awaiting for an OK. To prevent this pipe your commandto the comandlet Out-String. This will convert the output to one string array with 10 lines, all output will be shown in one message box (for example: dir C:\ | Out-String).
Config files:
PS2EXE can create config files with the name of the generated executable + ".config". In most cases those config files are not necessary, they are a manifest that tells which .Net Framework version should be used. As you will usually use the actual .Net Framework, try running your excutable without the config file.
Parameter processing:
Compiled scripts process parameters like the original script does. One restriction comes from the Windows environment: for all executables all parameters have the type STRING, if there is no implicit conversion for your parameter type you have to convert explicitly in your script. You can even pipe content to the executable with the same restriction (all piped values have the type STRING).
Password security:
Never store passwords in your compiled script! One can simply decompile the script with the parameter -extract. For example Output.exe -extract:C:\Output.ps1 will decompile the script stored in Output.exe.
Script variables:
Since PS2EXE converts a script to an executable, script related variables are not available anymore. Especially the variable $PSScriptRoot is empty. The variable $MyInvocation is set to other values than in a script. You can retrieve the script/executable path independant of compiled/not compiled with the following code (thanks to JacquesFS): if ($MyInvocation.MyCommand.CommandType -eq "ExternalScript")
{ $ScriptPath = Split-Path -Parent -Path $MyInvocation.MyCommand.Definition }
else
{ $ScriptPath = Split-Path -Parent -Path ([Environment]::GetCommandLineArgs()[0])
if (!$ScriptPath){ $ScriptPath = "." } }
Window in background in -noConsole mode:
When an external window is opened in a script with -noConsole mode (i.e. for Get-Credential or for a command that needs a cmd.exe shell) the next window is opened in the background. The reason for this is that on closing the external window windows tries to activate the parent window. Since the compiled script has no window, the parent window of the compiled script is activated instead, normally the window of Explorer or Powershell. To work around this, $Host.UI.RawUI.FlushInputBuffer() opens an invisible window that can be activated. The following call of $Host.UI.RawUI.FlushInputBuffer() closes this window (and so on). The following example will not open a window in the background anymore as a single call of "ipconfig | Out-String" will do: $Host.UI.RawUI.FlushInputBuffer()
ipconfig | Out-String
$Host.UI.RawUI.FlushInputBuffer()
Changes:

1.0.10 / 2021-04-10
parameter outputFile now accepts a target folder (without filename)
1.0.9 / 2021-02-28
new parameter UNICODEEncoding to output as UNICODE changed parameter debug to prepareDebug finally dared to use advanced parameters
1.0.8 / 2020-10-24
refactored
1.0.7 / 2020-08-21
bug fix for simultanous progress bars in one pipeline
1.0.6 / 2020-08-10
prompt for choice behaves like Powershell now (console mode only) (limited) support for Powershell Core (starts Windows Powershell in the background) fixed processing of negative parameter values support for animated progress bars (noConsole mode only)
1.0.5 / 2020-07-11
support for nested progress bars (noConsole mode only)
1.0.4 / 2020-04-19
Application.EnableVisualStyles() as default for GUI applications, new parameter -noVisualStyles to prevent this
1.0.3 / 2020-02-15
converted files from UTF-16 to UTF-8 to allow git diff ignore control keys in secure string request in console mode
1.0.2 / 2020-01-08
added examples to github
1.0.1 / 2019-12-16
fixed "unlimited window width for GUI windows" issue in ps2exe.ps1 and Win-PS2EXE
1.0.0 / 2019-11-08
first stable module version
0.0.0 / 2019-09-15
experimental
https://b.thumbs.redditmedia.com/3Mu9vWE4WE2c6zq8Hnu_iBc-cOnwyg_0yuCfikR6INY.jpg Hey!

I have to search a flag related with privilege escalation. The first thing I did was running linpeas to search for the PE vector. The only thing that was interesting was this (If it's in this color means that has a 95% to succeed with the pe)



https://preview.redd.it/e2gm5rsjhno71.png?width=1341&format=png&auto=webp&s=d16feb570615aa69b75d81d05b7d9605d34c0d7c

So my home dir is in the path, ok. My first though was to create a bash script that initiates a reverse shell and give it a name that the root my execute. But I'm unable to succeed. No interesting cronjobs, no vulnerable SUID bins, I even sniffed the root commands with pspy and nothing i could exploit. I've been two days trying all other types of pe exploits but none works. I'm out of ideas. Any suggestions? Thank you!

submitted by /u/FreeRaider1
[link] [comments]
Hacking on Medium
Text-based Diagramming using Vite and Mermaid


Use Vite and Mermaid for dynamic diagramming.

Continue reading on Medium »
Hacking on Medium
Hacktivitycon 2021 — Writeups


Swaggy (web)

Continue reading on Medium »
1700+ testers joined during the first week of public testing! 300+ reports submitted by testers. Augmented Finance devs fixed many issuesContinue reading on Medium » (https://augmentedfinance.medium.com/augmented-finance-testnet-progress-update-week-1-7df4b318351b?source=rss------bug_bounty-5)
Inviting users to stress test our multichain token bridge in the Polkalokr Bug Bounty.Continue reading on Polkalokr » (https://medium.com/polkalokr/polkalokr-bug-bounty-launch-4b02f7620020?source=rss------bug_bounty-5)
Deep Web
Sites like prnt.sc or something closer to it?

The site is supposed to be a service for screenshots on the cloud but there’s no privacy. Try combining two letters followed by 4 numbers after forward dash and you’ll get a random screenshot. Ex: prnt.sc/ba4444

Is there something like this where you could poke around people’s photos or something?

submitted by /u/Buillshirt
[link] [comments]
Hacking Articles Tips Tricks Videos Tutorials
Photo
Black Hat Ethical Hacking
Azure Zero-Day Flaws Highlight Lurking Supply-Chain Risk

https://www.blackhatethicalhacking.com/wp-content/uploads/2021/08/Untitled-design-2-1.png Azure Zero-Day Flaws Highlight Lurking Supply-Chain RiskPost Views: 107
Reading Time: 1 Minute
Dubbed OMIGOD, a series of vulnerabilities in the Open Management Infrastructure used in Azure on Linux demonstrate hidden security threats
Four Microsoft zero-day vulnerabilities in the Azure cloud platform’s Open Management Infrastructure (OMI) — a software that many don’t know is embedded in a host of services — show that OMI represents a significant security blind spot, researchers said.

Collectively dubbed “OMIGOD” because of the name and the reaction of the researchers who discovered them, the flaws — which were zero-day when found — affect thousands of Azure customers and millions of endpoints, according to a blog post published this week by cloud infrastructure security firm Wiz.

Though Microsoft patched them this week in its monthly Patch Tuesday raft of updates, their presence in OMI highlights the risk for the supply chain when companies unknowingly run code — particularly open-source code — on their systems that allows for exploitation, researchers said.

Indeed, recent high-profile supply-chain attacks such as SolarWinds and Kaseya demonstrate how much damage can be done when undetected flaws in third-party software that organizations use in larger systems are exploited.

“One of the biggest challenges in preventing them is that our digital supply chain is not transparent,” senior security researcher Nir Ohfeld wrote in the Wiz post. “If you don’t know what’s hidden in the services and products you use every day, how can you manage the risk?

Indeed, the OMIGOD  vulnerabilities discovered by Ohfeld and his colleagues present a security danger to potentially millions of unsuspecting customers of cloud computing services, he said.
See Also: Complete Offensive Security and Ethical Hacking Course
“In a small sample of Azure tenants we analyzed, over 65 percent [of Azure customers] were unknowingly at risk,” Ohfeld wrote.

The vulnerabilities that Wiz researchers discovered include one that allows for remote code execution (RCE), CVE-2021-38647. The other three are privilege-escalation vulnerabilities (CVE-2021-38648, CVE-2021-38645 and CVE-2021-38649) of lower risk but which are critical for a full attack chain.

“Unless a patch is applied, attackers can easily exploit these four vulnerabilities to escalate to root privileges and remotely execute malicious code (for instance, encrypting files for ransom),” Ohfeld said. Hidden Cloud Security Danger in OMIOne reason for the significant alarm over the flaws is that they are found in OMI, an agent automatically deployed when customers set up a Linux virtual machine (VM) in their cloud and enable certain Azure services, researchers explained.

“This happens without customers’ explicit consent or knowledge,” Ohfeld wrote. “Users simply click ‘agree’ to log collection during setup, and they have unknowingly opted in.”

OMI is a perilous attack surface because Azure provides “virtually no public documentation” about it, he said. That means most customers have never heard of it and are unaware that it even exists as an exploitable entity in their deployment.

Moreover, the OMI agent runs as root with the highest privileges, so any user can communicate with it using a UNIX socket or via an HTTP API when configured to allow external access, Ohfeld explained.
See Also: Windows MSHTML zero-day defenses bypassed as new info emerges “As a result, the vulnerabilities we found would allow external users or low-privileged users to remotely execute [...]