Security Boulevard

Authors/Presenters:Punkcoder

Our sincere appreciation to DEF CON, and the Presenters/Authors for publishing their timely DEF CON 32 erudite content. Originating from the conference’s events located at the Las Vegas Convention Center; and via the organizations YouTube channel.

Permalink

The post DEF CON 32 – AppSec Village – Navigating The Cyber Security Labyrinth Choose Your Own Security Adventure appeared first on Security Boulevard.

As organizations adopt more modern application strategies, APIs are increasingly important for enabling seamless communication and data exchange. However, this interconnectedness also introduces more significant security risks. APIs are gateways to sensitive information, making them prime targets for attackers. This can result in data breaches, business disruptions, and reputational damage.

To tackle these challenges, Salt Security, a leader in API security, has partnered with Dazz, an application security posture management expert. This collaboration combines the strengths of both platforms to deliver a comprehensive solution that offers exceptional protection and remediation against API threats.

Proactive Risk Reduction and Automated Remediation

Integrating Salt Security and Dazz offers a comprehensive API and Application Security Posture Management (ASPM) solution. Salt Security utilizes its patented platform, powered by AI and machine learning, to analyze API traffic, enabling effective discovery, posture governance, and threat protection. Meanwhile, Dazz consolidates security exposure data across code, cloud, applications, and infrastructure, prioritizing the most critical findings.

This potent combination allows for proactive risk reduction by identifying and addressing API vulnerabilities before they can be exploited. Automated root cause analysis traces API misconfigurations and vulnerabilities back to their origin in the code. This gives developers the context to quickly resolve issues and prevent them from reoccurring.

Reduced MTTR and Improved Security Posture

Combining Salt Security's precise API threat detection with Dazz's automated remediation capabilities allows organizations to reduce the Mean Time to Remediation (MTTR) significantly. This integration improves security by providing continuous visibility, proactive threat detection, and automated responses. As a result, it strengthens defenses and lowers the chances of successful attacks.

Key Features and Benefits

The Salt Security and Dazz integration offers a range of benefits:

• Comprehensive API and Application Security Posture Management: Addresses threats specific to APIs and general application vulnerabilities, providing complete visibility and control over your entire attack surface.
• Proactive Risk Reduction: Identifies and mitigates API vulnerabilities before they can be exploited.
• Automated Root Cause Analysis: Traces API misconfigurations and vulnerabilities back to their source, enabling efficient remediation and preventing recurring issues.
• Reduced Mean Time to Resolution (MTTR): Accelerates the resolution of vulnerabilities through automated remediation capabilities.
• Improved Security Posture: Enhances your overall security posture with continuous visibility, proactive threat detection, and automated remediation.

Conclusion

Integrating Salt Security and Dazz provides a robust solution for organizations aiming to enhance their API and application security. By combining the capabilities of both platforms, organizations can gain comprehensive visibility, proactively address risks, automate remediation, and strengthen their overall security posture.

If you want to learn more about how the Salt and Dazz integration provides best-in-class API security, contact Salt and Dazz today!

The post Salt Security and Dazz: A Powerful Partnership for API Security appeared first on Security Boulevard.

TL;DR: BOFHound can now parse Active Directory Certificate Services (AD CS) objects, manually queried from LDAP, for review and attack path mapping within BloodHound Community Edition (BHCE).

Background

My last BOFHound-related post covered the support and usage strategies for Beacon object files (BOFs) enabling the manual collection of data required for BloodHound’s AdminTo and HasSession edges, among others. This brief post will cover the addition of AD CS object parsing (shoutout to GitHub user P-aLu for collaborating on the update) and some queries to get you started.

But first, to clear up some misconceptions…

BOFHound is not a BOF!

Surprised and/or confused? Somewhat angry? Yes, this is the most common misconception I hear about the tool. BOFHound is not a BOF implementation of SharpHound; rather, it is a Python script that runs completely offline from your target network. I repeat — it is neither a BOF, nor a tool that actively enumerates a target Active Directory (AD) network. If this is not news to you, enlightened reader, consider skipping ahead to The Good Stuff.

So What Does BOFHound Do (and Why on Earth Did You Name It That)?

BOFHound was born from repeated red team engagements in a large AD network where the blue team would flag SharpHound and other “loud” methods of LDAP enumeration. (In this environment, “loud” meant an expensive LDAP query — a query that returned a number of results over a threshold the client had determined to be indicative of attacker reconnaissance.) The team I worked with at the time adjusted by primarily relying on the ldapsearch BOF, part of TrustedSec’s situational awareness collection, for LDAP reconnaissance. This had two main benefits:

