Cipher and Password Bruteforcing with OpenSSL

Ever had to crack something, but you don’t know the cipher? Sometimes the encrypted text gives you clues on which encryption algorithm has been used, but not always. For those cases, it might be useful with the script I am talking about in this post.

Bruteforcing the cipher type might be the only way to get through your challenge. It will create somewhat large amounts of data, but we’ll look at ways we can make it easier to process.

In the scripts below we have the following inputs:

  • A text file containing all the ciphers OpenSSL support. I’ve listed a bunch of them at the bottom of this post.
  • The password we will be trying to guess, or a dictionary of words. A dictionary could e.g. be the top 1000 common passwords.
  • Encrypted.txt contains our encrypted txt. The encrypted text file could contain base64 data, but then we would have to add the -a flag to the command.

Before running the command, we need a directory “cipherout” in the directory where we are running the command. The following command will try the passwords CompanyName00 through CompanyName99:

while read -r line; do for i in {00..99}; do openssl $line -v -d -in encrypted.txt -pass pass:CompanyName$i -out cipherout/$line-$i.txt; echo $line $i;done; done < openssl-ciphers.txt

If you’d rather use a wordlist for the password guessing, change the command into a double while loop:

while read -r line; do while read -r line2; do openssl $line -v -d -in encrypted.txt -pass pass:$line2 -out cipherout/$line-$line2.txt; echo $line $line2;done < wordlist.txt; done < ciphers.txt

This will produce a list of files inside the cipherout folder, each one representing the cipher type and the password tested. Now, analyze your cipherout folder looking for strings and alphanumeric output and see if anything makes sense. If you’re working this for a challenge, keep in mind that the resulting output could be yet another cipher.

Tools can also be used to create the passwords you are guessing. For example, a great idea could be to use Hashcat to produce the dictionary of words you can use for your cracking activities. Unfortunately Hashcat doesn’t directly support cracking these ciphers, as that tools is mostly used for cracking hashes (normally for password storage), not encryption ciphers. However, it can still create a nifty wordlist you can use though. An idea would be to manually create a list of potential passwords, then use Hashcat’s word mangling rules on this wordlist. In my wordlist I have the words securesolutions and netsecurity. Applying Hashcat’s leetspeak rule on this wordlist produces the following output:

hashcat64 –stdout /tmp/wordlist.txt -r /rules/leetspeak.rule

Quick list of open-ssl ciphers (might be missing some):


Rapid android application pentesting

This is a quick guide to get started with Android application testing. I wont delve into details of testing, but instead cover what is necessary to do in order to get started. The topics I go through are:

  1. Get a hold of an Android device through emulation or physical device
  2. Find and download the APK you want to test
  3. Decompile the APK
  4. Sign, Build and Install the updated APK

Find a suitable Android device

First, get ahold of a suitable Android device emulator, e.g. using the Android SDK or a commercial product such as Genymotion, Alternatively, set your device to USB debugging and connect your phone with a USB cable.

Get a hold of the APK

You need the APK file you want to attack. Normally developers have multiple ways of allowing you access to the APK file, however if it is located on the Android Play store, install it to your device, then pull the APK file with ADB.

Locate your package using ADB

Use the packet manager to list all packages on your device.

Then figure out its path on the device

Use the packet manager to locat the path of the installed package.

Pull the file from the device onto your workstation

Use adb pull a long with the path of the APK you discovered in the last step.

Decompile the APK

Grab apktool to easily decompile th APK into its different parts.

This will give us a directory tree containing assets, smali code, resources and manifests. You can also open up the APK with a zip viewer, e.g. 7zip and view and extract the contents.

Dalvik Excutable into Java

The APK is essentially only a compressed container. You can open it up in e.g. 7zip and review its files. One of the files is a dex file, a Dalvik Executionable, which is essentially the compiled Android application. This file can b decompiled into Java code using dex2jar.

The Dalvik Executable has now been converted into a Java JAR container. This can be further disassembled and inspected by a tool such as jd-gui.

java jar decompiled

Create keystore, build, sign, uninstall and deploy

