Blog Various Thoughts
Various Thoughts
Cancel

Various Thoughts

background image

Thoughts, Opinions and Tips/Tricks (that don’t constitute a post)


  • If you have ADCS within your environment, ensure it has been audited. Take all necessary steps to harden ADCS. This is the easiest and quickest way to DA since 2022.


  • BYOD (bring your own driver) attacks blind EDRs. Using a driver allow attackers to directly communicate with the system’s kernel to disable callback routines and Windows ETW. Mimikatz’s Mimidrv driver is a popular example of this. What if the environment is using Driver Signature Enforcement to enforce only signed drivers? Well, we can use a legitimate driver such as gdrv.sys that is vulnerable to arbitrary memory read/write from userland to disable DSE. There are many other signed drivers that can achieve the same result.


  • Just entering into a Mimikatz shell shows little value when demoing evasion (these posts on LinkedIn keep CISO’s up at night). Accessing LSASS and dumping hashes proves it’s worth.


  • Dominating a domain through ‘1337’ hacking means absolutely nothing if the reporting does not have the same level of professionalism. The primary focus of our job is to provide information of discovered threats/vulnerabilities, not to shame the defenders. We are all on the same team.


  • Normal AD users do not need to add 10 computer to your domains. Consider editing the ms-DS-MachineAccountQuota attribute in AD.


  • I’m not going to debate if phishing assessments are a good or bad idea. Organization leaders need to consider their defenses implemented against these attacks. Keep in mind that attackers don’t care about ethics, but if a user clicking on something causes your domain to be compromised, you probably have bigger problems to worry about.


  • If you’ve rolled out a new security product such as a SIEM or EDR, validate that it is collecting the right data and working as intended. Time after time I’ve seen organizations roll out products only to have default tools go undetected due to misconfigurations. Impacket is a great tool to test this.


  • Install Sysmon on all servers.


  • 2FA is a quick way to stop attackers in their tracks, but 2FA forms are not created equal. Too many organizations have been breached by an attacker spamming push notifications and the victim eventually accepting. Code-based 2FA would’ve made this attack much harder. Teach users that unexpected 2FA notifications should be reported.


  • The most secure 2FA methods are biometric (I know this is not usually feasible), hardware (YubiKey, FIDO, etc), and encryption based (many ‘dark web’ sites use encryption based by having a user decrypt a PGP message when logging in).


  • BitLocker everything.


  • OSINT yourself and organization. Don’t let an attacker discover things that you didn’t know were public.


  • Never use ‘in-browser’ proxies. They usually inject tracking scripts to every request. The biggest offenders are clearnet TOR proxies (.onion.to, .onion.cab, etc). The same goes for some in-app browsers on mobile devices (always use the default browser if possible). Free is never ‘free’. Your data is the product.


  • “Stealer malware” doesn’t just grab credentials and cookies. The new trend is to steal browser configuration data that is sold along with the credentials/cookies. This is to prevent 2FA from being triggered through anomaly detection. Genesis market is most famous for this and is frequently visited by ransomware operators to gain initial access. Do some research on how much data websites can grab just from your browser, and it may surprise you.


  • Unpopular opinion: MS Defender/RTP has come a long way in recent years. For the average personal user (NOT ORGANIZATIONS), it’s a solid product. Yes, custom malware can bypass it, but all AVs can be bypassed with some effort and time.


  • Security needs to have a seat at the table. There’s nothing worse than having to invest in security after a breach. On that note, cyber insurance is a good investment, but it’s not a replacement for environment hardening. If you need justification for a security budget, get the prices for IR investigations and calculate the total cost for your organization.


  • Have a security.txt file or an easy way to report security issues. Yes, you may receive an abundance of “beg bounties” (ex: “I found a broken SPF record, pls pay me $1000!”), but you don’t want to be a company that appears to not take security issues seriously. Work with legitimate researchers and platforms (Bugcrowd, Hackerone, Synack, etc), fix the issues, and reward accordingly.


  • Best practice recommendations should be included in reports. Some pentesters think otherwise, but these findings still provide value. I believe in security through layers and fixing the smallest of issues will improve the overall security posture.


  • Getting breached through macros are soon to be a thing-of-the-past. The new way attackers are gaining initial access are through disk image files such as .iso’s. These auto mount when double-clicked and do not propagate MOTW (Mark-of-the-web). Auto mounting .iso’s should be disabled through the following registry entry:
    reg delete "HKEY_CLASSES_ROOT\Windows.ISO.File\shell" /f


  • Never take CVSS scores at face value. Just because a tool or report spits out a score, it doesn’t mean it’s accurate to YOUR environment. Take a “human” aspect to rate the security of a vulnerability. Nessus classifies eternal blue as a high and not a critical 🤷‍♂️


  • If you are working with a limited security budget, the Windows firewall is a great place to properly segment your network. It’s not the easiest to configure across an environment, but it’s free and can stop attacks in their tracks. Attackers love flat networks. Also, there are open source SIEMs that can be used to help monitor your network.


  • Use separate non-admin accounts for day-to-day tasks and only use Domain Admin accounts when needed.


  • Audit your AD. Make sure there are no unnecessary accounts, groups, permissions, comments, etc… Bloodhound and PingCastle are good tools to do this.


  • Tabletop exercises are a great way to test and find potential issues with your incident response playbooks. Plan for the worst so you have an idea what to do if it happens.


  • Never punish users for security trainings. If they think something is suspicious, make sure they are not afraid to report it.


  • Cobalt Strike is a great C2 platform, but there are many other open source competitors. Other C2’s have Beacon Object File support making them arguably as powerful.


  • Be creative when demonstrating findings. You found XSS? Show how it can be used to steal cookies not just popping an alert box.


  • Red teaming is not the place to “ask for forgiveness, not permission”. You are a guest in the environment and should act accordingly. It’s frustrating getting pushback, but your job is to provide information, not to go rogue.


  • If you want to learn about kernel exploitation, spend some time on video game hacking forums. There are some extremely talented individuals whose primary focus is beating anti-cheat engines.


  • Many big vulnerabilities have been from undocumented features and functionality software.


  • Account lockout policies are not created equal. Apply appropriate policies to appropriate resources. Have a policy or alerting rule, but don’t let an attacker cause DOS from externally locking out your domain.


  • Use WDAC, ASR, DSE, and NAC to harden your environment. Nothing is 100% perfect but layering security controls is the name of the game here.


  • I’m not going to name specific companies, but I am a fan of deception tools. They are not a replacement for other security controls, but provide invaluable ways to detect malicious activity in your environment. These tools can be deployed for free but have additional features if you want to pay.


  • In cybercrime, there is no ‘standard’ attacker or playbook they follow. Some deal with initial access all the way to extortion. Some are just looking for initial access that will be sold. Some are looking to cash-out stolen data.


  • Geo-block resources like your VPN to unexpected countries. Does anyone at your company really need to connect to the VPN from an IP address originating from Azerbaijan at 2 AM? Do this in conjunction with blocking known public VPN IPs and TOR exit nodes. Look into anomaly detection solutions that pick up on abnormal user behavior. This isn’t perfect, but it’ll add yet another hurdler for attackers.


  • Audit user web-browser extensions. Malicious extensions and apps often end up on the ‘official’ browser store.


  • Always report cybercrime incidents to the FBI. Yes, nothing immediate may be done depending on who/where it came from, but a case can still be built and used for future investigations. Insurance policies may require this, and you may receive updates on potential remediation efforts.


  • Your guest Wi-Fi network should not drop users to your internal network. Ensure it’s properly segmented.


  • Don’t trust domains when analyzing network traffic. Many legitimate domains allow for attackers to use in a variety of ways when it comes to phishing, malware, etc. Check out Mr Dox’s LOTS project for a comprehensive list.


  • Vulnerabilities are found by thinking outside the box. There are many motives for attackers. Some are looking for fame, some are looking for money to provide for their families, and others are trying to buy their next Audi R8. The commonality between most is that most spend their days solely focused on trying to achieve their goals. Put yourself in their shoes and try to think like them when hardening your environment.


  • The second a tool gains some level of popularity, it’s going to be statically detected by most AV’s. Even the smallest tweaks can through off these static detections.


  • Incorporate brand reputation into your playbooks. Some attackers just want to cause chaos and don’t care about the monetary gain.


  • Keep a constantly updated inventory of your assets. Be able to act quickly if a breach occurs.


  • Monitor temporary directories and grab any juicy file that may be dropped. Automate this because these files are often quickly deleted.


  • Never inherently trust applications to do what they say they are going to do:

    • Example 1: Thought your browser history was deleted completely? It can be rebuilt from looking at files that are untouched such as the favicon cache database and many other sources.

    • Example 2: Do you believe the website when it says ‘your credentials are securely stored’ on their end? This may not always be the case as many breaches have shown.

    • Example 3: Want to remove a program from your system by uninstalling it? There is probably a way folder sitting in the appdata directory that is not removed.


  • JavaScript isn’t just for the web. If a JS file is dropped on a Windows host, the Windows Based Script Host will execute the script by default. This bypasses all protections such as sandboxing that browsers provide. An attacker can invoke an ActiveX object to interact with the host through WScript.Shell. Combine this with the recent vulnerability (~2022) that allows all files to bypass mark of the web if signed (with an invalid) certificate, and you have a recipe for disaster.


  • Have a plan for insider threats. Attackers are constantly looking for easy ways in such as through employees (browse a cyber crime forum, and you’ll see). Disgruntled employees aren’t the only ones to worry about as financial gain can easily sway loyalty.


  • None of the great bug bounty hunters made $1M+ in a year by following “standard” methodologies. They each have their own method and style in how they go about finding vulnerabilities. If you are interested in bug bounties, create your own methodology and automate as much as possible. Speed is key in programs that have thousands of people after the same goal.


  • External OWA servers are an unnecessary risk in 2022+.


  • Block common password phrases. When I’m cracking passwords, I throw in phrases such as company name, location, etc. to my base wordlist and a have a .rule file perform mutations. You can audit this yourself.


  • Ensure legacy auth is disabled in Office products if not needed. Legacy protocols such as POP3 are not supported by 2FA.


  • If 2FA is enforced, make sure all users are registered. Don’t let an attacker set up 2FA on behalf of someone that may may-not login frequently (ex: janitor, maintenance, etc.).


  • I don’t care that Microsoft recommends keeping IPv6 on. It’s most likely not needed in your environment and is a quick way to get a foothold/escalate privileges in your network.


  • If phishing, buy domains and create a basic fake website. Try to wait some time before using. This will improve the domain reputation and will be more likely to bypass email filters. Do not use a lookalike domain as these usually get instantly flagged. Lookalike users will also get flagged, so be sure to use a unique username.


  • Email attachments won’t usually get past phishing filters. Make the phish as basic as possible and add a link to a site you control. Adding multiple ‘depths’ to the site helps. This is where you can have the user download the malicious file, use HTML smuggling, or phish for credentials.


  • Basic auth can be an effective way to phish/use with Responder.py. It’s pretty easy to implement in GoPhish.


  • Subdomain takeover is a bigger deal than most people think. Depending on the setup, you can modify cookies and bypass CORS/CSP if you control a subdomain of the target site. A low finding from a web-app test could be easily a critical if you control a subdomain.


  • If you are red teaming and using RDP, delete the RDP cache files after you are done in: %APPDATA%\Microsoft\Terminal Server Client\Cache


  • If you are a defender, be careful when uploading suspected malware to VirusTotal or any other public sandboxes. Uploads are downloaded by researchers, security companies, and others. If the malware contains identifiable information (like a ransomware readme.txt), disclosure of your breach may be leaked way before your org is ready.


  • Don’t let a breach be the reason you implement logging. Be sure that the necessary logs are collected so that if something does happen, you can quickly identify the source and scope of the breach. Logging should be network wide (workstations, servers, cloud, the legacy system no-one touches, etc.).


  • Want a CVE? Install a local WordPress and poke around at plugins that can be installed.


  • If you don’t disable PowerShell on standard workstations (AppLocker is good for this), be sure that you don’t have outdated PowerShell versions on systems (ex. V2). These versions provide almost no logging and will most likely be used by attackers.


  • Don’t burn your access by querying AD if you’re in a highly restrictive environment. There’s a wealth of cached AD information on a standard user’s workstation. <TODO: Finish tool to pass in cached AD info to Bloodhound>


  • It’s important to work with the client to identify what the goal of the engagement is (it’s often not always getting DA).


  • Don’t test payloads/implants on VirusTotal. If you do, you’re going to have a bad time :/. The submissions will be sent to security companies and be alerted on. Use a site like antiscan.me. These won’t usually have the ‘big players’ but will still provide insight.


  • If phishing a client that uses KnowBe4, add a X-PHISHTEST header to the email. This simple addition may bypass their mail filter. For defenders, follow their recommendation and change the default header to a unique token to permit legitimate KnowBe4 traffic. To check for KnowBe4, pull the DNS records for a domain. Often, there will be a knowbe4-site-verification TXT record.


  • RDP == Ransomware Delivery Protocol. Lock it down and monitor it in your environment. This is the most convenient way to move laterally in a network.


  • Static detection is very different from dynamic detection. Getting a shell is the easy part, what you do after is the hard part.


  • If you have an idea for a project or tool, don’t abandon it if you find that someone’s already created something similar. Put your own spin on the idea.


  • The PASSWD_NOTREQD AD flag does not mean that the account does not have a password. It means that it could be blank, or is not required to follow the domain password policy. In practice, I’ve never come access a PASSWD_NOTREQD account that had a blank password, but they are out there.


  • Double-check Google’s Sponsored links. There is almost no verification done on Google’s end, and cyber-criminals often advertise lookalike domains to spread malware.


  • Be creative when phishing. Most phishing sites will quickly get flagged if you do not take the necessary steps. Some examples include removing suspicious keywords, converting the html content to unicode, using a framework like React, randomize the endpoints per IP, and having the page just be a screenshot (of the real site) with just a login form.


  • Teaching users to hover over links to see where they are actually going to is often taught in security awareness training. Using Javascript, the hovered anchor tag can be spoofed and the user will be redirected to a different site. This usually dosen’t apply to emails as JavaScript is often blocked by default, but can be in other malicious means. Where does this link go (hover over it): Google?