• It grants the operator full control over the LDAP query filter, meaning discretion can be used to avoid static query strings tied to common offensive tools and leveraged in detections [1, 2]
• The operator can specify a limit on the result count, so that the query returns no more than N entries; this is helpful when consciously avoiding expensive queries (result pools can also be narrowed with search scope, targeted query filters, or through a search base)

Here are some downsides to solely relying on this approach for LDAP enumeration:

• Queries only return text-based results (i.e., there is no visualization or BloodHound-like graph that many operators prefer)
• Identifying ACL abuses is essentially impossible with this approach alone
• Trying to keep track of and organize relationships between objects, like group memberships (let alone nested memberships), by hand in text/Excel files is difficult

The bigger the target environment is, the more these problems are amplified. These also all sound like problems that BloodHound was originally created to solve. Is there any way we could maintain the granular control the ldapsearch BOF offers us over enumeration and still be able to use BloodHound?

Enter BOFHound. It aims to serve this very niche need by reading LDAP objects from your ldapsearch results in C2 logs, processing them, and producing BloodHound JSON files.

Thus the name BOFHound — read output from the ldapsearch BOF in log files and make it BloodHound-usable. LogHound just doesn’t have the same ring to it, does it?

This allows for ACL relationships to be parsed (from base64 encoded nTSecurityDescriptor attributes) and for your operators to continue visualizing nodes and relationships in the BloodHound UI where they are happy.

Now you might be wondering “BloodHound collects all data [that we frequently care for] in an AD environment, so how can this work with partial data obtained from manual queries?” Well, it’s simple; the BloodHound UI will only show you what you have enumerated via manual queries and parsed with BOFHound. In other words, it will be incomplete data and, if you’re using this approach, you’re likely fine with that. We can target specific information we want to populate the graph with, such as objects related to our objectives, objects that have privileges we want to compromise, or objects that often make easy targets (i.e., AD CS, SCCM).

But BloodHound will actually show you a little more than only what you’ve queried. Object ACLs return references (SIDs) to other objects in the environment that are granted some permission over the object you queried. When you parse these ACLs without an object tied to the SID, they are represented in the graph by nodes with SIDs for names or question mark icons. For example, if I query only the domain object, run it through BOFHound, upload the result to BloodHound, and check the Inbound Object Control on the domain object, we’ll see this.

Parsing Single Object Reveals the Presence of Many More

I’ve only queried the domain object, but I also now know that these six other objects exist. Knowing their SIDs provides a means to query those objects that might be of interest. As I query them and rerun BOFHound, we can slowly fill in that picture and expand it, essentially providing a way to identify objects of interest, and work backwards from them.

The Fog of War

A while back, I was talking with Jared Atkinson about BOFHound and these very misconceptions when he made a very apt analogy: clearing the fog of war. In games like Civilization or Age of Empires, you start surrounded by the “fog of war,” representing the world you know exists, but otherwise know nothing about. As you scout around, you reveal more of the map, pushing back the fog of war, and gaining more information about the game’s world.

An unsophisticated player may just send their scouts out to chart the entire map as fast as possible. This could end up being advantageous, but it could also backfire by increasing the probability of encounters the player is unprepared for (i.e., a hostile faction). A sophisticated player may choose to scout areas as it’s advantageous to them, or when they’re prepared to deal with potentially hostile discoveries.

Brb, Building a Scout

As a prospective BOFHound user, the fog of war is the great unknown AD environment: objects, relationships, attack paths, etc. Immediately trying to chart the entire map is like trying query every AD object at once (i.e., (objectClass=*), running SharpHound); very beneficial data to have if successful, but you’re at high risk of revealing your presence to the hostile blue team. BOFHound is supposed to aid you in taking the careful, “sophisticated player” approach. Each time you manually run a batch of LDAP queries and parse/process with BOFHound, you clear a bit more of the fog and incrementally learn more about the environment you’re in. It is an iterative process (query → parse → query, etc.) until you feel you have sufficient information to take additional action or move on.

I think it goes without saying, but this approach is quite niche. If you do not care about being detected performing LDAP reconnaissance or know/think an alert will not fire for something like running SharpHound or ADExplorer, then you should run them. Having a more complete dataset will always allow you to spend your time more efficiently. I use this methodology described with BOFHound a handful of times a year, when I care about being stealthy; you really have no need for this in your playbook otherwise.

