Search Results

In this blog post, we describe a phishing attack observed by Polito, Inc., which uses an obfuscated JavaScript attachment. We will then show how to analyze the malicious obfuscated JavaScript by following the attack chain through some static and dynamic testing. It will show how the analyzed code was designed to capture Microsoft O365 credentials and upload them to a website. This specific attack is interesting; attackers are often looking for new and creative ways to deliver their payloads. Their purpose in doing so is multi-folded: An attempt to bypass security products An attempt to bypass security training An attempt to harvest credentials from unsuspecting users Even potential victims may have been trained to avoid opening documents, scripts, and executables from unknown senders, it is nowadays important to be careful with almost any file type. Malicious file attachment: To protect the privacy of the individual that received this file, all identifying information has either been redacted or obscured. An executive received a suspicious email, which they were concerned was sent by a threat actor. The email looked like an eFax message with a poorly worded .htm attachment. The attachment appeared to be a recycled lure of a voicemail attachment as can be seen by the Play button and the 37 secs in the file description. Figure 1 - Spam email with the attachment Malware analysis: The initial phishing message was sent via an attached.htm file named “(redacted) ▶ ─────── 01mins37secs.htm”. The individual did not open the email, but sent a copy of the attachment for analysis. We were unable to obtain email headers of the original email. Static Analysis: I first opened the .htm file using Notepad++ to gain initial insight. I could see that this file contained obfuscated JavaScript programing language. Figure 2 - Partially obfuscated JavaScript Code The first step was attempt to de-obfuscate the code. I used an online tool from Coder’s Toolbox to perform this, with the settings for URL, Decode, and US-ASCII. This approach provided an output of readable code: Figure 3 - Using Coder’s Toolbox to de-obfuscate the JavaScript Code I then used another online tool named js-beautify to clean up the code and make it more presentable: Figure 4 - Using js-beautify to clean up the JavaScript Code Line 3: Contains the recipient of the phishing email Line 4: Contains a Base64 encoded URL link to a php file Line 6: Is a self-contained webpage that replicated a Microsoft Login page Since this code contained an URI Component, it was time to extract some more information. I used Mozilla’s developer tool decodeURI() by pasting in the portions in-between the script and we got what was a prompt to enter our Microsoft Password: Figure 5 - Prompt to enter a password Dynamic Analysis: Using Developer tools from Google Chrome and reloading the .htm page, we can gain some insightful information from the Headers. Here we can see a request to a URL that calls file labeled “o365.php”. Figure 6 - Headers of the .htm file Through a series of JavaScript commands and encodings the captured information, along with other information such as IP address and User-Agent String, are uploaded to the follow URL: https[:]//redacted/../o365logz.txt Figure 7 – Web directory of the malicious URL Figure 8 – Information that is upload and stored by the malicious code How was this possible? Providers such as Google, flag malicious websites when they present a risk for users in the form of malware. From what it appears, this site has only been around for approximately 4 months, and is not flagged as malicious by a few vendors. Figure 9 – VirusTotal giving a clean score to the malicious URL Figure 10 – AlienVault not seeing any activity associated with the site How can you protect yourself? Since spam and phishing emails can take a variety of forms, we suggest the following: Never open emails and/or attachments from untrusted sources. If you have received an email that looks “out of the norm”, it is always better to report it to your IT support team or email provider Never enter you credentials in a website that is missing the “https” in the beginning of the URL e.g. “https[:]//login.microsoft.com” is the correct URL. The URL “http[:]//login.microssoft.com” is not Block the spam email address Delete the spam email message Keep your device’s OS, software and anti-malware software up to date Original blog post can be found at: https://www.politoinc.com/post/malicious-efax-attachments-can-potentially-steal-your-microsoft-o365-password

On a business trip that I took in 2017, I needed to print out a document, so I headed down the to the hotel lobby and asked the lady at the desk to direct me to where I could use a printer to print out some documents. She directed me to the business center that was located around the corner. I needed to check my Gmail, so I opened Chrome and was directed to the landing page where someone previously had logged in. It showed a person’s name and their iCloud email address. I used the link to choose another user and signed into my Gmail account. I printed my documents and then signed out of Chrome, but curiosity got the best of me. I Googled the iCloud account which the first hit was a Facebook profile. I click the link and I was directed to Facebook’s homepage and the username and password was automatically populated. I clicked sign in just to verify the credential’s and was immediately logged. Since this was an iCloud account, I went to the iCloud homepage and the same thing, the username and password was auto-filled and the credentials were still valid. Of course, I did nothing malicious, so I closed both tabs. Again, being Chrome I went to Chrome’s password settings page. Here, I found dozens upon dozens of stored usernames and passwords. In order to see these stored passwords, you need the Windows password of the current login. This password was conveniently taped to the computer monitor and I was able to verify it worked, by showing one of the stored Chrome passwords. Again, I did nothing malicious but verify the weakness and dangers of the Chrome browser remembering your credential’s and not signing out of websites when you are done conducting your business on a public computer. Here are some suggestions If you don’t have to use a public computer: Don't save your login information. Don't leave the computer unattended with sensitive information on the screen. Erase your tracks. Disable, of don’t use, the feature that stores passwords. Delete your temporary Internet files and your history. Watch out for over-the-shoulder snoops. Don't enter sensitive information into a public computer.

