Login
One of the major struggles in bug bounty hunting is to collect and analyze data during reconnaissance, especially when there are a lot of tools around but very few that offer actually useful results. The job of eliminating false positives and unrelated data from your recon becomes harder as the size of your target increases.
Most popular tools used by bug bounty hunters like Knockpy, Sublist3r, and Subfinder are command line based and often difficult to use when the size of the target becomes bigger. With a lot of results provided, it becomes harder and longer to filter out the most important ones, remove unnecessary results, and pick the right investigation vector. However, some companies are still trying to simplify the recon process by rethinking old approaches and implementing UI/UX, and technical features.
Spyse is that reconnaissance automation framework that every bug bounty hunter should test at least once.
At the core of reconnaissance is OSINT and data analysis, one needs to analyze a target and map out its infrastructure efficiently.
To become familiar with your target's attack surface, you need to perform recon in a proper manner and gather information about its assets. For that, it's crucial to enumerate all the assets belonging to the investigated target (domains, sub-domains, IP address, etc) and related assets, basically everything that is closely connected to the main target.
By doing it precisely, anyone can easily spot the low hanging fruits such as sub-domain takeovers that can have a huge impact.
Spyse is the tool that simplifies this process and makes your routine work easier by storing all needed information in one place and pointing where to look first.
Be the fastest in reaching your target's assets. Bug Bounty Hunting is a rat race – the faster you are able to fully analyze your target's attack surface, the more the chances of scoring a bounty. There is competition in every field, but with close to a million bug bounty hunters working across platforms – at any given time there may be hundreds of thousands of bug bounty hunters working on a specific target of a bug bounty program, which leads us to the biggest hurdle – time.
If you are not able to optimize your reconnaissance workflow and reduce the time you spend on your targets, you will lag behind the others. If you are at par with the others, and stick to the usual tools, you still stay average – but with an industry-leading solution like Spyse, you not just become fast but faster than the others.
With Spyse, it's just a plug-and-play operation. It has all the necessary data about your targets already collected, even before you begin to hunt on a target, and the advanced search filter mechanism is way better than most command-line based open source tools..
If you run the traditional tools just after you get access to a new target, it might take days to just collect the data on larger targets and, yet more time to analyze and make sense of it. Spyse's advanced search feature can get you to the same results in less than a fraction of a second.
You can search for information about your target domain name (say, Target.com), from Spyse's collection of over 4.5B domain name records, all indexed.
 |
| Search your target in over 25TB database. |
Spyse is not just another cybersecurity search engine, it's an advanced yet simple Reconnaissance framework of sorts. Unlike Censys and Shodan, Spyse offers a user friendly filter which doesn't make use of advanced query syntax, dorks, etc.
Spyse's advanced search feature is aimed to be simple to use, user friendly yet efficient and precise. The advanced search lets you hit your goal by tuning the search parameters to exactly the targets you are after – minimizing false positives and inaccurate results.
 |
| Advanced Search Filter to find Apache servers belonging to a target |
For example, if you are looking for Apache servers in a particular target's infrastructure, you can set the search filters to match your target's Organization name (domain name or, AS or, IP ranges) and add another filter, Site info > HTTP Header > Name and Value to Server and Apache respectively, and let the backend handle the rest for you.
 |
| Spyse has collected and indexed over 4.5B domains |
Spyse has gathered data of over 217.1M hosts with open ports, indexed 4.5B domains, 66M SSL/TLS certificates, 371M email-related data, 143.7K vulnerabilities, 1.2M organizations and more. Learn more about their data statistics here.
Having to deal with so much data on large scope bug bounty targets during recon makes it incredibly difficult and tedious to scan these assets, and perform reconnaissance at scale. However, Spyse collects and updates this data on a regular basis, and indexes it, making it easier to filter out small bits of information that are important for your recon.
The whole database updates once a week except for some types of data that do not change too often, like domains.
Spyse has taken care of it. It is difficult to manage vast amounts of gathered information. Some hunters who have advanced development knowledge prefer to make their own automation with a proper backend and database of targets, yet they tend to miss out on lots of data and find it hard to manage, & correlate it.
However, with Spyse you don't need advanced development skills, because it crawls, collects and connects all the data about your targets.
Developing a web application to manage the whole process might be beneficial but it will cost you lots of work. Nevertheless, you have Spyse that can be implemented with other tools simply through the API connection. This should save the time you would have otherwise spent running only manual command line tools.
You can also filter your target's assets by response code (for example – 200 status code, for valid request), which helps you quickly find interesting assets from a large number of target subdomains and domains. This is a very handy feature while doing recon on any target, as it gives you a quick overview of the publicly accessible assets of your target.
 |
| Browsing targets by status code (for example, 200 status code) |
Spyse has a very handy data export feature that lets you quickly export your scan data in JSON and CSV format. Whether you like to see your data in Excel or, implement it in your own application or, visualize it using ElasticSearch, Spyse has got you covered. It also makes it easier for you to use the exported data with other custom tools (most tools support JSON/CSV data, as its a common format).
 |