I hope this detour helped clear up some of the self-inflicted misconceptions around BOFHound’s purpose, intended usage, and name. This took up way more space than I initially intended (and became a bit rant-y), but now we can get into the AD CS updates.

The Good Stuff

In addition to the AD CS support, I recently added parsing support for Havoc log files. The rest of this blog will use the ldapsearch BOF via Havoc to demo one method of AD CS enumeration. While you’re probably not rolling out Havoc on your red team assessments, I realized only supporting log parsing for commercial C2s might otherwise turn users away from testing BOFHound in a lab. Havoc ships with an outdated version (as of 10/22/2024) of the ldapsearch BOF (needs updated for AD CS querying), but that can be easily remedied by copying the latest BOFs over to havoc/client/Modules/SituationalAwareness/ObjectFiles/and updating the ldapsearch_parse_params() function within hacov/client/Moduels/SituationalAwareness/SituationalAwareness.py to the definition in this gist.

On past assessments, I’ve typically leveraged one of the various adcs_enum BOFs included in situational awareness collection for AD CS enumeration and config analysis. These work great and I’ve used them to identify vulnerable templates and AD CS ESC paths during real-world engagements. Why bother switching enumeration playbooks? Manually analyzing a wall of certificate config text can work, but it can also be error prone, especially when it comes to trying to unroll group memberships for permissions like enrollment rights.

Trusty Old Text Wall of Certificate Configs

While it’s still all too common to find paths like ESC1 with groups such as Domain Users, Domain Computers, and Authenticated Users jumping out when checking enrollment rights, unrolling nested rights (like the path below) isn’t always so straightforward when reviewing these config dumps.

ESC1 Path Through Nested Group Membership

The question the remainder of the blog tries to answer — can we piece together this same picture without burning the red team by running SharpHound? My coworker Jonas Bülow Knudsen released a very informative blog about AD CS attack paths in BloodHound when they were introduced and his blog details the types of LDAP objects relied upon for mapping AD CS relationships. In short, there are six “new” types of objects we care about:

• Enterprise CAs
• AIACAs
• Root CAs
• NTAuth Stores
• Certificate Templates
• Issuance Policies

If we query these objects (and the domain object), we can graph out the attack paths. There’s no “right” way to do this with ldapsearch, but a basic approach is a sequence of queries based on object class. All the target objects are nested in the Configuration naming context — technically we could query them all at once with (objectClass=*)and a search base of CN=Cofiguration,DC=domain,DC=local. However, if you’re interested in this manual approach in the first place, you may not be interested in that sort of wide-ranging query 😉.

Here’s a sample query transcript to get you started:

# Query the domain object
ldapsearch (objectclass=domain) *,ntsecuritydescriptor

# Query Enterprise CAs
ldapsearch (objectclass=pKIEnrollmentService) *,ntsecuritydescriptor 0 3 "" "CN=Configuration,DC=domain,DC=local"

# Query AIACAs, Root CAs and NTAuth Stores
ldapsearch (objectclass=certificationAuthority) *,ntsecuritydescriptor 0 3 "" "CN=Configuration,DC=domain,DC=local"

# Query Certificate Templates
ldapsearch (objectclass=pKICertificateTemplate) *,ntsecuritydescriptor 0 3 "" "CN=Configuration,DC=domain,DC=local"

# Query Issuance Policies
ldapsearch (objectclass=msPKI-Enterprise-Oid) *,ntsecuritydescriptor 0 3 "" "CN=Configuration,DC=domain,DC=local"

If you’re new to the ldapsearch BOF (or even just its recent argument updates), here’s a quick breakdown of its positional arguments. Consider this query from the examples: ldapsearch (objectclass=pKIEnrollmentService) *,ntsecuritydescriptor 0 3 "" "CN=Configuration,DC=essos,DC=local" — what does this mean?

https://medium.com/media/095f6961612f6b8e24622c1c90fbdbeb/href

Here’s an example of one transcript query performed with the ldapsearch BOF via Havoc. I’m doing this enumeration across a domain trust in my lab (GOAD, from sevenkingdoms.local to essos.local), hence the explicit definition of domain controller to query and search base (even for objects in the default naming context).

Query for AIACAs, NTAuth Stores, and Root CAs

After running each of the queries in the sample transcript, we can parse that minimal dataset from the Havoc loot logs with BOFHound.

bofhound -i /opt/havoc/data/loot --parser havoc --zip BOFHound Parsing the Log Data

After the data has been parsed, we can load up BHCE and upload the output archive.

