Is it still possible to brute force online?

[deed]

I assume brute forcing isn't as easy as it used to be since the popularity of the technique has been increasing these past few years.

I was trying to mess around and brute forcing my own live mail account, using numerous brute forcing softwares, and it SEEMS that it is just plain impossible...

I've of course tried VIA SMTP protocol but didn't work. Then I tried by https-post-form, but the variables/options needed are far too complicated to get.

Maybe there's a way I'm not aware of? Or Brute Forcing online accounts has been entirely cornered by security?

[0E 800]

Find a away to get passed the Completely Automated Public Turing test to tell Computers and Humans Apart. (CAPTCHA)

[madf0x]

It's still possible but most places with even a fraction of a brain implement rate limiting of all stripes and colors, so your odds are stacked against you if thats your tactic of choice. Of course there are still plenty of second rate and obscure services out there that can still be attacked by brute forcing logins.

At least brute forcing logins are mostly dead. Obviously the concept of bruteforcing is merely a tactic used to solve a wide range of problems, and many of them are still very relevant to security.

Since you were talking about  email, I should point out you'd probably have a better time trying to figure out the password recovery security questions most email providers have, or just social engineer in some form the victim. Not even necessarily to get them to tell you their password, but getting them to click on some evil link of yours, run some evil executable of yours, or open some evil file for a commonly unpatched client software like adobe reader.

If you do really want to stick to brute forcing, youre going to want to at least establish that your tool or code can make a  successful connection first. As 0E 800 hinted at, for a lot of forms that may mean solving some captcha, especially if the service later detects the automated behavior (as you can imagine, some places like google are more on the ball with this). Once you can get a successful login to a test account, then you need to find the lockout policies, usually its some rate policies such as no more than 3 attempts within a minute, or no more that 10 attempts in a single hour, or both. Dont assume those numbers though, merely an example on my part. Once you know the lockout rate you can throttle your tool better, cause slow is better than not at all. Depending on your target, it may be worthwhile to instead try a small amount of passwords and attempt them on a range of accounts instead of hammering one at a time. In lax windows networks(talking more like a company intranet here) this can be a nice tactic to avoid a lot of newbie account lockout settings set in Active Directory(of course if its a lax windows networks, there are a lot of more standard time tested methods that dont rely on brute forcing )

Ultimately in my opinion, it takes far too much time and effort to get results brute forcing account info through some login form. If you're really committed you can eventually get some results but the way I see it its like trying to get inside a locked house. The front door doesnt budge so you decide to bash your forehead on the wall till you can make a hole to climb in, when instead you could have just opened a window.

[inability]

Depending on your target, it may be worthwhile to instead try a small amount of passwords and attempt them on a range of accounts instead of hammering one at a time.

This is absolutely true. Doing a username/password list attack with a large number of accounts and a small number of passwords uses less effort and will net you the low-hanging fruit in a shorter amount of time.

Bruteforcing in the sense of trying every single possible password against a target account, or even a dictionary attack, is largely neutralised on websites due to the presence of rate limiting and CAPTCHAs. You're not going to find an even moderately big online service that doesn't have some form of protection against these attacks.

The closest thing to bruteforcing that is actually prevalent now is the use of combolists to score accounts on various websites. The idea is that username/password combos are obtained (most of the time through the compromise of some site) and tools are used along with thousands of open proxies to try these combos on websites such as Netflix and Hulu+. The idea, as you can imagine, is to get premium content for free.

[ShadowCloud]

I think the other posts on this thread has really provided you with vital information with regards to what you are trying to achieve, what the limitations are and what you are better of attempting.

With that being said, there is one piece of advice you might want to consider for things that fall outside this scope but that still pertains to brute force in a web environment.  A fundamental difference between brute force on your local environment and brute force over web is latency and RTT (round trip time) if a web server needs 3 seconds to process your request and send the response back to you, you are severely limited in your attack rate.  In most cases it makes sense to launch a distributed brute force attacks from multiple locations.  So instead of attempting to run 200 attacks per minute from a single machine, run 20 attacks per minute from 10 machines.

(I'm mostly referring to API and web services being vulnerable, they are mostly designed for code so the captcha problem presented above does not present themselves here.  I've seen multiple systems that do everything right on their front end login, but the web service authentication fails to adhere to these same policies)

[0E 800]

So a script that opened Firefox went to website inputs login and uses a word list checks for success or captcha, if not, wait, try again next password on list, check success or captcha, if not wait, try again, check for success or capcha, if captcha returns true then, exit firefox, change proxy/node, open firefox, repeat.

Run script spread across 50+ vm farm.

However you still run into the issue that not all sites are configured the same and you risk locking a users account which also notifies the user of such attempt being made. So you would need to do a lot of testing and finessing the script and customize it for each campaign.

I am not a professional, just my point of view.