LAPSToolkit – Tool To Audit And Attack LAPS Environments

Functions written in PowerShell that leverage PowerView to audit and attack Active Directory environments that have deployed Microsoft’s Local Administrator Password Solution (LAPS). It includes finding groups specifically delegated by sysadmins, finding users with “All Extended Rights" that can view passwords, and viewing all computers with LAPS enabled.Please submit issues or comments for any problems or performance improvements. This project was created with code from an older version of PowerView.For more information on how LAPS works see https://adsecurity.org/?p=1790.Get-LAPSComputers:Displays all computers with LAPS enabled, password expriation, and password if user has accessFind-LAPSDelegatedGroups:Searches through all OUs to see which AD groups can read the ms-Mcs-AdmPwd attributeFind-AdmPwdExtendedRightsParses through ExtendedRights for each AD computer with LAPS enabled and looks for which group has read access and if any user has "All Extended Rights". Sysadmins may not be aware the users with All Extended Rights can view passwords and may be less protected than the users in the delegated groups. An example is the user which adds a computer to the domain automatically receives the "All Extended Rights" permission. Since this function will parse ACLs for each AD computer, this can take very long with a larger domain.Special thanks to Sean Metcalf (@pyrotek3), Will Schroeder (@harmj0y), Karl Fosaaen (@kfosaaen), Matt Graeber (@mattifestation) for research and code with LAPS, AD permissions, and offensive PowerShell.Download LAPSToolkit

Link: http://feedproxy.google.com/~r/PentestTools/~3/0JNW5bf6UGc/lapstoolkit-tool-to-audit-and-attack.html

DNS-Shell – An Interactive Shell Over DNS Channel

DNS-Shell is an interactive Shell over DNS channel. The server is Python based and can run on any operating system that has python installed, the payload is an encoded PowerShell command.Understanding DNS-ShellThe Payload is generated when the sever script is invoked and it simply utilizes nslookup to perform the queries and query the server for new commands the server then listens on port 53 for incoming communications, once payload is executed on the target machine the server will spawn an interactive shell.Once the channel is established the payload will continously query the server for commands if a new command is entered, it will execute it and return the result back to the server.Using DNS-ShellRunning DNS-Shell is relatively simpleDNS-Shell supports two mode of operations direct and recursive modes:Perform a git clone from our DNS-shell Github pageDNS-Shell direct mode: sudo python DNS-Shell.py -l -d [Server IP]DNS-Shell recursive mode: sudo python DNS-Shell.py -l -r [Domain]Download DNS-Shell

Link: http://www.kitploit.com/2019/03/dns-shell-interactive-shell-over-dns.html

AutoRDPwn v4.8 – The Shadow Attack Framework

AutoRDPwn is a script created in Powershell and designed to automate the Shadow attack on Microsoft Windows computers. This vulnerability allows a remote attacker to view his victim’s desktop without his consent, and even control it on request. For its correct operation, it is necessary to comply with the requirements described in the user guide.RequirementsPowershell 4.0 or higherChangesVersion 4.8• Compatibility with Powershell 4.0• Automatic copy of the content to the clipboard (passwords, hashes, dumps, etc.)• Automatic exclusion in Windows Defender (4 different methods)• Remote execution without password for PSexec, WMI and Invoke-Command• New available attack: DCOM Passwordless Execution• New available module: Remote Access / Metasploit Web Delivery• New module available: Remote VNC Server (designed for legacy environments)• Autocomplete the host, user and password fields by pressing Enter• It is now possible to run the tool without administrator privileges with the -noadmin parameter*The rest of the changes can be consulted in the CHANGELOG fileUseThis application can be used locally, remotely or to pivot between computers. Thanks to the additional modules, it is possible to dump hashes and passwords, obtain a remote shell, upload and download files or even recover the history of RDP connections or passwords of wireless networks.One line execution:powershell -ep bypass “cd $env:temp ; iwr https://darkbyte.net/autordpwn.php -outfile AutoRDPwn.ps1 ; .\AutoRDPwn.ps1"The detailed guide of use can be found at the following link:https://darkbyte.net/autordpwn-la-guia-definitivaScreenshotsCredits and Acknowledgments• Mark Russinovich for his tool PsExec -> https://docs.microsoft.com/en-us/sysinternals/downloads/psexec• HarmJ0y & Matt Graeber for his script Get-System -> https://github.com/HarmJ0y/Misc-PowerShell• Stas’M Corp. for its RDP tool Wrapper -> https://github.com/stascorp/rdpwrap• Kevin Robertson for his script Invoke-TheHash -> https://github.com/Kevin-Robertson/Invoke-TheHash• Benjamin Delpy for his tool Mimikatz -> https://github.com/gentilkiwi/mimikatz• Halil Dalabasmaz for his script Invoke-Phant0m -> https://github.com/hlldz/Invoke-Phant0mContactThis software does not offer any kind of guarantee. Its use is exclusive for educational environments and / or security audits with the corresponding consent of the client. I am not responsible for its misuse or for any possible damage caused by it.For more information, you can contact through info@darkbyte.netDownload AutoRDPwn

Link: http://www.kitploit.com/2019/03/autordpwn-v48-shadow-attack-framework.html

Phantom Evasion – Python AV Evasion Tool Capable To Generate FUD Executable Even With The Most Common 32 Bit Metasploit Payload (Exe/Elf/Dmg/Apk)