curl -L https://ghst.ly/getbhce > docker-compose.yml
sudo docker compose pull
sudo docker compose up

In the UI, we can use some of the prebuilt queries to help us find common misconfigurations and escalation paths. I’ll start with the prebuilt Enrollment rights on ESC1 certificate templates query, which will limit the templates I view to just those that meet ESC1 requirements.

Prebuilt AD CS Queries

Here’s what those results look like with the objects we queried in the lab. We know the SIDs ending in 519 and 512 are Enterprise Admins and Domain Admins, but we’ve got an unknown object with a resource ID (RID) of “1602”.

The “Fog of War” — Unknown Objects in the Graph

If we issue an LDAP query for that mystery SID, we can determine that it’s a group (think back to the original attack path screenshot we’re working towards).

ldapsearch (objectSid=S-1–5–21–2301939034–812057587–2058894929–1602) *,ntsecuritydescriptor Query the Unknown BloodHound Node

That returned properties for the group granted enrollment rights, including its distinguished name, which we can use to unroll the group members.

Just One More Turn

To unroll the group’s members (return first and Nth degree members) we can take the group’s distinguished name and issue an LDAP query using the LDAP_MATCHING_RULE_TRANSITIVE_EVAL matching rule.

ldapsearch (memberOf:1.2.840.113556.1.4.1941:=CN=Nested1,CN=Users,DC=essos,DC=local) *,ntsecuritydescriptor Unroll Group Membership

That query returns two results in the lab, though only one can be seen in the screenshot. However, if you look closely at the user object returned, you’ll notice the memberOf attribute doesn’t contain the Nested1 group from our query filter (meaning the object must be a Nth degree member).

Now we rerun BOFHound, same as we did before.

bofhound -i /opt/havoc/data/loot --parser havoc --zip

After we ingest the data again, rerunning the same ESC1 enrollment rights query shows the previously unknown SID with enrollment rights belonged to the Nested1 group.

Slowly Clearing the Fog of War

This prebuilt query doesn’t unroll the group members, though. If we click the [email protected] object to bring up the properties pane on the right side, we can click the Inbound Object Control section to unroll enrollment rights (and potentially other ACL-based abuses).

The Unrolled Enrollment Rights Leading to ESC1

This reveals the path we initially examined, showing a way to perform ESC1 through nested enrollment rights. Should we return to BloodHound’s pathfinding tab and search for paths starting at [email protected] and ending at ESSOS.LOCAL, we now have all the data necessary to map the attack path shown at the beginning of this section (if you’re following along in GOAD, your pathfinding might surface a shorter ASCSESC3 path that you have to filter out).

Assessment Debrief

BloodHound currently supports edges for ESC1, ESC3, ESC4 and ESC13. You can quickly query any escalation path abusing one of them with:

MATCH p=()-[:ADCSESC1|ADCSESC3|ADCSESC4|ADCSESC13]->()
RETURN p ADCSESC1, ADCSESC3, ADCSESC4 Edges from GOAD “Misconfigurations” Is Anything Missing?

The ManageCA and ManageCertificates edges from BloodHound are not currently implemented in BOFHound. These relationships require reading values from the registry on CAs, which would require some other “collector” and parser (something akin to how BOFHound supports AdminTo and HasSession edges). These relationships are not currently relied on for any ESC attacks that BHCE supports, but will be if or when BloodHound gains ESC7 support.

Conclusion

This post served to clear up some common misconceptions about BOFHound, introduce the ability to parse AD CS objects, and provide a starting point for querying relevant LDAP objects. I hope that the added support for Havoc makes it easier to follow along with this post in a lab and give BOFHound a try. If you encounter any bugs, please feel free to open an issue on GitHub or shoot me a message in the BloodHoundGang Slack (@Tw1sm).

BOFHound: AD CS Integration was originally published in Posts By SpecterOps Team Members on Medium, where people are continuing the conversation by highlighting and responding to this story.

The post BOFHound: AD CS Integration appeared first on Security Boulevard.

Cybersecurity is a leading concern for risk managers as AI-related cyber risks surge, and despite growing investments, many businesses still lack comprehensive cyber insurance, according to a Nationwide survey.

The post AI Cyberattacks Rise but Businesses Still Lack Insurance appeared first on Security Boulevard.

CHOROLOGY.ai this week added an Automated Compliance Engine (ACE) to its data security posture management (DSPM) platform that makes use of multiple types of artificial intelligence (AI) to rapidly classify sensitive data at scale.

