This project's goal is to be simple to create and destroy your own VPN service using WireGuard.

• Terraform >= 1.0.0
• Ansible >= 2.10.5

Run with sudo is necessary because we need permission on localhost to install packages, configure a network interface and start a process.

Select your cloud provider AWS, DigitalOcean and open the directory

You can change the region or key name in the variable.tf

• Initialize Terraform

terraform init

• Plan our modifications

sudo terraform plan

• Apply the changes

sudo terraform apply

• For Digital Ocean you need to declare your token(do_token) in variable.tf or command line:

sudo terraform plan -var "do_token=value"
sudo terraform apply -var "do_token=value"

• Test the connection without VPN

curl ipinfo.io/ip

• Start VPN

sudo systemctl start [email protected]

• Test the connection with VPN

curl ipinfo.io/ip

• Just run:

sudo terraform destroy

• AWS
• Digital Ocean
• GCP
• OCI

Contributions, issues and feature requests are welcome!
Feel free to check issues.

• Work
• Linux client(Debian, RedHat and Arch base)
• Terraform to deploy server on AWS
• Mac client
• Add other cloud providers

• Twitter: @p0ssuidao

Japanese researchers spotted an Olympics-themed wiper targeting Japanese users ahead of the 2021 Tokyo Olympics.

Tokyo Olympics could be a great opportunity for cybercriminals and malware authors, the US FBI warned private US companies of cyberattacks that might attempt to disrupt the 2021 Tokyo Olympics. Researchers from the Japanese security firm Mitsui Bussan Secure Directions (MBSD) discovered an Olympics-themed malware that implements wiping capabilities, The Record reported. The malicious code was specifically designed to target Japanese PCs and was detected ahead of the opening ceremony of the 2021 Tokyo Olympics.

Experts noticed that the file has been uploaded to VirusTotal from France, at the time of its discovery it was detected by multiple antivirus products as a generic threat.

The malicious code was designed to wipe certain file types (DOTM, DOTX, PDF, CSV, XLS, XLSX, XLSM, PPT, PPTX, PPTM, JTDC, JTTC, JTD, JTT, TXT, EXE, LOG) in the user’s personal Windows folder.

The malware only targets data under the Users folder, likely because it was designed to infect users who do not have administrator privileges.

Experts also discovered that the malware targets files created with the Ichitaro Japanese word processor, a circumstance that suggests it was developed to target Japanese users.

The malware also implements evasion and anti-analysis capabilities to prevent the malicious code from being analyzed.

The wiper uses the cURL app to access content on the XVideos adult video portal while deleting files on the infected systems. Experts believe that this feature was implemented to trick experts into believing that the infection took place while accessing adult sites.

The malware is also able to delete itself and evidence of its presence from infected computers.

The actual attack vector seems to be a malicious executable disguised as PDF file, the malicious code was found in a Windows EXE file that was disguised as a PDF file named: [Urgent] Damage report regarding the occurrence of cyber attacks, etc. associated with the Tokyo Olympics.exe.”

“The file looks like a PDF as far as the icon is seen, but it is disguised as an icon, and when you look at the detailed display of the folder, you can see that the extension is EXE as shown below.” reads the report published by the security firm. “The main purpose of this malware is to delete the user’s files, and all the target files under <user folder> ( including subfolders ) are deleted.”

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, 2021 Tokyo Olympics)

The post Japanese computers hit by a wiper malware ahead of 2021 Tokyo Olympics appeared first on Security Affairs.

Probe and discover HTTP pathname using brute-force methodology and filtered by specific word or 2 words at once.

Brute-forcing website directories or HTTP pathname and validate using HTTP response code is not relevant anymore. This tool will help you to perform a penetration test, because it could validate the directories using specific-word or 2 words at once and the results will more accurate.

• Web administrator/login panel
• Credential in some paths
• Third-party token
• Etc

git clone https://github.com/xchopath/pathprober
cd pathprober/

pip3 install -r requirements.txt

• Multiple URL targets (in a file separated by newline) or single URL target
• Multiple paths (in a file separated by newline) or single path
• 1 word or 2 words (filter)
• Save valid results to another file
• Multi-threading

Multiple target, multiple path, and multiple words:

python3 pathprober.py -T target.txt -P path.txt -w "APP_NAME" -w2 "DB_PASSWORD"

Single target, multiple path, and single word:

python3 pathprober.py -t https://redacted.com/ -P path.txt -w "APP_NAME"

Multiple target, single path, multiple words, and save output to file:

python3 pathprober.py -T target.txt -p /.env -w "APP_NAME" -w2 "TWILIO" -o output.txt