Phantom-Evasion is an interactive antivirus evasion tool written in python capable to generate (almost) FUD executable even with the most common 32 bit msfvenom payload (lower detection ratio with 64 bit payloads). The aim of this tool is to make antivirus evasion an easy task for pentesters through the use of modules focused on polymorphic code and antivirus sandbox detection techniques. Since version 1.0 Phantom-Evasion also include a post-exploitation section dedicated to persistence and auxiliary modules.The following OSs officialy support automatic setup:Kali Linux Rolling 2018.1+ (64 bit)Parrot Security (64 bit)The following OSs are likely able to run Phantom Evasion through manual setup:Arch Linux (64 bit)BlackArch Linux (64 bit)Elementary (64 bit)Linux Mint (64 bit)Ubuntu 15.10+ (64 bit)Windows 7/8/10 (64 bit)ContributorsSpecial thanks to:phra https://github.com/phrastefano118 https://github.com/stefano118Getting StartedSimply git clone or download and unzip Phantom-Evasion folderKali Linux:Automatic setup officially supported, open a terminal and execute phantom-evasion:sudo python phantom-evasion.py or:sudo chmod +x ./phantom-evasion.pysudo ./phantom-evasion.pyDependencies (only for manual setup)metasploit-frameworkmingw-w64 (cygwin on windows)gccapktoolstripwine (not necessary on windows)apksignerpyinstallerrequire libc6-dev-i386 (linux only)WINDOWS PAYLOADSWindows Shellcode Injection Modules (C)Msfvenom windows payloads and custom shellcodes supported(>) Randomized junkcode and windows antivirus evasion techniques(>) Multibyte Xor encoders availables (see Multibyte Xor encoders readme section)(>) Decoy Processes Spawner available (see Decoy Process Spawner section)(>) Strip executable available (https://en.wikipedia.org/wiki/Strip_(Unix))(>) Execution time range:35-60 secondWindows Shellcode Injection VirtualAlloc: Inject and Execute shellcode in memory using VirtualAlloc,CreateThread,WaitForSingleObject API. Windows Shellcode Injection VirtualAlloc NoDirectCall LL/GPA: Inject and Execute shellcode in memory using VirtualAlloc,CreateThread,WaitForSingleObject API. Critical API are dinamically loaded (No Direct Call) using LoadLibrary and GetProcAddress API. Windows Shellcode Injection VirtualAlloc NoDirectCall GPA/GMH: Inject and Execute shellcode in memory using VirtualAlloc,CreateThread,WaitForSingleObject API. Critical API are dinamically loaded (No Direct Call) using GetModuleHandle and GetProcAddress API. Windows Shellcode Injection HeapAlloc: Inject and Execute shellcode in memory using HeapAlloc,HeapCreate,CreateThread,WaitForSingleObject API. Windows Shellcode Injection HeapAlloc NoDirectCall LL/GPA: Inject and Execute shellcode in memory using HeapCreate,HeapAlloc,CreateThread,WaitForSingleObject API. Critical API are dinamically loaded (No Direct Call) using LoadLibrary and GetProcAddress API. Windows Shellcode Injection HeapAlloc NoDirectCall GPA/GMH: Inject and Execute shellcode in memory using HeapCreate,HeapAlloc,CreateThread,WaitForSingleObject API. Critical API are dinamically loaded (No Direct Call) using GetModuleHandle and GetProcAddress API. Windows Shellcode Injection Process inject: Inject and Execute shellcode into remote process memory (default: OneDrive.exe (x86) , explorer.exe (x64)) using VirtualAllocEx,WriteProcessMemory,CreateRemoteThread,WaitForSingleObject API. Windows Shellcode Injection Process inject NoDirectCall LL/GPA: Inject and Execute shellcode into remote process memory (default: OneDrive.exe (x86) , explorer.exe (x64)) using VirtualAllocEx,WriteProcessMemory,CreateRemoteThread,WaitForSingleObject API. Critical API are dinamically loaded (No Direct Call) using LoadLibrary and GetProcAddress API. Windows Shellcode Injection Process inject NoDirectCall GPA/GMH: Inject and Execute shellcode into remote process memory (default: OneDrive.exe (x86) , explorer.exe (x64)) using VirtualAllocEx,WriteProcessMemory,CreateRemoteThread,WaitForSingleObject API. Critical API are dinamically loaded (No Direct Call) using GetModuleHandle and GetProcAddress API. Windows Shellcode Injection Thread Hijack: Inject shellcode into remote process memory and execute it performing thread execution hijack (default: OneDrive.exe (x86) , explorer.exe (x64)) using VirtualAllocEx,WriteProcessMemory,Get/SetThreadContext,Suspend/ResumeThread API. Windows Shellcode Injection Thread Hijack LL/GPA: Inject shellcode into remote process memory and execute it performing thread execution hijack (default: OneDrive.exe (x86) , explorer.exe (x64)) using VirtualAllocEx,WriteProcessMemory,Get/SetThreadContext,Suspend/ResumeThread API. Critical API are dinamically loaded (No Direct Call) using LoadLibrary and GetProcAddress API. Windows Shellcode Injection Thread Hijack GPA/GMH: Inject shellcode into remote process memory and execute it performing thread execution hijack (default: OneDrive.exe (x86) , explorer.exe (x64)) using VirtualAllocEx,WriteProcessMemory,Get/SetThreadContext,Suspend/ResumeThread API. Critical API are dinamically loaded (No Direct Call) using GetModuleHandle and GetProcAddress API. Windows Pure C meterpreter stagerPure C polymorphic meterpreter stagers compatible with msfconsole and cobalt strike beacon.(reverse_tcp/reverse_http)(>) Randomized junkcode and windows antivirus evasion techniques (>) Phantom evasion decoy process spawner available (see phantom evasion decoy process spawner section) (>) Strip executable available (https://en.wikipedia.org/wiki/Strip_(Unix)) (>) Execution time range:35-60 secondC meterpreter/reverse_TCP VirtualAlloc (x86/x64): 32/64 bit windows/meterpreter/reverse_tcp polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_tcp (if x86) — windows/x64/meterpreter/reverse_tcp (if x64) , memory:Virtual) C meterpreter/reverse_TCP HeapAlloc (x86/x64): 32/64 bit windows/meterpreter/reverse_tcp polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_tcp (if x86) — windows/x64/meterpreter/reverse_tcp (if x64) , memory:Heap) C meterpreter/reverse_TCP VirtualAlloc NoDirectCall GPAGMH (x86/x64): 32/64 bit windows/meterpreter/reverse_tcp polymorphic stager written in c (rrequire multi/handler listener with payload set to windows/meterpreter/reverse_tcp (if x86) — windows/x64/meterpreter/reverse_tcp (if x64) , memory:Virtual , API loaded at runtime) C meterpreter/reverse_TCP HeapAlloc NoDirectCall GPAGMH (x86/x64): 32/64 bit windows/meterpreter/reverse_tcp polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_tcp (if x86) — windows/x64/meterpreter/reverse_tcp (if x64) , memory:Heap , API loaded at runtime) C meterpreter/reverse_HTTP VirtualAlloc (x86/x64): 32/64 bit windows/meterpreter/reverse_http polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_http (if x86) — windows/x64/meterpreter/reverse_http (if x64) , memory:Virtual) C meterpreter/reverse_HTTP HeapAlloc (x86/x64): 32/64 bit windows/meterpreter/reverse_http polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_http (if x86) — windows/x64/meterpreter/reverse_http (if x64) , memory:Heap) C meterpreter/reverse_HTTP VirtualAlloc NoDirectCall GPAGMH (x86/x64): 32/64 bit windows/meterpreter/reverse_http polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_http (if x86) — windows/x64/meterpreter/reverse_http (if x64) , API loaded at runtime) C meterpreter/reverse_HTTP HeapAlloc NoDirectCall GPAGMH (x86/x64): 32/64 bit windows/meterpreter/reverse_http polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_http (if x86) — windows/x64/meterpreter/reverse_http (if x64) , memory:Heap , API loaded at runtime) C meterpreter/reverse_HTTPS VirtualAlloc (x86/x64): 32/64 bit windows/meterpreter/reverse_http polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_https (if x86) — windows/x64/meterpreter/reverse_https (if x64) , memory:Virtual) C meterpreter/reverse_HTTPS HeapAlloc (x86/x64): 32/64 bit windows/meterpreter/reverse_http polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_https (if x86) — windows/x64/meterpreter/reverse_https (if x64) , memory:Heap) C meterpreter/reverse_HTTPS VirtualAlloc NoDirectCall GPAGMH (x86/x64): 32/64 bit windows/meterpreter/reverse_http polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_https (if x86) — windows/x64/meterpreter/reverse_https (if x64) , API loaded at runtime) C meterpreter/reverse_HTTPS HeapAlloc NoDirectCall GPAGMH (x86/x64): 32/64 bit windows/meterpreter/reverse_http polymorphic stager written in c (require multi/handler listener with payload set to windows/meterpreter/reverse_https (if x86) — windows/x64/meterpreter/reverse_https (if x64) , memory:Heap , API loaded at runtime) Powershell / Wine-Pyinstaller modulesPowershell modules:(>) Randomized junkcode and windows antivirus evasion techniques (>) Decoy Process Spawner available (see phantom evasion decoy process spawner section) (>) Strip executable available (https://en.wikipedia.org/wiki/Strip_(Unix)) (>) Execution time range:35-60 secondWindows Powershell/Cmd Oneliner Dropper: Require user-supplied Powershell/Cmd oneliner payload (example Empire oneliner payload). Generate Windows powershell/Cmd oneliner dropper written in c. Powershell/Cmd oneliner payload is executed using system() function. Windows Powershell Script Dropper: Both msfvenom and custom powershell payloads supported. (32 bit powershell payloads are not compatible with 64 bit powershell target and vice versa.) Generate Windows powershell script (.ps1) dropper written in c. Powershell script payload is executed using system() function (powershell -executionpolicy bypass -WindowStyle Hidden -Noexit -File “PathTops1script"). Wine-Pyinstaller modules:(>) Randomized junkcode and windows antivirus evasion techniques (>) Execution time range:5-25 second (>) Require python and pyinstaller installed in wine.Windows WinePyinstaller Python MeterpreterPure python meterpreter payload.WinePyinstaller Oneline payload dropperPure python powershell/cmd oneliner dropper.Powershell/cmd payload executed using os.system().LINUX PAYLOADSLinux Shellcode Injection Module (C)Msfvenom linux payloads and custom shellcodes supported.(>) Randomized junkcode and C antivirus evasion techniques (>) Multibyte Xor encoders availables (see Multibyte Xor encoders readme section) (>) Strip executable available (https://en.wikipedia.org/wiki/Strip_(Unix)) (>) Execution time range:20-45 secondLinux Shellcode Injection HeapAlloc: Inject and Execute shellcode in memory using mmap and memcpy. Linux Bash Oneliner Dropper: Execute custom oneliner payload using system() function. OSX PAYLOADSOSX 32bit multi-encoded:Pure msfvenom multi-encoded OSX payloads.ANDROID PAYLOADSAndroid Msfvenom Apk smali/baksmali:(>) Fake loop injection (>) Goto loopAndroid msfvenom payloads modified an rebuilded with apktool (Also capable of apk backdoor injection).UNIVERSAL PAYLOADSGenerate executable compatible with the OSs used to run Phantom-Evasion.Universal Meterpreter increments-trick Universal Polymorphic Meterpreter Universal Polymorphic Oneliner dropper POST-EXPLOITATION MODULESWindows Persistence RegCreateKeyExW Add Registry Key (C) This modules generate executables which needs to be uploaded to the target machine and excuted specifing the fullpath to file to add to startup as arguments. Windows Persistence REG Add Registry Key (CMD) This module generate persistence cmdline payloads (Add Registry Key via REG.exe). Windows Persistence Keep Process Alive This module generate executable which need to be uploaded to the target machine and executed. Use CreateToolSnapshoot ProcessFirst and ProcessNext to check if specified process is alive every X seconds. Usefull combined with Persistence N.1 or N.2 (persistence start Keep process alive file which then start and keep alive the specified process) Windows Persistence Schtasks cmdline This modules generate persistence cmdline payloads (using Schtasks.exe).Windows Set Files Attribute Hiddenhide file through commandline or with compiled executable (SetFileAttributes API)WarningPYTHON3 COMPATIBILITY TEMPORARILY SUSPENDED!Decoy Processes Spawner:During target-side execution this will cause to spawn (Using WinExec or CreateProcess API) a maximum of 4 processes consequentialy. The last spawned process will reach the malicious section of code while the other decoy processes spawned before will executes only random junk code.PRO: Longer execution time,Lower rate of detection. CONS: Higher resource consumption.Multibyte Xor Encoder:C xor encoders with three pure c decoding stub available with Shellcode Injection modules.MultibyteKey xor:Shellcode xored with one multibyte (variable lenght) random key. Polymorphic C decoder stub.Double Multibyte-key xor:Shellcode xored with the result of xor between two multibyte (variable lenght) random keys Polymorphic C decoder stub.Triple Multibyte-key xor:Shellcode xored with the result of xor between two multibyte (variable lenght) random keys xored with a third multibyte random key. Polymorphic C decoder stub.Download Phantom-Evasion

