001spartan

The vaccines are not failing. They are incredibly effective at preventing infections _and_ reducing severity of breakthrough infections. The Delta variant is more easily transmitted and more likely to cause breakthrough infections, but that does not account for the majority of the surge [0]. It's largely a surge amongst unvaccinated populations, buoyed by a smaller proportion of breakthrough infections. The ease with which Delta spreads, combined with relaxed restrictions on gatherings and masking, accounts for the surge in infections.

Despite the decline in vaccine effectiveness (I've seen conflicting studies of how much this has changed), they're still incredibly effective compared to any other protection we have at the moment.

None of this changes the fact that people are going to continue to die until a higher proportion of the population receives a COVID vaccine -- and that we _can_ mitigate this through other measures. None of these things lead me to the conclusion that we should return to normal and accept an increased healthcare system burden and death rate.

[0] https://www.cdc.gov/mmwr/volumes/70/wr/mm7034e1.htm?s_cid=mm...

Vaccines work. Vaccinated people are far less likely to contract COVID, and when they do they are far less likely to require healthcare resources beyond the standard treatments for someone who has the flu (stay home, rest, treat symptoms as needed).

Social distancing and masking work. They reduce the possibilities for spread between people -- not perfectly, but enough to reduce it to a manageable level for our current healthcare resources.

Saying that our current measures to combat the virus don't work is disingenuous at best, and a blatant disregard for everything we've learned from the past year and a half at worst.

I agree! But the issue is that where these processes exist they are not designed for the scale of the current pandemic, are too inconsistent when implemented, and rely on spare personnel that do not currently exist.

Building more hospitals is a long-term process. Training medical personnel is a long-term process. Emergency measures intended to bridge the gap are untenable politically, and people are dying because of it. Thousands of them per day.

The answer to this is not to say 'we can't fix the underlying issues right now, so we're not going to do anything'. The answer is to take measures that we _can_ implement until those longer-term solutions can come into play.

Returning to normal is a terrible idea when COVID patients are overwhelming hospitals across the world. How can things be normal if our healthcare systems are nearing collapse?

You might be willing to accept the risk of getting sick on your behalf, but by advocating a return to 'normal' before we have the capabilities to deal with this virus, you are advocating for putting even more stress on healthcare systems across the globe already on the verge of failure. There are patients in heavily-impacted areas who cannot access healthcare for other life-or-death concerns because hospitals are crumbling under the workload of COVID cases.

The article even states this; COVID is likely to reach endemic status eventually, but we are still nowhere near that. Ignoring it will have enormous costs on vulnerable populations -- even more than it already has.

That's why those of us in the security industry have to say "compliance is not security" whenever PCI is brought up.

Even Windows gets this wrong at times, with several UAC bypass techniques exposed by auto-elevating binaries. Still, Microsoft has done a great deal of work with the Windows privilege model to prevent things like this, and these issues are steadily being resolved.

1. Dozens (if not hundreds) of tools are used. It's all about personal preference, and what you're used to. Personally, I don't often use most of the tools you mentioned except Mimikatz; I use a commercial framework paired with many open source or private PowerShell scripts and .NET tools.

2. Something like evilginx2 can provide man in the middle functionality for stealing MFA tokens, or I try to find endpoints that have misconfigured or absent MFA.

3. It depends on the engagement. We like assumed breach scenarios because they're more effective for the time and money involved, but clients want entirely black-box engagements fairly often as well. Otherwise, I'll focus on using OSINT to develop a phishing target list, assuming I do basic scans against the organization's external network footprint and don't find anything egregious.

4. It's all about experience. You have to come up against the tools, and then see what works. It's really a lot of trial and error, though a lot of common bypass techniques will work against multiple products. There's no one-size-fits-all bypass.

5. Twitter, public Slack channels, and research performed by myself and my coworkers.

6. Learn soft skills. It's easy to teach someone how to do the technical part of the job, but you have to be able to communicate it to stakeholders. Technically, you should focus on the areas that interest you, but ensure that it's something used by the types of clients you're doing work for. It doesn't help to know the latest and greatest Linux attacks if none of your clients even know what Linux is. It doesn't help to be a badass web application pentester if you're expected to be able to move through a large Active Directory environment. Personally, I focus on Windows and Active Directory environments.

It is sexual assault to expose someone to unwanted sexual advances. It's the same thing as flashing. Why should someone be exposed to a picture of another's genitals when it's unwanted? It's forcing someone else to engage in a sexual way without consent, even if the only reaction is to block the sender, or look away.

The Amazon Prime Visa gives 5% back on Amazon purchases.

Automated tools can only discover so much, because there are always edge cases that tools won't be able to analyze or exploit. Human creativity is a big part of penetration testing, whether it's web application assessments or other types of penetration testing, because tools have false positives, and can't come up with creative bypasses for security measures in the way a human can.

You can definitely automate many parts of testing, especially enumeration steps, but any security professional knows that a tool is no substitute for a knowledgeable hacker.

I can't speak for DNSDumpster, but a common technique I use to do subdomain enumeration is just brute forcing with a wordlist. By enumerating with a large enough wordlist, you can discover matching subdomains for a target domain.

I think it's about on par with what developers earn for the same skill bracket and location. As a pentester, I don't think it's necessarily about having _more_ skill than developers, it's just a different set of skills.

When we use this technique (known as "tailgating") to break into client sites, we always recommend that the organization try to foster a culture of "trust, but verify". This means employees stopping people if they don't have their badges displayed, or showing unrecognized people to the reception desk, or closing the door behind you to make sure the next person has to badge in, even if they have a badge that looks plausible.

It's not an easy thing to learn to challenge people, but it's vital to maintain a good physical security posture. Employees need to feel comfortable challenging those who they don't recognize, and making sure that employees are part of an organization's security team is important.

That's very true. In many cases, that's even _perfectly fine_. Not every organization needs enough physical security to deter a determined attacker. The ones that do hire people like Sophie (or me), and take the lessons to heart. Even if the organization doesn't make changes to their physical security posture as a result, they know what to be aware of, and they know where their weaknesses are.

A lot of our security--both network and physical--is based on the illusion of security. One of the most important things that penetration testing does is to make organizations aware of the issues, to put the bug in their ear to remind them that security is important, and shouldn't be an afterthought. We see lots of organizations make material improvements to their security as a result of red team exercises. We also see a lot of organizations that don't. It's disheartening when that happens, but I like to think I help make a difference. The next data breach might be mitigated by our recommendations, or even prevented entirely.

I need about fifteen seconds of quality time with an unlocked computer before it belongs to me. Devices like the USB Rubber Ducky ( https://hakshop.com/products/usb-rubber-ducky-deluxe ) make it trivial to compromise unlocked systems within seconds. Stealing info can then be done at your leisure, from anywhere you have internet access.

Just because she skipped over some unimportant parts of the story doesn't mean she didn't have plenty of time after being shown around the building to accomplish her objectives. She does address this, too:

> I took FOREVER looking around this office space, and eventually they said their goodbyes because they had to go back to work. They had a strict policy of escorting visitors. But I had been seen walking around with trusted insiders so no one questioned me.

> I was free to take my time. I made myself at home. My main objective at this site was to weasel my way into private corner offices.

If you did this job, you would not be surprised by the ease with which you can pull off these sorts of things. I've been doing this for a couple years now, and it's terrifyingly easy to compromise data or physical security for organizations that really should know better.

This is exactly why penetration testers and red teams do these types of engagements. We like to emphasize that organizations need to assume they've been compromised by someone, and they need to constantly keep that in mind when they build security policies and technical controls. You can never keep a determined attacker out, but you can limit the damage that they can do, and make them spend more time getting in.

It also appears to be using common Windows lateral movement techniques based on credential stealing (namely WMI and PsExec), in addition to EternalBlue.

If you leave your wifi on when you're not connected to a network, your device will automatically start sending probes for known networks. For instance, if your home wifi network is called "duggan's network", and you're at an airport across the world, your phone will advertise to all devices in the vicinity that you're looking for "duggan's network".

Then, a malicious person can advertise an SSID of "duggan's network", and in certain cases, could get your device to connect to that network without you interacting with your device, or even realizing that something has changed.

Ask most infosec people, and they'll tell you that they _always_ turn off their wifi when they leave a trusted location.

The F-16 is close to 40 years old, and the F-15 has been in service for 40 years as of 2016.

As someone who has very strong feelings about sites not letting me choose secure passwords, or storing them insecurely...no.

Fines for storing passwords insecurely and getting breached, sure. This is already handled by PCI/HIPAA, but could definitely stand to be improved. Prison time? There's no possible way that would end well.

Fines for "anyone whose password can be brute forced from one of these leaks"? So that means 80% of people out there would be given "substantial fines". Not going to happen.

I'll take your word for it. I guess I conflate them because they're both utterly abhorrent worldviews.

Weev is a well-known white supremacist. I would take anything he says with a hefty portion of salt.

Yes, this shows that antivirus is trivial to bypass. However, antivirus is not the last word in endpoint protection. While this method can be used to get otherwise ordinary payloads past antivirus, behavior-based detection and application whitelisting can be used to prevent many of these attacks.

I had the UltraPro as my work laptop at my last employer, and I despised it. The keyboard was impossible to work with (typos, keys didn't always register), and it felt flimsy and cheap. Not what I would expect from a system that cost as much as a MacBook. The only benefit was the powerful specs.

I've been a vim user for a few years (I wouldn't consider myself a power user, though). I switched to Spacemacs last year, and I don't regret it at all. The power of the Emacs ecosystem mixed with excellent hotkeys (on top of vim's better keybinds already) is a formidable combination.

That may be, but it's still a backdoor by definition. There are better ways to allow a vendor to access a device, and a hardcoded password that nobody else knows about is not exactly a "front door".

Correct, you can't use the password alone, but the challenge/response method used is readily available online, and easy to implement.

It uses a kind of challenge/response, where the device provides a salt that is used with a hardcoded password for that account. It seems to look like 'AK1' + base64(salt|SHA1(salt|password|Fortinet magic)) according to http://fossies.org/linux/john/src/FGT_fmt_plug.c, a cracker for Fortigate passwords.