cyphershell.tech

Author: Ben

  • Western Sydney University Breach

    The University’s IT team reported the breach this month. The final object of the hackers’ actions: student and faculty data found in Office 365 and an Isilion database of documents. However, no public statement yet as to who did it or really why. I feel like it could’ve been a disgruntled student aiming to get info on another student or even teacher. But let’s look at basic issues that probably plague most public universities.

    Office 365 MFA

    Since 2019, Microsoft has been rolling out Security Defaults for individual and enterprise 365 solutions. Security Defaults include pre-enabled MFA setting for all users in the new tenant when it is set up.

    This is great news for anyone signing up for a random personal Office 365 subscription or for a brand new business starting out. However, it is safe to say that most universities have been around a lot longer than 5 years.

    This means MFA was most likely not enabled by default for Western Sydney University students and faculty. Even though it is possible that their IT team could have implemented MFA, I don’t see this security measure (no matter how important) to be the number one priority for a school. The IT department is probably swamped with provisioning new devices for new students each year and replacing broken tech as the year goes on.

    Thus, in this hack the most probably and simple breach of entry was a set of compromised credentials or weak passwords — since university email address patterns are public knowledge, making it easy to guess usernames.

    Isilon Storage

    Isilon may sound like a fancy cloud solution but it is nothing more than a NAS device. It operates in a storage cluster using FreeBSD. This means it provides access via the HTTP, SMB, NFS, and FTP protocols.

    And as any good script kiddie will do (such as myself), one will search and find the default admin credentials for Isilon devices. Turns it out it is root:a. That’s it. root for the username and a for the password.

    Now I’m really hoping the storage admins did not keep this default credential set. But, even if it was changed, Isilon provides LDAP/AD authentication. So, if the hacker already breached 365 with working credentials, he could have easily accessed the file storage, as well.

    Solutions

    The answers are always simple. And in this case, it is no different.

    Enable MFA and change default credentials. Yes, it will be annoying and cumbersome to set it up for hundreds or thousands of students and faculty, but it will save you your job later on. School systems are great places for SSNs, financial account numbers, passports, immigration documents, and even PHI. Nobody wants to deal with that mess.

    To enable security defaults:

    1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
    2. Browse to Identity > Overview > Properties.
    3. Select Manage security defaults.
    4. Set Security defaults to Enabled.
    5. Select Save.

    Lastly, change your NFS/SMB shares’ default credentials. Also, remember that if you do use LDAP/AD for authentication to the share, you may lose out on MFA tokens. I don’t know how Isilon, so that’s always a concern.

  • APT29 Microsoft Email Breach Walkthrough

    Below is a plausible narrative on how the breach may have gone down, based on Microsoft’s own After Action Report. These details are not proven, but involve the most plausibly relevant bureaucratic movements, government personnel, and operational tactics.

    Purpose

    During the Summer of 2023, SVR Director Sergey Naryshkin attends a regular Security Council meeting and receives strategic objectives to help with the Ukraine effort. This may include:

    • Intelligence on US DoD contractors’ efforts and technologies against Russia.
    • Intelligence on US leadership for an influence campaign
    • Intelligence on current US government technological infrastructure

    Director Naryshkin takes these strategic objectives to his SVR leadership and they conclude that the most efficient and effective way to answer these questions is to gain intelligence from Microsoft. They know that most US federal government and even DoD infrastructure utilize Microsoft’s on-prem or Azure cloud services. Thus, instead of targeting each entity separately, they should target Microsoft’s communications to kill multiple birds with one stone. SVR leadership tasks its Foreign Counterintelligence Directorate and its Science & Technology Directorate to produce a task force aimed at breaching Microsoft’s internal communications for the above-mentioned objectives.

    Fall of 2023, the Task Force produces a Plan of Attack. Winter of 2023-2024, the Team enacts the plan.

    Reconnaissance (TA0043) and Resource Development (TA0042)

    Task Force Team Leader (TL) distributes the following tasks for simultaneous completion:

    • Operative Alpha to analyze past internal Microsoft compromises to compile a list of most commonly used administrative/service account usernames and passwords.
    • Operative Bravo to reach out to the Operational Support Service to create a distributed proxy infrastructures.
    • Operative Charlie to enumerate plausible internal Microsoft 365 tenant subdomains.

    The OpSupport Service obtains operational funds to pay for a legitimate residential proxy service with dozens of addresses based in the US with Monero (XMR) cryptocurrency. OpSupport uses their own proxy/VPN via an Eastern European entity with a US server to purchase the residential proxies via AnyIP proxy service. OpSupport sends the proxy infrastructure information back over to Bravo. Bravo reports back to TL with infrastructure.

    Alpha returns and reports with list of most commonly used usernames/passwords within past internal Microsoft environments.

    Charlie writes a python script to check for tenant name availability (like the one below). Or uses https://o365.rocks/. Then inputs various test/staging environment names into the script to check for plausible testing/staging tenant names. If there is a hit, the operative then queries Google and Github for reference to this domain to see if there is a connection to internal Microsoft infrastructure.

    import requests
import json