Once you have made the necessary modifications to the source code, either through modifying e.g. assets or smali, you are now ready to deploy the modified application.

Create a keystore

Build the modified code back into APK

This will create a release folder containing the updated APK.

Sign the updated APK

Uninstall the APK from the device to allow for reinstall

Install the updated APK

Put it all together

The above commands can get tedius to write over and over when making small modifications to your APK. Instead pull them all together into one single line of command as this (commands after the keystore has been created):

Why frustrate yourself over passwords?

When creating a new account for yourself, either at your employeer, on the Internett in general or for your customers, you should in theory adhere to some best practice rules such as creating a strong password. That is:
– Above 20 characters
– A variety of special characters
– No sentences, they alone can quite easily be cracked
– Fully unique password, not used anywhere else, doesn’t look like any of your other passwords.

Sounds easy? No? Exactly… It is impossible to practice what we preach, at least without a system to help us out. In my video below I use a Password Manager to help me solve this issue. Might be interesting if you want a less frustrating and more secure day using good passwords.



I found a security vulnerability, how do I disclose it?

I get different people approaching me all the time regarding this question; how do you disclose security vulnerabilities? In this post I’ll share my thoughts on the subject.

First of all, you should probably stay away from researching vulnerabilities on-line, wihtout permission. Your hat will quickly turn to shades of grey, and suddenly black before you know it. However, if you still want to continue, here are some tips I’ve compiled.

Read – If that haven’t discouraged you, then read on.

Don’t test without permission; stick with bug bounty programs such as HackerOne and BugCrowd. They have huge lists of companies who volunteer their systems to be tested by hackers. Do note, some restrictions usually apply. I’ve had some luck with this before, working out medium sized payouts from different companies.

Disclose it to the vendor. This is the noble and ethical thing to do when you’ve discovered a vulnerability, however you are in the risk that the vendor will not take the testing lighly.
In fact, here is an example of a very severe SQL Injection vulnerability I reported through responsible disclosure. The vulnerability was found through a Google search, and verification was done on a login field to log on as administrator. My disclosure went to the customer directly, while they went to their supplier. Their response is below:

Hi <redacted>,
I can inform you that your current solution was developed quite many years ago, and we are aware of some potential security risks, however we do not consider realistic as there are multiple layers of protection throughout the system, from the outside to inside. If you migrate to our newest solution <redacted>, security will be priority 1 and we are certain most hacker attacks will be virtually impossible. To date you have nothing to worry about, but we see the potential to get you onto the newest product as-soon-as-possible.

Att: The hacker who found this
We consider it a serious offense when it comes to attacking our solution. Our policy is to consider all non-planned penetration testing as a hacker attack and we will prosecute if this type of testing repeats itself.

It is not easy to get payed for your hard work. You might’ve put hours into reverse engineering an application in order to discover the vulnerability, however the vendor may not appreciate it in the sense it should. In fact, they could try get you to sign a non-disclosure agreement, take the report and forget it ever happened. They could even hold you liable if your vulnerability ended up on the internett in some manner.

In case you are not getting the proper replies from the vendor, you could try reach out to their production teams directly. This will only work if you know someone to contact on the inside, albeit open source intelligence could bring you to some contact information.

