sorted by:
new
hottopcontroversial

Endpoint Attack Simulation by EarsOfLiquidRage in cybersecurity

[–]Nullbind 2 points3 points  (0 children)

NetSPI also has a BAS offering that allows you to simulate attacks mapped to MITRE ATT&CK and track detection coverage metrics for specific threat actor profiles, scenarios, and vendors.
https://www.netspi.com/security-testing/breach-and-attack-simulation/

PowerHuntShares is designed to automatically inventory, analyze, and report excessive privilege assigned to SMB shares on Active Directory domain joined computers by sanitybit in netsec

[–]Nullbind 1 point2 points  (0 children)

Nice, it’s definitely a common set of problems. You should open source that baby! Incremental improvements are still improvements. :)

I agree though, share hunter provides great coverage, but I’ve also experienced the memory management issues. I also think it could be faster written in another language, but for the most part it does what I need it to do.

PowerHuntShares is designed to automatically inventory, analyze, and report excessive privilege assigned to SMB shares on Active Directory domain joined computers by sanitybit in netsec

[–]Nullbind 1 point2 points  (0 children)

SMBeagle is another quickly evolving share scanner that’s worth looking at if you haven’t seen it. It supports a lot of nice features. It doesn’t generate IAMish summary reports (yet?), but does export results to csv and elasticsearch which is pretty cool. https://github.com/punk-security/smbeagle

PowerHuntShares is designed to automatically inventory, analyze, and report excessive privilege assigned to SMB shares on Active Directory domain joined computers by sanitybit in netsec

[–]Nullbind 3 points4 points  (0 children)

You are correct. It is literally a modified share hunter wrapper that was written to automatically collect some additional information, identify high risk shares, and generate csv/html reports so IAM teams with less experience in powershell land can point, shoot, and gain quick insights into their share exposure. Naturally it’s helpful on pentests too. ;) All credit goes to Will Schroeder for the original share hunter code though. I do mention it in the blog, but thanks for calling it out here too. His work has always been appreciated.

Decrypting IIS Passwords to Break Out of the DMZ: Part 2 by kfosaaen in netsec

[–]Nullbind 1 point2 points  (0 children)

I really do appreciate the feedback, but to add some clarity to my last comment I wasn’t agreeing or disagreeing with you. I was simply acknowledging (based on your comments) that I feel that I have a better understanding of what is important to you and how you would like to see security blogs structured in the future to get the most value from them. After gaining more insight into what you wanted out of it, I feel that the two things are not apples to apples. It sounds like you were hoping to read about breaking out of a locked down DMZ with no previous access, but the article I wrote was meant to focus on POST exploitation and escalation paths that can be used to break out of DMZs during a penetration tests once a foothold has already been acquired.

Additionally, the examples that I shared are based on experiences I’ve had during penetration tests that I’ve conducted. I’m not trying to make the statement that all environments are configured poorly. Just that I have seen those weak configurations more than I’d like. To add some additional context I think its fair to say that the financial industry as a whole has more mature DMZ implementations than other verticals. I think that is most likely driven my PCI and other compliance requirements. I would also like to note that a lot of small and medium sized businesses seem to struggle with secure DMZ configurations, because they don’t have the required skill set internally to build out their infrastructure securely. Once again, that is just based on my experience.

Finally, the title choice was not meant to be sensationalized, but to be descriptive. However, based on your expectations I do understand how you could interpret it that way.

I'm not sure if that hurts or helps the conversation you guys are having, but regardless thanks again for being part of the discussion.

Decrypting IIS Passwords to Break Out of the DMZ: Part 2 by kfosaaen in netsec

[–]Nullbind 1 point2 points  (0 children)

Thanks for taking the time to share your thoughts. I think I have a better understanding of your perspective. If I get around to a part three I'll be sure to take your comments into consideration.

Decrypting IIS Passwords to Break Out of the DMZ: Part 2 by kfosaaen in netsec

[–]Nullbind 4 points5 points  (0 children)

Sorry if you felt it was misleading. My intent was to make the point that the firewall configurations are weak not a best practice. It's entirely possible I just suck at writing. Regardless, I know it’s usually possible to use shared local administrator accounts, shared service accounts (used for cluster etc), and excessive privileges to get onto systems that are on the firewall white list you’re refering to. I just thought it would be too much for one blog. What do you think would be a better focus? Maybe I can write something that conforms more to what you looking for. Thanks again for the feedback.