| Export reconnaissance data in multiple formats – JSON or, CSV |
Spyse can easily handle a lot of information. With conventional tools, you can miss a lot of information while working on large targets but with Spyse – it's no longer a problem!
Spyse not just gathered an incredibly large dataset of assets, It structured all of them in an understandable and intuitive way with loads of conclusions that indicate vulnerable or just interesting parts of the target.
Find out how everything is connected:
 |
| Spyse IP data output |
Easily locate related data:
 |
| Spyse related data |
Understand vulnerability level of the target and explore found vulnerabilities:
 |
| Instant Vulnerability assessment of the target |
Benefit from ready made conclusion based on data analysis:
 |
| Ready-made conclusions made by Spyse |
The web interface lets you visualize your target's data more efficiently and in a better manner than other tools. This helps you take decisions easily, and find vulnerable assets more easily than using conventional tools. With bigger targets like Yahoo having as many as 143.4k sub-domains, using conventional tools like subfinder becomes harder, but with Spyse you can visualize the relationships between different assets, and decide where to spend your time while hunting on the target's assets.
Spyse's advanced data gathering solution gives you an extremely intuitive interface to search through loads of data and offers you a visual approach to dealing with large amounts of recon information.
Instead of moving back and forth between different tools that give inaccurate data, using the stunning UI makes it easier to wade through a sea of OSINT data. Use it for quick target overview alone or in combination with other tools and remove all unnecessary amnual work.
In conclusion, explore a wide variety of Spyse’s tools that will help you to find exact piece of information.
Most necessary tools:
A new incident involving a cryptocurrency exchange made the headlines, the India-based cryptocurrency exchange suffered a security incident, threat actors leaked sensitive data of 325K users on the Dark Web.
Leaked data includes names, e-mails, mobile numbers, encrypted passwords, user wallet details, order details, bank details, KYC details (PAN number, passport numbers) and deposit history.
The researcher Rajshekhar Rajaharia analyzed the leaked data, it is a MongoDB database of 6GB that contains three backup files with BuyUcoin data.
Trading in #cryptocurrency? 3.5 Lakh Users data including me leaked From @buyucoin. The leaked data contains Name, Email, Mobile, bank account numbers, PAN Number, Wallets Details etc. Again didn't informed to affected users by company.
— Rajshekhar Rajaharia (@rajaharia) January 21, 2021
Story – https://t.co/rUrfSQ96Z1#InfoSec pic.twitter.com/1xFOtLcd8F
The data was discovered by at threat intelligence firm Kela Research, it was leaked by a well-known threat actor known as ShinyHunters.
BuyUcoin has yet to confirm the security incident, it only announced the launch of an investigation.
Since data appeared on the dark web, Buyucoin has released two official statements on the incident.
“In the mid of 2020, while conducting a routine testing exercise with dummy data, we faced a ‘low impact security incident’ in which non-sensitive, dummy data of only 200 entries were impacted. We would like to clarify that not even a single customer was affected during the incident.” wrote Shivam Thakral, the company CEO.
Rajaharia was disappointed with the official statement and published the following tweet:
https://t.co/TNK1uXQKDL
— Rajshekhar Rajaharia (@rajaharia) January 21, 2021
Such an irresponsible statements by @buyucoin. I am your registered and #KYC Verified user. You leaked my own data too. Please change your statement ASAP. What if someone used my account in any illegal activity. Please Inform your users Right Now. #InfoSec pic.twitter.com/dJGN5VesEH
Then Buyucoin CEO published the following statement:
“We are thoroughly investigating each and every aspect of the report about malicious and unlawful cybercrime activities by foreign entities in mid-2020.”
In November, grocery e-commerce website Bigbasket suffered a data breach, the details of over 20 million people were offered for sale on the darkweb for over $40,000.
“Now, the same hacker group is asking about $10,000 in Bitcoin for the BigBasket database and is also selling the three companies’ databases,” Rajaharia added.
“There is a strong connection between all these recent data leaks, including BigBasket.”
Recently data stolen from other Indian companies were offered by the same threat actors for sale in hacker forums, including JusPay, ClickIndia, ChqBook, and WedMeGood.
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
(SecurityAffairs – hacking, data breach)
The post Cryptocurrency exchange BuyUcoin hacked, data of 325K+ users leaked appeared first on Security Affairs.
NetOps, SecOps and CloudOps — you’ll learn about it all on today’s episode featuring Raju Chekuri, CEO of NetEnrich. Raju shares his career journey, discusses his work helping new tech and cybersecurity startups, and explains why clinging blindly to a five-year plan can be a recipe for disaster.
0:00 - Intro
2:12 - Getting started in cybersecurity
3:38 - How the security landscape has changed
8:27 - Complexity and scope of cybersecurity
10:05 - 16+ years at NetEnrich
14:30 - Going beyond governance to do it right
17:30 - Strategies for upping ITOps along with business
22:50 - Examples of companies doing it right
24:55 - Helping startups become successful
30:45 - Keys to a solid business plan
33:42 - Mentorships in security and startups
36:25 - Being an entrepreneur & humanitarian
40:15 - What's next for NetEnrich?
46:18 - Outro
We’re also excited to share a new, hands-on training series called Cyber Work Applied. Every other week, expert Infosec instructors and industry practitioners teach you a new cybersecurity skill and show you how that skill applies to real-world scenarios. You’ll learn how to carry out different cyberattacks, practice using common cybersecurity tools, follow along with walkthroughs of how major breaches occurred and more. And it's free! Click the link below to get started.
– Learn cybersecurity with our FREE Cyber Work Applied training series: https://www.infosecinstitute.com/learn/
– View Cyber Work Podcast transcripts and additional episodes: https://www.infosecinstitute.com/podcast
Raju founded NetEnrich in 2004 after a successful IT career as an entrepreneur, visionary and business leader in Silicon Valley. He has led the company’s growth as SaaS for digital operations while innovating for AIOps and cybersecurity solutions. Raju is currently the chairman of the board at OpsRamp, a spin-off from NetEnrich. Previously, he founded Velio Communications, Inc., and led it to its acquisition by LSI Logic and Rambus in 2003. Raju earned an MBA at St. Mary’s College of California and a Bachelor of Technology at Kakatiya University.
About Infosec
Infosec believes knowledge is power when fighting cybercrime. We help IT and security professionals advance their careers with skills development and certifications while empowering all employees with security awareness and privacy training to stay cyber-safe at work and home. It’s our mission to equip all organizations and individuals with the know-how and confidence to outsmart cybercrime. Learn more at infosecinstitute.com.
On Saturday, Tesla sued the former employee Alex Khatilov for allegedly stealing 26,000 confidential documents, including trade secrets. The software engineer transferred the sensitive files to his personal Dropbox account.
Khatilov stole files from the internal network of the carmaker, the documents were related to the Warp Drive software. The Warp Drive is a proprietary back-end software system used to automate business processes.
According to the complaint, the former employee started stealing the company files a few days after he was hired.
“The complaint says he began working for Tesla on December 28, 2020, and almost immediately began uploading files and scripts (written in a programming language called Python) to his Dropbox account. Tesla confronted him about his alleged theft on January 6th.” states CNBC.
The defendant claimed that he “forgot” he had downloaded the files and was not able to explain the reason for his downloads.
“The Tesla Trade Secrets are extremely valuable to Tesla, and would be to a competitor. Access to the scripts would enable engineers at other companies to reverse engineer Tesla’s automated processes to create a similar automated system in a fraction of the time and with a fraction of the expense it took Tesla to build it.” states the complaint. “Third-party engineers could not compose these scripts based on public information, especially with such minimal time and effort. The scripts also would inform competitors of which systems Tesla believes are important and valuable to automate and how to automate them – providing a roadmap to copy Tesla’s innovation.”
Khatilov told to New York Post that he had unintentionally moved the files to Dropbox.
“I’ve been working for, like, 20 years in this industry, and I know what sensitive documents are about, and I never, ever tried to access any of those, or steal it” said Khatilov. “I didn’t know that there was 26,000 files there.”
The company has a different opinion, it accused the former employee of trying to cover his tracks.
“Even worse, it became apparent that Defendant had brazenly attempted to destroy the evidence by hurriedly deleting the Dropbox client and other files during the beginning of the interview when investigators were attempting to remotely access his computer.” states the complaint.
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
(SecurityAffairs – hacking, Tesla)
The post Tesla sues former employee for allegedly stealing sensitive docs appeared first on Security Affairs.
This is a proof of concept program to escalate privileges on a Windows host by abusing WSUS. Details in this blog post: https://www.gosecure.net/blog/2020/09/08/wsus-attacks-part-2-cve-2020-1013-a-windows-10-local-privilege-escalation-1-day/ It was inspired from the WSuspect proxy project: https://github.com/ctxis/wsuspect-proxy
Privilege escalation module written by Maxime Nadeau from GoSecure
Huge thanks to:
The tool was tested on Windows 10 machines (10.0.17763 and 10.0.18363) in different domain environments.
RSS Security Usage: WSuspicious [OPTION]...
Ex. WSuspicious.exe /command:"" - accepteula - s - d cmd / c """"echo 1 > C:\\wsuspicious.txt"""""" /autoinstall
Creates a local proxy to intercept WSUS requests and try to escalate privileges.
If launched without any arguments, the script will simply create the file C:\\wsuspicious.was.here
/exe The full path to the executable to run
Known payloads are bginfo and PsExec. (Default: .\PsExec64.exe)
/command The command to execute (Default: -accepteula -s -d cmd /c ""echo 1 > C:\\wsuspicious.was.here"")
/proxyport The port on which the proxy is started. (Default: 13337)
/downloadport The port on which the web server hosting the payload is started. (Sometimes useful for older Windows versions)
If not specified, the server will try to intercept the request to the legitimate server instead.
/debug Increase the verbosity of the tool
/autoinstall Start Windows updates automatically after the proxy is started.
/enabletls Enable HTTPS interception. WARNING. NOT OPSEC SAFE.
This will prompt the user to add the certificate to the trusted root.
/help Display this help and exit
The ILMerge dependency can be used to compile the application into a standalone .exe file. To compile and compile the application, simply use the following command:
dotnet msbuild /t:Restore /t:Clean /t:Build /p:Configuration=Release /p:DebugSymbols=false /p:DebugType=None /t:ILMerge /p:TrimUnusedDependencies=true
ZDNet first reported that the well-known threat actor ShinyHunters has leaked the data of more than 2.28 million users registered on the dating site MeetMindful,
The threat actor leaked the data for free download on a publicly accessible hacking forum.
“The leaked data, a 1.2 GB file, appears to be a dump of the site’s users database.” reported ZDNet.
Leaked data included real names, email addresses, city, state, and ZIP details, body details, dating preferences, marital status, birth dates, latitude and longitude, IP addresses, bcrypt-hashed account passwords, Facebook user IDs, and Facebook authentication tokens.
The availability of such data expose users of the dating site to several cybercriminals activities, including sextortion and scams.
ZDNet pointed out that the leaked dump doesn’t include the messages exchanged by the registered users.
MeetMindful has yet to confirm the alleged data breach.
Thousands of users of the hacker forum have viewed the thread where the MeetMindful data was shared, this means that it is already circulating in the hacking community.
Early this week, ShinyHunters leaked the details of millions of users registered on Teespring, and in November he leaked data of the Pluto TV service.
In July, ShinyHunters offered on a hacker forum a collection of databases stolen from eighteen companies, over 386 million user records available online.
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
(SecurityAffairs – hacking, MeetMindful)
The post Hacker leaks data of 2.28M users of dating site MeetMindful appeared first on Security Affairs.
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
(SecurityAffairs – hacking, newsletter)
The post Security Affairs newsletter Round 298 appeared first on Security Affairs.
The computer chipmaker Intel Corp. confirmed that an internal error is the cause of a data leak that prompted it to release a quarterly earnings report early.
Intel chief financial officer, George Davis, told The Financial Times that the chipmaker believed a threat actor stole financially sensitive information from its site and for this reason, it anticipated the release of a quarterly earnings report to avoid that attackers could use this data for operations on the stock market.
The company confirmed that attackers did not compromise the corporate network.
““An infographic was hacked off of our PR newsroom site,” the newspaper quoted Davis as saying. It quoted an unnamed company spokesperson as saying Intel was notified that the graphic was circulating outside the company.” reported the Associated Press.
Now the company excluded the hack, and confirmed the incident was caused by an internal error, below the statement issued by the company:
“the URL of our earnings infographic was inadvertently made publicly accessible before publication of our earnings and accessed by third parties.” reads the Intel’s statement. “Once we became aware of the situation we promptly issued our earnings announcement. Intel’s network was not compromised and we have adjusted our process to prevent this in the future.”
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
(SecurityAffairs – hacking, Intel)
The post Chipmaker Intel reveals that an internal error caused a data leak appeared first on Security Affairs.
ATMMalScan is a commandline tool for Windows operating systems version 7 and higher, which helps to search for malware traces on an ATM during the DFIR process. This tool examines the running processes of a system, as well as the hard disk, depending on the specified file path. To scan a system, a user with standard rights is sufficient. However, ATMMalScan provides the best results with administrator privileges.
Currently ATMMalScan does not support codepages that require Unicode, this means Windows operating systems that are set to e.g. Cyrillic or Chinese characters, no representative result can be guaranteed.
Make sure at least Visual C++ Redistributable for Visual Studio 2015 has been installed on the ATM, you like to scan.
Step1 => Scan process memory and disk. ===> Check if Admin privileges are available on the device for best results!
Step2 => ATMMalScan detected a Malware called XFS_DIRECT in a process, gives details about the thread and its rules matches. Further a full processmemory dump has been saved to disk, to catch the malicious process, its modules, as well as its stack and heap pages.
Step3 => Dump can be found here => .\Dump
Step4 => Open dumpfile with Windbg and extract the ATM malware to disk using ".writemem"
Step5 => Repair the dumped PE with one of your favorite PE-Fixers and start analysing the malware in detail.
Telesforo Aviles (35) is a former ADT employee that pleaded for accessing the cameras he installed at the home of the company’s customers.
Every time the man worked at the home of a customer in the Dallas area where an attractive woman was living, he added his personal email address to customers’ “ADT Pulse” accounts, to have real-time access to the video feeds from the cameras.
“This defendant, entrusted with safeguarding customers’ homes, instead intruded on their most intimate moments,” said Acting U.S. Attorney Prerak Shah. “We are glad to hold him accountable for this disgusting betrayal of trust.”
Aviles faces up to five years in federal prison for having illegally accessed roughly 200 accounts more than 9,600 times, in a period of more than four years.
Mr. Aviles admitted having regularly added his own email address to customers’ ADT Pulse accounts to watch women naked and couples engaged in sexual activity for his own sexual gratification, they said.
“The defendant used his position of employment to illegally breach the privacy of numerous people. The FBI works with our law enforcement partners to thoroughly investigate all cyber intrusions and hold criminals accountable for their actions,” said FBI Dallas Special Agent in Charge Matthew J. DeSarno.
ADT discovered Aviles’s activity on April 23 when a customer informed the company of the presence of an unauthorized email on their ADT account.
In April 2020, ADT terminated Aviles and reported him to law enforcement.
“Recently, a customer called to let us know there was an unauthorized email on their ADT account. The security and privacy of our customers is our top priority, and we immediately began an internal investigation.” reads a statement published by the company. “Unfortunately, our investigation revealed that during a service visit, one of our Dallas-area technicians had added his personal email address to this customer’s account to gain unauthorized access, and he had done the same thing during service visits with other customers in the Dallas area.”
The company contacted the impacted customers and apologized to them.
“We apologize to the customers affected by the actions of this former employee and deeply regret this incident,” ADT’s statement said. “The ADT mission is to help protect and connect people with the things they love most. Fully earning this trust back may take time, but nothing is more important to us and to those who have served our customers under the ADT banner for the last 145 years.”
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
(SecurityAffairs – hacking, privacy)
The post ADT employee pleads guilty for accessing cameras installed by the company appeared first on Security Affairs.
Output from the kernel log after compiling and running example/open1_hook.c
xnuspy is a pongoOS module which installs a new system call, xnuspy_ctl, allowing you to hook kernel functions from userspace. It supports iOS 13.x and 14.x on checkra1n 0.12.2 and up. 4K devices are not supported.
Requires libusb: brew install libusb
Run make in the top level directory. It'll build the loader and the module. If you want debug output from xnuspy to the kernel log, run XNUSPY_DEBUG=1 make.
After you've built everything, have checkra1n boot your device to a pongo shell: /Applications/checkra1n.app/Contents/MacOS/checkra1n -p
In the same directory you built the loader and the module, do loader/loader module/xnuspy. After doing that, xnuspy will do its thing and in a few seconds your device will boot. loader will wait a couple more seconds after issuing xnuspy-getkernelv in case SEPROM needs to be exploited.
Sometimes a couple of my phones would get stuck at "Booting" after checkra1n's KPF runs. I have yet to figure out what causes this, but if it happens, try again. Also, if the device hangs after bootx, try again. Finally, marking the compiled xnuspy_ctl code as executable on my iPhone X running iOS 13.3.1 is a bit spotty, but succeeds 100% of the time on my other phones. If you panic with a kernel instruction fetch abort when you execute your hook program, try again.
xnuspy will patch an enosys system call to point to xnuspy_ctl_tramp. This is a small trampoline which marks the compiled xnuspy_ctl code as executable and branches to it. You can find xnuspy_ctl's implementation at module/el1/xnuspy_ctl/xnuspy_ctl.c and examples in the example directory. That directory also contains xnuspy_ctl.h, a header which defines constants for xnuspy_ctl. It is meant to be included in all programs which call it.
You can use sysctlbyname to figure out which system call was patched:
size_t oldlen = sizeof(long);
long SYS_xnuspy_ctl = 0;
sysctlbyname("kern.xnuspy_ctl_callnum", &SYS_xnuspy_ctl, &oldlen, NULL, 0);
This system call takes four arguments, flavor, arg1, arg2, and arg3. The flavor can either be XNUSPY_CHECK_IF_PATCHED, XNUSPY_INSTALL_HOOK, XNUSPY_REGISTER_DEATH_CALLBACK, XNUSPY_CALL_HOOKME, or XNUSPY_CACHE_READ. The meaning of the next three arguments depend on the flavor.
XNUSPY_CHECK_IF_PATCHEDThis exists so you can check if xnuspy_ctl is present. Invoking it with this flavor will cause it to return 999. The values of the other arguments are ignored.
XNUSPY_INSTALL_HOOKI designed this flavor to match MSHookFunction's API. arg1 is the UNSLID address of the kernel function you wish to hook. If you supply a slid address, you will most likely panic. arg2 is a pointer to your ABI-compatible replacement function. arg3 is a pointer for xnuspy_ctl to copyout the address of a trampoline that represents the original kernel function. This can be NULL if you don't intend to call the original.
XNUSPY_REGISTER_DEATH_CALLBACKThis flavor allows you to register an optional "death callback", a function xnuspy will call when your hook program exits. It gives you a chance to clean up anything you created from your kernel hooks. If you created any kernel threads, you would tell them to terminate in this function.
Your callback is not invoked asynchronously, so if you block, you're preventing xnuspy's garbage collection thread from executing.
arg1 is a pointer to your callback function. The values of the other arguments are ignored.
XNUSPY_CALL_HOOKMEhookme is a small assembly stub which xnuspy exports through the xnuspy cache for you to hook. Invoking xnuspy_ctl with this flavor will cause hookme to get called, providing a way for you to easily gain kernel code execution without having to hook an actual kernel function.
There are no arguments for this flavor.
XNUSPY_CACHE_READThis flavor gives you a way to read from the xnuspy cache. It contains many useful things like kprintf, current_proc, kernel_thread_start, and the kernel slide so you don't have to find them yourself. For a complete list of cache IDs, check out example/xnuspy_ctl.h.
arg1 is one of the cache IDs defined in xnuspy_ctl.h and arg2 is a pointer for xnuspy_ctl to copyout the address or value of what you requested.
For all flavors except XNUSPY_CHECK_IF_PATCHED, 0 is returned on success. Upon error, -1 is returned and errno is set. XNUSPY_CHECK_IF_PATCHED does not return any errors.
XNUSPY_INSTALL_HOOKerrno is set to...
EEXIST if: arg1.ENOMEM if: kalloc_canblock or kalloc_external returned NULL.ENOSPC if: xnuspy_tramp structs or reflector pages. These data structures are internal to xnuspy. This should never happen unless you are hooking hundreds of kernel functions at the same time.EFAULT if: current_map()->hdr.vme_start is not a pointer to the calling processes' Mach-O header.ENOENT if: map_caller_segments was unable to find __TEXT and __DATA for the calling process.EIO if: mach_make_memory_entry_64 did not return a memory entry for the entirety of the calling processes' __TEXT and __DATA segments.errno also depends on the return value of vm_map_wire_external, mach_vm_map_external, copyin, copyout, and if applicable, the one-time initialization function. An errno of 10000 represents a kern_return_t value that I haven't yet taken into account for (and a message is printed to the kernel log about it if you compiled with XNUSPY_DEBUG=1).
If this flavor returns an error, the target kernel function was not hooked. If you passed a non-NULL pointer for arg3, it may or may not have been initialized. It's unsafe to use if it was.
XNUSPY_REGISTER_DEATH_CALLBACKerrno is set to...
ENOENT if: If this flavor returns an error, your death callback was not registered.
XNUSPY_CALL_HOOKMEerrno is set to...
ENOTSUP if: hookme is too far away from the page of xnuspy_tramp structures. This is determined inside of pongoOS, and can only happen if xnuspy had to fallback to unused code already inside of the kernelcache. In this case, calling hookme would almost certainly cause a kernel panic, and you'll have to figure out another kernel function to hook.If this flavor returns an error, hookme was not called.
XNUSPY_CACHE_READerrno is set to...
EINVAL if: arg1 does not represent anything in the cache.arg1 was KALLOC_EXTERNAL, but the kernel is iOS 13.x.arg1 was KALLOC_CANBLOCK, but the kernel is iOS 14.x.arg1 was KFREE_EXT, but the kernel is iOS 13.x.arg1 was KFREE_ADDR, but the kernel is iOS 14.x.errno also depends on the return value of copyout and if applicable, the return value of the one-time initialization function.
If this flavor returns an error, the pointer you passed for arg2 was not initialized.
While writing replacement functions, it was easy to forget that I was writing kernel code. Here's a couple things to keep in mind when you're writing hooks:
__TEXT segment. You will panic if, for example, you accidentally call printf instead of kprintf. You need to re-implement any libc function you wish to call. You can create function pointers to other kernel functions and call those, though.PAGE_SIZE expands to vm_page_size, not a constant. You need to disable PAN (on A10+, which I also don't recommend doing) before reading this variable or you will panic.Skimming https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/KernelProgramming/style/style.html is also recommended.
For some reason, logs from os_log_with_args don't show up in the stream outputted from the command line tool oslog. Logs from kprintf don't make it there either, but they can be seen with dmesg. However, dmesg isn't a live feed, so I wrote klog, a tool which shows kprintf logs in real time. Find it in klog/. I strongly recommend using that instead of spamming dmesg for your kprintf messages.
Bugs are inevitable when writing code, so eventually you're going to cause a kernel panic. A panic doesn't necessarily mean there's a bug with xnuspy, so before opening an issue, please make sure that you still panic when you do nothing but call the original function and return its value (if needed). If you still panic, then it's likely an xnuspy bug (and please open an issue), but if not, there's something wrong with your replacement.
Since xnuspy does not actually redirect execution to EL0 pages, debugging a panic isn't as straightforward. Open up module/el1/xnuspy_ctl/xnuspy_ctl.c, and right before the only call to kwrite_instr in xnuspy_install_hook, add a call to IOSleep for a couple seconds. This is done to make sure there's enough time before the device panics for logs to propagate. Re-compile xnuspy with XNUSPY_DEBUG=1 make -B and load the module again. After loading the module, if you haven't already, compile klog from klog/. Upload it to your device and do stdbuf -o0 ./klog | grep shared_mapping_kva. Run your hook program again and watch for a line from klog that looks like this:
shared_mapping_kva: dist 0x780c replacement 0x100cd780c umh 0x100cd0000 kmh 0xfffffff0311c0000
If you're installing more than one hook, there will be more than one occurrence. In that case, dist and replacement will vary, but umh and kmh won't. kmh points to the beginning of the kernel's mapping of your program's __TEXT segment. Throw your hook program into your favorite disassembler and rebase it so its Mach-O header is at the address of kmh. For IDA Pro, that's Edit -> Segments -> Rebase program... with Image base bubbled. After your device panics and reboots again, if there are addresses which correspond to the kernel's mapping of your replacement in the panic log, they will match up with the disassembly. If there are none, then you probably have some sort of subtle memory corruption inside your replacement.
xnuspy will manage this for you. Once a process exits, all the kernel hooks that were installed by that process are uninstalled within a second or so.
Most function hooking frameworks have some minimum length that makes a given function hookable. xnuspy has this limit only if you plan to call the original function and the first instruction of the hooked function is not B. In this case, the minimum length is eight bytes. Otherwise, there is no minimum length.
xnuspy uses X16 and X17 for its trampolines, so kernel functions which expect those to persist across function calls cannot be hooked (there aren't many which expect this). If the function you want to hook begins with BL, and you intend to call the original, you can only do so if executing the original function does not modify X17.
xnuspy_ctl will perform one-time initialization the first time it is called after a fresh boot. This is the only part of xnuspy which is raceable since I can't statically initialize the read/write lock I use. After the first call returns, any future calls are guarenteed to be thread-safe.
This is simplified, but it captures the main idea well. A function hook in xnuspy is a structure that resides on writeable, executable kernel memory. In most cases, this is memory returned by alloc_static inside of pongoOS. It can be boiled down to this:
struct {
uint64_t replacement;
uint32_t tramp[2];
uint32_t orig[10];
};
Where replacement is the kernel virtual address (elaborated on later) of the replacement function, tramp is a small trampoline that re-directs execution to replacement, and orig is a larger, more complicated trampoline that represents the original function.
Before a function is hooked, xnuspy creates a shared user-kernel mapping of the calling processes' __TEXT and __DATA segments (as well as any segment in between those, if any). __TEXT is shared so you can call other functions from your hooks. __DATA is shared so changes to global variables are seen by both EL1 and EL0. This is done only once per process.
Since this mapping is a one-to-one copy of __TEXT and __DATA, it's easy to figure out the address of the user's replacement function on it. Given the address of the calling processes' Mach-O header u, the address of the start of the shared mapping k, and the address of the user's replacement function r, we apply the following formula: replacement = k + (r - u)
After that, replacement is the kernel virtual address of the user's replacement function on the shared mapping and it is written to the function hook structure. xnuspy does not re-direct execution to the EL0 address of the replacement function because that's extremely unsafe: not only does that put us at the mercy of the scheduler, it gives us no control over the scenario where a process with a kernel hook dies while a kernel thread is still executing on the replacement.
Finally, the shared mapping is marked as executable* and a unconditional immediate branch (B) is assembled. It directs execution to the start of tramp, and is what replaces the first instruction of the now-hooked kernel function. Unfortunately, this limits us from branching to hook structures more than 128 MB away from a given kernel function. xnuspy does check for this scenario before booting and falls back to unused code already in the kernelcache for the hook structures to reside on instead if it finds that this could happen.
*not exactly what happens, what actually happens produces that effect
This module completely neuters KTRR/AMCC lockdown and KPP. I don't recommend using this on a daily driver.
I do my best to make sure the patchfinders work, so if something isn't working please open an issue.
Sophos researchers that investigated the recently uncovered crypto-mining campaign targeting SQL servers with MrbMiner malware believe that it was conducted by an Iran-based company.
In September, a group of hackers launched brute-force attacks on MSSQL servers with the intent to compromise them and install crypto-mining malware dubbed MrbMiner.
According to security firm Tencent, the team of hackers has been active over the past few months by hacking into Microsoft SQL Servers (MSSQL) to install a crypto-miner. The threat actors used a botnet to target thousands of MSSQL installations with the MrbMiner. The name of the miner comes after one of the domains used by the group to host their malicious code.
Once the hackers gained access to a system, they downloaded an initial assm.exe file to achieve persistence and to add a backdoor account for future access. Upon creating the account, the malicious code connects to the C2 to download a Monero (XMR) cryptocurrency miner that runs on the local server.
The Sophos researchers explained that they did not collect enough evidence to determine exactly the attack chain, the speculate the attackers used techniques similar to the ones employed in campaigns distributing the Kingminer, Lemon_Duck, or MyKings miners,
“The MrbMiner cryptojacking payload included a kernel-level device driver (WinRing0x64.sys), and a miner executable named Windows Update Service.exe to obfuscate its purpose. The executable was a modified version of the XMRig miner.” reads the post published by Sophos.
The malicious payload was designed to target Windows systems, but experts also found a Linux build of the miner on several servers they analyzed.
Sophos researchers discovered that cryptocurrency data was sent to wallets on the poolmrb.xyz and mrbpool.xyz domains as well as to the pool.supportxmr.com domain. The experts discovered that the cryptominer was downloaded from the vihansoft.ir, mrbfile, and mrbftp domains and communicated with the poolmrb/mrbpool domains.
The analysis of the configuration of the miner, the IP addresses involved in the campaign, and domains used by the threat actors led to a software company based in Iran.
“A lot of the records relating to the miner’s configuration, its domains and IP addresses, point to a single point of origin: a small software company based in Iran.” continues the analysis. “The payload location and the C2 server addresses are both hardcoded into the downloader. One domain, used as both a C2 and a payload server, was vihansoft.ir, registered to a software development company based in Iran. Payloads were also downloaded directly from the same IP address used to host vihansoft.ir (and from a few other domains which contained the string “mrb,” such as mrbfile.xyz).”
“We found the miner downloads in the web root of the vihansoft domain, in a repository under a now-shuttered Github user account, and on the mrbfile.xyz and mrbftp.xyz domains, as well as on a small number of IP addresses,” continues Sophos.
Experts noticed that the same username used for the GitHub account was present on the machine used to compile the miner. Despite it is not possible to retrieve any WHOIS information for both the “mrb” domains nor vihansoft, they use the same WHOIS privacy service, WhoisGuard, based in Panama, to conceal the domain ownership data.
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
(SecurityAffairs – hacking, mrbminer)
The post MrbMiner cryptojacking campaign linked to Iranian software firm appeared first on Security Affairs.
ZMap is a fast single packet network scanner designed for Internet-wide network surveys. On a typical desktop computer with a gigabit Ethernet connection, ZMap is capable scanning the entire public IPv4 address space in under 45 minutes. With a 10gigE connection and PF_RING, ZMap can scan the IPv4 address space in under 5 minutes.
ZMap operates on GNU/Linux, Mac OS, and BSD. ZMap currently has fully implemented probe modules for TCP SYN scans, ICMP, DNS queries, UPnP, BACNET, and can send a large number of UDP probes. If you are looking to do more involved scans, e.g., banner grab or TLS handshake, take a look at ZGrab, ZMap's sister project that performs stateful application-layer handshakes.
The latest stable release of ZMap is version 2.1.1 and supports Linux, macOS, and BSD. We recommend installing ZMap from HEAD rather than using a distro package manager.
Instructions on building ZMap from source can be found in INSTALL.
A guide to using ZMap is found in our GitHub Wiki.
TheHackerNews revealed in an exclusive that the security provider SonicWall was hacked on Friday.
The company was targeted with a coordinated attack on its internal systems, threat actors exploited zero-day vulnerabilities in their VPN solutions, such as NetExtender VPN client version 10.x and Secure Mobile Access (SMA).
“The San Jose-based company said the attacks leveraged zero-day vulnerabilities in SonicWall secure remote access products such as NetExtender VPN client version 10.x and Secure Mobile Access (SMA) that are used to provide users with remote access to internal resources.” reported TheHackerNews.
SonicWall told The Hacker News that they believe the coordinated attack was conducted by highly sophisticated threat actors exploiting.
The Hacker News was the first media to receive reports that SonicWall’s internal systems were unavailable since Tuesday and that the source code hosted on the company’s GitLab repository was accessed by the attackers.
SonicWall has immediately launched an investigation into the incident. and would provide additional updates as more information emerges..
Below the list of affected products shared by THN:
SonicWall published an Urgent Security Notice for NetExtender VPN Client 10.X, SMA 100 Series vulnerability that includes a series of recommendations for its customers.
“Recently, SonicWall identified a coordinated attack on its internal systems by highly sophisticated threat actors exploiting probable zero-day vulnerabilities on certain SonicWall secure remote access products. The impacted products are:
The NetExtender VPN client and SMB-oriented SMA 100 series are used for providing employees/users with remote access to internal resources. The SMA 1000 series is not susceptible to this vulnerability and utilizes clients different from NetExtender.” states the urgent security notice published by the security provider.
FOR SMA 100 SERIES the vendor recommends to use a firewall to only allow SSL-VPN connections to the SMA appliance from known/whitelisted IPs or configure whitelist access on the SMA directly itself.
FOR FIREWALLS WITH SSL-VPN ACCESS VIA NETEXTENDER VPN CLIENT the security firm recommends organizations using VERSION 10.X to disable NetExtender access to the firewall(s) or restrict access to users and admins via an allow-list/whitelist for their public IPs.
SonicWall also recommends enabling multi-factor authentication on all SONICWALL SMA, Firewall & MYSONICWALL accounts.
This incident could potentially have a significant impact on multiple organizations that use the above products. This is the last incident in order of time that impacted security vendors, recently MalwareBytes revealed that it was hit by SolarWinds attackers, the same that compromised FireEye, Microsoft, and Crowdstrike.
The security provider confirmed that the following products are not affected:
If you want to receive the weekly Security Affairs Newsletter for free subscribe here.
(SecurityAffairs – hacking, SonicWall)
The post Security firm SonicWall was victim of a coordinated attack appeared first on Security Affairs.