If you don’t have any luck with the vendor, you could try sell the vulnerability to companies such as HP’s Zero Day Initiative ( These companies might resell the vulnerability to not-so-ethical companies and organisations.

Another option is full disclosure. Just go all out with all your information and see what happens. This can have several bad affects, e.g. black hats and script kiddies instantly abusing your information in order to commit crime or to produce chaos. You might have your 15 minutes of fame, but is it really worth it? Or you could do anonymous full disclosure, but thats hardly any ethical either. Or perhaps only through pain comes success? I won’t be the judge.


If you have leverage, e.g. you are a big commercial company and the vulnerable vendor is your supplier, you could threathen them that there will be implication if your security concerns are not followed through, i.e. discontiniuing the use of their product. Most often it can be helpful to have one of your seniors from your side have a friendly chat with the seniors on their side.

Some news instances, e.g. Null CTRL from Norways newspaper Dagbladet, have a team of journalists ready to talk with you regarding vulnerabilities. They can do the responsible disclosure for you and when it goes to a story, it may even come something good out of it, i.e. additional focus on IT security, perhaps pushing more jobs in the IT security space. 

In all fairness, what you’ve done is most likely illegal, even if it is something silly as just toying with parameters. In some cases the law is not clearly enough defined, and if you are caught doing something someone consider illegal, you might be subject to becoming a test subject in the court subject. All in all, IANAL and you should not take legal advice from anyone else than your lawyer.



Thanks for reading!
Bonus material for my Norwegian readers. This is Norsis’s reply on how to do responsible disclosure:

Som praksis oppfordrer vi alle som detekterer sikkerhetshendelser (sikkerhetshull og sårbarheter) til å melde fra om dette slik at virksomhetene selv kan rette opp i svakhetene. Er det i egen virksomhet er det en selvfølge at dette rapporteres og at du som gjør det ikke blir stilt til ansvar men heller får positiv respons på rapporteringen.  Har du funnet dette i form av “etisk hacking” i en annen virksomhet ville jeg fortsatt ha rapportert til virksomheten om funnet slik at de kan tette igjen sikkerhetshullet. Så lenge du ikke har gått videre å gjennomført et datainnbrudd vil dette i hovedsak bli positivt mottatt av virksomheten. Er du usikker på om du vil rapportere direkte kan du evt. gi oss en beskrivelse av situasjonen så tar vi kontakt med virksomheten det gjelder.”

“Det er spesielt flere forhold som jeg kan peke når det gjelder ulovligheten i dette (sett fra virksomhetens side) siden du påpeker det kriminelle aspektet. Jeg har her også hentet fått underlag fra universitetet i Oslo som har mange som ser nærmere på denne problemstillingen.

Fellesbetegnelsen for dette er datakriminalitet og datakriminalitet defineres gjerne som straffbare handlinger som begås ved utnyttelse av informasjonsteknologi.
Et eksempel på dette er ulovlig inntrengning i datasystemer for å få tilgang til informasjon (datainnbrudd), eller for å slette eller endre data (skadeverk).

Informasjonsteknologien kan også benyttes som middel til å begå tradisjonelle forbrytelser. Gjerningspersonen kan for eksempel endre opplysningene i et dataanlegg med hensyn til hvem som skal motta en elektronisk pengeoverføring (databedrageri).
De siste årene har man sett at en del av kriminaliteten skjer via Internett. Internett brukes blant annet til å markedsføre ulike “investeringer”, som i realiteten er bedragerier. Kriminelle bruker Internett til å kommunisere seg imellom og til å utveksle ulovlig materiale, for eksempel barnepornografi.

Man skiller mellom datakriminalitet og bruk av informasjons- og kommunikasjonsteknologi i tradisjonell kriminalitet. De viktigste former for datakriminalitet er:

Med datainnbrudd menes det å trenge seg inn i datasystemer for å skaffe seg tilgang til beskyttet informasjon. Innbruddet kan straffes når man har skaffet seg tilgang til dataene/programutrustningen. En slik handling er straffbar selv om man ikke har gjort seg kjent med informasjonen. Man kan skaffe seg uberettiget tilgang på mange forskjellige måter, for eksempel ved å misbruke passord eller utnytte sikkerhetshull.

Datainnbrudd rammes av straffeloven § 145 andre og tredje ledd.

Straff etter den tradisjonelle bedrageribestemmelsen forutsetter at en fysisk person er blitt forledet eller lurt. En datamaskin kan ikke forledes. Det er derfor nødvendig med en egen bestemmelse om databedrageri. I stedet for forledelse av en person forutsetter databedrageri at man har påvirket resultatet av en automatisk databehandling. Dette kan skje ved manipulasjon, sletting eller endring av data. Databedrageri er en vinningsforbrytelse. Dersom gjerningspersonens motiv ikke er å oppnå økonomisk vinning, men kanskje å skade eller misbruke fornærmedes datasystem, kommer ikke bedageribestemmelsen til anvendelse. I stedet rammes handlingen som skadeverk eller ulovlig bruk av datakraft.

Databedrageri rammes av straffeloven § 270 første ledd nr 2
Grovt uaktsomt databedrageri rammes av straffeloven § 271 a.

Manipulasjon, endring eller sletting av data hos andre kan medføre at datalagringsmediet ikke lenger kan brukes slik eieren har bestemt. Det samme gjelder avskjæring av nettilgang. Slike handlinger kan være straffbart skadeverk. Eksempler er implantering av “trojanske hester” eller virusprogrammer, som kan ødelegge data og programmer eller gjøre anlegget sårbart ved å lage sikkerhetshull. Et annet eksempel er handlinger som skaper overbelastninger på dataanlegget eller nettverkslinjen, som medfører at anlegget trer ut av funksjon.

Skadeverk rammes av straffeloven § 291
Grovt skadeverk rammes av straffeloven § 292
Straffeloven § 151 b, som ble innført i 1987, rammer sabotasje mot viktige informasjonssamlinger og anlegg i samfunnet.

Ulovlig bruk av dataressurser
Den som eier en gjenstand, kan bestemme hva den skal brukes til og av hvem. Misbruk av en gjenstand som tilhører andre, kan være straffbart dersom eieren påføres tap eller ulempe, eller man oppnår vinning. Dette gjelder også misbruk av datakraft. Det er dermed straffbart å koble seg på en annens maskin og bruke denne uten samtykke fra eieren. Ved dataangrep er det vanlig at gjerningspersonen utfører en del kommandoer inne i den maskinen han har koblet seg til. I tillegg til datainnbruddet er dette ulovlig bruk av fornærmedes datamaskin. Et annet eksempel er misbruk av fornærmedes datamaskin til eget formål, for eksempel å sikre seg døgnkontinuerlig adgang til Internet Relay Chat (IRC). Slike handlinger har store konsekvenser for dataanleggets eier, som blir tvunget til å bruke ressurser på å finne ut hva som har skjedd og på å gjenopprette datasikkerheten. Utgiftene kommer fort opp i titusenvis av kroner.

Det er altså ikke bare selve inntrengningen som rammes strafferettslig. Også uberettiget bruk innebærer lovbrudd. Bestemmelsen kan også komme til anvendelse ved interne forhold, for eksempel dersom en arbeidstaker misbruker arbeidsgiverens dataanlegg til private formål.

Datamisbruk rammes av straffeloven § 261. Selv om betydelig vinning ikke er oppnådd, kan handlingen likevel være straffbar, men da etter den mildere bestemmelsen i straffeloven § 393.

Dette var mye fra lovsiden av saken, det er viktig at virksomheter tester egen sikkerhet og her er det mange virksomheter/leverandører eller driftsleverandører som ikke gjør en god nok jobb. Ser du svakheter er det derfor viktig å fortsette å melde fra.


15 solid tips on producing good documentation

Documentation has been very dear for me for a long time. The usefulness and importance of documenting is just so immerse! In this post I’ll take a chop on some of my thoughts on documenting.

  1. Keep it simple stupid. Documentation should be brief and to the point. Do your best in having economy of words, don’t spend them easily. Simple bulletpoints goes a far way! Use simple langugage and short sentences.
  2. Use English when writing! Even if you are an entirely non-English shop, write in English still. You never know when you are going to expand into neighbouring countries that may require you to share information in English. Also, I am sure you’ve had to work with a consultant one-time or another, where the consultant is only English speaking. And no, Google Translate won’t cut it.
  3. Screenshots or video are not a preferred way to document. They can compliment existing documentation, but should not be your only documentation.
  4. Don’t create documentation using only copy/paste from whitepapers or the like. Only do this if it is a 100% fit for purpose. Instead consider linking and referencing the material rather than copy it.
  5. Capture the essence of the information you are creating. Make it as simple as possible to read and understand the documentation. “Economy of Words” gets you a long way!
  6. Don’t include passwords in the documentation. Sensitive information is usually OK as the documentation should be behind access restrictions, however passwords are not. Passwords should be changed regulary, so instead of storing them in e.g. the wiki, store them in a password manager. I’ve written a blog about using password managers here.
  7. Documentation should be a part of business requirements. Don’t let systems, services or other things go live without having at least a simple documentation readily available. It shouldn’t take long to set up some simple documentation scaffolding and adding some information to it.
  8. Keep the documentation platform highly available, good performance and ease of use. A wiki, i.e. Mediawiki, is excellent for this. If you make documentation tedious and hard, it won’t be used. Trust me on this!
  9. Knowledge is power; hence many will avoid documenting to keep them valuable to the business. Don’t be this guy! First of all, you will quickly be noticed using this strategy, second, any thriving business will be looking to keep good employees. Documenting, and thus helping build a healthy organisation, will ensure you are sticking around for the end game.
  10. Don’t get stuck doing the same repeatable tasks over and over again. Create good procedures and next time, someone else might be doing your tasks. Spreading the knowledge will allow you to move on to more challenging tasks. Having solid documents may even allow you to easily out-source your work load to the servicedesk.
  11. Keep your documentation solution always ready. If it’s a notepad or a wiki, always have it signed in and ready for you to type in. The moment it is not trivial to document, you are most likely going to skip it. Make it as easy as possible for yourself to create notes.
  12. Do not wait until the last minute to write documentation. You will forget what you did! Instead, write it as you work. If you did something wrong with your setup, requiring you to redo parts of the documentation, that is fine. Just go back and edit the step which you had to change.
  13. Update the documentation, don’t let it go stale. Stale documentation is bad, and wrong documentation is even worse. Ensure that it is simple and easy to update documents.
  14. Not everyone is an author. However, you still need to write something. Just remember to keep your information easily readable and understandable. Point back to point 1, KISS.
  15. Avoid repetition. Duplicate information is a no-go. It is a hassle to update information multiple places, instead use your documention platforms features for inclusion of duplicate information from one master source.

Got some tips of your own? Leave it in the comments. Thanks for reading!

How to Password Reset

A lot of companies and organisations does not do password resets properly today. Here is a recipe on how to do it securely.

  1. User enters the login page. This must be loaded over HTTPS.
  2. User clicks the “Forgot password” button. The user must then supply something unique to the user, e.g. email or username.
  3. The backend system affirms the details submitted, but does not give away if the details are correct or not. The system simply states that “A password reset email has been sent to the user, if it exists”.
  4. The system sends an email to the email address behind the username . The email must contain the following:
    • Who ordered the email? IP address and the country behind that IP is useful information.
    • Time and date the reset was ordered.
    • Some information regarding the password reset function and a notification to ignore this email, if it was not them who ordered it.
    • A unique link back to the system where the password reset in itself is done. The link needs to have the following properties:
      • It should contain a high entropy unique key, e.g. a long and strong unique key. This key should be as good as impossible to guess.
      • A fixed time the key is valid, e.g. the link only allows password resret if it is clicked within 15-30 minutes.
      • The link must be loaded over HTTPS.
    • Inform on the duration the link is active and that it is a one-time use link.
  5. The user is then taken to a form where he can enter his new password.
  6. Send a new email to the user, notifying that his password was in fact changed.

LinkedIn Phish – Investment Proposal

Today I received the following message from a LinkedIn contact:


I hope all is well with you, please review this recommendation for an investment opportunity which am considering a partnership with you if you’re interested. I hope that the reasons for this investment, which are alluded to in more details in the enclosed document( ), will make you consider this alliance positively.

I hope you you will reply soon. With best wishes,

Warm Regards,


I think this looked wierd, so I opened the site in a safe browser and explored a little. It turned out it was definitely a phish. The landing page looks thrustworthy:



The bad guys left a mistake though at . This zip file contains some simple scripts that sends all credentials submitted to the following email address: .The script then redirects you to this PDF:

I’ve sent an email to to notify them about this phish.