Just how many more data breaches or ransomware takeovers will it take until organization’s take information assurance AKA cyber security seriously? I know for a fact that we are nowhere near this end goal of data protection. If you have to blame a single technician for not patching a server that leads to a compromise, you need to think again and reevaluate your policies and procedures as a whole. Every day I read about another breach or an encryption takeover. I understand that org’s are required to get tested on a regular basis, such as a pentest, vuln test, security or audit; but there is so much information to take from that report. I believe that today’s attack vector is always from the inside going out. E-mail is the easiest way to compromise a network. Long are the days of trying to penetrate network defenses from the outside. How easy is it to harvest an email and phish that address to get an unsuspecting victim to click on one simple link? Perhaps it’s embedded PDF? Or maybe a malicious executable or Microsoft Office document? Whatever the flavor is, there is now a reverse shell into the network. The average time that an attacker is in the network undetected is 150 days. Now comes the part of lateral movement and finding the crown jewels of the organization. Whatever the critical information is, it will be found and exploited for the attacker's benefit. But first persistence. The clock is now ticking to create a persistent connection from the inside back to the attacker’s machine. It’s not uncommon for normal users to be admins even its just local or even worse domain. AV bypass is too easy if I know the product(s) you are running inside the environment. Almost every firewall allows outbound connections initiated from the inside. Persistence can be achieved by creating or harvesting an account or creating registry keys that beacon back whenever the machine is rebooted. Attackers don’t always need elevated rights, just enough rights to get access to the information that is most critical to the organization. Second, lateral movement. It’s too easy to hide lateral movement inside of “normal Microsoft Windows traffic”. Do you allow SMB, PSEXEC or RDP inside the environment? Awesome, there’s malicious traffic inside your network. Maybe the attacker does some Pass-the-Hash because why not and that’s second, lateral movement. It’s too easy to hide lateral movement inside of “normal Microsoft Windows traffic”. Do you allow SMB, PSEXEC or RDP inside the environment? Awesome, there’s malicious traffic inside your network. Maybe the attacker does some Pass-the-Hash because why not and that’s easier and less time consuming than trying to crack your “complex password”. Or perhaps accounts are using the same username and password across multiple applications. The point is, lateral movement is hard to detect unless you know what normal is for the network. Third, exfiltration. Time to move the data out. If an organization hasn’t detected an attack, they might during data. Third, exfiltration. Time to move the data out. If an organization hasn’t detected an attack, they might during data exfil. Depending on how much data needs to move will determine the method. Small amounts of data can be moved via C2 channels, but large amounts of data will probably be hidden will other “normal” traffic. If an attacker can get that data to blend in with the rest of traffic, well I hope it wasn’t the secret recipe. It’s time to take a stance as security and cyber professionals and take back our networks. Executives and managers need to understand what a secure environment looks and feels like, even if it’s a painful process. Lock down users, devices, and applications across the environment. Original Blog can be found at: https://www.cybrary.it/blog/0p3n/how-much-more-needs-to-be-compromised/

Just knowing that the notion of a simple three letter word could wreak havoc in my life is scary beyond anything imaginable. I am speaking of a simple “Yes”. Getting a call from an unsolicited number has me screening my calls more than ever before. My thought now is, if it is that important the caller can leave me a VM and I will happily return their call. If I do happen to pick up the phone by nature and the caller does identify me by name from a legitimate company, such a job recruiter, what then? Do I confirm my identity or do I blow off the call and seem like a jerk? I think that is difficult to answer. I did happen to blow off the last recruiter that called me. I was not expecting a phone call since I am not in the job market. I am now, and still, politely declining to give my phone number or email address during the checkout process at all retailers. I always did, and now more than ever, seeing that this once oblivious pieces of information are just as sensitive as my other PII, such as my address, date of birth, and SSN. When a scammer places an unsolicited call, they are more than likely recording the call. If the scammer can get the person on the other side to confirm their identity, they pretty much can act on your behalf and steal your identity. Your recorded voice combined with public information such as your address and date of birth will let the scammer apply for credit and you will probably never know unless you regular check your credit history or have active credit monitoring. I would actually prefer to get an email or social media message beforehand to let me know that someone is going to call me or that I can call them. This still does not ease the feeling that someone could be recording the phone call without my knowledge. It is a time that we must stay vigilant, and educate ourselves and others around us. Just as a bank would never send you an email to confirm information, we should have the same mindset and think that they would also never call unless there is some sort of disclaimer, such as the call be being recorded and monitored for a potential fraud alert. Original Blog can be found at: https://www.cybrary.it/blog/0p3n/hell-unsolicited-phone-call/