The post CHOROLOGY.ai Extends AI Reach to Classify Sensitive Data appeared first on Security Boulevard.

Cybersecurity firm Proofpoint, which is eyeing an IPO in the next 18 months, is buying startup Normalyze to improve its data protection capabilities and mitigate the threat humans present in an increasingly fast-paced, interconnected, and AI-focus world.

The post Proofpoint Boosting Data Security with Normalyze Acquisition appeared first on Security Boulevard.

Organizations spend 32.4% of security budgets on code security, yet only 44% of developers follow secrets management best practices. Get the full insights in our 2024 report.

The post Voice of Practitioners 2024 appeared first on Security Boulevard.

Introduction

Within today’s quickly transforming threat context, security operations centers (SOCs) need robust tools to detect, analyze, and respond to threats efficiently. ReversingLabs’ integration with Microsoft Sentinel, a cloud-native Security Information and Event Management (SIEM) solution, empowers SOCs with advanced threat intelligence and file enrichment capabilities. This blog post explores how these integrations enhance security operations and streamline incident response.

The post Enhancing Security Operations with ReversingLabs and MicrosoftSentinel Integrations appeared first on Security Boulevard.

Open banking has revolutionized the financial services industry, allowing customers to share their financial data with third-party providers through secure APIs (Application Programming Interfaces). While this has opened up new avenues for innovation, it also brings significant security risks. Securing APIs in open banking is essential to protect sensitive financial data and maintain customer trust. […]

The post Why Does Every Retailer Need Penetration Testing to Ensure Customer Safety? first appeared on StrongBox IT.

The post Why Does Every Retailer Need Penetration Testing to Ensure Customer Safety? appeared first on Security Boulevard.

Generative AI, often abbreviated as GenAI, is undoubtedly here to stay. The power to generate humanlike text, images, code, and...

The post 5 Steps to Assess the Cyber and Privacy Risk of Generative AI appeared first on Symmetry Systems.

The post 5 Steps to Assess the Cyber and Privacy Risk of Generative AI appeared first on Security Boulevard.

Disclaimer 1: This blog post is on a new and still under development toolset in John the Ripper. Results depict the state of the toolset as-is and may not reflect changes made as the toolset evolves.

Disclaimer 2: I really need to run some actual tests and password cracking sessions using this attack, but I'm splitting that analysis up into a separate blog post. Basically I have enough forgotten drafts sitting in my blogger account that I didn't want to add another one by trying to "finish" this post before hitting publish. So stay tuned for new posts if you want to see how effective this attack really is.

Introduction:

It's been about 15 years since I last wrote about John the Ripper's Markov based Incremental mode attacks [Link] [Link 2]. 15 years is a long time! A lot of work has been done applying Markov based attacks to password cracking sessions, ranging from the OMEN approach to Neural Network based password crackers. That's why I was so excited to see a new proof of concept (PoC) enhancement of JtR's Incremental mode that was just published by JtR's original creator SolarDesigner.

The name of this enhancement is likely going to change over time. Originally it was described in an e-mail thread as "Markov phrases". That's not a bad descriptor, but doesn't really get to the heart of the current PoC. Therefore in this blog post I'm going to call this attack after the new script SolarDesigner released (tokenize.pl) and just refer to it as a "Tokenizer Attack". I think this  gets closer to conveying how the underlying enhancement differs from the original Incremental attack which the tokenizer attack is built on.

The next question of course is "What does this new enhancement do?" To take a step back, what make Markov attacks "Markovian" is they represent the conditional probability of tokens appearing together. For example, if you see the letter 'q' in an English word, the next letter is very likely to be a 'u'. How far you look ahead to apply this probability is measured by the "order" of the Markov chain. So the above example would describe a first-order Markov process. If we extended this and said that given a 'q' and then a 'u', the next most likely character would be a 'e', now we are talking about a second-order Markov process. Where this starts to play out compared to a first-order process is that 'qu' -> 'e' with a high probability but the highest probability next character for the substring 'tu' might be 'r'.  Therefore the highest probable letter following a 'u' might change based on the letter before the 'u' Basically the order represents the "memory" of the Markov chain. It can remember X previous tokens of the string it is generating.

The reason I bring this up is that JtR's Incremental mode works with trigraphs which "roughly" can be represented by second-order Markov processes. I use "roughly" since like most Markov implementations, Incremental mode contains nuances and differences from the abstract/academic definition of Markov based processes. Those nuances aren't super important for this current investigation/blog-post so I'm going to gloss over them for now.

