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
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
Download PS2EXE (https://github.com/MScholtes/PS2EXE)
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]
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: security in practice
Find out Mobile Number from Email ID?
I was wondering if there is a way in which I can find out a person's mobile number from its Email ID?
submitted by /u/Lmao_py
[link] [comments]
Find out Mobile Number from Email ID?
I was wondering if there is a way in which I can find out a person's mobile number from its Email ID?
submitted by /u/Lmao_py
[link] [comments]
reddit
Find out Mobile Number from Email ID?
I was wondering if there is a way in which I can find out a person's mobile number from its Email ID?
Hacking Articles Tips Tricks Videos Tutorials
Photo
Augmented Finance Testnet Progress Update: Week 1
https://augmentedfinance.medium.com/augmented-finance-testnet-progress-update-week-1-7df4b318351b?source=rss------bug_bounty-5
https://augmentedfinance.medium.com/augmented-finance-testnet-progress-update-week-1-7df4b318351b?source=rss------bug_bounty-5
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)
Polkalokr Bug Bounty Launch
https://medium.com/polkalokr/polkalokr-bug-bounty-launch-4b02f7620020?source=rss------bug_bounty-5
https://medium.com/polkalokr/polkalokr-bug-bounty-launch-4b02f7620020?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]
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]
reddit
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...
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 [...]
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 [...]
Hacking Articles Tips Tricks Videos Tutorials
Photo
Black Hat Ethical Hacking
New malware uses Windows Subsystem for Linux for stealthy attacks
https://www.blackhatethicalhacking.com/wp-content/uploads/2021/08/Untitled-design-2-1.png New malware uses Windows Subsystem for Linux for stealthy attacksPost Views: 821
Reading Time: 1 Minute
Security researchers have discovered malicious Linux binaries created for the Windows Subsystem for Linux (WSL), indicating that hackers are trying out new methods to compromise Windows machines.
The finding underlines that threat actors are exploring new methods of attack and are focusing their attention on WSL to evade detection. Using WSL to avoid detectionThe first samples targeting the WSL environment were discovered in early May and continued to appear every two to three weeks until August 22. They act as loaders for the WSL environment and enjoy very low detection on public file scanning services.
In a report today, security researchers at Lumen’s Black Lotus Labs say that the malicious files either have the payload embedded or fetch it from a remote server.
The next step is to inject the malware into a running process using Windows API calls, a technique that is neither new nor sophisticated.
From the small number of samples identified, only one came with a publicly routable IP address, hinting that threat actors are testing the use of WSL to install malware on Windows.
The malicious files rely mainly on Python 3 for carrying out their tasks and are packaged as an ELF executable for Debian using PyInstaller.
“As the negligible detection rate on VirusTotal suggests, most endpoint agents designed for Windows systems don’t have signatures built to analyze ELF files, though they frequently detect non-WSL agents with similar functionality” – Black Lotus Labs
See Also: Complete Offensive Security and Ethical Hacking Course Less than a month ago, one of the malicious Linux files was detected by just one antivirus engine on VirusTotal. Refreshing the scan on another sample showed that it went completely undetected by the engines on the scanning service
https://www.bleepstatic.com/images/news/u/1100723/2021/WSLMalwareScan.jpg Python and PowerShellOne of the variants, written completely in Python 3, does not use any Windows API and seems to be the first attempt at a loader for WSL. It uses standard Python libraries, which makes it compatible with both Windows and Linux.
The researcher found in a test sample code that prints “Hello Sanya” in Russian. All but one file associated with this sample contained local IP addresses, while the public IP pointed to 185.63.90[.]137, already offline when the researchers tried to grab the payload.
See Also: Windows MSHTML zero-day defenses bypassed as new info emerges Another “ELF to Windows” loader variant relied on PowerShell to inject and execute the shellcode. One of these samples used Python to call functions that killed the running antivirus solution, established persistence on the system, and run a PowerShell script every 20 seconds.
Based on inconsistencies observed when analyzing several samples, the researchers believe that the code is still being developed, although in the final stage.
The limited visibility from the public IP address indicates activity restricted to targets in Ecuador and France between late June and early July.
Black Lotus Labs assesses that the WSL malware loaders are the work of a threat actor testing the method from a VPN or proxy node.
Microsoft introduced Windows Subsystem for Linux in April 2016. In September 2017, when WSL was freshly out of beta, researchers at Check Point demonstrated an attack they called Bashware where WSL could be abused to hide malicio[...]
New malware uses Windows Subsystem for Linux for stealthy attacks
https://www.blackhatethicalhacking.com/wp-content/uploads/2021/08/Untitled-design-2-1.png New malware uses Windows Subsystem for Linux for stealthy attacksPost Views: 821
Reading Time: 1 Minute
Security researchers have discovered malicious Linux binaries created for the Windows Subsystem for Linux (WSL), indicating that hackers are trying out new methods to compromise Windows machines.
The finding underlines that threat actors are exploring new methods of attack and are focusing their attention on WSL to evade detection. Using WSL to avoid detectionThe first samples targeting the WSL environment were discovered in early May and continued to appear every two to three weeks until August 22. They act as loaders for the WSL environment and enjoy very low detection on public file scanning services.
In a report today, security researchers at Lumen’s Black Lotus Labs say that the malicious files either have the payload embedded or fetch it from a remote server.
The next step is to inject the malware into a running process using Windows API calls, a technique that is neither new nor sophisticated.
From the small number of samples identified, only one came with a publicly routable IP address, hinting that threat actors are testing the use of WSL to install malware on Windows.
The malicious files rely mainly on Python 3 for carrying out their tasks and are packaged as an ELF executable for Debian using PyInstaller.
“As the negligible detection rate on VirusTotal suggests, most endpoint agents designed for Windows systems don’t have signatures built to analyze ELF files, though they frequently detect non-WSL agents with similar functionality” – Black Lotus Labs
See Also: Complete Offensive Security and Ethical Hacking Course Less than a month ago, one of the malicious Linux files was detected by just one antivirus engine on VirusTotal. Refreshing the scan on another sample showed that it went completely undetected by the engines on the scanning service
https://www.bleepstatic.com/images/news/u/1100723/2021/WSLMalwareScan.jpg Python and PowerShellOne of the variants, written completely in Python 3, does not use any Windows API and seems to be the first attempt at a loader for WSL. It uses standard Python libraries, which makes it compatible with both Windows and Linux.
The researcher found in a test sample code that prints “Hello Sanya” in Russian. All but one file associated with this sample contained local IP addresses, while the public IP pointed to 185.63.90[.]137, already offline when the researchers tried to grab the payload.
See Also: Windows MSHTML zero-day defenses bypassed as new info emerges Another “ELF to Windows” loader variant relied on PowerShell to inject and execute the shellcode. One of these samples used Python to call functions that killed the running antivirus solution, established persistence on the system, and run a PowerShell script every 20 seconds.
Based on inconsistencies observed when analyzing several samples, the researchers believe that the code is still being developed, although in the final stage.
The limited visibility from the public IP address indicates activity restricted to targets in Ecuador and France between late June and early July.
Black Lotus Labs assesses that the WSL malware loaders are the work of a threat actor testing the method from a VPN or proxy node.
Microsoft introduced Windows Subsystem for Linux in April 2016. In September 2017, when WSL was freshly out of beta, researchers at Check Point demonstrated an attack they called Bashware where WSL could be abused to hide malicio[...]