EvilZone

Dude you have command execution.

Literally hundreds of different ways you could just setup a shell and call it good.

Stop focusing on getting the treasure, treat it like a normal box. You have execution, setup a shell or some means of persistence, THEN go goodie shopping.

Just whatever you do dont make the primary difficulty be from 'being traced in x seconds' like every other game in the genre does.

"exact same processor" if its the same processor one works the other doesnt, its not a chipset problem, his processor either got shocked while putting it together or was DOA to start with.

"So I swap processors between the machines and my machine is able to POST just fine with her processor but her machine does not POST with my processor."

You misread the post, the processor in question worked fine in his machine, both processors failed on the machine with issues. Ergo, the processor is not the problem here, either the motherboard is, or some unrelated issue is.

I second motherboard incompatibility, but it isn't over yet. What exactly is included in the build? Gimmie yo parts list

More specifically give us a pcpartpicker list.

heck it'll probably point out any compatibility issues you have before you can even give us the details

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.

I'm reminded of the darpa project I think HD Moore worked on to test new grant paperwork, was basically a wardialler on speed built for about 50$ that could call every number in a given country in less than an hour. There was some amusing speculation about how many bombs in development one could set off by hitting cell phone triggers early. How long semi-random country wide cell phone calls would terrorists stand before abandoning that trigger method.

Other than maybe toying with that, there really isn't much a hacker could do to truly damage an organization like ISIS without discretely handing data over to authorities and letting them make the judgement call.

Even something 'big' but misguided like announcing the locations of ammo depots and training groups could easily, and likely, turn into a case of 'we already knew about that, and thanks for giving the terrorists a heads up when we had an OP planned in three days when a high value target would have been inspecting the camp, yup, real helpful anon'.

People like anonymous dont realize that in a true information warefare its impossible to be an independent and successful third party. If you could there would be literally ZERO reason for the CIA/NSA to work with the GHQ on ANYTHING. In an information war if you have an enemy, you HAVE to side with your enemy's enemies or else you simply risk helping your enemy instead. At least, if you plan to take objectable action with the data you gain.

1.1T is Huge. That file would cover every possible combination that regular people use for wifi and demonstrate to my friends how bad password they have.
I can delete 150 000 since I covered every year from 1900 until 2000. Plus I wanted to have all combinetions even smoler then 8 char. But I will add to script to remove every combination that have less then 8.
File have 45 000 lines only with names, surnames, middlenames and words that people generaly use. Everything else is birthday combinations and numbers with special simbols.

I literally can't think of a WPA implementation that would even accept password lengths of 7 or less, so if your focusing on WPA, you might as well cut those lengths out. Also keep in mind that many tools have issues with opening large files like that, so when you go to generate it, split it into numbered chunks so you can feed them into your tools incrementally.

File most def wouldn't cover every possible password used by regular people. More and more APs are setup with a default semi-unique password that you are simply not going to reliably get in a generated password list(outside of flukes or abusing vendor specific bad pseudo-random passwords). Just something to keep in mind. Not to mention as per WPA specification, the ssid is mixed into the crypto, making rainbow tables unfeasible except for some very common ssids, with that in mind remember that its gunna take some serious horsepower to power through a terabyte plus sized list.

You may be better off collecting a few different raw lists and mixing and sorting them manually, so that way you test real world passwords first. Essentially assume that if someone has been proven to use a given password once, someone else is using the same password elsewhere. Far easier to guess that then to try and generate a bunch of 'unique' passwords. Of course the exception being for targeted password generation. However, in the context of wifi security targeted password generation is only reliably useful against business, companies, etc that are more likely to standardize their passwords for easy employee use.  Home users are gunna be using either the default complex password, or using a common password you can find in other lists. Thats just assuming they aren't picking out good secure passwords in the first place.


All this being said, theres a good reason why a lot of serious wifi security research goes into avoiding passwords whenever possible or abuse implementations.