Link: http://feedproxy.google.com/~r/PentestTools/~3/u2lYO11vEuc/phantom-evasion-python-av-evasion-tool.html

DCOMrade – Powershell Script For Enumerating Vulnerable DCOM Applications

DCOMrade is a Powershell script that is able to enumerate the possible vulnerable DCOM applications that might allow for lateral movement, code execution, data exfiltration, etc. The script is build to work with Powershell 2.0 but will work with all versions above as well. The script currently supports the following Windows operating systems (both x86 and x64):Microsoft Windows 7Microsoft Windows 10Microsoft Windows Server 2012 / 2012 R2Microsoft Windows Server 2016How it worksThe script was made based on the research done by Matt Nelson (@enigma0x3), especially the round 2 blogpost that goes into finding DCOM applications that might be useful for pentesters and red teams.First a remote connection with the target system is made, this connection is used throughout the script for a multitude of operations. A Powershell command is executed on the target system that retrieves all the DCOM applications and their AppID’s. The AppID’s are used to loop through the Windows Registry and check for any AppID that does not have the LaunchPermission subkey set in their entry, these AppID’s are stored and used to retrieve their associated CLSID’s.The script uses a specific blacklist with each OS, this is why there are different options for the target operating system. The blacklist skips CLSID entries that might hang the script because of DCOM applications that cannot be activated, this reduces the load on the target system and reduces the time for the script to complete.With the CLSID, the DCOM application associated with it can be activated. The ‘Shortcut’ CLSID is used to count the amount of MemberTypes associated with it, this is done to check the default amount of MemberTypes. This number is used to check for the CLSID’s that hold anything different than this amount. The script does this with the CLSID of the ‘Shortcut’ (HKEY_CLASSES_ROOT\CLSID\{00021401-0000-0000-C000-000000000046}) because this is a shared CLSID across the Microsoft Windows operating systems. The CLSID’s with a different amount of MemberTypes might hold a Method or Property that can be (ab)used, and will be added to an array.The CLSID’s in the array are being checked on strings in the MemberTypes that might indicate a way to (ab)use it, this list of strings can be found in the VulnerableSubset file. Please note that this list is by no means a complete list to find every single vulnerable DCOM application, but this list being a dynamic part of the process should give the user of the script a way to look for specific strings that migth indicate a functionality of a DCOM application that might be useful for their purpose.The results of the script are outputted in a HTML report and should be usable for auditing a system as a preventive measure. For the offensive side I created an Empire module which at the time of writing is awaiting approval to be added to the master branch. If you would like to add this to Empire yourself you can do so by adding the module located here.For a full technical explanation of the idea, the script and possible detection methods you can read the research paper associated with this.PrerequisitesThe script, while not being used as an Empire module, has some limitations as the working of the script and how it connects with the target machine differs.For this script to work, the Windows Remote Management services need to be allowed in the Windows Firewall (5985);If the target system’s network profile is set to Public the following command needs to be executed to allow Windows Remote Management services being used on the target system: Enable-PSRemoting -SkipNetworkProfilecheck -ForceThis script only works when one has the credentials of a local Administrator on the target system. Without these credentials you will not be able to start a remote session with the target machine, or be able to activate DCOM applications.Example usageWhen in a Microsoft Windows domain:.\DCOMrade.ps1 -ComputerName [Computername / IP] -User [Local Administrator] -OS [Operating System] -Domain [Domain name]When not in a Microsoft Windows domain:.\DCOMrade.ps1 -ComputerName [Computername / IP] -User [Local Administrator] -OS [Operating System]LimitationsCurrently the script does try to release any instantiated / activated DCOM applications but some activations start new processes (such as Internet Explorer), the process could be stopped but this would mean that if a user on the target system is using that particular application, this process will stop for them as well;Another thing, which probably has to do with bad my coding skills, is that the script might introduce considerable load on the target system if the target system does not have a lot of resources. Be considerate when using this in a production environment or on servers;The script might take some time to execute completely, this depends on the amount of DCOM applications and the size of the vulnerable subset file.AcknowledgementsThis script was inspired by a DCOM lateral movement workshop that was given by Eva Tanaskoska, without this workshop the whole idea for trying to enumerate this in an automated manner would never be conceived.Thanks to Matt Nelson’s (a.k.a. @enigma0x3) research I was able to find enough information to come up with a form of automation.Philip Tsukerman’s article which sums up most of the available DCOM techniques for lateral movement and going into how these work.Download DCOMrade

