Huntress saw Oracle SQLi used to deploy rare khunt toolkitKhunt enabled OS commands, credential theft, and registry hive exfiltrationDefense includes input sanitation and more Someone managed to pair the classic SQL Injection (SQLi) attack with a nifty database trick to take over the underlying system entirely. Security researchers Huntress, who were called in to investigate the incident, said the investigation first showed a classic, decades-old technique called an SQL injection attack: a public-facing application with an Oracle backend accepted and executed SQL commands input into a form without checking whether that input was valid or not.This granted the attackers the ability to upload a database-resident, posts-exploitation toolkit named khunt. This technique is something of a cyber-white whale: it’s been widely discussed but rarely seen in the wild.How to defend“What happened next, however, raised our eyebrows,” Huntress said. “After performing SQL injection, the threat actor managed to upload a database-resident, post-exploitation toolkit named khunt. This is a technique that's previously been discussed and described over the years, including via a technique described as oraexec – however, the use of the technique in the wild has rarely been documented.”As a toolkit, khunt granted the attackers multiple capabilities, including loading cmd.exe on the system and running arbitrary OS commands, steal usernames and passwords, listing, reading, searching, and checking file sizes (essentially looking around the compromised system), unzipping files, and more. Of all the things they could have done, the attackers opted to run a PowerShell command and invoke the Windows Registry tool, copying the SAM, SECURITY and SYSTEM registry hives. They can later use the copies to extract and decode password hashes for local accounts on the system, the researchers explained. To defend against such attacks, Huntress recommends making sure the forms aren’t injectable. “Practice proper input sanitization and query parameterization for any inputs,” they warned. “It's also important to ensure that users with the ability to execute queries aren't overprovisioned.” Even if someone manages to pull off SQL injection, user accounts should not be capable of authoring Java sources or running stored procedures.