bash:~/pathprober$ python3 pathprober.py --help

 ___  ____ ___ _  _ ___  ____ ____ ___  ____ ____
 |__] |__|  |  |__| |__] |__/ |  | |__] |___ |__/
 |    |  |  |  |  | |    |  \ |__| |__] |___ |  \
       Probe HTTP pathname filtered by words

usage: pathprober.py [-h] [-t https://example.com] [-p pathname] [-T target.txt] [-P path.txt] [-w Word] [-w2 Word] [-o output.txt]

PathProber - Probe and discover HTTP pathname using brute-force methodology and filtered by specific word or 2 words at once

optional arguments:
  -h, --help            show this help message and exit
  -t https://example.com
                        Single website target
  -p pathname           Single pathname
  -T target.txt         Multiple target separated by newline
  -P path.txt           Multiple pathname separated by newline
  -w Word               A word that you want to find in a path
  -w2 Word              A secon   d word that you want to find in a path
  -o output.txt         Save the results to file

• @xchopath (from @zerobyte-id)

A researcher found a flaw in Windows OS, tracked as PetitPotam, that can be exploited to force remote Windows machines to share their password hashes.

Security researcher Gilles Lionel (aka Topotam) has discovered a vulnerability in the Windows operating system that allows an attacker to force remote Windows machines to authenticate and share their password hashes with him. The news of the attack was first reported by The Record.

The attack abuse the Encrypting File System Remote (EFSRPC) protocol, which is used to perform maintenance and management operations on encrypted data that is stored remotely and accessed over a network.

Lionel also published a proof-of-concept (PoC) exploit code on GitHub.

“PoC tool to coerce Windows hosts to authenticate to other machines via MS-EFSRPC EfsRpcOpenFileRaw function. This is possible via other protocols and functions as well .” reads the description provided by the expert.

“The tools use the LSARPC named pipe with inteface c681d488-d850-11d0-8c52-00c04fd90f7e because it’s more prevalent. But it’s possible to trigger with the EFSRPC named pipe and interface df1941c5-fe89-4e79-bf10-463657acf44d.”

In the PetitPotam attack demonstrated by the expert, he sent SMB requests to a remote system’s MS-EFSRPC interface and forced its system to initiate an authentication procedure and share its NTLM authentication hash.

The NTLM authentication hash can be used to carry out a relay attack or can be lately cracked to obtain the victim’s password. The PetitPotam attack can be very dangerous because it allows attackers to take over a domain controller and compromise the entire organization.

Gilles highlighted that disabling support for MS-EFSRPC did not work to mitigate this attack. At the time of this writing, there is no workaround to mitigate this issue.

Lionel told BleepingComputer, that this as a vulnerability but rather the abuse of a legitimate function. 

The attack can potentially impact most of the supported Windows versions, it was successfully tested against Windows 10, Windows Server 2016, and Windows Server 2019 systems.

Mimikatz author Benjamin Delpy also successfully tested the PetitPotam attack and published a video PoC of the attack.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, windows)

On Disk, The Devil’s In The Details

Introduction

During red team operations and penetration tests, there are occasions where you need to drop an executable to disk. It’s usually best to stay in memory and avoid this if possible, but there are plenty of situations where it’s unavoidable, like DLL sideloading. In these cases, you typically drop a custom malicious PE file of some sort. Being on disk instead of in memory opens you up to the world of AV static analysis and the set of challenges bypassing it presents. There are many resources on the net about avoiding AV signatures, say for example Metasploit shellcode, by using string obfuscation, encryption, XORs, pulling down staged payloads over the network, shrinking the import table, polymorphic encoding, etc. I’m going to assume you’ve done your due diligence and handled the big stuff. However there are some other more subtle indicators and heuristics AV can use to help spot a malicious binary when it is present on disk. These are what this post is all about.

Data About Data

When you compile a binary, whether it’s a DLL or an EXE, the compiler will automatically include a certain amount of metadata about the resulting binary, such as the compliation date and time, compiler vendor, debug files, file paths, etc. This “data about data” can reveal a lot about an executable, especially an executable never encountered by a given AV engine.

The AV engine’s job is to take files, inspect the metadata, apply heuristics, and determine liklihood of it being malicious. Clearly the more metadata and information we leave in our dropped binary, the more likely it is to be flagged. We are automatically at a disadvantage, since we are writing custom code that has never been seen by the AV engine and its file hash is unfamiliar. Compare that to a very commonly-seen file, like a Firefox installer MSI with a known hash and metadata, seen by many installations of the AV software across customer locations, and you can see how a custom compiled binary can stick out.