def check_tenant_name_availability(tenant_name, client_id, client_secret, tenant_id):
    url = f"https://graph.microsoft.com/v1.0/domains/{tenant_name}.onmicrosoft.com"

    # Obtain an access token using client credentials
    token_url = f"https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token"
    token_data = {
        'grant_type': 'client_credentials',
        'client_id': client_id,
        'client_secret': client_secret,
        'scope': 'https://graph.microsoft.com/.default'
    }
    token_response = requests.post(token_url, data=token_data)
    token = token_response.json().get('access_token')

    if not token:
        print("Failed to obtain access token")
        return

    headers = {
        'Authorization': f'Bearer {token}'
    }

    response = requests.get(url, headers=headers)

    if response.status_code == 404:
        print(f"The tenant name '{tenant_name}' is available.")
    elif response.status_code == 200:
        print(f"The tenant name '{tenant_name}' is already taken.")
    else:
        print(f"An error occurred: {response.status_code}, {response.text}")

# Example usage
tenant_name = "exampletenantname"
client_id = "your_client_id"
client_secret = "your_client_secret"
tenant_id = "your_tenant_id"

check_tenant_name_availability(tenant_name, client_id, client_secret, tenant_id)

    Initial Access (TA0001) and Credential Access (TA0006)

    TL tasks Alpha to run a slow, password spray script on the plausible tenant domains, utilizing the proxy infrastructure and compiled credentials. After two weeks, Alpha receives a hit on prodstaging.microsoft.com with the username testdevadmin and password password123. Script output indicates that testdevadmin requires no MFA.

    Alpha logs into portal.azure.com with these credentials and finds that the testdevadmin user has the Global Administrator Role. The operative then goes to “App registrations” to view connected OAuth apps. He finds a test OAuth app.

    Alpha sees an OAuth app in this Test environment and views its supported account types.

    Alpha sees that this app allows for multi-tenant account access — meaning that it can be accessed from both Production and Test Microsoft environments.

    Discovery (TA0007) and Lateral Movement (TA0008)

    Alpha pivots to production Microsoft environment and logs in to the Azure Portal using the same test tenant credentials and sends a request for the Test OAuth App. This provides a prompt for the test admin to approve it. Now this app has permissions within both the test and prod tenants.

    With this foothold, the Threat Actors can add additional API permissions to create new users, create new apps, and to access all production mailboxes now that the app has access in the prod environment:

    • full_access_as_app
    • Directory.AccessAsUser.All
    • Mail.ReadWrite.All
    • EWS.AccessAsUser.All

    Appendix

    APT29 Mitre ATT&CK Tactics and Techniques

  • Gold Check X Account Takeover

    Scams coming from verified accounts on various platforms is not a new thing under the sun. But it’s another level when, on X, instead of compromising a blue checkmarked individual’s account, hackers OR disgusting pajeet scammers compromise a gold checkmarked account for high profile businesses and organizations. Imagine being contacted by such an account — which is exactly what happened recently to another X user.

    I am unsure what the original account was, but compromising a gold check account and renaming it to X Helps is something I feel a lot of people will fall for.

    The message to @DonutOperator contains a phishing link to hxxp://journey-x-annoying[.]com/case. Let’s start analysis and see if we can take this down.

    Analysis

    VirusTotal gives a 6/94 community score: https://www.virustotal.com/gui/domain/journey-x-annoying.com

    WHOIS lookup in the VT Details tab shows that the domain was created and registered yesterday on 19 January via Tucows Domain Registration.

    URLScan shows the URL leads to an X “Copyright Infrigement” so-called alert:

    But as with 90% of all phishing attempts, the tell is in the details. Most scammers and hackers are foreign and can never get English grammar or spelling right. You’d think they’d be smart enough to just use an online spell check. Or even an AI generated paragraph. Also, they utilize the urgency tactic to rush a naive user into submitting a form right away:

    Copyright infringement [is] detected in your account. If you think [the] copyright infringement is incorrect(?), you should provide feedback on the form. If you can’t give feedback, [y]our account will be permanently deleted from our servers within 24 hours!

    URLScan shows no malicious redirects. VirusTotal shows that it is served by 104.21.52.83 and 172.67.197.67. These are both Cloudflare servers.

    I threw the URL into Any.run sandbox app and found that clicking the Next button on the initial splash page doesn’t bring down any malicious code. Just an X login page: https://app.any.run/tasks/e8fc7414-1e99-4b19-8887-3fac567cb356

    Lastly, I did run dirbuster from a Kali instance in order to find additional web server directories hiding on that domain — but I found nothing. All resulted in 404 http status codes. Granted, the domain has been alive for long and maybe can still be used for additional staging or malware hosting in the future.

    Conclusion

    Infiltration of the actor behind this scam will take an actual chat with the user and sending my own phishing link.

    Overall it is a very effective phishing method. Compromise X accounts via social engineering and then use that account to phish others. Not sure of the scammer’s end game. Maybe to get to a “big fish” account in order to extort the account owner of money to get it back? I’m not sure. In this instance, the scammer just overlayed the phishing page with a real X login page to mimick it. But in reality the hacker is capturing credentials in a MITM attack.

    Compromising gold checkmark accounts is a very easy way to get to someone. Always check for weird URL domains and for incorrect grammar/spelling.