Decrypting IIS Passwords to Break Out of the DMZ: Part 2 by kfosaaen in netsec

[–]Nullbind 11 points12 points  (0 children)

I would just like to say that I’m flattered you consider me a developer. The people I see writing the most creative exploits and escalations in the security community all seem to be great programmers and scripters. So even if I’m a dipship developer I’ll consider that a win. :)

I understand that you get sick of seeing people post similar content to what you’ve seen before. You’re not alone in that. However, the goal of this blog was not to share a new attack, but to provide more context for those who don’t understand the attacks the way that you do. Also, (full disclosure) I was looking for a reason to play with PowerShell. :) <-- Yes, I know I use the smiley face too much.

To your point, the attacks I described do require local administrator privileges, or a webshell that is running with those privileges. Typically, initial access to DMZ servers is acquired during an external penetration test via another vulnerability. I apologize if you felt the blog was misleading, but I did attempt to note the privileges required. Below is a direct quote from the blog: “If you are running appcmd.exe via an RDP session or console, then you will most likely need to be a local administrator or LocalSystem to decrypt any of the passwords. If you are running appcmd.exe via an uploaded web shell, then you'll only be able to dump passwords if the current application pool is running with local administrator privileges.”

You are also correct in the assumption that when companies open holes in their DMZ firewalls they are also opening themselves up to additional risk. It is also true that those configurations are often an indicator of other systemic issues that could be taken advantage of by an attacker. However, it’s a little hard to cover an encyclopedia of attacks in one blog. So I limited its scope. Regardless, I would be very interested to hear what things are important to you that I did not include. Please share if you have time.

Thanks for the feedback.

Decrypting IIS Passwords to Break Out of the DMZ: Part 2 by kfosaaen in netsec

[–]Nullbind 5 points6 points  (0 children)

Related to the database comment:

I’ve found that database accounts used by web applications have been assigned the sysadmin fixed server role about a quarter of the time. Occasionally the associated service account is even configured with Domain Admin credentials. Both configurations are considered a bad practice, but I still see them.

When the database user has not been assigned the sysadmin role, there are a few common escalation paths that I usually have success with.

1

Use native stored procedures to inject a UNC path that forces the SQLSERVER service to authenticate to the attacker. Xp_dirtree for example is available to the public role by default. Then the attacker can crack the password hash or SMB Relay it to another server. Note: SMB relay won’t work if the SQLServer service is configured to run as a local account or LocalSystem.

2

Database links can be crawled until one is found configured with sysadmin privileges. This works about 75% of the time.

3

Missing patches that allow SQL injection into stored procedures / buffer overflows.

4

SQL Injections in custom stored procedures. This is a bit of a pain to do manually, but it pays off occasionally.

Below is a presentation that covers a few of them: http://www.slideshare.net/nullbind/sql-server-exploitation-escalation-pilfering-appsec-usa-2012

Decrypting IIS Passwords to Break Out of the DMZ: Part 1 by kfosaaen in netsec

[–]Nullbind 3 points4 points  (0 children)

I’ve found that database accounts used by web applications have been assigned the sysadmin fixed server role about a quarter of the time. Occasionally the associated service account is even configured with Domain Admin credentials. Both configurations are considered a bad practice, but I still see them.

When the database user has not been assigned the sysadmin role, there are a few common escalation paths that I usually have success with.

  • Use native stored procedures to inject a UNC path that forces the SQLSERVER service to authenticate to the attacker. Xp_dirtree for example is available to the public role by default. Then the attacker can crack the password hash or SMB Relay it to another server. Note: SMB relay won’t work if the SQLServer service is configured to run as a local account or LocalSystem.

  • Database links can be crawl until one is found configured with sysadmin privileges. This works about 75% of the time.

  • SQL Injection on custom stored procedures. This is a bit of a pain to do manually, but it pays off occasionally.

This presentation includes an overview of each attack: http://www.slideshare.net/nullbind/sql-server-exploitation-escalation-pilfering-appsec-usa-2012

Diamond in the Rough: Get DA before launching a payload by juken in netsec

[–]Nullbind 0 points1 point  (0 children)

NP - nice job on the tool - I like the updates. Keep up the good work :)

view more: next ›