Link: http://feedproxy.google.com/~r/PentestTools/~3/xaHJPu0lHk0/dcomrade-powershell-script-for.html

BEEMKA: Basic Electron Post-Exploitation Framework

PenTestIT RSS Feed
There are a lot of applications today that use Electron Framework, as it helps you build cross platform desktop apps with JavaScript, HTML, and CSS. Examples are applications such as Skype, Station, etc. A new post-exploitation framework – BEEMKA can now help you in maintaining access and exfiltration. What is BEEMKA? BEEMKA is a modular,Read more about BEEMKA: Basic Electron Post-Exploitation Framework
The post BEEMKA: Basic Electron Post-Exploitation Framework appeared first on PenTestIT.

Link: http://pentestit.com/beemka-basic-electron-exploitation-framework/

PowerShell for Fun and Profit – Paul’s Security Weekly #590

    Joff will demonstrate some syntax with PowerShell useful for transferring data into a network while pen testing. The technical segment assumes that the pen testing is able to directly use PowerShell from the console itself, although the techniques can be adapted for different purposes. Derbycon Upcoming technical segments Paul’s Stories Two charged with […]
The post PowerShell for Fun and Profit – Paul’s Security Weekly #590 appeared first on Security Weekly.

Link: http://feedproxy.google.com/~r/securityweekly/Lviv/~3/idmoSxoktMk/