One interesting area of research is implementing "variable order" Markov processes. Aka some particularly likely substrings might be created by a third/fourth/fifth/sixth order Markov process, but other less likely transitions might be implemented in a lower order (first/second) Markov process. As an example of that, if you were using a second order Markov chain the initial letters 'or' might generate a next letter of 'k' with a high probability, but if you take a larger step back and see the earlier letters are 'passwor' then the next letter will almost certainly be a 'd' instead. Based on this, it's tempting to "apply the largest memory possible" to your Markov processes. The limiting factor though is if you extend things out too much you run into overtraining issues, not being able to generate substrings not seen in the training data, and general implementation issues (the size of your Markov grammar explodes). So being able to dynamically switch how much memory/state you are keeping track of can be very helpful when generating password guesses. While more research is needed, this is my current theory why the CMU Neural Network Markov based attacks [Link] outperform other Markov implementations. I strongly suspect the Neural Network makes use of a variable order Markov process when generating guesses.

That's a lot of words/background to say that JtR's Tokenizer attack can be thought of as a way to incorporate variable length Markov orders into JtR's current Incremental mode attack. It does this by identifying certain likely substrings (aka "tokens") and then replacing them in the training set with a "placeholder" character. So for example the likely substring "love" might be replaced with the hex value of x15. This would normally be an unprintable character in ASCII (NAK), but it allows JtR's normal Incremental mode charset to be trained using these replacements. The resulting Incremental charset will have probability information for generating the character "x15" (NAK) as part of a password guess. Now (NAK) isn't actually part of a real password (unless the user did something really cool). This means when running a password cracking session, you'll need to then apply an External mode to translate these guesses back into the full ASCII text outputs. For example the guess "I(x15)MyWife" would be translated by the External mode into "IloveMyWife" which can then be fed into a real password cracking session.

While I can certainly dive more into the details of the tokenizer attack, this intro is already too long. So lets instead look at how to run it!

References:

• Post by SolarDesigner announcing the release of the tokenize.pl script: [Link]
• John the Ripper Bleeding Edge: [Link]

Configuring The Attack: 1) Update JtR Bleeding Edge:

• The new code, (including tokenize.pl) is available in the newest version of JtR Bleeding Jumbo.
• To make use of it, clone the gihub repository and make sure you are on the "bleeding-jumbo" branch which is the default. [Link]
• (Optional) Rebuild JtR from source.
• This is optional since the new code "should" work with older versions of JtR. But you might want to rebuild JtR to be on the safe side.

2) Create a Custom Incremental .CHR File:

• Run the new tokenize.pl script on your training passwords. 

• Notes:
• Save the full output of this tool, as you'll need to run the Sed command to parse/tokenize your trianing set, and you'll need to paste the External "Untokenize" script to your john.conf file. Both of these steps will be described later

• Example:
• ./tokenize.pl TRAINING_PASSWORDS.txt

Example output when training on one million passwords from RockYou. You may note that the results are slightly different than when SolarDesigner trained on the full RockYou list:

• Re-run the sed script on the training set to generate a custom training file.