All is not lost, however. AV can’t simply declare every newly-seen file malicious, as all known-good files start off as unknown at some point. So the AV must use imperfect signatures, metadata, and heuristics to make a good vs. bad determination. We want to remove as many pieces of information that could push us towards a positive dectection as we can.

Now will making these changes make your malicious payload FUD and guaranteed to slip through? Not at all. If you’re dropping unencrypted Cobalt Strike shellcode all over the place, you’re done. But as AV and EDR gets better, the more important it is to give them as little information as possible. And who wants to burn a perfectly crafted custom payload beacuse you left some silly string in? It’s not a magic bullet, it’s not even an ordinary unmagical bullet, but every little bit helps.

Code Signing

One way developers can help signal to Windows and AV engines that their software is not malicious is by using code signing certs. These are (supposed to be) expensive and difficult to obtain x.509 certificates that can be used to cryptographically sign a compiled binary. The idea is that only the legitimate and properly vetted owner should have access to the private key, and must have legitimately signed the file, indicating that it is trustworthy. This gives AV a high fidelity way of identifying the author.

There are two problems with this approach though. Stuxnet famously stole multiple valid code signing certs in order to sign its payloads and help avoid detection. Certificate private keys occasionally end up committed to Github as well. So a validly signed cert is never a 100% guarantee of non-maliciousness.

The other issue is that sometimes AV engines fail to check the validity of a certificate at all, instead simply checking to see if the file has been signed. Which means as long as we can sign our payload with any old self-signed cert, we would pass this particular check. Lucky for us, anyone can generate a code signing cert and use it to sign their malware. It’s free and easy to automate. This Stack Overflow post shows how to create one on Windows and how to use signtool to sign a binary. On Linux, you can use Limelighter to sign with an existing certificate, or download the cert from a website and use it as a code signing cert:

And the resulting self-signed binary:

CarbonCopy is another good tool that can use website certificates to sign a file.

File Properties

Another piece of data, or rather lack of data, are the file properties of an executable. By default, this information is not included when you compile a binary. It looks like this:

It must be added via a resource file and compiled into the binary. This missing information is another, somewhat low fidelity, indicator that a file may not have been produced by a legitimate software vendor, and is therefore more likely to be malicious. Admittedly, this is probably not a huge red flag to most AV, but it’s easy enough to implement, so why not? The details add up.

Creating the resource file is not the most straightforward process. I found the easiest way was to let Visual Studio create it for me. You create a new item of the type resource, and then add a Version resource. Tweak it how you’d like, and the save the resulting Resource.rc file. I’ve created one and stripped out the extraneous lines for easy use here.

Here are two gists for creating the object file to include with your compilation sources: Windows and Linux. Thanks to Sektor7 for the Windows version.

Here is the result of including a resource file during compilation:

The Rich Header

The Rich header is an undocumented field within the PE header of Windows executables that were created by a Microsoft compiler. It captures some information about the compilation process, including the compiler and linker versions, number of files compiled, objects created, etc. It has been covered in some depth in several places, but a good recap and analysis is here.

Because this header encodes rather specific information about an executable, it provides a way of tracking it between systems. AV engines can use it match up strains of malware, attribution, etc. Some threat actors are aware of this fact however, and try to use it to their advantage. The most well-known case of this was the OlympicDestroyer malware, which spoofed its Rich header to resemble the Lazarus group.

I don’t have code or specific recommendations here, mainly because what you might want to do with the Rich header will depend on what you want to acheive. It is worth knowing about, because it is an indicator that you can use, or have used against you. For instance, the GCC compiler doesn’t include the Rich header. If the environment you’re operating in is dominated by Windows machines, much of the software runnning was likely compiled by Visual Studio. Running a GCC or MinGW compiled binary alone isn’t enough on its own to get you caught, but it may make you stand out, which can often mean the same thing. So you may want to add a Rich header, or remove it, or change it to emulate an adversary, or do nothing at all with it. Just know that it exists, and be aware of what it might tell the opposition about your file. Knowledge is power after all.

If you would like to at least remove the Rich header, peupdate can handle that for you. Another option would be one of the PE parsing Python libraries.

Here is a breakdown of the Rich header, courtesy of the wonderful PE-bear. Note the references to masm and the Visual Studio version used.

Compile Times

Another indicator AV can use to help determine maliciousness in a file is the compilation time. The idea is that most software will have been compiled some time in the past before it is used. A very recently compiled binary, say within the past day or even hour, could look very suspicious, especially running on Bob in HR’s machine, who probably isn’t doing any programming. Even a signed binary with no other obvious signs of being malicious, depending on the compile time, can look mighty strange. As always, context matters. If by chance you’ve breached the development network, new binaries are business as usual.