DevAudit – Open-source, Cross-Platform, Multi-Purpose Security Auditing Tool

DevAudit is an open-source, cross-platform, multi-purpose security auditing tool targeted at developers and teams adopting DevOps and DevSecOps that detects security vulnerabilities at multiple levels of the solution stack. DevAudit provides a wide array of auditing capabilities that automate security practices and implementation of security auditing in the software development life-cycle. DevAudit can scan your operating system and application package dependencies, application and application server configurations, and application code, for potential vulnerabilities based on data aggregated by providers like OSS Index and Vulners from a wide array of sources and data feeds such as the National Vulnerability Database (NVD) CVE data feed, the Debian Security Advisories data feed, Drupal Security Advisories, and many others.DevAudit helps developers address at least 4 of the OWASP Top 10 risks to web application development:A9 Using Components with Known VulnerabilitiesA5 Security MisconfigurationA6 Sensitive Data ExposureA2 Broken Authentication and Session Managementas well as risks classified by MITRE in the CWE dictionary such as CWE-2 Environment and CWE-200 Information Disclosure As development progresses and its capabilities mature, DevAudit will be able to address the other risks on the OWASP Top 10 and CWE lists like Injection and XSS. With the focus on web and cloud and distributed multi-user applications, software development today is increasingly a complex affair with security issues and potential vulnerabilities arising at all levels of the stack developers rely on to deliver applications. The goal of DevAudit is to provide a platform for automating implementation of development security reviews and best practices at all levels of the solution stack from library package dependencies to application and server configuration to source code.Features Cross-platform with a Docker image also available. DevAudit runs on Windows and Linux with *BSD and Mac and ARM Linux support planned. Only an up-to-date version of .NET or Mono is required to run DevAudit. A DevAudit Docker image can also be pulled from Docker Hub and run without the need to install Mono. CLI interface. DevAudit has a CLI interface with an option for non-interactive output and can be easily integrated into CI build pipelines or as post-build command-line tasks in developer IDEs. Work on integration of the core audit library into IDE GUIs has already begun with the Audit.Net Visual Studio extension. Continuously updated vulnerabilties data. DevAudit uses backend data providers like OSS Index and Vulners which provide continuously updated vulnerabilities data compiled from a wide range of security data feeds and sources such as the NVD CVE feeds, Drupal Security Advisories, and so on. Support for additional vulnerability and package data providers like vFeed and Libraries.io will be added. Audit operating system and development package dependencies. DevAudit audits Windows applications and packages installed via Windows MSI, Chocolatey, and OneGet, as well as Debian, Ubuntu, and CentOS Linux packages installed via Dpkg, RPM and YUM, for vulnerabilities reported for specific versions of the applications and packages. For development package dependencies and libraries DevAudit audits NuGet v2 dependencies for .NET, Yarn/NPM and Bower dependencies for nodejs, and Composer package dependencies for PHP. Support for other package managers for different languages is added regularly. Audit application server configurations. DevAudit audits the server version and the server configuration for the OpenSSH sshd, Apache httpd, MySQL/MariaDB, PostgreSQL, and Nginx servers with many more coming. Configuration auditing is based on the Alpheus library and is done using full syntactic analysis of the server configuration files. Server configuration rules are stored in YAML text files and can be customized to the needs of developers. Support for many more servers and applications and types of analysis like database auditing is added regularly. Audit application configurations. DevAudit audits Microsoft ASP.NET applications and detects vulnerabilities present in the application configuration. Application configuration rules are stored in YAML text files and can be customized to the needs of developers. Application configuration auditing for applications like Drupal and WordPress and DNN CMS is coming. Audit application code by static analysis. DevAudit currently supports static analysis of .NET CIL bytecode. Analyzers reside in external script files and can be fully customized based on the needs of the developer. Support for C# source code analysis via Roslyn, PHP7 source code and many more languages and external static code analysis tools is coming. Remote agentless auditing. DevAudit can connect to remote hosts via SSH with identical auditing features available in remote environments as in local environments. Only a valid SSH login is required to audit remote hosts and DevAudit running on Windows can connect to and audit Linux hosts over SSH. On Windows DevAudit can also remotely connect to and audit other Windows machines using WinRM. Agentless Docker container auditing. DevAudit can audit running Docker containers from the Docker host with identical features available in container environments as in local environments. GitHub repository auditing. DevAudit can connect directly to a project repository hosted on GitHub and perform package source and application configuration auditing. PowerShell support. DevAudit can also be run inside the PowerShell system administration environment as cmdlets. Work on PowerShell support is paused at present but will resume in the near future with support for cross-platform Powershell both on Windows and Linux. RequirementsDevAudit is a .NET 4.6 application. To install locally on your machine you will need either the Microsoft .NET Framework 4.6 runtime on Windows, or Mono 4.4+ on Linux. .NET 4.6 should be already installed on most recent versions of Windows, if not then it is available as a Windows feature that can be turned on or installed from the Programs and Features control panel applet on consumer Windows, or from the Add Roles and Features option in Server Manager on server versions of Windows. For older versions of Windows, the .NET 4.6 installer from Microsoft can be found here.On Linux the minimum version of Mono supported is 4.4. Although DevAudit runs on Mono 4 (with one known issue) it’s recommended that Mono 5 be installed. Mono 5 brings many improvements to the build and runtime components of Mono that benefit DevAudit.The existing Mono packages provided by your distro are probably not Mono 5 as yet, so you will have to install Mono packages manually to be able to use Mono 5. Installation instructions for the most recent packages provided by the Mono project for several major Linux distros are here. It is recommended you have the mono-devel package installed as this will reduce the chances of missing assemblies.Alternatively on Linux you can use the DevAudit Docker image if you do not wish to install Mono and already have Docker installed on your machine.InstallationDevAudit can be installed by the following methods:Building from source.Using a binary release archive file downloaded from Github for Windows or Linux.Using the release MSI installer downloaded from Github for Windows.Using the Chocolatey package manager on Windows.Pulling the ossindex/devaudit image from Docker Hub on Linux.Building from source on LinuxPre-requisites: Mono 4.4+ (Mono 5 recommended) and the mono-devel package which provides the compiler and other tools needed for building Mono apps. Your distro should have packages for at least Mono version 4.4 and above, otherwise manual installation instructions for the most recent packages provided by the Mono project for several major Linux distros are here Clone the DevAudit repository from https://github.com/OSSIndex/DevAudit.git Run the build.sh script in the root DevAudit directory. DevAudit should compile without any errors. Run ./devaudit –help and you should see the DevAudit version and help screen printed. Note that NuGet on Linux may occasionally exit with Error: NameResolutionFailure which seems to be a transient problem contacting the servers that contain the NuGet packages. You should just run ./build.sh again until the build completes normally.Building from source on WindowsPre-requisites: You must have one of: A .NET Framework 4.6 SDK or developer pack.Visual Studio 2015.Clone the DevAudit repository from https://github.com/OSSIndex/DevAudit.git From a visual Studio 2015 or ,NETRun the build.cmd script in the root DevAudit directory. DevAudit should compile without any errors. Run ./devaudit –help and you should see the DevAudit version and help screen printed. Installing from the release archive files on Windows on LinuxPre-requisites: You must have Mono 4.4+ on Linux or .NET 4.6 on Windows. Download the latest release archive file for Windows or Linux from the project releases page. Unpack this file to a directory. From the directory where you unpacked the release archive run devaudit –help on Windows or ./devaudit –help on Linux. You should see the version and help screen printed. (Optional) Add the DevAudit installation directory to your PATH environment variable Installing using the MSI Installer on WindowsThe MSI installer for a release can be found on the Github releases page.Click on the releases link near the top of the page.Identify the release you would like to install.A “DevAudit.exe" link should be visible for each release that has a pre-built installer.Download the file and execute the installer. You will be guided through a simple installation.Open a new command prompt or PowerShell window in order to have DevAudit in path.Run DevAudit.Installing using Chocolatey on WindowsDevAudit is also available on Chocolatey.Install Chocolatey.Open an admin console or PowerShell window.Type choco install devauditRun DevAudit.Installing using Docker on LinuxPull the Devaudit image from Docker Hub: docker pull ossindex/devaudit. The image tagged ossindex/devaudit:latest (which is the default image that is downloaded) is built from the most recent release while ossindex/devaudit:unstable is built on the master branch of the source code and contains the newest additions albeit with less testing.ConceptsAudit TargetRepresents a logical group of auditing functions. DevAudit currently supports the following audit targets:Package Source. A package source manages application and library dependencies using a package manager. Package managers install, remove or update applications and library dependencies for an operating system like Debian Linux, or for a development language or framework like .NET or nodejs. Examples of package sources are dpkg, yum, Chocolatey, Composer, and Bower. DevAudit audits the names and versions of installed packages against vulnerabilities reported for specific versions of those packages.Application. An application like Drupal or a custom application built using a framework like ASP.NET. DevAudit audits applications and application modules and plugins against vulnerabilities reported for specific versions of application binaries and modules and plugins. DevAudit can also audit application configurations for known vulnerabilities, and perform static analysis on application code looking for known weaknesses.Application Server. Application servers provide continuously running services or daemons like a web or database server for other applications to use, or for users to access services like authentication. Examples of application servers are the OpenSSH sshd and Apache httpd servers. DevAudit can audit application server binaries, modules and plugins against vulnerabilities reported for specific versions as well as audit server configurations for known server configuration vulnerabilities and weaknesses.Audit EnvironmentRepresents a logical environment where audits against audit targets are executed. Audit environments abstract the I/O and command executions required for an audit and allow identical functions to be performed against audit targets on whatever physical or network location the target’s files and executables are located. The follwing environments are currently supported :Local. This is the default audit environment where audits are executed on the local machine.SSH. Audits are executed on a remote host connected over SSH. It is not necessary to have DevAudit installed on the remote host.WinRM. Audits are executed on a remote Windows host connected over WinRM. It is not necessary to have DevAudit installed on the remote host.Docker. Audits are executed on a running Docker container. It is not necessary to have DevAudit installed on the container image.GitHub. Audits are executed on a GitHub project repository’s file-system directly. It is not necessary to checkout or download the project locally to perform the audit.Audit OptionsThese are different options that can be enabled for the audit. You can specify options that apply to the DevAudit program for example, to run in non-interactive mode, as well as options that apply to the target e.g if you set the AppDevMode option for auditing ASP.NET applications to true then certain audit rules will not be enabled.Basic UsageThe CLI is the primary interface to the DevAudit program and is suitable both for interactive use and for non-interactive use in scheduled tasks, shell scripts, CI build pipelines and post-build tasks in developer IDEs. The basic DevAudit CLI syntax is:devaudit TARGET [ENVIRONMENT] | [OPTIONS]where TARGET specifies the audit target ENVIRONMENT specifies the audit environment and OPTIONS specifies the options for the audit target and environment. There are 2 ways to specify options: program options and general audit options that apply to more than one target can be specified directly on the command-line as parameters . Target-specific options can be specified with the -o options using the format: -o OPTION1=VALUE1,OPTION2=VALUE2,…. with commas delimiting each option key-value pair.If you are piping or redirecting the program output to a file then you should always use the -n –non-interactive option to disable any interactive user interface features and animations.When specifying file paths, an @ prefix before a path indicates to DevAudit that this path is relative to the root directory of the audit target e.g if you specify: -r c:\myproject -b @bin\Debug\app2.exe DevAudit considers the path to the binary file as c:\myproject\bin\Debug\app2.exe.Audit TargetsPackage Sources msi Do a package audit of the Windows Installer MSI package source on Windows machines. choco Do a package audit of packages installed by the Choco package manager. oneget Do a package audit of the system OneGet package source on Windows. nuget Do a package audit of a NuGet v2 package source. You must specify the location of the NuGet packages.config file you wish to audit using the -f or –file option otherwise the current directory will be searched for this file. bower Do a package audit of a Bower package source. You must specify the location of the Bower packages.json file you wish to audit using the -f or –file option otherwise the current directory will be searched for this file. composer Do a package audit of a Composer package source. You must specify the location of the Composer composer.json file you wish to audit using the -f or –file option otherwise the current directory will be searched for this file. dpkg Do a package audit of the system dpkg package source on Debian Linux and derivatives. rpm Do a package audit of the system RPM package source on RedHat Linux and derivatives. yum Do a package audit of the system Yum package source on RedHat Linux and derivatives. For every package source the following general audit options can be used: -f –file Specify the location of the package manager configuration file if needed. The NuGet, Bower and Composer package sources require this option. –list-packages Only list the packages in the package source scanned by DevAudit. –list-artifacts Only list the artifacts found on OSS Index for packages scanned by DevAudit. Package sources tagged [Experimental] are only available in the master branch of the source code and may have limited back-end OSS Index support. However you can always list the packages scanned and artifacts available on OSS Index using the list-packages and list-artifacts options.Applications aspnet Do an application audit on a ASP.NET application. The relevant options are: -r –root-directory Specify the root directory of the application. This is just the top-level application directory that contains files like Global.asax and Web.config.-b –application-binary Specify the application binary. The is the .NET assembly that contains the application’s .NET bytecode. This file is usually a .DLL and located in the bin sub-folder of the ASP.NET application root directory.-c –configuration-file or -o AppConfig=configuration-file Specifies the ASP.NET application configuration file. This file is usually named Web.config and located in the application root directory. You can override the default @Web.config value with this option.-o AppDevMode=enabled Specifies that application development mode should be enabled for the audit. This mode can be used when auditing an application that is under development. Certain configuration rules that are tagged as disabled for AppDevMode (e.g running the application in ASP.NET debug mode) will not be enabled during the audit. netfx Do an application audit on a .NET application. The relevant options are: -r –root-directory Specify the root directory of the application. This is just the top-level application directory that contains files like App.config.-b –application-binary Specify the application binary. The is the .NET assembly that contains the application’s .NET bytecode. This file is usually a .DLL and located in the bin sub-folder of the ASP.NET application root directory.-c –configuration-file or -o AppConfig=configuration-file Specifies the .NET application configuration file. This file is usually named App.config and located in the application root directory. You can override the default @App.config value with this option.-o GendarmeRules=RuleLibrary Specifies that the Gendarme static analyzer should enabled for the audit with rules from the specified rules library used. For example: devaudit netfx -r /home/allisterb/vbot-debian/vbot.core -b @bin/Debug/vbot.core.dll –skip-packages-audit -o GendarmeRules=Gendarme.Rules.Naming will run the Gendarme static analyzer on the vbot.core.dll assembly using rules from Gendarme.Rules.Naming library. The complete list of rules libraries is (taken from the Gendarme wiki):Gendarme.Rules.BadPracticeGendarme.Rules.ConcurrencyGendarme.Rules.CorrectnessGendarme.Rules.DesignGendarme.Rules.Design.GenericGendarme.Rules.Design.LinqGendarme.Rules.ExceptionsGendarme.Rules.GendarmeGendarme.Rules.GlobalizationGendarme.Rules.InteroperabilityGendarme.Rules.Interoperability.ComGendarme.Rules.MaintainabilityGendarme.Rules.NUnitGendarme.Rules.NamingGendarme.Rules.PerformanceGendarme.Rules.PortabilityGendarme.Rules.SecurityGendarme.Rules.Security.CasGendarme.Rules.SerializationGendarme.Rules.SmellsGendarme.Rules.Ui drupal7 Do an application audit on a Drupal 7 application. -r –root-directory Specify the root directory of the application. This is just the top-level directory of your Drupal 7 install. drupal8 Do an application audit on a Drupal 8 application. -r –root-directory Specify the root directory of the application. This is just the top-level directory of your Drupal 8 install.All applications also support the following common options for auditing the application modules or plugins: –list-packages Only list the application plugins or modules scanned by DevAudit. –list-artifacts Only list the artifacts found on OSS Index for application plugins and modules scanned by DevAudit. –skip-packages-audit Only do an appplication configuration or code analysis audit and skip the packages audit. Application Servers sshd Do an application server audit on an OpenSSH sshd-compatible server. httpd Do an application server audit on an Apache httpd-compatible server. mysql Do an application server audit on a MySQL-compatible server (like MariaDB or Oracle MySQL.) nginx Do an application server audit on a Nginx server. pgsql Do an application server audit on a PostgreSQL server. This is an example command line for an application server audit: ./devaudit httpd -i httpd-2.2 -r /usr/local/apache2/ -c @conf/httpd.conf -b @bin/httpd which audits an Apache Httpd server running on a Docker container named httpd-2.2.The following are audit options common to all application servers:-r –root-directory Specifies the root directory of the server. This is just the top-level of your server filesystem and defaults to / unless you want a different server root.-c –configuration-file Specifies the server configuration file. e.g in the above audit the Apache configuration file is located at /usr/local/apache2/conf/httpd.conf. If you don’t specify the configuration file DevAudit will attempt to auto-detect the configuration file for the server selected.-b –application-binary Specifies the server binary. e.g in the above audit the Apache binary is located at /usr/local/apache2/bin/httpd. If you don’t specify the binary path DevAudit will attempt to auto-detect the server binary for the server selected.Application servers also support the following common options for auditing the server modules or plugins: –list-packages Only list the application plugins or modules scanned by DevAudit. –list-artifacts Only list the artifacts found on OSS Index for application plugins and modules scanned by DevAudit. –skip-packages-audit Only do a server configuration audit and skip the packages audit. EnvironmentsThere are currently 5 audit environment supported: local, remote hosts over SSH, remote hosts over WinRM, Docker containers, and GitHub. Local environments are used by default when no other environment options are specified.SSHThe SSH environment allows audits to be performed on any remote hosts accessible over SSH without requiring DevAudit to be installed on the remote host. SSH environments are cross-platform: you can connect to a Linux remote host from a Windows machine running DevAudit. An SSH environment is created by the following options:-s SERVER [–ssh-port PORT] -u USER [-k KEYFILE] [-p | –password-text PASSWORD]-s SERVER Specifies the remote host or IP to connect to via SSH.-u USER Specifies the user to login to the server with.–ssh-port PORT Specifies the port on the remote host to connect to. The default is 22.-k KEYFILE Specifies the OpenSSH compatible private key file to use to connect to the remote server. Currently only RSA or DSA keys in files in the PEM format are supported.-p Provide a prompt with local echo disabled for interactive entry of the server password or key file passphrase.–password-text PASSWORD Specify the user password or key file passphrase as plaintext on the command-line. Note that on Linux when your password contains special characters you should use enclose the text on the command-line using single-quotes like ‘MyPa

Link: http://www.kitploit.com/2018/12/devaudit-open-source-cross-platform.html