• Example:
• cat TRAINING_PASSWORDS.txt | sed {{REALLY LONG SED COMMAND}} > new_training.txt
• Closer to Real Example:
• cat TRAINING_PASSWORDS.txt | sed 's/1234/\x10/; s/love/\x15/; s/2345/\x1b/; s/3456/\x93/; s/ilov/\xe5/; s/123/\x6/; s/234/\x89/; s/ove/\x8c/; s/lov/\x90/; s/345/\x96/; s/456/\xa4/; s/and/\xb2/; s/mar/\xc1/; s/ell/\xd9/; s/199/\xdf/; s/ang/\xe0/; s/200/\xe7/; s/ter/\xe9/; s/198/\xee/; s/man/\xf4/; s/ari/\xfb/; s/an/\x1/; s/er/\x2/; s/12/\x3/; s/ar/\x4/; s/in/\x5/; s/23/\x7/; s/ma/\x8/; s/on/\x9/; s/el/\xb/; s/lo/\xc/; s/ri/\xe/; s/le/\xf/; s/al/\x11/; s/la/\x12/; s/li/\x13/; s/en/\x14/; s/ra/\x16/; s/es/\x17/; s/re/\x18/; s/19/\x19/; s/il/\x1a/; s/na/\x1c/; s/ha/\x1d/; s/am/\x1e/; s/ie/\x1f/; s/11/\x7f/; s/ch/\x80/; s/10/\x81/; s/00/\x82/; s/te/\x83/; s/ve/\x84/; s/as/\x85/; s/ne/\x86/; s/ll/\x87/; s/or/\x88/; s/ta/\x8a/; s/st/\x8b/; s/is/\x8d/; s/01/\x8e/; s/ro/\x8f/; s/20/\x91/; s/ni/\x92/; s/at/\x94/; s/34/\x95/; s/45/\x97/; s/it/\x98/; s/08/\x99/; s/mi/\x9a/; s/ca/\x9b/; s/ic/\x9c/; s/da/\x9d/; s/he/\x9e/; s/21/\x9f/; s/nd/\xa0/; s/me/\xa1/; s/ng/\xa2/; s/mo/\xa3/; s/ba/\xa5/; s/sa/\xa6/; s/ti/\xa7/; s/56/\xa8/; s/sh/\xa9/; s/ea/\xaa/; s/ia/\xab/; s/ol/\xac/; s/se/\xad/; s/ov/\xae/; s/be/\xaf/; s/de/\xb0/; s/co/\xb1/; s/ss/\xb3/; s/99/\xb4/; s/to/\xb5/; s/22/\xb6/; s/oo/\xb7/; s/02/\xb8/; s/ke/\xb9/; s/ee/\xba/; s/ho/\xbb/; s/ey/\xbc/; s/ck/\xbd/; s/ab/\xbe/; s/et/\xbf/; s/ad/\xc0/; s/13/\xc2/; s/07/\xc3/; s/pa/\xc4/; s/09/\xc5/; s/06/\xc6/; s/ki/\xc7/; s/98/\xc8/; s/hi/\xc9/; s/th/\xca/; s/05/\xcb/; s/14/\xcc/; s/25/\xcd/; s/ay/\xce/; s/ce/\xcf/; s/89/\xd0/; s/ac/\xd1/; s/os/\xd2/; s/ge/\xd3/; s/03/\xd4/; s/ka/\xd5/; s/ja/\xd6/; s/bo/\xd7/; s/do/\xd8/; s/04/\xda/; s/e1/\xdb/; s/nn/\xdc/; s/em/\xdd/; s/31/\xde/; s/15/\xe1/; s/18/\xe2/; s/ir/\xe3/; s/91/\xe4/; s/om/\xe6/; s/90/\xe8/; s/30/\xea/; s/nt/\xeb/; s/di/\xec/; s/si/\xed/; s/ou/\xef/; s/un/\xf0/; s/24/\xf1/; s/us/\xf2/; s/88/\xf3/; s/ai/\xf5/; s/78/\xf6/; s/y1/\xf7/; s/so/\xf8/; s/pe/\xf9/; s/ot/\xfa/; s/ga/\xfc/; s/ly/\xfd/; s/16/\xfe/; s/ed/\xff/'  > new_training.txt

• Convert the new_training.txt file to a John the Ripper potfile format

• Reason: Currently JtR's Incremental mode character sets can only be trained from cracked passwords in a potfile. You can't just give it a set of raw plaintext passwords.
• Enhancement: You can totally combine this step with the previous one by piping the output of the original Sed command into this second one. I'm keeping these steps separate for now since my recommendation is going to be to update the tokenizer.pl script to incorporate this step into the Sed command it generates. Basically I'm hopeful I can just delete this step in the future
• Example: 
• cat new_training.txt | sed 's/^/:/' > training.pot

• Run the JtR Incremental mode training program on the new training file.

• Flags:
• --make-charset= : the filename here is the name of the Incremental character file you want to create. Warning: It will overwrite existing files!
• --pot- : In this example, this is the potfile to read in training passwords from. In "normal' usage this is the file where your cracked passwords will be stored.

• Example:
• john --make-charset=tokenize.chr --pot=training.pot

Example output of running the training session on one million training passwords:

3) Update John the Ripper's Config File