One complication with timestamps in a PE file is the sheer number of them. This post puts the number at 8, though some are not always included, or are simply for managing bound imports and are not full timestamps. A tool is included for viewing them, and tools like PEStudio are great for this as well. Two commonly modified timestamps are the TimeDateStamp of the COFF File Header, and the TimeDateStamp field of the debug directory:

Like the Rich header, timestamps are not something that must be changed. They are just another piece of information to be aware of, something that can tell the blue team a story. You get to decide what story is appropriate, depending on the context of the engagment.

For an excellent deep dive into timestamps, I recommend this blog post.

Conclusion

The main theme of this post has been about knowing the little details of the malware you write, and the context in which you deploy that malware. Context matters, details add up, and they can make or break an engagement. I hope this list of subtleties will come in handy on your next engagement.

In0ri is a defacement detection system utilizing a image-classification convolutional neural network.

When monitoring a website, In0ri will periodically take a screenshot of the website then put it through a preprocessor that will resize the image down to 250x250px and numericalize the image before passing it onto the classifier. The core of the classifier is a convolutional neural network that is trained to detect the defacement of a website. If the monitored website is indeed, defaced, In0ri will send out warnings via email to the user.

• Python3 (version >=3.6)
• Docker
• Docker-compose

git clone https://github.com/J4FSec/In0ri.git
cd In0ri

Edit the file FlaskApp/sendEmail.py

EMAIL_ADDRESS = "[email protected]"
EMAIL_PASSWORD = "$uper$ecurePa$$word"

Edit the file chatbot.py

CHAT_ID= 'foo' # Channel ID to send notifications to
TOKEN = 'bar' # Bot token retrieved from @BotFather

docker-compose up -d

There's two ways to deploy and using In0ri:

• Running off crontab by periodically visiting the url.
• Internal agent running off the web server

Visit the WebUI on https://<serverIP>:8080/ and click on "Register" then fill in the form and submit it.

Visit the WebUI on https://<serverIP>:8080/ and click on "Register" then fill in the form and submit it.

Click on "Create Agent" then fill in the form and check your email for the Agent's key.

On the web server that you wants to be monitored by In0ri, download the Agent folder from Github repository

Installing the required packages for the internal Agent

python3 -m pip install watchdog
python3 -m pip install requests

Edit the file config.json in the same folder as agent

nano config.json

A key is sent to your email after registering the Agent on the WebUI rootPath is the root directory of the web application that you want to be monitored exludePath are the subfolders that you wants excluded from the scans apiServer is the URL to the API server of In0ri serverIP is the IP of the API server of In0ri

{
    "id":"01",
    "key":"123123123",
    "rootPath":"/var/www/html",
    "excludePath":"",
    "apiServer":"http://<serverIP>:8088/checkdeface"
}

And run the Agent:

python3 agent.py

Model training is handled by Shu

In0ri is built by Echidna with the help of Cu64 and Klone.

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.

Estonian hacker Pavel Tsurkan has pleaded guilty in a United States court to the counts of computer fraud and of creating and operating a proxy botnet.

The Estonian national Pavel Tsurkan has pleaded guilty in a United States court to two counts of computer fraud and abuse.

According to court documents, Pavel Tsurkan (33) operated a criminal proxy botnet composed of more than 1,000 devices. The IoT botnet was tracked as the “Russian2015” because it was using the domain Russian2015.ru.

The infected devices were acting as a proxy to transmit third-party internet traffic, then operators were offering it for rent to threat actors that used it to conduct multiple malicious activities.

“He then sold access to global cybercriminals who channeled their traffic through the victims’ home routers, using the victims’ devices to engage in spam campaigns and other criminal activity. The Alaska victims experienced significant data overages even when there were no home computers connected to the victims’ home networks. The data overages resulted in hundreds to thousands of dollars per victim.” reads the press release published by DoJ. 

The hacker compromised more than 1,000 computers and routers worldwide, DoJ reported that at least 60 victims are in Alaska.

“Today’s cybercriminals rely on increasingly sophisticated techniques to hijack computers and personal electronic devices for their criminal activities. Botnets like the ‘Russian2015’ are a dangerous threat to all Americans and today’s guilty plea demonstrates we can and will hold accountable foreign cybercriminals and their enablers,” said Acting U.S. Attorney Bryan Wilson, District of Alaska. “Our success in disrupting this botnet was the result of a strong partnership between private industry experts and law enforcement.”

The man will be sentenced on November 10, 2021, he faces up to 10 years in prison.

Follow me on Twitter: @securityaffairs and Facebook

Pierluigi Paganini

(SecurityAffairs – hacking, cybercrime)