• Add the following to John the Ripper's "john.conf" config file
• New Values:
• [Incremental:Tokenize]
• File = $JOHN/tokenize.chr
• Notes:
• If you save your Incremental character file as "custom.chr" you can use the default custom Incremental mode that is already including in John.conf instead
• Feel free to update the name of this attack (in this example it's "Tokenize") to whatever identifier you want to use.
• Add the "Untokenize External Mode" config generated when you ran tokenize.pl to your john.conf
• Notes:
• I don't think there are many restrictions where you paste this in, as long as it is not in the middle of another configuration item or at the very end.

Below is a screenshot of me running the tokenize.pl script again, with the External mode section highlighted.

Next is a screenshot of me pasting the resulting External mode into my John the Ripper config file.

Running The Attack:

To run the attack, you can use the following commands in addition to your normal attack commands:

• Arguments:

• --incremental=Tokenize : You can set this to be whatever name you specified in your john.conf file to use the .chr file you generated with tokenize.pl

• --external=untokenize : This calls the external mode to convert the tokenized output of the Incremental mode attack into a normal password guess

• Example:

• ./john --incremental=tokenize --external=untokenize --stdout

Here is a screenshot comparing the first 25(ish) guesses generated by both the new Tokenize attack and the default JtR Incremental attack. It's interesting to note that the default Incremental attack seems to start off stronger with more likely passwords. What's important though is longer password cracking sessions, which I'll investigate in future tests.

Conclusion: The next step will be to run some actual tests. The experiments SolarDesigner ran seemed to imply a significant improvement when running the tokenize attack over the first two billion guesses compared to a standard Incremental attack. This assumes you run these attacks after cracking the "common" passwords first using a more traditional wordlist attack. I'm having to restrain myself from speculating about the results of future tests that I'm planning on running (better to just run them), but hopefully this blog post is helpful for anyone else who also wants to experiment with this new attack. It's a cool attack and a neat approach so I'm looking forward to seeing how it evolves going forward.

The post Running JtR’s Tokenizer Attack appeared first on Security Boulevard.

NSFOCUS Showcases Two Groundbreaking Topics at SAS 2024: An In-Depth Analysis of the DarkCasino APT Group and the Evolution of New Botnets. SANTA CLARA, Calif., October 30, 2024 – The 17th Security Analyst Summit (SAS), a premier global event focused on cybersecurity, recently concluded in Bali, Indonesia, where NSFOCUS was invited to participate. As the […]

The post NSFOCUS Showcases Two Groundbreaking Topics at SAS 2024 appeared first on NSFOCUS, Inc., a global network and cyber security leader, protects enterprises and carriers from advanced cyber attacks..

The post NSFOCUS Showcases Two Groundbreaking Topics at SAS 2024 appeared first on Security Boulevard.

The post How Security Automation Platforms Streamline SOC Operations appeared first on AI-enhanced Security Automation.

The post How Security Automation Platforms Streamline SOC Operations appeared first on Security Boulevard.

If you process credit card payments, you need to prioritize security. One way to guarantee this safety is by complying with Payment Card Industry (PCI) Data Security Standards (DSS).

The post PCI DSS Self-Assessment Questionnaires: Choosing the Right Type appeared first on Security Boulevard.

If your business processes credit card transactions, it needs to meet the Payment Card Industry (PCI) Data Security Standards (DSS).

The post PCI DSS Compliance Levels and Requirements: A Complete Guide appeared first on Security Boulevard.

Although not a new concept, Operational Relay Box (ORB) networks—often referred to as "covert," "mesh," or "obfuscated" networks—are...

The post An Introduction to Operational Relay Box (ORB) Networks – Unpatched, Forgotten, and Obscured appeared first on Security Boulevard.

Modern apps require hundreds of secrets to function (API keys, cloud credentials, etc.). However, poor management of these secrets can expose sensitive information publicly or to malicious actors.

The post What Is Secrets Management? Best Practices and Challenges appeared first on Security Boulevard.

4 min read The new WIF support capability enables access without having to manage secrets.

The post Aembit Introduces Google Workload Identity Federation Support appeared first on Aembit.

The post Aembit Introduces Google Workload Identity Federation Support appeared first on Security Boulevard.

Handling large volumes of sensitive data in testing environments is challenging. You need to protect customer information, financial records, and other confidential data without compromising security or violating regulations. At the same time, you have to keep data relationships intact and make sure testing accurately reflects real-world scenarios. The risks multiply when data moves between […]

The post Test Data Management Best Practices: Handling Sensitive Data Across Multiple Databases first appeared on Accutive Security.

The post Test Data Management Best Practices: Handling Sensitive Data Across Multiple Databases appeared first on Security Boulevard.

Authors/Presenters:Chloé Messdaghi, Kasimir Shulz

Our sincere appreciation to DEF CON, and the Presenters/Authors for publishing their timely DEF CON 32 erudite content. Originating from the conference’s events located at the Las Vegas Convention Center; and via the organizations YouTube channel.

Permalink

The post DEF CON 32 – AppSec Village – Got 99 Problems But Prompt Injection Ain’t Watermelon appeared first on Security Boulevard.